Redes de Datos
1er parcial – 2018
Solución
Esta es una posible solución a las preguntas planteadas. Por razones didácticas normalmente contiene bastante más información que la mínima necesaria para responder la pregunta.
Pregunta 1
(6 puntos)
a) En relación con el modelo de capas analizado en clase, defina los conceptos de entidad y protocolo.
Una “entidad” es un elemento activo dentro de una capa e implementa las funciones de la capa. Puede haber más de una entidad para implementar diferentes funciones dentro de una capa. Las entidades pueden estar implementadas en software (procesos) o en hardware (ej: chips de I/O). Ejemplos de entidades son: a nivel de capa de aplicación un servidor de nombres, a nivel de capa de transporte el proceso del sistema operativo que implementa TCP, a nivel de capa de red un enrutador. Llamamos entidades pares a aquellas entidades de un mismo nivel en diferentes máquinas que intervienen en la comunicación.
Un protocolo es un acuerdo entre partes sobre cómo va a realizarse la comunicación. En el modelo utilizado en el curso, llamamos protocolos al conjunto de reglas de comunicación y convenciones entre entidades pares. Por ejemplo la entidad que implementa TCP en la capa 4 de la máquina A, dialoga utilizando un “protocolo” (TCP) con la entidad par de la máquina B. El protocolo define el formato de datos que se intercambia (qué campos, con qué valores posibles, etc) así como las reglas de intercambio (antes de enviar datos se necesita establecer una conexión, los números de secuencia deben reconocerse de tal forma, etc).
b) En el estudio de capa de aplicación, se consideró el caso de la navegación en Internet. Para este caso, identifique y fundamente con un ejemplo, cuáles serían las entidades y protocolos que están involucrados a nivel de capa de aplicación.
Consideremos el caso de la navegación en Internet. Veremos algunas entidades y protocolos que están involucrados a nivel de capa de aplicación.
Supongamos que deseamos ver el contenido de una página, por ejemplo www.algo.com. Para eso necesitamos un programa cliente de navegación (el navegador o browser, por ejemplo Firefox, Chrome, Internet Explorer, etc) que es la entidad de capa de aplicación en la máquina cliente.
En el otro extremo de la comunicación, existe un servidor web que aloja el contenido de www.algo.com que será la entidad par con la que dialogará el navegador.
Estas dos entidades (navegador y servidor web) dialogarán usando normalmente el protocolo HTTP (Hypertext Transport Protocol) o HTTPS (HTTP Seguro).
Es necesario mencionar que para poder efectuar la conexión vamos a necesitar la dirección IP del servidor web al que deseamos acceder y para eso tenemos que recurrir al servicio DNS que se encarga de resolver la correspondencia entre un nombre o etiqueta (en el ejemplo www.algo.com) y una dirección IP (la del servidor que aloja ese sitio). Por tanto participarán también una entidad cliente DNS en nuestro equipo que dialogará con el protocolo DNS con una entidad par implementada en un servidor DNS (típicamente el servidor local recursivo).
Pregunta 2
(9 puntos)
a) Explique cómo se organiza el árbol de nombres en el sistema de nombres de dominio (DNS).
El sistema de nombres de dominio surgió ante la necesidad de vincular las direcciones IP que entienden las máquinas con los nombres de dominio más amigables para los humanos, aunque desde sus inicios se utilizó para guardar también otros tipos de información. Originalmente, siendo pocos (del orden de cientos) los dominios existentes, se utilizaban tablas que realizaban este vínculo, pero con el paso del tiempo se hizo necesario un sistema escalable, eficiente, descentralizado, que evitara la saturación de los servidores y la superposición de nombres. Así surgió el DNS.
Cada nombre está compuesto por etiquetas alfanuméricas que convencionalmente se representan unidas por puntos. Estas etiquetas se ordenan en un “árbol” de nombres, partiendo de una «raíz», que son los root servers (son 13 direcciones IPv4 y otras tantas IPv6, con copias distribuidas para dar redundancia), coordinados por la IANA. La raíz convencionalmente se representa por un punto.
Las etiquetas en el DNS se organizan en una estructura de árbol con la raíz hacia arriba. En cada nodo y hoja del árbol pueden existir RR (Resource Records) asociando información a esa etiqueta. Los RR pueden ser de diferentes tipos: A (address IPv4), AAAA (address IPv6), NS (name server), CNAME (Canonical Name o alias), PTR (pointer), MX (mail exchange), etc.
Un FQDN (Fully Qualified Domain Name) se conforma concatenando y separando por puntos (“.”) desde abajo hacia arriba las etiquetas correspondientes. En el diagrama anterior, por ejemplo fluit.cs.vu.nl. Y pc24.cs.keio.ac.jp serían FQDNs.
El primer nivel bajo la raíz del arbol (root) son los TLD (Top Level Domains) donde se clasifican en dominios genéricos (.com, .edu, mil) y los dominios de dos letras asignados a los países (.jp, .us, .uy, .ar, etc).
Bajo cada TLD se pueden definir subdominios.
Para que el sistema de nombres sea escalable es necesario que la información pueda ser gestionada de forma descentralizada y que además se encuentre almacenada de forma descentralizada. Para resolver esta descentralización el DNS prevé que la autoridad que gestiona un dominio pueda delegar la autoridad para administrar sus subdominios.
Por ejemplo. Los administradores de la raíz, delegaron al Servicio Central de Informática de la Universidad de la República (SECIU) la gestión del dominio .uy. Para implementar esa delegación SECIU debe disponer un servidor DNS (con respaldo) donde se almacenarán los registros correspondientes al dominio uy. Este será el servidor autoritativo para el dominio .uy.
La delegación consiste entonces en que en los servidores DNS de la raíz (root servers) se configure un registro NS que asocie al dominio uy el nombre del servidor de nombres al que se le delega.
uy. 3600 IN NS a.nic.uy.
El registro tiene 5 campos: etiqueta, tiempo de vida, familia, tipo de registro y valor.
En este caso dice que el dominio uy está delegado al servidor cuyo nombre es a.nic.uy, con una validez de 1 hora (3600 segundos).
En general será necesario también un registro de tipo A que asocie una dirección IP al nombre del servidor, por ejemplo:
a.nic.uy. 159415 IN A 164.73.128.5
Para los niveles inferiores al TLD, cada administrador de un TLD puede administrar y/o delegar los subdominios que cree bajo su rama.
Por ejemplo para el dominio uy, SECIU decidió delegar la administración del dominio com.uy a ANTEL y administrar él mismo los dominios .edu.uy, mil.uy, gov.uy, org.uy, etc.
b) Explique el significado y cometido de los registros MX y PTR.
El registro MX indica el nombre de un servidor de correos para el dominio que figura en la etiqueta, el valor esta compuesto también por un numero que indica la prioridad del servidor. Un ejemplo es:
ETIQUETA TTL CLASE TIPO VALOR
fing.edu.uy 3600 IN MX 0 smtp.fing.edu.uy
Un registro PTR tiene como valor un alias de una dirección IP. Se usa para asociar un nombre a una dirección IP, a fin de permitir búsquedas de la dirección IP y devolver el nombre de la máquina correspondiente. Estas búsquedas se llaman búsquedas reversas y utilizan una rama particular del árbol de direcciones (el TLD “in-addr.arpa”). El TIPO PTR tiene asociados como valor el nombre asociado a la dirección IP, y como etiqueta una conformada a partir de la dirección IP. La etiqueta se forma invirtiendo los octetos y agregandole el TLD al final: si la IP vale A.B.C.D, la etiqueta valdrá D.C.B.A.in-addr.arpa. Un ejemplo es:
ETIQUETA TTL CLASE TIPO VALOR
2.32.73.164.in-addr.arpa. 86400 IN PTR davinci.fing.edu.uy.
c) Un servidor local recursivo en Canadá desea enviar un correo a [email protected]. Explique detalladamente cómo se realiza la búsqueda indicando los servidores involucrados, las consultas realizadas y las respuestas recibidas. Utilice nombres y direcciones IP de fantasía para identificar todos los equipos que necesite para realizar la consulta.
Se recomienda realizar un diagrama o una tabla con la secuencia de eventos y sus datos relevantes (qué registro se consulta, a quién se consulta, cuál es la respuesta, qué información contiene).
Para enviar un correo a [email protected] se necesita saber cuál es el equipo que recibe los correos para el dominio fing.edu.uy, o sea necesitamos averiguar el registro MX asociado al dominio fing.edu.uy y posteriormente la IP de dicho servidor.
Cuando una computadora debe resolver un nombre DNS normalmente tiene asociado un servidor de nombres recursivo a quién trasladarle la consulta. Si la computadora lo buscara por si misma, sería como si ella fuera un servidor recursivo. Consideraremos el caso en que los cachés están vacíos.
Convención de nombres:
IP_PCCA – dirección IP de la computadora de Canadá
IP_DNSRPC – dirección IP del servidor local recursivo configurado en la PCCA IP_ROOT – dirección IP de alguno de los root servers
ns.uy, IP_NSUY – nombre y dirección IP del servidor DNS autoritativo del dominio uy
ns.edu.uy, IP_NSEDUUY – nombre y dirección IP del servidor DNS autoritativo del dominio edu.uy ns.fing.edu.uy, IP_NSFING – nombre y dirección IP del servidor DNS autoritativo del dominio fing.edu.uy
Sec Origen Destino Consulta Observaciones
1 IP_PCCA IP_DNSRPC Registro MX asociado a fing.edu.uy? PCCA consulta a su DNS recursivo 2 IP_DNSRPC IP_ROOT Registro MX asociado a fing.edu.uy? Las búsquedas comienzan siempre
por la raíz del árbol si no tenemos información en caché.
Las IPs de los root servers deben ser conocidas y estar preconfiguradas en el DNS local recursivo
3 IP_ROOT IP_DNSRPC Registro NS asociado a uy es ns.uy Registro A asociado a ns.uy es IP_NSUY
Los root servers nunca responden recursivamente, por lo que la respuesta contiene las indicaciones de cómo proseguir la búsqueda. Como lo que estamos buscando pertenece a la rama uy y el root sabe que delegó esa rama a ns.uy envía el registro NS con esa información. A su vez como para proseguir la búsqueda se necesita una dirección IP a quién consultar y para evitar una segunda consulta, el root server devuelve también la IP asociada a ns.uy (glue record)
4 IP_DNSRPC IP_NSUY Registro MX asociado a fing.edu.uy? Siempre las consultas se hacen por el registro final buscado ya que podría suceder que alguien tuviera la respuesta en su caché o que fuera autoritativo para los datos buscados. 5 IP_NSUY IP_DNSRPC Registro NS asociado a edu.uy es
ns.edu.uy
Registro A asociado a ns.edu.uy es IP_NSEDUUY
Se aclara que ninguno de los servidores responde recursivamente.
6 IP_DNSRPC IP_NSEDUUY Registro MX asociado a fing.edu.uy? 7 IP_NSEDUUY IP_DNSRPC Registro NS asociado a fing.edu.uy es
ns.fing.edu.uy
Registro A asociado a ns.fing.edu.uy es IP_NSFING
8 IP_DNSRPC IP_NSFING Registro MX asociado a fing.edu.uy? 9 IP_NSFING IP_DNSRPC Registro MX asociado a fing.edu.uy es
smtp.fing.edu.uy
Observar que el registro MX contiene el nombre del servidor de correo, pero para realizar la comunicación vamos a necesitar la IP asociada a ese nombre (registro A).
Puede ser que en este paso ya nos devuelvan el registro A asociado a smtp.fing.edu.uy, de estar dentro del dominio.
Para este ejemplo se supuso que no. 10 IP_DNSRPC IP_NSFING Registro A asociado a
smtp.fing.edu.uy?
11 IP_NSFING IP_DNSRPC Registro A asociado a smtp.fing.edu.uy es IP_SMTPFING
Obtengo la IP buscada.
Tabla 1: Secuencia de consultas y respuestas DNS
Pregunta 3
(10 puntos)
a) Explique con un ejemplo cómo se realiza el establecimiento de una conexión en el protocolo TCP. Indique qué banderas y campos son relevantes, así como sus valores.
TCP es un protocolo orientado a conexión, lo que significa que para intercambiar datos sobre TCP previamente deberemos establecer una conexión, que nos da certeza de que del otro lado nos están
escuchando y que permitirá acordar parámetros para la comunicación. Ese establecimiento de conexión se realiza a través del llamado “three way handshake”.
Los campos relevantes en el establecimiento de conexión son las banderas SYN y ACK, y los campos de número de secuencia y número de reconocimiento. Es también relevante la bandera RST, que debe estar en cero para un establecimiento de conexión exitoso.
Cuando A desea establecer una conexión con B, debe enviar un segmento con la bandera SYN en 1, un número de secuencia X (elegido por A a partir de su reloj de tiempo real) y la bandera de ACK en 0 ya que no hay nada previo para reconocer (el primer mensaje de una conexión es el único que lleva la bandera de ACK en 0, todos los restantes la llevan en 1 ya que siempre se indica qué es lo próximo que se espera recibir).
B, si desea aceptar la solicitud de conexión, responderá con un segmento con la bandera SYN en 1, un número de secuencia Y (elegido por B), la bandera de ACK en 1 y el campo de reconocimiento con X+1, indicando que reconoce el mensaje recibido. En este punto el originador da por establecida la conexión. Es ahora el turno de que A acuse recibo del mensaje de B enviando un segmento con número de secuencia X+1 (el que B espera), la bandera de ACK en 1, el campo de reconocimiento en Y+1, la bandera de SYN toma el valor 0 a partir de este segmento y hasta el final de la conexión. Cuando B reciba este mensaje da por establecida la conexión. En estos intercambios no se envían datos de carga útil, aunque se consumen números de secuencia en los reconocimientos.
El esquema siguiente, extraído de las diapositivas del curso (Capa de Transporte TCP y UDP), ejemplifica gráficamente lo planteado:
b) La siguiente secuencia de segmentos (ordenada en el tiempo) pertenece a un tramo de una comunicación que usa el protocolo TCP. Asuma que no hay segmentos previos pendientes de reconocimiento (y que no ocurren descartes o retransmisiones). Complete los campos que faltan:
Las dos tramas iniciales nos dan la información de los números de secuencia y reconocimiento en uso. El n.º de reconocimiento en la trama 2 nos indica que B está esperando el segmento cuya carga útil comienza con el byte 400, reconociendo así haber recibido la trama 1 (números de secuencia del 350 al 399). Es decir que la siguiente trama enviada por A (trama 3) utilizará 400 como nº de secuencia. Además reconocerá haber recibido los bytes del 1020 al 1189 enviados por B, indicando que espera la secuencia 1190. Como la trama 3 no envía carga útil (es solo un reconocimiento), la siguiente trama enviada por A (trama 4) tendrá el mismo número de secuencia, y como A no recibió datos de B también será igual el nº de reconocimiento.
Por último la trama 5 tendrá como número de secuencia el que corresponde al siguiente byte que B envía, y reconoce los 150 bytes enviados por A (secuencias 400-549) indicando que espera recibir secuencia 550
Orden en
el tiempo OrigenIP DestinoIP Carga útil(bytes) Número deSecuencia ReconocimientoNúmero de
1 A B 50 350 1020
2 B A 170 1020 400
3 A B 0 400 1190
4 A B 150 400 1190
Pregunta 4
(9 puntos)
a) Explique qué se entiende por congestión en una red y por qué es importante controlarla.
La congestión en una red se da cuando en algún componente de la red (comutador, enrutador, enlace) hay un exceso de paquetes a procesar o transmitir. En general aparece en varios equipos en una zona de la red. Esto significa que la capacidad de procesamiento o de transmisión es insuficiente para despachar los paquetes que pretenden circular. Por tanto se producirán demoras adicionales (por encolamiento) y eventualmente pérdidas de paquetes.
El incremento de tiempo de procesamiento podría dar lugar a que el transmisor considere que el paquete se perdió y decida retransmitirlo. En este caso se estarían generando más paquetes de los necesarios y se contribuiría a aumentar la congestión.
Por tanto la congestión de la red es un efecto no deseado que es bueno controlar. Hay que tener en cuenta que si bien es un fenómeno no deseado, inevitablemente va a aparecer en algún momento de sobrecarga de la red, ya que sería caro dimensionar la capacidad de la red para un pico máximo que eventualmente sucede en un caso aislado.
El control de congestión tratará de evitar la congestión detectando síntomas y tomando medidas preventivas o paliativas.
b) Explique qué acciones pueden tomarse para controlar la congestión. Ejemplifique cómo pueden influir en la congestión las decisiones de diseño de las diferentes capas.
Esencialmente la congestión aparece porque hay demasiados paquetes en la red, por lo que hay muchas posibles acciones para disminuir la cantidad de paquetes en la red.
Diferentes decisiones en todas las capas del modelo pueden afectar la cantidad de paquetes en la red. A modo de ejemplo, en capa de transporte, la implementación de ventanas deslizantes con ventana de receptor igual a 1 segmento (solo se aceptan datos en orden) o ventana mayor que 1 segmento (acepto datos en desorden) afecta la cantidad de paquetes a retransmitir en caso de pérdidas. Si la ventana es 1 y se pierde un segmento, entonces el transmisor deberá retransmitir todos los paquetes que hubiera enviado a continuación del paquete perdido. Si fuera mayor que 1, entonces los siguientes a la pérdida se habrían almacenado en la ventana del receptor y no sería necesario retransmitirlos.
Otro efecto en capa de transporte puede darse con el cálculo del timeout de retransmisión. Si el ajuste no tiene una tolerancia adecuada, podría decidir retransmitir un segmento de forma temprana, sin dar tiempo a que llegue demorado.
Un ejemplo en capa de transporte puede ser el control de congestión que implementa TCP.
En capa de red, los protocolos de ruteo pueden generar más o menos información para intercambiar con sus vecinos, generando por tanto más o menos tráfico. También se pueden hacer controles de admisión (ver parte c) para evitar el ingreso de tráfico excesivo a la red.
En capa de enlace, aparecen también problemas similares a los de la capa de transporte y de modo similar, las decisiones de diseño pueden afectar la congestión.
En las arquitecturas de red de datagramas, en capa de red hay pocas herramientas para controlar la congestión por la modalidad como se encaminan los paquetes. Cuando un equipo decide el próximo salto para un destino, desconoce los eventuales problemas de congestión que hay más adelante en el camino. Por tanto, en las arquitecturas de datagramas (por ejemplo IP) el control de congestión se delega a la capa de transporte (TCP).
En las arquitecturas de red de circuitos virtuales, como antes de encaminar tráfico es necesario señalizar un camino por la red (circuito virtual, CV), los equipos por los que ese CV desea pasar pueden rechazar la solicitud de acuerdo a sus capacidades o su estado de congestión. Estas arquitecturas por tanto tienen mayores herramientas para realizar control de congestión en capa de red.
c) Explique los mecanismos de balde con goteo y balde con fichas vistos en clase. Indique de qué forma contribuyen al control de congestión.
Los mecanismos balde con goteo y balde con fichas, permiten adecuar o adaptar el tráfico que pretende ingresar a la red. La idea es que la red se dimensione para un cierto comportamiento previsto y estos mecanismos permiten controlar que el tráfico se adecue a ese comportamiento.
En el caso del balde con goteo, la idea es controlar la tasa máxima de bps que pueden ingresar a la red. Si la velocidad supera ese valor, entonces el tráfico se “aplana”, almacenándose en un buffer los datos en exceso. Dependiendo del tamaño del buffer, podrá haber o no pérdida de paquetes.
En el caso del balde con fichas, se permite acumular crédito de datos a transmitir, de modo que si la red no se usa por un tiempo se acumula crédito de datos que luego pueden salir en ráfaga. Dependiendo nuevamente de la capacidad del balde, es el pico de tráfico que se tolera en un cierto intervalo de tiempo. Ajustando los parámetros de estos mecanismos (según el caso velocidad de salida, capacidad del balde, velocidad de goteo) es posible controlar el tráfico que pretende ingresar a la red para acotarlo a cierto comportamiento, intentando que no afecte la congestión de la red.
d) Si todos los nodos de la red implementan los mecanismos descriptos en la parte c). ¿Podemos garantizar que no habría congestión? Justifique debidamente su respuesta.
Los mecanismos de la parte c) controlan que el tráfico que ingresa a la red se mantenga dentro de ciertos parámetros pero no garantizan que no se aparezcan problemas de congestión en otras partes de la red. Por ejemplo si todo el tráfico que ingresa a la red estuviera destinado a un mismo equipo, seguramente se producirían efectos de congestión en la red cercana a ese equipo destino por la superposición de tráfico proveniente de varias fuentes.
Pregunta 5
(8 puntos)
a) ¿Cómo implementa TCP el control de flujo?
Detalle el comportamiento del transmisor y del receptor.
TCP implementa el mecanismo de ventanas deslizantes para garantizar la confiabilidad de la comunicación (que todos los mensajes enviados lleguen correctamente a destino y que no haya duplicados ni pérdidas).
El objetivo del control de flujo es adaptar la velocidad de envío del transmisor a la capacidad de procesamiento del receptor. Si esto no se cumpliera, la red puede estar funcionando perfectamente pero, de igual forma se perdería información que llega al receptor pero que este no puede aceptar.
Para implementar el control de flujo, TCP cuenta con un campo de 16 bits en su encabezado para avisar el tamaño de ventana disponible WS (window size).
Cada receptor informa cuanto espacio tiene libre el buffer para recibir información en cada momento, este valor lo llamaremos Window Size del Receptor (WSR).
El tamaño del buffer asignado a la aplicación depende de la implementación. La aplicación podría solicitar un tamaño de buffer fijo o el sistema operativo podría tener la capacidad de adaptar el tamaño del buffer de forma dinámica. La asignación de buffers es importante en la comunicación, por ejemplo, al asignar buffers muy chicos, en caso de que el receptor no tenga mucha capacidad de procesamiento disponible en ese momento, si se llena el buffer puede limitar al transmisor a seguir enviando información hasta liberarse espacio en el buffer o hasta que el sistema operativo asigne un mayor tamaño.
El receptor, cada vez que recibe una TPDU devuelve un reconocimiento y además informa su WSR.
El transmisor no debe enviar más información que el WSR informado por el receptor para que no haya pérdidas.
En caso que el receptor devuelva WSR=0, el transmisor debe esperar hasta que se libere espacio en el buffer del receptor y este informe al transmisor enviando una TPDU con WSR > 0, lo que habilita al transmisor a enviar información nuevamente.
Dado que el tamaño de ventana WS en el encabezado TCP está limitado a 64 kbits (por ser un campo de 16 bits), hoy en día este valor es muy bajo para los enlaces de alta velocidad que se disponen. Por esto surge la necesidad de poder especificar valores más grandes de tamaño de ventana. Este problema se puede solucionar mediante una opción del encabezado TCP llamada Window Scale. Esta opción aparece en el encabezado TCP como un agregado de 3 bytes de información.
i. Type (1byte) = 3. ii. Length (1byte) = 3 iii. Shift.cont (1byte)
Donde Shift.cont indica la cantidad de bits de “shift” al valor indicado en el campo WS.
b) En un escenario en que la aplicación del receptor sea muy lenta leyendo la información recibida, ¿es posible que el control de flujo no habilite al transmisor a enviar información?
i) Describa lo que ocurre en el receptor y cómo se informa al transmisor.
Existen 2 casos posibles en los cuales el transmisor puede quedar bloqueado:
Caso 1- el receptor recibe los datos, se llena su buffer y la aplicación no consume estos datos
inmediatamente. En ese caso devolverá tamaño de ventana WSR = 0.
En esta situación el emisor quedará bloqueado y no podrá enviar datos hasta recibir una TPDU del receptor con WSR > 0.
Únicamente el emisor puede enviar datos sin recibir un tamaño de ventana WSR > 0 sí:
i. Quiere enviar datos urgentes. En este caso envía una TPDU con el campo PUSH de un bit en el encabezado en 1 informando esta urgencia.
ii. El emisor puede enviar un segmento con un payload de 1 byte, para forzar a que el receptor
re-anuncie su ventana WSR (que será > 0 en caso que ahora tenga buffer disponible para recibir datos). También puede enviarse una TPDU con un número de secuencia viejo (ya reconocido), TPDU que el receptor descartará por caer fuera de su ventana (ya lo había recibido) pero enviará un reconocimiento en el cual informará su nueva WSR. Estas acciones son útiles en caso de perderse una TPDU por parte del receptor informando que tiene nuevamente espacio en el buffer.
Caso 2- el emisor manda todo lo que le permitía la ventana pero aún no le llegaron los ACKs.
Pregunta 6
(8 puntos)
a) Explique en qué consiste la función de ruteo en capa 3.
La función principal de la Capa de red es lograr llevar los paquetes desde un punto de la red a otro, es decir, encontrar una ruta o camino por el cual se pueda encaminar los paquetes de datos. Esta función se puede dividir en dos funciones complementarias, la función de encaminamiento o forwarding y la función de ruteo. Decimos que son complementarias por que la función de ruteo carece de sentido si no se implementa luego una función de forwarding y la función de forwarding no puede llevarse a cabo si antes no se armarnos las rutas correspondientes.
La función de ruteo consiste en encontrar la mejor ruta por la cual encaminar luego los paquetes hacia un destino. Por definición, esta función debe darse en cada entidad de la capa 3 y puede realizarse de forma estática (las rutas se configuran manualmente) o mediante algoritmos y protocolos de ruteo dinámico. En el caso de ruteo dinámico, los equipos de red intercambian información con otros equipos de red usando algún protocolo (por ejemplo los vistos en el laboratorio: RIP y OSPF) y a partir de la información intercambiada aplican algún algoritmo para determinar los mejores caminos, reflejándolo luego en la tabla de rutas.
Las características deseables de la función de ruteo son:
- Exactitud: La función de ruteo debe dar resultados concisos para poder llegar a los destino.
- Sencillez: Los algoritmos deben ser simples para poder ser implementados en los enrutadores cargando lo menos posible su memoria y procesador.
- Robustez: Los algoritmos deben responder frente a fallas o cambios de la topología de la red sin necesidad de que el administrado tenga que operar.
- Estabilidad: la estabilidad es un aspecto fundamental de la función de ruteo. Un algoritmo estable alcanza el equilibrio y lo conserva siempre que la topología de la red no cambie.
- Equidad: En teoría, el algoritmo de ruteo debería buscar igualdad de condiciones en todos los equipos que desean comunicarse.
- Optimización: para tener en cuenta este parámetro, debemos hacerlo en base a una métrica la cual puede ser retardo, número de saltos, etc.
En muchos casos resulta imposible equilibrar todas estas características y dependerá del tipo de servicio que se quiere brindar a las capas superiores para darle más peso a un u otra propiedad.
b) ¿La función de ruteo es exclusiva de las redes de datagramas, o aparece también en las redes de circuitos virtuales? Justifique.
Tanto en arquitectura de redes basadas en datagramas como en circuitos virtuales, se necesita tener una función de ruteo en cada punto de la red de forma de establecer las rutas.
En la arquitectura de datagramas, la tabla de rutas se consulta para encaminar cada paquete (mediante la función de forwarding).
En una arquitectura de red basada en circuitos virtuales también se necesita una función de ruteo en cada enrutador para poder establecer los mejores caminos o circuitos antes de poder enviar información. Para establecer un circuito virtual se requiere enviar mensajes de señalización y establecer un acuerdo con los
nodos participantes en un circuito. Una vez establecido el circuito virtual el forwarding o encaminamiento se realiza a través de las tablas de circuitos virtuales y no se consultan más las tablas de rutas.
Si los circuitos virtuales son permanentes (no se establecen a demanda sino que se configuran administrativamente), no se necesitaría la función de ruteo en los enrutadores.
c) Compare el ruteo estático y el ruteo dinámico
Como se mencionó el ruteo puede realizarse de forma estática o dinámica.
Si es estático o no adaptativo las rutas se establecen de forma manual por el administrador de la red. En esta forma de ruteo, cualquier caída de algún nodo de la red puede dejar incomunicado a zonas distintas de la red y para retomar comunicación debería o bien reparar la falla o configurar nuevas rutas por caminos alternativos manualmente. Esto puede degradar el servicio por el lapso que lleva reconfigurar las rutas.
En los algoritmos de ruteo dinámicos o adaptativos, las rutas pueden variar en función de los cambios que ocurran en la red sin operación del administrador. Estos algoritmos pueden ser sensibles al tráfico, a cambios en la topología de la red debido por ejemplo a caídas en un servidor, a la calidad de servicio, etc.
