MODELO OSI – CAPA DE SESIÓN

INTEGRANTE
Ocaña diestra roger
Pablo
Obregón
Montalvo
CAPA DE SESIÓN

El nivel de sesión o capa de sesión es el

quinto nivel del modelo OSI que
proporciona los mecanismos para controlar
el diálogo entre las aplicaciones de los
sistemas finales. En muchos casos, los
servicios de la capa de sesión son
parcialmente, o incluso, totalmente
prescindibles. No obstante en algunas
aplicaciones su utilización es ineludible
SERVICIOS DE LA CAPA DE
SESIÓN

Entre los servicios ofrecidos tenemos.

– INTERCAMBIO DE DATOS
– ADMINSTRACION DE DIALOGO
– SINCRONIZACION
– ADMINISTRACION DE ACTIVIDADES
– NOTIFICACION DE EXCEPCIONES
INTERCAMBIO DE DATOS

Lacaracterística más importante de la capa

de sesión es el Intercambio de datos. Una
sesión sigue un proceso de tres fases:

1. ESTABLECIMIENTO
2. UTILIZACIÓN
3. LIBERACION
ESTABLECIMIENTO

En el establecimiento de una sesión un usuario de sesión

invoca una primitiva S-CONNECT.request con el objeto de
establecer una sesión, el proveedor de sesión solo ejecuta un
T-CONNECT.request para establecer una conexión de
transporte.
De la misma manera, el establecimento de una sesión, al igual
que el establecimiento de un conexión de transporte, implica
una negociación entre los corresponsales (usuarios) para fijar
los valores de varios parámetros como pueden ser la calidad
de servicio, y la bandera indicando si los datos acelerados
están o no permitidos.
Estos se pasan a la conexión de transporte sin que se les haga
modificación alguna.
LIBERACIÓN

En la liberación existen importantes diferencias entres una

sesión y una conexión de transporte. La principal entre esta es
la forma de cómo se liberan las sesiones y las conexiones de
transporte.
Las conexiónes de trasnporte terminan con la primitiva T-
DISCONNECT.request, que produce una liberación abrupta y
puede traer como resultado la perdida de los datos en trafico
que haya en el momento de la liberación.
Las sesiones se terminan con la primitiva S-RELEASE.request
que resulta en una liberación ordenada en la cual los datos no
se llegan a perder.
MANEJO DE DIALOGO
COMUNICACIÓN EN HALF DUPLEX
S-DATA
request S-DATA
indication
S-DATA
request S-DATA
indication
S-TOKEN-GIVE
request
COMUNICACIÓN EN HALF DUPLEX
S-DATA
request S-DATA
indication
S-DATA
request S-DATA
indication

S-TOKEN-GIVE
request S-TOKEN-GIVE
indication

S-DATA
request
S-DATA
indication
COMUNICACIÓN EN FULL DUPLEX
SINCRONIZACIÓN

Los usuarios pueden insertar puntos de

sincronización en el flujo del mensaje. Cada
uno de estos puntos lleva un número de
sede. Cuando un usuario invoca una
primitiva para solicitar un punto de
sincronización, el otro obtiene una
indicación. De la misma manera si uno de
ellos invoca una primitiva para
resincronización el otro también obtiene una
indicación de esto.
El almacenamiento de los mensajes y la
subsiguiente retransmisión posterior se lleva a
cabo arriba de la capa de sesión; lo que la
capa de sesión proporciona es una forma
de transportar señales de sincronización y
resincronización numeradas a través de la
red.
PUNTOS DE SINCRONIZACIÓN

Son identificadores que se van introduciendo a lo largo

de la sesión, y que permiten devolver a ésta a una
situación reconocible si se producen errores o existe
algún desacuerdo (mediante un procedimiento de
resincronización). Los puntos de sincronizacion pueden
ser:
- Mayores
- Menores

Nota: Hay que distinguir entre errores de comunicación

(ya resueltos en los niveles 1 al 4) y de aplicación.
PUNTOS DE SINCRONIZACIÓN

 PUNTOS DE SINCRONIZACION MAYORES

Se debe confirmar explícitamente. Son utilizados para
que ciertas actividades se hagan completamente o no
se hagan. Es necesario para poder tener el testigo de
sincronización mayor o actividad. Delimitan las
unidades de diálogo. Son siempre confirmados.

 PUNTOS DE SINCRONIZACION MENORES

Son puntos que sincronizan tareas menos críticas. Es
necesario tener el testigo de sincronización menor. Se
insertan dentro de las unidades de diálogo. Pueden ser
no confirmados.
UNIDAD DE DIALOGO

Las delimitadas por los puntos de

sincronización mayor.
TESTIGOS (TOKENS)

Son derechos que permiten invocar distintos servicios y

que se asignan dinámicamente entre los interlocutores.
El servicio asociado a un testigo sólo puede ser
invocado por su poseedor.

TIPOS DE TESTIGOS:
– De datos
– De liberación de conexión
–
De sincronización menor
– De sincronización mayor y actividad
TIPOS DE DATOS

 Normales

 Acelerados (Expedited)

 Tipados (Typed)

 De Capacidad (Capability)
ADMINISTRACIÓN DE ACTIVIDADES

Permite que el usuario divida el flujo de mensajes en unidades lógicas

denominadas actividades en la terminología OSI. Cada actividad es
completamente independiente de cualquiera de las demás que
pudieron haber venido antes o que vendrán después de ella.

Un posible uso es el de "poner en cuarentena" las peticiones recibidas

hasta que finalice la actividad, evitando bloqueos.

Las actividades pueden interrumpirse, reanudarse o ser abandonadas.

No es posible solapar dos o más actividades.
ADMINISTRACIÓN DE ACTIVIDADES

También pueden extenderse a lo largo de más de una

sesión:

Por último, una actividad puede descomponerse en una

o más unidades de diálogo:

Para evitar el inicio de actividades simultáneas desde

ambos extremos del diálogo, la administración de
actividades se controla mediante un testigo.
GESTIÓN DE ACTIVIDADES

• Una actividad es una unidad lógica de

trabajo y consiste de una o mas unidades de
diálogo. Es una forma de estructurar el
intercambio de datos.
• Pueden interrumpirse y retomarse mas tarde.
La salvaguarda de los datos es
responsabilidad del usuario de sesión.
INFORME DE EXCEPCIONES

• Para comunicación de situaciones

excepcionales (normalmente errores) entre
usuarios y el proveedor del servicio:
• Iniciados por el usuario:
• S-U-EXCEPTION-REPORT.request (motivo,
datos)
• S-U-EXCEPTION-REPORT.indication (motivo,
datos)
• Iniciado por el proveedor:
• S-P-EXCEPTION-REPORT.indication (motivo)
PROTOCOLOS IMPORTANTES
SERVICIO

Esta capa proporciona sus servicios a la

capa de presentación, facilitando el medio
necesario para que las entidades de
presentación de dos máquinas diferentes
organicen y sincronicen su diálogo y
procedan al intercambio de datos, mediante
el establecimiento de sesiones.
TIPOS DE SERVICIO

 SERVICIO ORIENTADO A LA CONEXIÓN

– FASE DE ESTABLECIMIENTO DE LA SESIÓN O
CONEXIÓN
– TRANSFERENCIA DE DATOS
–
–
GESTIÓN DE TOKENS o TESTIGOS
– SINCRONIZACIÓN Y RESINCRONIZACIÓN
– COMUNICACIÓN DE EXCEPCIONES
– GESTION DE ACTIVIDAD
CIERRE DE UNA SESIÓN O LIBERACIÓN DE
LA CONEXIÓN
 SERVICIO NO ORIENTADOS A CONEXIÓN
– TRANSFERENCIA DE DATOS
PRIMITIVAS

Existen cuatro tipos de primitivas.

– De petición o solicitud (REQUEST). Empleada para invocar
un servicio y pasarle los parámetros necesarios para su
ejecución.
– De indicación (INDICATION). Usada para indicar que un
procedimiento ha sido invocado por el usuario par del
servicio en la conexión y pasar los parámetros asociados o
para indicar al usuario del servicio el inicio de una acción
por parte del proveedor.
– De respuesta (RESPONSE). Empleada por el usuario del
servicio para reconocer o completar algún procedimiento
previamente iniciado por una indicación del proveedor.
– De confirmación (CONFIRM). Usada por el proveedor del
servicio para reconocer o completar algún procedimiento
previamente iniciado por una petición del usuario.
PRIMITIVAS
SINCRONIZACIÓN Y
RESINCRONIZACIÓN

Sincronización: Este grupo de servicios permite, si es

necesario, abandonar la conversación y retomarla en un
punto anterior conocido, por un error.
Existen 2 tipos: Puntos de sincronización mayor y menor
– S-SYNC-MAJOR.request ()
– S-SYNC-MAJOR.indication ()
– S-SYNC-MAJOR.response ()
– S-SYNC-MAJOR.confirm ()
– S-SYNC-MINOR.request ()
– S-SYNC-MINOR.indication ()
– S-SYNC-MINOR.response ()
– S-SYNC-MINOR.confirm ()
SINCRONIZACIÓN Y
RESINCRONIZACIÓN

Resincronizacion.Para regresar a un punto

marcado por un punto de sincronismo.
– S-RESYNC.request ()
– S-RESYNC.indication ()
– S-RESYNC.response ()
– S-RESYNC.confirm ()
COMUNICACIÓN DE
EXCEPCIONES

Para comunicación de situaciones

excepcionales (normalmente errores) entre
usuarios y el proveedor del servicio:
Iniciados por el usuario:
– S-U-EXCEPTION-REPORT.request ()
– S-U-EXCEPTION-REPORT.indication ()
Iniciado por el proveedor:
– S-P-EXCEPTION-REPORT.indication ()
MODELO OSI – CAPA DE SESIÓN

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.
Más bien depende de las aplicaciones
individuales al manejo de sus sesiones,
siempre que sea necesario.
 Se ha trabajado mucho sobre RPC
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.
Modo semidúplex no está soportado
CAPA DE SESIÓN EN USENET

Aligual que en ARPANET, USENET no

cuenta con una capa de sesión.

Ninguno de los servicios de sesión se

necesita en absoluto.