Diseño de arquitecturas de redes

Cuando se diseña una arquitectura de red hay una serie de aspectos y decisiones fundamentales que condicionan todo el proceso. Entre estos cabe mencionar los siguientes:

Direccionamiento: cada capa debe poder identificar los mensajes que envía y recibe. En ocasiones un mismo ordenador puede tener varias instancias de una misma capa, por lo que la sola identificación del ordenador puede no ser suficiente.

Normalmente cualquier protocolo admite comunicación en ambos sentidos (dúplex); pero no siempre se permite que esta ocurra de forma simultánea (full-dúplex). También se debe determinar si se definirán prioridades, y cuáles serán éstas.

En cualquier comunicación es preciso establecer un control de errores, ya que los canales de comunicación no son totalmente fiables. Es preciso decidir que código de detección y/o corrección de errores se va a utilizar, y en que capa o capas se va a llevar a cabo. Generalmente a medida que los medios de transmisión mejoran y las tasas de errores disminuyen la detección/corrección se va suprimiendo de las capas inferiores y dejando al cuidado de las más altas, ya que es un proceso costoso que puede llegar a ralentizar apreciablemente la transmisión.

En algunos casos se debe tener en cuenta la posibilidad de que los paquetes lleguen a su destino en orden diferente al de envío.

Debe contemplarse la posibilidad de que el receptor no sea capaz de ‘digerir’ la información enviada por el transmisor. Para esto es conveniente disponer de algún mecanismo de control de flujo y notificación para indicar la congestión.

Normalmente los equipos funcionan de forma óptima cuando el tamaño de los mensajes que se envían esta dentro de un cierto rango. Para evitar los problemas que puede producir el envío de mensajes muy grandes o muy pequeños se suelen contemplar mecanismos de fragmentación y reagrupamiento. Es importante que estos mecanismos estén claramente especificados para evitar la destrucción del mensaje en tránsito.

Interfaces y servicios

Debido a su importancia vamos a estudiar con más detalle que es un servicio. Empezaremos con algunas definiciones.

Llamaremos entidad a los elementos activos en cada capa. Una entidad puede ser un proceso, un componente hardware, o una combinación de ambos. Un ordenador puede tener una o varias entidades en cada capa (por ejemplo un ordenador con dos tarjetas de conexión a LAN).

Llamaremos entidades iguales o entidades pares (‘peer entities’ en inglés) a dos entidades diferentes que pertenecen a la misma capa; generalmente estarán en diferentes máquinas, pero podrían estar en la misma.

Las entidades de la capa n implementan los servicios que utiliza la capa n+1. En este caso la capa n actúa como el proveedor del servicio y la capa n+1 es el usuario del servicio. El uso que la capa n haga de los servicios de la capa n-1 es algo que no afecta ni incumbe a la capa n+1.

Los servicios están disponibles en los SAPs (Service Access Points). Los SAPs de la capa n son los puntos donde la capa n+1 puede acceder a los servicios ofertados. Cada SAP de cada entidad de la capa n tiene una dirección que le identifica de forma única en toda la red.

Denominamos interfaz al conjunto de reglas que gobiernan el intercambio de información entre capas. En una comunicación la entidad de la capa n+1 intercambia una IDU (Interface Data Unit) con la entidad de la capa n a través del SAP (ver Fig. 1-12 del Tanenbaum). La IDU esta formada por una SDU (Service Data Unit) e información de control. La SDU es la información que se transmite a la entidad equivalente (peer) en el lado contrario, y de allí a la capa n+1 a través de su SAP. La información de control es necesaria como su nombre indica para que la capa n haga correctamente su trabajo, pero no es parte de los datos mismos. En la especificación de una arquitectura solo es necesario describir la estructura de la SDU, pero no la de la IDU; ésta se describe en la interfaz, que puede ser distinta para cada implementación.

Para transferir la SDU (Service Data Unit) la entidad de la capa n puede tener que fragmentarla en varias PDUs (Protocol Data Units). Cada PDU llevará una cabecera que permitirá a la entidad de la capa n en el otro lado ensamblar de nuevo la SDU correctamente.

Servicios orientados y no orientados a conexión

En una arquitectura de redes cada capa utiliza los servicios de la capa inmediatamente inferior para comunicar con la correspondiente del otro extremo. En función de como se establezca esa comunicación suelen distinguirse dos tipos de servicios: orientados a conexión y no orientados a conexión.

En el servicio orientado a conexión, también llamado CONS (Connection Oriented Network Service), primero se establece el canal de comunicación, después se transmiten los datos, y por último se termina la conexión. Dicha ‘conexión’ se denomina circuito virtual (VC, virtual circuit). Una vez establecido el VC el camino físico que van a seguir los datos está determinado; los paquetes deben ir todos por él desde el origen al destino, y llegar en el mismo orden con el que han salido. Dado que el VC establece de forma clara el destino, los paquetes no necesitan contener su dirección. Generalmente se distinguen dos tipos de circuitos virtuales: conmutados, también llamados SVCs (Switched Virtual Circuits), y permanentes, conocidos también como PVCs (Permanent Virtual Circuits). Los SVCs se establecen y terminan a petición del usuario, normalmente cuando hay paquetes que se quieren transmitir. Los PVCs están establecidos todo el tiempo que la red está operativa (o al menos eso es lo que se pretende). Al hablar de circuitos utilizaremos las denominaciones ‘establecer’ y ‘terminar’ en vez de abrir y cerrar, ya que estos términos tienen un significado completamente opuesto según se trate de ingenieros informáticos o electrónicos (para un ingeniero electrónico un circuito esta abierto cuando esta interrumpido, es decir cuando no puede viajar por el ninguna señal).

En el servicio no orientado a conexión, llamado también CLNS (ConnectionLess Network Service) la comunicación se establece de manera menos formal. Cuando una entidad tiene información que transmitir sencillamente la envía en forma de paquetes, confiando que estos llegaran a su destino mas pronto o mas tarde. No se establece previamente un VC ni otro tipo de canal de comunicación extremo a extremo; los paquetes pueden ir por caminos físicos diversos, y deben incluir cada uno la dirección de destino. Los paquetes pueden ser almacenados por nodos intermedios de la red, y reenviados mas tarde. Aunque lo normal es que lleguen en el mismo orden con que han salido, esto no esta garantizado como ocurría en el servicio orientado a conexión debido al almacenamiento en nodos intermedios y a la diversidad de caminos físicos posibles. A los paquetes enviados en un servicio no orientado a conexión se les denomina datagramas, ya que cada paquete viaja hacia su destino de forma completamente independiente de los demás como si fuera un telegrama.

Generalmente se suelen explicar los modelos orientado y no orientado a conexión con dos analogías: el sistema telefónico y el sistema postal. El sistema telefónico es un ejemplo de servicio orientado a conexión, mientras que el sistema postal es un servicio no orientado a conexión. La analogía es bastante exacta salvo por el hecho de que en redes telemáticas la diferencia en el tiempo de entrega del mensaje entre servicios CONS y CLNS no es tan grande como la anterior comparación podría hacer pensar.

En cualquiera de los dos tipos de servicio antes mencionados es posible que se produzca pérdida de información; también puede ocurrir que el tiempo de envío del paquete, también llamado retardo o latencia (‘delay’ y ‘latency’ respectivamente en inglés) sea demasiado grande o fluctúe dentro de un amplio rango debido a la carga o congestión en la red (el término inglés usado para denominar dicha fluctuación es jitter, que literalmente significa mieditis, temblar de miedo). En algunos casos se requiere una entrega fiable, es decir que se garantice la entrega de los paquetes, o un retardo y/o jitter garantizados, o sea no superiores a un determinado valor. Por ejemplo si transferimos un fichero, normalmente dividiéndolo en múltiples paquetes, necesitaremos un servicio fiable en la entrega, pero podemos tolerar un retardo o jitter más o menos grande; por el contrario la voz, o el vídeo (imagen en movimiento) toleran un pequeño porcentaje de pérdidas, pero requieren un retardo y un jitter reducidos y constantes. Cuando al establecer una comunicación se solicita un nivel mínimo para alguno de éstos parámetros se dice que se requiere una calidad de servicio (llamada QoS, Quality of Service). La calidad de servicio estipula unos mínimos que la red ha de satisfacer para efectuar la conexión, por ejemplo 'transmisión fiable con un retardo no superior a 100 ms'; es posible que la red no sea capaz de satisfacer la calidad solicitada, en cuyo caso podría hacer una propuesta alternativa, a modo de regateo (por ejemplo, ‘no puedo asegurar 100 ms de retardo, lo mínimo es 250ms, ¿estás conforme?’) Una vez pactadas las condiciones de la conexión éstas actúan a modo de contrato que obliga a la red a dar la calidad de servicio prometida al usuario. No todos los protocolos o redes ofrecen la posibilidad de negociar calidades de servicio; en estos casos el protocolo simplemente aprovecha los medios disponibles lo mejor que puede, intentando evitar las congestiones y situaciones críticas en lo posible, y repartir los recursos entre los usuarios de manera mas o menos equilibrada; esta estrategia se denomina del ‘mejor esfuerzo’ (o también ‘best effort’). Como ejemplos de redes con QoS podemos citar ATM, como ejemplos de redes ‘best effort’ podemos mencionar TCP/IP (la Internet) y Ethernet.

Primitivas de servicio

Recordemos que, en el modelo de capas, cada capa ofrece sus servicios a la siguiente. El servicio se define por un conjunto de operaciones u órdenes que la capa superior puede mandar a la capa inferior. Dicho conjunto de operaciones se denomina primitivas.

Vamos a analizar en detalle las primitivas que participan en el establecimiento y terminación de una conexión entre la capa n de dos sistemas llamados A y B. La entidad A.n (es decir, la capa n del sistema A) inicia la conexión emitiendo la primitiva CONNECT.request, que provoca la transferencia de una IDU (Interface Data Unit) a través del SAP (Service Access Point) a la entidad A.n-1; ésta extrae la información de control y la interpreta creando la SDU (Service data Unit), que convierte en una o varias PDUs (Protocol Data Units); las PDUs son transferidas a B.n-1, que regenera a partir de ello la SDU, luego la información de control correspondiente y con ambos la IDU; una vez dispone de la IDU la transmite a B.n a través del SAP mediante la primitiva CONNECT.indication, que le indica a B.n que alguna entidad desea establecer conexión con ella. La entidad B.n emite entonces la primitiva CONNECT.response para indicar si acepta o rechaza la conexión (las primitivas pueden llevar parámetros y sería aquí donde se indicaría esto). La respuesta se traduce en un paquete que B.n-1 envía a A.n-1, el cual informa a A.n de la situación mediante la primitiva CONNECT.confirm.

Obsérvese que el mismo evento origina diferentes primitivas en cada lado. Una CONNECT.request produce una CONNECT.indication en el lado contrario, y la CONNECT.response se convierte en CONNECT.confirm. Existe una cierta simetría entre las primitivas, ya que a una CONNECT.request siempre le corresponderá una CONNECT.indication en el lado opuesto (salvo que falle la comunicación).

En este ejemplo hemos hecho un servicio confirmado, es decir, hemos verificado que la conexión se establecía, para lo cual ha tenido que enviarse un paquete en cada sentido. Se podría haber hecho una conexión no confirmada, para lo cual sencillamente se habría emitido la CONNECT.request y la CONNECT.indication.

Una vez establecida la conexión lo normal sería transferir datos, y finalmente terminar la conexión. Un ejemplo del conjunto de primitivas que se emitirían a lo largo de una conexión podría ser el siguiente:

En A:                                                                    En B:

CONNECT.request

CONNECT.indication

CONNECT.response

CONNECT.confirm

DATA.request

DATA.indication

DATA.request

DATA.indication

DISCONNECT.request

DISCONNECT.indication

Aquí hemos introducido cuatro nuevas primitivas para poder transferir datos y terminar la conexión. Obsérvese que como antes una primitiva request va seguida siempre de una indication en el lado contrario. En este ejemplo hemos supuesto que se intercambiaban únicamente dos paquetes de datos.

Como ya hemos dicho las primitivas pueden llevar parámetros, y de hecho casi siempre los llevan. Por ejemplo una CONNECT.request llevará la máquina con la que se desea conectar, una CONNECT.indication dirá la máquina que quiere conectar con nosotros, etc. La descripción detallada de estos argumentos, su significado, etc., no es parte de la especificación de las primitivas (y por tanto del servicio) sino del protocolo. El protocolo puede modificarse sin necesidad de cambiar las primitivas. Por ejemplo, un protocolo puede establecer que el servicio de establecimiento de conexión sea confirmado y otro que no lo sea, y ambos pueden utilizar el mismo conjunto de primitivas antes descrito.

Una vez más diremos que la interfaz no forma parte del protocolo. Por ejemplo imaginemos en el caso anterior que las entidades A.n y A.n-1 acuerdan que la SDU estará codificada en EBCDIC, mientras que B.n y B.n-1 acuerdan utilizar ASCII. Si el protocolo de la capa n-1 establece que la PDU estará en ASCII, entonces A.n-1 sabe que deberá realizar la conversión de códigos cada vez que construya una PDU a partir de una SDU, o viceversa.