INSTITUTO TECNOLGICO DE QUERTARO UNIDAD TOLIMN

INGENIERIA EN SISTEMAS COMPUTACIONALES Redes de Computadoras GRUPO: T6A2010 Resumen

NOMBRE DEL ASESOR: MC. Arturo Ramrez Paredes NOMBRE DEL TUTOR: Ing. Sandra Hernndez Rincn NOMBRE DEL ESTUDIANTE: Mara Amarylis Cspedes Basaldua FECHA: 03/05/13

LA CAPA DE RED La capa de red se encarga de llevar los paquetes desde el origen hasta el destino. Llegar al destino puede requerir muchos saltos por enrutadores intermedios. Esta funcin ciertamente contrasta con la de la capa de enlace de datos, que slo tiene la meta modesta de mover tramas de un extremo del cable al otro. Por lo tanto, la capa de red es la capa ms baja que maneja la transmisin de extremo a extremo. Para lograr su cometido, la capa de red debe conocer la topologa de la subred de comunicacin (es decir, el grupo de enrutadores) y elegir las rutas adecuadas a travs de ella; tambin debe tener cuidado al escoger las rutas para no sobrecargar algunas de las lneas de comunicacin y los enrutadores y dejar inactivos a otros.

ASPECTOS DE DISEO DE LA CAPA DE RED

Servicios proporcionados a la capa de transporte

La capa de red proporciona servicios a la capa de transporte en la interfaz capa de red/capa de transporte. Una pregunta importante es qu tipo de servicios proporciona la capa de red a la capa de transporte. Los servicios de la capa de red se han diseado con los siguientes objetivos en mente.

1. Los servicios deben ser independientes de la tecnologa del enrutador. 2. La capa de transporte debe estar aislada de la cantidad, tipo y topologa de los enrutadores presentes. 3. Las direcciones de red disponibles para la capa de transporte deben seguir un plan de numeracin uniforme, aun a travs de varias LANs y WANs.

Dadas estas metas, los diseadores de la capa de red tienen mucha libertad para escribir especificaciones detalladas de los servicios que se ofrecern a la capa de transporte. Con frecuencia esta libertad degenera en una batalla campal entre dos

bandos en conflicto. La discusin se centra en determinar si la capa de red debe proporcionar servicio orientado o no orientado a la conexin.

Implementacin del servicio no orientado a la conexin

Si se ofrece el servicio no orientado a la conexin, los paquetes se colocan individualmente en la subred y se enrutan de manera independiente. No se necesita una configuracin avanzada. En este contexto, por lo general los paquetes se conocen como datagramas (en analoga con los telegramas) y la subred se conoce como subred de datagramas. Si se utiliza el servicio orientado a la conexin, antes de poder enviar cualquier paquete de datos, es necesario establecer una ruta del enrutador de origen al de destino. Esta conexin se conoce como CV (circuito virtual), en analoga con los circuitos fsicos establecidos por el sistema telefnico, y la subred se conoce como subred de circuitos virtuales.

Implementacin del servicio orientado a la conexin

Para servicio orientado a la conexin necesitamos una subred de circuitos virtuales. Veamos cmo funciona. El propsito de los circuitos virtuales es evitar la necesidad de elegir una nueva ruta para cada paquete enviado. En su lugar, cuando se establece una conexin, se elige una ruta de la mquina de origen a la de destino como parte de la configuracin de conexin y se almacena en tablas dentro de los enrutadores. Esa ruta se utiliza para todo el trfico que fluye a travs de la conexin, exactamente de la misma forma en que funciona el sistema telefnico. Cuando se libera la conexin, tambin se termina el circuito virtual. Con el servicio orientado a la conexin, cada paquete lleva un identificador que indica a cul circuito virtual pertenece.

Comparacin entre las subredes de circuitos virtuales y las de datagramas

ALGORITMOS DE ENRUTAMIENTO

La funcin principal de la capa de red es enrutar paquetes de la mquina de origen a la de destino. En la mayora de las subredes, los paquetes requerirn varios saltos para completar el viaje. La nica excepcin importante son las redes de difusin, pero aun aqu es importante el enrutamiento si el origen y el destino no estn en la misma red. Los algoritmos que eligen las rutas y las estructuras de datos que usan constituyen un aspecto principal del diseo de la capa de red. El algoritmo de enrutamiento es aquella parte del software de la capa de red encargada de decidir la lnea de salida por la que se transmitir un paquete de entrada. Si la subred usa datagramas de manera interna, esta decisin debe tomarse cada vez que llega un paquete de datos, dado que la mejor ruta podra haber cambiado desde la ltima vez.

Los algoritmos de enrutamiento pueden agruparse en dos clases principales: no adaptativos y adaptativos. Los algoritmos no adaptativos no basan sus decisiones de enrutamiento en mediciones o estimaciones del trfico y la topologa actuales.

En

contraste,

los

algoritmos

adaptativos

cambian

sus decisiones de

enrutamiento para reflejar los cambios de topologa y, por lo general tambin el trfico. Los algoritmos adaptativos difieren en el lugar de donde obtienen su informacin (por ejemplo, localmente, de los enrutadores adyacentes o de todos los enrutadores), el momento de cambio de sus rutas (por ejemplo, cada T segundos, cuando cambia la carga o cuando cambia la topologa) y la mtrica usada para la optimizacin (por ejemplo, distancia, nmero de saltos o tiempo estimado de trnsito).

Principio de optimizacin

Es posible hacer un postulado general sobre las rutas ptimas sin importar la topologa o el trfico de la red. Este postulado se conoce como principio de optimizacin, y establece que si el enrutador J est en ruta ptima del enrutador I al enrutador K, entonces la ruta ptima de J a K tambin est en la misma ruta. Para ver esto, llamemos r1 a la parte de la ruta de I a Jr1 y r2 al resto de la ruta. Si existiera una ruta mejor que r2 entre J y K, podra conectarse con r1 para mejorar la ruta entre I y K, contradiciendo nuestra aseveracin de que r1r2 es ptima.

Enrutamiento por la ruta ms corta

El concepto de ruta ms corta merece una explicacin. Una manera de medir la longitud de una ruta es por la cantidad de saltos. Usando esta mtrica, las rutas ABC y ABE de la figura 5-7 tienen la misma longitud. Otra mtrica es la distancia geogrfica en kilmetros, en cuyo caso ABC es claramente mucho mayor que ABE (suponiendo que la figura est dibujada a escala).

Sin embargo, tambin son posibles muchas otras mtricas adems de los saltos y la distancia fsica. Por ejemplo, cada arco podra etiquetarse con el retardo medio de encolamiento y transmisin de un paquete de prueba estndar, determinado por series de prueba cada hora. Con estas etiquetas en el grafo, la ruta ms corta es la ms rpida, en lugar de la ruta con menos arcos o kilmetros.

Inundacin

Otro algoritmo esttico es la inundacin, en la que cada paquete de entrada se enva por cada una de las lneas de salida, excepto aquella por la que lleg. La inundacin evidentemente genera grandes cantidades de paquetes duplicados; de hecho, una cantidad infinita a menos que se tomen algunas medidas para limitar el proceso. Una de estas medidas es integrar un contador de saltos en el encabezado de cada paquete, que disminuya con cada salto, y el paquete se descarte cuando el contador llegue a cero. Lo ideal es inicializar el contador de saltos a la longitud de la ruta entre el origen y el destino. Si el emisor desconoce el tamao de la ruta, puede inicializar el contador al peor caso, es decir, el dimetro total de la subred. Una tcnica alterna para ponerle diques a la inundacin es llevar un registro de los paquetes difundidos, para evitar enviarlos una segunda vez. Una manera de lograr este propsito es hacer que el enrutador de origen ponga un nmero de secuencia en cada paquete que recibe de sus hosts.

Una variacin de la inundacin, un poco ms prctica, es la inundacin selectiva. En este algoritmo, los enrutadores no envan cada paquete de entrada por todas las lneas, sino slo por aquellas que van aproximadamente en la direccin correcta. Por lo general, no tiene mucho caso enviar un paquete dirigido al oeste a travs de una lnea dirigida al este, a menos que la topologa sea extremadamente peculiar y que el enrutador est seguro de este hecho.

Enrutamiento por vector de distancia

Los algoritmos de enrutamiento por vector de distancia operan haciendo que cada enrutador mantenga una tabla (es decir, un vector) que da la mejor distancia conocida a cada destino y la lnea que se puede usar para llegar ah. Estas tablas se actualizan intercambiando informacin con los vecinos.

El algoritmo de enrutamiento por vector de distancia a veces recibe otros nombres, incluido el de algoritmo de enrutamiento Bellman-Ford distribuido y el de algoritmo Ford-Fulkerson, por los investigadores que los desarrollaron (Bellman, 1957, y Ford y Fulkerson, 1962). ste fue el algoritmo original de enrutamiento de ARPANET y tambin se us en Internet con el nombre RIP.

Enrutamiento por estado del enlace

Hoy en da se usan bastante algunas variantes del enrutamiento por estado del enlace. El concepto en que se basa el enrutamiento por estado del enlace es sencillo y puede enunciarse en cinco partes. Cada enrutador debe: 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. 4. Enviar este paquete a todos los dems enrutadores. 5. Calcular la ruta ms corta a todos los dems enrutadores.

Enrutamiento jerrquico

Cuando se utiliza el enrutamiento jerrquico, los enrutadores se dividen en lo que llamaremos regiones, donde cada enrutador conoce todos los detalles para enrutar paquetes a destinos dentro de su propia regin, pero no sabe nada de la estructura interna de las otras regiones. Cuando se interconectan diferentes redes, es natural considerar cada una como regin independiente a fin de liberar a los enrutadores de una red de la necesidad de conocer la estructura topolgica de las dems. En las redes enormes, una jerarqua de dos niveles puede ser insuficiente; tal vez sea necesario agrupar las regiones en clsteres, los clsteres en zonas, las zonas en grupos, etctera, hasta que se nos agoten los nombres para clasificarlos.

Enrutamiento por difusin

El envo simultneo de un paquete a todos los destinos se llama difusin; se han propuesto varios mtodos para llevarla a cabo. Un mtodo de difusin que no requiere caractersticas especiales de la subred es que el origen simplemente enve un paquete distinto a todos los destinos. El mtodo no slo desperdicia ancho de banda, sino que tambin requiere que el origen tenga una lista completa de todos los destinos. En la prctica, sta puede ser la nica posibilidad, pero es el mtodo menos deseable. La inundacin es otro candidato obvio. Aunque sta es poco adecuada para la comunicacin punto a punto ordinaria, para difusin puede merecer consideracin seria, especialmente si no es aplicable ninguno de los mtodos descritos a continuacin. El problema de la inundacin como tcnica de difusin es el mismo que tiene como algoritmo de enrutamiento punto a punto: genera demasiados paquetes y consume demasiado ancho de banda. Un tercer algoritmo es el enrutamiento multidestino. Con este mtodo, cada paquete contiene una lista de destinos o un mapa de bits que indica los destinos deseados.

Un cuarto algoritmo de difusin usa explcitamente el rbol sumidero para el enrutador que inicia la difusin, o cualquier otro rbol de expansin adecuado. El rbol de expansin es un subgrupo de la subred que incluye todos los enrutadores pero no contiene ciclos.

Nuestro ltimo algoritmo de difusin es un intento de aproximar el comportamiento del anterior, aun cuando los enrutadores no saben nada en lo absoluto sobre rboles de expansin. La idea, llamada reenvo por ruta invertida (reverse path forwarding), es excepcionalmente sencilla una vez planteada. Cuando llega un paquete difundido a un enrutador, ste lo revisa para ver si lleg por la lnea normalmente usada para enviar paquetes al origen de la difusin.

Enrutamiento para hosts mviles

En la actualidad millones de personas tienen computadoras porttiles, y generalmente quieren leer su correo electrnico y acceder a sus sistemas de archivos normales desde cualquier lugar del mundo. Estos hosts mviles generan una nueva complicacin: para enrutar un paquete a un host mvil, la red primero tiene que encontrarlo. Se dice que los hosts que nunca se mueven son estacionarios; se conectan a la red mediante cables de cobre o fibra ptica. En contraste, podemos distinguir otros dos tipos de hosts. Los hosts migratorios bsicamente son hosts estacionarios que se mueven de un lugar fijo a otro de tiempo en tiempo, pero que usan la red slo cuando estn conectados fsicamente a ella. Los hosts ambulantes hacen su cmputo en movimiento, y necesitan mantener sus conexiones mientras se trasladan de un lado a otro. Usaremos el trmino hosts mviles para referirnos a cualquiera de las dos ltimas categoras, es decir, a todos los hosts que estn lejos de casa y que necesitan seguir conectados.

Enrutamiento en redes ad hoc

Ya vimos cmo realizar el enrutamiento cuando los hosts son mviles y los enrutadores son fijos. Un caso an ms extremo es uno en el que los enrutadores mismos son mviles. Entre las posibilidades se encuentran:

1. Vehculos militares en un campo de batalla sin infraestructura. 2. Una flota de barcos en el mar. 3. Trabajadores de emergencia en un rea donde un temblor destruy la infraestructura. 4. Una reunin de personas con computadoras porttiles en un rea que no cuenta con 802.11.

En todos estos casos, y en otros, cada nodo consiste en un enrutador y un host, por lo general en la misma computadora. Las redes de nodos que estn cerca entre s se conocen como redes ad hoc o MANETs (Redes ad hoc Mviles).

ALGORITMOS DE CONTROL DE CONGESTIN

Cuando hay demasiados paquetes presentes en la subred (o en una parte de ella), hay una degradacin del desempeo. Esta situacin se llama congestin. Cuando la cantidad de paquetes descargados en la subred por los hosts est dentro de su capacidad de conduccin, todos se entregan (excepto unos pocos afligidos por errores de transmisin) y la cantidad entregada es proporcional al nmero enviado. Sin embargo, a medida que aumenta el trfico, los enrutadores ya no pueden manejarlo y comienzan a perder paquetes. Esto tiende a empeorar las cosas. Con mucho trfico, el desempeo se desploma por completo y casi no hay entrega de paquetes.

Principios generales del control de congestin

Muchos problemas de los sistemas complejos, como las redes de computadoras, pueden analizarse desde el punto de vista de una teora de control. Este mtodo conduce a dividir en dos grupos todas las soluciones: de ciclo abierto y de ciclo cerrado. En esencia, las soluciones de ciclo abierto intentan resolver el problema mediante un buen diseo, para asegurarse en primer lugar de que no ocurra. En contraste, las soluciones de ciclo cerrado se basan en el concepto de un ciclo de retroalimentacin. Este mtodo tiene tres partes cuando se aplica al control de congestin:

1. Monitorear el sistema para detectar cundo y dnde ocurren congestiones. 2. Pasar esta informacin a lugares en los que puedan llevarse a cabo acciones. 3. Ajustar la operacin del sistema para corregir el problema.

Polticas de prevencin de congestin En la figura 5-26 vemos diferentes polticas para las capas de enlace de datos, red y transporte que pueden afectar a la congestin (Jain, 1990).

Control de congestin en subredes de circuitos virtuales

Una de las tcnicas que se usa ampliamente para evitar que empeoren las congestiones que ya han comenzado es el control de admisin. La idea es sencilla: una vez que se ha detectado la congestin, no se establecen circuitos virtuales nuevos hasta que ha desaparecido el problema.

Desprendimiento de carga

Cuando ninguno de los mtodos anteriores elimina la congestin, los enrutadores pueden sacar la artillera pesada: el desprendimiento de carga, que es una manera rebuscada de decir que, cuando se inunda a los enrutadores con paquetes que no pueden manejar, simplemente los tiran.

El trmino viene del mundo de la generacin de energa elctrica, donde se refiere a la prctica de instalaciones que intencionalmente producen apagones en ciertas reas para salvar a la red completa de venirse abajo en das calurosos de verano en los que la demanda de energa elctrica excede por mucho el suministro. Un enrutador abrumado por paquetes simplemente puede escoger paquetes al azar para desprenderse de ellos, pero normalmente puede hacer algo mejor.

CALIDAD DEL SERVICIO

Requerimientos

Un flujo es un conjunto de paquetes que van de un origen a un destino. En una red orientada a la conexin, todos los paquetes que pertenezcan a un flujo siguen la misma ruta; en una red sin conexin, pueden seguir diferentes rutas. La necesidad de cada flujo se puede caracterizar por cuatro parmetros principales: confiabilidad, retardo, fluctuacin y ancho de banda. Estos parmetros en conjunto determinan la QoS (calidad del servicio) que el flujo requiere.

LA CAPA DE RED DE INTERNET

Antes de entrar a los detalles especficos de la capa de red de Internet, vale la pena dar un vistazo a los principios que guiaron su diseo en el pasado y que hicieron posible el xito que tiene hoy en da. En la actualidad, con frecuencia parece que la gente los ha olvidado. Estos principios se enumeran y analizan en el RFC 1958.

A continuacin presentamos los que consideramos como los 10 mejores principios (del ms al menos importante). 1. Asegrese de que funciona. No termine el diseo o estndar hasta que mltiples prototipos se hayan comunicado entre s de manera exitosa. Con demasiada frecuencia, los diseadores primero escriben un estndar de 1000 pginas, lo aprueban y despus descubren que tiene demasiadas fallas y no funciona. Despus escriben la versin 1.1 de ese mismo estndar. sta no es la manera correcta de proceder. 2. Mantenga la simplicidad. Cuando tenga duda, utilice la solucin ms simple. William de Occam formul este principio (la navaja de Occam) en el siglo XIV. Dicho en otras palabras: combata las caractersticas. Si una caracterstica no es absolutamente esencial, descrtela, especialmente si el mismo efecto se puede alcanzar mediante la combinacin de otras caractersticas. 3. Elija opciones claras. Si hay varias maneras para realizar la misma tarea, elija slo una. 1. Tener dos o ms formas de hacer lo mismo es buscarse problemas. Con frecuencia, los estndares tienen mltiples opciones o modos o parmetros debido a que personas poderosas insisten en que su mtodo es el mejor. Los diseadores deben resistir con fuerza esta tendencia. Simplemente diga no. 4. Explote la modularidad. Este principio lleva directamente a la idea de tener pilas de protocolos, cuyas capas son independientes entre s. De esta

forma, si las circunstancias requieren que un mdulo o capa cambie, los otros no se vern afectados. 5. Prevea la heterogeneidad. En cualquier red grande habrn diferentes tipos de hardware, facilidades de transmisin y aplicaciones. Para manejarlos, el diseo de la red debe ser simple, general y flexible. 6. Evite las opciones y parmetros estticos. Si los parmetros son inevitables (por ejemplo, el tamao mximo del paquete), es mejor hacer que el emisor y el receptor negocien un valor que definir opciones fijas. 7. Busque un buen diseo; no es necesario que sea perfecto. Con frecuencia, los diseadores tienen un buen diseo pero ste no puede manejar algn caso especial. En lugar de desbaratar el diseo, los diseadores deberan dejar que esa parte la resuelvan las personas con el caso especial. 8. Sea estricto cuando enve y tolerante cuando reciba. En otras palabras, slo enve paquetes que cumplan rigurosamente con los estndares, pero espere paquetes que tal vez no cumplan del todo y trate de lidiar con ellos. 9. Piense en la capacidad de crecimiento. Si el sistema va a manejar de manera efectiva millones de hosts y miles de millones de usuarios, las bases de datos no centralizadas de cualquier tipo son tolerables y la carga debe dispersarse lo ms equitativamente posible en los recursos disponibles. 10. Considere el desempeo y el costo. Si una red tiene un desempeo pobre o un costo exagerado, nadie la utilizar.

LA CAPA DE TRANSPORTE

La capa de transporte no es una capa ms. Es el corazn de toda la jerarqua de protocolos. La tarea de esta capa es proporcionar un transporte de datos confiable y econmico de la mquina de origen a la mquina de destino, independientemente

de la red o redes fsicas en uso. Sin la capa de transporte, el concepto total de los protocolos en capas tendra poco sentido.

EL SERVICIO DE TRANSPORTE Servicios proporcionados a las capas superiores

La meta fundamental de la capa de transporte es proporcionar un servicio eficiente, confiable y econmico a sus usuarios, que normalmente son procesos de la capa de aplicacin. Para lograr este objetivo, la capa de transporte utiliza los servicios proporcionados por la capa de red.

El hardware o software de la capa de transporte que se encarga del trabajo se llama entidad de transporte, la cual puede estar en el kernel (ncleo) del sistema operativo, en un proceso de usuario independiente, en un paquete de biblioteca que forma parte de las aplicaciones de red o en la tarjeta de red.

Primitivas del servicio de transporte

Sockets de Berkeley

Inspeccionemos brevemente otro grupo de primitivas de transporte, las primitivas de socket usadas en el UNIX de Berkeley para el TCP.

Las primeras cuatro primitivas de la lista son ejecutadas en ese orden por los servidores.

ELEMENTOS DE LOS PROTOCOLOS DE TRANSPORTE

El servicio de transporte se implementa mediante un protocolo de transporte entre las dos entidades de transporte. En ciertos aspectos, los protocolos de transporte se parecen a los protocolos de enlace de datos. Ambos se encargan del control de errores, la secuenciacin y el control de flujo, entre otros aspectos. Sin embargo, existen diferencias significativas entre los dos, las cuales se deben a diferencias importantes entre los entornos en que operan ambos protocolos. En la capa de enlace de datos, dos enrutadores se comunican directamente mediante un canal fsico mientras que, en la capa de transporte, ese canal fsico es reemplazado por la subred completa. Por una parte, en la capa de enlace de datos no es necesario que un enrutador especifique el enrutador con el que quiere comunicarse; cada lnea de salida especifica de manera nica un enrutador en particular. En la capa de transporte se requiere el direccionamiento explcito de los destinos.

Direccionamiento

El siguiente es un posible escenario para una conexin de transporte.

1. Un proceso servidor de hora del da del host 2 se enlaza con el TSAP 1522 para esperar una llamada entrante. La manera en que un proceso se enlaza con un TSAP est fuera del modelo de red y depende por entero del sistema operativo local. Podra, por ejemplo, usarse una llamada como nuestra LISTEN. 2. Un proceso de aplicacin del host 1 quiere averiguar la hora del da, por lo que emite una solicitud CONNECT especificando el TSAP 1208 como el origen y el TSAP 1522 como destino. Esta accin al final da como resultado una conexin de transporte que se establece entre el proceso de aplicacin del host 1 y el servidor 1 del host 2. 3. A continuacin el proceso de aplicacin enva una solicitud de hora. 4. El proceso de servidor de hora responde con la hora actual. 5. Despus se libera la conexin de transporte.

Establecimiento de una conexin

El establecimiento de una conexin suena fcil, pero en realidad es sorprendentemente complicado. A primera vista, parecera suficiente con que una entidad de transporte enviara una TPDU CONNECTION REQUEST al destino y esperar una respuesta CONNECTION ACCEPTED. El problema ocurre cuando la red puede perder, almacenar o duplicar paquetes. Este comportamiento causa complicaciones serias. El tiempo de vida de un paquete puede restringirse a un mximo conocido usando una de las siguientes tcnicas: 1. Un diseo de subred restringido.

2. Colocar un contador de saltos en cada paquete. 3. Marcar el tiempo en cada paquete.

Liberacin de una conexin

La liberacin de una conexin es ms fcil que su establecimiento. No obstante, hay ms escollos de los que uno podra imaginar. Como mencionamos antes, hay dos estilos de terminacin de una conexin: liberacin asimtrica y liberacin simtrica. La liberacin asimtrica es la manera en que funciona el sistema telefnico: cuando una parte cuelga, se interrumpe la conexin. La liberacin simtrica trata la conexin como dos conexiones unidireccionales distintas, y requiere que cada una se libere por separado.

Multiplexin

La multiplexin de varias conversaciones en conexiones, circuitos virtuales y enlaces fsicos desempea un papel importante en diferentes capas de la arquitectura de la red. En la capa de transporte puede surgir la necesidad de multiplexin por varias razones. Por ejemplo, si en un host slo se dispone de una direccin de red, todas las conexiones de transporte de esa mquina tendrn que utilizarla. Cuando llega una TDPU, se necesita algn mecanismo para saber a cul proceso asignarla. Esta situacin, conocida como multiplexin hacia arriba, se muestra en la figura.

Si un usuario necesita ms ancho de banda del que le puede proporcionar un circuito virtual, una alternativa es abrir mltiples conexiones de red y distribuir el trfico entre ellas en round robin (de manera circular), como se muestra en la figura. Esto se denomina multiplexin hacia abajo.

LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: UDP

Internet tiene dos protocolos principales en la capa de transporte, uno orientado y otro no orientado a la conexin. En las siguientes secciones analizaremos los dos. El protocolo no orientado a la conexin es UDP. El protocolo orientado a la conexin es TCP. Empezaremos con UDP porque es bsicamente IP con un encabezado corto.

Introduccin a UDP

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexin, UDP (Protocolo de Datagramas de Usuario). Este protocolo proporciona una forma para que las aplicaciones enven datagramas IP encapsulados sin tener que establecer una conexin. UDP se describe en el RFC

768. UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido por la carga til.

Llamada a procedimiento remoto

La informacin se puede transportar desde el invocador al proceso invocado en los parmetros, y se puede regresar en el resultado del procedimiento. El paso de mensajes es transparente para el programador. Esta tcnica se conoce como RPC (Llamada a Procedimiento Remoto) y se ha vuelto la base de muchas aplicaciones de redes. Tradicionalmente, el procedimiento invocador se conoce como cliente y el proceso invocado, como servidor.

El propsito esencial de RPC es hacer que una llamada a procedimiento remoto sea lo ms parecida posible a una local. En la forma ms simple, para llamar a un procedimiento remoto, el programa cliente debe enlazarse con un pequeo procedimiento de biblioteca, llamado stub del cliente, que representa al procedimiento servidor en el espacio de direcciones del cliente. De forma similar, el servidor se enlaza con una llamada a procedimiento denominada stub del servidor. Estos procedimientos ocultan el hecho de que la llamada a procedimiento desde el cliente al servidor no es local.

LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: TCP

UDP es un protocolo simple y tiene algunos usos especficos, como interacciones cliente-servidor y multimedia, pero para la mayora de las aplicaciones de Internet se necesita una entrega en secuencia confiable. UDP no puede proporcionar esto, por lo que se necesita otro protocolo. Se llama TCP y es el ms utilizado en Internet.

Introduccin a TCP

TCP (Protocolo de Control de Transmisin) se diseo especficamente para proporcionar un flujo de bytes confiable de extremo a extremo a travs de una interred no confiable. Una interred difiere de una sola red debido a que diversas partes podran tener diferentes topologas, anchos de banda, retardos, tamaos de paquete y otros parmetros. TCP tiene un diseo que se adapta de manera dinmica a las propiedades de la interred y que se sobrepone a muchos tipos de fallas. TCP se defini formalmente en el RFC 793. Conforme el tiempo pas, se detectaron varios errores e inconsistencias, y los requerimientos de algunas reas cambiaron.

Cada mquina que soporta TCP tiene una entidad de transporte TCP, ya sea un procedimiento de biblioteca, un proceso de usuario o parte del kernel.

El modelo del servicio TCP

El servicio TCP se obtiene al hacer que tanto el servidor como el cliente creen puntos terminales, llamados sockets. Cada socket tiene un nmero (direccin), que consiste en la direccin IP del host, y un nmero de 16 bits, que es local a ese host, llamado puerto. Un puerto es el nombre TCP para un TSAP. Para obtener el servicio TCP, se debe establecer de manera explcita una conexin entre un socket en la mquina emisora y uno en la mquina receptora. Las llamadas de socket se listan en la figura.

Un socket puede utilizarse para mltiples conexiones al mismo tiempo. En otras palabras, dos o ms conexiones pueden terminar en el mismo socket. Las conexiones se identifican mediante los identificadores de socket de los dos extremos, es decir (socket1, socket2). No se utiliza ningn otro nmero de circuitos virtuales ni identificador.

Los nmeros de puerto menores que 1024 se llaman puertos bien conocidos y se reservan para servicios estndar.

Todas las conexiones TCP son de dplex total y de punto a punto. Dplex total significa que el trfico puede ir en ambas direcciones al mismo tiempo. Punto a punto significa que cada conexin tiene exactamente dos puntos finales. TCP no soporta la multidifusin ni la difusin. Una conexin TCP es un flujo de bytes, no uno de mensajes. Los lmites de los mensajes no se preservan de extremo a extremo.

Bibliografa
Tanenbaum, A. S. (2003). Redes de Computadoras. Mxico: PEARSON Educacin.