Una determinada capa de una arquitectura puede ofrecer gran cantidad de servicios.

Los servicios bsicos que casi siempre se ofrecen son: CONNECT: Se emplea para establecer una conexin. Este servicio se utiliza en comunicaciones orientadas a la conexin. DISCONNECT: Se utiliza para liberar una conexin y as terminar la comunicacin. Tambin es un servicio orientado a la conexin. DATA: Se utiliza para enviar informacin, tanto orientado a la conexin como sin conexin.

Cuando una capa cualquiera de la arquitectura desea establecer una conexin con su homnima remota, deber realizar una llamada al servicio CONNECT de la capa que tiene debajo. sta, a su vez, tambin debe realizar esa llamada, a no ser que se trate de la capa ms inferior. Lo mismo ocurre con los servicios DISCONNECT y DATA.

Primitivas de servicios.
Un servicio est definido por un conjunto de operaciones ms sencillas llamadas primitivas. En general, las primitivas se utilizan para realizar alguna accin o para informar de un suceso ocurrido en una entidad par.

Queremos establecer una conexin utilizando la notacin formal para las primitivas y servicios. Sin tener en cuenta las diferentes capas de la arquitectura de la red, el orden de acciones que se realiza es el siguiente: 1. La estacin 1 que desea establecer la conexin realiza una llamada a la primitiva CONNECT.request, lo que produce el envo de un mensaje de control al extremo distante. 2. La estacin 2 recibe una notificacin CONNECT.indication que le advierte de que existe una entidad de su mismo nivel que quiere establecer una conexin con sta, ya que ha recibido un mensaje de control.

3. La estacin 2 llama a la primitiva CONNECT.response para que se enve otro mensaje de control como respuesta, aceptando las condiciones para el establecimiento de la comunicacin.

4. La estacin 1 recibe la respuesta a su solicitud y es advertida por el evento CONNECT.confirm. En ese momento sabr si se ha aceptado o denegado la solicitud de conexin, examinando el contenido del mensaje de control recibido.

Todos estos pasos tambin se pueden representar grficamente como muestra la figura.

La mayor parte de las primitivas tienen parmetros adicionales, como son la direccin de la estacin en el otro extremo, el mensaje que se enva, el tipo de confirmacin (positiva o negativa), etc. La tabla resume algunos parmetros ms importantes que se relacionan normalmente con las primitivas.

Existen algunas reglas bsicas a la hora de trabajar con primitivas: El servicio CONNECT siempre es confirmado, por lo que, llevar siempre las primitivas request, indication, response y confirm. Esto impide la prdida accidental de

datos, da la opcin al otro extremo de poder negar determinadas solicitudes de conexin y permite que ambos interlocutores puedan negociar las condiciones de la comunicacin. El servicio DATA puede ser confirmado o no. Si es no confirmado, slo llevar las primitivas request e indication.

El servicio DISCONNECT suele ser no confirmado, aunque en determinadas condiciones es importante asegurar que los dos extremos finalizan la comunicacin y as liberan sus recursos reservados.

EJEMPLO 1 Se desea enviar un bloque de datos utilizando un servicio orientado a la conexin y fiable. Para ello, hay que indicar cules son las primitivas que se ejecutan en cada una de las estaciones que intervienen en la comunicacin.

EJEMPLO 2 Supongamos que queremos realizar el diagrama de comunicacin entre dos estaciones, suponiendo que cada una de ellas tiene una arquitectura de dos capas y se utiliza un servicio no orientado a la conexin para transmitir los datos. Dadas esas condiciones, podemos encontrarnos con varios casos diferentes: Servicios fiables en la capa 1 y en la capa 2 (figura 2.13). Servicio fiable en la capa 1 y no fiable en la capa 2 (figura 2.14). Servicio no fiable en la capa 1 y fiable en la capa 2 (figura 2.15).

Figura 2.13

Los servicios de la capa 1 y de la capa 2 son fiables. En estas condiciones, las dos capas de la estacin 2 deben enviar confirmaciones y, a su vez, las dos capas de la estacin 1 deben recibir respuesta a sus envos.

Figura 2.14

Los servicios de la capa 1 son fiables, pero los de la capa 2, no. En este caso, slo la capa 1 gestiona el uso de las confirmaciones en los envos. La capa 2, por su parte, solamente puede enviar o recibir datos. Este modelo de comunicacin resulta ms ptimo y natural con respecto al resto, ya que las capas inferiores se encargan de controlar los errores, tarea que queda oculta para las capas superiores.

FIGURA 2.15

Los servicios de la capa 1 son no fiables y los de la capa 2 son fiables. Se da la circunstancia de que la capa 1 de la estacin 2 debe enviar una confirmacin, pero no dispone de primitivas DATA.response ni DATA.cofirm. Para solucionar esto, la capa 2 incluye toda la informacin de control dentro del campo de datos de un mensaje, que se enva con la primitiva DATA.request. Tanto la capa 1 de la estacin 2 como la capa 1 de la estacin 1 desconocen el significado de la informacin que estn enviando y no saben que se trata en realidad de informacin de control para confirmar la recepcin correcta de un envo.