Tema 3. Interconexión de Redes

Transcripción

1 1 de 60 Enrique Alba Torres Universidad de Málaga (UMA)

2 2 de 60 de redes Hasta ahora hemos supuesto implícitamente que hay una sola red homogénea y que cada máquina usa el mismo protocolo en cada capa. Por desgracia este supuesto es demasiado optimista: existen muchas redes diferentes que incluyen las LAN, MAN y WAN. En cada capa hay numerosos protocolos de uso muy difundido. Existe realmente mucha heterogeneidad: más de SNAs, 2000 DECNETs e innumerables tipos de LAN. A continuación se estudiarán los problemas que surgen cuando dos o más redes se unen para trabajar, formando una interred. Es difícil que las redes individuales desaparezcan para integrarse todas en OSI, así que debe estudiarse su interconexión práctica.

3 3 de 60 de redes

4 4 de 60 de redes Las razones para que exista dicha heterogeneidad de redes son: Ya existían antes de aparecer OSI múltiples redes. IBM aún soporta redes SNA. Hay muchos estándares distintos de propósito específico. Las LANs son raramente OSI. Además, el hardware es barato, lo que contribuye a la diversidad y a que existan decisiones muy locales de compañías (no generales) que hacen necesario la interoperatividad. Ejemplos de la necesidad de interconexión de redes: LAN-LAN : Transmisión de un fichero entre dos departamentos. LAN-WAN: Transmisión remota por de un dpto. a otro. WAN-WAN: Intercambio remoto de ficheros. LAN-WAN-LAN: Dos departamentos remotos comunicándose.

5 5 de 60 de redes

6 6 de 60 de redes La unión entre dos redes tiene lugar a través de la inserción de cajas negras para gestionar los paquetes que pasan de una a otra. A estos dispositivos se les llama relays o conmutadores. Existen dos tipos de relays atendiendo al número de redes que interconectan: Bilaterales conectan directamente dos redes entre sí. Multilaterales conectan directamente varias redes entre sí. Por lo general los relays no se nombran por el número de redes que interconectan, sino por el máximo nivel OSI que tienen implementado. Así tenemos: Nivel 1 (físico) repetidores y hubs. Nivel 2 (enlace) puentes y switches. Nivel 3 (red) pasarelas, routers o encaminadores. Por encima del nivel 3 conversores de protocolo.

7 7 de 60 de redes Dos Ethernets conectadas por un switch Dos Ethernets conectadas por routers

8 8 de 60 OSI e El modelo OSI contempla la interconexión de redes a nivel de red, aunque no está bien definido, como ocurre con la seguridad. No se tomaron en cuenta las opiniones de ARPANET. CCITT también sufrió una falta de predicción asignando 4 dígitos decimales (10000 redes) para direccionamiento. OSI suponía que llegarían a existir una o dos redes públicas por país y que las redes privadas se agruparían en redes públicas mayores. Pero el mercado se ha decantado por multitud de redes distintas. El modelo OSI de la capa de red distingue 3 subcapas: Subcapa de Acceso a la Subred Subcapa de Mejora de la Subred Subcapa Interred

9 9 de 60 OSI e SUBCAPA DE ACCESO A LA SUBRED: Maneja el protocolo específico de la subred física usada. Genera y recibe paquetes de datos y control. El software está diseñado para acceder a la subred real. No hay garantías de que funcione con otras subredes. SUBCAPA DE MEJORA DE LA SUBRED: Armoniza el funcionamiento en subredes que ofrezcan servicios distintos. Presenta a la subcapa de interred un modelo uniforme de servicios.

10 10 de 60 OSI e SUBCAPA INTERRED: Conecta de forma lógica las dos subredes. Utiliza N-SAPs de manera uniforme para que los procesos de transporte que usan sus servicios se conecten. Luego se direcciona realmente dichos procesos, y no a máquinas solamente. Su principal función es el encaminamiento extremo-a-extremo. Decide el próximo enlace y cuál de entre las subredes disponibles para cada paquete. El encaminamiento es similar al presentado para una única subred. El encaminamiento jerárquico está muy indicado para grandes redes. No confundir INTERRED (internet) con la red de redes Internet. La capa de INTERRED es la más importante ya que en ella están los N-SAPs que comunican las aplicaciones con la red.

11 11 de 60 Relays Son dispositivos para la conexión de dos o más subredes de comunicación. Las conversiones de un relay son a veces imposibles de llevar a cabo. Su dificultad depende de la importancia de las diferencias entre las dos subredes. El sistema relay puede establecerse a cualquier nivel del modelo OSI en teoría, aunque en la práctica, a niveles de transporte y superiores las conversiones de protocolo son muy puntuales. Como ya se ha comentado, existen 4 tipos muy comunes de relays: REPETIDORES PUENTES PASARELAS CONVERSORES DE PROTOCOLO

12 12 de 60 Trabajan a nivel físico. Repetidores LAN 1 REPETIDOR LAN2 Con la distancia la información se distorsiona, por lo que la función básica del repetidor es restaurar la señal que le llega y retransmitirla. Amplifican señales eléctricas cuando se usan cables largos (no solo cables sino también otros medios de transmisión física). Solo copian los bits que reciben por su entrada en su salida. Por ejemplo, la temporización en del protocolo MAC permite cables de hasta 2,5 Km, pero los transceivers sólo dan potencia para 500 m. La solución es usar repetidores para aumentar la distancia.

13 13 de 60 Hay dos tipos de repetidores: Repetidores Eléctrico: transforma de voltaje en voltaje (une dos coaxiales). Optoeléctrico: alguno de sus extremos es de fibra. El uso de repetidores a la hora de interconectar redes necesita de varias consideraciones: Saturación: si se unen dos redes muy saturadas mediante un repetidor, la red única que surge está mucho más saturada (problemas de tráfico intenso). Seguridad: acceso potencial de nuevos usuarios. Incompatibilidad: no es posible introducir un repetidor para unir redes que utilizan protocolos diferentes, ya que cada protocolo requiere unos timeouts y unos requisitos físicos de funcionamiento determinados, amén del formato de los paquetes.

14 14 de 60 También se les llama bridges. Tienen implementado hasta el nivel de enlace de datos. Son dispositivos de almacén y envío. Aceptan una trama de una subred, la pasan al nivel de enlace para verificar checksums y la devuelven a la capa física para envío a la otra subred. Por lo tanto son dispositivos más lentos que los repetidores, pero no se dedican únicamente a retransmitir la información, tienen más software que los hace más versátiles. En el nivel de enlace pueden hacerse algunos cambios en las cabeceras de las tramas, pero no se conocen ni usan las cabeceras de nivel de red para nada. Mediante puentes es posible interconectar redes que utilizan protocolos diferentes.

15 15 de 60 Pero también plantean varios problemas: Puede haber problemas con los timeouts. Los paquetes pueden tardar más tiempo del esperado para llegar a su destino, con lo que puede expirar el timeout de un paquete antes de llegar en la nueva interred y no porque se haya perdido. El principal problema es la conversión de tramas de forma coherente entre protocolos si las redes que se interconectan son distintas. En cuanto a la seguridad no presentan problemas, ya que los puentes tienen capacidad de filtrar información. En la práctica los puentes actuales pueden realizar tareas avanzadas como compresión o encriptación, típicas de niveles superiores (p.ej. 6), pero se requieren aplicaciones nuevas y que el hardware sea de la misma empresa.

16 16 de 60

17 17 de 60 Trabajan a nivel de red. Algunos autores llaman gateway a un relay que trabaja a cualquier nivel OSI y router a un gateway a nivel de red. Para nosotros gateway y router es lo mismo. Las subredes conectadas por un gateway pueden ser mucho más distintas entre sí que usando un puente, ya que a nivel de red es donde se encuentran las mayores diferencias entre redes. Se pueden hacer conversiones sofisticadas, e incluso hay alternativas para conectar redes distintas sin hacer conversiones. Una decisiva ventaja sobre el puente es que una pasarela puede conectar redes con formatos de direccionamiento distinto, como por ejemplo una LAN 802 con direcciones binarias de 48 bits y una red X.25 con direcciones X.121 decimales de 14 dígitos. Las pasarelas son en general más lentas que los puentes.

18 18 de 60 Conversores de Protocolo Trabajan a nivel de transporte o superior. Se suele hablar de conmutación de transporte frente a conmutación de nivel 3, por ejemplo. Su trabajo es mucho más complejo que el de un gateway: puede convertir entre dos protocolos sin perder mucho significado. Como ejemplos, la conversión de TP4 (OSI) a TCP (Internet), la conversión MOTIS (OSI) a RFC 822 (Internet), etc... El trabajo de un conversor es en general a nivel de aplicación entre dos estándares distintos, y no se hacen traducciones genéricas entre entidades de protocolos genéricas.

19 19 de 60 Puntos Conflictivos en el Diseño de Cada LAN usa su propio formato de trama (o marco). No existe ninguna razón técnica para la incompatibilidad, sólo que las tres grandes compañías que soportan tres grandes estándares (Xerox, General Motors e IBM) no cambian el suyo ni cooperan. Esto supone que los puentes consumirán CPU y memoria en los cambios de formatos, checksums, etc., y pueden aparecer errores no detectados debidos a bits erróneos en la memoria del puente. Un problema más serio es el del ancho de banda diferente de las diferentes redes, por ejemplo: (ethernet) 1, 10, 1000, 1000 Mbps (token bus) 1 a 10 Mbps (token ring) 1, 4, 16 y 100 Mbps Esto supone que si se conecta una o a una el puente deberá retener los datos en buffers porque no puede entregarlos tan rápido (contención y problemas de memoria).

20 20 de 60 Puntos Conflictivos en el Diseño de Un problema sutil son los temporizadores. Si una envía un mensaje largo a una y espera confirmación el retraso en el puente por la menor velocidad de la (según el estándar) puede hacer saltar la temporización y retransmitir. Tras múltiples intentos abortará la transmisión e informará a la capa de transporte de destino muerto. Es posible también en los gateways. Además, los tres principales tipos de la 802 tienen una máxima longitud de trama diferente: bytes (estándar a 10 Mbps) bytes bytes (si MTHT es 10 ms) Si la trama de una red es demasiado larga para el destino hay respuesta en los protocolos 802 sobre si se puede o no, o cómo fragmentar en tramas más pequeñas. En general las tramas son unidades indivisibles y una trama excesivamente larga puede ser un problema sin solución.

21 21 de 60 Puntos Conflictivos en el Diseño de En aras de la transparencia se debería descartar este tipo de transmisiones interred demasiado largas (aunque el problema sí que tiene solución en la práctica a veces). Esto es así porque todos los protocolos asumen que una trama llega o no llega (no se contempla una llegada parcial). remotos: variante para conectar LANs dispersas geográficamente. Se usa un protocolo punto a punto como PPP (túnel, ideal si las redes son iguales entre sí) o bien un traductor (que elimine/genere cabeceras/colas).

22 22 de 60 IEEE 802.x a 802.y Se podría pensar que diseñar un puente entre una LAN 802 y otra es algo trivial, pero esto no es así. Cada una de las 9 combinaciones de 802.x a 802.y (para x/y=3, 4, 5) tiene su propio grupo de problemas: a 802.3: En si una estación quiere transmitir tiene que chequear antes el canal para comprobar que no haya nadie transmitiendo y monopolizar la transmisión para asegurarse de que no haya colisiones. Si el puente no puede transmitir porque la red destino está muy saturada puede agotar su memoria, lo que supone que se descartarán tramas. Siempre puede ocurrir cuando se envía a una (no se volverá a mencionar). Con y las estaciones y el puente tienen asegurada la obtención del token y una retención de este tipo no es un problema. A los puentes que trabajan con Ethernet se les suele poner un suplemento de memoria.

23 23 de a 802.3: IEEE 802.x a 802.y Las tramas contienen bits de prioridad que no existen en las Esto supone que si dos se comunican a través de una estos bits pierden su sentido. Lo que se hace con ellos es ignorarlos pero esto traerá consecuencias en la transmisión: - Cuando la trama pasa de la a la se pierden los bits de prioridad. - Entonces, al pasar de la a otra hay que volver a generarlos, y la solución más usada es poner una prioridad alta. El uso de tokens temporales en la (trama con bit de token a 1 que viaja al destino para permitirle confirmar) hace que un puente no sepa qué hacer: si le confirma la entrega al origen es mentira porque el destino podría estar muerto, y si no se la confirma probablemente el origen informará a la capa superior de que el destino está muerto. No parece tener solución.

24 24 de a 802.3: IEEE 802.x a 802.y Las tramas tienen los bits A y C en el campo de estado del marco (frame status) que el destino debe rellenar para indicar al origen si se direccionó bien la trama y si el destino la copió. El puente podría confirmar ambos, pero si el destino está realmente muerto habría un gran problema: en todo caso el puente cambia la semántica a 802.4: El problema es qué valores usar para los bits de prioridad. Una solución, como ya se ha comentado, es que el puente retransmita a la mayor prioridad posible porque las tramas que le llegan ya han sido retrasadas considerablemente.

25 25 de a 802.4: IEEE 802.x a 802.y El problema es el préstamo temporal del token, pero si el puente retransmite a la mayor prioridad posible puede que el destino confirme antes del timeout a 802.4: Los problemas son los bits A y C y además que las definiciones de prioridad son distintas ( al menos existen bits de prioridad en ambas!). El puente puede copiarlos unos en otros y rezar para que funcione el cambio (!) a 802.5: El puente debe inventarse los bits de prioridad para la 802.5

26 26 de a 802.5: IEEE 802.x a 802.y Los problemas son potenciales respecto a la transmisión de tramas muy largas. Además está el problema del préstamo temporal del token a 802.5: El problema es el del manejo de los bits A y C.

27 27 de 60 IEEE 802.x a 802.y Destino Origen Agotar memoria Agotar memoria Eliminar bits de prioridad Generar bits de prioridad (alta) Préstamo temporal del token Temporizadores Generar bits de prioridad (alta) Bits A y C Préstamo temporal del token Temporizadores Préstamo temporal del token Temporizadores Tramas muy largas Agotar memoria Bits A y C Tramas muy largas Bits A y C Bits A y C Eliminar bits de prioridad Eliminar bits A, C Bits de prioridad Tramas muy largas

28 28 de 60 Tipos de Cuando el comité IEEE 802 se sentó a diseñar un estándar LAN realmente produjo 3 estándares incompatibles. Al reunirse para diseñar un estándar para puentes mejoró notablemente y produjeron solo 2 estándares incompatibles. Hasta el momento nadie le ha pedido que diseñe un estándar para conectar con gateways sus dos tipos de puentes incompatibles. El acercamiento de la IEEE para interconexión de un gran número de redes con múltiples puentes consiste en usar uno de entre dos tipos distintos de puentes:

29 29 de 60 PUENTES TRANSPARENTES: Tipos de Apoyados por las compañías del CSMA/CD y de Token Bus. Su objetivo es la facilidad de instalación y uso. Se conectan dos LANs únicamente introduciendo un puente de este tipo en medio. No se requiere configuración hardware ni software y las estaciones no son conscientes de su presencia. PUENTES POR ENCAMINAMIENTO FUENTE: Apoyados por IBM y otras compañías que usan topología en anillo. Su objetivo es hacer un uso óptimo del ancho de banda (lo que no ocurre en los puentes transparentes, por no usar toda la topología de la red).

30 30 de 60 Transparentes Operan en modo promiscuo: aceptan cualquier trama desde cualquier LAN a la que estén conectados. Para cada paquete debe decidirse si descartarlo o enviarlo, y si hay que enviarlo, por qué LAN hacerlo. El proceso de enrutamiento de cada trama de entrada depende de la LAN por la que le llega y de la LAN en la que está su destino: Si la LAN destino es la misma que la LAN origen se descarta la trama. Si la LAN destino y la LAN origen son distintas se envía la trama. Si la LAN destino es desconocida se usa el proceso de inundación, reenviando la trama por todas las LANs excepto por la de origen.

31 31 de 60 Transparentes Disponen de una tabla hash para asociar a cada nodo destino una de sus LANs de salida y utilizan el Algoritmo de Aprendizaje Hacia Atrás (Baran): Cuando a un puente le llega una trama consulta su dirección de origen y anota en su tabla la línea por la que le llegó. Esto lo hace para saber que es por dicha línea por donde se alcanzará al nodo que envió ese paquete y así enviar por ahí todos los paquetes cuyo destino sea dicho nodo. Cuando llega una trama con destino desconocido, es decir, con un destino que no está en su tabla (por ejemplo recién conectado el puente), utiliza inundación para encaminarla. Una vez que el nodo destino recibe la trama envía una confirmación y el puente asocia en su tabla el destino y la línea por la que llegó la confirmación. Es decir, cualquier nodo que transmita algún mensaje es localizado por el puente, que lo introduce en sus tabla para saber por qué línea tiene que enviar paquetes para dicho nodo.

32 32 de 60 Transparentes Como la topología de la red puede cambiar a medida que las máquinas y los puentes se encienden, se apagan o se mueven, para manejar topologías dinámicas cada vez que se anota una entrada en la tabla se anota también el tiempo actual. Cada vez que llega una trama cuyo origen ya está en la tabla se actualiza su entrada con el nuevo tiempo. Por tanto el tiempo asociado a cada entrada indica la última vez que se vió una trama de esa máquina. Periódicamente, el puente elimina las entradas de la tabla que tienen más cierto tiempo. De esta manera se actualizan los caminos ya que si una máquina se desconecta de su LAN el puente lo dará de baja en próximas purgas. Así se adapta el contenido de la tabla a la topología de la red y se reduce el tamaño de su tabla. Sin embargo, esto supone también un inconveniente ya que si una máquina se queda muda (sin enviar ningún mensaje) durante un tiempo, cualquier tráfico enviado a ella tendrá que pasar por el proceso de inundación, hasta que ella misma envía de nuevo.

33 33 de 60 Transparentes Por seguridad o eficiencia, se pueden usar puentes paralelos, aunque esto provoca problemas de bucles. Para evitarlo, todos los puentes se organizan en árbol abarcando todas las LANs. De esta manera se evitan ciclos al existir un único camino origen-destino. Para construir el árbol se elige un nodo raíz (por ejemplo el puente cuyo número de serie sea menor) y cada puente difunde su identidad y los puentes que conoce conectados también a sus LANs. El árbol se construye haciendo que los paquetes elijan el camino más corto a la raíz. No todos los puentes estarán en el árbol necesariamente (uso subóptimo de recursos). El algoritmo se ejecuta con periodicidad para detectar cambios en la topología. El algoritmo para la construcción del árbol presenta problemas de escala en grandes redes (por ejemplo, telefónicas). Si dos grupos de LANs se comunican por puentes conectados por una WAN el algoritmo necesita que se optimice su ejecución para minimizar los paquetes necesarios a transmitir sobre la WAN.

34 34 de 60 Transparentes transparentes en paralelo

35 35 de 60 por Encaminamiento Fuente Los puentes por encaminamiento fuente hacen un uso más eficiente de la red, ya que mejoran el uso del ancho de banda frente a los transparentes que usen un árbol. Se asume que cada emisor sabe si el destino está o no en su LAN. Cuando envía una trama a una LAN distinta activa el bit más significativo de la dirección destino e incluye en la cabecera la ruta exacta que la trama debe seguir. El camino se construye como una sucesión puente-lan-puente... donde cada LAN tiene un identificador único de 12 bits y cada puente otro de 4 bits pero único sólo en su LAN (otro puente en otra LAN puede tener el mimo identificador). Un puente sólo se interesa por las tramas cuyo MSB (bit más significativo) de la dirección destino está a 1. Entonces busca en la ruta de la trama el número de LAN por la que llegó. Si tras éste le sigue su propio número de puente entonces comprueba cuál es la siguiente LAN y la pasa a ésta; si no, la ignora.

36 36 de 60 Implementaciones posibles: por Encaminamiento Fuente SOFTWARE: Modo promiscuo. Copia todas las tramas a su memoria para comprobar si su MSB está a 1. Si es así sigue inspeccionando la trama. En caso contrario la ignora. HÍBRIDO: La interfaz (hardware) a la red del puente inspecciona el MSB y le entrega la trama sólo si está a 1. Esta interfaz reduce en gran medida el número de inspecciones que tiene que realizar el puente. HARDWARE: La interfaz además de comprobar el MSB también busca en la ruta para ver si su puente asociado está en ella. Sólo le entrega la trama si este puente debe retransmitir. Ahorra mucho tiempo de CPU. La implementación software requiere poco hardware pero la CPU debe ser rápida, mientras que la implementación hardware funciona con una CPU más lenta pero necesita circuitos adicionales (además podría manejar más LANs).

37 37 de 60 por Encaminamiento Fuente Para conocer cualquier camino que necesite un nodo debe difundir una trama de descubrimiento que los demás nodos difunden a su vez. Cuando la respuesta desde el destino vuelve cada puente anota su identidad. El origen recibirá muchos caminos distintos y elegirá el mejor de entre ellos según su criterio. Aunque se asegura encontrar la mejor ruta ( se exploran todas!) la explosión en el número de tramas difundidas provoca congestión en el sistema. Algo parecido ocurre en los puentes transparentes, pero su explosión es lineal y no exponencial respecto al número de nodos en la red, como ocurre aquí. Las rutas hacia los distintos destinos se almacenan en cachés en los hosts para limitar esta explosión, pero en todo caso supone consciencia en los hosts de la existencia de los puentes, problemas de administración, y por supuesto esto dista mucho de ser transparente.

38 38 de 60 Comparación entre IEEE 802 CONCEPTO TRANSPARENTE ENCAMINAMIENTO FUENTE Orientación Transparencia Configuración Sin conexión Totalmente Automática Orientado a la conexión No transparente Manual Encaminamiento Localización Fallos Subóptimo Aprendizaje hacia atrás Manejados por el puente Óptimo Tramas de descubrimiento Manejados por los hosts Complejidad En los puentes En los hosts

39 39 de 60 Comparación entre IEEE 802 TRANSPARENTES Invisibles a los hosts y compatibles 802 Se adaptan a la topología Usan sólo un árbol entre los puentes Problema: localización inicial del nodo Manejan fallos sin que los hosts lo sepan ENCAMINAMIENTO FUENTE Ni invisibles ni compatibles Difíciles de instalar y administrar Encaminamiento óptimo y distribución de carga Problema: explosión exponencial de tramas de descubrimiento Si cae un puente la detección es lenta y cara computacionalmente

40 40 de 60 Comparación entre IEEE 802 Los puentes por encaminamiento fuente sin uso de hardware inteligente tienen un alto tiempo de proceso por paquete. Además complican a los hosts en el almacenamiento, descubrimiento y manejo de rutas, consumiendo sus tiempos de CPU. Ya que típicamente existe un número de hosts varias órdenes de magnitud mayor que el número de puentes parece mejor poner la complejidad y el coste extra en los puentes y no en todos los hosts. Por esta razón el funcionamiento transparente es muy valorado hoy en día, siempre que la red y las aplicaciones permitan su uso frente a encaminamiento fuente.

41 41 de 60 (Gateways) Las pasarelas o gateways operan a nivel de red, mientras que los puentes operan a nivel de enlace. Son más flexibles que los puentes y pueden realizar conversiones entre formatos de dirección de redes distintas. Sin embargo, son más lentos que los puentes debido a que necesitan un mayor volumen de cálculos. Los puentes se utilizan de forma interna en las organizaciones, mientras que las pasarelas son los puntos de salida al exterior. Se suelen usar en WANs donde nadie espera que manejen paquetes por segundo ni velocidades similares y el retraso es admisible. Una WAN es usualmente concebida como una red de pasarelas.

42 42 de 60 Gateways Orientados a la Conexión: (Gateways) Todos los paquetes con un mismo origen y destino pasan por las mismas pasarelas (quizás no por los mismos nodos intermedios). Gateways Sin Conexión: Los paquetes con un mismo origen y destino no tienen por qué pasar por las mismas pasarelas (diferentes rutas, como Internet).

43 43 de 60 Gateways Orientados a la Conexión Pensados para el modelo OSI de Internetworking: Concatenación Orientada a la Conexión de redes que usan Circuito Virtual. Los CVs son a nivel de red (en puentes es a nivel de enlace). Un puente puede manejarse fácilmente por parte del propietario de la LAN, pero un gateway que conecte a dos WANs de distintos países provoca problemas de gestión. La solución es dividirlo en dos medios-gateways separados por un cable. El único conflicto es acordar el protocolo a usar en dicho cable. Cada organización maneja su mitad como más le convenga. Un protocolo típico sobre cable entre medios-gateways es X.75 (CCITT) que es casi idéntico a X.25, basado en la idea de CVs concatenados interredes. ESPAÑA Semi-Gateway Gateway X.75 Semi-Gateway FRANCIA

44 44 de 60 Gateways Orientados a la Conexión El establecimiento de CVs interred es similar al normal intrarred. Los semi-gateways eligen al próximo semi-gateway al que enviar el paquete de setup del CV, así hasta alcanzar el host remoto. Los gateways al reenviar un paquete cambian apropiadamente el número de CV y realizan los cambios de formato necesarios. Todos los paquetes de datos atravesarán la misma secuencia de gateways a menos que los CVs se implementen internamente usando datagramas. En la práctica las redes que usan CVs entre redes también los usan internamente. El proceso de uso es como el visto para CVs intrarred pero, como ya se ha comentado, sólo es fija la secuencia de gateways y no necesariamente la secuencia de IMPs. Cuando se conectan dos redes con X.25 el host conecta con la subred en X.25.

45 45 de 60 Gateways Orientados a la Conexión El protocolo interno IMP-IMP no se especifica en CCITT y probablemente sea distinto para cada subred. La misma libertad tienen los gateways para comunicar con el resto de la subred pero las opciones son claras: Usar el mismo protocolo que IMP-IMP (gateway como IMP). Usar X.25 (gateway como host). Aunque el protocolo X.75 sólo se usa en líneas gateway-gateway dicta la arquitectura de CVs concatenados, al requerir que todos los paquetes de una conexión pasen por el mismo CV entre gateway y gateway.

46 46 de 60 Gateways Sin Conexión Usados en el modelo CCITT de redes conectadas por datagramas (servicio sin conexión). En el viaje de un mensaje al pasar por diferentes pasarelas la capa de transporte podría subdividirlo en datagramas (si es demasiado largo) siendo su homónima en el destino la que los reensambla. Para pasar de una red a otra (de gateway a gateway) cada gateway enmarca la trama con la cabecera (header) y cola (trailer) a nivel de enlace de datos apropiadas para la red en que lo deposita, tras despojarla de los correspondientes a la red de la que la recibe. Cada red le impone un tamaño máximo a los paquetes. Causas: Hardware: anchura del slot de transmisión TDM. Sistema Operativo: todos los buffers son de 512 bytes de tamaño. Protocolos: nº de bits dedicados a la longitud del paquete. Cumplir con un estándar: nacional o internacional. Deseo de reducir el error: incluir retransmisiones a algún nivel. Evitar que un paquete ocupe el canal demasiado tiempo.

47 47 de 60 Gateways Sin Conexión Los diseñadores no son libres de elegir su propio tamaño máximo, por ejemplo: HDLC: 802.4: X.25: bits bits ARPA (radio): ARPANET: ETHERNET: bits bits bytes Cuando un paquete grande debe viajar por una red cuyo tamaño máximo por unidad de transferencia (MTU) es demasiado pequeño surgen nuevos problemas que se deben solucionar. Soluciones propuestas: Evitar que se presente la situación. La interred podría usar un algoritmo de encaminamiento que permitiese evitar pasar paquetes grandes por redes que no puedan manejarlos. Pero si la red destino es de este tipo es imposible enviar en paquete. Se puede minimizar el problema pero no evitarlo totalmente. La solución real práctica casi única es que los gateways puedan partir los paquetes en fragmentos y enviarlos como paquetes separados. Sin embargo fragmentar es considerablemente más simple que desfragmentar.

48 48 de 60 Comparación entre Gateways OC y SC VENTAJAS : Circuitos Virtuales Concatenados Se puede prevenir la congestión por preasignación de buffers en los gateways Se garantiza secuenciamiento Se pueden usar cabeceras cortas Se pueden evitar problemas causados por paquetes duplicados retrasados Datagramas Adaptación fácil ante problemas por congestión Puede usarse en redes que no tienen CVs Robustos frente a fallos en los gateways Es posible usar una gran variedad de algoritmos de encaminamiento adaptativo

49 49 de 60 Comparación entre Gateways OC y SC INCONVENIENTES : Circuitos Virtuales Concatenados Espacio reservado en tablas de encaminamiento para cada conexión abierta aunque no se usen No hay rutas alternativas para hacer CdC Vulnerabilidad ante fallos en los gateways Difícil de implementar si hay una red datagrama Datagramas Mayores encabezamientos Mayor probabilidad de congestión

50 50 de 60 Tunneling, una solución muy usada

51 51 de 60 Tipos de Existen dos tipos de fragmentación: (a) TRANSPARENTE No visible para el host destino (b) NO TRANSPARENTE Visible para el host destino

52 52 de 60 Tipos de TRANSPARENTE: La fragmentación en una red es transparente a las demás redes que deba atravesar. El gateway que fragmenta envía todos los fragmentos a un mismo gateway destino y éste se encarga de recomponerlos. Las demás redes no perciben la fragmentación realizada. Es simple, aunque problemática: - El gateway destino debe saber cuándo tiene todos los fragmentos (esto supone usar un contador o bit de fragmento final). - Todos siguen la misma ruta hacia el gateway destino y eso puede ser ineficiente. Es posible que el gateway destino presente bloqueo por reensamblado. - Sobrecarga por las sucesivas fragmentaciones y composiciones al pasar por varias redes de pequeña MTU.

53 53 de 60 Tipos de NO TRANSPARENTE: Solo reensambla el host destino. Los fragmentos se manejan como si fuesen paquetes originales. Una ventaja es que podrían utilizarse rutas a diferentes gateways de salida de la subred, aunque si el modelo usado es el de CVs concatenados esta mejora no puede utilizarse. Los problemas asociados son: - Se exige que cualquier host pueda reensamblar. - Cada fragmento aumenta la sobrecarga por aparición de nuevas cabeceras que permanecen todo el viaje del paquete.

54 54 de 60 Algoritmos de Shoch (1979): - Cada paquete lleva un bit indicando si el destino es capaz o no de reensamblado. Si es así cada gateway puede elegir si usar fragmentación transparente o no. Si el destino no puede reensamblar, cada gateway debe hacer que el siguiente gateway reensamble los fragmentos. - Un bit similar debe usarse en la práctica para definir al menos el último fragmento. La numeración de los segmentos debe permitir su reensamblado. Hay dos grandes soluciones distintas: - Numeración en árbol - MTU elemental

55 55 de 60 Algoritmos de Numeración en árbol: El paquete X se fragmenta en trozos numerados X.0, X.1, etc... Si el fragmento X.0 se vuelve a fragmentar se le numera X.0.0, X.0.1, etc... Si hay espacio en la cabecera para el peor caso y no se generan duplicados esta solución asegura el reensamblado correcto (no importa el orden de llegada). Una pequeña desventaja es que el tamaño de la numeración es variable según el camino que siga el paquete, y por lo tanto hay que dejar espacio suficiente en la cabecera. Además, si alguno de las fragmentos llega mal al destino habría que retransmitir el paquete completo, y como no todos los paquetes van por el mismo camino dentro de la red, puede que lleguen los paquetes duplicados o incluso paquetes con la misma numeración y distinto contenido.

56 56 de 60 Algoritmos de MTU elemental: Se elige un tamaño básico de MTU que pase por cualquiera de las interredes. Al fragmentar, todos los paquetes son de dicho tamaño menos el último que puede ser menor. Un paquete podría contener varios de estos fragmentos por eficiencia de envío. La cabecera debería contener el número del paquete original, así como el número del primer fragmento contenido en el paquete. Debe existir un bit en el paquete indicando que el último fragmento elemental contenido en la trama es (o no) el último de los fragmentos originales. Por ejemplo, tenemos el siguiente paquete de 10 bytes para MTU=8 (sólo payload en este ejemplo, es decir, carga útil), por lo que habría que fragmentarlo: Cabecera Datos (10 bytes) A B C D E F G H I J Nº del paquete Bit de fin de paquete Nº del primer byte de datos Fragmentos: A B C D E F G H I J

57 57 de 60 Algoritmos de MTU elemental: Se requieren dos números de secuencia en la cabecera de los paquetes interred. El primer campo indica el número de datagrama original y el segundo el offset dentro de él. En el límite, un fragmento elemental es un bit o byte. Algunos protocolos interred llevan este método más lejos y consideran toda la transmisión por un CV como un paquete gigante y cada fragmento recibe el número absoluto de byte del primer byte en el fragmento.

58 58 de 60 para y El software es muy distinto del usado en los hosts. La eficiencia es imprescindible. Los puentes y pasarelas están limitados por CPU. Las interrupciones son rápidas, pero dan lugar a software mal estructurado, por lo que sólo se usaron al principio de las comunicaciones. Lo ideal es planificar procesos que estarán dormidos esperando sobre colas de trabajos a realizar, y cuyos resultados encolan en sus salidas, que serán a su vez la entrada de otros procesos. Cada proceso tiene su propio espacio de direcciones. Los procesos que atienden a las entradas deben tener la mayor prioridad posible para evitar perder paquetes de entrada cuando estos lleguen. Los procesos de salida tienen prioridad intermedia y los de encaminamiento la menor prioridad. Estos últimos cogen paquetes y determinan su ruta poniéndolos en la cola de algún proceso de entre los de salida. También filtra: si el paquete es de control o bien su destino es la misma red que su origen no lo encola: lo ignora. Si hay procesos de estadísticas suelen recibir la menor de todas las prioridades. Si hay procesos de gestión, normalmente se les asignan la mayor prioridad posible para una gestión eficiente e inmediata.

59 59 de 60 para y La orientación a procesos está bien estructurada pero es lenta por los cambios de contexto entre diferentes procesos. Una solución de compromiso es que los procesos compartan el mismo espacio de direccionamiento al correr todos en modo kernel (núcleo). Para un SO de propósito general esto es imposible, pero en un gateway se supone que los procesos están bien definidos y vale la pena perder seguridad frente a las ganancias en velocidad y eficiencia. El algoritmo de planificación en un gateway es crítico. Mejor que round-robin es dejar que los procesos terminen para evitar tener que guardar el contexto (costoso). El sistema sólo necesitaría una pila global (no una por proceso). La ejecución de procesos por prioridad también puede ser cara y podría considerarse que al terminar cada proceso hiciese un polling de las interfaces de red y marcase los procesos que podrían ejecutarse a partir de ese momento. El planificador elegiría el de mayor prioridad para ejecutar en cada momento.

60 60 de 60 para y La comunicación entre procesos también es crítica. Copiar mensajes de una cola a otra es inaceptable: deben pasarse punteros. El problema es que el proceso que los pasa no sabe cuándo liberar el buffer y es el receptor del mensaje el que debe liberarlos o reutilizarlos. Este problema se agrava por el hecho de que los paquetes pueden cambiar de tamaño y además deben pasar por varias capas software. Una solución es leer el paquete no desde el principio del buffer, sino a una distancia igual a la cabecera más larga posible. En todo caso se utilizan siempre buffers de tamaño constante. Problemas adicionales: temporizadores y cambios de orden en los bytes.