Unidad VII

CAPA DE TRANSPORTE

Aspectos de diseño de la capa de transporte.

En este documento se dará una introducción a algunos de los aspectos que los diseñadores de la capa de transporte deben abordar. Incluyen el tipo de servicio que se provee a la capa de sesión, la calidad de este servicio, así como las primitivas de la capa de transporte que se proporcionan para invocar al servicio.


Servicios proporcionados a la capa de sesión.

El objetivo fundamental de la capa de transporte consiste en proporcionar un servicio eficiente, fiable y económico a sus usuarios, normalmente entidades (por ejemplo procesos) de la capa de sesión.

De la misma manera como hay dos tipos de servicio de red, también hay dos tipos de servicio de transporte: es decir, orientado a conexión y sin conexión. El servicio de transporte orientado a conexión es similar al servicio de red orientado a conexión, desde muchos puntos de vista. En los dos casos, las conexiones tienen tres fases: La establecimiento, de transferencia de datos y la de liberación.

Dado que los usuarios no ejercen ningún control sobre la subred, no pueden resolver el problema relacionado con un servicio deficiente mediante el empleo de mejores IMP, o bien, incrementado el tratamiento de errores en la capa de enlace.

Básicamente, se puede decir que la existencia de la capa de transporte hace posible que el servicio de transporte sea mas fiable qué el proporcionado por la capa de red subyacente. Los paquetes extraviados, los datos dañados, e incluso los N-RESET de la red pueden ser detectados y compensados por la capa de transporte. Además las primitivas de servicio de la capa de transporte pueden diseñarse para ser independientes de las primitivas de servicio de la capa de red, que pueden variar considerablemente de red a red.

Gracias a la capa de transporte, es posible que los programas de aplicación puedan escribirse utilizando un conjunto normalizado de primitivas, y hacer que dichos programas funcionen en una gran variedad de redes, sin tener que preocuparse de la manera de tratar con diferentes interfases de cada subred y con transmisiones inseguras. Si todas las redes reales perfectas y tuvieran las mismas primitivas de servicio, probablemente no se necesitaría la capa de transporte.


Calidad de servicio.

Otra manera de ver la capa de transporte consiste en considerar que su función primordial es la de enriquecer la QOS (Calidad de servicio) suministrada por la capa de red. La calidad de servicio podría parecer un concepto muy vago (el echo que todos se pongan de acuerdo respecto a lo que realmente constituye un "buen" servicio no es una cosa sencilla), la QOS puede caracterizarse por medio de varios parámetros específicos. El servicio de transporte OSI le permite al usuario especificar valores preferidos, aceptables y no aceptables para estos parámetros, en el momento en que se lleva a cabo el establecimiento de la conexión. Algunos de los parámetros también son aplicables al transporte sin conexión. Dependerá de la capa de transporte el revisar estos parámetros y, de acuerdo con el tipo de servicio de red o servicios que se encuentran disponibles para ella, determinara si la capa puede suministrar el servicio que lo solicita. En lo que resta de esta sección se discutirán los parámetros de la QOS.

El retardo en el establecimiento de la conexión: Es el tiempo que transcurre entre una solicitud de conexión de transporte y la confirmación que recibe el usuario del servicio de transporte. Incluye el retardo de procesamiento en la entidad de transporte remota. Igual que para todos los parámetros que miden un retardo, cuanto mas corto sea este, mejor será el servicio suministrado.

La probabilidad de fallo de establecimiento de conexión: Es el riesgo que no se pueda establecer una conexión adentro del máximo tiempo de retardo permitido; por ejemplo, debido a la congestión de la red, a la falta de espacio en las tablas de las IMP, o bien, otros problemas internos.

El parámetro caudal: mide el numero de octetos de datos del usuario que se transfieren cada segundo, los cuales se miden durante un intervalo de tiempo reciente. El caudal se mide en forma independiente para cada sentido. Realmente hay dos tipos diferentes de caudal: uno de ellos es la razón de transferencia que realmente se mide, en tanto que el control caudal es aquel que la red es capaz de ofrecer. El caudal real puede llegar a ser menor que la capacidad de la red, porque el usuario no estuvo enviando datos tan rápidamente como la red puede aceptarlos.

El retardo de trafico: Mide el tiempo que transcurre entre el envío de un mensaje por el usuario de transporte de la maquina fuente, y su recepción por el usuario de transporte en la maquina destinataria. Como en el caso del caudal, se trata independientemente cada sentido.

La tasa de error residual: Mide el numero de mensajes perdidos o dañados, como una fracción del total de mensajes transmitidos, en el periodo de muestreo. Desde el punto de vista teórico, la tasa de error residual debería ser igual a cero, dado que el trabajo de la capa de transporte precisamente consiste en esconder todos los errores de la capa de red. En la practica, sin embargo, este puede tener un valor finito (pequeño).

La probabilidad de fallo de transferencia: Mide la manera en la cual el servicio de transporte esta actuando, de acuerdo con lo prometido. Cuando se establece una conexión de transporte, se llega de acuerdo con respecto a un nivel dado de caudal, de retardo de trafico y de tasa de error residual. La probabilidad de fallo de transferencia indica la fracción de veces que estos objetivos acordados no se llegaron a satisfacer, durante algún periodo de observación.

El retardo en la liberación de conexión: Es el tiempo que transcurre entre el inicio de la liberación de una conexión por el usuario de transporte y de liberación real en el otro extremo.

La probabilidad de fallo en la liberación de conexión: Es la fracción de intentos de liberación de conexión que no se completaron dentro del intervalo de retardo acordado por la liberación de conexión.

El parámetro protección: proporciona una forma para que el usuario del transporte especifique el interés que tiene de hacer que la capa de transporte brinde protección contra terceros que no estén autorizados (es decir, interceptores de líneas telefónicas) para leer o modificar los datos transmitidos.

El parámetro prioridad: brinda una forma al usuario de transporte para indicar que algunas de sus conexiones son mas importantes que otras y, en caso de que existiera congestión, tenga la seguridad de que las conexiones con alta prioridad obtendrán servicio, antes de las de menor prioridad.

El parámetro resistencia: proporciona la probabilidad de que la misma capa de transporte termine espontáneamente una conexión, ya sea por problemas internos o por congestión.


Primitivas del servicio de transporte.

Las primitivas del servicio de transporte OSI ofrecen, tanto el servicio orientado a conexión como el servicio sin conexión. A continuación se muestra la lista de las primitivas de transporte.

A pesar de las similitudes con el servicio de red, también hay algunas diferencias importantes, entre ellas la mas importante es el servicio de red esta diseñado para modelar el servicio ofrecido por las redes reales (por ejemplo las redes X.25), defectos y todo. Estas redes pueden perder paquetes y, en forma, emitir N-RESET, debido a problemas internos de la red. De este modo, el servicio de red proporciona una manera para que sus usuarios traten con los asentimientos y N-RESET.

El servicio de transporte, por lo contrario, no hace ninguna indicación de los asentimientos o N-RESET. Desde el punto de vista del usuario de transporte, el servicio esta libre de errores. Como es obvio, las redes reales no están libres de error, pero este es precisamente el propósito de la capa de transporte, el proporcionar un servicio fiable por encima de una red insegura.

Los asentimientos y los N-RESET que vienen del servicio de red son interceptados por las entidades de transporte, y los errores se recuperan por medio del protocolo de transporte. Si la conexión de una red se interrumpe, la capa de transporte puede establecer una nueva, y de esta manera continuar con la conexión a partir de donde la dejo la anterior.

Una de las entidades de transporte invoca una primitiva T-CONNECT.request para indicar su deseo de establecer una conexión con el usuario de transporte vinculado a la dirección del punto de acceso al servicio de transporte (TSAP), mencionado en la primitiva T-CONNECT.request. esta primitiva trae como resultado la aparición de un T-CONNECT.indication en el extremo del destinatario. El usuario de transporte, vinculado al TSAP direccionado, recibe la indicación y puede aceptarla mediante un T-CONNECT.response, o rechazarla con un T-DISCONECT.requet. El resultado de una aceptación se envía de vuelta al extremo iniciador como un T-CONNECT.confirm; mientras que el resultado de un rechazo se envía de vuelta como un T-DISCONNECT.indication.

También es posible otro escenario distinto al intentar establecer una conexión, y tiene lugar cuando el mismo proveedor del servicio de transporte rechaza la conexión. Tal rechazo puede ser por culpa del usuario de transporte (por ejemplo, un parámetro erróneo en la primitiva T-CONNECT.request). o por fallo de la entidad de transporte local (por ejemplo, falta de espacio en tablas internas). En este escenario, nada se transmite a través de la red, así que el usuario remoto ni siquiera logra enterarse del intento fallido.

La manera normal consiste en que uno de los participantes emita un T-DISCONNECT.indication. Cualquier participante, el que llama o el llamado, puede iniciar la liberación de la conexión. Si los dos participantes, simultáneamente, emiten una primitiva T-DISCONNECT.request, la conexión se libera sin que ninguna de las dos partes obtenga una indicación al respecto.

El orden en el cual las primitivas de transporte deben ser utilizadas esta gobernado por medio de reglas estrictas. Por ejemplo, no se permite la emisión de un T-DISCONNECT-request cuando no existe una conexión establecida (o por lo menos, que se encuentre en proceso de establecimiento). Hay cuatro estados legales que el extremo de una conexión pueden llegar a tener en un TSAP. Los dos extremos no tienen porque estar necesariamente en el mismo estado. Durante la fase de establecimiento, por ejemplo, el participante iniciador va desde un estado INACTIVO hasta un estado de CONEXIÓN DE SALIDA PENDIENTE, antes de que suceda cualquier otra cosa en el otro extremo. Cuatro estados son los siguientes:

1.- INACTIVO: No hay conexión establecida, ni tratando de establecerse. Es posible tener conexiones tanto de salida como de entrada.

2.- CONEXIÓN DE SALIDA PENDIENTE: Se ha hecho un T-CONNECT-request. La respuesta del corresponsal remoto todavía no se ha recibido.

3.- CONEXIÓN DE ENTRADA PENDIENTE: Llego un T-CONNECT-indication. Todavía no se ha aceptado o rechazado.

4.- CONEXIÓN ESTABLECIDA: Se ha establecida una conexión valida. La fase de establecimiento esta completa y, por lo tanto, se puede iniciar la transferencia de datos.


Protocolos de transporte.

El servicio de transporte se realiza por medio de un protocolo de transporte que se utiliza entre las dos entidades de transporte. En la capa de enlace, hay dos enrutadores, que se comunican directamente a través de un canal físico, en tanto que en la capa de transporte, este canal físico se sustituyen por la subred completa. Esta diferencia tiene muchas implicaciones importantes para los protocolos.

Por otro lado, en la capa de enlace no es necesario que un enrutador especifique con que enrutador desea comunicar cada línea de salida especifica unívocamente un IMP particular. En la capa de transporte se necesita ó se requiere un direccionamiento explícito de los destinos.

Otra diferencia entre las capas de enlace y transporte es la existencia potencial de capacidad de almacenamiento en la subred. Cuando un enrutador transmite una trama ó marco, esta puede llegar o perderse, pero no puede saltar ó rebotar de un lugar a otro durante algún tiempo, ni tampoco esconderse en un extremo alejado del mundo y después emerger repentinamente en algún momento inoportuno, 30 segundos mas tarde. Si el interior de la subred se utilizan datagramas y enrutamientos adaptables, existe una probabilidad poco despreciable de que un paquete pueda almacenarse durante varios segundos y posteriormente entregarse. Las consecuencias, de esta facultad que tiene la subred de almacenar paquetes, pueden ser desastrosas y, por lo tanto, requerir el uso de protocolos especiales.

Cuando mas malo sea el servicio de red, será mas complejo el protocolo de transporte.

La clase 0 es la mas sencilla. En esta se establece una conexión de red para cada conexión de transporte que se haya solicitado, y al mismo tiempo supone que la conexión de red no comete errores. El protocolo de transporte no se realiza un secuenciamiento o control de flujo, basándose en que la capa de red subyacente lo haga todo correctamente. Sin embargo, si proporciona los mecanismos para el establecimiento y liberación de las conexiones de transporte.

La clase 1 es parecida a la clase 0, excepto que se ha diseñado para recuperarse de N-RESET. Si la conexión de red, que se esta utilizando para una conexión de transporte, alguna vez emite un N-RESET, las dos entidades de transporte se resincronizan que continúan a partir del punto en el que se habían quedado. Para lograr esta resincronización, deberán utilizar y guardar taza de números de secuencia, algo que se necesita en la clase 0. La clase 1, fuera de tener la facultad de recuperarse de los N-RESET , no llega a proporcionar ningún tipo de control de error o de flujo adicional al que la misma capa de red proporciona.

La clase 2, al igual que la clase 0, esta diseñada para ser utilizada con redes fiables (tipo A). Difiere de la clase 0 en el sentido en que los dos o mas conexiones de transporte pueden transmitirse (multiplexadas) sobre la misma conexión de red. Esta característica resulta muy útil cuando hay varias conexiones de transporte abiertas, cada una con relativamente poco trafico, el operador aplica una tarifa muy elevada por tiempo de conexión, por cada conexión de red abierta.

La clase 3 combina las características de la clase 1 y 2. Permite la multiplexión y, también, puede recuperarse de los N-RESET. Además, utiliza un control de flujo explícito.

La clase 4 esta diseñada para el servicio de redes tipo C. Tiene características totalmente paranoicas. Esta por consiguiente, deberá ser capaz de manejar paquetes que se hayan perdido, duplicado o dañado, N-RESET, y cualquier otra cosa que la red pueda enviarle. No es necesario recalcar que los protocolos de la clase 4 son bastante mas complejos que los demás. El echo de realizar un trabajo muy intenso, para ser que el servicio sea casi seguro, en las capas de enlace y de red, y después descubrir que no es lo suficientemente bueno para lograr satisfacer las necesidades de la capa de transporte, lo cual propicie que la clase 4 tenga que utilizarse de todos modos ahí, puede resultar al final bastante ineficiente.

La elección de la clase de protocolo, que deberá utilizarse en una conexión dada, es determinada por las entidades de transporte en el momento en que se establece una conexión. La parte iniciadora puede proponer una clase preferente, y cero o mas clases alternas.


Administracion de conexión.

En la capa de transporte, llega a ser mucho mas complejo el establecimiento, la liberación y la administración general de conexiones. En esta sección se verán con mayor detalle algunos de los asuntos relacionados con la administración de las conexiones. También, se vera que a veces se necesitaran protocolos especiales.


Direccionamiento.

Cuando un usuario de transporte desea establecer una conexión con algún otro usuario, deberá especificar con que usuario remoto se conectara. (el transporte sin conexión tiene el mismo problema: es decir, a quien se transmitirán cada uno de los mensajes?) El método que normalmente se emplea consiste en definir puntos de acceso al servicio de transporte (TSAP), a los cuales puedan unirse los procesos y esperar qué llegue alguna solicitud de conexión. Los TSAP son completamente análogos a los NSAP (puntos de acceso al servicio de red).

1.- Un proceso servicio que proporciona la hora del día en la maquina B se une solo al TSAP 122 para esperar un T-CONNECT.indication. La manera como un proceso se une por si mismo a un TSAP queda fuera del modelo OSI y depende totalmente del sistema operativo local.

2.- Un proceso en la maquina A desea averiguar la hora del día, por lo que emita un T-CONNECT.request, especificando el TSAP 6 como la fuente y, el TSAP 122 como el destino.

3.- La entidad de transporte, que se encuentra en A, selecciona un NSAP de su maquina, así como en la maquina destinataria, y establece una conexión de red (por ejemplo, un circuito virtual X.25) entre ambas. Mediante el empleo de esta conexión, puede hablarle a la entidad de transporte localizada en B.

4.- Lo primero que la entidad de transporte en A le comunica a su corresponsal en B es: "Buenos días. Me gustaría establecer una conexión de transporte entre mi TSAP 6 y tu TSAP 122.

5.- La entidad de transporte en B emite entonces un T-CONNECT.indication, y si el servidor de la hora del día que esta en el TSAP 122 esta de acuerdo, se establecerá la conexión de transporte.

En lugar de que todos los servicios imaginables se encuentren escuchando en un TSAP bien conocido, cada maquina, que desee ofrecer un servicio a usuarios remotos, tiene un servidor de procesos especial (o registrador) a través del cual se hace la solicitud de todos los servicios. Siempre que el servidor de procesos este inactivo, escucha en un TSAP bien conocido. Los usuarios potenciales de cualquier servicio deberán comenzar por hacer un T-CONNECT.request, especificando la dirección del TSAP del servidor de procesos.

Una vez que la conexión quedo establecida, el usuario transmite un mensaje al servidor de procesos, indicándole el programa que sesea correr (por ejemplo, el programa de hora del día). Entonces el servidor de procesos selecciona un TSAP seleccionado. Por ultimo, el servidor de procesos envía al usuario remoto la dirección del TSAP seleccionado, después termina la conexión, y vuelve a seguir escuchando nuevamente en su bien conocido TSAP.

Llegados a este punto, el proceso nuevo estará escuchando en un TSAP que ya conoce el usuario, por lo que este puede liberar la conexión que lo une al servidor de procesos y conectarse al proceso nuevo. Una vez que se llega a establecer esta conexión, el proceso nuevo ejecuta el programa deseado cuyo nombre recibió del servidor de procesos, junto con la dirección del TSAP que tenia qué escuchar. Cuando el servidor termina de ejecutar su trabajo, libera la conexión y termina también.

Con frecuencia se utiliza un esquema alternativo para tratar esta situación. En este modelo existe un proceso especial denominado servidor de nombres o también, en algunas ocasionas servidor de directorio. Para determinar la dirección del TSAP correspondiente a un nombre de un servidor dado, como por ejemplo "la hora del día", un usuario establece una conexión con el servidor de nombres . Así, el usuario transmite un mensaje especificando el nombre del servicio, y entonces el servidor de nombres devuelve un mensaje con la dirección del TSAP . Posteriormente, el usuario libera la conexión con el servidor de nombres y establece una nueva con el servidor deseado.

La función del servidor de nombres es análoga a la de la operadora de asistencia al directorio del sistema telefónico que proporciona una correlación de nombres con números. Igual que en el sistema telefónico, resulta primordial, que la dirección del TSAP, utilizada por el servidor de nombres (o el servidor de procesos en el protocolo de conexión inicial), sea efectivamente bien conocida. Si no conoce el numero del operador de información, o podrá llamarlo para averiguar otro numero.


Establecimiento de conexión.

Establecer una conexión suena fácil, pero es en realidad sorprendentemente engañoso, en especial en las redes tipo C. A primera vista, parecería suficiente qué una entidad de transporte simplemente transmitiera una TPDU CR (SOLICITUD DE CONEXIÓN) al destino, y esperar una respuesta CC (CONFIRMACION DE CONEXIÓN). El problema se presenta cuando la red puede perder, almacenar y duplicar paquetes.

El tiempo de vida de un paquete puede restringirse a un máximo conocido por medio de las siguientes técnicas:

1.- Diseño restringido de la subred.
2.- Colocación de un contador de saltos en cada paquete.
3.- Sellado de cada paquete con una estampilla de tiempo.

El primer método incluye a cualquiera de los métodos que evitan que los paquetes entren en un ciclo, combinado con alguna manera de limitar el retardo por congestión sobre la trayectoria mas larga posible (ahora conocida). El segundo método consiste en tener un contador de saltos que se incremente cada vez que un IMP reexpide el paquete. El protocolo de enlace, simplemente descarta cualquier paquete mas antiguo que cierto tiempo acordado previamente. Este ultimo método requiere que los relojes de las IMP estén sincronizados, lo cual bien a ser una tarea nada trivial, a menos que la sincronización se logra fuera de la red, por ejemplo, escuchando la difusión periódica de la hora exacta de alguna estación de radio.

Administración de conexiones basada en un temporizador. El problema original que planteamos era el de encontrar una forma para evitar la terrible pesadilla de paquetes duplicados antiguos que contenían las TPDU CR, DATA y DR, que repentinamente aparecían de la nada, y eran aceptadas como legitimas. Una manera de lograr esto es que la entidad de transporte asigne un identificador de conexión único a cada conexión, para que pueda llegar asentir aquellas TPDU procedentes de conexiones anteriores. Otra segunda manera, es la de utilizar un protocolo de ida-vuelta-ida para el establecimiento de conexiones. Fletcher y Watson (1978) y Watson (1981), propusieron una tercera manera basada en temporizadores. En esta sección se describirá este método. La idea básica esta muy relacionada con la propuesta anterior de liberar una conexión al termino de una temporización, si no existe ningún tipo de actividad. Así , en un esquema, una entrada en la tabla de una entidad de transporte correspondiente a una conexión, no se elimina cuando la conexión es liberada. Sino hasta cuando haya espirado un intervalo de tiempo cuidadosamente seleccionado.

La parte central de su esquema es la siguiente: cuando un emisor desea enviar a un receptor un flujo consecutivo de TPDU crea internamente un registro de conexión. Por medio de este registro de conexión se mantiene un seguimiento de aquellas TPDU que se han enviado, de que asentamiento se han recibido, etcétera. Cada vez que se crea un registro de conexión, se arranca un temporizador. Cada vez que una TPDU se envía, utilizando un registro de conexión creado previamente, el temporizador se arranca de nuevo. Si el periodo del temporizador expira se elimina el registro de conexión. Los intervalos de tiempo para el emisor y el receptor son diferentes, y se seleccionan cuidadosamente, para que el receptor siempre elimine su registro de conexión, mucho antes que el emisor.

La primera TPDU en el flujo contiene una bandera de 1 bit, llamado DRF (Bandera de serie de datos), que lo identifica como el primer elemento de una serie de TPDU . En el momento en que se transmite la TPDU, el temporizador se detiene; si el temporizador vence, se retransmite la TPDU. Si, por otra parte, después de que se efectúen n retransmisiones, no existe todavía un asentimiento, el emisor se da por vencido. El tiempo de abandono tiene un papel muy importante en el protocolo.

Cuando llega al receptor una TPDU con la bandera DRF puesta, el receptor anota su numero de secuencia y crea un registro de conexión. Las TPDU subsiguientes solo se aceptaran si están en secuencia. Si la primera TPDU que llega al receptor no tiene la bandera DRF puesta, se descartara. Eventualmente, la primera TPDU (ya sea original o correspondiente a una retransmisión), llegara y el registro de conexión podrá crearse. En otras palabras, solamente se puede crear un registro de conexión en el momento en que se llega una TPDU con la bandera DRF puesta.

Cada vez que una TPDU llega en secuencia, se pasa al usuario de transporte y se devuelve un sentimiento al emisor. Si llega una TPDU fuera de secuencia, cuando exista un registro de conexión, podrá ser almacenada. También podrá ser asentida. Sin embargo, el echo de que se reciba un asentimiento no implica que todas las TPDU anteriores también hayan sido recibidas a menos que la bandera, ARF (Bandera de serie asentimiento), haya sido puesta.

Una secuencia de TPDU se transmite y todas se reciben ordenadamente y, a su vez, son asentidas. Cuando el emisor obtiene el asentimiento de la ultima TPDU que se transmitió, y ve la bandera ARF, detiene todos los temporizadores de retransmisión. Si no hay mas datos próximos a llegar procedentes del usuario, del transporte, el temporizador del registro de conexión del receptor expira eventualmente, para qué posteriormente también lo haya el del emisor. No hay una necesidad explícita de TPDU de establecimiento o liberación (aunque la bandera DRF es de alguna manera análoga a una TPDU CR).

El emisor, eventualmente, retransmitirá la TPDU al termino de una temporización en forma repetida si es necesario, hasta que sea asentida. Una vez que el receptor haya creado un registro de conexión, se puede llegar a detectar con facilidad una discontinuidad en el flujo de TPDU, y se puede reparar mediante las temporizaciones y retransmisiones del emisor.


Protocolo de transporte sencillo sobre X.25.

Las primitivas de servicio abstractas son las primitivas orientadas a conexión del modelo OSI exceptuando el servicio de datos acelerados, que solo añade complejidad sin que proporcione una nueva visión sobre la forma como funciona la capa de transporte.

Ejemplo de primitivas de servicio.

Nuestro primer problema surge con la manera de expresar las primitivas de transporte del modelo OSI en Pascal. Para el caso de CONNECT. request resulta muy sencillo: se hace llamar al procedimiento de biblioteca denominado connect, el cual puede llamarse con los parámetros apropiados necesarios para establecer una conexión. Sin embargo, el CONNECT.indication es mucho mas difícil.

La primitiva CONNECT.indication viene a ser una excelente manera de modelar como funcionan los teléfonos, pero no es una buena manera de modelar el funcionamiento de los ordenadores.

Para proporcionarle una interfase razonable a nuestra capa de transporte, tendremos que hacer lo que las redes reales hacen, e inventar un modelo diferente mas orientado a ordenador, para el establecimiento de conexión. En nuestro modelo, existen procedimientos disponibles para tal efecto, escucha y conecta. Cuando un proceso (por ejemplo, un usuario de transporte) quiere tener la posibilidad de aceptar llamadas de entrada, llamada al procedimiento escucha, especificando un TSAP, para escuchar. El proceso, entonces, se bloquea hasta que algún proceso remoto intenta establecer una conexión en su TSAP. E l otro procedimiento, conecta, se puede utilizar cuando un proceso desea iniciar el establecimiento de una conexión. El extremo que llama especifica las TSAP local remoto, y se bloquea mientras la capa de transporte trata de establecer la conexión. Si la conexión se establece, los dos interlocutores se desbloquean y pueden comenzar a intercambiar información. Para liberar la conexión se utilizara el procedimiento desconectar. Cuando los dos lados se hayan desconectado, se liberara la conexión. La transmisión de datos tiene exactamente el mismo problema que el establecimiento de conexión: aunque la primitiva T-DATA.requuest pueda realizarse en forma directa por medio de la llamada a un procedimiento de biblioteca, no pueda hacerse de la misma manera para el T-DATA.indication. Aquí se utilizara la misma solución para la transmisión de datos que para el establecimiento de conexión, es decir, una llamada activa envía que transmite los datos y una llamada pasiva recibe que bloquea el proceso que la invoca hasta que un mensaje haya llegado. Por lo tanto nuestra definición concreta del servicio consiste en cinco primitivas: CONNECT (conectar), LISTEN (escucha), DISCONNECT (desconectar), SENDD (envía) y RECEIVE (recibe). Cada una de estas primitivas tiene una correspondencia exacta con los procedimientos de biblioteca que ejecutan la primitiva. Los parámetros para las primitivas de servicio y los procedimientos de biblioteca son los siguientes:

Connum = CONNECT (local, remote)
Connum = LISTEN (local)
Status = DISCONNECT (connum)
Status = SEND (connum, buffer, bytes)
Status = RECEIVE (connum, buffer, bytes)

La primitiva CONNECT tiene dos parámetros, un TSAP local (es decir, una dirección de transporte) local, y un TSAP remoto, remote, y trata de establecer una conexión de transporte entre los dos. Si tiene éxito, devuelve un numero no negativo en connum, utilizado para identificar la conexión en llamadas subsiguientes. Si falla, la razón por la cual fallo se pone en connum, como un numero negativo. En nuestro modelo sencillo, cada TSAP puede participar en una sola conexión de transporte, por lo que una posible razón de fallo es que una de las direcciones de transporte se este utilizando actualmente. Algunas otras razones son las siguientes: el echo de que el hostal remoto este desactivado, que la dirección local sea ilegal, o bien, que la dirección remota sea ilegal.

La primitiva LISTEN anuncia el deseo del proceso que la invoca de aceptar solicitudes de conexión dirigidas al TSAP indicado. El usuario de la primitiva permanece bloqueado hasta que se realice un intento de conectarse con el. No hay ninguna temporización.

La primitiva DISCONNECT termina con una conexión de transporte; el parámetro connum indica cual de ellas. Los posibles errores son los siguientes: que connum permanezca a otro proceso, o bien, que connum no sea un identificador de conexión valido. El código de error, o 0 para el caso en que se tenga éxito, se devuelve en Status.

La primitiva SEND transmite el contenido de tampón como un mensaje en la conexión de transporte indicada, posiblemente en varias unidades si llega a ser demasiado grande. Los posibles errores que se devuelven en Status son los siguientes: que no haya conexión, que la dirección de tampón sea ilegal, o bien que haya una cuanta negativa.

La primitiva RECEIVE indica el deseo del proceso que la invoca por aceptar información. El tamaño del mensaje que llega se coloca en el parámetro bytes. Si el proceso remoto ha liberado la conexión, o bien, si la dirección de buffer es ilegal en el parámetro Status se devuelve un código de error.

Ejemplo de entidad de transporte.

La capa de transporte utiliza las primitivas de servicio de red para poder transmitir y recibir TPDU. Del mismo modo que las primitivas de servicio de transporte del modelo OSI no pueden correlacionares directamente con procedimientos de biblioteca, tampoco lo pueden hacer los procedimientos del servicio de red. En este ejemplo, se le da la vuelta a este problema mediante el empleo de X.25 como interfase de la capa de red. Cada TPDU será transportada en un paquete, y cada uno de estos corresponderá a una TPDU. A continuación, a cada una de estas unidades se les llamara "paquetes". En este ejemplo, se supondrá que el x.25 es completamente fiable (es decir del tipo A) y que no llega a perder ningún paquete ni tener restablecimientos de circuito. En la figura 7.10 se da un ejemplo de programa para llevar a cabo el servicio de transporte requerido. Este programa (que viene a ser efectivamente el código de la entidad de transporte) puede ser parte del sistema operativo del hostal o bien, un paquete de rutinas de biblioteca que corran dentro del espacio de direcciones del usuario. También puede estar contenido en un chip coprocesador o en una tarjeta de red conectada en la parte posterior del hostal .

Sin embargo, es importante mencionar, que, en este ejemplo, la "entidad de transporte" realmente no es en absoluto una entidad separada, si no una parte del proceso del usuario. En particular, cuando el usuario ejecuta una primitiva que bloquea, como LISTEN por ejemplo, la entidad de transporte también se bloquea. Mientras que este diseño es perfecto para un hostal con un solo proceso de usuario, para un hostal con múltiples usuarios, seria mas lógico que la entidad de transporte fuese un proceso separado, distinto de todos los procesos de usuario. La interfase con la capa de red (X.25), se hace a través de los procedimientos ToNet y FromNet (no mostrados). Cada uno de ellos tiene dos parámetros: el identificador de la conexión, que se corresponde uno a uno con los circuitos virtuales de la red; los bits Q y M de X.25, por medio de los cuales se indica que se trata de un mensaje de control y que hay mas datos del mensaje en el siguiente paquete, respectivamente; el tipo de paquete, seleccionado del conjunto CALL REQUEST (solicitud llamada), CALL ACCEPTED (llamada aceptada), CLEAR REUQUEST (solicitud cancelación), CLEAR CONFIRMATION (confirmación cancelación), DATA (datos) y CREDIT (crédito); un puntero a los datos y el numero de octetos de datos.

En las llamadas a toNet, la entidad de transporte (es decir, alguno de los procedimientos de la figura 7.10), lleva todos los procedimientos para que sean leídos por la capa de red; en tanto que en las llamadas a FromNet, la capa de red desmembra el paquete de llegada para la entidad de transporte. Al pasar la información con parámetros de procedimiento, en lugar de pasar el paquete mismo de salida o llegada, la capa de transporte queda aislada de los detalles de protocolo de la capa de red. Si la entidad de transporte intentara enviar un paquete cuando la ventana deslizante del circuito virtual subyacente esta llena, queda suspendida dentro del ToNet, hasta que haya espacio en la ventana. Este mecanismo es transparente para la entidad de transporte y esta controlado por la capa de red, utilizando comandos del tipo EnableTransportLayer y DisableTransportLayer, qué vienen a ser equivalentes a aquellos descritos en los protocolos anteriores.

Además de este mecanismo de suspensión transparente, también existen los procedimientos explícitos Sleep y WakeUp (los cuales no se muestran) llamados por la entidad de transporte. El procedimiento sleep se llama cuando la entidad de transporte se bloquea lógicamente, esperando que suceda un evento externo generalmente la llegada de un paquete. Después de que el procedimiento Sleep haya sido llamado, se detiene la ejecución de la entidad de transporte (naturalmente la del proceso del usuario).

Cada conexión mantenida por la entidad de transporte se encuentra siempre en uno de los siete estados siguientes:

1.- INACTIVO: cuando todavía no se ha establecido la conexión
2.- ESPERANDO: cuando se ha ejecutado un CONNECT y transmitido un CALLREQUEST.
3.- EN LA COLA DE ESPERA: cuando ha llegado un CALLREQUEST; y no se ha realizado un LISTEN.
4.- ESTABLECIDO: la conexión se ha establecido.
5.- TRANSMITIENDO: el usuario esta esperando se le autorice la transmisión de un paquete.
6.- RECIBIENDO : cuando se ha efectuado un RECEIVIE.
7.- DESCONECTANDO: cuando localmente se ha efectuado un DISCONNECT.

Las transiciones entre los estados pueden presentarse cuando se ejecutan las primitivas, cuando llegan los paquetes o cuando termina el tiempo del temporizador.

La mayor parte de los procedimientos son llamados directamente por los programas del usuario; sin embargo PacketArrival y Clock, son diferentes. Estos se activan espontáneamente por la aparición de eventos externos: es decir, con la llegada de un paquete y el clic de un reloj, respectivamente. En efecto, son rutinas de interrupción. Se supondrá que estos jamas se invocaran mientras que este funcionando un procedimiento de la entidad de transporte. Solo cuando el proceso de usuario este durmiendo, o ejecutándose fuera de la entidad de transporte, se les podrá llamar. Esta propiedad es crucial para el correcto funcionamiento de la entidad de transporte.



©Uriarte Ramírez José Rodolfo

©Arredondo Hernandez Edy Paul