Test

CAP. 5 PROBLEMAS 479 45. Usted explica el protocolo ARP a un amigo. Cuando usted termina su explicación, él dice: “Ya entien- do. ARP proporciona un servicio a la capa de red, por lo que es parte de la capa de enlace de datos”. ¿Qué le diría a su amigo? 46. ARP y RARP asignan direcciones de un espacio a otro. En este sentido, son similares. Sin embargo, sus implementaciones son esencialmente diferentes. ¿En qué aspecto fundamental son diferentes? 47. Describa una forma de reensamblar fragmentos IP en el destino. 48. La mayoría de los algoritmos de reensamble de datagramas IP tienen un temporizador para evitar que un fragmento perdido enlace búferes de reensamble por siempre. Suponga que un datagrama se divide en cuatro fragmentos. Los primeros tres fragmentos llegan y el cuarto se retrasa. En algún momento, el temporizador termina, por lo que se descartan los tres fragmentos de la memoria del receptor. Un poco más tarde, llega el último fragmento. ¿Qué se debería hacer con él? 49. Tanto en IP como en ATM, la suma de verificación cubre sólo el encabezado y no los datos. ¿Por qué supone que se eligió este diseño? 50. Una persona que vive en Boston viaja a Minneápolis, y lleva su computadora portátil. Para su sorpre- sa, la LAN de su destino en Minneápolis es una LAN IP inalámbrica, por lo que no tiene que conectar- se. ¿Para que el correo electrónico y otro tipo de tráfico llegue de manera correcta aún es necesario todo el proceso con los agentes de base y foráneos? 51. IPv6 utiliza direcciones de 16 bytes. Si un bloque de 1 millón de direcciones se asigna cada picosegun- do, ¿cuánto tardará la dirección? 52. El campo Protocolo utilizado en el encabezado IPv4 no está presente en el encabezado IPv6 fijo. ¿Por qué? 53. Cuando se introduce el protocolo IPv6, ¿tiene que cambiarse el protocolo ARP? De ser así, ¿los cam- bios son conceptuales o técnicos? 54. Escriba un programa para simular enrutamiento que utilice inundación. Cada paquete debe contener un contador que se decrementa en cada salto. Cuando el contador llega a cero, el paquete se descarta. El tiempo es discreto y cada línea maneja un paquete por intervalo de tiempo. Cree tres versiones del pro- grama: todas las líneas están inundadas, todas las líneas, excepto la de entrada, están inundadas, y sólo las k mejores líneas (elegidas de manera estática) están inundadas. Compare la inundación con el enru- tamiento determinista (k = 1) con base en el retardo y el ancho de banda utilizado. 55. Escriba un programa que simule una red de computadoras usando tiempo discreto. El primer paquete de cada cola de enrutador da un salto por intervalo de tiempo. Cada enrutador sólo tiene un número fi- nito de búferes. Si un paquete llega y no hay espacio para él, se descarta y no se retransmite. En su lu- gar, hay un protocolo de extremo a extremo, lleno de terminaciones de temporización y paquetes de confirmación de recepción, que en algún momento regenera dicho paquete del enrutador de origen. Grafique la velocidad real de transporte de la red como una función del intervalo de terminación de temporizador de extremo a extremo, con parámetros de tasa de error. 56. Escriba una función para realizar el reenvío en un enrutador IP. El procedimiento tiene un parámetro, una dirección IP. También tiene acceso a una tabla global que consiste de un arreglo de tres variables. Ca- da arreglo contiene tres enteros: una dirección IP, una máscara de subred y la línea de salida a utilizar. La función usa CIDR para buscar la dirección IP en la tabla y regresa la línea a utilizar como su valor.

480 LA CAPA DE RED CAP. 5 57. Utilice los programas traceroute (UNIX) o tracert (Windows) para trazar la ruta de su computadora a varias universidades de otros continentes. Haga una lista de los enlaces transoceánicos que ha descu- bierto. Algunos sitios para probar son: www.berkeley.edu (California) www.mit.edu (Massachusetts) www.vu.nl (Amsterdam) www.ucl.ac.uk (Londres) www.usyd.edu.au (Sydney) www.u-tokyo.ac.jp (Tokyo) www.uct.ac.za (Cape Town)

6 LA CAPA DE TRANSPORTE La capa de transporte no es una capa más. Es el corazón de toda la jerarquía de protocolos. La tarea de esta capa es proporcionar un transporte de datos confiable y económico de la máqui- na de origen a la máquina de destino, independientemente de la red o redes físicas en uso. Sin la capa de transporte, el concepto total de los protocolos en capas tendría poco sentido. En este ca- pítulo estudiaremos en detalle la capa de transporte, incluidos sus servicios, diseño, protocolos y desempeño. 6.1 EL SERVICIO DE TRANSPORTE En las siguientes secciones daremos una introducción al servicio de transporte. Veremos el ti- po de servicio proporcionado a la capa de aplicación. Veremos el tipo de servicio que se propor- ciona a la capa de aplicación. Para que el tema del servicio de transporte quede claro, analizaremos dos conjuntos de primitivas de la capa de transporte. Primero analizaremos uno muy sencillo (e hipotético) para mostrar las ideas básicas. Después veremos la interfaz que se utiliza común- mente en Internet. 6.1.1 Servicios proporcionados a las capas superiores La meta fundamental de la capa de transporte es proporcionar un servicio eficiente, confiable y económico a sus usuarios, que normalmente son procesos de la capa de aplicación. Para lograr este objetivo, la capa de transporte utiliza los servicios proporcionados por la capa de red. El hardware 481

482 LA CAPA DE TRANSPORTE CAP. 6 o software de la capa de transporte que se encarga del trabajo se llama entidad de transporte, la cual puede estar en el kernel (núcleo) del sistema operativo, en un proceso de usuario independien- te, en un paquete de biblioteca que forma parte de las aplicaciones de red o en la tarjeta de red. En la figura 6-1 se ilustra la relación (lógica) entre las capas de red, transporte y aplicación. Host 1 Host 2 Capa de aplicación Capa de aplicación (o de sesión) Interfaz de (o de sesión) Dirección de aplicación/transporte transporte TPDU Entidad de Entidad de transporte transporte Protocolo de transporte Dirección de red Interfaz de transporte/red Capa de red Capa de red Figura 6-1. Las capas de red, transporte y aplicación. Así como hay dos tipos de servicio de red, orientado y no orientado a la conexión, hay dos ti- pos de servicio de transporte. El servicio de transporte orientado a la conexión es parecido en mu- chos sentidos al servicio de red orientado a la conexión. En ambos casos, las conexiones tienen tres fases: establecimiento, transferencia de datos y liberación (o terminación). El direccionamien- to y el control de flujo también son semejantes en ambas capas. Además, el servicio de transporte no orientado a la conexión es muy parecido al servicio de red no orientado a la conexión. La pregunta obvia es: ¿si el servicio de la capa de transporte es tan parecido al de la capa de red, por qué hay dos capas diferentes? ¿Por qué no es suficiente una sola capa? La respuesta es su- til, pero crucial, y nos remite a la figura 1-9. El código de transporte se ejecuta por completo en las máquinas de los usuarios, pero la capa de red, por lo general, se ejecuta en los enrutadores, los cuales son operados por la empresa portadora (por lo menos en el caso de una red de área amplia). ¿Qué sucede si la capa de red ofrece un servicio poco confiable? ¿Qué tal si esa capa pierde paquetes con frecuencia? ¿Qué ocurre si los enrutadores se caen de cuando en cuando? Problemas, eso es lo que ocurre. Los usuarios no tienen control sobre la capa de red, por lo que no pueden resolver los problemas de un mal servicio usando mejores enrutadores o incremen- tando el manejo de errores en la capa de enlace de datos. La única posibilidad es poner encima de la capa de red otra capa que mejore la calidad del servicio. Si, en una subred orientada a la cone- xión, a la mitad de una transmisión larga se informa a una entidad de transporte que su conexión de red ha sido terminada de manera abrupta, sin indicación de lo sucedido a los datos actualmen- te en tránsito, la entidad puede establecer una nueva conexión de red con la entidad de transporte

SEC. 6.1 EL SERVICIO DE TRANSPORTE 483 remota. Usando esta nueva conexión de red, la entidad puede enviar una solicitud a su igual preguntando cuáles datos llegaron y cuáles no, y reiniciar a partir de donde se originó la inte- rrupción. Esencialmente, la existencia de la capa de transporte hace posible que el servicio de transpor- te sea más confiable que el servicio de red subyacente. La capa de transporte puede detectar y compensar paquetes perdidos y datos alterados. Más aún, las primitivas del servicio de transporte se pueden implementar como llamadas a procedimientos de biblioteca con el propósito de que sean independientes de las primitivas del servicio de red, las cuales podrían variar considerable- mente entre las redes (por ejemplo, el servicio LAN no orientado a la conexión puede ser bastan- te diferente del servicio WAN orientado a la conexión). Al ocultar el servicio de red detrás de un conjunto de primitivas de servicio de transporte, el cambio del servicio de red simplemente re- quiere reemplazar un conjunto de procedimientos de biblioteca por otro que haga lo mismo con un servicio subyacente distinto. Gracias a la capa de transporte, es posible escribir programas de aplicación usando un conjun- to estándar de primitivas, y que estos programas funcionen en una amplia variedad de redes sin necesidad de preocuparse por lidiar con diferentes interfaces de subred y transmisiones no confia- bles. Si ninguna red real tuviera fallas, y si todas tuvieran las mismas primitivas de servicio y se pudiera garantizar que nunca jamás cambiaran, tal vez la capa de transporte sería innecesaria. Sin embargo, en el mundo real esta capa cumple la función clave de aislar a las capas superiores de la tecnología, el diseño y las imperfecciones de la subred. Por esta razón, mucha gente establece una distinción entre las capas 1 a 4, por una parte, y la(s) capa(s) por encima de la 4, por la otra. Las cuatro capas inferiores pueden verse como el pro- veedor del servicio de transporte, y la(s) capa(s) superiores son el usuario del servicio de trans- porte. Esta distinción entre proveedor y usuario tiene un impacto considerable en el diseño de las capas y pone a la capa de transporte en una posición clave, ya que constituye el límite principal entre el proveedor y el usuario del servicio confiable de transmisión de datos. 6.1.2 Primitivas del servicio de transporte Para permitir que los usuarios accedan al servicio de transporte, la capa de transporte debe proporcionar algunas operaciones a los programas de aplicación, es decir, una interfaz del servi- cio de transporte. Cada servicio de transporte tiene su propia interfaz. Con el propósito de ver los aspectos básicos, en esta sección examinaremos primero un servicio de transporte sencillo (hipo- tético) y su interfaz. En la siguiente sección veremos un ejemplo real. El servicio de transporte es parecido al servicio de red, pero hay algunas diferencias importan- tes. La principal es que el propósito del servicio de red es modelar el servicio ofrecido por las redes reales, con todos sus problemas. Las redes reales pueden perder paquetes, por lo que el ser- vicio de red generalmente no es confiable. En cambio, el servicio de transporte (orientado a la conexión) sí es confiable. Claro que las redes reales no están libres de errores, pero ése es precisamente el propósito de la capa de trans- porte: ofrecer un servicio confiable en una red no confiable.

484 LA CAPA DE TRANSPORTE CAP. 6 Como ejemplo, considere dos procesos conectados mediante canalizaciones en UNIX. Ambos consideran que la conexión entre ellos es perfecta. No quieren saber de confirmaciones de recepción, paquetes perdidos, congestión ni nada por el estilo. Lo que quieren es una conexión 100 por ciento confiable. El proceso A pone datos en un extremo de la canalización y el proceso B los saca por el otro extremo. Ésta es la esencia del servicio de transporte orientado a la conexión: ocultar las imperfecciones del servicio de red para que los procesos usuarios puedan dar por hecho simple- mente la existencia de un flujo de bits libre de errores. Como nota al margen, la capa de transporte también puede proporcionar un servicio no con- fiable (de datagramas), pero hay muy poco que decir al respecto, por lo que en este capítulo nos concentraremos principalmente en el servicio de transporte orientado a la conexión. Sin embargo, hay algunas aplicaciones que se benefician del transporte no orientado a la conexión, como la computación cliente-servidor y la multimedia de flujo continuo, por lo que veremos algo sobre ellas más adelante. Una segunda diferencia entre los servicios de red y de transporte es a quién están dirigidos. El servicio de red lo usan únicamente las entidades de transporte. Pocos usuarios escriben sus propias entidades de transporte y, por lo tanto, pocos usuarios o programas llegan a ver los aspec- tos internos del servicio de red. En contraste, muchos programas (y, por lo tanto, programadores) ven las primitivas de transporte. En consecuencia, el servicio de transporte debe ser adecuado y fácil de usar. Para tener una idea de lo que podría ser el servicio de transporte, considere las cinco primiti- vas listadas en la figura 6-2. Esta interfaz de transporte ciertamente es sencilla, pero muestra la esencia de lo que debe hacer una interfaz de transporte orientada a la conexión: permite que los programas de aplicación establezcan, usen y liberen conexiones, lo cual es suficiente para muchas aplicaciones. Primitiva Paquete enviado Significado LISTEN (ninguno) Se bloquea hasta que algún proceso intenta la conexión CONNECT CONNECTION REQ. Intenta activamente establecer una conexión SEND DATA Envía información RECEIVE (ninguno) Se bloquea hasta que llega un paquete DATA DISCONNECT DISCONNECTION REQ. Este lado quiere liberar la conexión Figura 6-2. Primitivas de un servicio de transporte sencillo. Para ver cómo podrían usarse estas primitivas, considere una aplicación con un servidor y cier- ta cantidad de clientes remotos. Para comenzar, el servicio ejecuta una primitiva LISTEN, normal- mente llamando a un procedimiento de biblioteca que hace una llamada de sistema para bloquear al servidor hasta la aparición de un cliente. Cuando un cliente desea comunicarse con el servidor, ejecuta una primitiva CONNECT. La entidad de transporte ejecuta esta primitiva bloqueando al

SEC. 6.1 EL SERVICIO DE TRANSPORTE 485 invocador y enviando un paquete al servidor. En la carga útil de este paquete se encuentra un men- saje de capa de transporte encapsulado, dirigido a la entidad de transporte del servidor. Aquí es pertinente una nota rápida sobre la terminología. A falta de un mejor término, usaremos las siglas poco elegantes de TPDU (Unidad de Datos del Protocolo de Transporte) para referir- nos a los mensajes enviados de una entidad de transporte a otra. Por lo tanto, las TPDUs (inter- cambiadas por la capa de transporte) están contenidas en paquetes (intercambiados por la capa de red). A su vez, los paquetes están contenidos en tramas (intercambiados por la capa de enlace de datos). Cuando llega una trama, la capa de enlace de datos procesa el encabezado de la trama y pasa el contenido del campo de carga útil de la trama a la entidad de red. Esta última procesa el encabezado del paquete y pasa el contenido de la carga útil del paquete a la entidad de transporte. Este anidamiento se ilustra en la figura 6-3. Encabezado Encabezado Encabezado de la trama del paquete de la TPDU Carga útil de la TPDU Carga útil del paquete Carga útil de la trama Figura 6-3. Anidamiento de las TPDUs, los paquetes y las tramas. Regresando a nuestro ejemplo de cliente-servidor, la llamada CONNECT del cliente ocasiona el envío de una TPDU CONNECTION REQUEST (solicitud de conexión) al servidor. Al llegar ésta, la entidad de transporte verifica que el servidor esté bloqueado en LISTEN (es decir, esté interesado en manejar solicitudes). A continuación desbloquea el servidor y envía una TPDU CON- NECTION ACCEPTED (conexión aceptada) de regreso al cliente. Al llegar esta TPDU, el cliente se desbloquea y se establece la conexión. Ahora pueden intercambiarse datos usando las primitivas SEND y RECEIVE. En la forma más simple, cualquiera de las dos partes puede emitir una RECEIVE (bloqueadora) para esperar que la otra parte emita una SEND. Al llegar la TPDU, el receptor se desbloquea y puede procesar la TPDU y enviar una respuesta. Mientras ambos lados puedan llevar el control de quién tiene el turno para transmitir, este esquema funciona bien. Observe que en la capa de transporte, incluso un intercambio de datos unidireccional es más complicado que en la capa de red. También se confirmará (tarde o temprano) la recepción de cada paquete de datos enviado. Asimismo, la recepción de los paquetes que llevan TPDUs de control se confirmará de manera implícita o explícita. Estas confirmaciones son manejadas por las entidades de transporte usando el protocolo de capa de red, y son transparentes para los usuarios de transpor- te. De la misma forma, las entidades de transporte necesitarán preocuparse por los temporizadores