TEMA 1 Introduccin a las Redes-

1.1 Hardware de Redes

- Modelos generales de red: modelo Cliente-Servidor, y modelo P2P (peer to peer, de igual a igual), el cual consistira en una especie de Cliente-Servidor Dinmico donde cada equipo puede ser cliente y servidor a la vez. - Descentralizacin de la computacin, a lo cual contribuyo la evolucin de las telecomunicaciones.

1.1.1 Clasificacin:
* Canal de transmisin: 1) Redes de difusin (Broadcast), un nico canal de transmisin. Todas las maquinas conectadas a dicho canal recibirn el paquete, pero tan solo lo procesaran, aquellas a las que vaya dirigido. Para indicar a que maquinas va direccionado nuestro paquete, se introduce un cdigo determinado en el campo de direccin del paquete. Broadcasting (difusin), cuando un paquete es procesado por TODAS las maquinas. Multicasting (multidifusin), el paquete es enviado a un SUBCONJUNTO de maquinas. Topologa: Hay dos tipos de redes de difusin, las de Bus (cable conectado a todas las maquinas de nuestra red. Sistema rpido -10 Mbps a 10 Gbps- y de coste medio. Por ej. Ethernet, Token Bus, etc.), y las de Anillo (los equipos se conectan de forma circular, cada nodo esta unido a otros dos nodos. La informacin que deseamos transmitir circula a travs del anillo hasta llegar a su destino. Los bits que conforman el paquete que deseamos enviar, empiezan a circular por el anillo, sin esperar a que se hayan transmitido los dems bits restantes del paquete. Se trata de un sistema lento 16 Mbps- y caro. Por ej. Token Ring.) No obstante, tambin podemos clasificar las redes de difusin, adems de por su topologa, por el mtodo de asignacin de canal usado (que mquina debe transmitir informacin en cada momento, para evitar el caos en la red): Esttica, dividimos el tiempo en intervalos y asignamos a cada mquina un tiempo durante el cual podr transmitir informacin si as lo desea. El gran problema de este mtodo, es el tiempo desaprovechado en caso de que durante el turno de una maquina esta no desee transmitir nada. Dinmica, la asignacin dinmica consiste en asignar el canal de transmisin bajo demanda, segn vayan pidindolo las maquinas que deseen transmitir. Para evitar el caos debemos gestionar dichas peticiones, hay dos mtodos para ello, el centralizado, disponemos de una entidad dedicada exclusivamente a arbitrar las distintas peticiones, escogindolas en base a distintos algoritmos y decisiones, y el descentralizado, donde no disponemos de dicha entidad central, sino que cada equipo de la red debe decidir por s mismo cuando es el momento adecuado para ponerse a transmitir, existen distintos algoritmos para ello.

2) Redes punto a punto (Unicast), varios canales de comunicacin interconectados entre s. A menudo, el paquete deber pasar por varias maquinas hasta llegar a su destino final. Unicasting (unidifusin), transmisin de un paquete de punto a punto.

* Tamao/Cobertura: 1- Red de rea Personal (PAN). Por ej. Una impresora inalmbrica que conecta con un equipo. 2- Red de rea Local (LAN). stas, al estar limitadas por su tamao, se tratar de un dato que conoceremos con toda seguridad, y sabiendo el tamao de la red nos ser til para su diseo y clculo del tiempo de transmisin de los paquetes. El tiempo de retardo en este tipo de redes es muy bajo. Tambin existen redes de difusin basadas en LAN, como es la red Ethernet (red de difusin, con topologa bus, y con control de transmisin dinmico y descentralizado). Por ej. Piso, Edificio, Aeropuerto, etc. 3- Red de rea Metropolitana (MAN). Por ej. Televisin por cable en una ciudad. Una antena nica, conectada a cientos de hogares, tambin se poda aprovechar el cableado para proporcionar Internet. O WiMAX, una MAN fija inalmbrica. 4- Red de rea Amplia (WAN). Una WAN est formada por una subred y un conjunto de hosts conectados a una LAN. Una red WAN podra verse como un conjunto de redes ms pequeas (LAN) que para intercambiarse informacin entre s hacen uso de subredes. Las subredes estn formadas por un conjunto de enrutadores y lneas de transmisin (cable, fibra ptica, radiofrecuencia, etc.), cada enrutador est conectado a distintas lneas de transmisin, y debe encargarse de conectar una lnea de entrada determinada, con su correspondiente lnea de salida. Dentro de la subred existen multiples caminos posibles que pueden tomar nuestros paquetes, para elegir el adecuado los enrutadores usan distintos algoritmos de enrutamiento. Los hosts no forman parte de esta Subred, la subred solo contiene enrutadores y lneas de transmisin. Cuando un Cliente de una LAN enva una peticin a un Host conectado a esa misma LAN, y ste, para procesar la peticin requiere comunicarse con otro Host de otra LAN, usa la Subred para transferirle dicha peticin al segundo host requerido. Hay dos tipos de WANs, las de conmutacin de paquetes (aquellas donde el paquete se almacena en cada enrutador hasta que la lnea de salida necesaria este libre) y las satelitales (donde cada enrutador est equipado con una antena que le permite comunicarse con un satlite en rbita, y ste, es el que decide a que otro enrutador transferir la informacin recibida. Es decir, no hay una conexin punto a punto entre enrutadores, aunque tambin existe la posibilidad de combinar ambos aspectos). Por ej. Televisin por satlite con cobertura de un pas entero.

5- Internet. Cobertura del planeta entero. * Interred: Conexin de dos o ms redes (Por ej. Internet).

1.1.2 Redes Inalmbricas

Nacidas de la idea de telgrafo inalmbrico de Marconi, y a partir del cual tambin nacera la radio, y toda una serie de tecnologa inalmbricas. Las redes inalmbricas tienden a usarse para: 1) Conectar dispositivos entre s. Por ej. Un ratn o teclado inalmbricos que conectan por Bluetooth con la unidad central. Se tratara de un tipo de red PAN (Red de rea Personal) Inalmbrica. 2) Crear LANs Inalmbricas. Cada equipo est dotado de una antena emisora y receptora, y puede comunicarse con otros equipos de forma directa, de igual a igual, si ambos estn cerca, o mediante el uso de una antena central y de mayor potencia, para realizar de vnculo entre ambos equipos, en el caso de que estos se encuentren lejos. 3) Crear WANs Inalmbricas. Semejantes a las LANs inalmbricas pero a gran escala. Hoy en da existen WANs inalmbricas con bajo ancho de banda, como son las redes de telefona celular las cuales interconectan miles de telfonos mviles entre s, pero que debido a la gran distancia existente entre el emisor y el receptor las velocidades de transmisin son bastante bajas. Y WANs inalmbricas con alto ancho de banda, como por ej. La tecnologa WiMAX. La mayora de redes inalmbricas en algn punto acaban conectndose con una red almbrica, ya sea para extender ms fcilmente la red, o para proporcionar acceso a Internet a sta.

1.1.3 Subredes, Redes e Interredes

A menudo se confunden los trminos subred, red e interred. Por interred debe entenderse una red formada por un conjunto de redes interconectadas entre s. Dichas redes deben de ser independientes y de comportamiento distinto. Para determinar que realmente nos encontramos ante dos redes distintas, no hay una metodologa firme, pero por lo general suelen considerarse diferentes aquellas redes con topologa distinta (bus, circular,) o con tecnologas de transmisin que difieren (broadcasting, unicasting,). Por ej. La conexin dos LANs, o una WAN con una LAN, etc. En el caso de las redes de tipo WAN, el conjunto formado por la subred ms los distintos hosts, no se considera una interred, en su lugar, todo el conjunto es considerado una sola Red. En cambio, si uso una red del tipo WAN para interconectar dos LANs, en dicho caso, si que nos encontramos ante una interred. Subred, nombre usado para denominar al conjunto de enrutadores y lneas de comunicacin usados para comunicar partes distantes dentro de una misma red. Por ej. Los conmutadores telefnicos de los operadores de telefona, los cuales se

conectan con otros conmutadores de otras centrales de la compaa para poder enviar y recibir llamadas desde puntos muy distantes entre s.

1.2 Software de Redes

1.2.1 Principios bsicos
La mayora de redes se dividen en una serie de capas o niveles, cuyas funciones y nombre vara de red a red. El objetivo de cada capa es proporcionar algn tipo de servicio a la capa superior, y dicho servicio es esencial para que la capa superior pueda desempear correctamente el suyo, as pues, cada capa depende de los servicios de su capa inferior, que a su vez esta depende de los de la inferior a sta, y as sucesivamente, se trata de una cadena de favores. La capa N de una mquina siempre se comunicar con la equivalente capa N de otra mquina. El conjunto de reglas usadas para establecer dicha comunicacin vienen determinadas por el protocolo de capa N. As pues, un protocolo no es ms que un acuerdo entre las partes en comunicacin sobre cmo debe llevarse a cabo dicha comunicacin (el concepto de protocolo usado en redes mantiene una relacin directa con el significado de la palabra en otras reas. Por ej. Cuando hablamos de un protocolo de actuacin durante una intervencin policial, o de un protocolo de conducta para una reunin social, etc.) Cada capa N no se comunica con su correspondiente capa N de otra mquina de forma directa, sino que en su lugar, se envan los datos y la informacin de control a la capa inmediatamente inferior, y as sucesivamente, hasta llegar a la capa de nivel ms bajo, la capa fsica o capa de nivel 0. La capa fsica, se encarga de codificar toda la informacin binaria que deseamos transferir a algn tipo de representacin fsica que luego la mquina de destino pueda descifrar (impulsos de luz, en el caso de fibra ptica, o ondas electromagnticas en las redes inalmbricas, etc.). Entre una capa A cualquiera y su capa superior B existe una interfaz, sta indica a B como acceder a los servicios ofertados por A. Especifica cules son los parmetros que B debe pasar a A, y qu resultados se esperan, es decir que debe devolver la capa A a B. Arquitectura de red, conjunto de capas y protocolos. Pila de protocolos, la lista de protocolos usados por un sistema (Arquitectura filosofotraductor-secretaria, pg. 29). Las entidades que usan los protocolos para comunicarse se llaman iguales y podran ser procesos, hardware, personas, etc. Encabezado (Header), es como se denomina a la informacin de control que cada capa aade a cada paquete (mensaje). Cuando transferimos datos entre dos capas de dos maquinas distintas, adems de datos tambin transferimos toda una serie de informacin relativa al paquete enviado (nmero de secuencia para ordenar los fragmentos de texto enviados, tamaos, medidas, etc.). Si el paquete que hemos transferido de una capa A a su capa B inferior, es excesivamente grande, ste se divide en varios fragmentos. Cabe recordar que, normalmente, cada capa de nuestra red impondr un tamao mximo determinado para que los paquetes que reciba puedan ser aceptados. A su vez, la capa coloca un Header a cada

fragmento en los que ha divido el mensaje original (el mismo para cada uno de ellos). Cuando el mensaje sea recibido en la maquina destino, cada capa de sta ira eliminando automticamente los headers introducidos por las capas de nivel equivalente en la mquina emisora. La capa de nivel ms bajo de nuestra red obviando la capa de nivel 0 o fsica, aade adems de un encabezado, un Terminador, para indicar que ya hemos acabado de procesar el mensaje original y que ya est listo para enviarse mediante la capa fsica. Las capas ms bajas de una torre de protocolos suelen encontrarse implementadas en el propio hardware o firmware de los dispositivos (tarjetas de red, router, etc.) Control de errores, los medios fsicos usados para transferir la informacin digital no son perfectos, en consecuencia, pueden producirse errores durante dicho proceso. Por ello, cada equipo de nuestra red debe implementar una serie de reglas de deteccin y correccin de errores, dichas reglas deben ser las mismas para todos los sistemas que estn participando en la comunicacin. Control de flujo, as es como se denomina al control de la velocidad de transferencia de datos. A menudo un nivel N de una determinada maquina es ms eficaz y rpido que el nivel equivalente de la maquina receptora (normalmente debido a una implementacin ms deficiente de dicha capa o por limitaciones de hardware), en tales casos, se produce una saturacin de datos, para la cual existen diferentes posibles soluciones, una de las ms comunes, es adaptar la velocidad de transferencia a la de la mquina ms lenta. En ocasiones, pueden haber procesos en determinadas capas que exijan paquetes de tamao pequeo para realizar sus tareas, en tal caso, el mensaje original y de gran tamao es dividido en mltiples paquetes pequeos, que a su vez, se ensamblan todos dentro de un mismo paquete de gran tamao. Se enva dicho paquete enorme al proceso de la maquina destino, y luego ste lo desmiembra de nuevo en paquetes diminutos antes de procesarlos. Multiplexin y Desmultiplexin. Cuando dos o ms procesos distintos desean transferir informacin a un mismo destinatario usando la misma conexin, suele usarse la tcnica de Multiplexin en la capa fsica para unir dichos mensajes en uno de slo, para posteriormente, en el equipo receptor volver a desmultiplexar la seal, y recuperar los mensajes separados. Direccionar y Enrutar. Por direccionar nos referimos al proceso de determinar el destino de un paquete. Las redes suelen estar formadas por varios equipos, y necesitamos indicar de todos ellos, a cual se dirige nuestro paquete. Por otro lado, cuando hablamos de Enrutar nos referimos a seleccionar el camino ms eficiente a seguir por nuestro paquete. Normalmente hay mltiples caminos en nuestra red que llevan a un mismo destino, Enrutar consiste en seleccionar cul de ellos es el ms adecuado (normalmente el ms corto o con menos trfico). 1.2.2 Servicios de las capas Principalmente las capas ofrecen dos tipos de servicios a sus respectivas capas superiores: servicios orientados y no orientados a la conexin.

Los servicios orientados a la conexin, son aquellos en los cuales se establece previamente una conexin entre el emisor y el receptor, se usa, y luego se abandona (similitud con el sistema telefnico). En algunas ocasiones, es posible que antes de empezar la transmisin de datos, se pacte previamente que parmetros se usaran (por ej. longitud mxima del mensaje). La informacin se enva bit a bit, secuencialmente y en orden, hasta transmitir el paquete entero. Por otro lado, los servicios no orientados a la conexin, mantienen cierta similitud con el sistema postal. En vez de establecer previamente una conexin con el receptor, confiamos en la red de transporte de informacin, y enviamos un mensaje (carta) con la confianza de que ste llegar a su destino. El receptor por su parte, recibe el mensaje (la carta) sin previo aviso. La informacin es enviada como un bloque, de datagrama en datagrama (en este tipo de servicios los paquetes reciben dicha denominacin). No es frecuente, pero en este tipo de servicios, podra ocurrir que un mensaje enviado con posterioridad, por diversas causas, lograra llegar antes que otro que fue enviado antes. Servicios confiables y no confiables. Se considera que un servicio (ya sea orientado o no a la conexin) es confiable si nos permite asegurar una alta probabilidad de que todos los mensajes llegarn a nuestro receptor, es decir, no se pierden paquetes durante la transmisin. Para ello, generalmente, se suele recurrir a la confirmacin de la recepcin de cada paquete, de esta forma el emisor puede estar seguro de que el mensaje a llegado a su destino satisfactoriamente. No obstante, dicha confirmacin de recepcin introduce retardos y sobrecargas en la conexin, por lo que no siempre nos ser til. En el caso de los servicios orientados a la conexin confiables, existen dos subcategoras: de mensajes o de bytes. En el primer caso, la informacin es transmitida respetando los lmites de cada mensaje. Si deseamos enviar un mensaje de 2048 bytes, dividido en dos paquetes de 1024, as es tal y como lo recibir nuestro receptor. En el caso de un servicio confiable por flujo de bytes, recibiramos la informacin bit a bit, hasta alcanzar los 2048 bytes que conforman el paquete enviado. En tal caso, nuestro destinatario nunca podra averiguar si el paquete original eran dos de 1024 bytes, o por ej. 2048 de 1 byte. Para segn que aplicaciones nos ser ms til una u otra. Tambin existen servicios no orientados a la conexin confiables y no confiables. Aquellos servicios de este tipo que no confirman la recepcin de mensajes (no confiables), se denominan Servicios de Datagramas (por ej. Correo basura). En contraste, si existe una confirmacin por parte del destinatario, hablaremos de Servicios de Datagramas Confirmados (por ej. Correo certificado). Finalmente, existe una tercera variante, los Servicios de SolicitudRespuesta, dnde el emisor enva un solo datagrama que contiene una solicitud a la cual el receptor debe responder. Este tipo de servicio es usado en la implementacin de conexiones con modelo cliente-servidor, donde el cliente emite una peticin, y el servidor la responde (por ej. Consulta a una base de datos).

Cuadro resumen: Servicio Flujo confiable de mensajes Orientado a la conexin Flujo confiable de bytes Conexin no confiable Ejemplo Transferencia de un documento Transferencia de un archivo Webcam o VozIP (para evitar los retardos)

NO Orientado a la conexin

Datagrama no confiable Datagrama confirmado Solicitud-Respuesta

Correo basura Correo certificado Consulta a base de datos

1.2.3 Primitivas de servicio Se conocen por primitivas de un servicio, el conjunto de operaciones bsicas que ste pone a disposicin de un determinado proceso para que pueda usar dicho servicio. Este conjunto de operaciones suele consistir en llamadas al sistema operativo. Un proceso de una aplicacin que est corriendo en nuestra mquina, en un momento determinado, necesita usar el servicio de la capa N que le proporciona conexin con un servidor, para ello realizar una peticin al servicio y ste a su vez, mediante las primitivas ceder el control del proceso al kernel del SO para que ste enve los paquetes necesarios. El servicio de cada capa simplemente hace de intermediario entre el proceso y el SO, adems de definir el conjunto de primitivas aceptadas y el protocolo que se usar para la transmisin de los paquetes enviados por el SO. El conjunto de primitivas proporcionadas por un servicio, dependen de la naturaleza y propsitos de ste, de nada ms. Para cada servicio definiremos unas primitivas acordes con nuestro propsito y tipo de conexin (las primitivas para un servicio orientado a la conexin difieren de las disponibles para un servicio no orientado a la conexin). Ejemplo de las primitivas disponibles para un servicio simple orientado a la conexin: Primitiva LISTEN (servidor) CONNECT (cliente) Significado Pausa el proceso en espera de una solicitud de conexin entrante Se enva un paquete para solicitar conexin al servidor. Si exista algn proceso en escucha, ste queda liberado, y se devuelve al cliente un paquete de confirmacin de recepcin (ACK). El cliente o servidor quedan bloqueados a la espera de recibir nuevas solicitudes de datos. El cliente o servidor envan los datos solicitados. El cliente hace un DISCONNECT cuando ya haya terminado con todas las solicitudes, al

RECEIVE (cliente/servidor) SEND (cliente/servidor) DISCONNECT (cliente/servidor)

hacerlo, el servidor recibe un paquete informando de la desconexin, a lo cual el servidor responde enviando un paquete de confirmacin de recepcin y terminando la conexin, en este momento, el proceso del cliente queda liberado.

Ejemplo de terminaciones de primitivas de servicio: Terminaciones request Significado Solicitud de datos o conexin entre dos capas N de distintos host. Un request realizado por una capa es repetido de capa en capa hasta llegar a la capa fsica. Indicacin de la llegada de nuevos datos. Una indicacin es repetida de capa en capa hasta llegar desde la capa fsica a la capa a la que van dirigidos los datos. Aceptacin de los datos o solicitudes requeridas por otro capa del mismo nivel. Se informa al servicio de la capa que solicito datos de que el destinatario ha aceptado nuestra llamada.

indication

response (solo para servicios confirmados) confirm (solo para servicios confirmados)

Ejemplo de dilogo tpico entre dos capas de nivel N con servicios confirmados:

Ejemplo real de primitivas de servicio con terminaciones: Llamada a un amigo

1. CONNECT.request Marcas le nmero de telfono 2. CONNECT.indication Suena su telfono 3. CONNECT.response Coge el telfono

4. CONNECT.confirm - Oyes que deja de sonar el timbre 5. DATA.request Le invitas a tomar algo 6. DATA.indication Oye la invitacin

7. DATA.request Dice le va bien y se despide 8. DATA.indication Oyes le va bien y te despides 9. DISCONNECT.request Cuelgas el telfono

10. DISCONNECT.indication Oye que has colgado y cuelga

1.2.4 Conceptos clave: Servicio, Protocolo e Interfaz Cuando hablamos de un Servicio, nos podemos referir a l como el conjunto de primitivas que una capa proporciona a la capa superior que est sobre ella. El servicio que la capa inferior ofrece a la capa superior. Un protocolo, es un conjunto de reglas que dictaminan en que formato y como deben interpretarse, el contenido de los paquetes enviados entre dos procesos de capas del mismo nivel. Servicio y protocolo son trminos independientes, podemos cambiar el protocolo usado en un servicio de una capa N, por otro cualquiera, siempre y cuando el nuevo protocolo proporcione exactamente los mismos servicios que el anterior. Es decir, la idea sera la siguiente: el servicio muestra el conjunto de operaciones que nuestra capa puede realizar, pero esconde o abstrae, la implementacin de stas, ya que de ello se encargar el protocolo de dicha capa. Haciendo una analoga con los lenguajes de programacin de alto nivel, el servicio equivaldra a un TAD (Tipo Abstracto de Datos) o un objeto (Java), en el cual definimos las distintas operaciones a disposicin del usuario de nuestro programa, pero escondemos los detalles de cmo stas han sido implementadas (protocolo). Finalmente, en cuanto al concepto de interfaz (que ya fue tratado en captulos anteriores), recordar que consiste en la especificacin de parmetros que un servicio de la capa N+1 debe transmitir a la capa N, as como los resultados que se esperan que devuelva la capa N al servicio N+1.

1.2.5 Modelos de referencia: OSI y TCP/IP La arquitectura de red OSI se encuentra prcticamente en desuso, pero el modelo en s que sta presenta sigue usndose hoy en da y an es vlido. Lo que ha quedado en desuso de OSI son sus protocolos, los cuales han sido substituidos por los del modelo TCP/IP.

1.2.5.1 Modelo OSI Este modelo est basado en una propuesta desarrollada por la ISO (Organizacin Internacional de Estndares) y cuyo fin era la estandarizacin internacional de los protocolos usados en varias capas. El nombre de OSI (Open Systems Interconnection) se debe a la intencionalidad de conectar entre s sistemas abiertos, es decir, sistemas abiertos a la comunicacin con otros sistemas. El modelo OSI naci como una propuesta de las grandes empresas de telecomunicacin de los distintos pases, y recibi un fuerte respaldo por parte de las entidades gubernamentales.

Estructura del modelo OSI (7 capas): Capa fsica (bits): En esta capa se lleva a cabo la transmisin de bits (0 y 1) a travs de un determinado medio fsico (cobre, radiofrecuencia, fibra ptica,). Se encarga entre otras tareas, de determinar las formas en como representaremos fsicamente el cdigo binario, como se establecer y terminar la conexin, minimizar errores durante la transmisin de datos, etc. Transforma las tramas que recibe de la capa de enlace de datos en seales elctricas o electromagnticas, o, por el contrario, transforma la seal elctrica en tramas de datos que entregar a la capa superior. Capa de enlace de datos (tramas): La capa de enlace de datos se encarga de proporcionar una transmisin sin errores entre dos medios conectados fsicamente. Adems tambin se ocupa del direccionamiento fsico, de la topologa de la red, del acceso a la red, de la notificacin de errores, de la distribucin ordenada de tramas y del control del flujo. A cada trama, se le aade una cabecera con la direccin fsica de origen y destino (direccin MAC) e informacin de control diversa. Normalmente de esta capa suelen ocuparse los Switches (o routers con switch integrado). Capa de red (paquetes): La capa de red se encarga de que los datos lleguen desde su destino a su origen, an cuando no exista una conexin fsica entre ambos sistemas. Para ello, determina la ruta de los datos (direccionamiento lgico). Tambin se encarga de controlar el congestionamiento de la red. Capa de transporte (segmentos): Su funcin bsica es aceptar los datos enviados por las capas superiores, dividirlos en pequeas partes si es necesario, y pasarlos a la capa de red. La capa de transporte tambin determina qu tipo de servicio proporcionar a la capa de Servicio. Por ejemplo, la comunicacin puede ser manejada para que los paquetes sean entregados en el orden exacto en que se enviaron, asegurando una comunicacin punto a punto libre de errores, o sin tener en cuenta el orden de envo. Una de las dos modalidades debe establecerse antes de comenzar la comunicacin para que una sesin determinada enve paquetes, y se ser el tipo de servicio brindado por la capa de transporte hasta que la sesin finalice. A diferencia de las capas 1-3, la capa de transporte no est tan encadenada a sus capas inferiores, ya que sta opera de extremo a extremo (de origen a destino) sin subredes de por medio, mientras que, las capas 1-3 se limitan a operar con sus vecinos ms inmediatos.

La capa de transporte es independiente de sus capas inferiores, es decir, debe ser capaz de transferir datos entre dos maquinas sin que un posible cambio en el hardware afecte a tal tarea. Llegado a ste punto, podemos afirmar que una posible divisin del modelo OSI consistira en separar la subred de comunicacin (enrutadores, switches, tarjetas de red, cables,) en la cual se basan las capas 1-3, de la comunicacin directa origen-destino de las dems capas superiores. Capa de sesin: Se encarga de establecer, gestionar, y finalizar las conexiones entre usuarios finales (procesos de las aplicaciones). Entre sus tareas, figuran las de: controlar quien debe transmitir en cada momento, evitar que las dos partes intenten ejecutar la misma operacin crtica a la vez, aadir checkpoints o puntos de referencia para permitir reanudar las conexiones en caso de interrupcin, Capa de presentacin: La capa de presentacin es la primera en tratar el contenido de los datos en vez de la forma en cmo estos se transmiten. Se trata de una especie de traductor que acta de intermediario entre los datos recibidos y la representacin interna de stos. A menudo distintas mquinas usan mtodos variados de representacin de la informacin (ASCII, Unicode, etc.), lo que hace necesaria la existencia de un interprete de dichos datos que permite comunicarnos con cualquier entidad. Capa de aplicacin: La capa de aplicacin ofrece a los procesos de las aplicaciones la posibilidad de acceder a los servicios de capas inferiores, y se encarga de definir los protocolos que usan las aplicaciones para intercambiar datos (SMTP, POP3, FTP, HTTP, SSL, Telnet,).

1.2.5.2 Modelo TCP/IP El modelo TCP/IP fue usado por primera vez en la madre de todas las redes: ARPANET. Con la aparicin de nuevos mtodos de comunicacin alternativos a la lnea telefnica (radio, satlite,) surgi la necesidad de revisar la arquitectura vigente de ARPANET y crear una que tuviera la capacidad de conectar mltiples redes de una manera solida, dicha arquitectura acabara conocindose como el modelo de referencia TCP/IP, de acuerdo con sus dos protocolos primarios. A diferencia del modelo OSI, el modelo TCP/IP naci como una propuesta de la propia comunidad informtica para dar solucin a los distintos problemas de comunicacin que se presentaban en la poca. Estructura del modelo TCP/IP (4 capas): Capa de interred o internet (Protocolo IP/ PDU: Datagrama IP): La capa de interred o internet cumple con la misma misin que su anloga, la capa de red (modelo OSI), se encarga de hacer llegar los paquetes de datos del origen a su destinatario. El servicio ofrecido por la capa de internet es no orientado a la conexin, por lo que se van inyectando paquetes en la red los cuales que no tienen porque llegar en el orden exacto en el que fueron enviados. En el caso en que fuera necesario reordenar los paquetes, se podran encargar de ello las capas superiores.

La principal diferencia con la capa de red del modelo OSI se encuentra en los protocolos usados, en el caso de la capa de internet el protocolo IP (Internet Protocol), el cual permite definir como deben ser los paquetes transmitidos para que stos puedan viajar sin ningn tipo de problemas a travs de todo tipo de redes de cualquier lugar del mundo, es decir, a travs de internet (red de redes). Protocolos de la capa de red (OSI) como el X.25 y Host/IMP Protocol estaban diseados para redes simples y unitarias, no para transportar paquetes a travs de distintas redes interconectadas entre s, tal necesidad no surgi como caba esperar, hasta la llegada de Internet. En la capa de Internet cada entidad participante en la comunicacin se identifica mediante una direccin global de red (IP pblica). Los datos son enviados a la direccin IP correspondiente. Capa de transporte (protocolo TCP/UDP. PDU= Segmento TCP): La capa de transporte se encarga de la transmisin de informacin de extremo a extremo (origen-destinatario), tal y como tambin sucede en la capa de transporte OSI. Dicha capa puede trabajar con dos protocolos distintos, tiles segn los requerimientos de la aplicacin. El primero de ellos, el protocolo TCP (Transfer Control Protocol) es un protocolo confiable y orientado a la conexin. La capa de transporte recibe un flujo de bytes que son divididos en segmentos (segmentos TCP) y pasa cada uno de ellos a su capa inferior (capa de internet), para que sta pueda enviarlos de forma ordenada y confiable al destinatario. El protocolo TCP tambin soporta control de flujo para evitar que un emisor rpido sature a un receptor lento. Por otro lado, nuestras aplicaciones tambin pueden usar si lo desean, el protocolo UDP (User Datagram Protocol) que a diferencia del TCP se trata de un protocolo no confiable y no orientado a la conexin es usado por las aplicaciones que no desean la segmentacin ni el control de flujo ofrecido por TCP, ofreciendo soluciones y mtodos propios. El protocolo UDP es usado en entornos solicitud-respuesta de tipo cliente-servidor o en la transmisin de imagen y sonido en tiempo real. A nivel de transporte cada entidad participante en la comunicacin se identifica mediante un puerto (SAP, Service Access Point en el modelo OSI). Los datos son enviados de un puerto origen a un puerto destinatario. Capa de aplicacin (PDU: flujo de bytes): La experiencia ha demostrado como las capas de sesin y presentacin presentes en el modelo OSI apenas son usadas por las aplicaciones, lo que ha originado su eliminacin en el modelo TCP/IP, dnde los servicios ofrecidos por dichas capas suelen integrarse dentro de la capa de aplicacin o en el cdigo del propio programa. La capa de aplicacin se encarga de recibir los datos internos usados por una aplicacin determinada para codificarlos bajo un protocolo estndar (HTTP, FTP, SMTP,) y entregar el flujo de bytes resultante a las capas inferiores de la pila de protocolos TCP/IP. Capa de host a red (capa fsica + capa enlace de datos): Debajo de la capa de red hay un gran vaco. El modelo TCP/IP no especifica cmo deben implementarse los servicios ofrecidos por la capa fsica y de enlace de datos del modelo OSI. No obstante, y a modo de referencia, puede usarse la descripcin ofrecida de dichas capas en OSI.

1.2.5.3 Comparacin modelos OSI y TCP/IP Ya hemos analizado las caractersticas de ambos modelos de referencia, y hemos podido observar como los dos se estructuran en forma de pila o torre de protocolos independientes y como la funcionalidad de las capas es muy similar en ambos modelos. No obstante, tambin existen ligeras diferencias. Vemoslas en el siguiente cuadro: Modelo OSI Puntos a favor 1) Primero se diseo el modelo, posteriormente los protocolos, otorgando una flexibilidad total para cambiar los protocolos por otros que ejercen las mismas funciones Modelo TCP/IP 2) Los servicios ofertados por cada capa estn perfectamente definidos y documentados. 3) La capa de red mediante su protocolo IP permite la transferencia de datos a travs de distintas redes interconectadas entre s (Internet). 4) La capa de transporte soporta comunicaciones orientadas a la conexin (TCP) y tambin de no orientadas (UDP). Lo que proporciona mayor usabilidad de la capa por parte de las aplicaciones. Puntos en contra 2) Los servicios que cada capa debe ofrecer son poco concretos. Lo que oblig a crear subcapas que aumentaran la funcionalidad. 1) En primer lugar se disearon los protocolos (el TCP y el IP), posteriormente, se creara el modelo en base a dichos protocolos. Imposibilidad de cambiar los 3) La capa de red usa protocolos usados por otros. protocolos que solo permiten el trfico de datos dentro de una misma red. 4) La capa de transporte nicamente soporta comunicaciones orientadas a la conexin.

- Porque fracas el modelo OSI? 1) Falta de inversin: Cuando aparecieron los protocolos OSI, en cientos de universidades ya se estaban usando los protocolos TCP/IP, lo cual llamo la atencin de un gran nmero de proveedores interesados en dicha tecnologa y que ms tarde acabaran ofreciendo apoyo econmico. OSI no quiso adaptarse a la pila de protocolos TCP/IP lo que hizo que perdiera apoyo en forma de inversin econmica por parte de las empresas. 2) Modelo complejo y deficiente: Los estndares que definen OSI son complejos y difciles de implementar, por otro lado, la decisin de usar siete capas tampoco es del todo acertada, ya que dos de ellas estn prcticamente vacas (la de sesin y la de presentacin), mientras que otras dos estn saturadas de contenido (la de enlace de datos y la de red). Otro de los graves problemas de OSI es la repeticin de algunas funciones en distintas capas, como por ej. El control de flujo, el control de errores o el direccionamiento, presentes en cada capa del modelo. 3) Implementacin deficiente: La enorme complejidad del modelo y los protocolos provoc que las primeras implementaciones por parte de los desarrolladores fueran deficientes, lo que provoc que pronto se empezara a asociar OSI con baja calidad o lentitud. En contraste, TCP/IP desde sus inicios recibi unas muy buenas implementaciones, las cuales adems de buenas eran gratuitas. Rpidamente empezara a popularizarse el modelo y a ser usado cada vez con ms frecuencia, lo cual provoc la aparicin de mejoras, que a su vez atraan a ms usuarios. 4) Politizacin: El concepto que se tena sobre OSI, era el de un modelo nacido del mundo gubernamental, un mundo que resultaba distante y se mantena alejado de las comunidades de desarrolladores y programadores que eran los que realmente implementaban las redes de computadores. Tal percepcin del modelo fue un factor ms que contribuy a su fracaso.

- Resulta perfecto el modelo TCP/IP? El modelo de referencia TCP/IP tambin tiene una serie de defectos o deficiencias: 1) El primer de ellos es una definicin confusa de los conceptos: servicio, interfaz y protocolo. No separa correctamente la especificacin de la implementacin en s. 2) Otro problema de TCP/IP es la restriccin para usar otros protocolos que no sean el TCP y el IP, lo que le hace poco flexible para describir otras redes que usen otros protocolos, como por ej. una red basada en Bluetooth. Por lo que el modelo no es del todo general, ni vlido para describir cualquier tipo de red. 3) La capa de nivel ms bajo (capa host a red) no est del todo bien definida, tal y como ya hemos comprobado en apartados anteriores. Adems de ello, no se trata de una capa como tal, sino ms bien una especie de interfaz entre la capa de red y una hipottica capa de enlace de datos. 4) No distingue, ni tampoco siquiera menciona, las capas fsica y de enlace de datos, a pesar de ser completamente diferentes.

- Conclusin El modelo OSI resulta un ejemplo a seguir de cmo debe disearse una red (quitando las innecesarias capas de sesin y presentacin), separando especificacin de implementacin y aportando un modelo general que pueda adaptarse a la mayora de redes existentes. En contraste, sus protocolos son muy complejos y pesados, lo que hace que no se tomen como referencia a la hora de disear un nuevo protocolo. Por otro lado, con TCP/IP ocurre exactamente el proceso inverso. Dispone de unos excelentes protocolos, pero descuida enormemente el modelo en s, hasta el punto de resultar prcticamente inexistente y usarse tan slo sus protocolos.

1.2.5.4 Transmisin de Datos Cmo llegan los datos que hemos enviado desde el host A al host B? Independientemente del modelo escogido (OSI o TCP/IP) el proceso de transmisin de informacin siempre se basa en el mismo concepto: fragmentacin y reensamblaje. Los datos que deseamos enviar desde el Host A experimentan un proceso de fragmentacin, es decir, se les aade consecutivamente nueva informacin segn avanzan por los distintos niveles de nuestra red. Esta nueva informacin, que suele aadirse en forma de cabecera (header), bsicamente consiste en datos de control que cada capa aade para poder realizar controles de errores, de flujo, etc. La informacin final que el host A acabar enviando a B, se tratara del conglomerado formado por el mensaje original que se deseaba transferir, ms el conjunto de cabeceras que cada capa de nuestra red ha ido aadiendo a dichos datos. Cuando los datos son recibidos en el sistema de destino, stos son reensamblados, es decir, volvemos a recuperar el mensaje original. Para ello, cada capa de nuestra red ir eliminando su correspondiente cabecera, la cual fue aadida por la capa homnima del sistema origen. De esta forma, mediante este proceso inverso lograremos que los datos acaben llegando intactos de nuevo hasta la capa de aplicacin del host B. A continuacin puede observarse una imagen ilustrativa del proceso descrito:

* PDU (Protocol Data Unit): La unidad de informacin con la que trabaja una capa N. Est compuesta por los datos recibidos de la capa superior (PDU N+1), y la informacin de control de la capa N actual (PDU de N= PDU N+1 ms Informacin de control de N).

1.2.6 Ejemplo de Redes Prximamente.

TEMA 2 -La capa de red (Internet)2.1 Introduccin * Como ya hemos visto en captulos anteriores, la capa de red se encarga de llevar los paquetes desde el origen al destino, siendo la capa de nivel ms bajo que hace un trato en la conexin de extremo a extremo (de PC a PC), puesto que la capa inmediatamente inferior, la capa de enlace de datos, solo trata la forma en cmo las tramas se envan desde un extremo del cable al otro, (cable, radiofrecuencia, fibra ptica,). por ej. mediante el uso de protocolos de enlace de datos punto a punto como PPP. * El principio base de la capa de red consiste en hacer llegar un paquete desde el host A al host B usando una subred (conjunto de enrutadores o routers), la cual pertenece a la empresa de telecomunicaciones local en cuestin y que nos sirve como medio para transportar nuestros datos. Los paquetes IP que deseemos enviar van saltando de enrutador en enrutador, hasta llegar a su destino. Existen distintos algoritmos de enrutamiento para decidir que ruta tomarn nuestros paquetes, algo que ms adelante veremos. Este tipo de conmutacin de paquetes se conoce como Conmutacin de almacenamiento y reenvo, ya que cada router almacena el paquete recibido y lo reenva a otro; el paquete no ser eliminado hasta que se haya comprobado que se ha recibido correctamente y sin errores. * El tipo de servicio que proporciona la capa de red es NO orientado a la conexin, es decir, se envan los datagramas IP de forma desordenada y sin control de flujo, ya que previamente no establecemos una conexin. Puede que muchos de estos paquetes no lleguen en orden o se pierden, de estos aspectos ya se encargarn los hosts implicados. * Tal y como ya se ha mencionado reiteradas veces con anterioridad, cuando hablamos de servicios NO orientados a la conexin, los paquetes tienden a llamarse datagramas (en analoga a los telegramas), y la subred usada se denomina subred de datagramas. Por otro lado, los servicios orientados a la conexin, trabajan con paquetes que son enviados bajo previa conexin con el enrutador del host de destino, dicha conexin se conoce como CV (Circuito Virtual), y la subred usada se denomina subred de circuitos virtuales.

2.2 Subredes de Datagramas y Subredes de Circuitos Virtuales - Subred de Datagramas: Supongamos que deseamos enviar un mensaje del host A al host B, pero la longitud del mensaje es superior al tamao mximo de paquete permitido por nuestra capa de red, para solucionarlo, dividiremos el mensaje original en 4 paquetes, dnde cada uno de ellos almacenar en su cabecera las direcciones de origen y destino correspondientes. Empezaremos enviando el paquete 1 (o cualquier otro, ya que hemos visto que no se envan en orden) a nuestro enrutador o en defecto, al de la empresa de telecomunicaciones que nos proporcione el servicio de Internet. A partir de este momento, nuestro paquete empezar a navegar a travs de la subred de datagramas de la teleco hasta alcanzar el enrutador de destino al cual est conectado el host al cual deseamos enviar el mensaje. Para lograr dicha

tarea, cada router almacena una Tabla de enrutamiento (Routing Table) donde se registra el camino a seguir para cada destino posible de la subred. Cada entrada de la tabla consiste en un par de columnas, una que indica el destino del paquete y otra el nodo ms prximo al cual lo enviaremos. Las tablas de enrutamiento pueden ser estticas, si se configuran una nica vez y la ruta almacenada siempre es la misma e invariable (esttica), aunque tambin podemos aadir rutas alternativas (si por ej. se congestionara la red); y dinmicas, dnde las tablas se reconfiguran automticamente a partir de la informacin que reciben de sus nodos vecinos. Existen distintos algoritmos para ambos tipos de tablas, y que determinan la forma en cmo escogeremos el camino ms idneo para el envo de nuestros paquetes, dichos algoritmos se conocen como Algoritmos de enrutamiento. * Subred de circuitos virtuales: En contraste con una subred de datagramas, los paquetes enviados no se enrutan individualmente y por separado, sino que se establece un circuito virtual fijo a travs del cual se transferirn todos los datos. Este mtodo de funcionamiento es idntico al usado en la telefona para el establecimiento de conexin de una llamada telefnica (Redes orientadas a la conexin, ATM). Por lo tanto la ruta a seguir por nuestros paquetes, permanecer invariable y constante durante toda la transmisin. En este caso, cada paquete incluye en su cabecera un identificador de conexin que indica a que circuito virtual pertenece, con la finalidad de poder conmutar adecuadamente stos. Estos paquetes no contienen ningn tipo de direccin IP, tan slo el identificador. El funcionamiento interno de dicha subred es parecido al caso anterior, con el matiz de que las tablas que ahora guardar cada enrutador, estructuran la informacin de una forma ligeramente distinta a las subredes de datagramas. Ahora la tabla almacenar por un lado la direccin del emisor del paquete junto a su identificador de conexin, y por otro, la direccin de destino al cual lo reenviaremos as como el identificador de conexin que usaremos. En ocasiones es posible que, el identificador de conexin de un paquete entrante no coincida con el identificador de salida, en la mayora de casos, esto se debe a que hemos recibido un paquete perteneciente a una conexin que ha escogido un n identificativo que ya est siendo usado en otro circuito virtual, en tal caso, y para evitar conflictos, asignaremos otro identificador de salida cuando reenviemos el paquete al nodo correspondiente. De tal tarea, se suele encargar el router que est conectado de forma directa con el host transmisor que realiza la conexin, ya que es el nico que sabe con certeza que el paquete proviene de un host cuyo identificador coincide con un circuito virtual establecido por un host distinto. - Comparacin entre las subredes de datagramas y las de circuitos virtuales Tanto los circuitos virtuales como los datagramas tiene distintos puntos a favor y en contra, en trminos generales ambos son totalmente vlidos para su uso en la transmisin de datos, a continuacin expondremos las principales diferencias existentes. - Ancho de banda o espacio de memoria?: El hecho de tener que almacenar ambas direcciones de origen y destino en la cabecera de los datagramas IP, provoca que inevitablemente estemos desperdiciando ancho de banda cuando transmitimos paquetes pequeos, ya que la inclusin de tales datos supone una sobrecarga significativa al tamao final del mensaje. En cambio, los circuitos virtuales nicamente incluyen un nmero de identificador de conexin, nada ms. En contrapartida, la mayor cantidad de informacin

almacenada por las tablas de los enrutadores en un circuito virtual, repercute negativamente en la cantidad de memoria fsica necesaria en dichos dispositivos, lo que supone tener que invertir en mejores y ms potentes equipos tcnicos. Esto es as, ya que las tablas de los circuitos virtuales disponen por un lado de una entrada por cada conexin virtual que exista, las cuales son menos extensas y ms simples que las largusimas entradas de enrutamiento para cada nodo posible de la subred de datagramas, pero a cambio tambin debemos almacenar la ruta de los paquetes de peticin de conexin que enviamos durante el establecimiento del circuito virtual. stos tambin deben enrutarse y almacenan en su cabecera las direcciones de destino y origen, tal y como tambin sucede en los datagramas IP. Toda esta informacin debe ser guardada en la tabla de los routers de un circuito virtual. As pues, la cuestin estara en decidir en que nos sale ms rentable invertir, en una mejor infraestructura para nuestra subred con el fin de que soporte un mayor ancho de banda? (debido al relativo desperdicio del que hacen gala los paquetes IP); o de lo contrario, preferimos invertir en enrutadores ms sofisticados y de mayor potencia que nos permitan almacenar gigantescas tablas de routing? - Calidad y rendimiento de la red: Los circuitos virtuales presentan ciertas ventajas en trminos de calidad y rendimiento de la lnea, esto es debido a que los recursos necesarios para establecer la conexin se reservan con antelacin con el fin de evitar sobrecargas en la red; si no hay suficiente capacidad de enrutacin la conexin se rechaza, mientras que en una red de datagramas, se aceptaran todas las peticiones de transmisin de datos sin tener en cuenta una posible saturacin de la red. - Usos espordicos de la red: En el caso de que se use la subred para comunicaciones breves y espordicas como por ejemplo, en las transacciones para tramitar pagos con tarjetas de crdito (la mquina a travs de la cual se hace pasar la tarjeta emite una llamada a la sucursal bancaria para comprobar de que se disponga del crdito suficiente para la realizacin de la compra), el uso de circuitos virtuales carecera de total sentido ya que es mucho mayor el tiempo que se tarda en establecer y terminar el circuito que el tiempo en s durante el cual vamos a hacer uso de esta conexin. En estos casos, suelen usarse subredes de circuitos virtuales permanentes (el circuito se establece manualmente y persiste en el tiempo, no es eliminado una vez se haya hecho uso de ste), de esta forma nos ahorramos los tiempo de inicio y terminacin de conexin. - Seguridad: Los circuitos virtuales tienen un gran hndicap en lo que a seguridad de conexin se refiere. Como la ruta que se establece en estos circuitos es nica y unnime para todos los paquetes pertenecientes a una misma conexin, si alguno de los enrutadores de nuestro circuito virtual se cae y pierde el contenido de su memoria, todos las conexiones que pasaban a travs de dicho dispositivo quedarn automticamente canceladas ya que el router no sabr como commutar los paquetes que reciba al haber perdido la informacin de los circuitos virtuales que pasaban a travs de l. En contraste, si un enrutador de una red de datagramas queda inhabilitado, solo sufrirn los usuarios cuyos paquetes estuvieran almacenados en ese preciso instante en el router, las dems comunicaciones no se vern afectadas. Adems no perderemos todos los paquetes transmitidos al dispositivo que ha fallado, ya que si con anterioridad se emiti una confirmacin de recepcin sobre stos, ya no ser necesario volver

a retransmitirlos. No obstante, todos los paquetes que no hubieran sido confirmados antes de la cada del router, volvern a ser reenviados automticamente. - Flexibilidad: Los enrutadores de una subred de datagramas son capaces de equilibrar el trfico que transcurre a travs de cada lnea de conexin cambiando dinmicamente (en tiempo real) la ruta escogida para cada paquete y as evitar pasar a travs de routers cados o sobrecargados; tambin conseguimos evitar las redes lentas. Estas caractersticas no son implementables en circuitos virtuales. A continuacin un cuadro resumen comparativo de la informacin expuesta:

Caracterstica
Configuracin del circuito Direccionamiento

Subred de datagramas
No necesaria La cabecera de cada datagrama contiene las direcciones de origen y destino Los enrutadores no almacenan informacin sobre el estado de las conexiones. Enrutan el datagrama sin importar su procedencia, solo interesa saber la direccin de destino. Cada datagrama se enruta de forma independiente

Subred de circuitos virtuales

Obligatoria La cabecera de cada paquete contiene un n identificativo de conexin (circuito virtual) Cada enrutador almacena informacin sobre las conexiones establecidas a travs de ste. Cada CV requiere espacio de tabla en el router. Se comprueba la procedencia del paquete para su correcta conmutacin. Cada paquete se enruta siguiendo la misma ruta, sta queda determinada en el momento de establecer la conexin (cuando creamos el CV). Terminacin de todos los CVs que pasaban a travs del dispositivo fallido.

Informacin de estado

Enrutamiento

Efecto de fallas del enrutador

Calidad del servicio

Control de congestin

Ninguno. Excepto para aquellos datagramas que aun no hayan sido confirmados en el momento de la falla. Resulta difcil ofrecer una buena Fcil, siempre y cuando podamos calidad del servicio ofrecido. reservar suficientes recursos por adelantado para cada CV. Resulta difcil ofrecer una buena Fcil, siempre y cuando podamos calidad del servicio ofrecido. reservar suficientes recursos por adelantado para cada CV.

2.3 Algoritmos de enrutamiento Uno de los aspectos ms importantes durante el diseo de la capa de red es la eleccin del algoritmo de enrutamiento que mejor se adapte a nuestros propsitos. Recordemos que un algoritmo de enrutamiento consiste en un conjunto de tcnicas software que determinarn la lnea de salida a travs de la cual reenviaremos los paquetes de entrada. En el caso de los circuitos virtuales, como la ruta escogida es siempre la misma para todos los paquetes de una misma conexin, suele llamarse enrutamiento de sesin.

No debe confundirse el proceso de reenviar con aquellas funciones desempeadas por el algoritmo de enrutamiento. Cuando recibimos un paquete, consultamos las tablas de enrutamiento para decidir la lnea de salida a tomar, y lo reenviamos. Por otro lado, el enrutador a su vez va llenando y actualizando dichas tablas, de esto se encarga el algoritmo usado. Ante todo, un algoritmo de enrutacin debe ser capaz de adaptarse a los cambios de topologa (adicin de nuevos enrutadores, substitucin de otros, nuevas lneas de transmisin, etc.) y al trfico, sin requerir abortar todas las transmisiones y reiniciar nuestra red cada vez que se produzca un cambio en sta. Tambin es importante mantener en equilibrio la optimizacin y la equitividad; resulta poco recomendable optimizar al mximo la comunicacin entre dos hosts, si para ello debemos de anular por completo la conectividad entre otro par de equipos. Resulta ms convincente y justo, establecer un grado medio de optimizacin dnde al menos todos los hosts tengan la oportunidad de cmo mnimo poder comunicarse. Otro punto importante es el de la relacin entre el retardo medio de los paquetes y la velocidad mxima de transmisin. Ambos conceptos tambin estn en conflicto, ya que a mayor velocidad de transferencia ms rpidamente se llenar la cola de paquetes de los enrutadores, y una cola que est cerca de su capacidad mxima se vuelve ms lenta, provocando que aparezcan retardos en la conexin. Una solucin intermedia pasa por utilizar un software de enrutamiento que optimice el nmero de saltos necesarios para llegar al destino, de sta forma se reduce el retardo (ya que la longitud a recorrer es menor), y se consiguen velocidades de transporte mayores. 2.3.1 Clases de algoritmos de enrutamiento Los algoritmos de enrutamiento pueden agruparse en dos tipos principales: estticos (no adaptativos), y los dinmicos (adaptativos). Los algoritmos dinmicos difieren entre s de aspectos como el lugar de donde obtienen su informacin (de los enrutadores adyacentes, de todos los enrutadores,), el momento en el que deben cambiarse las rutas (cada cierto intervalo de tiempo, segn la congestin de la red, cuando cambie la topologa,), y la mtrica usada para la optimizacin (distancia, nmero de saltos, tiempo estimado de trnsito,). - Principio de optimizacin Es posible realizar un postulado general sobre las rutas ptimas, independientemente de la mtrica usada para la optimizacin. Este postulado se conoce como principio optimizacin, y establece que si la ruta optima para ir desde el enrutador A al enrutador C es R1, entonces, si tenemos un enrutador B que est dentro de esta ruta ptima y se encuentra en algn punto intermedio entre A y B, la ruta R2 ms optima entre B y C (o entre A y B) tambin se hallar dentro de R1. Se trata de un hecho bastante lgico si pensamos en que sucedera si no fuera as, si existiese algn camino entre B y C ms optimo que el descrito por R1, significara que la ruta entre A y C no es todo lo ptima que podra ser, lo cual contradice nuestra afirmacin de que R1 es la ruta ms optima.

R2 R1

El conjunto de rutas ptimas de todos los orgenes a un destino concreto se puede representar mediante una estructura en rbol con raz en el destino, conocida como rbol sumidero (o rbol divergente). As pues, el objetivo de todo algoritmo de enrutamiento es averiguar el rbol sumidero de todos los routers de la red (poniendo en la raz del rbol, es decir, como destino, el enrutador del que deseamos averiguar su rbol sumidero). 2.3.1.1 Algoritmos de enrutamiento estticos 2.3.1.1.1 Enrutamiento por la ruta ms corta (Shortest path) El enrutamiento por la ruta ms corta se trata de un algoritmo sencillo y de amplio uso. Representamos nuestra subred mediante un grafo, donde cada nodo equivaldra a un enrutador y cada rama a una lnea de comunicacin. El algoritmo se basa en buscar la ruta ms corta entre un par de nodos de dicho grafo. El concepto ruta ms corta puede interpretarse de varias y diversas formas segn la mtrica que hayamos escogido. Si hemos escogido el nmero de saltos (ramas), el camino ptimo entre dos nodos ser aquel que menos saltos necesite para llegar al destino, por otro lado, tambin podemos usar la distancia geogrfica real como mtrica; con este mtodo es posible que sea ms optimo alcanzar un nodo mediante una ruta que se encuentre a cinco saltos consecutivos (muy cercanos) entre s, que no un camino con tres saltos, pero muy lejanos cada uno de ellos. Adems del nmero de saltos y la distancia tambin pueden usarse todo un conjunto de factores a partir del cual deseamos calcular el coste de movernos desde un nodo a otro; como por ejemplo: el ancho de banda, trfico medio, costo de comunicacin, distancia, retardo medio, y cualquier otro factor que deseemos tener en cuenta. Podemos crear una funcin de coste en base a todos los elementos que deseemos tener en cuenta en la eleccin de la ruta ms corta. La informacin sobre el coste entre dos nodos es representada en el grafo etiquetando cada nodo (entre parntesis) con su distancia (el coste total) al nodo de origen.

Para calcular la ruta ms corta (de menor coste) en un grafo existen distintos algoritmos, uno de lo ms usados es el algoritmo de Dijkstra. Inicialmente, tenemos marcado (rellenndolo en color negro) el nodo a partir del cual iremos elaborando la ruta ptima hasta el destino, y todos los dems nodos de nuestro grafo con la etiqueta infinito; ya que de momento no se conocen rutas. Cuando marcamos un nodo, lo convertimos en permanente (un nodo es permanente cuando inequvocamente ya ha sido escogido para formar parte de nuestra ruta

final), el resto de nodos se consideran tentativos (an no se sabe si acabarn formando parte de nuestra ruta o no). A continuacin, examinamos cada uno de los nodos tentativos adyacentes al de origen, y los etiquetamos con su coste respecto a ste. Una vez etiquetados, consultamos cual de los dos tiene un coste menor, y lo convertimos en permanente. Ahora ste ser nuestro nuevo nodo de trabajo, es decir, el nodo a partir del cual calcularemos los siguientes costes. Vamos repitiendo dicho proceso hasta finalmente alcanzar el nodo de destino propuesto.

2.3.1.1.2 Enrutamiento por inundacin (Flooding) El enrutamiento por inundacin consiste en enviar cada paquete de entrada a todas las lneas de salida, excepto aquella por la que lleg. Como cabra esperar, la cantidad de trfico redundante (innecesario) que genera dicha tcnica es enorme, ya que duplicamos muchos paquetes. Mediante este mtodo nos aseguramos que nuestros paquetes seguirn la ruta ms corta, ya que los enviamos a travs de todas las rutas posibles inundando todos los posibles caminos de la red con nuestros paquetes. Sin lugar a dudas, alguno de estos caminos ser el ms corto.

Dos de las tcnicas ms usadas para eliminar los paquetes duplicados son: el uso de contadores de saltos (hop counter), integrados en la cabecera de cada paquete, van decrementando su valor con cada salto, finalmente cuando el contador llega a cero el paquete es descartado. Con el fin de evitar que el paquete no pueda llegar a su destino debido a no disponer de suficientes saltos en su contador, ste suele iniciarse al tamao de la ruta o si se desconoce tal valor, al tamao total de la subred. Otro mtodo consistira en obligar a que cada enrutador de origen ponga un nmero de secuencia en cada paquete emitido, guardando en los dems routers de la subred una lista de los paquetes ya vistos. Cada lista adems estar acompaada de un contador de nmero de secuencia, de esta forma, es posible averiguar de una forma rpida y precisa si el paquete de entrada recibido esta duplicado o no (si el contador de secuencia tiene un valor de 20, y recibimos un paquete con secuencia 14, no ser necesario consultar la lista entera de paquetes tramitados para averiguar que ese paquete ya fue tratado con anterioridad). Se debe guardar una lista de secuencias por cada enrutador emisor, pues podra darse el caso de que un router recibiera un paquete con un nmero de secuencia ya conocido pero perteneciente a un host distinto, en tal caso, no debera de eliminarse.

Una variacin de la inundacin, algo ms prctica, es la inundacin selectiva. En este caso, solo enviaremos los paquetes a travs de aquellas lneas de salida que salgan en alguna direccin aproximadamente correcta; por ejemplo, si un paquete va dirigido a un host que se encuentra en la zona sur de nuestra subred, no tendra sentido enviar tambin el paquete en direccin norte. De esta forma logramos reducir ligeramente el nmero de duplicados. El enrutamiento por inundacin tiende a usarse en aplicaciones militares dnde la transmisin de datos es un factor crtico, y deseamos que la informacin llegue a su destino aunque media subred haya sido bombardeada (al inundar la subred con paquetes, siempre quedar alguna zona a travs de la cual stos estn circulando, a excepcin de que la subred entera quedara inutilizada). La inundacin tambin encuentra otros usos en las redes inalmbricas, dnde la estacin emisora (por ej. un router wifi) inunda su periferia con paquetes que pueden ser recibidos por cualquier otro dispositivo que se encuentre dentro de la cobertura. Tambin suele usarse en aplicaciones distribuidas para actualizar determinados datos de forma simultnea en todas las mquinas; o cuando el retardo medio debe ser lo menor posible, ya que no hay ningn algoritmo de enrutamiento ms rpido en encontrar la ruta ptima que ste (ignorando la sobrecarga en las lneas de comunicacin que la propia inundacin provoca). 2.3.1.2 Algoritmos de enrutamiento dinmicos 2.3.1.2.1 Enrutamiento por vector de distancia (Distance Vector Routing) El algoritmo de enrutamiento por vector de distancia (algoritmo de enrutamiento BellmanFord o Ford-Fulkerson) es, junto al de estado por enlace, uno de los algoritmos ms comunes y usados en redes de computadores (por ej. fue el primer algoritmo en enrutamiento usado en ARPANET). Su funcionamiento es simple, consiste en guardar una tabla (vector distancia) por enrutador, y que almacenar cual es la mejor lnea de salida a tomar para cada posible destino de nuestro red. Estas tablas son actualizadas dinmicamente en tiempo real a partir de la informacin que cada enrutador reciba de sus vecinos, de esta forma, podemos reflejar los cambios que se produzcan en la red. La tabla de enrutamiento contendr dos entradas por cada router que haya en la subred: la lnea de salida que tomaremos y la distancia a la que nos encontramos de ste. Recordemos, tal y como comentbamos anteriormente, que el concepto distancia depende de la mtrica usada (el retardo medio, la cantidad de saltos; en este caso siempre 1, distancia real, etc.). Se presupone que inicialmente cada enrutador conoce la distancia hasta cada uno de sus vecinos y desconoce la del resto de nodos. Para completar dicha informacin los routers deben enviar cada T mseg sus tablas de enrutamiento a todos sus vecinos, y stos a su vez, al cabo de otra fraccin de tiempo, a los suyos; y as sucesivamente, hasta conseguir que todas las tablas de routing de todos los enrutadores lleguen hasta todos los equipos de la subred, de esta forma mantenemos actualizadas las tablas a la vez que permitimos completarlas. Las buenas noticias que se produzcan en nuestra red, tales como la activacin de un enrutador que anteriormente se encontraba inoperativo o la reduccin en el trfico de la red

desde un nodo, son intercambiadas a razn de N saltos (por ej. si nos encontramos a cuatro saltos de X, los cambios producidos en dicho nodo nos llegaran al cabo de cuatro intercambios de tablas de routing, ya que en cada intercambio las tablas recorren un salto). Pero en el enrutamiento por vector de distancia, el problema no son las buenas noticias sino las malas, ya que la deteccin de estas es bastante lenta e ineficiente. Esto es debido a un problema conocido como conteo al infinito, y que consiste en empezar a aumentar el coste de ir desde cada enrutador hasta el nodo en conflicto, de forma ilimitada hasta alcanzar el valor que hayamos definido para infinito. Veamos un ejemplo de ello:

Inicialmente A est desactivado. Cuando A se activa, B se entera de que A existe al recibir su vector distancia y actualizar su tabla indicando que A dista 1. El nodo C se entera de que A existe porque B le indica que tiene un enlace hacia A de coste 1. Entonces C actualiza su tabla registrando una trayectoria hacia A de coste 2. Si el nodo A se desconecta entonces B no recibe el VD de A. Sin embargo el nodo C le dice que tiene una trayectoria hasta A de distancia 2. B no sabe que la trayectoria de C a A pasa por el mismo y por tanto cree que puede llegar a A a travs de C por lo que actualiza su tabla registrando la distancia 2 + 1 = 3 hasta A En el siguiente intercambio, el nodo C comprueba que sus vecinos B y D tienen una trayectoria hasta A de distancia 3. C calcula su propia distancia hasta A en 3 + 1 = 4. En los siguientes intercambios, los nodos elevan ilimitadamente su distancia a A (cuenta a infinito).

Llegar un punto en que el conteo alcance el valor mximo (infinito), llegado a este punto el nodo de destino pasa a clasificarse como inaccesible. El mismo problema ocurrira si usramos cualquier otra mtrica en vez de los saltos, como el retardo medio. Por tanto, queda claro que las noticias malas llevan muchsimo ms tiempo para ser detectadas, hecho que suceder cuando todos los nodos hayan escrito en sus tablas el valor de infinito para alcanzar el enrutador cado. Existe solucin para el conteo infinito? Una de las medidas prudentes para evitarlo consiste en definir valores lgicos para infinito, preferiblemente que ste sea igual a la ruta ms larga de nuestra subred ms 1 (si la mtrica son los saltos), o un valor ligeramente alto pero prudente si la mtrica es el retardo medio (para asegurarnos que todos los paquetes llegarn por muy lenta que sea la ruta). De sta forma lograremos que tardemos menos en alcanzar el valor infinito y con ello detectar antes el enrutador fallido. La esencia del problema reside en que cuando X pregunta a Y si dispone de alguna ruta para llegar hasta Z y Y le responde, X es incapaz de averiguar si en la ruta que le ha propuesto Y est tambin incluido el mismo. Como puede observarse, realmente es un problema difcil de solventar ya que se halla en el propio funcionamiento interno del algoritmo.

Adems de tomar precauciones con el valor definido para infinito, otra medida a tomar sera modificar ligeramente el algoritmo de enrutamiento para evitar que un nodo informe a su vecino sobre la distancia que conoce hasta el nodo X cuando la trayectoria hacia X pasa a travs de ese nodo vecino, en su lugar, le informar de que la distancia es infinita. Dicha tcnica se conoce como Recorte por Horizonte dividido y permite que las noticias malas se propaguen con tanta rapidez como las buenas (a N saltos). No obstante, esto no se trata de una solucin definitiva al problema de conteo infinito, ya que dicha tcnica no es til para todas las topologas posibles de red, aunque si logra minimizar bastante su aparicin. Existen algoritmos de encaminamiento como los de Estado de Enlace que no sufren de este tipo de problemas. * Puntos positivos: Algoritmo dinmico de mecnica simple Encuentra eficazmente la ruta ptima

* Puntos negativos: Problema del conteo al infinito Requiere el intercambio de mucha informacin entre routers Reacciona lento a problemas en la red (enlaces rotos)

2.3.1.2.2 Enrutamiento por estado del enlace (Link State Routing) El enrutamiento por vector de distancia fue usado en ARPANET hasta que fue substituido por el de estado de enlace, la razn principal fue la necesidad de solventar el problema del conteo hasta el infinito que tenda a aparecer con bastante frecuencia. A todo esto se unieron distintos cambios en la infraestructura de la subred que aumentaba el ancho de banda de diversas rutas (la mayora de zonas transmitan a 56 kbps pero otras lo hacan a 230 kbps o incluso 1.544 Mbps), pero la mtrica vigente no tena en cuenta el ancho de banda para el clculo del coste; as que entre ambas cosas decidieron cambiar por completo el algoritmo de enrutamiento usado (lgicamente para cambiar nicamente la mtrica no hubiera sido necesario cambiar de algoritmo). El concepto en el que se basa el enrutamiento por estado del enlace es sencillo y puede dividirse en siete pasos: 1) Descubrir a sus vecinos y conocer sus direcciones de red. 2) Medir el retardo o costo para cada uno de sus vecinos. 3) Construir un paquete que indique todo lo que acaba de aprender. Dicho paquete no ser necesario volver a construirlo a no ser que se produzcan cambios importantes que deban ser comunicados a toda la subred (por ej. la cada o reactivacin de un enrutador). 4) Enviar este paquete a todos los dems enrutadores (mediante inundacin por ejemplo).

5) Calcular la ruta ms corta a todos los dems enrutadores (Dijkstra, Shortesth Path). * Los pasos 3-5 debern repetirse cada vez que se produzca una actualizacin importante en la red. Como puede observarse, el algoritmo por estado de enlace es una especie de versin dinmica del de enrutamiento por la ruta ms corta. En vez de crear manualmente un grafo de nuestra subred para posteriormente calcular la ruta ptima mediante algn algoritmo como el de Dijkstra, y luego introducir los datos en las tablas de encaminamiento uno a uno; el enrutamiento por estado de enlace realizar por nosotros y de forma automtica dicho proceso. Veamos los siete pasos de forma detallada: 1) Conocimiento de los vecinos: Cuando un enrutador se pone en funcionamiento, lo primero que hace es intentar averiguar quines son sus vecinos; para ello enva un paquete especial del tipo HELLO (por inundacin por ej.) por cada lnea de salida. Los routers que reciban dicho paquete respondern con una identificacin nica (direccin IP). 2) Medicin del costo de la lnea: En el algoritmo por estado del enlace es necesario que cada enrutador sepa el retardo asociado a cada uno de sus vecinos, para ello enviar un paquete especial del tipo ECHO a travs de todas las lneas de salida. Una vez los routers reciban dicho paquete, debern devolverlo inmediatamente. Para calcular el retardo medio, se sumar el tiempo de ida y vuelta del paquete, y se dividir entre dos. De esta forma, el enrutador puede tener una idea aproximada de lo que tardara un paquete en llegar hasta cada uno de sus vecinos. Con este mtodo estamos teniendo en cuenta que los retardos son simtricos (se tarda lo mismo en ir de A a B que de B a A), lo cual no siempre es cierto. Esta operacin puede repetirse cada T mseg y usarse el promedio obtenido, de esta forma obtendremos unos resultados muy precisos. Cuando calculamos el retardo medio se puede tener en cuenta la carga o no. En el primer de los casos, deberamos iniciar el temporizador des de el momento en que el paquete ECHO ha sido puesto en cola en el enrutador de destino; de esta forma, se tendr en cuenta el tiempo que tardar en ser procesado nuestro paquete en base a lo llena que est la cola del dispositivo (carga). En el caso de que no deseemos tener en cuenta dicha carga, bastar con iniciar el temporizador des de el momento en que el paquete pasa a ser tratado (el dispositivo ya termin de procesar los paquetes recibidos con anterioridad). Qu es ms til? Hay argumentos a favor tanto para la inclusin de la carga en el retardo medio como para la exclusin. Por un lado, si decidimos incluir el retraso inducido por la carga de la lnea, permitiremos que antes dos o ms lneas con el mismo ancho de banda, el enrutador escoja aquella con menor carga. Lo que se traducir en una mayor eficiencia. En contraste, podra darse el problema de que aparecieran oscilaciones en nuestra red debido al clculo del retardo medio incluyendo la carga. Estas oscilaciones apareceran cuando existen pocas lneas a travs de las cuales debe pasar un gran cantidad de trfico proveniente de distintas zonas de nuestra subred, y una de ellas se encuentra altamente sobrecargada; ante dicha situacin el algoritmo decidir que la mejor ruta es la otra lnea, y ahora reenviar todo el trfico a travs de sta, hasta que tambin se sature, y decida que la mejor vuelva a ser la

otra, y as sucesivamente, el algoritmo ira intercambiando entras las dos posibles rutas. Esto no tan slo puede provocar un enrutamiento errneo sino tambin la aparicin de problemas potenciales. Una fcil solucin al problema sera la adicin de ms lneas de transmisin, as como una divisin equitativa de la carga de la subred entre dichas lneas. Trminos: * Carga de la lnea (nos referimos a la cantidad de paquetes que tenga en cola el enrutador, es decir, pendientes por procesar. Una cola de gran capacidad evita la saturacin del dispositivo, y en consecuencia de la lnea. As pues, la carga de la lnea depende de la capacidad de la memoria del enrutador). * Ancho de banda de la lnea (contra mayor sea el ancho de banda de la lnea, es decir, la cantidad de bits por segundo que sea capaz de transmitir, antes llegarn los paquetes a destino; por lo que el retardo medio depende proporcionalmente del ancho de banda de la lnea usada para el envi).

3) Construccin de los paquetes de estado del enlace: Una vez ya hemos identificado a todos nuestros vecinos, y tenemos los retardos (costes) asociados a stos; ya podemos escribir toda esta informacin en un paquete que enviaremos a travs de todas las lneas de salida. El interior del paquete contendr la identidad del emisor, seguida de un nmero de secuencia, una edad (que describiremos despus) y una lista de vecinos con los retardos asociados. A Secuencia Edad C 3 E 7

Cundo se construirn los paquetes de estado del enlace? Cada T mseg (peridicamente) o cada vez que se produzca algn cambio significante en la subred (por ej. la cada o reactivacin de un router). 4) Distribucin de los paquetes de estado del enlace: La parte ms compleja del algoritmo es la distribucin ptima de paquetes de estado del enlace. De igual forma que en los pasos 1 y 2, recurriremos a la distribucin por inundacin para distribuir dichos paquetes; tremendamente til cuando desconocemos como llegar a todos los enrutadores de nuestra subred y deseamos enviar informacin a todos ellos. Como ya vimos cuando hablbamos del enrutamiento por inundacin (flooding), una de las tcnicas usadas para evitar la redundancia de paquetes (duplicados) es la etiquetacin de cada paquete con un nmero de secuencia. Cuando un enrutador reciba un paquete de estado del enlace, comprobar su nmero de secuencia y el enrutador emisor, y lo comparar con el contador de secuencias; si el nmero recibido es ms alto que ste, significa que el paquete aun no ha sido visto, si en cambio su valor es inferior, lo descartar.

El uso de nmeros de secuencia conlleva toda una serie de problemas a los que debemos encontrar solucin: 1) Que suceder cuando alcancemos el valor mximo para los nmeros de secuencia y debamos volver a empezar desde 0. 2) Si un enrutador se cae y al reactivarse vuelve a empezar desde 0, como debemos actuar. 3) Si por la causa que sea, se corrompiera un solo bit del nmero de sec. El nmero enviado sera otro totalmente distinto, anulando todos los paquetes que posteriormente enviemos con un nmero de sec. inferior. Para tratar de solucionar todos estos conflictos usaremos adems de un nmero de secuencia, un temporizador descendente al que lo llamaremos Edad. Cada paquete de estado del enlace contendr en su cabecera, como ya vimos antes, la edad de ste; es decir, su duracin en segundos antes de ser eliminado. Cada 1 segundo, se disminuye en 1 el valor de la Edad; cuando alcance el valor 0, se descartar la informacin del enrutador que recibi el paquete. Otro dato importante, es que todos los paquetes de este tipo recibidos deben ser confirmados al enrutador emisor conforme los hemos recibido correctamente, para ello se enviar un paquete especial de confirmacin del tipo ACK. Un refinamiento del algoritmo descrito consistira en retener durante un breve periodo de tiempo los paquetes de estado del enlace recibidos, en prevencin de que nos llegue otro ms actualizado durante este espacio de tiempo. En caso de ser as, se comprueban los nmeros de secuencia, si coinciden, se desecha el duplicado, sino se elimina el ms viejo. De sta forma logramos reducir ligeramente el trfico generado por inundacin y minimizamos la cantidad de informacin antigua que enviamos a los dems enrutadores. Por otro lado, si recibimos un duplicado de un paquete mientras el original an se encuentra en el buffer del enrutador (almacenado), antes de desecharlo deberemos actualizar las banderas (flags) de transmisin y confirmacin, con el fin de reflejar el nuevo estado. Origen Secuencia Edad Banderas de Banderas de Datos envo confirmacin (ACK) A C F A C F 0 1 1 1 0 0 1 1 0 0 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 0 0 1 1

A F E C D

21 21 21 20 21

60 60 59 60 59

5) Clculo de las nuevas rutas: Una vez que un enrutador ha recibido los paquetes de estado de enlace de todos los nodos de la subred, ya puede construirse una especie de grafo lgico (virtual) sobre sta; para posteriormente, ejecutar el algoritmo de Dijkstra y hallar las rutas ms cortas a todos los destinos posibles. En el caso de subredes grandes puede resultar un problema la enorme cantidad de informacin que deberemos guardar acerca de la subred en cada enrutador. El tiempo de cmputo de Dijkstra en estos casos tambin puede convertirse en un problema.

* Estado de enlace vs Vector distancia: Convergencia. El algoritmo por vector distancia tarda demasiado en converger an con la tcnica del horizonte dividido. Informacin de la red. En encaminamiento por vector distancia, cada router enva informacin slo a sus vecinos, pero esta es sobre toda la red. Sin embargo el encaminamiento por EE enva a todos los nodos de la red, pero su informacin es relativa a sus vecinos. Adems el enrutamiento por vector distancia no permite conocer la topologa de la red. Capacidad y uso de memoria. Con algoritmos basados en estado de enlace, el trfico de la red siempre es el mismo sin depender del tamao de la red. Con vectores distancia, se transmiten vectores de un tamao proporcional al nmero de nodos. El routing por vector distancia slo guarda las distancias al resto de nodos. Con estado de enlace se ha de almacenar adems la topologa de la red. Sucesos en la red. Al no tener informacin sobre la topologa, el routing por vector distancia no se adapta tan bien a los cambios en la red como el basado en estado de enlace. Sin embargo, el encaminamiento basado en vector distancia es mucho ms sencillo que el de estado de enlace, lo que en ocasiones puede resultar bastante til.

2.4 Calidad del Servicio (QoS) * Cmo se define?: Podemos definir la calidad del servicio en base a: la confiabilidad (probabilidad de que se pierda un paquete), retardo, fluctuacin (diferencia en retardo entre paquetes), y ancho de banda. * Requisitos de las aplicaciones:

* Tcnicas para alcanzar buena calidad de servicio: Sobreaprovisionamiento (red entera): Es una solucin fcil pero costosa. Consiste en disponer de un buen equipamiento en toda nuestra red, y el cual pueda asegurarnos sobradamente capacidad de enrutamiento, espacio en bfer y ancho de banda. Almacenamiento en buffer (cliente): Los paquetes recibidos pueden ser almacenados en un buffer antes de ser entregados. Normalmente este buffer se trata de una pequea memoria ubicada en la tarjeta de red del host. Mediante esta tcnica incrementamos ligeramente el retardo (ya que los paquetes no son entregados

inmediatamente), pero a cambio reducimos drsticamente la fluctuacin; ya que todos los paquetes se vaciarn del buffer de forma simultnea. Dicha tcnica es til en el campo de la transmisin en tiempo real de audio y video; de hecho la mayora de reproductores multimedia, antes de empezar a retransmitir un contenido de forma remota, llenan un buffer interno con los primeros segundos del archivo. Modelado de trfico (empresa de telecos): Adaptar el trfico al tipo de uso que le daremos a la conexin. Consiste en que usuario y empresa de telecomunicaciones lleguen a un acuerdo para adaptar el trfico de la lnea contratada. Dicha adaptacin suele consistir en un control del flujo de los datos, para que sta sea lo ms constante y continua posible (velocidad de transmisin de los datos). Reservacin de recursos (enrutador): Se pueden reservar tres tipos de recursos: ancho de banda, espacio de bfer, y ciclos de CPU. La reserva de recursos requiere que todos los paquetes de una misma aplicacin transcurran a travs de una ruta concreta de routers, lo cual es un concepto muy prximo al de establecimiento de conexin. Lo que hacemos pues, es reservar recursos para este flujo de paquetes en todos los enrutadores que hemos seleccionado para dicho flujo. Calendarizacin de paquetes: Consiste en adoptar algn tipo de tcnica que defina en qu orden enviaremos los paquetes de los distintos flujos recibidos; esto se hace necesario para evitar que un emisor rpido ocupe todo el ancho de banda de un enrutador, empeorando la calidad de servicio de los emisores ms lentos. Existen distintos algoritmos que dan solucin a tal problema, uno de los ms usados es el de encolamiento justo ponderado. Consiste en dar prioridad a aquellos servicios que necesiten un mayor ancho de banda (por ej. servidores de video en tiempo real), sin llegar a asfixiar a los dems tipos de conexiones. En el encolamiento justo ponderado se retransmite una cantidad N de bytes durante cada pulso de reloj (virtual) de cada paquete que quiera usar una misma lnea de salida; la cantidad de bytes transmitidos dependern del ancho de banda estimado para esa conexin. Con cada pulso de reloj cambiamos de paquete, de esta forma logramos un uso justo de la conexin a la vez que proporcionamos mayor ancho de banda a las aplicaciones que realmente lo requieran.

* Servicios integrados: Los servicios integrados hacen referencia al diseo de arquitecturas para la multimedia de flujos continuos. A este mtodo se le conoce como calidad de servicio basada en flujo. El principal protocolo usado en servicios integrados es RSVP (Protocolo de reservacin de recursos). Para ms informacin sobre el RSVP consultar libro pg. 410. * Servicios diferenciados (DiffServ): Los servicios integrados requieren configuraciones avanzadas para cada flujo y complejos intercambios entre los enrutadores a travs de los cuales transcurre el flujo. Por ello, existen pocas implementaciones de RSVP o algo parecido. Los servicios diferenciados pueden implementarse de forma local en cada enrutador y sin que toda la ruta est involucrada. A este mtodo se le conoce como calidad de servicio basada en clase y consiste en clasificar los paquetes entrantes segn la clase a la que pertenezcan

(transferencia de archivos, correo, etc.) asignando a cada una un buffer distinto, posteriormente los paquetes son enviados en base a la preferencia de su clase. La empresa de telecomunicaciones tiene una serie de recursos estndar destinados a cada tipo de servicio, por ej. todas las transferencias de archivos obtienen los recursos reservados para dicha clase. En cambio, en el caso de los servicios integrados se reservan recursos de forma individual y privada para cada flujo. 2.5 Fragmentacin y Reensamblaje Internet est formada por un conjunto de subredes, donde cada una impone un tamao mximo de paquete (debido a variaciones en el hardware, protocolos, u otras razones). Si deseamos enviar un paquete a travs de una subred, con un tamao superior al mximo permitido por sta, el paquete ser rechazado. La solucin pasa por dividir aquellos paquetes que se excedan en tamao, en mltiples fragmentos pequeos, para posteriormente enviarlos independientemente a su destino. Una vez estos hayan llegado a su destino, sern reensamblados de nuevo pudiendo restaurar el mensaje original. Existen dos mtodos distintos para el reensamblaje de los fragmentos: 1) Fragmentacin transparente: Cuando un paquete de tamao superior al mximo permitido por una subred determinada llega a la puerta de enlace de entrada (lo ms probable es que trate de un enrutador especializado); sta lo divide en fragmentos. Dichos fragmentos son transmitidos a travs de la subred hasta alcanzar la puerta de enlace de salida (en el caso de que la subred actual no sea la de destino), dnde los fragmentos sern reensamblados de nuevo antes de ser transferidos a una nueva subred; de esta forma logramos hacer transparente el proceso de fragmentacin ocultndolo a las dems subredes. Alguno de los problemas de la fragmentacin transparente es que requiere saber si ya han llegado todos los fragmentos para proceder a su reensamblaje, lo que supone tener que usar contadores o bits de final de paquete en cada paquete; otro problema es que al obligar a todos los fragmentos a pasar a travs de la misma puerta de enlace, stos debern seguir la misma ruta con la disminucin de rendimiento que ello conlleva; y finalmente, la sobrecarga producida por los procesos de fragmentacin y reensamblaje de cada subred de tamao de paquete pequeo por la que transcurran nuestros datos es significativa. Las redes ATM usan este tipo de fragmentacin (o segmentacin en este caso). 2) Fragmentacin no transparente: Cuando un paquete entra por primera vez en una subred de tamao mximo de paquete pequeo, y debe ser fragmentado; no volver a reensamblarse hasta alcanzar el host de destino. Los fragmentos generados sern tratados como paquetes independientes y circularn a travs de todas las subredes necesarias hasta alcanzar su destino. Como puede observarse, en este caso la fragmentacin no se oculta; no es transparente. La fragmentacin no transparente tambin acarrea con una serie de problemas; por ejemplo, requiere que todos los hosts de destino sean capaces de reensamblar los fragmentos recibidos. Otro inconveniente sera la sobrecarga total que generamos en todas las subredes por las que transcurran nuestros fragmentos, ya que, estos deben incluir sus propias

cabeceras; aumentando ligeramente la cantidad de bytes transmitidos. Adems, como los fragmentos no sern reensamblados hasta alcanzar el nodo de destino, dicha sobrecarga ser arrastrada a travs de todas las subredes usadas. En contraste, este mtodo tiene una ventaja, y es que permite usar puertas de enlace de salida distintas, lo que se traduce en una mayor eficiencia. Las redes IP usan fragmentacin no transparente.

- Sistema de numeracin de fragmentos: Usar un sistema de numeracin de paquetes en rbol, es decir, el paquete 0 lo dividimos en los fragmentos 0.0, 0.1, 0.2, etc.; conlleva un gran inconveniente, y es que un mismo paquete podra ser fragmentado de forma distinta durante un reenvo del mismo. Es posible que alguno de los fragmentos enviados originariamente se pierdan o corrompan, en tal caso, deberemos reenviar de nuevo el paquete entero; pero podra ocurrir que esta vez la ruta elegida pasara a travs de una subred distinta, y el paquete se dividiera en una cantidad de fragmentos tambin distinta, enumerndolos con unos dgitos ya usados anteriormente durante el primer envo, esto provocar que el reensamblaje resulte errneo. Precisamente para evitar esta diferencia en el tamao de los fragmentos creados, se usar un tamao de fragmento elemental; suficientemente pequeo para que pueda ser aceptado por cualquier subred de Internet. Dicho tamao ser definido por el protocolo de la capa de red que usemos (IP o cualquier otro), y dividir el paquete original en fragmentos iguales al tamao de fragmento elemental; menos el ltimo fragmento, que se permitir que sea ms pequeo. Los bytes necesarios para almacenar la cabecera de los fragmentos no se tienen en cuenta en el anlisis del tamao del paquete; es decir, las subredes solo comprueban el tamao de carga til. En el encabezado del paquete se almacenar el nmero de paquete (el cual lo identifica), el nmero del primer fragmento de tamao elemental de este paquete, y el bit usado para indicar el fin de paquete (el bit 1). A continuacin se escribiran los datos que deseemos transferir. Las redes con protocolo IP utilizan una medida de fragmento elemental de 8 bytes (64 bits). Por lo que, todos los tamaos elementales debern ser mltiples de 8 bytes (16 bytes, 24 bytes, 32 bytes, 40 bytes, etc.)

2.6 Servicio de la capa de red (IP) La capa de red usa varios protocolos que se encargan de distintos aspectos. En el caso de la comunicacin entre dos sistemas, hablamos del protocolo IP (Internet Protocol), cuya funcin es asegurarse de que todos los datagramas enviados lleguen correctamente a su destino. Tambin existen otro tipo de protocolos diseados para otras funciones; como los de control (ICMP, ARP, DHCP, etc.), los de enrutamiento, etc.

El servicio proporcionado por la capa de red consta de dos primitivas: send (enviar) y deliver (entregar). La primera de ellas se usa para enviar un paquete, y requiere los siguientes parmetros: identidad del datagrama, indicacin de fragmentacin, y tiempo de vida. En contraste, deliver() se usa para recibir un paquete. 2.6.1 Datagrama IP: Un datagrama IP consta de una cabecera (header) ms los datos que deseemos transmitir. La cabecera tiene una parte fija de 20 bytes y una parte opcional de tamao variable. Veamos una ilustracin de un datagrama IPv4:

* Los campos de la cabecera del datagrama se transmiten de izquierda a derecha; empezando por el bit de mayor peso del campo Versin. * - Versin IP: indica que versin del protocolo IP se est usando (IPv4 o IPv6). - Longitud de la cabecera (IHL): Indica cuantas palabras de 32 bits contiene la cabecera (incluyendo tanto la parte fija como las opciones). Como hemos visto anteriormente, la longitud mnima de la cabecera (sin opciones) es de 20 bytes, es decir, 160 bits; o lo que es lo mismo 5 palabras de 32 bits (5 * 32= 160). Este campo usa 4 bits para codificar la longitud de la cabecera, as que el nmero mximo en binario que podemos representar es 2-1 (nmero 15); y 15 palabras de 32 bits equivalen a una longitud mxima para la cabecera de 60 bytes, pero teniendo en cuenta que 20 bytes equivalen a la parte fija del encabezado obtenemos: 20 bytes + 40 bytes en opciones= 60 bytes mximos totales. - Tipo de servicio: Indica el tipo de servicio al que pertenece el paquete (transferencia de archivos, video en tiempo real, correo, etc.). Este campo solo tiene sentido en los sistemas diferenciados (DiffServ); tal y como ya vimos en el apartado anterior. Actualmente, la mayora de routers por defecto omiten dicho campo, a no ser que se les indique lo contrario. - Longitud total: Longitud total del datagrama IP; incluyendo la cabecera (parte fija + opciones) y los datos. La longitud mxima es de 65.535 bytes, actualmente este lmite es suficiente.

- Identificacin del datagrama: Etiqueta que permite identificar a un datagrama y totalmente necesario para el correcto reensamblaje de fragmentos recibidos en un host de destino. - DF / MF / Identificador del fragmento: DF (Dont fragment), significa no fragmentar. Esta bandera (flag) indica a los enrutadores que reciban el datagrama que no lo fragmenten ya que el host de destino ser incapaz de reensamblarlo. Para que el reensamblaje pueda llevarse a cabo se requiere que todas las mquinas puedan trabajar con fragmentos de 576 bytes o menos (IP usa un tamao elemental de fragmentos de 64 bytes). MF (More fragments); significa ms fragmentos e indica si faltan ms fragmentos de un mismo paquete por recibir. Todos los fragmentos deben establecer este bit a 1, menos el ltimo. Identificador del fragmento; indica el nmero de fragmento del datagrama. Dado que el tamao del campo es de 13 bits, como mximo podemos dividir un paquete en 8192 fragmentos. - Tiempo de vida (TTL): Se trata de una especie de contador que disminuye con cada salto realizado por el paquete. Si el TTL de un datagrama determinado es de 63, el paquete expirar tras realizar 63 saltos; de esta forma, nos aseguraremos de que ningn paquete pueda quedarse navegando eternamente si se produciera algn tipo de error al enrutarlo. Cuando el contador de un datagrama llega a 0, se enva un paquete de aviso al host origen. - Protocolo de destino: Este campo codifica el protocolo de nivel de transporte al que va destinado este paquete (normalmente TCP o UDP). Est unificado para todo el mundo en Nmeros de protocolos por la IANA (Internet Assigned Numbers Authority). - Suma de verificacin del encabezado (Checksum header): Verifica que no existan errores en la cabecera del datagrama; dicha verificacin se realiza en cada enrutador a travs del cual pase nuestro paquete. Cuando ste llegue a su destino, este campo deber tener un valor igual a 0 si no se han producido errores en la cabecera durante su transmisin. El simple hecho de que exista como mnimo un campo que va cambiando en la cabecera con cada salto, el tiempo de vida, ya hace necesario el chequeo continuo de errores en sta. - Direccin origen / Direccin destino: Son las direcciones IP de los host de origen y destino, respectivamente. - Opciones: Las opciones se disearon con el fin de poder aadir nuevas funcionalidades en el futuro que no se hubieran tenido en cuenta en el momento de disear la cabecera IP. Cada opcin debe empezar por un cdigo de 1 byte que la identifica; a continuacin, algunas opciones incluyen un campo de longitud de la misma de 1 byte. Finalmente, se aadiran los datos (1 o ms bytes). Se definieron 5 opciones bsicas aunque actualmente se han agregado algunas ms: * Seguridad: Especifica qu tan secreto es el datagrama (por ej. en redes militares que quieran enrutar los datagramas a travs de distintos pases segn el nivel de seguridad indicado por stos). No obstante, todos los enrutadores lo ignoran, as que esta opcin solo sirve para que los espas puedan realizar su trabajo con mayor facilidad.

* Enrutamiento estricto desde el origen: En dicho campo debe escribirse la ruta completa desde el host de origen hasta el de destino mediante la escritura de las direcciones IP de los enrutadores por lo que deseemos que pase nuestro paquete. Esta opcin suele ser til cuando se han corrompido tablas de enrutamiento. * Enrutamiento libre desde el origen: Indica una lista ordenada de routers a travs de los cuales queremos obligar a que pasen nuestro paquetes, pero se les permite pasar tambin a travs de otros enrutadores en el camino. Esto suele ser til para dirigir la direccin de nuestra ruta, pudiendo indicar por ejemplo, enrutadores situados al Oeste o Este de nuestra posicin actual. til para evitar ciertos pases o zonas. * Registrar ruta: Obliga a todos los enrutadores por los cuales pase el datagrama, a que registren su direccin IP en este campo. El problema de esta opcin, es que, como ya hemos visto antes, el tamao mximo para las opciones es de 40 bytes, siendo una cifra bastante pequea e insuficiente como para poder almacenar las direcciones de todos los enrutadores por los que pase nuestro paquete (podra llegar a recorrer 50 enrutadores o ms). De hecho, es por este motivo que las tcnicas de trace route (trazado de ruta), usadas para reconstruir la ruta seguida por un determinado paquete, no usan dicha opcin de la cabecera para tal tarea, sino que en su lugar usan el campo TTL (tiempo de vida). * Marca de tiempo: Esta opcin es exactamente idntica a la de registrar ruta, pero adems, aade una marca de tiempo de 32 bits.

2.6.2 Direcciones IP Cada host y enrutador debe disponer de una identificacin nica de red, una direccin IP. En el caso de los enrutadores debe ser pblica (visible para las dems maquinas), en los host se usan IPs privadas (solo visibles para nuestra LAN). Si un host perteneciera a dos redes distintas, debera tener asignadas de igual forma, dos direcciones IP privadas; aunque esto es algo realmente poco frecuente. Las direcciones IPs constan de 4 octetos separados por un punto, es decir, 4 bytes o 32 bits (1 octeto= 1 byte). El mximo nmero representable con 32 bits es 4.294.967.296; que es el nmero mximo de dispositivos que podemos identificar en una red IPv4. Adems, stas acostumbran a clasificarse en clases, esta categorizacin recibe el nombre de direccionamiento con clase (classful addressing). Actualmente est en desuso. Veamos un ejemplo ilustrativo:
1.0.0.0 127.255.255.255 128.0.0.0 191.255.255.255 192.0.0.0 223.255.255.255 224.0.0.0 239.255.255.255 240.0.0.0 255.255.255.255

Con las redes de tipo A, podemos direccionar hasta 128 redes con un mximo de 16 millones de hosts cada una; con las de tipo B, hasta 16.382 redes con 64.000 hosts cada una; y finalmente, las de tipo C, con 2 millones de redes con 256 hosts cada una. Las direcciones IPs son administradas y concedidas por el ICANN (Corporacin de Internet para la Asignacin de Nombres y Nmeros) para evitar conflictos. Dicho organismo tambin se encarga del control de los nombres de dominio (por ej. www.google.es). Hay algunas direcciones IP que estn reservadas para determinadas funciones: * 0.0.0.0: Se usa para hacer referencia al propio host. Esta direccin nicamente es usada por los hosts cuando estn arrancando y an no disponen de una direccin IP privada. * Todo 0 en el campo Red: indica que nos estamos refiriendo a la red en la que nos encontremos. A continuacin introduciramos un nmero de host; 0 si nos queremos referir a nosotros mismos (en tal caso, sera igual al caso anterior), o cualquier otro identificador de host de nuestra red. * 255.255.255.255 (Todo 1): Permite la difusin del mensaje a nuestra red local (LAN). * Red / host= todo 1: Si escribimos un nmero de red y a continuacin todo unos para el host, conseguiremos difundir el mensaje a todos los hosts de la red remota indicada. * 127.x.y.z: Se reservan para direcciones locales de prueba (loopbacks). Los paquetes no llegan a salir, simplemente se procesan y se tratan como si fueran paquetes de entrada. ------------------------------------------------------------------------------------------------------------------------------ Subredes: Las subredes surgieron en respuesta a la necesidad de solucionar uno de los mayores problemas a la hora de conectar varias redes entre s. Imaginmonos, que actualmente usamos una red X mediante Mascara de subred= numero de bits usados para la clase + la red+ la subred. Indicados con una barra; por ej. /22. Se excluyen los bits para el host. Otra forma es mediante octetos; poniendo un 1 a todos los bits usados, y un 0 a los no usados (aquellos que hayamos asignado para el host). CIDR (Direccionamiento sin clase)= Creado para solucionar los problemas con las clases de IP. Las de tipo B estn muy pedidas pero se desperdician mucho sus capacidades. Adems cuesta mucho mantener tablas de routing por cada clase; pesadas y con miles de entradas. Son complejas de mantener y costosas de transferir entre routers. Dichas tablas contienen dos tipos de direcciones IP, las que indican redes o subredes ajenas, y de las que no necesitamos saber los direcciones de sus host, y las que hacen referencia a la propia red o subred, de las cuales si conocemos TODOS los host. De esta forma, simplificamos la cantidad de datos en las tablas. Por esta razn, se cre la tcnica CIDR.

Consiste en asignar direcciones IP en bloques que sean potencia de 2, por ej. si pides 2000 direcciones te darn un bloque de 2048 direcciones IP. Con CIDR lo que se consigue es optimizar la asignacin de las escasas direcciones IPv4 y reducir el tamao de las tablas de enrutamiento permitiendo agrupar las direcciones IP en bloques CIDR, donde diversas direcciones comparten un mismo nmero determinado de bits. Los primeros cuatro nmeros decimales se interpretan como una direccin IPv4, y el nmero tras la barra es la longitud de prefijo, contando desde la izquierda, y representa el nmero de bits comunes a todas las direcciones incluidas en el bloque CIDR. Decimos que una direccin IP est incluida en un bloque CIDR, y que encaja con el prefijo CIDR, si los N bits iniciales de la direccin y el prefijo son iguales. Por tanto, para entender CIDR es necesario visualizar la direccin IP en binario. Dado que la longitud de una direccin IPv4 es fija, de 32 bits, un prefijo CIDR de N-bits deja 32 N bits sin encajar, y hay 2(32 N) combinaciones posibles con los bits restantes. Esto quiere decir que 2(32 N) direcciones IPv4 encajan en un prefijo CIDR de N-bits, estas direcciones indican la cantidad de hosts que puede almacenar con dicha direccin.

NAT (Network Adress Traductor): El problema de CIDR era que, por ejemplo, para una red /16, que permite 2 a la 16, es decir, 65.534 hosts. Los ISP solo podan mantener con esa direccin a 65.534 PCs de forma simultnea (1 por IP). Esto unido a que la mayora de clientes, ya sean de empresas o particulares, usan conexiones de Internet por cable o ADSL mediante el uso de routers (los cuales mantienen fija la conexin), no es til usar IPs dinmicas que puedan ser asignadas dinmicamente conforme los clientes realicen una llamada al ISP, ya que, ya lo estn de conectados la mayora del tiempo. Para solventar los problemas de escasez de IPs, mientras no acaba de implementarse IPv6, se pens en NAT. Con NAT se asigna una sola IP pblica (o un grupo pequeo de ellas) por cliente, mientras que cada PC dispone de una IP privada que lo identifique dentro de la LAN.

Cuando deseemos enviar un paquete a Internet, lo que hace NAT, es que traduce la direccin IP origen (algo del tipo 192.168.0.0) a la direccin IP pblica real suministrada por el ISP. Pero, cmo sabe un paquete entrante a que PC debe dirigirse? Ya que en la cabecera IP solo almacenamos la direccin destino pblica, no la privada. La solucin es analizar los puertos TCP o UDP usados en la conexin. De igual forma que, las IPs identifican exclusivamente a cada enrutador, los puertos realizan una funcin anloga para las conexiones, las identifican de forma exclusiva. No podr existir jams dos conexiones TCP a una misma direccin IP, usando los mismos puertos; si los puertos de destino son distintos s que sera posible. Ahora, cuando enviamos un paquete, la NAT introduce en ste su direccin IP pblica, pero adems tambin aade en la cabecera del segmento TCP el puerto de origen; el cual es substituido por otro contenido en una tabla de la NAT para evitar que dos PCs que usan el mismo puerto origen puedan entrar en conflicto. Toda esta informacin es almacenada en una tabla, por ejemplo: 192.168.0.20:5000. Indica que todas las conexiones TCP que vayan dirigidas al puerto 5000, sus paquetes directamente sern enviados al PC interno con IP 192.168.0.20. Al recibir un paquete, NAT examina el puerto de destino contenido en el segmento TCP, y comprueba si existe en la tabla. Por ejemplo, un servidor web deja el puerto 80 abierto para recibir peticiones. Dicha informacin estara reflejada en la tabla NAT, para permitir conexiones entrantes a travs de dicho puerto. Problemas: * Se pierde la esencia de que una IP identifique nica y globalmente a cada mquina, ya que, con NAT una sola IP pblica puede esconder a cientos de PCs. * Si se destruye o se pierde el contenido de una caja NAT, se pierden todas las conexiones TCP. En este sentido convierte a Internet en una especie de red orientada a la conexin; insegura y vulnerable. Sin NAT, si un enrutador de un cliente es destruido, simplemente reenviaremos los paquetes no confirmados de nuevo, con NAT deberamos empezar de nuevo. * Viola la independencia entre capas. Ya que la capa IP conoce en que campo de la capa TCP se encuentran codificados los puertos. Por lo que, si algn dia se cambia el protocolo TCP por otro, o se aade algn tipo de cambio (puertos de 32 bits, por ej.); NAT dejara de funcionar correctamente. * Dependencia de los protocolos TCP y UDP. Si una aplicacin decide usar un protocolo distinto, y en consecuencia con una cabecera diferente a TCP o UDP; la caja NAT no podr hallar el puerto de origen, y la conexin no se podr llevar a cabo. * Lmite de ordenadores por IP en 61.440, ya los puertos TCP se codifican en 16 bits (quitando los 4.000 puertos especiales reservados).

- Protocolos de control: * ICMP (Protocolo de Mensajes de Control en Internet): Define el tipo de mensaje estndar a codificar en un paquete IP segn el evento ocurrido. Hay muchos, por ejemplo, los paquetes de ICMP de tipo Time exceded, que los enrutadores envan cuando un paquete ha llegado a un TTL= 0 (usado en trace route). O los de tipo ECHO que usa el programa Ping de MS-DOS para calcular el retardo medio a un host. Ejemplos de alguno de ellos: Destination unreachable Time exceeded no puedo entregar el packete

time to live del paquete = 0

Parameter problem

algn parmetro en el header est mal

Source squelch

no me pases tantos paquetes!

Redirect

no tienes tu tabla actualizada

Echo

ests vivo?

Echo reply

si, estoy vivo?

Timestamp request

dime cundo sale tu paquete para que vea cunto tarda en llegar mi paquete sale a las 12:30:31

Timestamp reply

* ARP (Protocolo de Resolucin de Direcciones): Se trata de un protocolo de preguntas y respuestas. En una LAN (Ethernet o Wifi) cada PC tiene un identificador de red (direccin MAC en redes Ethernet o Wifi), dicha informacin es lo nico que sabe la capa de enlace de datos (por ej. la tarjeta de red de un PC). Por lo que, sta no puede enviar un paquete directamente a una IP, sino a alguna direccin MAC. Lo que ocurre pues, es que la tarjeta Ethernet enva por difusin un paquete preguntando por la IP a la que debe enviar los datos a travs de toda la LAN; recibindolo todos los hosts conectados a sta, pero nicamente contestando aquel equipo cuya IP coincida con la preguntada. De ser as, el host le enviar un paquete a la tarjeta de red con su direccin MAC. Ahora la tarjeta de red ya puede transferir los datos. Si deseamos enviar un paquete ARP a una LAN distinta, debemos configurar en la cach del ARP, que todos los paquetes dirigidos a esa LAN se enven a travs de un determinado

identificador de red (normalmente el de un Switch o router). Cuando el router recibe el paquete, comprueba la IP en sus tablas de enrutamiento, y difunde el paquete a travs de la LAN destino directamente, o lo reenvia a otro router (o switch) que se encargue de gestionar los paquetes destinados a esa red para que lo difunda. * RARP (Protocolo de Resolucin de Direccin de Retorno): El proceso inverso a ARP; dada una direccin Ethernet, proporciona la direccin IP correspondiente. Por ejemplo, si un PC quiere conectarse con un servidor de archivos para recibir datos, pero desconoce su propia direccin IP, usara RARP para averiguarla y poder as indicar al servidor web la direccin IP a la que debe enviar los ficheros. El problema de RARP es que exige un servidor de este tipo por LAN. Actualmente, NO SE USA. * BOOTP: Como el RARP pero usando mensajes UPD. En este caso, el servidor BOOTP debe guardar una tabla con pares direccin IP y MAC, para cuando reciba una solicitud de una maquina Ethernet, saber a qu direccin IP se deben enviar sus datos (la direccin IP de sta, mascara de subred, direccin de un servidor web, o lo que sea que deseemos comunicar). El problema de BOOTP es precisamente el mantenimiento de sta lista, que exige modificarla cada vez que deseemos aadir un host. * DHCP: DHCP reemplaza a RARP y BOOTP, permitiendo asignacin manual o automtica de una direccin IP. Con DHCP no es necesario que el servidor se encuentre en la misma LAN como ocurria con las anteriores alternativas; ya que ste no usa difusin. Cuando un host recin inicializado desea averiguar su direccin IP, enva un paquete del tipo DHCP Discovery por difusin a travs de su LAN. Dicho paquete es interceptado por un retransmisor DHCP, el cual se encarga de enviar todos los paquetes DHCP Discovery que encuentre a un servidor DHCP que puede encontrarse en una red distinta. El nico requisito, es que todas las LANs que quieran tener acceso a un servidor DHCP remoto, debern tener en su red un retransmisor DHCP, nada ms.

- IPv6: IPv6 y IPv4 son incompatibles a nivel de protocolo, pero si IPv6 si es compatible con otros protocolos de Internet como TCP, UDP, ICMP, OSPF, DNS, etc. * Mejoras: 1) Espacio de direcciones casi inagotable. Son de 16 bytes de longitud en vez de 4 bytes como en IPv4. 2) Simplificacin del encabezado. Contiene solo 7 campos contra los 13 del IPv4, lo que permite procesar ms rpido los paquetes, y en consecuencia mejorar la velocidad de transporte y retardo. 3) Mayor apoyo a las opciones. Campos que antes eran obligatorios ahora son opcionales, adems ahora se implementan de forma distinta; permitiendo que los enrutadores omitan opciones no dirigidas a ellos. Con lo que la velocidad de transmisin y retardo disminuirn. 4) Mejores leves en seguridad. Algunas de ellas ya fueron incluidas posteriormente en IPv4.

5) Mejor soporte para calidad de servicio. * Cabecera bsica IPv6:

* Encabezados de extensin: Una de las novedades de IPv6 es que permite aadir mltiples cabeceras destinadas a distintas funcionalidades. Estas cabeceras se aadiran a continuacin de la cabecera de tamao fijo de IPv6, y seran opcionales su adicin o no. Algunas de ellas son: Extensin Descripcin cmo manejar datagramas grandes 64kB (jumbograms) informacin para el host de destino (no utilizado de momento) lista de routers a utilizar (source routing)

Opciones de salto a salto

Opciones de destino

Opciones de routing

Opciones de fragmentacin

como en IPv4, salvo que los routers no fragmentan, sino el host remitente verificacin del remitente

Opciones de autenticacin

Opciones de encriptado

informacin sobre la encriptacin de los datos

TEMA 3: Capa de Transporte (TCP/UDP)

* Funciones: La capa de transporte se encarga del transporte confiable entre aplicaciones que deseen intercambiar datos. La capa de red no puede asegurar dicha confiabilidad. * Servicios aportados: Transmisin fiable todos los paquetes de datos llegarn al destino sin errores en el orden de envo sin duplicados Multiplexacin varias aplicaciones (o procesos) en un host pueden compartir los servicios del nivel de red los datos de una aplicacin llegan a la aplicacin adecuada en el destino Control de flujo el remitente adaptar su flujo de paquetes a la capacidad del destinatario

* Tipos de redes TCP y servicios ofrecidos:

* Primitivas de servicio: TCP (servicio orientado a la conexin) / UDP (servicio no orientado a la conexin).

Internet (UDP) Send Deliver

* Comparativa nivel de red vs nivel de transporte: Nivel de red protocolos entre routers direccionamiento de hosts Nivel de transporte protocolos entre hosts direccionamiento de procesos visible desde la aplicacin

no suele ser visible desde la aplicacin

* Establecimiento de conexiones (TCP): Para resolver el problema de los paquetes duplicados que llegan con retraso se usa la tcnica de acuerdo de tres vas (3 way handshake). Se envan paquetes enumerados con una numero de secuencia que identifica de forma exclusiva la conexin. TCP lo que hace es coger todos los bytes (octetos) que deseamos enviar, y los divide en segmentos, el numero de segmento (SEQ) usado es el del primer octeto presente en ese segmento. * Terminacin de conexiones (TCP): Consultar libro. * Control de flujo: El control de flujo ya se hace al nivel de enlace, sobre lneas fsicas de punto a punto; pero al nivel de transporte hay varios problemas aadidos: El nivel enlace no asegura un control de flujo directo entre los hosts (slo indirecto, a travs de todos los nodos intermedios) El retraso de extremo a extremo (host to host) es muy largo comparado con el tiempo de envo de un paquete de datos El retraso adems puede ser muy variable, por lo que es difcil utilizar temporizadores

Un host muy rpido podra saturar a un host lento, por lo que es necesario un control de flujo. El problema es si se produce un retardo en el envi de un paquete STOP que indique al host rpido que el buffer ya est lleno, para que ste deje de enviar ms datos. Mientras el host no reciba este paquete habrn datos que se habrn perdido para siempre por no haber lugar donde almacenarlos. Soluciones: * No hacer nada, confiar en retransmisiones muy ineficiente puede incluso empeorar el problema si el remitente es muy rpido * Confiar en el control de flujo al nivel enlace el efecto de control de flujo se propaga lentamente (back pressure)

el nivel enlace slo se puede controlar el flujo agregado al nivel host (no al nivel aplicacin)

* Utilizar protocolo de ventana deslizante el remitente no sabe distinguir entre confirmaciones (ACKs y NACKs) y mensajes de control de flujo * Utilizar protocolo de crdito se separan mensajes de control de flujo y de confirmacin se utiliza una ventana deslizante de tamao variable (en ambos hosts)

La solucin actual usada es la de usar una ventana deslizante de tamao variable. Dicha tcnica consiste en enviar un paquete al host emisor sobre el espacio del buffer en bytes que nos queda libre (WIN), as como el byte siguiente que espera recibir (ACK). Propiedades de esta tcnica: Retransmisin de segmentos perdidos o daados temporizador demasiado corto: respuesta lenta a errores temporizador demasiado largo: riesgo de retransmisiones innecesarias temporizador adaptable: difcil de medir el retraso al nivel de red y afinar el tiempo justo Entrega ordenada mediante los nmeros de secuencia Eliminacin de duplicados mediante los nmeros de secuencia el espacio de secuencias debe ser suficientemente grande para permitir la muerte de segmentos obsoletos (232 bits en TCP)

* Temporizadores usados en TCP:

* Cabecera segmento TCP:

* Implementacin de TCP (Estrategias de retransmisin): First Only + menos trfico: slo se retransmiten segmentos perdidos - ms retraso: la retransmisin de segmento j tiene que esperar hasta segmento j-1 se ha confirmado Batch + menos retraso: siempre se reenvan todos los segmentos no confirmados - ms trfico: riesgo de retransmisiones no necesarias Individual + menos trfico y menos retraso: cada segmento se retransmite de manera individual - ms procesamiento (CPU y memoria): muchos temporizadores!

* Optimizacin de TCP (programacin): A) Adaptacin dinmica de temporizadores de retransmisin: objetivo: estimar el valor ptimo del temporizador en cada momento hay que basarse sobre envos y confirmaciones previos existen varios algoritmos para predecir el retraso y su variacin (Jacobson, Karn) B) Adaptacin dinmica del tamao de la ventana (crdito) slow start: empezar la conexin con una ventana moderada crecimiento lineal de la ventana para evitar congestin * Protocolo UDP: sin conexin sin retransmisiones sin control de flujo pero con multiplexacin (puertos UDP) ejemplos de uso coleccin peridica de datos no-crticos (p.ej. sensores) flujos de multimedia (voz sobre IP, video) aplicaciones con propia gestin de errores y flujo (p.ej. RPC)

UDP proporciona un acceso casi directo a IP, slo aade el concepto de puertos. * Segmento UDP:

* Comparativa TCP vs UDP:

TCP transmisin fiable sin errores sin duplicados entrega en orden de envo control de flujo

UDP menos redundancia sin conexin, sin retransmisiones cabecera muy ligera genera menos congestin acceso casi directo al servicio de red

TEMA 4: Sockets
Un socket no es nada ms que la implementacin en cdigo de las reglas definidas por los protocolos TCP y UDP. Se trata de una especie de dispositivo virtual (o lgico) que representa las conexiones de nuestras aplicaciones. Por lo tanto, en Linux podemos tratar a un socket como un file descriptor; pudiendo usar todas las funciones disponibles para stos (leer, escribir, abrir, cerrar, duplicar, configurar stdin, stdout, etc.) En el mundo del software libre son muy usados los llamados Sockets de Berkeley. Se trata de una librera de funciones en cdigo C para Unix, y representan la implementacin de TCP en estos sistemas. Utilizan el modelo cliente-servidor en el establecimiento de conexiones entre aplicaciones, y se permite una comunicacin bidireccional entre stas. Para Windows existe una librera similar llamada Winsock. * Primitivas de sockets: Primitiva SOCKET BIND LISTEN Descripcin crear nuevo dispositivo lgico de comunicacin asociar el socket con una direccin IP y un puerto TCP iniciar escucha de solicitudes de conexin (crear cola de solicitudes) esperar solicitud de conexin (el proceso bloquea mientras espera) escribir datos al socket (tambin se puede utilizar write!) leer datos del socket (tambin se puede utilizar read!) cerrar conexin

ACCEPT SEND RECEIVE CLOSE

- Parmetros de la primitiva socket(dominio, tipo, protocolo): Dominio PF_INET PF_INET6 Tipo SOCK_STREAM transporte fiable, orientado a conexin (corresponde a TCP) IPv4 IPv6

SOCK_DGRAM

transporte no fiable sin conexin (corresponde a UDP) transporte fiable, sin conexin acceso directo a los protocolos (permite manipular headers)

SOCK_SEQPACKET

SOCK_RAW

Protocolo IPPROTO_IP usa protocolos default (p.ej. TCP para SOCK_STREAM)

* Implementacin de los sockets de Berkeley (cliente/servidor): A) SERVIDOR 1. crear socket con socket() 2. asociar el socket con un puerto con bind() 3. iniciar escucha de peticiones de conexin con listen() 4. acceptar conexin con accept() 5. enviar o recibir datos con send()/recv() o write()/read() 6. cerrar la conexin con close() B) CLIENTE 1. crear socket con socket() 2. conectar a un servidor con connect() 3. enviar o recibir datos con send()/recv() o write()/read() 4. cerrar la conexin con close()

TEMA 5: Interconexin de Redes

- Repetidor: Trabaja a nivel fsico. Simplemente se limita a copiar la entrada a la salida. Funciona solo entre segmentos con el mismo protocolo MAC, es transparente para los protocolos, y la velocidad de las LANs debe ser igual. - Concentrador (HUB): Un concentrador funciona repitiendo cada paquete de datos en cada uno de los puertos con los que cuenta, excepto en el que ha recibido el paquete, de forma que todos los puntos tienen acceso a los datos. Tambin se encarga de enviar una seal de choque a todos los puertos si detecta una colisin. - Puente (Bridge): Trabajan en la capa de enlace de datos. Se usan para interconectar distintas redes LAN. Cuando un puente recibe una trama Ethernet, comprueba su direccin MAC, y la reenva a la LAN adecuada. Los puentes admiten distintos tipos de redes fsicas y velocidades en las LANs que interconecta. Se usan sobretodo para interconectar LANs nicamente; los puentes tambin son tiles para aumentar la capacidad, cubrir una distancia geogrfica, aumentar la fiabilidad, aumentar la seguridad, y para conectar redes con trfico diferente. Un router que interconecta redes con transmisin fsica diferentes tiene funcionalidad de puente. - Commutador (Switch): Prcticamente idntico a un Puente pero con la peculiaridad, de que todas las tramas enviadas incluso dentro de una misma LAN, deben pasar obligatoriamente a travs de el Switch (el bridge hubiera descartado la trama). - Puerta de enlace de transporte: Estos dispositivos hacen de traductores entre redes con distintos protocolos orientados a la conexin; dndole el formato necesario a los datos enviados. Por ej. para comunicar una red TCP con una red ATM; ambas orientadas a la conexin a nivel transporte. Problemas comunes con los puentes de transporte: servicio orientado a conexin vs. sin conexin, con o sin retransmisiones y control de flujo, checksum utilizado para detectar errores, direccionamiento (puertos en TCP, TSAP en OSI), tamao y estructura de PDUs (segmentos en TCP).

- Puerta de enlace de aplicacin: Comprenden el contenido interno de los datos que enviamos, pudiendo cambiar el formato de stos para adaptarlos a determinadas aplicaciones. Hace de traductor entre protocolos de aplicacin de distintos sistemas. Por ej. podemos adaptar el formato de un mensaje WAP de un mvil a HTTP para poder navegar por internet desde el mvil. * Cortafuegos: Puede trabajar a distintos niveles: puerta de enlace de aplicacin, puerta de enlace de transporte, y a nivel red (packet filtering). A nivel red, el cortafuegos filtra todos los paquetes entrantes para determinar si son seguros o no. A nivel de aplicacin, hace un anlisis de los datos que la aplicacin desee enviar.

* DNS (Domain Name System): Servidor encargado de traducir una direccin del nivel aplicacin (URI) a una direccin al nivel red (IP). Se trata de un sistema distribuido y jerrquico. Los nombres de dominio son administrador por el ICANN. Existe un mnimo de DNS, el primario y el secundario. Es decir, ICANN requiere un mnimo de 2 name servers para cada domino. Los nombres de dominio funcionan de forma jerrquica, es decir, con la creacin de subdominios. Por ejemplo, www.upf.edu / dret.upf.edu / webmail.dret.upf.edu.