La capa de sesin

Las capas de sesin, presentacin y aplicacin constituyen las capas superiores en el Modelo de
Referencia OSI. A diferencia de las cuatro capas inferiores, las cuales estn fundamentalmente involucradas
en proporcionar una comunicacin fiable de extremo a extremo, el objetivo de las capas superiores consiste en
proporcionar una serie de servicios orientados al usuario. Estas parten de un canal sin error, proporcionado
por la capa de transpone, y le aaden algunas caractersticas que resultan tiles para una extensa variedad de
aplicaciones, de tal manera que los programadores de estas aplicaciones no tengan que volver a realizar una y
otra vez, cada una de estas caractersticas como parte de cada uno de los programas individuales.
Bsicamente, la capa de sesin es un invento de la ISO. Antes de la aparicin del modelo OSI,
ninguna de las redes existentes tenla una capa de sesin (aunque algunos de los servicios de sesin del modelo
OSI tambin aparecen en SNA, pero dispersos sobre varias capas). Durante el desarrollo del modelo OSI, se
llev a cabo un debate de magnitud considerable con respecto a la necesidad de tener una capa de sesin. La
propuesta britnica hecha ante la ISO, por ejemplo, solamente tomaba en consideracin cinco capas y entre
stas no se inclua una capa de sesin.
Aunque una mayora del comit de la ISO decidi eventualmente incluir una capa de sesin, deber
quedar claro, sobre todo considerando la brevedad de este capitulo, que la capa de sesin es una capa muy
"delgada", con relativamente pocas caractersticas, comparada con las capas inferiores. Adems, en el
momento en que se establece una conexin en la capa de sesin, se pueden seleccionar diferentes opciones
para deshabitar la mayor parte de las caractersticas disponibles. La capa de sesin no es tan importante como
la capa de transporte, por ejemplo e incluso muchas aplicaciones no llegan a necesitar su reducido nmero de
caractersticas.
Sin embargo, ahora es parte del Modelo de Referencia OSI, por lo que vamos a examinarla y estudiar
los servicios que ofrece, y cmo funcionan.
ASPECTOS DE DISEO DE LA CAPA DE SESION
En esta seccin se estudiarn algunos de los aspectos de diseo de la capa de sesin que son
relevantes. Entre stos se incluyen la administracin de dilogos, la sincronizacin y la administracin de
actividades, entre otros. Estos se pueden considerar como servicios con "valor aadido", colocados encima de
una conexin de transporte desnuda.
Servicios suministrados a la capa de presentacin
La capa de sesin proporciona una serie de servicios a la capa de presentacin. En la figura 7-1 se
muestra su posicin dentro de la estructura jerrquica. Esta figura es similar a la capa de transporte, con la
excepcin de que los puntos de acceso al servicio se llaman ahora puntos de acceso al servicio de sesin
(SSAP), y las unidades de datos de protocolo se denominan unidades de datos de protocolo de sesin (SPDU).
De la misma manera que para la capa de transporte, aqu se utilizarn indistintamente los trminos
proveedor del servicio de sesin y entidad de sesin.

La funcin principal de la capa de sesin consiste en proporcionar una manera por medio de la cual
los usuarios de la capa de sesin (por ejemplo, las entidades de presentacin o, en algunas ocasiones, procesos
del usuario comn y corrientes) establezcan conexiones, llamadas sesiones, y transfieran datos sobre ellas en
forma ordenada. Una sesin podra utilizarse para un acceso remoto desde un terminal a un ordenador remoto,
o para una transferencia de archivos, o para cualquier otro propsito. Aunque en la capa de sesin se
encuentran disponibles primitivas sin conexin, una sesin sin conexin no puede hacer ningn uso de las
caractersticas orientadas al usuario para las cuales se dise la capa de sesin. Por esta razn, el estudio se
enfocar inicialmente al modelo orientado a conexin. Sin embargo, posteriormente en este capitulo se
discutir una aplicacin interesante de sesiones sin conexin.
Una sesin se parece a una conexin de transporte, pero no son idnticas. Por lo general, cuando
llega a presentarse una solicitud para que la capa de sesin establezca una sesin, se deber establecer una
conexin de transporte que se encargue de soportar la conexin. Cuando termina la sesin, se libera la
conexin de transporte. En este ejemplo hay una correlacin uno a uno entre las conexiones de sesin y de
transporte. En la figura 7-2 se muestra esta situacin. Tambin, es posible tener otro tipo de correlaciones.
Considrese el caso de una lnea area que tiene oficinas de reserva en varias ciudades. Cada oficina tiene
agentes con terminales conectados a un miniordenador ubicado en la oficina local.
Los miniordenadores se conectan, mediante una red de rea extendida, a un ordenador principal, en
el cual se encuentra la base de datos de las reservas. Cada vez que un agente contesta una llamada, se
establece una sesin con el ordenador principal. Una vez que la llamada se procesa, la sesin se da por
terminada, pero lo importante aqu es que no hay necesidad de cargar con el problema de liberar la conexin
de transporte subyacente, porque seguramente ser necesaria otra vez en unos cuantos segundos. Es ms
sencillo, por lo tanto, permitir que sesiones consecutivas utilicen la misma conexin de transporte, como se
muestra en la figura 7-2b. En la figura 7-2c se da una tercera forma posible de correlacin entre sesiones y
conexiones de transporte. En este caso se puede observar una sesin que abarca mltiples conexiones de
transporte. Si, por ejemplo, llega a fallar una conexin de transporte (por cualquier razn), la capa de sesin
puede establecer una nueva conexin de transporte y seguir con la sesin sobre la nueva conexin. Si las de
transporte residen en los hostales, esta situacin no deberla ocurrir porque se espera que las entidades de
transporte se puedan recuperar por si mismas de fallos ocurridos en la capa de red (es decir, de la subred). Si
las entidades de transporte, sin embargo, son externas a los hostales, el problema de la recuperacin por fallos
externos se desplaza a la capa de sesin, porque sta entonces, se convierte en la capa inferior del software
que puede sobrevivir a fallos en la subred.
Como cosa aparte, no est permitido multiplexar varias sesiones en una sola conexin de transporte
simultneamente, de la misma manera como la capa de transporte puede multiplexar varias conexiones de
transporte en una conexin de red. En cualquier instante de tiempo, cada conexin de transporte lleva una
sesin como mximo. La multiplexin se lleva a cabo para reducir el costo o mejorar el rendimiento,
procedimientos que vienen a ser funciones de la capa de transporte.

Intercambio de datos
La caracterstica ms importante de la capa de sesin es el intercambio de datos. Una sesin, al igual
que una conexin de transporte, sigue un proceso de tres fases: la de establecimiento, la de utilizacin y la de
liberacin. Las primitivas que se le proporcionan a la capa de presentacin, para el establecimiento,
utilizacin y liberacin de sesiones, son muy parecidas a las proporcionadas a la capa de sesin para el
establecimiento, uso y liberacin de conexiones de transporte. En muchos casos, todo lo que la entidad de
sesin tiene que hacer, cuando una primitiva es invocada por el usuario de sesin, es invocar la primitiva de
transporte correspondiente para que se pueda as realizar el trabajo.
Por ejemplo, cuando un usuario de sesin invoca una primitiva S-CONNECT.request con objeto de
establecer una sesin, el proveedor de sesin slo ejecuta un T-CONNECT.request para establecer una
conexin de transporte (suponiendo que ninguna conexin de transporte se encuentra disponible). De la
misma manera, el establecimiento de una sesin, al igual que el establecimiento de una conexin de
transpone, implica una negociacin entre los corresponsales (es decir, los usuarios) para fijar los valores de
varios parmetros. Algunos de estos parmetros efectivamente pertenecen a la conexin de transporte, como
podra ser la calidad de servicio, y la bandera indicando si los datos acelerados estn o no permitidos. Estos se
pasan a la conexin de transporte sin que se les haga modificacin alguna. Otros, estn especficamente
relacionados con la capa de sesin. Por ejemplo, si se est llevando a cabo el establecimiento de una sesin
entre dos ordenadores, con el propsito de intercambiar correo electrnico en ambas direcciones, uno de los
parmetros de sesin podra especificar qu lado enviar primero.
No obstante, y a pesar de estas similitudes, existen importantes diferencias entre una sesin y una
conexin de transporte. La principal entre stas es la forma como se liberan las sesiones y las conexiones de
transporte. Las conexiones de transporte se terminan con la primitiva T-DISCONNECT.request, que produce
una liberacin abrupta y puede traer como resultado la prdida de los datos en trfico que haya en el momento
de la liberacin. Las sesiones se terminan con la primitiva S-RELEASE.request, que resulta en una liberacin
ordenada (a la cual tambin se le conoce como liberacin garbosa) en la cual los datos jams se llegan a
perder. Una liberacin abrupta, como T-DISCONNECT.request, tambin se encuentra disponible bajo la
forma de S-U-ABORT.request.
En la figura 7-3 se muestra la diferencia entre una liberacin ordenada y otra abrupta. En la
liberacin abrupta, inmediatamente despus de que cualquiera de los usuarios haya invocado la primitiva
apropiada para llevar a cabo la desconexin, no se le podrn entregar ms datos. En la figura 7-3a, una vez
que B haya invocado un T-DISCONNECT.request, su extremo de la conexin se libera inmediatamente. En
un momento dado, podra no recibir el mensaje que est en trfico hacia l, an cuando dicho mensaje llegara
antes de que llegue a A la TPDU DR.
Adems, A no puede rechazar la solicitud para liberar la conexin. El proveedor del servicio de
transporte slo emite un T-DISCONNECT.indication, y nada ms. Es como en una conexin telefnica:
cuando uno de los interlocutores cuelga el auricular, la conexin termina, sin importar cul es el deseo del
otro interlocutor.

La liberacin ordenada trabaja de manera diferente. Esta utiliza una comunicacin con las primitivas
solicitud (request), indicacin (indication), respuesta (response) y confirmacin (confirm). En la figura 7-3b,
incluso despus de que B haya invocado una primitiva S-RELEASE.request, todava puede aceptar mensajes,
hasta que A haya confirmado la liberacin. Con slo emitir un S-RELEASE.request no se termina la sesin
por si misma. El usuario remoto debe estar de acuerdo; si este usuario quiere continuar la sesin, puede
rechazar el intento de liberacin (dicindolo en un parmetro en la primitiva S-RELEASE.response), y la
sesin contina como si nada hubiera sucedido. Una sesin solamente se puede terminar cuando ambos
interlocutores estn satisfechos.
Si ustedes piensan que es extrao que la liberacin ordenada est presente en la capa de sesin, pero
no en la capa de transporte, les aseguro que no son los nicos que piensan as. Cuando, para el gobierno de
Estados Unidos, se estaba haciendo el anteproyecto de la norma correspondiente a la capa de transporte, la
Oficina Nacional de Normas (NBS) tambin not esta falta y decidi aadir a la capa de transporte una
opcin de liberacin ordenada, resolviendo as el problema y, simultneamente, haciendo que la norma de los
Estados Unidos fuera diferente de aqulla usada en el resto del mundo. En el mundo de las normas, con
frecuencia se tiene que decidir entre la alternativa de hacerlo correctamente o hacerlo de la misma manera que
todos los dems lo hacen. Esta es la razn por la cual hay tantas normas.
El direccionamiento es otra de las reas en las que hay diferencia entre las capas de sesin y
transporte, aunque slo levemente. Para establecer una sesin, uno debe especificar la direccin SSAP a la
cual se va a conectar (en lugar de la direccin TSAP). Aunque las normas no indican la forma cmo las
direcciones SSAP deben ser construidas, es muy probable que en la prctica la direccin de un SSAP constar
de una direccin TSAP, ms alguna informacin adicional de identificacin.
Otro de los motivos por los cuales el intercambio de datos de sesin difiere del intercambio de datos
de transporte, es en la cantidad de diferentes tipos de datos. La capa de transporte tiene dos flujos de datos que
son lgicamente independientes; es decir, los datos normales y los datos acelerados. La capa de sesin tiene
ambos tipos y, adems, otros dos (los datos tipados y los de capacidad). Los otros dos flujos se relacionan con
caractersticas de la capa de sesin que todava no hemos mencionado, por lo que se diferir su discusin
hasta que se vean posteriormente en este capitulo.
Administracin del dilogo
En principio, todas las conexiones del modelo OSI son dplex, es decir, las PDU se pueden mover en
ambas direcciones simultneamente sobre la misma conexin. En la figura 7-4a se muestra la comunicacin
dplex. Sin embargo, hay varias situaciones en las que el software de capas superiores est estructurado de tal
forma que espera que los usuarios tomen turnos (en este caso se tendr una comunicacin semiduplex). Este
diseo no tiene nada que ver con las limitaciones que presentan algunas terminales antiguos que todava

existen y que no pueden trabajar en el modo dplex, sino con el diseo apropiado del software de capas
superiores.

Como un ejemplo, considrese un sistema de administracin de base de datos que pueden acceder
desde terminales remotos (por ejemplo, para reservas en fincas areas o realizacin en casa de trmites
bancarios). El modo de operacin ms natural para el usuario es el de enviar una solicitud al sistema de base
de datos, y despus esperar la respuesta. El hecho de permitir que los usuarios enven una segunda o tercera
solicitud antes de Que la primera haya sido contestada, trae como consecuencia una complicacin innecesaria
del sistema. Lgicamente resulta deseable que el sistema funcione en modo dplex: o bien que le toque cl
turno de transmitir al usuario o al sistema de base de datos. El hecho de mantener un seguimiento de a quin
le corresponde el turno de hablar (y hacerlo cumplir), se denomina como administracin del dilogo, y es uno
de los servicios que puede ofrecer la capa de sesin en el momento que se le solicite.
La realizacin de la administracin del dilogo se hace mediante el empleo de un testigo de datos. En
el momento en que se establece una sesin, el funcionamiento dplex es una de las opciones elegibles. Si se
selecciona el funcionamiento semiduplex, la negociacin inicial tambin determina qu extremo poseer
primeramente el testigo. Solamente el usuario que tiene el testigo puede transmitir datos, el otro deber
permanecer en silencio. Una vez que el extremo que posee el testigo haya terminado de hacer su transmisin,
se la pasar a su corresponsal por medio de la primitiva S-TOKEN-GIVE.request, como se muestra en la
figura 7-4b. Qu pasa si el usuario que no tiene el testigo desea hacer una transmisin de datos? Puede
solicitar cortsmente el testigo mediante la primitiva S-TOKEN-PLEASE.request. El poseedor del testigo
puede estar de acuerdo y pasarlo o, tambin, puede rechazar la solicitud, en cuyo caso el otro usuario simple y
sencillamente tendr que esperar (o enviar un mensaje de urgencia con el uso de datos acelerados, que no
requieren de testigo). Si se selecciona la operacin dplex cuando se establece la sesin, no se utilizar ningn
testigo para la transmisin de datos.
Sincronizacin
Otro servicio de la capa de sesin es la sincronizacin, la cual se utiliza para llevar las entidades de
sesin de vuelta a un estado conocido, en caso de que haya un error o algn desacuerdo. A primera vista, este
servicio parecerla innecesario porque la capa de transporte se ha diseado cuidadosamente para que se pueda
recuperar, en forma transparente, de todos los errores de comunicacin, as como de fallos de las subredes.
Sin embargo, un estudio ms detallado demuestra que la capa de transporte se ha diseado para enmascarar
solamente los errores de comunicacin. Esta no se puede recuperar de los errores cometidos en la capa
superior.

Como un ejemplo de los problemas que se pueden presentar, considrese el servicio de teletex que
paulatinamente est reemplazando al telex (TWX), en el proceso de transmisin de mensajes impresos de una
compaa a otra. Los subscriptores a este tipo de servicio utilizan un dispositivo que contiene una CPU
(Unidad de procesamiento central), un teclado, una pantalla, una impresora, un mdem, un telfono y, en
algunas ocasiones, un disco. Inicialmente, el usuario se encarga de componer un mensaje usando el CRT
(tubo de rayos catdicos) y el teclado. Despus, la CPU llama a la compaa a la que se desea entregar el
mensaje, establece una sesin y transfiere el mensaje. Si el dispositivo receptor no tiene una unidad de disco
para almacenamiento, lo que viene a ser una posibilidad real en las versiones ms econmicas, los mensajes
que llegan debern imprimirse en tiempo real, a medida que se reciben.
Tan pronto como se recibe cada una de las SPDU, se asiente y el texto se pasa a la unidad impresora
para que se imprima. Ahora, supngase que se presenta un problema con la cinta o el papel de la impresora;
aun cuando el operador se de cuenta rpidamente del problema, y llegue a oprimir el botn del dispositivo par
detener el proceso de impresin, una parte de la informacin puede perderse. Dado que el mensaje ya se haba
asentido, el emisor ya no tendr copia del mismo y, por consiguiente, la transmisin del mensaje fallar. La
capa de transporte no puede hacer absolutamente nada al respecto; despus de todo, realiz su trabajo a la
perfeccin: es decir, se encarg de mover todos los bits de manera segura desde el emisor hasta el receptor.
Solamente despus de entregar la SPDU a la capa de sesin, devolvi un asentimiento. La capa de transporte
no tiene la culpa de que las capas superiores hayan perdido el baln.
La solucin recae en la capa de sesin. Los usuarios de sesin pueden dividir el texto en pginas, e
insertar un punto de sincronizacin entre cada una de ellas, como se muestra en la figura 7-5. En caso de
presentarse un problema, es posible restablecer el estado de la sesin a un punto previo de sincronizacin,
para desde ah continuar. Por supuesto, para hacer posible este proceso, llamado resincronizacin, el usuario
de sesin emisor (no la entidad de sesin), deber continuar reteniendo los datos durante el tiempo que sea
necesario.

Es importante entender cul es la semntica de la sincronizacin en la capa de sesin. Los usuarios

de sesin pueden insertar puntos de sincronizacin en el flujo del mensaje. Cada uno de estos puntos lleva un
nmero de sede. Cuando un usuario invoca una primitiva para solicitar un punto de sincronizacin, el otro
obtiene una indicacin. De la misma manera, si uno de ellos invoca una primitiva para resincronizacin, el
otro tambin obtiene una indicacin de esto. El almacenamiento de los mensajes y la subsiguiente
retransmisin posterior se lleva a cabo arriba de la capa de sesin; lo que la capa de sesin proporciona es una
forma de transportar seales de sincronizacin y resincronizacin numeradas a travs de la red.
Este mecanismo es ligeramente ms elaborado de lo que hemos esbozado hasta ahora. Existen dos
tipos diferentes de puntos de sincronizacin, el mayor y el menor, cada uno de ellos con sus propias
primitivas. Las unidades delimitadas por los puntos de sincronizacin mayores se llaman unidades de dilogo,
y generalmente representan panes de trabajo lgicamente significativas. Cuando se lleva a cabo la transmisin
de un libro, por ejemplo, los captulos podran estar delimitados por puntos de sincronizacin mayores, en
tanto que las pginas por puntos de sincronizacin menores. En la figura 7-6 se muestra tina sesin con tres
puntos de sincronizacin mayores y cuatro puntos de sincronizacin menores.
Los puntos de sincronizacin mayores y menores son diferentes en varios aspectos. Por la siguiente
razn, en el momento en que se realiza una resincronizacin, es posible volver slo hasta el punto de
sincronizacin mayor ms reciente, y no ms all. An, en el intervalo de tiempo entre los puntos de
sincronizacin 6 y 7 de la figura 7-6, se permite resincronizar regresando a 6, pero no a 1, 2, 3, 4 o 5. Al

levantar un muro de ladrillos en cada uno de los puntos de sincronizacin mayores, el emisor sabe que los
datos que fueron enviados antes del muro, pueden ser descartados con toda confianza. Los puntos de
sincronizacin menores no tienen esta propiedad. Justo antes del punto de sincronizacin 6 de la figura 7-6, se
permite resincronizar a 1, 2, 3, 4 o 5. La seleccin de qu tipo de punto de sincronizacin utilizar, y dnde
usarlo, depende naturalmente de los usuarios de sesin. Los puntos de sincronizacin mayores son tan
importantes, que cada uno que se inserte en el flujo de datos se debe confirmar explcitamente (es decir, se
asiente).

Los puntos de sincronizacin menores no son confirmados. En un canal de satlite, en donde el

mnimo tiempo para transmitir un mensaje y obtener su asentimiento es de 540 mseg, esta diferencia puede
llegar a ser significativa.
Para establecer un punto de sincronizacin, ya sea mayor o menor, se requiere que se posean los
testigos relevantes. Hay disponibles dos testigos independientes (para sincronizacin mayor y menor). Estos
son diferentes entre el, y tambin con respecto al testigo utilizado para controlar el flujo en las conexiones
semiduplex. Cuando se lleva a cabo la resincronizacin, todos los testigos se restauran a las posiciones que
tenan en el instante en el que se estableci el punto de sincronizacin.
Administracin de actividades
Otra de las caractersticas clave de la capa de sesin, estrechamente relacionada con la
sincronizacin, es la administracin de actividades. La idea tras la administracin de actividades es la de
permitir que el usuario divida el flujo de mensajes en unidades lgicas denominadas actividades. Cada
actividad es completamente independiente de cualquiera de las dems que pudieron haber venido antes o que
vendrn despus de ella.
Depende del usuario el determinar qu es una actividad. Como un primer ejemplo, considrese una
sesin que se haya establecido con el propsito de transferir varios archivos entre dos ordenadores. Se
necesita alguna forma para marcar el lugar en donde termina un archivo y comienza el siguiente. El empleo
del carcter ASCII FS (Separador de Archivos) no es la mejor idea, porque si los archivos contienen
informacin binaria, estos caracteres podran aparecer en los datos y sealar accidentalmente cl final de un
archivo, cuando no se trataba de esto. El empleo de algn tipo de insercin de carcter, como se hizo en la
capa de enlace, es una posibilidad, pero en la capa de sesin la insercin tendr que hacerse probablemente en
software y no en hardware, por lo que el procedimiento ser lento.
Lo que realmente se necesita es alguna manera de insertar un marcador en el flujo de mensajes, que
sea en s mismo diferente de un mensaje de datos (a esto algunas veces se le llama informacin fuera de
banda). Una manera de alcanzar este objetivo consiste en definir cada transferencia de un archivo como una
actividad separada, como se ilustra en la figura 7-7. En esta figura, el emisor emite una primitiva SACTIVITY-START.request, antes de que se inicie la transferencia de cada archivo. Esta primitiva llega al
otro extremo como un S-ACTIVITY-START.indicutan para marcar el inicio del archivo. Similarmente,
despus de que se completa la transferencia de cada archivo, la primitiva S-ACTIVITY-END se puede utilizar
para marcar el fin del archivo.
Es importante enfatizar aqu que la eleccin de lo que constituye una actividad la llevan a cabo los
usuarios, y no la capa de sesin. Lo nico que hace la capa de sesin es asegurar que cuando un usuario haga
una solicitud S-ACTIVITY, el otro usuario obtenga la indicacin correspondiente. Cundoo se hagan stas

solicitudes como reaccione el receptor a las indicaciones, no son cuestiones de inters para la capa de sesin.
La capa de sesin solamente est interesada en la ejecucin de las primitivas, pero no sobre su significado
(semntica) o uso. Es conveniente mencionar que una actividad cubre todo el trfico enviado en ambas
direcciones.

Como un segundo ejemplo sobre la manera en que la administracin de actividades puede utilizarse,
considrese un sistema bancario domstico en el cual la gente puede pagar sus facturas usando sus
ordenadores personales para transferir dinero de sus cuentas a aquellas de las compaas que emitieron las
facturas. El programa que se ejecuta en el ordenador personal podra comenzar preguntando por el nmero de
la cuenta a la que se va a cargar la factura y transmitir esta informacin al banco en su primer mensaje.
Despus, podra preguntar sucesivamente por el nmero de la cuenta a la que se va a abonar, as como la
cantidad, y enviar estos datos como los mensajes dos y tres.
|
Cuando el primer mensaje llega al ordenador del banco, el registro del disco que contiene la cuenta a
la que se va a cargar se localiza y se bloquea para impedir cualquier acceso concurrente. Cuando llega el
segundo mensaje, el registro de la cuenta a la que se va a abonar tambin se bloquea. Cuando llega el tercer
mensaje, se hace la transferencia de dinero y las dos cuentas se desbloquean. Imagnese qu es lo que pasara
si un fallo de energa elctrica suspendiera temporalmente el suministro de sta a la casa del usuario, justo
despus de haberse enviado el primer mensaje, recibido en el banco y procesado. La transaccin nunca se
completada y la cuenta bloqueada permanecerla as para siempre. Para evitar una situacin como sta, la
transaccin bancaria podra estructurarse como una actividad en la capa de sesin. Es decir, despus de
recibirla primitiva S-ACTIVITY-START.indication, el ordenador del banco simplemente podra acumular los
mensajes que llegaran, hasta que se presentara una primitiva S-ACTIVITY-END.indication, sealando que ya
no existen ms. Slo entonces, empezada el procesamiento de los mensajes y el bloqueo de las cuentas. De
esta manera, no habra fallos externos que provocaran que el ordenador del banco se quedara atorado a la
mitad de una transaccin.
La tcnica de acumular mensajes en un tampn de entrada hasta que todos ellos hayan llegado, antes
de empezar a procesarlos, se llama poner en cuarentena. En los primeros proyectos de la capa de sesin, la
cuarentena era un servicio de sesin explcito. Sin embargo, posteriormente, el comit de la ISO comprendi
que la cuarentena poda tambin obtenerse mediante la administracin de actividades, por lo que el servicio de
cuarentena no fue incluido en la norma que se public.
El tercero y ltimo ejemplo sobre la administracin de actividades toma en cuenta una propiedad que
todava no se ha mencionado: las actividades pueden interrumpirse (es decir, quedar suspendidas) y
posteriormente reiniciarse sin que llegue a haber prdida de informacin. Considrese el caso de alguien que
haya iniciado el proceso de cargar un archivo muy grande, de su ordenador ubicado en su oficina de trabajo
hacia su ordenador personal localizado en su casa. Ahora supngase que a la mitad del proceso de
transferencia, el usuario se ve en la necesidad de realizar una llamada telefnica urgente y necesita buscar el
nmero telefnico en su directorio telefnico en lnea que tiene en la oficina, preferiblemente sin destruir la
transferencia del archivo.
La solucin a este problema se da en la figura 7-8. La transferencia del archivo se inicia como una
actividad. En un momento del proceso de transferencia es posible emitir una primitiva S-ACTIVITY-

INTERRUPT.request, para suspender la transferencia del archivo. Entonces, se puede iniciar y completar otra
actividad, y finalmente la actividad original puede reiniciarse desde el punto en el que se interrumpi.

La administracin de actividades es la manera fundamental de estructurar una sesin. Por esta razn,
es primordial que las dos partes acuerden cul deber ser la estructura de la actividad. En un momento dado
podra surgir un problema, si las dos partes tratasen de iniciar actividades en forma simultnea. Con objeto de
impedir que ocurra este hecho, la administracin de actividades se controla mediante un testigo (de hecho el
mismo testigo utilizado para los puntos de sincronizacin mayores). Para invocar un servicio de actividad, un
usuario debe poseer el testigo de actividad; el cual puede pasarse y solicitarse independientemente de los
testigos de datos y de sincronizacin menor.
De hecho, la situacin es ms complicada de lo que hasta ahora se ha mencionado. Se inici tal y
como se ha descrito, pero posteriormente la ISO comprendi que podra ocurrir un problema en el momento
en que un usuario iniciara una actividad, mientras que el otro estuviera haciendo una sincronizacin menor.
Para evitar esta situacin, se cambiaron las reglas para exigir que un usuario tuviera los testigos de actividad y
de sincronizacin menor, as como el testigo de datos (si se utiliza) antes de iniciar una actividad o una
operacin de sincronizacin. Con esta estrategia se eliminaron los problemas originales, pero se cre uno
nuevo: Qu pasa si uno de los usuarios mantiene el testigo de actividad, el otro mantiene el testigo de
sincronizacin menor, y los dos usuarios desean tener los dos testigos? Cada uno se queda en un lazo,
emitiendo primitivas S-TOKEN-PLEASE, sin resultados. Se tendra como resultado un bloqueo. La nica
solucin para todas las aplicaciones es que traten de ser sumamente cuidadosas. En retrospectiva, un solo
testigo podra haber sido mucho mejor.
Las actividades estn estrechamente relacionadas con los puntos de sincronizacin. Cuando se inicia
una actividad, los nmeros de serie de los puntos de sincronizacin vuelven a 1 y se inserta un punto de
sincronizacin mayor. Dentro de una actividad es posible establecer puntos de sincronizacin adicionales,
tanto mayores como menores, como se ilustra en la figura 7-9.
Dado que el inicio de una actividad tambin corresponde a un punto de sincronizacin mayor, una
vez que se inicia una actividad, ya no es posible resincronizar a un punto anterior a aqul correspondiente al
inicio de dicha actividad. En particular, no es posible resincronizar a un punto de sincronizacin de una
actividad previa.
Notificacin de excepciones
|
Otra caracterstica de la capa de sesin es la correspondiente a un mecanismo de propsito general
para notificar errores inesperados. Si un usuario tiene algn problema, por cualquier razn, este problema se
puede notificar a su corresponsal utilizando la primitiva S-U-EXCEPTION-REPORT.request. Algunos datos
del usuario se pueden transferir utilizando esta primitiva. Los datos del usuario, generalmente, explicarn qu
es lo que sucedi.

Como un ejemplo, supngase que un programador disea un protocolo para la capa 7, complejo y de
propsito especial, para una aplicacin especifica. Durante depuracin del protocolo (o incluso despus de
que supuestamente se depur), se pueden presentar errores de protocolo; los cuales se pueden notificar al
corresponsal correspondiente utilizando el mecanismo de notificacin de excepciones de la capa de sesin.
La notificacin de excepciones no solamente se aplica a los errores detectados del usuario. El
proveedor del servicio puede generar una primitiva S-P-EXCEPTION-REPORT.indication para informarle al
usuario sobre los problemas internos que existen dentro de la capa de sesin, o sobre problemas que le
reporten procedentes de las capas de transporte o inferiores. Estas notificaciones contienen un campo que
describe la naturaleza de la excepcin. La decisin sobre qu accin tomar, si hay alguna, depender del
usuario.
Primitivas del servicio de sesin OSI
En esta seccin se estudiarn sistemticamente todas las primitivas de sesin OSI y, tambin, se
describir la funcin de cada una de ellas. En la figura 7-10 se encuentra una lista de todas ellas. Como se
puede observar, cada lnea de la tabla corresponde a un nmero de primitivas que oscila entre 1 y 4.
Potencialmente, cada tipo de primitiva tiene versiones de request, indication, response y confirm. Sin
embargo, no todas las combinaciones son vlidas; el S-DATA, por ejemplo, slo tiene request e indication.
Los asentimientos (es decir, response y confirm) estn a cargo de las capas inferiores.
Aunque hay 58 primitivas de servicio de sesin orientadas a conexin, se pueden entender mejor si
se dividen en siete grupos:
1. Establecimiento de conexin.
2. Liberacin de conexin.
3. Transferencia de datos.
4. Administracin de testigos.
5. Sincronizacin.
6. Administracin de actividades.
7. Notificacin de excepciones.
El primer grupo contiene cuatro primitivas de la forma S-CONNECT.xxx. La primitiva SCONNECT.request especifica un identificador de sesin, las direcciones SSAP del que llama y del llamado,

la calidad de servicio, el nmero-inicial de los puntos de sincronizacin, la asignacin inicial de los testigos,
algunos datos del usuario (que es opcional) y, posiblemente, varias opciones.

Las opciones se proporcionan porque no todas las sesiones necesitan de todos los servicios que
potencialmente se tienen disponibles. La sincronizacin, la administracin de actividades, la notificacin de
excepciones, as como ciertas clases de transferencia de datos, que se estudiarn enseguida, pueden habilitarse
o deshabilitarse individualmente para cada sesin, dependiendo de las necesidades de los usuarios.
El segundo grupo contiene siete primitivas relacionadas con la liberacin de sesiones; la primitiva SRELEASE.request, por ejemplo, se utiliza para solicitar la terminacin ordenada de la sesin. Una alternativa
a esta liberacin ordinaria es una liberacin negociada, en la que se utiliza un testigo de liberacin. Cuando se
selecciona esta opcin al momento del establecimiento de la sesin, solamente el usuario que posee este
testigo puede iniciar la liberacin. Algunas veces, este servicio es til cuando los dos extremos terminales de
una sesin no son iguales, sino que guardan una relacin maestro esclavo.

Tambin, se proporcionan dos formas de liberacin abrupta; una de ellas es iniciada por el usuario,
mientras que la otra es iniciada por el proveedor. Esta ltima solamente se lleva a cabo si la entidad de sesin
detecta la existencia de algn error fatal.
El tercer grupo se ocupa de la transferencia de datos. Como se mencion brevemente antes, hay
cuatro flujos de datos independientes; siendo stos los siguientes:
1. Datos regulares.
2. Datos acelerados.
3. Datos tipados.
4. Datos de capacidad.
Los dos tipos primeros de flujos de datos ya se han estudiado con cierta profundidad, por lo que
ahora se vern los otros dos tipos restantes. Los datos tipados son datos normales, con la excepcin de que
siempre pueden enviarse sin que importe la propiedad de cualquier testigo. A diferencia de la llegada de datos
normales, que est sealada por una primitiva S-DATA.indication, la llegada de datos tipados est sealada
por una primitiva S-TYPED-DA TA.indication, pata que el receptor pueda ordenarlos en forma separada. Los
datos tipados pueden ser utilizados por el usuario del servicio de sesin para mensajes de control, o bien, para
cualquier otro propsito que desee.
Las normas de la capa de sesin no especifican la forma cmo se van a utilizar los datos tipados. La
intencin que tuvo el comit de la ISO fue, sin embargo, la de proporcionar un flujo de datos fuera de banda
para la informacin de control de las capas superiores, para el mantenimiento de la red y para la
administracin del servicio. Por esta razn, los datos tipados pueden ser enviados en cualquier momento, sin
tomar en cuenta ningn riesgo. Anteriormente, vimos este concepto de un canal especial empleado para
informacin de control. En el protocolo X.25, hay un bit Q en la cabecera, para calificar los datos; hubiera
sido muy agradable silos datos tipados pudiesen haberse enviado mediante el empleo del bit Q.
Desafortunadamente, el servicio de la capa de transporte no tiene el concepto de datos tipados, por lo que no
hay forma alguna de que la entidad de sesin le pueda indicar a la capa de transporte que hay un mensaje que
contiene datos tipados.
El cuarto tipo de flujo de datos se llama datos de capacidad. Este, tambin, se destina a propsitos de
control, pero para el control de la misma capa de sesin. Su funcin real consiste en permitir cambios, en las
opciones de sesin y en los parmetros, durante la sesin (aunque, tericamente, se puede utilizar para
cualquier cosa que hayan acordado mutuamente los usuarios de la sesin). A diferencia de los datos tipados,
los datos de capacidad son asentidos totalmente; adems, y para evitar cualquier confusin, los datos de
capacidad solamente se pueden transmitir fuera de las (es decir, entre) actividades y, por consiguiente, slo
cuando se poseen los testigos de datos, de sincronizacin y de actividad.
El cuarto grupo de primitivas se ocupa de la administracin de los testigos. Como se muestra en la
figura 7-11, la capa de sesin tiene cuatro testigos. Utilizando la primitiva S-TOKEN-GIVE.request se pueden
pasar uno o ms testigos a la entidad corresponsal. Hay Parmetros Que especifican qu testigos debern
entregarse.
La primitiva S-TOKEN-PLEASE.request se puede utilizar para anunciar que el usuario que est emitiendo la
primitiva quiere los testigos especificados. Por ltimo, la primitiva S-CONTROL-GIVE.request puede
emplearse para renunciar a todos los testigos instantneamente. Slo se puede utilizar fuera de las actividades.
Lgicamente, esta primitiva no es necesaria, pero se incluy a solicitud del CCITT, para tener compatibilidad
con su protocolo de teletex, el cual trabaja en trminos de control y no en trminos de testigos.
Las primitivas de sincronizacin estn incluidas en el quinto grupo; las cuales se proporcionan tanto
para sincronizacin mayor como menor, as como para resincronizacin. Todas ellas, tambin, se confirman.
Cada primitiva especifica el nmero de serie del punto de sincronizacin que quiere insertar o al cual volver.
Estos nmeros de serie estn en el intervalo de 0 a 999.999. Todas las primitivas de sincronizacin requieren
la posesin de los testigos relevantes.
El sexto grupo de primitivas est relacionado con la administracin de actividades. Las actividades
pueden ser iniciadas, interrumpidas, reanudadas y desechadas (abandonadas). Al igual que la sincronizacin,
la administracin de actividades est controlada por testigos.

El sptimo y ltimo grupo contienen las primitivas de notificacin de excepciones. Ntese que la
primitiva S-P-EXCEPTION, al igual que S-P-ABORT, no se puede solicitar. El proveedor del servicio decide
s y cundo emitirla. La entidad de sesin realiza las primitivas del modelo OSI por medio del protocolo de
sesin, el cual se estudiar posteriormente en este capitulo.