Arquitectura de Redes, Sistemas y Servicio (04/05) Ingeniería Técnica de Telecomunicación Telemática. ETSIT Telecomunicación Universidad de Valladolid

Transcripción

1 Arquitectura de Redes, Sistemas y Servicio (04/05) Ingeniería Técnica de Telecomunicación Telemática ETSIT Telecomunicación Universidad de Valladolid Aclaraciones sobre la relación entre los tipos de servicios ofrecidos por capas en arquitecturas de comunicaciones y el funcionamiento interno de las mismas 1 Introducción Este breve documento intenta aclarar y fijar ideas y convenios acerca de algunas cuestiones relacionadas con las arquitecturas de comunicaciones en redes de datos que han suscitado dudas y discusiones en clase. En concreto trata de responder a preguntas tales como qué es una primitiva de servicio? qué es un servicio fiable? y uno confirmado? cuántas PDUs se intercambian entre capas pares que ofrecen servicios confirmados?, etc... En ocasiones la dificultad estriba en el uso inadecuado de la nomenclatura y por ello este documento también servirá para fijar convenios, en el ámbito de ARSS, sobre cuál es la denominación correcta de diferentes elementos de las arquitecturas de comunicaciones. 2 Algunas definiciones breves de conceptos básicos Servicio: conjunto de funcionalidades que una capa proveedora ofrece al usuario de esa capa (generalmente el usuario de una capa es la capa superior). Un servicio se especifica en términos de primitivas de servicio y sus correspondientes parámetros. Primitivas de servicio: interacciones entre un usuario de servicio y su proveedor. Una primitiva permite a un usuario de servicio especificar qué función desea que realice su proveedor y permite al dicho proveedor indicar el resultado de una función a su usuario. Parámetros de primitiva de servicio: permiten el intercambio de datos e información de control asociados a una primitiva entre un usuario y su proveedor. Tipos de primitivas de servicio: Request, Indication, Response y Confirm (ver tabla 2.3 de [2]). Tipos de servicios: En función de las fases que comprenden: o Orientado a conexión Fase de establecimiento de conexión Fase de uso del servicio Fase de finalización de conexión o No Orientado a conexión Únicamente comprenden la fase de uso del servicio En función de los tipos de primitivas asociadas (ver figura 2.10 de [2]) o Fiable o Confirmado: están involucradas primitivas de tipo request/indication/response/confirm 1 de 7

2 o No Fiable o No Confirmado: únicamente están involucradas primitivas de tipo resquest/indication Son posibles las cuatro combinaciones de tipos de servicios: Servicios orientados a conexión fiables Servicios orientados a conexión no fiables Servicios no orientados a conexión no fiables Servicios no orientados a conexión fiables PDU (Unidad de datos de protocolo, Protocol Data Unit): mensaje con datos intercambiados entre dos capas pares (del mismo nivel). Una PDU generalmente consta de una cabecera (con datos de control que tienen significado únicamente a entidades del nivel correspondiente) y un campo de datos (que, generalmente, son una PDU del nivel superior). Protocolo: conjunto de reglas que guían el diálogo entre dos entidades de dos capas pares (del mismo nivel). Dicho diálogo se lleva a cabo mediante el intercambio de PDUs de ese nivel. Mediante el intercambio de dichas PDUs se intenta llevar a cabo las tareas necesarias para ofrecer un determinado servicio a los usuarios de esa capa. Los protocolos incorporan mecanismos para resolver diversos problemas asociados a las redes de datos. Así, por ejemplo, los protocolos pueden incorporar mecanismos para el establecimiento de conexiones, para la liberación de las mismas, para la confirmación de la recepción de datos, para el control de errores, para el control de flujo, para el control de la congestión, etc. A partir de las definiciones anteriores, se puede intentar aclarar algunas cuestiones: 3 Algunas aclaraciones Un servicio fiable implica un servicio de transmisión libre de errores? (Respuesta obtenida de [1]) No. Un servicio fiable es un servicio con confirmación (el usuario de servicio entrega datos al proveedor, y el proveedor informa con posterioridad de si los datos se entregaron con éxito al destino). Esto significa que el proveedor habla con su capa par para que la capa par le informe de si ha entregado los datos al usuario en la máquina de destino, y normalmente se hace control de errores (es decir, si la PDU no llega bien en el primer intento, se retransmite). Un servicio no fiable es un servicio sin confirmación (el usuario de servicio entrega datos al proveedor, y el proveedor no informa del éxito o fracaso de la comunicación). Esto libera al proveedor de la máquina de origen de preocuparse por el éxito de la transmisión de su PDU, pero podría a pesar de todo hablar con su capa par para hacer control de errores, aunque no informe al usuario de servicio de ello. A pesar de esta distinción, lo más habitual es que los servicios fiables ofrezcan transmisión libre de errores (salvo causas insalvables) y que los servicios no fiables sean de mejor intento (best effort). 2 de 7

3 Si el nivel N ofrece un servicio fiable, es necesario que el protocolo de nivel N incorpore mecanismos de confirmación de datos enviados? No necesariamente. Suele depender (aunque no necesariamente) del tipo de servicio ofrecido por el nivel N-1 que, a su vez, puede tener influencia sobre el tipo de PDUs utilizadas por el protocolo de nivel N. Algunas alternativas (se van a ilustrar mediante un servicio genérico de intercambio de datos que denominaremos DATA): Servicio fiable (confirmado) de nivel N ofrecido por una entidad de nivel N que emplea un protocolo con mecanismos de confirmación de datos. Para el envío de las PDUs, la capa de N utiliza el servicio ofrecido por la capa N-1. En este ejemplo se asume que el servicio de nivel N-1 es no fiable (no confirmado). N_DATA.response N_DATA.confirm Figura 1 Cronograma de ejemplo de un servicio fiable de nivel N ofrecido sobre un servicio no fiable de nivel N-1 1. En este caso, el protocolo de nivel N ha de utilizar mecanismos de confirmación de datos (ACKs) para poder ofrecer un servicio fiable ya que el nivel N-1 ofrece un servicio no confirmado. Implica esto que el nivel N se ocupa de retransmitir las PDUs no asentidas? No necesariamente (ver la contestación a la pregunta anterior sobre si los servicios fiables implican transmisión de datos sin errores). Normalmente es así (un servicio de confirmación de datos lleva parejo un mecanismo de control de errores) pero no es imprescindible. 1 En los cronogramas de este documento, las flechas indican la invocación de primitivas (de modo similar a como se hace en el capítulo 2 de [2]). Así pues, esas flechas NO indican la propagación de una PDU de una capa a su par (como sucedía con los cronogramas de HDLC, por ejemplo). 3 de 7

4 A modo de ejemplo, si el protocolo de nivel N emplea un mecanismo de control de errores basado en una técnica ARQ de parada y espera, podría suceder algo parecido a lo siguiente: PDU se pierde Vence temporizador (tiempo no a escala) N_DATA.response N_DATA.confirm Figura 2 Cronograma de ejemplo de un servicio fiable de nivel N ofrecido sobre un servicio no fiable de nivel N-1 en el que se aprecia cómo el protocolo de nivel N incorpora mecanismos de control de errores. Servicio fiable (confirmado) de nivel N ofrecido por una entidad de nivel N que emplea un protocolo sin mecanismos de confirmación de datos. Para el envío de las PDUs, la capa de N utiliza el servicio ofrecido por la capa N-1. En este ejemplo se asume que el servicio de nivel N-1 es fiable (confirmado) N_DATA.response N-1_DATA.confirm N-1_DATA.reponse N_DATA.confirm Figura 3 Cronograma de ejemplo de un servicio fiable de nivel N ofrecido sobre un servicio fiable de nivel N-1. 4 de 7

5 En este caso, el nivel N únicamente ha generado una PDU con datos cuya recepción es confirmada por el nivel inferior (el nivel N pasa dicha confirmación a su usuario mediante la primitiva N_DATA.confirm). Si el nivel N ofrece un servicio no fiable, es necesario que el protocolo de nivel N no incorpore mecanismos de confirmación de datos enviados? No necesariamente. Lo normal es que si el servicio es no fiable, el protocolo de nivel N no utilice mecanismos de confirmación de datos... pero no es la única opción. Así, por ejemplo, y tal y como se indicó en la respuesta a la primera pregunta, es posible ofrecer un servicio no fiable y que, sin embargo, el proveedor de servicio utilice mecanismos de confirmación de datos e, incluso, de recuperación frente a errores. Servicio no fiable (no confirmado) de nivel N ofrecido por una entidad de nivel N que emplea un protocolo con mecanismos de confirmación de datos. Para el envío de las PDUs, la capa de N utiliza el servicio ofrecido por la capa N-1. En este ejemplo se asume que el servicio de nivel N-1 es no fiable (no confirmado) PDU se pierde Vence temporizador (tiempo no a escala) El nivel N asiente la recepción de datos sin esperar response del nivel N+1 Figura 4 Cronograma de ejemplo de un servicio no fiable de nivel N ofrecido sobre un servicio no fiable de nivel N-1. Se puede observar que el protocolo de nivel N incorpora mecanismos de confirmación de datos y control de errores. En este caso el nivel N consigue una transmisión libre de errores (salvo causas insalvables) aunque el servicio ofrecido (y el usado de nivel N-1) no sea confirmado. También es posible que quien ofrezca el servicio confirmado sea el nivel inferior (aunque no se informe de las confirmaciones al nivel N+1). En ese caso tendríamos: 5 de 7

6 Servicio no fiable (no confirmado) de nivel N ofrecido por una entidad de nivel N que emplea un protocolo sin mecanismos de confirmación de datos. Para el envío de las PDUs, la capa de N utiliza el servicio ofrecido por la capa N-1. En este ejemplo se asume que el servicio de nivel N-1 es fiable (confirmado) N-1_DATA.confirm N-1_DATA.reponse No se informa al usuario del nivel N Figura 5 Cronograma de ejemplo de un servicio no fiable de nivel N ofrecido sobre un servicio fiable de nivel N-1. Pero lo más normal es: Servicio no fiable (no confirmado) de nivel N ofrecido por una entidad de nivel N que emplea un protocolo sin mecanismos de confirmación de datos. Para el envío de las PDUs, la capa de N utiliza el servicio ofrecido por la capa N-1. En este ejemplo se asume que el servicio de nivel N-1 es no fiable (no confirmado). Figura 6 Cronograma de ejemplo de un servicio no fiable de nivel N ofrecido sobre un servicio no fiable de nivel N-1. 6 de 7

7 Este caso implica que no se puede conseguir una transmisión libre de errores? No necesariamente, porque lo niveles inferiores al N pueden estar ocupándose del control de errores (aunque si es el nivel N quien por alguna razón descarta una PDU debido a, por ejemplo, agotamiento de memoria, los niveles inferiores no podrán recuperar ese error...). Referencias [1] Eduardo Gómez, Página de preguntas frecuentes, Arquitectura de Redes, Sistemas y Servicios (Ingeniería de Telecomunicación). Disponible en Última actualización 16/11/2004. [2] W. Stallings, Comunicaciones y Redes de Computadores, 7ª ed., Prentice- Hall de 7