Redes informticas/Modelo OSI de ISO/Nivel

de transporte
La capa de transporte es el cuarto nivel del modelo OSI
encargado de la transferencia libre de errores de los datos
entre el emisor y el receptor, aunque no estn directamen-
te conectados, as como de mantener el ujo de la red. Es
la base de toda la jerarqua de protocolo. La tarea de es-
ta capa es proporcionar un transporte de datos conable y
econmico de la mquina de origen a la mquina destino,
independientemente de la red de redes fsica en uno. Sin
la capa transporte, el concepto total de los protocolos en
capas tendra poco sentido.
Objetivo
El objetivo de la capa transporte es proporcionar un ser-
vicio eciente, conable y econmico a sus usuarios, que
normalmente son procesos de la capa aplicacin. Para lo-
grar este objetivo, la capa transporte utiliza los servicios
proporcionados por la capa de red. El hardware o soft-
ware de la capa transporte que se encarga del trabajo se
llama entidad de transporte, la cual puede estar en el n-
cleo del sistema operativo, en un proceso independiente,
en un paquete de biblioteca o en la tarjeta de red.
Servicios
Hay dos tipos de servicio en la capa transporte, orientado
y no orientado a la conexin. En el servicio orientado a la
conexin consta de tres partes: establecimiento, transfe-
rencia de datos, y liberacin. En el servicio no orientado
a la conexin se tratan los paquetes de forma individual.
Es la primera capa que lleva a cabo la comunicacin ex-
tremo a extremo, y esta condicin ya se mantendr en las
capas superiores.
Para permitir que los usuarios accedan al servicio de
transporte, la capa de transporte debe proporcionar algu-
nas operaciones a los programas de aplicacin, es decir,
una interfaz del servicio de transporte. Cada servicio de
transporte tiene su propia interfaz. Con el propsito de
ver los aspectos bsicos, en esta seccin examinaremos
primero un servicio de transporte sencillo y su interfaz.
El servicio de transporte es parecido al servicio en red,
pero hay algunas diferencias importantes. La principal, es
que, el propsito del servicio de red es modelar el servi-
cio ofrecido por las redes reales, con todos sus problemas.
Las redes reales pueden perder paquetes, por lo que gene-
ralmente el servicio no es conable. En cambio, el servi-
cio de transporte(orientado a la conexin) si es conable.
Claro que las redes reales no estn libres de errores, pero
se es precisamente el propsito de la capa de transporte:
ofrecer un servicio conable en una red no conable.
Otra diferencia entre la capa transporte y la de red es a
quien van dirigidos sus servicios. El servicio de red lo usan
nicamente las entidades de transporte. Pocos usuarios
escriben sus entidades de transporte y pocos usuarios o
programas llegan a ver los aspectos internos del servicio
de red. En cambio, muchos programas ven primitivas de
transporte. En consecuencia el servicio de transporte debe
ser adecuado y fcil de usar.
Primitivas
Las primitivas de un transporte sencillo seran:
- LISTEN: Se bloquea hasta que algn proceso intenta el
contacto.
- CONNECT: Intenta activamente establecer una cone-
xin.
- SEND: Envia informacin.
- RECEIVE: Se bloque hasta que llegue una TPDU de
DATOS.
- DISCONNECT: Este lado quiere liberar la conexin.
Y con estas primitivas podemos hacer un esquema senci-
llo de manejo de conexiones. Las transiciones escritas en
cursiva son causadas por llegadas de paquetes. Las lneas
continuas muestran la secuencia de estados del cliente y
las lneas punteadas muestran la secuencia del servidor.
Implementacin
El servicio de transporte se implementa mediante un pro-
tocolo de transporte entre dos entidades de transporte. En
ciertos aspectos, los protocolos de transporte se parecen
a los protocolos de red. Ambos se encargan del control
de errores, la secuenciacin y el control del ujo.
Pero tambin existen diferencias importantes entre am-
bas, como los entornos en que operan, la capa transpor-
te necesita el direccionamiento explcito de los destinos,
mientras que la capa de red no, otra diferencia es la can-
tidad de datos, mucho mayor en la capa de transporte que
en la de enlace de datos.
Cuando un proceso desea establecer una conexin con un
proceso de aplicacin remoto, debe especicar a cul se
1
2
conectar. (a quin mand el mensaje?) El mtodo que
normalmente se emplea es denir direcciones de trans-
porte en las que los procesos pueden estar a la escucha
de solicitudes de conexin. En Internet, estos puntos ter-
minales se denominan puertos, pero usaremos el trmino
genrico de TSAP (Punto de Acceso al Servicio de Trans-
porte). Los puntos terminales anlogos de la capa de red
se llaman NSAP (Punto de Acceso al Servicio de Red).
Las direcciones IP son ejemplos de NSAPs.
Establecimiento de una conexin
El establecimiento de una conexin parece fcil, pero en
realidad es sorprendentemente difcil. A primera vista,
parecera que es suciente con mandar una TPDU (Uni-
dad de Datos del Protocolo de Transporte) con la peticin
de conexin y esperar a que el otro acepte la conexin. El
problema viene cuando la red puede perder, almacenar,
o duplicar paquetes. El principal problema es la existen-
cia de duplicados retrasados. Esto puede solucionarse de
varias maneras (ninguna es muy satisfactoria). Una es uti-
lizar direcciones de transporte desechables. En este enfo-
que cada vez que necesitemos una direccin la creamos.
Al liberarse la conexin descartamos la direccin y no se
vuelve a utilizar. O tambin asignar una secuencia dentro
de los datos transmitidos, pero estos plantean los proble-
mas de que si se pierde la conexin perdemos el orden
del identicador y ya no funciona. Pero la solucin seria
ms fcil si los paquetes viejos se eliminaran de la subred
cada cierto tiempo de vida. Para ello podemos utilizar
las siguientes tcnicas: Un diseo de subred Restringido.
Colocar un contador de saltos en cada paquete. Marcar el
tiempo de cada paquete. Pero en la prctica no vale solo
con hacer esto sino que tenemos que garantizar que todas
las conrmaciones de los paquetes tambin se eliminan.
Liberacin de una conexin
La liberacin de una conexin es ms fcil que su esta-
blecimiento. No obstante, hay ms escollos de los que
uno podra imaginar. Hay dos estilos de terminacin de
una conexin: liberacin asimtrica y liberacin simtri-
ca. La liberacin asimtrica es la manera en que funciona
el mecanismo telefnico: cuando una parte cuelga, se in-
terrumpe la conexin. La liberacin simtrica trata la co-
nexin como dos conexiones unidireccionales distintas, y
requiere que cada una se libere por separado. La libera-
cin asimtrica es abrupta y puede resultar en la perdida
de datos. Por lo que es obvio que se requiere un proto-
colo de liberacin ms renado para evitar la perdida de
datos. Una posibilidad es usar la liberacin simtrica, en
la que cada direccin se libera independientemente de la
otra. Aqu, un host puede continuar recibiendo datos aun
tras haber enviado una TPDU de desconexin.
La liberacin simtrica es ideal cuando un proceso tiene
una cantidad ja de datos por enviar y sabe con certi-
dumbre cundo los ha enviado. En otras situaciones, la
determinacin de si se ha efectuado o no todo el trabajo
y se debe terminarse o no la conexin no es tan obvia.
Podramos pensar en un protocolo en el que el host 1 di-
ga:Ya termine, Terminaste tambin?. Si el host 2 res-
ponde Ya termine tambin. Adis, la conexin puede
liberarse con seguridad.
Pero no es tan able por el problema de que siempre ten-
dremos que esperar la conrmacin de los mensajes reci-
bidos y si esta conrmacin no llega no libera la conexin
y despus puede que necesite la conrmacin de que lle-
go la conrmacin y entraramos en un bucle del que no
podemos salir.
Podemos hacer que al host 1 si no le llega la conrmacin
despus de N intentos (es que quiere la desconexin), se
libere. Esto produce una conexin semiabierta en la que el
host 1 est desconectado pero el host 2 no como no le llega
la conrmacin no se desconecta nunca. Para solucionar
esto creamos una regla por la cual si al host 2 no le llega
ninguna TPDU durante cierta cantidad de segundos, se
libera automticamente.
Manejo de una conexin
Ya examinamos la conexin y la desconexin, veamos la
manera en que se manejan las conexiones mientras estn
en uso. Uno de los aspectos clave es el control de ujo.
Necesitamos un esquema para evitar que un emisor rpi-
do desborde a un receptor lento. La diferencia principal
es que un enrutador por lo regular tiene relativamente po-
cas lneas, y un host puede tener numerosas conexiones.
Esta diferencia hace poco practico emplear la implemen-
tacin que se hace en la capa red.
En esta capa lo que se hace es, si el servicio de red no
es conable, el emisor debe almacenar en un buer to-
das las TPDUs enviadas, igual que en la capa enlace de
datos. Sin embargo, con un servicio de red conable son
posibles otros arreglos. En particular, si el emisor sabe
que el receptor siempre tiene espacio de buer, no nece-
sita tener copias de las TPDUs que enva. Sin embargo, si
el receptor no garantiza que se aceptar cada TPDU que
llegue, el emisor tendr que usar buers de todas mane-
ras. En el ltimo caso, el emisor no puede conar en la
conrmacin de recepcin de la capa red porque esto slo
signica que ha llegado la TPDU, no que ha sido acepta-
da.
Los Buers pueden ser de tres tipos, y usaremos cada uno
de ellos cuando ms nos convenga.
El equilibrio ptimo entre el almacenamiento del buer
en el origen y en el destino depende del tipo de traco
transportado por la conexin.
Multiplexin de conversaciones
La multiplexin de varias conversaciones en conexiones,
circuitos virtuales o enlaces fsicos desempea un papel
importante en diferentes capas de la arquitectura de red.
3
En la capa de transporte puede surgir la necesidad de mul-
tiplexin por varias razones. Por ejemplo, si en un host
slo se dispone de una direccin de red, todas la conexio-
nes de transporte de esa maquina tendrn que utilizarla.
Cuando llega una TPDU, se necesita algn mecanismo
para saber a cul proceso asignarla. Esta situacin se co-
noce como multiplexin hacia arriba.
La multiplexin tambin puede ser til en la capa trans-
porte para la utilizacin de circuitos virtuales, que dan
ms ancho de banda cuando se reasigna a cada circuito
una tasa mxima de datos. La solucin es abrir mltiples
conexiones de red y distribuir el trco entre ellas. Esto
se denomina multiplexin hacia abajo.
Recuperacin ante cadas
Si los hosts y los enrutadores estn sujetos a cadas, la
recuperacin es fundamental. Si la entidad de transpor-
te est por entero dentro de los hosts, la recuperacin
de cadas de red y de enrutadores es sencilla. Si la ca-
pa de red proporciona servicio de datagramas, las enti-
dades de transporte esperan prdida de algunas TPDUs
todo el tiempo, y saben cmo manejarla. Si la capa de
red proporciona servicio orientado a la conexin, enton-
ces la prdida de un circuito virtual se maneja estable-
ciendo otro nuevo y sondeando la entidad de transporte
remota para saber cuales TPDUs ha recibido y cuales no.
Un problema ms complicado es la manera de recuperar-
se de cadas del host. Al reactivarse, sus tablas estn en el
estado inicial y no sabe con precisin donde estaba.
En un intento por recuperar su estado previo, el servidor
podra enviar una TPDU de difusin a todos los dems
host, anunciando que se acaba de caer y solicitando a to-
dos sus clientes que le informen el estado de todas la co-
nexiones abiertas.
Internet tiene dos protocolos principales en la capa de
transporte, uno orientado a la conexin y otro no orienta-
do a la conexin. El protocolo no orientado a la conexin
es el UDP y el orientado es el TCP. El conjunto de pro-
tocolos de Internet soporta un protocolo de transporte no
orientado a la conexin UDP (protocolo de datagramas
de usuario). Este protocolo proporciona una forma para
que las aplicaciones enven datagramas IP encapsulados
sin tener una conexin.
TCP (protocolo de control de transmisin) se dise es-
peccamente para proporcionar un ujo de bytes con-
able de extremo a extremo a travs de una interred no
conable. Una interred diere de una sola red debido a
que diversas partes podran tener diferentes topologas,
anchos de banda, retardos, tamaos de paquete TCP
tiene un diseo que se adapta de manera dinmica a las
propiedades de la interred y que se sobrepone a muchos
tipos de situaciones.
4 1 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES
1 Text and image sources, contributors, and licenses
1.1 Text
Redes informticas/Modelo OSI de ISO/Nivel de transporte Fuente: http://es.wikibooks.org/wiki/Redes_informticas/Modelo_OSI_
de_ISO/Nivel_de_transporte?oldid=130980 Colaboradores: Ezarate y Annimos: 1
1.2 Images
1.3 Content license
Creative Commons Attribution-Share Alike 3.0