Unidad II: Capas Superiores del Modelo OSI
2.2 Capa de sesión
A diferencia de lo que ocurre con los protocolos de aplicación del conjunto TCP/IP, que interactúan
directamente con los protocolos de la capa de transporte (UDP y TCP), en el modelo de referencia OSI lo hacen a
Unidad II: Capas Superiores del Modelo OSI
2.2 Capa de sesión
Como se aprecia en la siguiente figura, el nivel de aplicación consta de dos conjuntos de protocolos, cada uno de los
cuales es un elemento de servicio de aplicación (ASE:
Application Service Element). El ASE es la especificación de servicio y protocolo combinada de un protocolo. Un
conjunto realiza funciones de aplicación específicas en tanto que el otro efectúa funciones de soporte más generales
conocidas también como elementos de servicio de
aplicación comunes (CASE: Common Application Service Element). En el conjunto TCP/IP, las funcionalidades de los CASE y de las capas de presentación y de sesión están
Unidad II: Capas Superiores del Modelo OSI
2.2 Capa de sesión
El propósito principal de la capade sesión en la pila OSI es
minimizar los efectos de los fallos en la red durante una transacción de aplicación. En muchas aplicaciones, una
transacción puede ocupar un tiempo considerable y requerir la transferencia de una gran
Unidad II: Capas Superiores del Modelo OSI
2.2 Capa de sesión
Un ejemplo sería una base de datos que contuviera un
conjunto de cuentas de clientes o expedientes de empleados y que se transfiriera de un proceso de aplicación servidor a un proceso cliente. Si ocurre un fallo de la red al final de una transferencia como esta, quizá sea necesario repetir la
transferencia completa, o varias transferencias de este tipo.
La capa de sesión ofrece servicios para reducir el efecto de este tipo de fallos.
Unidad II: Capas Superiores del Modelo OSI
2.2 Capa de sesión
1. Establecer un camino de comunicación lógico (conexión de sesión) con otra entidad de aplicación, utilizarlo para intercambiar datos (unidades de diálogo) y liberar la
conexión de una forma ordenada.
2. Establecer puntos de sincronización durante un diálogo y, en caso de ocurrir errores, reanudar el diálogo a partir de un punto de sincronización convenido
3. Interrumpir (suspender) un diálogo y reanudarlo después en un punto convenido de antemano.
Unidad II: Capas Superiores del Modelo OSI
2.2.1 Intercambio de Datos
La característica mas importante de la capa de sesión es el intercambio de datos. Una sesión, al igual que una conexión de transporte, sigue un proceso de tres fases: la de
establecimiento, la de utilización y la de liberación. Las primitivas que se le proporcionan a la capa de presentación, para el establecimiento, utilización y liberación de sesiones, son muy parecidas a las
Unidad II: Capas Superiores del Modelo OSI
2.2.1 Intercambio de Datos
En muchos casos, todo lo que la entidad de sesión tiene que hacer, cuando primitiva es invocada por el usuario de sesión, es invocar la primitiva de transporte correspondiente para que se pueda así realizar el trabajo. En cualquier caso , y a pesar de estas similitudes, existen importantes diferencias entre el intercambio de datos de sesión y el intercambio de datos de transporte. La mas importante de estas diferencias es la forma de liberar las sesiones y las conexiones de
Unidad II: Capas Superiores del Modelo OSI
2.2.1 Intercambio de Datos
Otro de los motivos porque el intercambio de datos de
sesión difiere del de transporte, es en la cantidad diferente de datos. La capa de transporte tiene dos flujos de datos que son lógicamente independientes, es decir, los datos
Unidad II: Capas Superiores del Modelo OSI
2.2.2 Administración del Dialogo
La administración del dialogo será uno e los servicio de la
capa de sesión y consistirá en mantener un seguimiento de a quien le corresponde el turno de hablar y de hacerlo
cumplir. En el momento en el que se inicia una sesión se seleccionara el modo de funcionamiento y ya sea dúplex o semidúplex, la negociación inicial determina quien tendrá primeramente el testigo de datos porque solo el usuario que posee el testigo podrás transmitir mientras el otro se
Unidad II: Capas Superiores del Modelo OSI
2.2.3 Sincronización
Se utiliza para llevar las entidades de sesión de vuelta a un estado conocido, en caso de que haya un error o algún
desacuerdo. A primera vista, este servicio parecería
Unidad II: Capas Superiores del Modelo OSI
2.2.3 Sincronización
La solución recae sobre la capa de sesión. Los usuarios de sesión pueden dividir el texto en paginas, e insertar un
punto de sincronización entre cada una de ellas. En caso de presentarse un problema, es posible restablecer el estado de la sesión a un punto previo de sincronización, para desde ahí continuar. Por supuesto, para hacer posible este proceso,
llamado resincronización, el usuario de sesión emisor
Unidad II: Capas Superiores del Modelo OSI
2.2.3 Sincronización
Existen dos tipos diferentes de puntos de sincronización, el mayor y el menor, cada uno de ellos con sus propias
Unidad II: Capas Superiores del Modelo OSI
2.2.3 Sincronización
Administración de Actividades
La idea tras la administración de actividades es la de permitir que el usuario divida el flujo de mensajes en
unidades lógicas denominadas actividades. Cada actividad es completamente independiente de cualquiera de las
demás que pudieron haber venido antes o que vendrán
después de ella. Es importante indicar que la elección de lo que constituye una actividad la llevan a cabo los usuarios, y no la capa de sesión. Lo único que hace la capa de sesión es asegurar que cuando un usuario haga una solicitud
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Otra característica de la capa de sesión es lacorrespondiente a un mecanismo de propósito general para notificar errores inesperados. Si un usuario tiene algún
problema, por cualquier razón, este problema se puede notificar a su corresponsal utilizando la primitiva
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La notificación 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 sesión, 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 excepción. La
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Especificación del protocolo
El protocolo de la capa de sesión se especifica en términos de una maquina de protocolo de sesión abstracta (MAS) que se considera dentro de la capa de sesión. Dicha maquina
abstracta se comunica con el usuario a través de un
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Especificación del protocolo
El protocolo de sesión establece las reglas para el intercambio de datos e información de control entre entidades de sesión pares utilizando una conexión de transporte.
- Si llega a la maquina de protocolo de sesión una unidad de datos del protocolo de sesión(SPDU), entregada por el
proveedor(capa de transporte), se generara una indicación o confirmación de servicio al usuario(primitivas indication o confirm). - Si se recibe del usuario un requerimiento o
respuesta (primitivas request o response), se envía una SPDU desde una entidad de sesión a otra y/o se genera un
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Especificación del protocolo (Cont..)
Una SPDU generada por la maquina de protocolo de sesión puede contener parámetros que toman valores
dependiendo del servicio solicitado por el usuario y/o de la información mantenida en la maquina de protocolo de
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Manejo del diálogo
Por defecto todas las conexiones son full-duplex (PDUs en ambos sentidos a la vez).
Existe hardware y aplicaciones únicamente half-duplex, por lo que a nivel de sesión necesitamos controlar qué extremo puede transmitir en cada momento.
El manejo de diálogo se consigue usando un token de datos. Al iniciar la conexión se negocia half-duplex y se identifica quién tendrá el token al principio.
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La sincronización
La sincronización se utiliza para regresar a un estado anterior conocido en caso de error durante la sesión. Aunque parezca innecesario (la capa de transporte sólo
recupera errores de comunicación) ocurren muchos errores a nivel de sesiones entre usuarios (capas superiores).
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La sincronización (Cont..)
Los usuarios pueden insertar puntos de sincronización (PdS) durante una sesión. Cada PdS lleva un número
identificativo. Cuando un extremo pide un PdS el otro
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La sincronización (Cont..)
En ningún caso se recupera el error a nivel de sesión. A este nivel se dan las primitivas para poder resincronizar pero
ésta se debe llevar a cabo en niveles superiores. Existen dos tipos de puntos de sincronización. Cada tipo de punto tiene su conjunto de primitivas asociadas.
Dos puntos de sincronización mayor delimitan una UNIDAD DE DIÁLOGO.
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La sincronización (Cont..)
•Sólo se puede resincronizar al PdS más cercano.
•Si entre dos PdS mayores no hay menores sólo se puede
resincronizar al anterior PdS mayor.
•Si hay dos PdS mayores y entre ellos varios menores sí puede
resincronizarse a cualquiera de ellos.
•Los PdS mayores se confirman, mientras que los menores no. •Poner cualquier PdS requiere poseer el token asociado al tipo
de punto deseado.
•Estos dos son distintos entre sí y distintos del token de datos. •Cuando se resincroniza se restauran los token a la situación
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Manejo de Actividades
Otra característica de la capa de sesión, relacionada con la sincronización, es el manejo de actividades. La idea es
permitir al usuario dividir el mensaje en unidades lógicas llamadas Actividades. Cada actividad es completamente
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Manejo de Actividades (Cont..)
La elección de qué constituye una actividad es hecha por los usuarios, no por la capa de sesión. La capa de sesión se
encarga de que cuando un usuario haga una petición de S-ACTIVITY el otro obtenga la correspondiente indicación.
Para evitar situaciones de bloqueo de recursos y problemas por caída del host local cualquier transacción debe
estructurarse como una actividad de la capa de sesión. Después de recibir la S-ACTIVITY-START.indication, el host remoto sólo acumula mensajes entrantes hasta que
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Manejo de Actividades (Cont..)
Las actividades, o se completan en su totalidad, o no se
completan en absoluto. De esta forma, ningún fallo externo dejaría al host remoto a medias en una transacción
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Informe de excepciones
Otra característica de la capa de sesión es un mecanismo para informe de errores inesperados.
Si un usuario tiene un problema, éste problema puede ser informado al otro usuario usando la primitiva
S-U-EXCEPTION-REPORT.request. Se pueden transferir datos usando esta primitiva. Los datos explicarán lo que ha
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Informe de excepciones
El informe de excepciones no sólo se aplica a los errores detectados por el usuario.
El proveedor del servicio puede generar un S-P-EXCEPTION-REPORT.indication para notificar al usuario sobre problemas internos a la capa de sesión o problemas informados desde la capa de transporte o las capas más bajas. Estos informes contienen un campo que describen la naturaleza de la
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
Primitivas del servicio en OSI
Cada tipo de primitiva puede tener request, indication,
response y confirm. Hay 58 primitivas que pueden dividirse
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La capa de Sesión en varias Redes Capa de Sesión en ARPANET
ARPANET no tiene una capa de sesión o algo que se le parezca; sino mas bien depende de las aplicaciones
individuales al manejo de sus sesiones, siempre que sea necesario. Por otro lado, se ha trabajado mucho sobre RPC (Remote Procedure Call) (caso especial de comunicación asíncrona, el emisor envía una petición de servicio al
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La capa de Sesión en varias Redes (Cont..) Capa de Sesión en MAP y TOP
MAP y TOP utilizan una forma restringida de la capa de sesión del modelo OSI. El establecimiento de sesión, la transferencia de datos y la liberación de sesión están
totalmente soportados para el modo dúplex; mientras que el modo semidúplex no está soportado. El servicio de
sincronización, la administración de actividades, la
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La capa de Sesión en varias Redes (Cont..) Capa de Sesión en MAP y TOP (Cont..)
Este subconjunto corresponde a grandes rasgos al
desaparecido subconjunto básico sincronizado, con la omisión del modo semidúplex y datos tecleados. Los
Unidad II: Capas Superiores del Modelo OSI
2.2.4 Notificación de excepciones
La capa de Sesión en varias Redes (Cont..) Capa de Sesión en USENET
Al igual que en ARPANET, USENET no cuenta con una capa de sesión. A diferencia de ARPANET, no es ni siquiera
posible, para las capas superiores, realizar por sí mismas los servicios de sesión. Ninguno de los servicios de sesión se
Unidad II: Capas Superiores del Modelo OSI
2.2.5 Llamada a procedimientos remotos
Llamada de procedimiento remoto (RPC)
En lugar de definir el protocolo NFS de cero, los diseñadores prefirieron construir tres piezas independientes. El protocolo NFS es en si, un mecanismo general de llamada de
procedimiento remoto (remote procedure call o RPC por sus siglas en inglés) y una representación de datos externa
(eXternal data representation o XDR) de propósito general. Su intención era separar los tres de manera que pudieran
Unidad II: Capas Superiores del Modelo OSI
2.2.5 Llamada a procedimientos remotos
Llamada de procedimiento remoto (RPC) (Cont..)
Desde el punto de vista del programador, el NFS en sí mismo no proporciona nuevos procedimientos que un programa
pueda llamar. En cambio, una vez que un administrador ha configurado al NFS, los programas acceden a los archivos
remotos valiéndose exactamente de las mismas operaciones que se emplean para los archivos locales. Sin embargo, la
RPC y la XDR proporcionan mecanismos que los
Unidad II: Capas Superiores del Modelo OSI
2.2.5 Llamada a procedimientos remotos
Llamada de procedimiento remoto (RPC) (Cont..)
En el lado cliente, el programador designa como remotos algunos procedimientos, forzando así al compilador a
incorporar el código RPC en dichos procedimientos. En el lado del servidor, el programador implanta los
procedimientos deseados y utiliza otras características de RPC para declararlos como parte de un servidor. Cuando el programa de cliente que se está ejecutando llama a uno de los procedimientos remotos, la RPC recolecta
automáticamente los valores para los argumentos, forma un mensaje, envía el mensaje al servidor remoto, espera una respuesta y almacena los valores devueltos en los
Unidad II: Capas Superiores del Modelo OSI
2.2.5 Llamada a procedimientos remotos
Llamada de procedimiento remoto (RPC) (Cont..)
En esencia, la comunicación con el servidor remoto ocurre de manera automática como efecto colateral de una llamada de procedimiento remoto. El mecanismo RPC oculta todos los detalles de los protocolos, haciendo posible que los
programadores que saben un poco acerca de los protocolos de comunicación subyacentes escriban programas
distribuidos.
XDR, que es una herramienta relacionada, brinda a los programadores una manera de transmitir datos entre
Unidad II: Capas Superiores del Modelo OSI
2.2.5 Llamada a procedimientos remotos
Llamada de procedimiento remoto (RPC) (Cont..)
La ventaja principal de XDR es que automatiza buena parte de la tarea de conversión de datos. Los programadores no
necesitan teclear manualmente las llamadas de
procedimiento XDR. De hecho, se proporciona el compilador XDR con los enunciados de declaración del programa para el que deben transformarse los datos, y el compilador genera
