INTERNETy TCPIPdiciembre 2003

Captulo 1.
Arquitecturas Estructuradas de Comunicaciones
1. ARQUITECTURAS COMUNICACIONES
1.1
ESTRUCTURADAS
DE
Introduccin y generalidades
Las redes son actualmente una de las partes esenciales de los sistemas de informacin ya que, a travs de ellas, un usuario puede comunicarse con otros y compartir recursos de informacin y computacin, con el ahorro econmico que esto conlleva. En este contexto, una red va a ser algo muy conceptual que se va a representar grficamente mediante una nube como un medio comn de comunicacin y comparticin. Por consiguiente, en este libro no se va a entrar en la topologa, tecnologa, etc., de ninguna red; pero s, por ejemplo, en los protocolos de comunicaciones TCP/IP y en las unidades de datos manejadas por dichos protocolos, las cuales se intercambian a travs de la infraestructura fsica de cualquier red en Internet.
RED
Figura 1.1.- Comparticin en red de recursos de informacin y computacin. Aunque la taxonoma de las redes es muy amplia y variada y, por tanto, se pueden clasificar de muy diferentes formas1; una forma muy til de clasificarlas, para una mayor comprensin, es basndose en su aspecto, ya sea fsico o abstracto. En funcin de esta caracterstica, se pueden establecer los dos tipos de redes siguientes:
1
En funcin de su tecnologa, del rea geogrfica que cubren, de su gestin o administracin, etc.
-1-
Captulo 1. Arquitecturas Estructuradas de Comunicaciones
REDES DE COMUNICACIONES: Redes fsicas que engloban cualquier tipo de red existente y, por tanto, cualquier tipo de servicio de comunicaciones (voz, datos, vdeo, etc.). REDES DE COMPUTADORAS: Redes abstractas formadas por la interconexin de las anteriores y basadas en el uso de un mismo conjunto de protocolos de comunicaciones que aseguran la interoperabilidad entre procesos iguales que se ejecutan en mquinas diferentes. Un ejemplo muy significativo es la red Internet, una inmensa red de computadoras formada por la interconexin de infinidad de redes fsicas y en donde se usan los protocolos TCP/IP para la comunicacin de los correspondientes sistemas finales. En este escenario, un sistema es cualquier mquina o dispositivo capaz de ejecutar la arquitectura de protocolos TCP/IP. En la Figura 1.2 se muestra una hipottica red o nube Internet formada por la interconexin de una serie de redes de comunicaciones o pequeas nubes fsicas. Se asume que todas las mquinas hablan un mismo lenguaje de comunicaciones en funcin de un conjunto de protocolos conocido como TCP/IP. Asimismo, ya se estudiar que existen unas computadoras conocidas como routers2 que hacen el papel de sistemas intermedios y que permiten encaminar datos de una nube a otra en funcin del destinatario.
TCP/IP
... ... ...

INTERNET
TCP/IP
... ...
RED FSICA
TCP/IP
...
IP
...
... ... ... ...
IP
... ...
...
IP
...
IP
... ... ...
...
IP
...
...
ROUTER
...
...
TCP/IP
...
TCP/IP
Figura 1.2.- Una hipottica red Internet.
En adelante, y a pesar de su sintaxis anglosajona, en este libro a un sistema intermedio o encaminador o dispositivo de encaminamiento se le denominar router.
-2-
1.2
Estratificacin en niveles de comunicaciones
Segn se muestra en la Figura 1.3, los protocolos TCP/IP se estratifican en una arquitectura estructurada en cinco niveles de comunicaciones. El nivel ms alto o nivel de aplicacin es el nivel con el que interactan los usuarios. El nivel ms bajo viene definido por el hardware de acceso al medio fsico de interconexin. Todos los niveles son mutuamente independientes en el sentido de que en cada nivel, a excepcin del nivel fsico o de hardware, hay uno o ms protocolos que llevan a cabo unas funciones y proporcionan unos servicios totalmente diferentes del resto de los niveles. En el caso de disponer de diferentes protocolos en un mismo nivel de comunicaciones, existirn distintas clases de funciones y servicios dentro de dicho nivel. En este contexto, un protocolo define unas funciones que proporcionan un determinado servicio en funcin del nivel de comunicaciones en que se encuentre. Dicho de otro modo, un servicio es el resultado de efectuar las acciones o funciones definidas por el correspondiente protocolo, basndose en unas determinadas cabeceras de informacin de control, cuyo formato tambin est definido en el diseo de dicho protocolo. Un nivel de comunicaciones, como es el caso del nivel de transporte TCP/IP, que ya se analizar, ofrece dos protocolos de transporte (TCP y UDP) que proporcionan dos servicios del nivel de transporte diferentes. Asimismo, un servicio puede ser el resultado de realizar una o ms funciones. Por ejemplo, las entidades IP, que funcionan segn su protocolo IP, para proporcionar el servicio del nivel Internet o nivel de red o de encaminamiento TCP/IP (que tambin se estudiar ms adelante), deben llevar a cabo, bsicamente, funciones como elegir una ruta en funcin de su tabla de encaminamiento, detectar potenciales errores fsicos en su cabecera de control, fragmentar (y reensamblar en el destino), etc.
APLICACIN
TRANSPORTE
INTERNET
RED DE ACCESO
INTERFAZ DE RED HARDWARE
Figura 1.3.- La arquitectura estructurada de comunicaciones TCP/IP.
-3-
Toda arquitectura estructurada de comunicaciones (TCP/IP de IAB, OSI de ISO, SNA de IBM, IPX/SPX de Novell, XNS de Xerox, etc.) presenta dos ventajas muy relevantes: REDUCCIN DE LA COMPLEJIDAD: Facilita la labor de diseo a travs de una estructura ms comprensible por una divisin en diferentes niveles de comunicaciones. Incluso esta caracterstica permite que diferentes equipos de trabajo (programadores) puedan desarrollar sus labores en diferentes niveles sin interferirse. FACILITACIN DEL CAMBIO TECNOLGICO: Permite que cualquier cambio llevado a cabo en cualquier nivel no afecte (si el sistema est bien estructurado) al resto de los niveles de la arquitectura. Actualmente, existen dos tipos de estndares en el contexto de las arquitecturas estructuradas de comunicaciones: DE IURE: Del latn por razn, por justicia, etc.; son los autnticos estndares ya que son aprobados y propuestos por un organismo internacional de normalizacin, tal es el caso de la arquitectura OSI del organismo ISO. DE FACTO: Mal llamados estndares, pero se consideran como tales por el facto o por el hecho de su amplio uso. ste es el caso de la arquitectura TCP/IP que no ha sido propuesta o aprobada por ningn organismo internacional de normalizacin y, sin embargo, es la arquitectura de comunicaciones por excelencia y, por tanto, la ms utilizada. La siguiente Figura 1.4 muestra dos sistemas finales con una misma arquitectura genrica de comunicaciones, los cuales estn conectados a travs de una red ya sea de comunicaciones o computadoras. En este ejemplo, el nivel ms alto es un nivel n y el ms elemental se corresponde con el nivel 1. A excepcin del nivel ms elemental o nivel fsico o de hardware (nivel 1), en cada nivel de comunicaciones habr al menos una entidad de software o proceso que se rige bajo un determinado protocolo de comunicaciones.
-4-
Emisor
Receptor
Nivel n ... Nivel 1
Nivel n ... Nivel 1
RED
Figura 1.4.- Comunicacin entre los distintos niveles de un mismo sistema. La comunicacin entre los diferentes niveles de un mismo sistema consiste en enviar los datos o la informacin que se ha de transmitir de ARRIBA ABAJO (del nivel n al nivel 1) en el sistema emisor, y de ABAJO ARRIBA (del nivel 1 al nivel n) en el sistema receptor. Cada entidad de software en el sistema emisor conoce previamente y por configuracin a su vecino del piso de abajo para la entrega correcta de las oportunas unidades de datos. En el sistema receptor, si existe ms de una entidad de software en un determinado nivel de comunicaciones de la arquitectura, la entidad en el piso o nivel inmediatamente inferior debe conocer (examinando la informacin de control recibida) el identificador de la entidad de software del piso superior a la cual va a pasar los correspondientes datos. En el caso de que slo haya una entidad en un nivel superior, el vecino de abajo le pasa los datos por omisin. Particularizando un poco ms, segn se describe en la siguiente Figura 1.5, la comunicacin entre los distintos niveles en sistemas diferentes se basa en que entre ambos extremos y para cada nivel existe un protocolo de comunicaciones que define los mensajes intercambiados y las acciones o funciones que tienen que llevar a cabo las entidades de software del nivel correspondiente. As, en el nivel n+1 de cada sistema habr una entidad del nivel n+1. Estas dos entidades del nivel n+1 se comunican intercambiando mensajes de control cuyo formato y acciones estn definidas a travs del correspondiente protocolo del nivel n+1. De la misma manera, en el nivel n de cada sistema habr una entidad del nivel n. Estas dos entidades del nivel n se comunican intercambiando mensajes de control cuyo formato y acciones estn definidas a travs del correspondiente protocolo del nivel n. De igual forma, en el nivel n-1 de cada sistema habr una entidad del nivel n-1. Estas dos entidades del nivel n-1 se comunican intercambiando mensajes de control cuyo formato y acciones estn definidas, a su vez, a travs del correspondiente protocolo del nivel n-1. Y as, sucesivamente, para el resto de los niveles exceptuando, como ya se ha comentado, el nivel ms elemental o de hardware.
-5-
Nivel n+1 Nivel n Nivel n-1 Nivel n-2 Hardware
Protocolo de nivel n+1 Protocolo de nivel n Protocolo de nivel n-1 Protocolo de nivel n-2
RED
Figura 1.5.- Comunicacin entre los distintos niveles en sistemas diferentes En la siguiente Figura 1.6 se ahonda un poco ms en el concepto de la comunicacin entre los distintos niveles de un mismo sistema. En el sistema emisor, la comunicacin de arriba abajo consiste en aadir, a los potenciales datos de usuario, cabeceras de informacin de control por cada uno de los niveles (a excepcin del nivel ms elemental o nivel fsico) por donde van pasando dichos datos. En el sistema receptor, se hace todo lo contrario, es decir, se eliminan dichas cabeceras a medida que se realizan las funciones pertinentes basndose en la cabecera de cada nivel. Cada cabecera contiene un mensaje de informacin de control. Como ya se ha indicado, el formato de la cabecera, y las acciones que hay que llevar a cabo en funcin de la informacin de control contenida en dicha cabecera, se define en el correspondiente protocolo de nivel. Por ejemplo, la entidad del nivel n introduce una cabecera para que la entidad homloga en el sistema receptor lleve a cabo unas funciones de nivel n basndose en la informacin registrada en dicha cabecera. Visto de otra manera: Para llevar a cabo un servicio del nivel n+1, dos entidades del nivel n+1 necesitan previamente un servicio del nivel n para realizar las funciones del nivel n+1 definidas por el protocolo del nivel n+1. Para llevar a cabo un servicio del nivel n, dos entidades del nivel n necesitan previamente un servicio del nivel n-1 para realizar las funciones del nivel n definidas por el protocolo del nivel n. Y as sucesivamente hasta llegar al nivel ms elemental o nivel fsico.
Resumiendo, cada nivel superior se apoya en los servicios del nivel inmediatamente inferior hasta alcanzar el nivel ms elemental o nivel fsico.
-6-
DATOS
DATOS DATOS DATOS DATOS DATOS
DATOS DATOS DATOS DATOS
RED
Figura 1.6.- Inclusin y eliminacin de cabeceras de informacin de control.
1.3
Modelo de referencia OSI
Dentro del marco de estndares especificados por el organismo internacional de normalizacin conocido como ISO (International Standards Organization), se ha definido una arquitectura estructurada de comunicaciones o modelo bsico de referencia OSI (Open Systems Interconnection) para la interconexin de sistemas abiertos. Este modelo de referencia OSI (ISO/IEC IS 7498) que se defini en 1978 y se public en 1982 por el comit tcnico conjunto JTC1 (Joint Technical Committee 1) de ISO y Comit Electrotcnico Internacional (IEC o International Electrotechnical Committee), describe cmo implementar una arquitectura estructurada en siete niveles de comunicaciones para interconectar sistemas finales heterogneos. Es importante tener en cuenta que antes de que se publicara el modelo OSI, la mayora de las computadoras se diseaban como sistemas cerrados, esto es, sistemas que no eran capaces de comunicarse con otros de diferentes fabricantes de equipos informticos (IBM, Digital, Xerox, etc.). En un principio este problema no era demasiado serio ya que cuando una empresa se informatizaba, apostaba por un solo fabricante el cual aparte de los equipos proporcionaba, asimismo, su propia solucin de comunicaciones, es decir, sus propios protocolos de comunicaciones. El escenario se complicaba cuando las distintas organizaciones dejaban de funcionar aisladamente y decidan comunicarse, incluso compartiendo recursos de informacin y computacin. Cada fabricante defina sus protocolos de comunicaciones para interconectar sus propios equipos, los cuales eran totalmente incompatibles con los de otros fabricantes. En este contexto, el mundo de las comunicaciones de datos se haba transformado en una autntica torre de Babel. Para resolver este galimatas se crearon distintas organizaciones nacionales e internacionales de normalizacin cuyo principal cometido era la generacin de normas de amplio consenso y recomendable cumplimiento por todos.
-7-
De entre todos estos organismos, el ms universal es ISO cuyas reas de actuacin abarcan temas tan dispares como materiales, alimentos, salud, transporte, comunicaciones, etc. Se fund en 1947 y est constituido por los organismos de normalizacin de la mayora de los pases con un mnimo nivel tecnolgico, representando el 95% de la produccin industrial en el mundo. Como se ha comentado con anterioridad, su principal logro en el mundo de las comunicaciones de datos fue la creacin del modelo arquitectnico de referencia para la interconexin de sistemas abiertos o modelo OSI. Entendiendo por sistemas abiertos, aqullos capaces de interconectarse con otros de acuerdo a unas normas internacionales. Es importante resaltar que OSI es una referencia abstracta y no una implementacin, es decir, OSI es un conjunto de documentos o papeles que indican cmo hay que desarrollar los protocolos. Dicho modelo irrumpi con una gran fuerza y fue adoptado por otros organismos prestigiosos de normalizacin tanto nacionales como internacionales. Tal es el caso del Comit Consultivo Internacional Telegrfico Telefnico (CCITT), lo que hoy se conoce como el sector de estandarizacin de Telecomunicaciones de la Unin Internacional de las Telecomunicaciones (ITU-T o UIT-T), que public, en 1984, un estndar equivalente (X.200). Pero a pesar de su puesta en escena, la red OSI y su arquitectura de comunicaciones del mismo nombre, sucumbi ante la llegada de la red Internet y de su arquitectura TCP/IP. De hecho, y a excepcin bsicamente de los tres primeros niveles de su arquitectura en redes de conmutacin de paquetes X.25, de los dos primeros niveles de su arquitectura de comunicaciones en redes de rea local segn la norma IEEE 802 y de su sintaxis comn de representacin y codificacin (ASN.1); en la actualidad OSI slo se emplea como una referencia estandarizada para la descripcin conceptual de los niveles de comunicaciones de otras arquitecturas (p. ej., TCP/IP). ISO pretenda que se implantara a nivel mundial una red de redes OSI, parecido a lo que hoy es Internet pero utilizando los protocolos OSI. En la Figura 1.7 se describe una hipottica red o nube OSI formada por la interconexin de una serie de redes o pequeas nubes fsicas (redes de comunicaciones). Se asume que todas las mquinas hablan un mismo lenguaje de comunicaciones basndose en un conjunto de protocolos OSI. Asimismo, al igual que en Internet, para interconectar las diferentes redes fsicas se necesitaban unas computadoras que hacan el papel de routers o de sistemas intermedios, permitiendo encaminar datos de una red a otra en funcin del destinatario. Al igual que los routers de TCP/IP disponen de un software de comunicaciones hasta el nivel de Internet o nivel de red de la arquitectura TCP/IP, los routers de OSI slo deban disponer de un software de comunicaciones hasta el nivel de red de la arquitectura OSI (nivel 3).
-8-
OSI
... ... ... ... ...

N3
RED FSICA
...
N3
OSI
... ... ... ... ...

N3
... ... ...

OSI
OSI
...
N3
... ... ...
...
N3
...
OSI
... ...
ROUTER
...
OSI
...
Figura 1.7.- Una hipottica red OSI.
1.3.1 Niveles de comunicaciones

En la Figura 1.8 se muestran los siete niveles de la arquitectura OSI y las funciones fundamentales que se realizan en cada uno de ellos.
APLICACIN
Procesos de Usuario (p.e., MOTIS/X.400)
PRESENTACIN APLICACIN
Independizacin de la Sintaxis Local mediante ASN.1 Procesos de Usuario (p.e., MOTIS/X.400)
SESIN
Administracin y Gestin del Dilogo
TRANSPORTE
Segmentacin y Transporte Extremo a Extremo
RED
Encaminamiento
ENLACE
Intercambio de datos entre dos entidades contiguas
FSICO
Acceso al Soporte de Transmisin
Figura 1.8.- Modelo OSI de ISO: Funciones de los niveles. Nivel de aplicacin (nivel 7): Es el nivel ms alto de la arquitectura OSI con el que interactan los correspondientes usuarios. Por tanto, en este nivel se ejecutan las diferentes aplicaciones o procesos de usuario como es el caso, por ejemplo, del correo electrnico que en OSI se describe en la norma MOTIS (Message Oriented Text Interchange System) cuyo equivalente ITU-T o UIT-T es, a su vez, la norma X.400.
-9-
Nivel de presentacin (nivel 6): Es el nivel responsable de la sintaxis de las informaciones intercambiadas entre entidades del nivel de aplicacin. Por consiguiente, es el nivel que se ocupa de la presentacin de los datos intercambiados por los procesos de aplicacin del usuario. Independiza las sintaxis locales de cada una de las mquinas mediante una sintaxis abstracta de representacin, codificacin y transferencia conocida como ASN.1 (Abstract Syntax Notation One). A travs de esta sintaxis se comunican mquinas que utilizan, por ejemplo, diferentes mtodos a la hora de numerar los enteros. As hay mquinas (p. ej., IBM) que empiezan a numerar sus octetos a partir del octeto ms significativo o de mayor orden, es decir, el situado ms a la izquierda (big-endian); sin embargo, hay otras (p. ej., Digital) que numeran sus octetos a partir del octeto menos significativo o de menor orden, es decir, el situado ms a la izquierda (little-endian). Asimismo, la representacin de los nmeros en coma flotante tambin difiere entre arquitecturas fsicas diferentes de mquinas. Tambin, la forma de codificar los caracteres (un octeto o dos por carcter) puede diferir de una mquina a otra, etc. ASN.1 juega un papel muy relevante fuera de la arquitectura OSI como es el caso, por ejemplo, de la arquitectura TCP/IP dentro del contexto del protocolo SNMP (Simple Network Management Protocol) de gestin de red TCP/IP para la representacin de sus variables que se almacenan en su base de informacin de gestin. Nivel de sesin (nivel 5): Es el nivel responsable de administrar y sincronizar el dilogo entre entidades del nivel de presentacin. La administracin del dilogo implica, en transmisiones semidplex (envos bidireccionales no simultneos), establecer turnos de dilogo mediante el envo de una secuencia especial de datos (testigo de control). Slo la entidad del nivel de presentacin que tenga el testigo puede transmitir datos y la otra debe permanecer en silencio. Cuando una entidad del nivel de presentacin termina de transmitir, solicita a travs de una llamada, el envo del testigo de control a su entidad del nivel de sesin que es quien ofrece dicho servicio y quien transmite dicha informacin para que la entidad del nivel de presentacin remota pueda enviar datos. A su vez, la sincronizacin del dilogo permite, cuando ocurre un fallo local (que implica prdida de datos) por encima del nivel de transporte, que las entidades del nivel de presentacin puedan reiniciar el dilogo en un punto conocido. Para ello, las entidades de presentacin dividen la informacin que desean transmitir en unas unidades denominadas pginas, mediante la insercin de un nmero de serie o punto de sincronizacin entre cada una de ellas. En el caso de presentarse un problema, se retransmiten todos los datos enviados despus del ltimo punto de sincronizacin recibido. La entidad del nivel de presentacin solicita a travs de una llamada, un punto de sincronizacin a su entidad del nivel de sesin que es
- 10 -
quien ofrece dicho servicio y quien incluye entre los datos el pertinente nmero de sincronizacin para la entidad receptora del nivel de presentacin. Por ltimo, indicar que el nivel de sesin es una capa muy delgada, es decir, con muy pocas funciones en comparacin con otros niveles. Incluso, durante el desarrollo del modelo OSI se llev a cabo un debate de gran magnitud sobre la conveniencia de disponer de dicho nivel. Nivel de transporte (nivel 4): Es el nivel responsable del transporte de los datos entre las entidades del nivel de sesin. Si el servicio ofrecido por el nivel de transporte es fiable, o lo que es lo mismo, orientado a conexin (concepto que ya se estudiar ms adelante), se establece una conexin extremo a extremo entre dos entidades de este nivel, una en la mquina de origen y otra en la mquina de destino. Por esta conexin fluyen, posteriormente, de manera ordenada todos los paquetes o unidades de datos de este nivel. En este tipo de servicio, el nivel de transporte se encarga de la fiabilidad de la comunicacin extremo a extremo, independientemente de la tecnologa, topologa, nmero y tipo de redes que hayan intervenido. Por tanto, hay todo un control de errores fsicos (deteccin y recuperacin de las unidades de datos que han cambiado fsicamente en algn bit) y lgicos (deteccin y recuperacin de unidades de datos perdidas, desordenadas y duplicadas). Asimismo, hay un control de flujo entre ambas entidades para impedir que una transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Si el servicio ofrecido por el nivel de transporte no es fiable, o lo que es lo mismo, no es orientado a conexin, no se establece ninguna conexin extremo a extremo entre dichas entidades. Consecuentemente, cada unidad de datos se trata como una unidad independiente y se enva aisladamente de las dems. Por consiguiente, no se mantiene ningn tipo de control de errores ni de flujo. Esto quiere decir que las unidades de datos pueden no llegar y en el caso de llegar, hacerlo de forma desordenada. Es importante resaltar que a partir de este nivel todas las comunicaciones son extremo a extremo ya que no va a intervenir nunca una entidad del nivel de transporte en el camino entre las dos entidades de transporte origen-destino. Nivel de red (nivel 3): Es el nivel responsable del encaminamiento de los paquetes de datos por una hipottica red OSI. Cada paquete o unidad de datos del nivel de red contiene una cabecera de informacin de control, incluyendo entre otras informaciones, la direccin de la correspondiente mquina destinataria del paquete en cuestin. En funcin de esta direccin, cada entidad del nivel de red, en el camino origen-destino, toma una decisin de encaminamiento hacia el sistema final remoto. Asimismo, al igual que en el nivel de transporte, el nivel de red puede ofrecer un servicio fiable (orientado a - 11 -
conexin) o no fiable (no orientado a conexin). Si el servicio es fiable, se establece una conexin entre las pertinentes dos entidades del nivel de red para que, adems de la funcin fundamental de encaminar, realicen todo un control de errores fsicos (deteccin y recuperacin de paquetes que han cambiado fsicamente en algn bit) y lgicos (deteccin y recuperacin de paquetes perdidos, desordenados y duplicados). Asimismo, hay un control de flujo entre ambas entidades del nivel de red para impedir que una entidad transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Si el servicio ofrecido por el nivel de red no es fiable (servicio tpico en una red de computadoras), o lo que es lo mismo, no es orientado a conexin, no se establece ninguna conexin entre las dos entidades del nivel de red. Consecuentemente, cada paquete se trata como una unidad independiente y se encamina aisladamente de los dems. Por consiguiente, no se mantiene ningn tipo de control de errores ni de flujo. Esto quiere decir, que las unidades de datos pueden no llegar y en el caso de llegar, hacerlo de forma desordenada. Nivel de enlace (nivel 2): Es el nivel responsable del intercambio de tramas (o unidades de datos de este nivel) entre dos entidades contiguas en el camino origen-destino. Asimismo, al igual que en los niveles de transporte y red, el nivel de enlace puede ofrecer un servicio fiable (orientado a conexin) o no fiable (no orientado a conexin). Si el servicio es fiable (servicio tpico en una red de computadoras OSI), se establece una conexin entre las pertinentes dos entidades del nivel de enlace para que realicen todo un control de errores fsicos generados por el medio fsico de interconexin (deteccin y recuperacin de tramas que han cambiado fsicamente en algn bit) y lgicos (deteccin y recuperacin de tramas perdidas, desordenadas y duplicadas). Asimismo, hay un control de flujo entre ambas entidades del nivel de enlace para impedir que una entidad transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Si el servicio ofrecido por el nivel de enlace no es fiable, o lo que es lo mismo, no es orientado a conexin, no se establece ninguna conexin entre las dos entidades del nivel de enlace. Consecuentemente, cada trama se trata como una unidad independiente y se enva aisladamente de las dems. Por consiguiente, no se mantiene ningn tipo de control de errores (slo hay una deteccin de errores fsicos sin recuperacin) ni de flujo. Nivel fsico (nivel 1): Es el nivel responsable del acceso al medio fsico de interconexin. Por consiguiente, define las caractersticas elctricas (niveles de tensin o voltaje entre los cables, ), mecnicas (forma y constitucin de los conectores, disposicin de los pines, ) y lgicas (seales intercambiadas) con el dispositivo de transmisin-recepcin (p.ej., un mdem) para acceder al medio fsico y permitir el envo de tramas entre las dos entidades contiguas del nivel de - 12 -
enlace. En consecuencia, en este nivel no hay entidades de software y, por tanto, no existe ningn protocolo del nivel fsico entre mquinas adyacentes.
1.3.2 Puntos de acceso al servicio

N+1
Interfaz Nivel N+1
SAP N
Nivel N
Figura 1.9.- Punto de acceso al servicio (SAP). ISO ha definido, para su arquitectura OSI, un conjunto de trminos y conceptos estandarizados que conviene conocer y que, con los mismos o con diferentes nombres, se han trasladado a otras arquitecturas de comunicaciones como es el caso de TCP/IP. 1. Servicio: Resultado de efectuar una o ms acciones o funciones definidas por el correspondiente protocolo. Formalmente, un servicio en OSI se identifica por un conjunto de primitivas o llamadas u operaciones. 2. Primitiva: Concepto abstracto que define3 cmo llevar a cabo la llamada a un servicio. Obviamente, para poder llamar a un servicio proporcionado por una entidad de software, primeramente, hay que saber llamar a dicha entidad. 3. SAP4 (Service Access Point): Punto de acceso al servicio o identificador de la entidad de software del nivel inmediatamente superior (vecino del piso de arriba), cuando en este nivel existe ms de una entidad. Un SAP del nivel N identifica siempre a una entidad del nivel N+1. Por tanto, en las llamadas de abajo arriba se usan los SAP para poder identificar a una entidad de entre otras que se encuentran en el nivel inmediatamente superior. En las llamadas de
En un documento para el programador.
Este mismo nombre (SAP origen y SAP destino) se usa, por ejemplo, en el subnivel LLC (Logical Link Control) 802.2 del nivel de enlace de la arquitectura de comunicaciones de redes de rea local que siguen la norma IEEE 802. Mediante este concepto se identifica a la entidad de software del nivel inmediatamente superior.
- 13 -
arriba abajo siempre se interacta con la misma entidad5 del nivel inmediatamente inferior. Cuando se realiza una llamada del nivel N+1 al nivel N se pasa, como un parmetro ms de la llamada, el SAP de la entidad remota N+1. Los SAP representan la frontera o lnea divisoria que define el interfaz entre los niveles de comunicaciones adyacentes en un mismo sistema.
1.3.3 Servicios
Sistema A
Nivel N+1
Sistema B PDU N+1
N+1
N+1
Nivel N+1
Solicitud
Interfaz
Confirmacin SAP N SAP origen
Respuesta SAP N
Indicacin
Interfaz
SAP destino
Nivel N
Nivel N
N
Conexin N
Figura 1.10.- Servicio confirmado. Dos entidades pares son dos entidades de software que se rigen bajo el mismo protocolo de comunicaciones y que estn ubicadas en el mismo nivel en sistemas diferentes. Por tanto, para que dos entidades pares del nivel N+1 se intercambien unidades de datos del protocolo (PDU: Protocol Data Unit) del nivel N+1, necesitan previamente un servicio del nivel N. Si el servicio ofrecido por el nivel N es confirmado (ver Figura 1.10), la entidad N+1 requiere cuatro primitivas del nivel N: Solicitud: Llamada de la entidad N+1 a la entidad N, en el sistema local emisor, para solicitar un servicio del nivel N. Indicacin: Llamada de la entidad N a la entidad N+1, en el sistema receptor remoto, para indicar a la entidad N+1 que una entidad par ha solicitado un servicio del nivel N con el objetivo de comunicarse con ella.
Identificada previamente en la configuracin local OSI.
- 14 -
Respuesta: Llamada de la entidad N+1 a la entidad N, en el sistema receptor remoto, para responder afirmativamente6 al servicio previamente solicitado por su entidad par. Confirmacin: Llamada de la entidad N a la entidad N+1, en el sistema local emisor, para indicar a la entidad N+1 que su entidad par desea confirmar el servicio previamente solicitado.
Sistema A
Nivel N+1 Solicitud de Servicio N
Sistema B PDU N+1
N+1
Interfaz
N+1
Nivel N+1 Indicacin de Servicio N
SAP N Origen
Interfaz
SAP N Destino
Nivel N
N
Servicio N
Nivel N
Figura 1.11.- Servicio no confirmado. Como ya se ha indicado, para que dos entidades pares del nivel N+1 se intercambien unidades de datos del protocolo (PDU: Protocol Data Unit) del nivel N+1, necesitan previamente un servicio del nivel N. Si el servicio ofrecido por el nivel N es no confirmado (ver Figura 1.11), se requieren, a su vez, dos primitivas del nivel N: Solicitud: Llamada de la entidad N+1 a la entidad N, en el sistema local emisor, para solicitar un servicio del nivel N. Indicacin: Llamada de la entidad N a la entidad N+1, en el sistema receptor remoto, para indicar a la entidad N+1 que una entidad par ha solicitado un servicio del nivel N para poder comunicarse con ella.
En caso de respuesta negativa, el servicio de la entidad N debe ofrecer a la entidad N+1 otro servicio mediante otra llamada representada por la correspondiente primitiva para solicitar un aborto de la conexin. De esta forma, N enva, por la red a su entidad par, un mensaje con esta informacin de control para que tenga constancia de este hecho la entidad N+1 en el Sistema A.
- 15 -
Asimismo, si el servicio ofrecido por un hipottico nivel N es fiable (ver siguiente Figura 1.12), se dice que el servicio es orientado a conexin, el cual dispone siempre de tres fases: 1. Establecimiento de la conexin (entre entidades del nivel N): Es una especie de aviso; primero, para que la entidad remota N + 1 d su consentimiento para recibir datos de nivel N+1 y, segundo, para que ambas entidades pares del nivel N lleven a cabo, en la siguiente fase de transferencia de datos, todas las funciones fiables como, la correccin de errores fsicos (bits cambiados en las unidades del nivel N transmitidas) y errores lgicos (unidades de datos del nivel N perdidas, desordenadas y duplicadas). Asimismo, efectan el correspondiente control de flujo para evitar congestiones. Se recuerda, que cada unidad de datos del nivel N encapsula una unidad de datos del nivel N+1. La fase de establecimiento de la conexin es siempre un servicio confirmado. 2. Transferencia de datos (entre entidades del nivel N): El envo de las unidades de datos se realiza fiablemente, es decir, ambas entidades del nivel N colaboran en el control de errores y flujo de la informacin intercambiada. La fase de transferencia de datos es siempre un servicio no confirmado. Las confirmaciones a los datos recibidos correctamente se envan por el propio protocolo del nivel N que es el que ofrece el servicio fiable. 3. Liberacin de la conexin (entre entidades del nivel N): Una vez las entidades del nivel N han transferido todas las unidades de datos del nivel N (encapsulan, a su vez, a las unidades de datos del nivel N+1), se procede a la liberacin de la conexin previamente establecida. La fase de liberacin de la conexin es siempre un servicio no confirmado. La confirmacin7 (OK!) al mensaje de Fin (liberar la conexin) se enva, en la Figura 1.12, porque as est diseado por el propio protocolo del nivel N; pero no porque se lo haya indicado la entidad del nivel N+1 a travs de otra llamada. Incluso, el protocolo del nivel N podra obligar a la entidad del nivel N del sistema B a transmitir otro mensaje de Fin (liberar la conexin) a su entidad par en el sistema A y que sta tambin se d por enterada transmitiendo, a su vez, otro OK! De esta ltima forma, y como otra alternativa ms de liberacin a la indicada en la Figura 1.12, una entidad N puede estar transmitiendo datos mientras la otra ha cerrado su lado de la conexin. Por consiguiente, en este ltimo caso, la conexin se liberar completamente cuando se enva en los dos sentidos un mensaje de Fin y se reciben los OK! pertinentes.
Si existen (no es obligatorio).
- 16 -
N+1
Sistema A
Medio Fsico de Interconexin N N
Sistema B N+1
Solicitud (Conexin)
Inicio de conexin
OK!
Indicacin (Conexin)
Respuesta
Confirmacin
Solicitud (Datos)
Datos OK!
(Protocolo del niv
Indicacin (Datos)
el N)
) Indicacin (Datos
Datos
Solicitud (Datos)
OK!
(Protocolo del nivel N )
Solicitud (Liberacin)
Fin OK!
el N) (Protocolo del niv
Indicacin (Liberacin )
Figura 1.12.- Servicio del nivel N orientado a conexin. Si el servicio ofrecido por un hipottico nivel N es no fiable, se dice que el servicio es no orientado a conexin (ver siguiente Figura 1.13), el cual dispone slo de una fase: Transferencia de datos (entre entidades del nivel N): El envo de las unidades de datos se realiza sin fiabilidad, es decir, cada unidad de datos del nivel N se trata como una unidad independiente y se enva aisladamente de las dems. Por consiguiente, no se mantiene ningn tipo de control de errores ni de flujo. Esto quiere decir, que las unidades de datos pueden no llegar y en el caso de llegar, hacerlo incorrectamente. La entidad receptora del nivel N va pasando los datos al nivel N+1 segn van llegando (aunque lleguen desordenadamente o con errores). Como el servicio ofrecido por el nivel N es no orientado a conexin, la entidad N del sistema B y del sistema A no enva ningn tipo de confirmacin (OK!) a las unidades de datos recibidas (ver siguiente Figura 1.13). Asimismo, tampoco hay un control de flujo, por tanto, cuando una entidad N se congestiona, empieza a eliminar todas las unidades del nivel N que vaya recibiendo. La fase de transferencia de datos ya sea de un servicio orientado a conexin o no orientado a conexin es siempre un servicio no confirmado. Este tipo de servicio de nivel N es lo que se entiende, tambin, por un servicio no orientado a conexin sin confirmacin, es decir, en el nivel N no existe ningn mecanismo de confirmaciones a los datos recibidos.
- 17 -
N+1
Sistema A
Medio Fsico de Interconexin N N
Sistema B N+1
Solicitud (Datos)
Datos
Datos
Indicacin (Datos)
Solicitud (Datos)
) Indicacin (Datos
Figura 1.13.- Servicio del nivel N no orientado a conexin sin confirmacin. El servicio no orientado a conexin sin confirmacin8, es til en dos situaciones. En primer lugar, cuando los niveles superiores ofrecen los mecanismos de control de errores y flujo necesarios. En segundo lugar, cuando no tiene ningn sentido establecer y mantener una conexin como puede ser, por ejemplo, el muestreo peridico de sensores de datos, componentes de seguridad y las transmisiones de imgenes o audio. En estos escenarios, la prdida ocasional de datos puede no ser importante siempre que stos lleguen de forma rpida. Un servicio menos tpico y, por tanto, menos utilizado es el servicio no orientado a conexin con confirmacin9. Este servicio tiene una cierta utilidad, por ejemplo, en la gestin de alarmas o seales de control de emergencia de una organizacin. Sera muy til una confirmacin de modo que el emisor pueda estar seguro de que el receptor ha recibido la seal o el aviso pertinente. Adems, teniendo en cuenta la urgencia de la seal, por razones obvias, no se debe perder tiempo en establecer la conexin como paso previo a la transferencia de los datos (aviso de alarma). Este ltimo servicio, aunque menos usual que los anteriores (orientado a
Que por otro lado es el tpico servicio no orientado a conexin cuya fase de transferencia es siempre un servicio no confirmado (dos primitivas).
9
A pesar del juego de palabras, la fase de transferencia de datos sigue siendo un servicio no confirmado (dos primitivas).
- 18 -
conexin y servicio no orientado a conexin sin confirmacin) se muestra en la siguiente Figura 1.14:
Sistema A Medio Fsico de Interconexin N N Sistema B N+1
N+1
Solicitud (Datos)
el N) (Protocolo del niv
Datos OK!
Indicacin (Datos)
Solicitud (Datos)
s) Indicacin (Dato
Datos
OK!
(Protocolo del nivel N )
Figura 1.14.- Servicio del nivel N no orientado a conexin con confirmacin.
1.3.4 Protocolos e interfaces

En este contexto, conviene diferenciar claramente entre protocolo e interfaz. Protocolo: Conjunto de reglas que controlan la interaccin entre entidades pares o iguales. Interfaz: Conjunto de reglas que controlan la interaccin entre entidades no pares, pero contiguas en el mismo sistema.
Por ejemplo, dos entidades pares o iguales (entienden el mismo protocolo) del nivel N en dos mquinas diferentes, llevan a cabo las mismas acciones a travs de su protocolo del nivel N. Sin embargo, dos entidades contiguas (p. ej., N y N-1) ubicadas en la misma mquina pero en niveles adyacentes diferentes (por tanto, son dos entidades diferentes), se rigen por el interfaz o lnea divisoria que les separa en el sistema.
- 19 -
PROTOCOLO Interfaz Interfaz
PROTOCOLO
Medio Fsico
Figura 1.15.- Diferencias entre protocolo e interfaz. Para una mayor comprensin de la diferencia existente entre protocolo e interfaz, se muestra en la Figura 1.15 una analoga entre dos sistemas con una misma arquitectura estructurada de comunicaciones de dos niveles y dos edificios de dos pisos. En el piso superior se encuentran dos arquitectos (dos entidades pares o iguales) que estn diseando una iglesia segn el protocolo que define una jerga o argot tcnico arquitectnico. El protocolo de este nivel define el formato de los mensajes arquitectnicos y las acciones que hay que realizar en funcin de dichos mensajes. En el nivel de abajo existen otras entidades que realizan unas funciones de transmisin de los mensajes del piso superior, por ejemplo, si tu hablas yo me callo, si hablas muy deprisa hazlo ms despacio, si no te entiendo repite, etc. Pues bien, teniendo en cuenta que en el piso superior no se tiene acceso directo al medio fsico de interconexin, los mensajes deben pasar a travs del pertinente interfaz (en la analoga un agujero en el suelo o la escalera) al piso inmediatamente inferior en el sistema emisor y al superior en el sistema receptor.
- 20 -
1.4

Bibliografa
Information Processing Systems-Open Systems Interconnection-Basic Reference Model, ISO 7498 (X.200, ITU-T), 1978. OSI EXPLAINED End to End Computer Communication Standards; J. Hendshall, S. Shaw, Ellis Horwood, 1988. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. Comunicaciones y Redes de Computadores. Sexta edicin. William Stallings. Ed. Prentice-Hall. 2000. Computer Networks. Cuarta edicin. A. S. Tanenbaum. Ed. International 2003. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002. Redes de Ordenadores. Protocolos, normas e interfaces. U. Black. Editorial. Ra-ma. 1995.
- 21 -
- 22 -
Captulo 2. Modelo en Internet
2. MODELO INTERNET
DE
COMUNICACIONES
EN
Una vez se han analizado los conceptos ms relevantes del modelo o arquitectura OSI como referencia estandarizada; se pasa, a continuacin, a estudiar con ms detenimiento el modelo de protocolos de comunicaciones de TCP/IP utilizado en la red Internet.
2.1
Historia
A principios de la dcada de los 60, el mundo se encontraba en plena psicosis de guerra fra. La posibilidad de un ataque nuclear era un supuesto manejado por las autoridades de los EE UU. Tras el temor a un desastre de este tipo, la cuestin que haba que resolver se poda resumir en lo siguiente: Cmo establecer una comunicacin despus de una tragedia de este tipo? No haba duda de que la Amrica de esa poca iba a necesitar una red robusta de mando y control que uniera entre s las bases esparcidas por todo el pas. Sin embargo, por mucho que se protegieran los nodos o sistemas intermedios (routers) y las lneas de comunicaciones siempre subsistira la posibilidad de que una bomba nuclear alcanzase el centro de control, objetivo primordial del enemigo, con lo que la red quedara inservible. En este escenario, el Departamento de Defensa (DoD) de los EE UU cay en la cuenta de que la tecnologa de conmutacin de circuitos empleada por la red telefnica tradicional era demasiado frgil para resistir el ms mnimo ataque y mucho menos la tan temida guerra nuclear. Si se destrua una conexin entre dos centrales importantes o quedaba una central fuera de servicio, buena parte de las comunicaciones de defensa del pas podran quedar inutilizadas. Sin embargo fue la corporacin RAND10, nido de estrategas de la guerra fra, quien plant cara a este importante problema, intentando responder a las siguientes preguntas: Cmo podran las autoridades de los EE UU comunicarse tras un ataque nuclear? Cmo se debera controlar y gobernar la red, teniendo en cuenta que una autoridad central sera, obviamente, el objetivo inmediato de un misil enemigo?
10
Research and Development.
- 23 -
En 1964 se promulg la propuesta RAND encaminada a solventar las eventualidades anteriores, cuyos principios11 fueron los siguientes: Todos los nodos deberan ser iguales y sin una autoridad central de control. Los mensajes se dividiran en bloques de una menor longitud denominados paquetes. Cada uno de estos paquetes llevara la informacin necesaria para ir de forma independiente desde un nodo origen a un nodo destino. La ruta particular de cada paquete no importaba, es ms los diferentes paquetes pertenecientes a un mismo mensaje podan ir por rutas diferentes. Slo contaba el resultado final, es decir, que existieran los mecanismos adecuados para recomponer el mensaje original en el lugar de destino. Por ejemplo, si se deseaba enviar un mensaje desde una mquina en New York a San Francisco, un trozo (paquete) podra ir por el norte (p. ej., Chicago), otro por el centro (p. ej., Denver) y otro por el sur (p. ej., Houston). Lo importante es que la mquina destinataria en San Francisco dispusiera del software necesario para reconstruir el mensaje tal y como ha salido desde la mquina de origen en New York. Naca de esta forma, un tanto siniestra, el concepto de RED DE CONMUTACIN DE PAQUETES y, por ende, la tecnologa del mismo nombre, como ejemplo de un sistema lo suficientemente robusto como para hacer frente a adversidades y fallos. Se resalta que Internet es una red de computadoras que basa su funcionamiento en la tecnologa de conmutacin de paquetes mediante un servicio de encaminamiento no orientado a conexin. La idea de crear una red descentralizada, basada en la conmutacin de paquetes y a prueba de bombas fue tomando cuerpo en el Instituto Tecnolgico de Massachusetts (MIT) y en la Universidad de California en Los ngeles (UCLA). Curiosamente, fue el Laboratorio Nacional de Fsica del Reino Unido quien primero construy un prototipo de esas caractersticas en 1968. En respuesta al lanzamiento, en 1957, del primer satlite sovitico (el Sputnik), el DoD fund la Agencia de Proyectos de Investigacin Avanzada del Pentgono (ARPA) para devolver la superioridad a los EE UU en aplicaciones informticas militares. En 1969, ARPA decidi financiar a la empresa BBN (Bolt, Beranek, and Newman, Incorporated) para llevar a cabo un experimento similar al europeo, aunque ms ambicioso, en los EE UU y en donde los nodos de la red se utilizaran para unir supercomputadoras de aquella poca. La BBN entreg en otoo de 1969, un primer nodo a la Universidad de
11
Que son la base de la actual Internet.
- 24 -
California en Los ngeles (UCLA). En diciembre de 1969, ya haba otros tres ms, concretamente en: El Instituto de Investigacin en Stanford (SRI). La Universidad de California en Santa Barbara (UCBS). La Universidad de Utah. La instalacin y puesta en funcionamiento de estos cuatro nodos en diciembre de 1969, es lo que constituy ARPANET, red que se llam as en honor a sus patrocinadores y que constituy el embrin de la futura red Internet. Durante los aos 70, la red ARPA fue creciendo pues su estructura descentralizada facilitaba la correspondiente expansin. Todos los sistemas conectados a ARPANET se comunicaban mediante un mismo lenguaje o protocolo basado en la tcnica de conmutacin de paquetes y conocido con el nombre de NCP (Network Control protocol). En 1973, ARPA que fue rebautizada como DARPA (Defense Advanced Research Projects Agency), lanz una nueva iniciativa con el objetivo de financiar la investigacin en tcnicas y tecnologas para conectar redes de paquetes de varios tipos. La idea era apoyar el desarrollo de protocolos (militares) de comunicaciones que permitieran a las computadoras comunicarse de modo transparente a travs de la interconexin de distintas redes de paquetes. Esta iniciativa fue bautizada como Proyecto Internetting, del que ha derivado el nombre actual de Internet. Un poco antes de que surgiera Internetting, Vinton Cerf en su laboratorio de Stanford y Robert Kahn en la compaa BBN, haban estado trabajando conjuntamente en entornos mviles de red (redes de radio y satlite de conmutacin de paquetes), diseando los correspondientes protocolos de interconexin. Es ms, en 1974 apareci un primer diseo del protocolo TCP (Transmission Control Protocol), en el que no se distingua entre TCP e IP (Internet Protocol), slo se hablaba del protocolo de control de transmisin en el nivel de transporte. Dicho esbozo de lo que luego seran los protocolos TCP/IP, apareci en un artculo publicado por Cerf y Kahn en mayo de 1974 en la revista IEEE Transactions of Communications.
- 25 -
TCP/IP
Figura 2.1.- Los protocolos en Internet. Antes de seguir, conviene recordar que TCP/IP son los protocolos de comunicaciones que definen el idioma o lenguaje utilizado para asegurar la interoperabilidad en Internet entre los diferentes sistemas finales de los usuarios. Igual que las personas necesitan utilizar un mismo idioma para entenderse, las mquinas en Internet necesitan utilizar unos mismos protocolos en cada uno de los niveles de comunicaciones de la arquitectura TCP/IP. Continuando con la historia de Internet y TCP/IP, la primera demostracin de los protocolos TCP/IP fue en julio de 1977, y en un escenario montado para interconectar las tres redes siguientes basadas en la tecnologa de paquetes: Red de radio de conmutacin de paquetes (PRNET: Packet Radio Network). Red de satlite de conmutacin de paquetes (SATNET: Packet Satellite Network). Red de cable de conmutacin de paquetes (ARPANET). De esta manera, se simul el escenario de un campo de batalla y, mediante una unidad mvil, basada en un sistema de radio (ubicada en San Francisco), se transmiti informacin a otras mquinas a nivel continental (EE UU) e intercontinental (Noruega e Inglaterra). Evidentemente, este tipo de demostraciones gustaron mucho a DARPA, que decidi en 1980, adoptar los protocolos TCP/IP y convertirlos en sus protocolos militares por excelencia. Posteriormente, en 1982, se decidi que todos los sistemas que se conectaran a ARPANET transitaran del viejo NCP al nuevo conjunto de protocolos TCP/IP.
- 26 -
Mientras tanto el uso de los protocolos TCP/IP se fue generalizando en otras redes para su conexin a ARPANET, que segua creciendo de forma sostenida, y transformndose en la futura red troncal (backbone nacional) de la nueva Internet. Es importante hacer notar, que a comienzos de la dcada de los 80 surgieron en el mundo cientfico de EE UU, otras redes para dar servicio a la comunidad cientfica e investigadora no directamente relacionada con ARPANET, como son las siguientes que se describen por su relevancia: CSNET (Computer Science Network): Se cre en 1981 e interconectaba los departamentos de informtica o de ciencias de la computacin de las universidades y centros pblicos de algunos estados de EE UU. Fue la primera red autnoma en conectarse con ARPANET va TCP/IP. BITNET (Because Its Time Network): Tambin se cre en 1981 y a su vez, interconectaba los departamentos de ciencias de algunos estados de EE UU. Por consiguiente, a diferencia de CSNET que una a los informticos, BITNET tena un carcter notoriamente multidisciplinar.
En 1983, la Agencia de Comunicacin de la Defensa (DCA) responsable de la instalacin de Redes de Datos de la Defensa y que desde julio de 1975 se ocupaba de ARPANET, separ sta en dos redes independientes: MILNET: La red de comunicaciones militares, creada para un entorno estrictamente militar. ARPANET: La red de investigacin que permaneci con el mismo nombre para dicho contexto de investigacin y desarrollo. Asimismo, era la red usada por las agencias gubernamentales de los EE UU (NASA, CIA, FBI, DCA, Departamento de Energa, ...). A pesar de su crecimiento, ARPANET, se fue quedando como una comunidad ms reducida frente a otras que iban surgiendo, impulsadas por la necesidad de conectar las nuevas y potentes mquinas que proliferaban, las cuales se interconectaban entre s mediante un pegamento transparente que una mltiples redes sin costuras aparentes. Puesto que el software de TCP/IP era de dominio pblico y la tecnologa bsica era descentralizada, era imposible frenar el impulso de interconexin de los usuarios.
- 27 -
En este contexto, la red Internet nace en 1983 como red de interconexin entre: ARPANET MILNET CSNET Las tres redes anteriores se unieron mediante los protocolos TCP/IP y a las cuales, posteriormente, se iran uniendo otras redes de EE UU y de otros pases. En este contexto, ARPANET se convirti en la red troncal de Internet. Un hecho resaltable en la historia de Intenet y TCP/IP fue en 1980, cuando DARPA (que al fin al cabo estaba financiada con dinero pblico) decidi que los protocolos TCP/IP no fueran un secreto militar, abrindolos al pblico en general de forma gratuita. Por tanto, una decisin trascendental de DARPA, en cuanto a potenciar el uso de los protocolos TCP/IP, fue llevarlos al entorno Unix, ya que con ello, consigui que el gran contexto universitario se interesara por dichos protocolos y comenzara a utilizarlos. Consecuentemente, para animar a los investigadores universitarios a adoptar y usar los nuevos protocolos, DARPA no tuvo mejor idea que financiar a sus viejos amigos de la BBN para que desarrollaran una implementacin de los protocolos TCP/IP sobre el Unix estndar de AT&T. Asimismo, financi a la Universidad de Berkeley (California) para que hicieran un porting o traslado del trabajo llevado a cabo por la BBN, al Unix de Berkeley v4.2. Como resultado de todo ello, DARPA consigui en una primera tacada que el uso de TCP/IP alcanzara el 90% de los departamentos universitarios informticos o de ciencias de la computacin. Adems, todo esto provoc incluso que muchos fabricantes y vendedores de computadoras, como es el caso de Sun Microsystems, comenzaran a utilizar BSD como base en sus productos comerciales. Asimismo, la Universidad de Berkeley desarroll un interfaz de programacin de aplicaciones (API de sockets) basado en unas libreras de funciones para facilitar la creacin e integracin de nuevas aplicaciones en la arquitectura TCP/IP y, por tanto, en Internet. Es importante recordar que TCP/IP se desarroll originalmente para la comunicacin de computadoras con sistema operativo Unix a travs de ARPANET. Los aos de 1983 a 1985 fueron un periodo de consolidacin de los protocolos Internet, en el sentido de que numerosos fabricantes de equipos informticos empezaron a sacar al mercado equipos que hablaban TCP/IP, convirtindolos en el estndar de facto para la intercomunicacin de computadoras.
- 28 -
Un ltimo factor decisivo en la historia de la arquitectura TCP/IP fue el nacimiento en 1986 de la red de alta velocidad NSFnet12 de la National Science Foundation (NSF) cuyo objetivo fue facilitar a toda la comunidad cientfica e investigadora americana el acceso mediante lneas de alta velocidad (56.000 bps en 1986, 1.5 Mbps en 1989 y 45 Mbps en 1992), a cinco grandes centros de supercomputacin. Ante los impedimentos de tipo burocrtico y administrativo para utilizar ARPANET, la NSF decidi crear una red propia que acabara convirtindose en la autntica espina dorsal o red troncal (backbone) de Internet. Para rentabilizar las inversiones, en vez de hacer una red en estrella, enlazando cada universidad o cada centro con los supercomputadoras mediante extensos circuitos dedicados, NSF financi una docena, aproximadamente, de redes regionales (casi una por estado) que se conectaron a la red troncal. A su vez, la red troncal NSFnet se conect al backbone de Internet de DARPA (ARPANET backbone). Dado su carcter abierto a toda la comunidad cientfico e investigadora13, la red NSFnet desencaden una explosin de conexiones sobre todo por parte de las universidades, originando una demanda creciente e imparable de conectividad Internet. Paralelamente, otras agencias del gobierno de EE UU (la NASA, el Departamento de Energa y el Instituto Nacional de la Salud) fueron poniendo en marcha sus propias redes, creando de este modo toda una confederacin TCP/IP. Paralelamente al auge de Internet, el final de la dcada de los 80 signific tambin el declive de ARPANET desde la entrada en escena de NSFnet; expirando pacficamente en 1990, vctima de su propio xito. Sus usuarios apenas notaron su desaparicin, debido a que su funcionalidad no slo permaneci sino que fue mejorando continuamente al ser reemplazada por una nueva red (INTERNET) con una tecnologa propia (TCP/IP). En el mismo ao de la desaparicin de ARPANET, concretamente, en julio del 90 se realiza la primera conexin espaola con Internet, mediante un servicio experimental de RedIRIS14 (http://www.rediris.es), un organismo dependiente del CSIC (Consejo Superior de Investigaciones Cientficas) que gestiona la actual Red nacional acadmica y de I + D en Espaa.
12
Una nube ms en Internet, la cual fue creada con dinero pblico para apoyar al mundo educativo y de investigacin. Al contrario que las iniciativas anteriores ms restringidas a investigadores del gobierno y al rea de la defensa. Antes Fundesco.
13
14
- 29 -
Para una mayor comprensin, la clave del desarrollo del fenmeno de Internet se podra resumir en dos aspectos fundamentales: Aspecto Tcnico: IP SOBRE TODO (antiguo eslogan en Internet).- El protocolo IP (Internet Protocolo) que se define en el nivel de red de la arquitectura TCP/IP, es la pieza clave sobre la que se construye toda la red Internet. Su simplicidad y flexibilidad hace posible su funcionamiento sobre todo tipo de tecnologas de red, lo cual posibilita en cualquier entorno el uso del resto de los protocolos superiores de la arquitectura Internet. Aspecto Estratgico: LIBERTAD, COOPERACIN Y GRATUIDAD.- Nadie gobierna Internet. No existe ningn organismo propio de Internet que se encargue de operar la red, por lo que hay una ausencia de innecesarias trabas de tipo burocrtico y administrativo. Internet es de todos y de nadie a la vez. Cada red conserva su independencia y est controlada y gobernada por su propia organizacin interna, por tanto, pertenece a todos y a nadie a la vez. Cada individuo y cada organizacin es el dueo de sus mquinas y de su informacin. No hay jefes ni censores oficiales ni oficiosos. Al no existir una autoridad central y ser una red democrtica y descentralizada, todos los nodos pueden dialogar entre ellos de igual a igual. Por consiguiente, Internet es incontrolable por una autoridad central, es decir, no tiene propietario. Quiere decir esto, que en todo caso es la propia comunidad la que debe autorregularse, ignorando o bloqueando por accin (enviando mensajes al origen de una determinada informacin) u omisin recriminando cualquier actitud incorrecta o deshonesta. En este escenario, es importante tener claro que la censura en Internet es algo totalmente absurdo. El contenido ilcito de una mquina en un pas determinado, puede ser absolutamente legal en otro pas diferente. Teniendo en cuenta que en Internet no se factura por la distancia, no habra ms que cambiar la informacin de una mquina a otra. Para una censura completa, todos los pases deberan acordar unas mismas reglas del juego. Pero, cundo todos los pases de este planeta se han puesto de acuerdo en algo? Los que pretenden censurar en Internet es que han entendido muy poco y, seguramente, les quede un largo camino todava por recorrer. Volviendo a otro aspecto estratgico. Se destaca el hecho de que numerosos individuos e instituciones han colaborado desinteresadamente en el desarrollo de nuevos procedimientos y aplicaciones, cuyo uso se ha ido extendiendo porque, a su vez, otros han participado con crticas, sugerencias, pruebas y mejoras. Por ltimo, recordar que en Internet no hay facturacin en funcin de la distancia a diferencia de otras redes comerciales. Tampoco se factura por el tiempo de acceso ni por el volumen de
- 30 -
trfico, otra cosa es lo que el usuario compre en Internet y lo que haga cada proveedor de servicios o ISP15 (que dispone de su propia infraestructura de red y men de servicios) en funcin de su esquema de tarifas. Otra de las razones del enorme crecimiento de Internet se debe en parte a que es una red basada en redes fsicas creadas con fondos gubernamentales o pblicos de cada pas dentro de Internet, lo que proporciona un servicio global prcticamente gratuito. Con respecto al conjunto de protocolos TCP/IP utilizados en Internet, stos renen una serie de caractersticas que se mencionan a continuacin: A pesar de que los protocolos TCP/IP son unos estndares de facto, son los protocolos ms extendidos y utilizados en el mundo de las comunicaciones de datos. No slo son de libre distribucin, sino que adems su funcionamiento est garantizado en la inmensa mayora de los sistemas. La estructura administrativa (IAB, o Internet Advisory Board) que coordina Internet, no opera la red (de ah su xito). Eso s, promueve el conocimiento general de la red y su tecnologa, definiendo las reglas de carcter tcnico. Toda la literatura Internet (documentos RFC o Request for Comments) es de dominio pblico y se encuentra, por la red, a la libre disposicin de cualquiera que necesite un documento al respecto. Los protocolos TCP/IP se encuentran implantados en la totalidad de los sistemas operativos (Unix, Windows, etc.). A diferencia de OSI/ISO, los productos TCP/IP han tenido una gran repercusin y acogida debido a que la realizacin de los estndares (de facto) sigue un proceso natural de ABAJO a ARRIBA, en cuanto a que primero se desarrolla, luego se prueba y despus se normaliza. De este modo, cuando un estndar llega a ser estable ya hay productos que lo implementan. El resultado es que el mercado ha surgido de forma natural. Si a esto se aade la colaboracin desinteresada entre mltiples individuos, grupos e instituciones y la ausencia de innecesarias trabas de tipo burocrtico y administrativo, se entiende el enorme crecimiento de todo lo que conlleva este entorno.
A continuacin, se procede a una definicin ms concreta de la red Internet y cmo sta se va formando. Partiendo del hecho, de que una red de computadoras no es ms que un conjunto de mquinas que hacen uso, tanto de las redes de datos subyacentes como de
15
El concepto de ISP se estudiar ms adelante.
- 31 -
un mismo conjunto de protocolos para comunicarse, asegurando tanto la interconexin como la interoperabilidad entre dichos computadoras; se puede avanzar en la definicin y definir Internet como: Una inmensa red de computadoras o red abstracta formada por la interconexin de muchas redes fsicas (redes de comunicaciones), cualquiera que sea su tecnologa y en donde todas utilizan la arquitectura de protocolos TCP/IP y, comparten un mtodo de direccionamiento comn. Internet o la red del mismo nombre, es la mayor red TCP/IP de computadoras que existe, la madre de todas las redes de computadoras. Por consiguiente, es una red lgica, abstracta o virtual que hace uso de las propias redes fsicas subyacentes que proporcionan la correspondiente infraestructura fsica de interconexin. Quiere decir esto, que todas las redes fsicas que intervienen componen una red lgica, de ah que digamos que Internet es la mayor red de redes existente en el planeta.
GATEWAY (ROUTER)
RED 1
RED 2
RED LGICA (PRIVADA) = RED 1 + RED 2

Figura 2.2.- Formacin de una red abstracta o de computadoras. La interconexin fsica de dos o ms redes fsicas (redes de comunicaciones) slo se puede realizar por medio de una computadora conectada a cada una de ellas. A la computadora que pasa las correspondientes unidades de datos (paquetes) entre redes se le denomina gateway o router o pasarela o dispositivo de encaminamiento o, simplemente, encaminador. ltimamente, se prefiere utilizar el trmino router o encaminador al de gateway, trmino original utilizado en los primeros documentos sobre Internet y TCP/IP. La Figura 2.2 describe el caso ms simple de interconexin de redes fsicas o redes de comunicaciones para formar una red abstracta o lgica privada (red de computadoras privada). En la siguiente Figura 2.3 se vuelve a mostrar una hipottica red o nube Internet formada por la interconexin de una serie de redes o pequeas nubes fsicas (redes de comunicaciones). Asimismo, como tambin se ha comentado con anterioridad, se estudiar que existen unas computadoras que hacen de dispositivos de encaminamiento - 32 -
y que se conocen como routers, los cuales juegan el papel de sistemas intermedios, encaminando datos de una nube a otra en funcin del destinatario.
... ... ... ...

INTERNET
RED FSICA
...
...
...
... ...
...
...
... ... ...
... ... ... ...
...
...
...
...
ROUTER
...
...
Figura 2.3.- Una hipottica red Internet. Prcticamente desde 1988, Internet ha venido experimentando un crecimiento exponencial en casi todos sus parmetros. Algunos datos son los siguientes: En 1969 haba una nica red fsica (ARPANET: embrin de Internet) En 1984 haba ms de 1000 redes fsicas interconectadas en Internet. En 1992 Internet enlazaba ms de 10.000 redes de 50 pases. En 1994 se haba logrado integrar 25.000 redes de 146 pases. En 1995 se interconectaban ms de 35.000 redes fsicas y el nmero de mquinas servidoras (sistema operativo multiusuario) era de de unos 4.800.000.
Tal y como se muestra en la siguiente Figura 2.4, hoy ya se puede hablar de ms de cien mil redes fsicas (prcticamente cada 30 minutos se conecta una nueva red a Internet), de ms de 75 millones de mquinas servidoras, ms de 500 millones de usuarios (las computadoras o sistemas finales) y ms de 160 pases conectados a Internet (cualquier pas con un mnimo de nivel tecnolgico). Ms en concreto, y con fecha de febrero de 2002, hay 544,2 millones de usuarios conectados a Internet en todo el mundo. En el contexto espaol el nmero de internautas o usuarios espaoles alcanza los 7,7 millones segn la ltima medicin del Estudio General de Medios (EGM).
- 33 -
>100.000 redes >75.000.000 servidores >160 pases >500.000.000 usuarios
Figura 2.4.- Nmeros en Internet.
2.2
Organizacin de centros para el acceso a Internet
Para lograr la coordinacin necesaria entre usuarios y proveedores del servicio de conexin, se dispone de una serie de procedimientos que son llevados a cabo por los centros responsables y que garantizan la correcta administracin y operacin de Internet. Estos centros han ido experimentando con el tiempo una progresiva descentralizacin y del clsico DDN (Defense Data Network)/Internet Network Information Center (InterNIC, http://www.internic.net) que operaban a nivel mundial se ha pasado a una estructura en donde intervienen nuevas y diversas organizaciones dentro de Internet que se encargan de realizar las tareas para las que tienen competencia. Dicha estructura se basa, en parte, en los siguientes centros: NIC (Network Information Center): Es una organizacin que lleva a cabo, fundamentalmente, las tareas administrativas centradas en el: Registro de nombres simblicos o de dominios de primer nivel bajo el nombre simblico del pas correspondiente. El NIC espaol (http://www.nic.es) ejerce esta funcin para el dominio es, gestionando de cara a Internet dicho dominio de primer nivel y registrando, dando de alta y delegando autoridad para los subdominios bajo es. Como se comentar posteriormente al hablar del DNS16, el administrador de cada nivel, que mantiene su parte correspondiente de la base de datos distribuida (DNS), es responsable del registro de los nombres de dominio dentro de su nivel, garantizando que stos sean nicos.
16
Domain Name System: Sistema de nombres de dominios en Internet.
- 34 -
En el escenario de los NIC o centros de informacin de red, se resalta que InterNIC se cre en abril de 1993 para llevar a cabo tareas de registro de direcciones de IP y nombres de dominio DNS que antes llevaba a cabo el ente DDN (Defense Data Network) de la DCA que gestionaba ARPANET. Ahora, todas estas tareas estn centralizadas en la raz o primer nivel dentro del ICANN (Internet Corporation Assigned Names and Numbers), organismo cuyas funciones se analizarn ms adelante. Durante muchos aos, el DoD mantuvo un importante papel de coordinacin en Internet. Su centro de informacin de la red DDN (DDN NIC) proporcionaba servicios a los usuarios, administradores de red, etc. En el verano de 1993, las funciones de apoyo a los usuarios civiles de Internet pasaron a la NSF (organismo subvencionado con dinero pblico) que financiaba, a su vez, dos agencias: Servicios de registro de InterNIC, por Network Solutions, Inc., Herndon, (Virginia). Servicios de directorio y base de datos de InterNIC, por AT&T.
Asimismo, se establecieron centros de registro adicionales en otros pases para coordinar los nombres y direcciones de las computadoras con TCP/IP. NOC (Network Operation Center): Es una organizacin con soporte de conexin a Internet y que lleva a cabo las tareas operativas de configuracin y gestin de mquinas y redes para dicho acceso; tareas que se describen a continuacin: Operacin de red: Diseo, configuracin de los equipos encaminadores, tareas operativas relacionadas con el servicio de DNS, etc. Gestin de la red: Informe de averas, monitorizacin en tiempo real del estado de la red, deteccin y correccin de problemas, gestin de configuracin de equipos, recogida de datos estadsticos, etc.
Por consiguiente, se puede considerar como NOC cualquier organizacin con un conjunto ms o menos numeroso de mquinas, y una red conectada a Internet indirectamente mediante un proveedor de servicios en Internet (ISP) o directamente (el NOC es el mismo ISP). Cada ISP dispone de su propio NOC. Por ejemplo, RedIRIS (http://www.rediris.es) es el NOC para el sector espaol de universidades y centros de investigacin. Es decir, RedIRIS es NOC e ISP, por ejemplo, para la Facultad de Informtica de la Universidad Politcnica de Madrid. A su vez, la Facultad de Informtica es slo un NOC que permite conectarse a Internet a sus alumnos, profesores y personal de administracin y servicios. Es importante resaltar que todo ISP es un NOC, pero no todo NOC es un ISP.
- 35 -
NCC (Network Coordination Center): Es una organizacin que lleva a cabo, de manera separada, las tareas de coordinacin a nivel continental de los NIC y NOC en cada uno de los correspondientes pases. Por ejemplo, en el contexto europeo lleva esta coordinacin, el centro de control de las redes IP europeas, RIPE NCC (http://www.ripe.net), ubicado en Amsterdam y que es el pertinente registro delegado de Internet en Europa. Resumiendo, uno de los objetivos en Internet es la descentralizacin de funciones para conseguir una mayor difusin de Internet en el planeta. Antes de que Internet traspasara las fronteras de los EE UU ya haba una serie de centros que coordinaban el funcionamiento de dicha red de redes. Para evitar que todo estuviera centralizado en un nico centro, ISOC se ha ido estructurando, con el tiempo, en diversas entidades, reduciendo muchas de las funciones que a nivel global llevaba a cabo InterNIC, una organizacin que contina llevando ciertas tareas administrativas y que ahora ha delegado en otras organizaciones dentro del contexto de Internet. Para ello, y tal como se ha sealado anteriormente, existe una serie de entidades (NIC) en cada pas (en Espaa http://www.nic.es) que controlan su registro DNS de nombres simblicos. Por encima, existen otras entidades que controlan y coordinan a los NIC como es el caso de RIPE NCC en Europa que, adems, aparte de otras funciones17 es un eslabn en la jerarqua de asignaciones de direcciones de IP en Europa. En un pas hay un NIC y tantos NOC como organizaciones existan con soporte de conexin a Internet, los cuales tienen que tener una entidad delegada de Internet por arriba (no centralizada en los EE UU) que marque ciertas polticas distribuidas como es el caso de la asignacin de direcciones de IP. En realidad es toda una jungla de centros cuyas funciones se van actualizando cada poco tiempo. Finalmente, los usuarios, organizaciones, proveedores (ISP) y NIC de cada pas son los ltimos eslabones en la jerarqua de Internet.
17
Coordina el DNS, gestiona la base de datos con redes IP, asigna nmeros de sistemas autnomos en Europa, etc.)
- 36 -
2.3
Jerarqua de centros de acceso a Internet

TRNSITO NACIONAL
...
INTERNET NSP (EE UU)
...
NSP (Espaa) NSP (Espaa)
ISP
...
...
... NAP ... ISP
...
ISP ... ISP ISP ... ISP ... NAP ISP ... ISP ISP
usuario
NSP (Network Service Provider): Centro de trnsito Internacional NAP (Network Access Point): Centro de trnsito nacional ISP (Internet Service Provider) o IAP (Internet Access Provider): Centro de Acceso Local
NAP ... ISP
Figura 2.5.- Jerarqua de centros de acceso a Internet. La Figura 2.5 muestra una jerarqua de centros, que se puede entender dentro de la semntica o del contexto de centros de operacin de red (NOC): NSP (Network Service Provider): Centro de trnsito internacional (tambin conocido como CIPSI o Centro Internacional Proveedor de Servicios IP), el cual juega un papel fundamental cuando las mquinas de origen y destino se encuentran en diferentes pases. Es el proveedor troncal o de backbone de red o centro que provee el acceso real al ncleo de Internet. En cada pas puede haber ms de un NSP que permite la conexin a Internet con otros pases. Por tanto, se consideran centros internacionales y componentes estructurales fundamentales de Internet. Un NSP puede ser NAP (concepto que se ve a continuacin) y proveedor o ISP de cara a un usuario final. Por ejemplo, en Espaa, algunos operadores globales de telecomunicaciones son NSP, tal es el caso de: Grupo Telefnica (Terra y TDATA o Telefnica Data), RedIRIS, BT Telecomunicaciones, etc. Por tanto, un operador global de telecomunicaciones o proveedor de trnsito puede ser NSP, NAP e ISP o NSP y NAP o slo NAP. En los dos ltimos casos, el usuario se conecta a un ISP y ste al operador que hace de NSP y NAP o slo de NAP. NAP (Network Access Point): Centro de trnsito nacional que juega un papel fundamental cuando las mquinas de origen y destino se encuentran en el mismo
- 37 -
pas. Conectan los ISP con otros a nivel nacional. Son tambin los centros de trnsito entre los ISP y NSP. Fundamentalmente, los NAP proporcionan interconexiones entre los ISP. El trfico se intercambia en los NAP pblicos para permitir que los clientes de un proveedor (ISP) alcancen a los clientes conectados a otro proveedor. Suelen ser uno de los puntos con ms congestin en Internet. Bsicamente, el procedimiento operativo consiste en lo siguiente: Un NAP mira la direccin de destino de la unidad de datos (datagrama IP18) recibida y consulta su tabla de encaminamiento para su pertinente envo. Si la mquina de destino se encuentra en el mismo pas que la mquina de origen, no es necesario atravesar ningn NSP, y el NAP encamina a otro NAP o incluso a un ISP. De esta forma, se evita que, por ejemplo, en el caso de Espaa, los internautas espaoles pasen por lneas extranjeras para conectarse a mquinas situadas fsicamente en Espaa y que dependen de otro operador de red (NAP). En este contexto, los NAP suelen conectarse entre s para formar los llamados puntos neutros de conexin entre dos o ms centros de igual jerarqua (NIX o Neutral Internet Exchange o punto neutro de intercambio de trfico en Internet dentro de un pas). Hay que tener en cuenta que antes gran parte de las conexiones entre usuarios espaoles pasaban por fuera del territorio espaol, hecho que provocaba considerables retrasos debido a sobrecargas en las lneas ISP (Internet Service Provider) o IAP (Internet Access Provider): Centro de Acceso Local, o lo que se entiende por un proveedor de servicios en Internet (acceso a Internet, servidor de pginas Web, correo, noticias, etc.) o, simplemente, un proveedor que proporciona slo el acceso a Internet tanto al usuario final directamente como a otros proveedores de servicios. Si un usuario es cliente de un proveedor, su conexin ser exclusivamente con dicho proveedor. La forma de conectarse el proveedor a uno o ms NAP, o a travs de conexiones directas, puede afectar la calidad de servicio.
2.4
El acceso a Internet
Para que un usuario desde su casa acceda a Internet, siempre es necesario disponer de un ISP. En este contexto, existe una gran cantidad de proveedores a nivel nacional (europeo o mundial) que pueden ofrecer diferentes modalidades de acceso y servicios de Internet a usuarios y organizaciones dentro de un pas. Por consiguiente, para que un usuario normal y corriente pueda acceder a Internet necesita disponer de una conexin a
Ya se estudiar que un datagrama IP es la unidad de datos manejada por el protocolo IP en el nivel de red de la arquitectura TCP/IP.
18
- 38 -
una mquina de entrada en Internet (la cual verifica el nombre de usuario y contrasea). Dicha mquina la proporciona un ISP a travs de un determinado esquema de tarifas. A su vez, el ISP necesitar un proveedor de trnsito u operador para poder conectar su router o dispositivo de encaminamiento a otro router en Internet. Obviamente, tambin el mismo operador puede ofrecer directamente el servicio ISP, como es el caso del Grupo Telefnica en Espaa mediante Terra (para usuarios individuales y empresas pequeas) y Telefnica Data (empresas de tipo medio y grandes).
INTERNET
Proveedor de Servicios en Internet (ISP)
Figura 2.6.- El acceso a Internet. Como se ha mencionado con anterioridad, en Internet no hay facturacin en funcin de la distancia a diferencia de otras redes comerciales. Tampoco se factura por el tiempo de acceso ni por el volumen de trfico; otra cosa es lo que se compre en Internet y lo que haga cada ISP (que dispone de su propia infraestructura de red y men de servicios) en funcin de su esquema de tarifas.
R.T.C.
Internet Proveedor (ISP)
TCP/IP
Usuario
Figura 2.7.- Tpico acceso bsico a Internet. En la Figura 2.7 se muestra la solucin ideal y ms barata para un usuario que de vez en cuando se conecta a Internet. Todo lo que necesita es una computadora, los
- 39 -
protocolos TCP/IP instalados en dicha mquina, una conexin telefnica, un mdem19 y, finalmente, el nmero telefnico de una mquina de entrada (ISP) a Internet. Previamente, el mdem se conecta a un puerto serie de la mquina del usuario y se configura indicando sus caractersticas o propiedades generales (tipo de mdem = estndar, puerto serie = COM 1 2, telfono del proveedor = xxxxxxx), propiedades de marcado (p. ej., cdigo de rea = 91, zona geogrfica = Espaa (34), marcacin = por tonos, ...). Por regla general, cuando uno se conecta a Internet (va ISP), hay que identificarse previamente como un cliente reconocido por el correspondiente ISP. Una vez efectuada la llamada, ste solicitar inicialmente el nombre de usuario y contrasea de su potencial cliente. Una vez verificada la anterior informacin, el ISP encaminar a dicho usuario por Internet en funcin, por ejemplo, de la pgina inicial que haya configurado el usuario en su navegador.
Figura 2.8.- Portales en Internet. Un portal en Internet, como su nombre indica, es una puerta de entrada a Internet, o lo que es lo mismo, una antesala que permite acceder a distintos servicios en Internet de forma ms cmoda. Por consiguiente, es el punto inicial donde se ofrece una serie de servicios comunes y habituales (enlaces clasificados por temticas, motor de bsqueda, etc.) que suelen ser necesarios cuando se comienza una sesin de navegacin. Cada vez, los portales son ms sofisticados y ofrecen ms servicios (cuentas de correo gratuitas,
19
Para transformar los ceros y unos procedentes de la computadora en sonido que pueda ser enviado por la Red Telefnica Conmutada y viceversa.
- 40 -
foros de discusin, chat, mantenimiento de pginas Web, etc.). El objetivo es que un internauta o usuario en Internet pueda encontrar todo lo que necesite, sin necesidad de navegar a lo loco, con el correspondiente ahorro de tiempo y dinero. Por regla general, los portales suelen ser ofrecidos por un ISP o un operador global de telecomunicaciones (Telefnica, Auna, BT, Airtel, Jazztel, Uni2, ). Asimismo, el objetivo de cualquiera de estas entidades es que el usuario se conecte inicialmente a su portal (a ser posible como direccin inicial de navegacin) cuando quiera acceder a Internet y, adems, sea un potencial cliente suyo contratando algn servicio especfico o algn acceso de ms calidad. Es curioso resaltar que en 1998, Espaa encabezaba la lista de los pases con ms empresas dedicadas a ofrecer a sus clientes acceso a Internet. La oferta superaba a la demanda: ms de 300 proveedores para 1,5 millones de internautas. Cuando los portales de las compaas telefnicas comenzaron a ofrecer el acceso gratuito, muchos ISP se vieron obligados a cerrar o a cambiar de actividad. Desde entonces, el sector vive un proceso de concentracin entorno a los grandes operadores. Actualmente, hay en Espaa menos de 50 proveedores con un volumen de negocio razonable. El mercado de Internet en Espaa concentra dos protagonistas: Terra del Grupo Telefnica y Wanadoo20 Espaa (de France Telecom) con con 1,8 millones y 1,5 millones de clientes respectivamente. Esto supone que ambas compaas controlan el 77% del mercado de acceso a Internet en nuestro pas. En la anterior Figura 2.8 se muestra, como ejemplo, el portal de Jazztel (http://www.ya.com/) que es operador de telecomunicaciones e ISP (Jazzfree) y que ofrece, aparte de otros servicios, un acceso gratuito a Internet.
RED DE TELEFNICA
Infraestructura alquilada
Internet Proveedor (ISP)
Usuario
Figura 2.9.- Acceso gratis a Internet.
20
Wanadoo es actualmente el segundo ISP en Europa.
- 41 -
En este escenario conviene resaltar que cuando se dice que una entidad ofrece un servicio de acceso gratuito a Internet a travs de una lnea convencional, en realidad, no es gratis la conexin; lo que se est pagando es la llamada local. Concretamente, por ejemplo, el coste de la llamada puede ser de 0,009 euros (1,64 pts)/minuto entre 18:00 y 8:00 h y 0,024 euros (4 pts)/minuto entre las 8:00 y 18:00 h. Conviene tener en cuenta que para que un ISP pueda ofrecer un acceso gratuito, es necesario que ese ISP posea una licencia de operador telefnico. Consecuentemente, ese ISP alquila, por ejemplo, a Telefnica parte de su infraestructura como una red privada virtual para poder entrar en el negocio de las llamadas (ver Figura 2.9). De esta forma, si un usuario cualquiera accede a travs de la red telefnica tradicional a la mquina de entrada21 del ISP; la tarifa local es la que Telefnica tenga establecida. Posteriormente, del tiempo total de conexin, Telefnica compensa al ISP en funcin de su esquema de tarifas, por ejemplo, los citados 0,009 euros (1,64 pts)/minuto entre 18:00 y 8:00 y 0,024 euros (4 pts)/minuto. Quiere decir esto, que el usuario no paga directamente al ISP sino a su operador telefnico. Evidentemente, para que un ISP proporcione conexiones gratuitas, es necesario disponer de un nmero suficientemente grande de potenciales clientes para que el servicio final sea de inters tanto para el ISP como para el operador telefnico. Como se indic anteriormente, esto ltimo fue la causa fundamental de que muchos ISP cerraran en Espaa. Por ltimo y para terminar con esta seccin dedicada al acceso a Intenet, slo indicar como referencia cultural22 que la urbe del mundo mejor conectada a Internet no es ninguna ciudad ms o menos importante de los EE UU sino la medieval ciudad espaola de Zamora, y los artfices de su transformacin recibieron en Washington un premio que la incluye en la historia de la red. En septiembre de 2002, Zamora se convirti en la primera ciudad del mundo donde no importa dnde se est, en un parque a orillas del Duero, en su puente de piedra del siglo XII o en la casa del Cid; siempre se podr estar conectado, sin necesidad de cables. Con ello, la tranquila ciudad que tuvo su gloria en la lejana Edad Media, ha entrado tambin en los anales de la historia de la ms moderna tecnologa, gracias a la tecnologa inalmbrica WiFi (IEEE 802.11). Hasta ahora slo existan hot spots lugares como aeropuertos y centros comerciales donde los abonados a un servicio de Internet podan acceder a la red de forma inalmbrica, ahora es toda una ciudad con 65.000 habitantes; pero cuyos numerosos edificios de piedra milenaria ofrecen dificultad, ya que obstaculizan la transmisin de las ondas de
21
Mismo login/password (p. ej., gratis/gratis) para todos los usuarios.
22
Tal y como se reflej el martes 3 de junio de 2003 en el diario EL MUNDO (http://www.elmundo.es/navegante/).
- 42 -
baja potencia que utiliza la red23. De aqu en adelante Zamora la bien cercada podr conocerse tambin como la bien conectada.
2.5 Organizacin de centros para el control y evolucin de Internet

(Internet Society)
ISOC
IAB
(Internet Advisory Board)
IANA
(Internet Assigned Numbers Authority)
IETF
(Internet Engineering Task Force)
IRTF
(Internet Research Task Force)
ICANN DNSO
(Internet Corporation Assigned Names and Numbers)
(Domain Name Supporting Organization)
PSO
IESG
(Internet Engineering Steering Group)
IRSG
(Internet Research Steering Group)
(Protocol Supporting Organization)
ASO
(Address Supporting Organization)
ARIN
RIPE NCC
AP NIC
Figura 2.10.- Organizacin de centros para el control y evolucin de Internet. Como ya se ha indicado, una de las caractersticas esenciales de Internet es su descentralizacin y que nadie gobierna esta inmensa red de computadoras, conservando cada red conectada su propia independencia. Sin embargo, para que semejante anarqua funcione24 es necesaria la existencia de una coordinacin que slo se preocupe de promover la red y de buscar respuestas a posibles problemas tcnicos. En este contexto, y segn se describe en la Figura 2.10, la Sociedad Internet o ISOC (Internet Society), promueve el conocimiento general de Internet y su tecnologa especificando las reglas de carcter tcnico. Consecuentemente, su principal objetivo es fomentar el crecimiento de Internet en todos sus aspectos (nmero de usuarios, nuevas aplicaciones, mejor infraestructura, etc.). Dentro de dicha sociedad est el gran
23
300 antenas de unos 10 cm de largo que permite a los 1.200 abonados navegar en la red informtica dondequieran que se encuentren. Otra aplicacin inmediata y lucrativa de la nueva tecnologa es su uso por telfonos mviles que permite a los abonados conversar todo lo que quieran por una tarifa plana mensual, que en Zamora es de 9,90 euros. Tal vez, la nica anarqua que funciona en el planeta.
24
- 43 -
consejo de patriarcas o IAB (Internet Advisory Board), que organiza y gestiona la Sociedad Internet. El IAB est formado por un grupo pequeo de investigadores (senior researchers), la mayora, diseadores y desarrolladores iniciales de la arquitectura TCP/IP. El IAB se encarga de determinar las necesidades tcnicas a corto, medio y largo plazo y de la toma de decisiones, guiando la evolucin del conjunto de protocolos TCP/IP. Tambin aprueba las recomendaciones y estndares de Internet, recogidos en una serie de documentos (los documentos RFC o Request For Comments). A su vez, del IAB dependen fundamentalmente dos organizaciones: IETF (Internet Engineering Task Force): Es el grupo de ingeniera de Internet que cuida los aspectos tcnicos a corto y medio plazo. El grupo de direccin del IETF es el IESG (Internet Engineering Steering Group). IRTF (Internet Research Task Force): Es el grupo de investigacin de Internet que estudia los aspectos tcnicos a largo plazo. El grupo de direccin del IRTF es el IRSG (Internet Research Steering Group). Asimismo, existe otro rgano de ISOC como es IANA (Internet Assigned Number Authority, http://www.iana.org), responsable de la definicin de polticas para la asignacin de los diversos recursos asignables de Internet, como es el caso de los nombres simblicos o de dominios, de las direcciones numricas o direcciones de Internet y de los valores o nmeros utilizados en el conjunto de protocolos TCP/IP. En este contexto, ICANN (http://www.icann.org), es una entidad delegada del IANA que lleva a cabo pragmticamente todo el trabajo definido en papel por IANA. Asimismo, del ICANN dependen tres organismos: DNSO: Encargado del registro de nombres simblicos o de dominios de primer nivel bajo la raz (IANA/ICANN) en el planeta. En definitiva, controla que no existan dos o ms pases compartiendo el mismo nombre simblico (el nombre simblico de Espaa es es, no debera haber otro pas con el mismo dominio). ASO: Responsable de la asignacin de direcciones numricas (4 octetos en formato X.X.X.X) por grandes bloques a tres registros regionales: AP NIC: Todos los pases de Asia y el Pacfico. RIPE NCC: Europa ARIN: Amrica y resto del mundo
En el caso europeo, ASO proporciona un bloque de direcciones a RIPE NCC que las distribuye a los operadores de telecomunicaciones o proveedores de trnsito de los diferentes pases europeos. En el caso de Espaa, Telefnica, Airtel, Auna, ..., que a su - 44 -
vez las distribuyen a los proveedores del servicio de acceso a Internet (ISP), y stos ltimos a sus clientes o usuarios. PSO: Encargado de la asignacin de los diferentes nmeros que identifican a los distintos protocolos y servicios en TCP/IP.
2.6
Las especificaciones en Internet: Documentos RFC
Segn se ha indicado anteriormente, existe una serie de especificaciones RFC (Request for Comments) o solicitudes de comentarios numeradas en secuencia, de forma cronolgica, que permite a los protocolos y servicios de la arquitectura TCP/IP ir evolucionando como estndares en Internet mediante un procedimiento documental aprobado por el IAB.
Solicitudes de Comentarios: Request For Comments (RFC) IAB (Internet Advisory Board) y el IAB Official Protocol Standards (RFC-3000): Estatus (status): Estndar (Standard) Borrador Estndar (Draft Standard) Propuesta Estndar (Proposed Standard) Experimental (Experimental) Informativo (Informational) Histrico (Historic) Mejor Prctica Actual (BCP o Best Current Practice) For Your Information (FYI)
Figura 2.11.- La literatura en Internet. Inicialmente, no hubo ningn procedimiento de estandarizacin oficial, las especificaciones RFC comenzaron en 1969 como parte del proyecto original de la red ARPANET de rea extensa. No hace mucho, el IAB comenz un proceso ms activo de centralizacin e informacin a travs de un RFC especfico (IAB Official Protocol Standards), el cual mantiene, mediante una actualizacin peridica, una lista completa en forma de resumen de todas las especificaciones RFC de servicios y protocolos de Internet, las cuales se clasifican por un estatus (status). El actual IAB Official Protocol Standards, es el documento RFC-3000. La revisin y publicacin de los documentos RFC es responsabilidad directa del Editor de RFC (RFC Editor) que es un miembro del IAB. Es importante resaltar que cualquier cambio o actualizacin en un RFC, implica un cambio en su nmero, con lo cual se debe obtener el nmero ms alto.
- 45 -
El IAB descansa en el IETF/IESG para la generacin de un nuevo estndar que inicialmente parte como un documento borrador (ID o Internet Draft). Generalmente, el proceso para que una especificacin se apruebe como estndar comienza por una recomendacin de un grupo de trabajo del IETF al IESG (rgano de direccin del IETF). Sin embargo, cualquiera puede enviar una memoria propuesta como ID al Editor RFC. Las normas para escribir un RFC se definen en el documento RFC-2223 (Instructions to RFC Authors). A su vez, el documento RFC-2026 (The Internet Standards Process -- Revision 3) especifica todos los conceptos y terminologa de los documentos RFC, as como el proceso de estandarizacin . El estatus de un RFC tiene que ver los niveles de madurez (maturity levels) de su contenido o con las diferentes fases que se han de seguir en su definicin. Los posibles estatus son: Estndar (Standard): Reconocido y normalizado. Slo cuando un protocolo alcanza el estatus de estndar se le asigna un nmero de estndar (STanDard number o STD). Por ejemplo, el protocolo IP cuyo nmero de RFC es el 791, tiene un estatus de estndar y un STD 5. El STD nunca cambia aunque en un futuro el nmero actual de RFC sea actualizado por otro. En este ltimo caso, el STD referencia al RFC original y a todos los documentos RFC estndares que actualizan al original (ojo!, el original no est obsoleto, sigue siendo estndar). Borrador estndar (Draft Standard): En fase de estandarizacin Propuesta estndar (Proposed Standard): Se considerar en un futuro, requiere implantaciones y pruebas. Experimental (Experimental): En fase de experimentacin, no debe ser implantado en el sistema salvo que se est participando en el experimento y haya coordinado su uso con el desarrollador del mismo. Informativo (Informational): Desarrollados por otros estandarizacin o vendedores fuera del alcance del IAB. organismos de
Histrico (Historic): Tiene poca probabilidad de transformarse en estndar de Internet, bien por estar obsoleto o por carecer de inters. Estndar (Standard), Borrador estndar (Draft Standard) y Propuesta estndar (Proposed Standard), se consideran parte del camino (The Internet Standards Track) que debe recorrer un RFC hasta que se convierte en estndar. Por consiguiente, Experimental (Experimental), Informativo (Informational) e Histrico (Historic) son distintos niveles de madurez fuera del mbito del Internet Standards Track.
- 46 -
A su vez, existen unas subseries de las series de RFC conocidas como Mejor Prctica Actual o BCP (Best Current Practice) con el objetivo de estandarizar prcticas o experiencias o trabajos o resultados25 de la toda la comunidad de Internet para llegar a una especie de consenso. Hay que tener en cuenta que Internet est compuesta por infinidad de redes gestionadas por organizaciones y administradores con diferentes polticas y formas de actuar. Asimismo, las series BCP se usan para documentar todas las prcticas que, a su vez, realice el mismo IETF. Resumiendo, los BCP son unos nmeros que identifican, a su vez, a los nmeros de RFC. Por ejemplo, el documento RFC-2026, BCP-0009 The Internet Standards Process - Revision 3 (status BEST CURRENT PRACTICE). Otro ejemplo es el documento RFC-1818, BCP-0001 Best Current Practice (status BEST CURRENT PRACTICE). Tambin hay un conjunto separado de documentos RFC que no contienen especificaciones de protocolos y servicios de Internet, sino informacin til y que se conoce como documentos Para Su Informacin (FYI o For Your Information). Disponen, como los STD, de su propio nmero pero slo est asociado a un RFC (a diferencia de los STD que pueden estar asociados a varios pertenecientes a la misma temtica). Por ejemplo, el documento RFC-1462, FYI-20 FYI on What is the Internet? (status informational). Hay un gran nmero de mquinas servidoras por Internet en donde se pueden consultar de forma gratuita los documentos RFC debidamente actualizados; por ejemplo, una direccin puede ser la de RedIRIS, que como ya se indic, es un organismo dependiente del CSIC (Consejo Superior de Investigaciones Cientficas) que controla y coordina la red acadmica y de investigacin y desarrollo en Espaa, y cuya direccin especfica para los documentos RFC es http://ftp.rediris.es/ftp/docs/rfc/. Asimismo, en la direccin http://www.rfc-editor.org/rfcxx00.html se pueden encontrar todos los documentos RFC no obsoletos y debidamente clasificados. Finalmente, una direccin muy interesante y recomendable es http://www.rfceditor.org/rfcsearch.html, que dispone de un motor de bsqueda de los documentos RFC. Este motor permite encontrar documentos, muy fcilmente, por el nmero o ttulo o palabra reservada y comprobar su nmero RFC o STD o BCP o FYI, autor, fecha, los documentos RFC que quedan obsoletos por el actual, etc.
25
Por ejemplo, llevados a cabo por una organizacin y que puede servir como experiencia a otras.
- 47 -
2.7 Sistema de nombres de dominio

IANA/ICANN
RAIZ
edu
mil
....
upm
es
uk
...
rediris
zape.fi.upm.es
zape
fi
chico
...
asterix
...
Figura 2.12.- Sistema de nombres de dominio: Identificacin simblica. Este servicio est encuadrado dentro del Sistema de Nombres de Dominio o DNS (Dominio Name System) de Internet. Bsicamente, el sistema DNS consiste en una jerarqua de nombres simblicos o de dominios nemotcnicos de mquinas repartida en un sistema de computacin o base de datos distribuida mediante servidores de nombres por toda la red Internet. Esta base de datos distribuida se consulta por las aplicaciones de usuario para llevar a cabo la traduccin entre los nombres simblicos y las correspondientes direcciones numricas. El procedimiento de actuacin descansa en unas mquinas especficas denominadas servidores de nombres (name servers). Generalmente, cada organizacin dispone de su propio servidor DNS que hace la traduccin de una direccin simblica de dicha organizacin en su correspondiente direccin numrica que, por otro lado, es la direccin con la que trabajan finalmente las mquinas. Ningn servidor de nombres contiene la base de datos completa, lo que hacen es comunicarse entre ellos va TCP/IP cuando alguno necesite la pertinente direccin numrica. En este escenario, un servidor DNS se convierte en cliente DNS de otro servidor DNS contiguo en la jerarqua DNS establecida. Los ISP facilitan servidores DNS para que un usuario pueda escribir la direccin destinataria en formato simblico. Esta distribucin jerrquica permite crear diferentes niveles o dominios de gestin o de responsabilidad para garantizar la unicidad de nombres. En el nivel superior se encuentran los dominios asociados a los distintos pases salvo la mayora de los dominios (bsicos y genricos de mximo nivel) de EE UU cuyo esquema de direcciones se diseo antes de que Internet traspasara las fronteras de dicho pas, tal es el caso entre otros de los seis siguientes:
- 48 -
edu: Instituciones educacionales o docentes mil: Instituciones militares gov: Instituciones gubernamentales org: Organizaciones no lucrativas com: Instituciones comerciales net: Centros de red y apoyo en Internet Con respecto a los dominios, ha habido unas cuantas ampliaciones como es el caso de (firm, shop, web, arts, rec, info, nom, ...) que son nombres de dominios nemotcnicos, bsicos y genricos, de mximo nivel (generic Top Level Domains) definidos por el IAHC (Internet Ad-Hoc Comittee) que se pueden ver en la direccin http://www.iahc.org del International Ad Hoc Committee (IAHC). El IAHC es un grupo de trabajo creado por las asociaciones Internet Architecture Board (IAB), Internet Assigned Numbers Authority (IANA), International Telecommunication Union (ITU), International Trademark Association (INTA), World Intellectual Property Organization (WIPO) e Internet Society (ISOC), cuya responsabilidad es mantener las normas administrativas de los servicios en Internet, incluyendo los dominios de nivel superior (com, org, etc.) as como su delegacin y mantenimiento, a travs de las correspondientes agencias o entidades delegadas. El nmero y el nivel de las asociaciones participantes en el proyecto dan una idea de la importancia de su cometido. Actualmente, los gLTD se definen, controlan y coordinan por el NTIA (National Telecommunications and Information Administration: agencia del Departamento de Comercio de EE UU, http://www.ntia.doc.gov/) y el ICANN (http://www.gtld-mou.org/) En Espaa aparte del NIC (http://www.nic.es), hay una empresa catalana llamada Nominalia (http://www.nominalia.com) que es un registro o entidad delegada del ICANN (DNSO) que inscribe, ante el NIC, bajo .es y, adems, permite enganchar una direccin bajo otros dominios como .com, .net, .org,, etc. A su vez, Nominalia debe coordinarse con otros registros delegados homlogos para evitar la repeticin de nombres simblicos bajo el correspondiente dominio nemotcnico, bsico y genrico de primer nivel. En funcin de lo anterior, una mquina puede colgar directamente de un dominio bsico y genrico de mximo nivel (p. ej., .com) y estar fsicamente en Espaa. En todo caso, el acceso a dicha mquina se realizar mediante un encaminamiento a travs de los routers correspondientes, los cuales deben estar debidamente configurados en - 49 -
funcin de la direccin numrica de la mquina en cuestin. Quiere decir esto, que es muy importante diferenciar entre direcciones simblicas (muy tiles para su memorizacin y uso) y las direcciones numricas que son las que utiliza el protocolo IP para el pertinente encaminamiento por Internet. Por debajo del nivel superior, tanto de los dominios bsicos Internet como de los dominios asociados a los diferentes pases, se encuentran los dominios correspondientes a las distintas organizaciones conectadas a Internet dentro de cada pas. El administrador de cada dominio, que mantiene su parte correspondiente de la base de datos distribuida, es responsable del registro de nombres de dominio dentro de su nivel, garantizando que stos sean nicos. Las direcciones por dominios de nombres en Internet no se corresponden con los nombres de nodo, o con mquinas fsicas por las que deba pasar el mensaje, sino que se basan en una jerarqua de dominios nemotcnicos que se corresponde con las entidades relacionadas con la situacin geogrfica-administrativa de la mquina destinataria (como por ejemplo, departamento, universidad, pas). De forma general, se puede designar una mquina (direccin_mquina) mediante la cadena: mquinadominio(n)dominio(n-1) ... dominio(1)dominio Los dominios se ordenan de derecha a izquierda, del ms general al ms particular, separando cada nombre simblico del anterior mediante un punto. Mientras que en mquina se pone la direccin simblica de la computadora en cuestin. Como se observa, la principal caracterstica de los dominios es que son nemotcnicos, identificando la situacin del destinatario y fcilmente recordables. Con este esquema se impide que dos o ms mquinas en Internet compartan la misma direccin simblica. Generalmente, y como se muestra en la anterior Figura 2.12, toda mquina conectada a la red de una organizacin en Internet tiene una direccin simblica (p. ej., zape.fi.upm.es) y una direccin numrica de cuatro octetos asociada (p. ej., 138.100.8.1). Se resalta que la computadora de un usuario que de vez en cuando se conecta desde casa a Internet, tiene slo una direccin numrica temporal que le ofrece su ISP en funcin de las direcciones numricas libres que disponga dicho proveedor en ese momento.
- 50 -
2.8
Direcciones numricas
DIRECCIN DE RED
DIRECCIN DE MQUINA
Notacin decimal con puntos: 4 octetos separados por puntos (p.ej., 138.100.12.16)
Figura 2.13.- Formato de las direcciones numricas. El formato de una direccin de Internet o numrica o IP manejada por el protocolo IP en su versin 4 (que ya se estudiar ms adelante) en el nivel Internet o de red de la arquitectura TCP/IP, representa un modelo jerrquico de direccionamiento en dos niveles: redes y mquinas. Consecuentemente, engloba dos tipos de informacin: la de la mquina y red a la cual dicha mquina est conectada. Por consiguiente, cada mquina en una red tiene una direccin lgica o simblica que es diferente de su direccin fsica e identifica a dicha mquina dentro de la red o nube fsica a la que est unido; existiendo una direccin de Internet diferente para cada equipo. Se recuerda, que, generalmente, una mquina en casa (conectada va mdem con Internet) tiene la direccin numrica temporal que le ha concedido su ISP. Mientras que una mquina conectada directamente a la red de rea local de la organizacin, dispone de forma fija de una direccin simblica y otra numrica asignada por dicha organizacin. Las direcciones se dan bajo la forma de cuatro octetos (32 bits) y cada octeto es un nmero entero decimal separado del anterior por un punto, de la forma siguiente: octeto-1octeto-2octeto-3octeto-4, Por ejemplo, 138.100.12.16 puede ser la direccin de una mquina en Internet o en una red privada TCP/IP. Antes de seguir con las direcciones numricas, conviene indicar que existen tres tipos de transmisiones en Internet: Unidifusin26 (Unicast): Se basa en un proceso de envo de una o ms unidades de datos (datagramas IP) desde un origen a un nico destinatario o receptor
26
O unidistribucin o punto a punto.
- 51 -
final. Por tanto, es una transmisin punto a punto con cada destinatario. Si se desea enviar la misma27 informacin y hay n destinatarios, habr n comunicaciones punto a punto independientes o n copias de la misma informacin enviadas desde el origen.
M2 M3
R2
R1
M1
ORIGEN
M4
R3
R5
M5
R4
2 datagramas IP de unidifusin
M6
Flujo de unidifusin
Figura 2.14.- Un ejemplo de unidifusin IP. En el ejemplo de la Figura 2.14, se desean realizar dos transmisiones de unidifusin basadas en el envo de una misma unidad de datos (datagrama IP) desde M1 a M2 y M4. Por consiguiente, hay que enviar una copia de la misma informacin desde M1 a M2 y otra ms desde M1 a M4; todo ello, a travs de los pertinentes routers R1-R2 y R1-R3-R5. Los dos datagramas IP son diferentes en su cabecera de control28 aunque con el mismo contenido en el campo de datos. Cada enlace entre mquinas suele ser una lnea punto a punto o una red de rea local. Multidifusin29 (Multicast): Se basa en un nico proceso de envo de una o ms unidades de datos (datagramas IP) desde un origen a todos los miembros de un
27
Obviamente, si la informacin es distinta y hay n destinatarios, tambin habr n comunicaciones independientes punto a punto; pero sin copias. Por ejemplo, en el campo de destino se registran direcciones numricas distintas.
28
29
O multidistribucin o multipunto. Este concepto fue una idea original de Steve Deering que describi en su tesis doctoral en la Universidad de Stanford y que ms tarde continu desarrollando en el Centro de Investigacin de Xerox en Palo Alto (Xerox PARC). Otros investigadores se interesaron por este estudio para su implantacin experimental en Internet. El resultado fue la publicacin del documento RFC 1112
- 52 -
grupo de potenciales destinatarios que comparten una misma direccin de multidifusin y, posiblemente, dispersos geogrficamente en mltiples redes por Internet. En este escenario, los routers intermedios de multidifusin tienen que poseer la capacidad necesaria para hacer las copias necesarias, de la informacin transmitida, desde el origen a las correspondientes mquinas destinatarias.
M2 M3
G1
1 datagrama IP de multidifusin
R2
G2
R1
M1
ORIGEN
M4
R3
R5
M5
G1
R4
G2
M6
Flujo de multidifusin
G3
Figura 2.15.- Un ejemplo de multidifusin IP. En el ejemplo de la Figura 2.15, se desea realizar una transmisin de multidifusin basada en el envo de una nica unidad de datos (datagrama IP) desde M1 a todas las mquinas (M2 y M4) que forman el grupo de multidifusin G1. En este tipo de transmisiones slo se envan los datagramas originales sin copias. Consecuentemente, en el ejemplo slo se transmite el datagrama IP original sin copias desde M1 al grupo G1. Cada enlace entre mquinas suele ser una lnea punto a punto o una red de rea local. Como ya se estudiar, R2 no transmite una copia a R5 porque tiene constancia de que existe otro envo de la misma informacin por otro camino (R1-R3-R5). Difusin30 (Broadcast): Se basa en un nico proceso de envo de una o ms unidades de datos (datagramas IP) desde un origen a todas las mquinas de una red de rea local. Todo ello, sin necesidad de transmitir desde el origen una copia de la misma informacin, por separado, a cada una de dichas mquinas. El
en el que se definen los requisitos necesarios que debe cumplir un equipo para soportar IP de multidifusin.
30
O distribucin.
- 53 -
problema de este tipo de difusin es que aparte de aumentar el trfico por la red, la informacin transmitida llegar posiblemente a ciertas mquinas que no tienen el ms mnimo inters por la informacin en cuestin. Este tipo de transmisin es muy frecuente en enlaces basados en redes de rea local del tipo Ethernet31 (IEEE 802.3).
M4
1 datagrama IP de difusin
M1
ORIGEN
M2
M5
M3
M6
Flujo de difusin
Figura 2.16.- Un ejemplo de difusin IP. En el ejemplo de la Figura 2.16, se desea realizar una transmisin a todas las mquinas (M1, M2, M3, M4, M5 y M6) del escenario planteado. Al igual que con la multidifusin, pero de una forma menos selectiva, slo se enva un datagrama IP desde M1 al resto de mquinas al grupo G1. En funcin de estas tres clases de transmisiones y como se estudiar seguidamente, en funcin del nmero de bits utilizados para identificar redes y mquinas, las direcciones numricas se clasifican en cinco clases de direcciones: A, B, C, D y E.
31
Por otro lado, la red de comunicaciones o red fsica ms extendida por Internet y en la cual todas las mquinas se conectan a un mismo cable.
- 54 -
5 clases de direcciones Internet o numricas o IP:

CLASE A: Unidifusin y difusin CLASE B: Unidifusin y difusin CLASE C: Unidifusin y difusin CLASE D: Multidifusin CLASE E: Reservada para un formato futuro
Figura 2.17.- Clases de direcciones numricas.
CLASE A
0 1 7 8 31
0 CLASE B
DIRECCIN DE RED
DIRECCIN DE LA COMPUTADORA
27-2
15 16 DIRECCIN DE RED
224 - 2
31 DIRECCIN DE LA COMPUTADORA
01 2
10 CLASE C 110
214
012 3 DIRECCIN DE RED
216 - 2
23 24 31 DIRECCIN DE LA COMPUTADORA
221
28 - 2
Figura 2.18.- Formato de las direcciones numricas: Clases A, B y C. Segn se indica en la anterior Figura 2.17, las clases A, B y C son las clases de direcciones numricas empleadas para las transmisiones de unidifusin y difusin. Asimismo, las direcciones numricas de la clase D se utilizan para las transmisiones de multidifusin. Clase A: Permite definir 27- 2 = 126 redes diferentes (los nmeros 0 y 127 estn reservados) y 224- 2 = 16.777.214 computadoras en cada una (los nmeros 0 y 16.777.215 estn reservados). Se utiliza para redes grandes capaces de conectar un gran nmero de mquinas. Clase B: Permite identificar 214 = 16.384 redes y 216- 2 = 65.534 computadoras en cada una (los nmeros 0 y 65.535 estn reservados). Se utiliza para redes de tipo medio. Clase C: Permite definir 221 = 2.097.152 redes y 28- 2 = 254 computadoras en cada una (los nmeros 0 y 255 estn reservados). Se utiliza para redes pequeas, las cuales conectan un nmero reducido de mquinas. - 55 -
2.8.1 Direcciones numricas de la clase A

0 1 78 31 DIRECCIN DIRECCIN DE LA MQUINA 0 DE RED
Identificador de clase
CLASE A = red.mquina.mquina.mquina
0 1 7 8 15 16 23 24 31
RED
MQUINA MQUINA MQUINA

224 2 = 16.777.214 mquinas
00000000 00000000 00000000 = 0.0.0 (RESERVADA) 00000000 00000000 00000001 = 0.0.1 00000000 00000000 00000010 = 0.0.2
27-2 = 126 redes

0 0 0 0 0 0 0 0 = 0 (RESERVADA) 0 0 0 0 0 0 0 1 = 1 (1.mquina.mquina.mquina) 0 0 0 0 0 0 1 0 = 2 (2.mquina.mquina.mquina)
....................................... .......................................
0 1 1 1 1 1 1 0 = 126 (126.mquina.mquina.mquina) 0 1 1 1 1 1 1 1 = 127 (RESERVADA)
............................................ ............................................
11111111 11111111 11111110 = 255.255.254 11111111 11111111 11111111 = 255.255.255 (RESERVADA)
Rango terico de direcciones de red: 0.0.0.0 a 127.0.0.0/Rango prctico de direcciones de red: 1.0.0.0 a 126.0.0.0 Rango terico completo de direcciones clase A: 0.0.0.0 a 127.255.255.255 Rango prctico completo de direcciones clase A: 1.0.0.0 a 126.255.255.254
Figura 2.19.- Formato de las direcciones de la clase A. En los 7 bits de la direccin de red de la clase A (ver Figura 2.19) no puede aparecer dos combinaciones, ni todo a ceros (0 en decimal), ni todo a unos (127 en decimal) porque son dos direcciones de red reservadas. A su vez, en los 24 bits de la direccin de mquina no puede aparecer dos combinaciones, ni todo a ceros (0.0.0 en decimal), ni todo a unos (255.255.255 en decimal) porque son dos direcciones de mquinas reservadas. El rango completo de direcciones es: 0.0.0.0---127.255.255.255.
2.8.2 Direcciones numricas de la clase B

En los 16 bits de la direccin de mquina de la clase B (ver siguiente Figura 2.20) no puede aparecer dos combinaciones, ni todo a ceros (0.0 en decimal), ni todo a unos (255.255 en decimal) porque son dos direcciones de mquinas reservadas. El rango completo de direcciones es: 128.0.0.0---191.255.255.255.
- 56 -
0 12
15 16
31
10
Identificador de clase 0 1 2
DIRECCIN DE RED
7 8 15 16
DIRECCIN DE LA MQUINA
23 24 31
CLASE B = red.red.mquina.mquina
10
RED
RED
MQUINA MQUINA
216 2 = 65.534 mquinas
00000000 00000000 = 0.0 (RESERVADA) 00000000 00000001 = 0.1 00000000 00000010 = 0.2
214 = 16.384 redes

10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 128.0 (128. 0. mquina.mquina) 10 0 0 0 0 0 1 0 0 0 0 0 0 0 0 = 129.0 (129.0.mquina.mquina) 10 0 0 0 0 1 0 0 0 0 0 0 0 0 0 = 130.0 (130. 0. mquina.mquina)
................................................... ...................................................
10 1 1 1 1 1 1 0 0 0 0 0 0 0 0 = 191.0 (191.0.mquina.mquina) .......................................................... 10 1 1 1 1 1 1 1 1 1 1 1 1 1 1 = 191.255 (191.255.mquina.mquina)
............................................ ............................................
11111111 11111110 = 255.254 11111111 11111111 = 255.255 (RESERVADA)
Rango de direcciones de red: 128.0.0.0 a 191.255.0.0 Rango terico completo de direcciones clase B: 128.0.0.0 a 191.255.255.255 Rango prctico completo de direcciones clase B: 128.0.0.0 a 191.255.255.254
Figura 2.20.- Formato de las direcciones de la clase B.
2.8.3 Direcciones numricas de la clase C

Finalmente, en los 8 bits de la direccin de mquina de la clase C (ver siguiente Figura 2.21) no puede aparecer dos combinaciones, ni todo a ceros (0 en decimal), ni todo a unos (255 en decimal) porque son dos direcciones de mquinas reservadas. El rango completo de direcciones es: 192.0.0.0---223.255.255.255.
- 57 -
0 1 2 3
110
Identificador de clase 0 1 2 3
DIRECCIN DE RED
7 8
23 24 31 DIRECCIN DE LA MQUINA
15 16 23 24 31
CLASE C = red.red.red.mquina
RED
RED
RED
110
MQUINA
28 2 = 254 mquinas
00000000 = 0 (RESERVADA) 00000001 = 1 00000010 = 2
221 = 2.097.152 redes

110 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 192.0.0 (192.0.0.mquina) 110 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 193.0.0 (193.0.0.mquina) 110 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 194.0.0 (194.0.0.mquina)
................................................... ...................................................
110 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 223.0.0 (191.0.0.mquina) .......................................................... 110 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 = 223.255.255 (223.255.255.mquina)
Rango de direcciones de red: 192.0.0.0 a 223.255.255.0 Rango terico completo de direcciones clase C: 192.0.0.0 a 223.255.255.255 Rango prctico completo de direcciones clase C: 192.0.0.0 a 223.255.255.254
........... ...........
11111110 = 254 11111111 = 255 (RESERVADA)
Figura 2.21.- Formato de las direcciones de la clase C.
2.8.4 Direcciones numricas de la clase D
0123 4
31 DIRECCIN DEL GRUPO DE MULTIDIFUSIN
1110
Figura 2.22.- Formato de las direcciones de la clase D. Como ya se ha sealado, este tipo de direccin numrica se utiliza en comunicaciones en grupo o de multidifusin (o multicast) con el objetivo de enviar una misma informacin a todos los miembros del grupo (posiblemente, dispersos geogrficamente en mltiples redes por Internet). Todos los miembros del grupo en cuestin comparten una misma direccin de la clase D. Tambin como ya se ha indicado, los routers intermedios de multidifusin tienen que poseer la capacidad de hacer las copias necesarias de la informacin transmitida desde el origen a las correspondientes mquinas destinatarias. Por consiguiente, se utiliza para la transmisin de informacin32 cuando el nmero de receptores es superior a uno y no se desea enviar desde el origen
32
Aplicaciones multimedia en tiempo real, por ejemplo: audioconferencias y videoconferencias.
- 58 -
una misma informacin por separado a cada miembro del grupo. Los primeros 4 bits de una direccin de multidifusin contienen 1110 e identifican la direccin como una multidifusin. Los 28 bits restantes especifican un grupo de multidifusin en particular sin contener una direccin de red como en las direcciones de la clase A, B y C. El rango completo de direcciones de multidifusin es: 224.0.0.0---239.255.255.255. Sin embargo, la direccin 224.0.0.0 est reservada, es decir, no se puede asignar a ningn grupo. El bloque de direcciones 224.0.0.1---224.0.0.255 se reserva para los protocolos de actualizacin y distribucin de la informacin de encaminamiento, descubrimiento de topologas a bajo nivel, as como para protocolos de mantenimiento. Tal es el caso de las siguientes: 224.0.0.1.- Asignada permanentemente a todas las mquinas en esta red de rea local. 224.0.0.2.- Asignada permanentemente a todos los routers de multidifusin en esta red de rea local. 224.0.0.4.- Asignada permanentemente a todos los routers del protocolo DVMRP. 224.0.0.5.- Asignada permanentemente a todos los routers del protocolo OSPF. 224.0.0.6.- Asignada permanentemente a todos los routers designados del protocolo OSPF. 224.0.0.9.- Asignada permanentemente a todos los routers del protocolo RIPv2. A su vez, el resto de direcciones, 224.0.1.0---239.255.255.255, se asigna a las diferentes aplicaciones de multidifusin en Internet. Por ejemplo: 224.0.1.1.- Asignada permanentemente al protocolo NTP (Network Time Protocol). 224.0.1.11.- Asignada permanentemente para audio IETF-1. 224.0.1.12.- Asignada permanentemente para vdeo IETF-1. 224.0.1.7.- Asignada permanentemente para noticias de audio (audionews).
- 59 -
224.0.1.6.- Asignada permanentemente para un servicio de msica (musicservice). Del ltimo rango indicado anteriormente (224.0.1.0---239.255.255.255), concretamente, el bloque de direcciones del 239.0.0.0 al 239.255.255.255, se reserva para aplicaciones locales en entornos de redes privadas. El resto de direcciones se asignan y desasignan dinmicamente. Conviene resaltar que las direcciones de multidifusin slo pueden emplearse como direcciones de IP de destino. stas nunca aparecen en el campo de direccin de IP del origen de un datagrama33.
2.8.5 Direcciones numricas de la clase E
01234 5
31 USO FUTURO
11110
Figura 2.23.- Formato de las direcciones de la clase E. Reservadas para un uso futuro o experimental. El rango completo de direcciones es: 240.0.0.0---247.255.255.255.
2.8.6 Direcciones numricas reservadas

0.0.0.0 (ruta por omisin o red desconocida) y 127.0.0.0 (direccin de la red de bucle o loopback) son dos direcciones de red reservadas.
Slo afectan a las direcciones clase A
Todo a ceros (direccin de red) y todo a unos (difusin dirigida) son dos direcciones de computadora reservadas.
Afectan a las direcciones clase A, B y C
Figura 2.24.- Direcciones numricas reservadas.
33
Ya se estudiar que un datagrama es la unidad de datos manejada por el protocolo IP en el nivel de red de la arquitectura TCP/IP.
- 60 -
Tal y como se refleja en la anterior Figura 2.24, las direcciones 0.0.0.0 (ruta por omisin) y 127.0.0.0 (direccin de la red de bucle) son las dos direcciones de red prohibidas para identificar redes fsicas de la clase A. Mientras que todos ceros y todos unos son las dos direcciones de mquina reservadas para identificar mquinas en direcciones clase A, B y C. As, la direccin 0.0.0.0 no se puede utilizar para identificar a una direccin de la clase A, es decir, en el primer octeto no puede aparecer 8 bits a cero para evitar que aparezcan seguidamente 24 bits a cero. Consecuentemente, 0.0.0.0 y 127.0.0.0 no se pueden usar para identificar a una red clase A. Asimismo, X.0.0.0 (clase A), X.X.0.0 (clase B), X.X.X.0 (clase C), X.255.255.255 (clase A), X.X.255.255 (clase B) y X.X.X.255 (clase C) no se pueden usar para identificar a una mquina clase A, B y C. X denota cualquier combinacin vlida de direccin de red de la clase A, B y C. Dicho de otra manera, X.0.0.0, X.X.0.0 y X.X.X.0 identifican a una red de la clase A, B y C respectivamente. Por consiguiente, no se pueden usar las anteriores tres direcciones para identificar a una mquina en una de esas redes. Asimismo, X.255.255.255, X.X.255.255 y X.X.X.255 son direcciones especiales de difusiones dirigidas34 a redes clase A, B y C. Es importante resaltar que las redes, al igual que las mquinas, tambin tienen direcciones numricas, las cuales tienen el ltimo o ltimos octetos a cero en funcin de la clase de la direccin de la red y (como ya se analizar) si se han usado todos los bits de esos octetos para identificar mquinas.
Clase Rango terico de direcciones Rango prctico de direcciones A B C 0.0.0.0 a 127.255.255.255 128.0.0.0 a 191.255.255.255 192.0.0.0 a 223.255.255.255 1.0.0.0 a 126.255.255.254 128.0.0.0 a 191.255.255.254 192.0.0.0 a 223.255.255.254
Funcin Unidifusin y difusin Unidifusin y difusin Unidifusin y difusin
Figura 2.25.- Rangos de direcciones numricas: Clases A, B y C.
34
Ya se explicar el concepto de difusin dirigida ms adelante.
- 61 -
La anterior Figura 2.25 muestra el rango terico y prctico de direcciones para redes y mquinas, es decir, en el caso prctico se denotan todas las posibles direcciones incluyendo direcciones de red y mquina.
A = red.computadora.computadora.computadora B = red.red.computadora.computadora C = red.red.red.computadora

N mximo de N mximo de redes computadores
Clase A Clase B Clase C
0 < red < 127

128 red < 192 192 red < 224
27-2 = 126
214 = 16.384 221 = 2.097.152
224-2 = 16.777.214 216 - 2 = 65534

(todos los 0s y 1s reservado)
(todos los 0s y 127 reservado) (todos los 0s y 1s reservado)
28 - 2= 254
(todos los 0s y 1s reservado)
Figura 2.26.- Notaciones decimales del primer octeto para las clases A, B y C. La Figura 2.26 muestra el formato de las direcciones numricas de las clases A, B y C. Asimismo, se especifican las notaciones decimales del primer octeto que indican las clases de dichas direcciones. Por ejemplo, 1.0.0.0, , 15.0.0.0, 55.0.0.0, ... 126.0.0.0 son direcciones de red de la clase A. 128.X.0.0, ..., 191.X.0.0 (p.ej., 128.12.0.0 191.84.0.0) son direcciones de red de la clase B. Finalmente, 192.X.X.0, ... 223.X.X.0 (p.ej., 192.33.78.0 223.134.89.0) son direcciones de red de la clase C.
- 62 -
2.8.7 Direcciones especiales

Solicitudes y respuestas del protocolo BOOTP:
Direccin IP CLIENTE a 0s (todos los bits a cero) = Esta mquina en esta red?
Mi direccin de mquina en esta red?: 0.0.0.0

Direccin IP SERVIDOR a 1s (todos los bits a uno) = La direccin de la computadora en esta direccin de red
RESPUESTA: La direccin del computadora en esta red: X.X.X.23 Difusin dirigida (Directed Broadcast): Direccin IP destino (computadora) a 1s
128.2.255.255 (mensaje a todas las mquinas y subredes conectadas a la subred 128.2.0.0)
Difusin limitada (Limited Broadcast): Direccin IP destino (red-computadora) a 1s

255.255.255.255 (mensaje a todas las mquinas en la misma red de la mquina origen de la difusin)
Direccin de bucle (Loopback address): Primer octeto = 127.x.x.x (x.x.x = cualquier valor salvo todo ceros o unos)
telnet 127.0.0.1 (comprobacin del acceso al servidor telnet que se ejecuta en la misma mquina) ftp 127.0.0.1 (comprobacin del acceso al servidor ftp que se ejecuta en la misma mquina)
Figura 2.27.- Direcciones especiales. La Figura 2.27 analiza las direcciones especiales empleadas en las direcciones numricas. Las dos primeras direcciones de la citada figura son las direcciones que utiliza el protocolo BOOTP (BOOTstrap) del nivel de aplicacin de la arquitectura TCP/IP que utilizan, o bien aquellas mquinas que se conectan por primera vez a una red, o bien aquellas mquinas sin disco duro que deben obtener inicialmente una serie de informaciones (direccin de Internet de la mquina, direccin del fichero de arranque, etc.) para poder estar operativa. Por ejemplo, cuando una mquina sin disco duro (cliente BOOTP) pregunta por su direccin a una mquina especfica (servidor BOOTP), pone todo a ceros en el campo de direccin de IP del cliente35 del correspondiente mensaje. A su vez, la mquina servidora BOOTP responde (direccin de IP del cliente a ceros y direccin de IP del servidor a unos) con un mensaje indicando, entre otras informaciones (mscara36, direccin del fichero de arranque, etc.), la direccin especfica de esa mquina (p.ej., X.X.X.23) en una red determinada (en el ejemplo, en una red de la clase C). El protocolo BOOTP utilizado para el arranque automtico de mquinas sin disco duro en un entorno TCP/IP se estudiar ms adelante.
35
La direccin IP del servidor la pone a unos, si no conoce previamente esta direccin. Este concepto se analizar ms adelante.
36
- 63 -
Otra direccin especial es la DIFUSIN DIRIGIDA que permite enviar un mismo mensaje de difusin progresivamente a todas las mquinas y subredes37 conectadas a una determinada subred de la mquina de origen de la difusin. Adems de la difusin dirigida, est la DIFUSIN RESTRINGIDA O LIMITADA, que a diferencia de la anterior difusin, el mensaje va nicamente a todas las mquinas conectadas directamente a la misma red de la mquina de origen de la difusin. Por consiguiente, las difusiones limitadas son siempre locales o directas y las difusiones dirigidas pueden ser locales (directas) o remotas. Finalmente, otra direccin especial es la DIRECCIN DE BUCLE empleada para autochequeos, pruebas y comprobaciones de software. Asimismo, tambin se emplea para el desarrollo de aplicaciones cliente-servidor sin necesidad de una red fsica que conecte al proceso cliente con el proceso servidor de la pertinente aplicacin. La red de bucle (127.0.0.0) es una red que no existe fsicamente, se asume que est dentro de la mquina en donde se est desarrollando tanto la parte cliente como la parte servidora de una determinada aplicacin. El proceso cliente tendr una direccin en esa nube ficticia (p.ej., 127.x.x.x) y el proceso servidor tendr la misma u otra direccin en esa red (p.ej., 127.y.y.y). De esta forma, se prueba la interaccin entre los dos procesos sin penalizar el trfico de una red fsica.
2.9
Creacin de subredes
Para empezar, se define una SUBRED como un subconjunto de una red de clase A, B o C. En este contexto, para que un administrador pueda crear sus propias redes a partir de la direccin numrica oficial asignada a la organizacin, y asignarles localmente sus propias direcciones numricas o direcciones de Internet; se introduce el concepto de SUBRED, dividiendo la parte local o direccin de la computadora en dos partes:
37
Este concepto se analizar ms adelante.
- 64 -
32 bits
DIRECCIN DE RED
Parte local
DIRECCIN DE RED
DIRECCIN DE SUBRED
Subred: Permite asignar localmente direcciones propias IP
Figura 2.28.- Creacin de subredes. DIRECCIN DE LA SUBRED: Para las subredes que se van a crear. DIRECCIN DE LA MQUINA: Para las mquinas que se van a conectar a dichas subredes. En funcin de lo anterior, si se desean crear ms subredes que mquinas conectadas a dichas subredes, se utilizarn ms bits para la parte de DIRECCIN DE LA SUBRED. A su vez, si se quieren conectar ms mquinas que subredes creadas, se utilizarn ms bits para la parte de DIRECCIN DE LA MQUINA. En este contexto, se establece un criterio de distribucin de bits en funcin: De la clase a la que pertenece la direccin de Internet asignada oficialmente a la red de la organizacin y la mscara38 para obtener la parte local de dicha direccin. Del nmero de subredes que se desea crear y nmero de mquinas que se quiera conectar a dichas subredes. De las direcciones reservadas para la parte local (todo a ceros y unos). En la siguiente Figura 2.29 se muestran las restricciones existentes a la hora de crear subredes. Si se parte del hecho de que todo a ceros (direccin de red) y unos (difusin dirigida) son dos direcciones de mquina reservadas; dichas direcciones tambin afectan
38
Concepto que se analizar seguidamente.
- 65 -
a las subredes en la parte local de subred y mquina para las direcciones de clase A, B y C. As, es importante tener en cuenta en la parte local lo siguiente: Direccin de subred: En esta zona de la parte local no se debe poner todo a ceros para identificar a una subred ya que en la parte local de mquina podra aparecer tambin todo a ceros y sera una direccin de red. Igualmente, no se debe poner todo a unos para identificar a una subred ya que en la parte local de mquina podra aparecer tambin todo a unos y sera una difusin dirigida a una red. Asimismo, aun intentando poner todo a ceros o unos en la direccin de subred, el software de TCP/IP instalado en la mquina podra no permitirlo ya que, a continuacin, tal y como se ha indicado, en la parte local de mquina podra aparecer todo a ceros (o todo a unos) y sera una direccin de red o una difusin dirigida a dicha red. Es importante tener en cuenta, que el no usar todo a ceros y todo a unos en la parte local de direccin de subred (cuando se crean subredes y se restan las dos direcciones reservadas) se genera un problema y es que se pierden direcciones39 para identificar mquinas. Direccin de mquina: En esta zona de la parte local no se debe poner todo a ceros para identificar a una mquina, ya que en la parte local de direccin de subred se podra haber tecleado tambin todo a ceros y, por tanto, sera una direccin de red. En el caso de que en la direccin de subred no apareciera todo a ceros y en la direccin de mquina s, se estara ante el caso de una direccin de subred. Igualmente, no se debe poner todo a unos para identificar a una mquina, ya que en la parte local de direccin de subred podra aparecer tambin todo a unos y sera una difusin dirigida a una red. Asimismo, en el caso de que en la direccin de subred no apareciera todo a unos y en la direccin de mquina s, se estara ante el caso de una difusin dirigida a una subred.
39
Todas las combinaciones asociadas a todo ceros y unos en la parte de subred.
- 66 -
Todo 0s (direccin de red) y todo 1s (difusin dirigida) son dos direcciones de mquina reservadas.
En subredes afectan a la parte local de subred y mquina en direcciones clase A, B y C
No usar ni todo 0s ni todo 1s
DIRECCIN DE RED
DIRECCIN DE MQUINA
Parte local
DIRECCIN DE RED
DIRECCIN DE SUBRED
DIRECCIN DE MQUINA
No poner todo a 0s ya que en la parte local de mquina podran aparecer todo a 0s y sera una direccin de red No poner todo 1s ya que en la parte local de mquina podra aparecer todo a 1s y sera una difusin dirigida a una red Problema: Se pierden direcciones para identificar mquinas
No poner todo a 0s como direccin de mquina ya que en la parte local de subred podra estar todo a ceros (o no) y sera una direccin de red (subred) No poner todo 1s como direccin de mquina ya que en la parte local de subred podra estar todo a 1s (o no) y sera una difusin dirigida a una red (subred)
Figura 2.29.- Restricciones en la creacin de subredes. En la Figura 2.30 que viene a continuacin, se resume y concreta toda la problemtica existente en la creacin de subredes. Para empezar y como recomendacin para evitar cualquier tipo de problema, se sugiere lo siguiente: 1. Restar, siempre que se pueda, las dos direcciones reservadas en la parte local de la direccin de subred, segn recomiendan los documentos RFC-950 (estndar) y 1219 (informativo). Si al restar estas dos direcciones reservadas, se comprueba que no se dispone del suficiente rango de direcciones numricas para identificar a todas las mquinas que se desee conectar; entonces, se permite hacer uso de las dos direcciones reservadas (todo ceros y unos) en la parte local de la direccin de subred, siempre y cuando: a. El software de TCP/IP permita la configuracin de todo ceros y unos. b. No se use un protocolo con clases de actualizacin y distribucin de informacin de encaminamiento, del tipo RIPv140.
40
Protocolo que se estudiar en el apartado de los protocolos de actualizacin y distribucin de la informacin de encaminamiento.
- 67 -
Aun suponiendo lo comentado en los dos apartados anteriores a y b, el hecho de no restar las dos direcciones reservadas genera problemas, segn se comentar ms adelante, con las difusiones dirigidas de forma simultnea a dos o ms subredes. Por consiguiente, la recomendacin para la parte de la subred es seguir los documentos RFC-950 y 1219. 2. Obligatoriamente, restar siempre (tanto para redes como para subredes) las dos direcciones reservadas en la parte local de la direccin de la mquina porque: El software de TCP/IP de una mquina no permite identificar a una mquina con la misma direccin de una red o subred. Asimismo, dicho software de TCP/IP tampoco va a permitir identificar a una mquina con la misma direccin de una difusin dirigida, ya que no va a saber si el mensaje es para una mquina o para todas las mquinas de esa subred o de otras subredes conectadas a la misma.
Todo 0s (direccin de red) y todo 1s (difusin dirigida) son dos direcciones de mquina reservadas.
En subredes afectan a la parte local de subred y mquina en direcciones clase A, B y C
No usar ni todo 0s ni todo 1s
DIRECCIN DE RED
Parte local
DIRECCIN DE RED
DIRECCIN DE SUBRED
No poner todo a 0s ya que en la parte local de mquina podran aparecer todo a 0s y sera una direccin de red No poner todo 1s ya que en la parte local de mquina podra aparecer todo a 1s y sera una difusin dirigida a una red Problema: Se pierden direcciones para identificar mquinas
No poner todo a 0s como direccin de mquina ya que en la parte local de subred podra estar todo a ceros (o no) y sera una direccin de red (subred) No poner todo 1s como direccin de mquina ya que en la parte local de subred podra estar todo a 1s (o no) y sera una difusin dirigida a una red (subred)
Figura 2.30.- Direcciones reservadas en la parte local al crear subredes. Para poder realizar el correspondiente encaminamiento en Internet por las diferentes redes, y subredes privadas creadas por las distintas organizaciones,; se introduce el concepto de mscara. Una mscara es un nmero de 32 bits que contiene unos en los bits que identifican tanto a una red (mscara de red), como a una subred (mscara de
- 68 -
subred), como a una mquina (mscara de mquina). Por consiguiente, existen tres tipos de mscara: 1. Una mscara de red es un nmero de 32 bits que contiene unos en los bits que identifican a esa red. Los ceros restantes a la derecha identifican a la parte de mquina de esa direccin de red. 2. Una mscara de subred es un nmero de 32 bits que contiene unos en los bits que identifican a esa subred. Los ceros restantes a la derecha identifican a la parte de mquina de esa direccin de subred. En este contexto, es importante resaltar que una mscara permite distinguir la parte local de una direccin numrica. Por consiguiente, todo lo que est a la derecha a ceros es lo que se considera como parte local para identificar mquinas o para la conveniente distribucin de bits a la hora de crear subredes y conectar mquinas a dichas subredes. 3. Una mscara de mquina es un nmero de 32 bits que contiene todo a unos y que identifican a la mquina en cuestin. Por consiguiente, no aparece ningn cero ya que se necesitan los cuatro octetos de la direccin de dicha mquina para poder acceder a ella.
Una mscara de red o subred o mquina es un nmero de 32 bits que contiene 1s en los bits que identifican a la red o subred o mquina Una mscara permite distinguir la parte local de una direccin numrica para la creacin de subredes Toda mscara facilita las labores de encaminamiento mediante la aplicacin de la operacin lgica AND a la direccin destino y mscara correspondiente
Figura 2.31.- Concepto de mscara. Los bits en la mscara de red o subred se indican como 1, si la red o subred trata a los bits correspondientes de la direccin de IP como parte de la direccin de la red o subred. A su vez, se indican como 0, si estos bits coinciden con la parte del identificador de la mquina. Por ejemplo, la mscara de red o subred de 32 bits: 11111111 11111111 11111111 00000000,
- 69 -
especifica que los tres primeros octetos identifican a la red y el cuarto a una mquina en dicha red. El estndar RFC-950 no restringe a las mscaras de subred para que seleccionen bits contiguos de la direccin. Por ejemplo, una subred puede tener asignada la mscara: 11111111 11111111 00011000 01000000, la cual selecciona los primeros dos octetos, dos bits del tercer octeto y un bit del cuarto. Aunque esta flexibilidad permite que se puedan realizar asignaciones interesantes de direcciones, tambin causa confusin en la asignacin de direcciones de mquina y en la debida comprensin de las tablas de encaminamiento. Consecuentemente, se recomienda que se utilicen mscaras contiguas (unos consecutivos) de red o subred y empleen la misma mscara para todo un grupo de redes-subredes fsicas que compartan una sola direccin numrica. Asimismo, es fundamental tener en cuenta que todas las mquinas, desde el router ms sofisticado hasta la computadora ms simple de usuario, hacen uso de las correspondientes mscaras para poder realizar el oportuno encaminamiento. Toda mquina en Internet o en una red privada TCP/IP debe tener previamente configurada una tabla de encaminamiento con las direcciones de red (la direccin de destino ser una o ms mquinas de esa red), y/o subred (la direccin de destino ser una o ms mquinas de esa subred) y/o mquinas (la direccin de destino ser nicamente la direccin de la mquina especificada). Como ya se estudiar seguidamente, para poder realizar las labores de encaminamiento hay que aplicar la operacin lgica AND a la direccin de destino y mscara correspondiente. Tambin se ver que en una tabla de encaminamiento toda direccin (de red, subred o mquina) tiene asociada su mscara (de red, subred o mquina). De esta forma, y mediante esta operacin se obtiene la direccin de red o subred en donde se supone que est conectada dicha mquina de destino o la direccin de una mquina contigua que se supone que est conectada mediante una lnea serie o punto a punto con la que a su vez va a efectuar el pertinente encaminamiento. En la Figura 2.32 se muestra las diferentes mscaras de red, por omisin, para las direcciones de la clase A, B y C. Como ya se ha indicado, todas las redes tienen una direccin con el ltimo o ltimos octetos a cero en funcin de la clase de la direccin de red y de si se han usado todos los bits de esos octetos para identificar mquinas; es decir, no se han utilizado para crear subredes.
- 70 -
CLASE DE DIRECCIN
MSCARA POR OMISIN (Decimal) 255.0.0.0 255.255.0.0 255.255.255.0
A B C
Figura 2.32.- Mscaras de red por omisin. A la hora de crear subredes es importante tener en cuenta lo siguiente: Clase A: 255.0.0.0.- Significa que la parte local est formada por tres octetos. Clase B: 255.255.0.0.- Denota que la parte local est formada por dos octetos. Clase C: 255.255.255.0.- Determina que la parte local est formada por un octeto. Se recuerda que una mscara permite distinguir la parte local de una direccin numrica. Asimismo, la mscara asociada a una direccin numrica no tiene porqu ser la de por omisin. Es ms la mscara de subred es siempre mayor que la de por omisin. Consecuentemente, cuanto mayor es una mscara, obviamente, menor es el espacio para la parte local.
VALOR DEL OCTETO

0 128 192 224 240 248 252 254 255
CLCULO DEL OCTETO

0 128 128+64 128+64+32 128+64+32+16 128+64+32+16+8 128+64+32+16+8+4 128+64+32+16+8+4+2 128+64+32+16+8+4+2+1
MSCARA BINARIA
00000000 10000000 11000000 11100000 11110000 11111000 11111100 11111110 11111111
Figura 2.33.- Clculo del octeto de una mscara. En la Figura 2.33 se muestran algunos posibles valores en decimal y sus correspondientes valores en binario para el clculo del octeto de una mscara.
- 71 -
En la siguiente Figura 2.34 se recoge un ejemplo de creacin de subredes segn los documentos RFC-950 y 1219. En ella, se describe una organizacin que ha creado, a partir de la direccin de Internet oficial (220.10.15.0) y mscara oficial asignada (255.255.255.0 o mscara por omisin de la clase C), 2 subredes (220.10.15.64 y 220.10.15.128). A la hora de crear subredes es importante distinguir la parte local de la direccin de IP asignada. Para ello, es imprescindible tener en cuenta la mscara asociada, es decir: Clase C: 255.255.255.0.- Significa que la parte local est formada por un octeto y que no se puede tocar el tercer octeto (ni obviamente el primero y segundo) para crear subredes. Dicho octeto se distribuir en funcin de las subredes que se desean crear, mquinas que se quiera conectar, y direcciones reservadas. Si la mscara asignada oficialmente hubiera sido 255.255.255.128, significa que se dispone como parte local de slo siete bits del ltimo octeto y se debera usar slo el primero o los dos primeros bits (RFC-950, RFC-1219) de mayor orden o ms a la izquierda.
Router
Internet
220.10.15.0
Parte local
220.10.15.0
255.255.255.0
Organizacin
00 01 10 11
= 0000 0000 = 220.10.15.0 = 0100 0000 = 220.10.15.64 = 1000 0000 = 220.10.15.128 = 1100 0000 = 220.10.15.192
Router
Subred
xx xx xxxx
Se desean crear dos subredes a partir de la direccin y mscara oficial asignada
22 2 = 2
220.10.15.65
220.10.15.64
......
220.10.15.129
Internet
2
220.10.15.128
......
Figura 2.34.- Un ejemplo segn los documentos RFC- 950 y 1219. En la siguiente Figura 2.35 se muestran todas las direcciones posibles de mquinas (de la 220.10.15.65 a la 220.10.15.126) que se puede conectar a la subred 220.10.15.64. Lo mismo para la 220.10.15.128 (de la 220.10.15.129 a la 220.10.15.190). Todo ello, a travs de un proceso de asignacin de direcciones segn los documentos RFC-950 y 1219, que recomiendan excluir las dos direcciones reservadas (todo ceros y unos) en la parte local de subred, para no tener ambigedades al confundir una direccin de
- 72 -
difusin dirigida a una subred, de otra dirigida a un grupo de subredes. Evidentemente, asumiendo los RFC-950 y RFC-1219 se pierden direcciones de mquinas: De la 220.10.15.1 a la 220.10.15.62 para la subred 220.10.15.0 (62 direcciones de mquinas perdidas). De la 220.10.15.193 a la 220.10.15.224 para la subred 220.10.15.192 (62 direcciones de mquinas perdidas). Pero si nunca se va a usar dichas direcciones, y se desean utilizar difusiones dirigidas por grupo, mejor seguir los citados RFC, los cuales son una recomendacin y no una obligacin, ya que se puede configurar las mquinas como se desee, siempre y cuando el software de TCP/IP lo permita y no se utilice un protocolo de encaminamiento con clases (RIPv1).
220.10.15.0 xxxx xxxx
Subred
2 2=
2
220.10.15.64
00 01 10 11
= 0000 0000 = 220.10.15.0 = 0100 0000 = 220.10.15.64 = 1000 0000 = 220.10.15.128 = 1100 0000 = 220.10.15.192
0100 0001 = 220.10.15.65
.... ...
.... ...
0111 1110 = 220.10.15.126 1000 0001 = 220.10.15.129
Rango de direcciones de mquinas (62)

0111 1111 es una difusin a la subred 220.10.15.64
220.10.15.128
.... ...
1011 1110 = 220.10.15.190
.... ...
1011 1111 es una difusin a la subred 220.10.15.128 220.10.15.255 es una difusin dirigida a las subredes 220.10.15.64 y 220.10.15.128
220.10.15.0 220.10.15.192
0000 0001 = 220.10.15.1
.... ...
.... ...
0011 1110 = 220.10.15.62 1100 0001 = 220.10.15.193
Se pierden 62 mquinas
.... ...
.... ...
1111 1110 = 220.10.15.254
Se pierden 62 mquinas
Figura 2.35.- Continuacin del ejemplo segn los documentos RFC- 950 y 1219. La Figura 2.36 que se muestra seguidamente, describe a travs de dos ejemplos cmo se obtiene una mscara en funcin de la clase de la direccin correspondiente. Teniendo en cuenta que una mscara de red o subred es un nmero de 32 bits que contiene unos en los bits que identifican a la red (mscara de red)-subred (mscara de subred). La clave para calcular la mscara asociada a una direccin consiste en responder a la siguiente cuestin:
- 73 -
En funcin de la clase de la direccin numrica oficial, cuntos bits se han utilizado en la parte local para identificar subredes? Como se han usado 2 bits de los 8 que delimitan la parte local, el cuarto octeto en decimal sera un 192. Asimismo, como la direccin es de la clase C, el primer, segundo y tercer octeto en decimal tambin contendran un 255 por omisin. En el caso hipottico de haber usado 1 bit de los 8 que delimitan la parte local, el cuarto octeto en decimal sera un 128. Asimismo, como la direccin es de la clase C, el primer, segundo y tercer octeto en decimal tambin contendran un 255 por omisin.
Una mscara de red o subred es un nmero de 32 bits que contiene 1s en los bits que identifican a la red o subred En funcin de la clase de direccin, cuntos bits se han utilizado en la parte local para direccionar subredes?
En el caso de usar dos bits para identificar dos subredes:
220.10.15. XXxx
255 255 255 Clase C
xxxx
255.255.255.192
1100 0000 = 192
En el caso hipottico de usar 1 bit para identificar dos subredes:
220.10.15. Xxxx
255 255 255 Clase C
xxxx
255.255.255.128
1000 0000 = 128
Figura 2.36.- Ejemplos de obtencin de una mscara. La siguiente Figura 2.37 muestra la obtencin de la mscara en el escenario final del ejemplo anterior (ver Figura 2.34). En dicho ejemplo se parta de una organizacin que haba creado, a partir de la direccin de Internet oficial (220.10.15.0) y mscara oficial asignada (255.255.255.0 o mscara por omisin clase C), 2 subredes (220.10.15.64 y 220.10.15.128).
- 74 -
En el caso de usar dos bits para identificar dos subredes:
220.10.15. X
255 255 255 Clase C
xxx
xxxx
255.255.255.192
220.10.15.65
1100 0000 = 192
Router
Internet
220.10.15.64 255.255.255. 192
......
220.10.15.129
220.10.15.128 255.255.255.192
......
Figura 2.37.- Obtencin de la mscara para el escenario final del ejemplo.

220 10 15 65 11011100 00001010 00001111 01000001 (OPERACIN AND) 11111111 11111111 11111111 11000000 11011100 00001010 00001111 01000000 220 10 15 64 220 10 15 129 11011100 00001010 00001111 10000001 11111111 11111111 11111111 11000000 11011100 00001010 00001111 10000000 220 10 15 128
Destino Mscara Ruta
Directa Directa 220.10.15.64 255.255.255.192 220.10.15.128 255.255.255.192
MSCARA =
(255.255.255.192)
MSCARA =
(255.255.255.192)
(OPERACIN AND)
TABLA DE ENCAMINAMIENTO
Interfaz
1 2
Figura 2.38.- Aplicacin de la operacin AND en el escenario del ejemplo. En el escenario planteado con anterioridad, si aparece, por ejemplo (ver Figura 2.38), una unidad de datos (datagrama IP) para la mquina 220.10.15.65, la entidad IP del nivel de red de la arquitectura TCP/IP, ubicada en el router de la organizacin, aplicar una operacin lgica AND a dicha direccin y a la mscara empleada. Se resalta que la entidad IP aplicar dicha operacin a todas las mscaras que tenga registradas en su tabla de encaminamiento. As, hasta encontrar en la tabla una entrada con una direccin de subred asociada a la mscara utilizada en la operacin lgica. Consecuentemente, el resultado es una direccin de red (220.10.15.64) que se asume que dicha entidad IP dispone en su tabla de encaminamiento. Seguidamente, en funcin del resto de la informacin asociada a dicha entrada, el router encaminar
- 75 -
directamente41 la unidad de datos en cuestin por el interfaz de salida42 a la pertinente mquina. Como se puede comprobar, el concepto de mscara, es fundamental para poder encaminar una unidad de datos (datagrama IP). Como se ha comentado anteriormente, todas las mquinas en Internet, desde un router hasta una simple computadora o sistema final de usuario, tienen una tabla de encaminamiento con una serie de direcciones conocidas y una mscara asociada a cada una de ellas. A su vez, si aparece, por ejemplo, otra unidad de datos (datagrama IP) para la mquina 220.10.15.129, la entidad IP del nivel de red de la arquitectura TCP/IP, ubicada en el router de la organizacin, aplicar una operacin lgica AND a dicha direccin y a la mscara correspondiente. Igual que antes, el resultado es una direccin de red (220.10.15.128) que se asume que dicha entidad IP dispone en su tabla de encaminamiento. Seguidamente, en funcin del resto de la informacin asociada a dicha entrada, el router encaminar directamente la unidad de datos en cuestin por el interfaz de salida43 a la pertinente mquina. La siguiente Figura 2.39 muestra los tpicos problemas de difusin cuando se hace uso de todas las direcciones posibles sin seguir las recomendaciones RFC-950 y RFC-1219. En este ejemplo, en lugar de usar dos bits, se utiliza uno slo para direccionar las dos subredes de la organizacin del ejemplo anterior. Obviamente, se consigue un mayor rango de direcciones para identificar mquinas (se pasa de 62 mquinas a 128); pero esto ltimo acarrea un problema: cmo se puede realizar una difusin dirigida, simultnea, a las dos subredes? Se resalta que 220.10.15.255 es una difusin dirigida exclusivamente a la subred 220.10.15.128 y no a las dos subredes.
41
Ya que el router est conectado a la misma red que la mquina destinataria. Cuyo nmero, el 1, tambin est indicado en la tabla. Cuyo nmero, el 2, tambin est indicado en la tabla.
42
43
- 76 -
220.10.15.0
X xxx xxxx
Subred
2 =
1
0 = 0000 0000 = 220.10.15.0 1 = 1000 0000 = 220.10.15.128
Mscara = 255.255.255.1000 0000 = 255.255.255.128

220.10.15.0 0000 0001 = 220.10.15.1
.... ...
.... ...
0111 1110 = 220.10.15.126
220.10.15.0111 1111 = 220.10.15.127 = Es una difusin dirigida a la subred 220.10.15.0
220.10.15.128
1000 0001 = 220.10.15.129
.... ...
1111 1110 = 220.10.15.254
.... ...
220.10.15.1111 1111 = 220.10.15.255 = Es una difusin dirigida a la subred 220.10.15.128

PROBLEMA: Cmo envo una difusin dirigida de manera simultnea a las dos subredes?
Figura 2.39.- Creacin de subredes sin seguir los documentos RFC-950 y 1219. La siguiente Figura 2.40 muestra otro ejemplo de una organizacin que ha creado, a partir de la direccin de Internet y mscara oficial asignadas (128.10.0.0/255.255.0.0), 254 subredes (128.10.1.0, 128.10.2.0, , 128.10.254.0) y 254 mquinas conectadas a cada una de ellas. Como ya se ha indicado con anterioridad, a la hora de crear subredes es importante distinguir la parte local de la direccin de IP asignada. Para ello, es imprescindible tener en cuenta la mscara asociada, es decir: Clase B: 255.255.0.0.- Significa que la parte local est formada por dos octetos para crear subredes, que se distribuir como se desee en funcin de las subredes y mquinas que se desean conectar y de las correspondientes direcciones reservadas. Por consiguiente, dicha organizacin crear como mximo 254 subredes (tercer octeto) y conectar tambin como mximo 254 mquinas (cuarto octeto) a cada una de dichas subredes. Se recuerda que si, por ejemplo, la mscara oficial asignada hubiera sido 255.255.255.0, significa que la parte local est formada por un solo octeto (el ltimo) y que no se puede tocar el tercer octeto (ni obviamente el primero y el segundo) para crear subredes. Por consiguiente, si no se especifica ninguna mscara, se toma por omisin la mscara natural de la direccin y se utiliza en funcin de las necesidades todos los bits a cero que se corresponden con la pertinente parte local.
- 77 -
Router
Internet
128.10. 0.0 Parte Local xxxx xxxx 0000 0000
Subredes 28 2 = 254
Subred
128.10.0.0
255.255.0.0
Organizacin
128.10.1.0 128.10.2.0
................. 128.10.254.0
128.10.1.0
0000 0000 0000 0001 = 1 0000 0010 = 2 ................. 1111 1110 = 254 1111 1111
Se desean crear 254 subredes a partir de la direccin y mscara oficial asignada
Internet
...
128.10.254.0
128.10.2.0
Figura 2.40.- Otro ejemplo segn los documentos RFC-950 y 1219. La siguiente Figura 2.41 muestra la obtencin de la mscara en el escenario final del ltimo ejemplo. En dicho ejemplo se parta de una organizacin que haba creado, a partir de la direccin de Internet oficial que le haba sido asignada (128.10.0.0), 254 subredes (128.10.1.0, 128.10.2.0, , 128.10.254.0) y 254 mquinas conectadas a cada una de ellas. En funcin de la clase de direccin, cuntos bits se han utilizado en la parte local para identificar subredes? Como se han usado 8 bits de los 16 que delimitan la parte local, el tercer octeto en decimal es un 255. Asimismo, como la direccin es de la clase B, el primer y segundo octeto en decimal tambin contiene un 255 por omisin.
- 78 -
128.10.X
255 255 Clase B
xxxxxxx.0
255.255.255.0
128.10.1.1
1111 1111 = 255
Router
Internet
128.10.1.0 255.255.255.0
......
128.10.254.1
......
2
128.10.254.0 255.255.255.0
......
Figura 2.41.- Obtencin de la mscara para el escenario final del ejemplo. En el ltimo escenario planteado, si aparece, por ejemplo (ver Figura 2.42), una unidad de datos (datagrama IP) para la mquina 128.10.1.1, la entidad IP del nivel de red de la arquitectura TCP/IP, ubicada en el router de la organizacin, aplicar una operacin lgica AND a dicha direccin y mscara empleada. Se vuelve a resaltar el hecho de que la entidad IP aplicar esta operacin a todas las mscaras que tenga registradas en su tabla de encaminamiento. As, hasta encontrar en la tabla una entrada con una direccin de subred asociada a la mscara utilizada en la operacin lgica. Por consiguiente, el resultado es una direccin de red (128.10.1) que se asume que dicha entidad IP dispone en su tabla de encaminamiento. Seguidamente, en funcin del resto de la informacin asociada a dicha entrada, el router encaminar directamente la unidad de datos en cuestin por el interfaz de salida44 a la pertinente mquina. A su vez, si aparece, por ejemplo, otra unidad de datos (datagrama IP) para la mquina 128.10.254.1, la entidad IP del nivel de red de la arquitectura TCP/IP, ubicada en el router de la organizacin, aplicar una operacin lgica AND a dicha direccin y mscara correspondiente. Igual que antes, el resultado es una direccin de red (128.10.254.0) que se asume que dicha entidad IP dispone en su tabla de encaminamiento. Seguidamente, en funcin del resto de la informacin asociada a dicha entrada, el router encaminar directamente la unidad de datos en cuestin por el interfaz de salida45 a la pertinente mquina.
44
Cuyo nmero, el 1, tambin est indicado en la tabla. Cuyo nmero, el 254, tambin est indicado en la tabla.
45
- 79 -
MSCARA =
(255.255.255.0)
128 10 1 1 10000000 00001010 00000001 00000001 11111111 11111111 11111111 00000000 10000000 00001010 00000001 00000000 128 10 1 254 128 10 1 10000000 00001010 11111110 00000001 11111111 11111111 11111111 00000000 10000000 00001010 11111110 00000000 128 10 254
Destino
128.10.1.0
(OPERACIN AND)
MSCARA =
(255.255.255.0)
(OPERACIN AND)
Mscara ... ...
Ruta
Interfaz
1
255.255.255.0 255.255.255.0
Directa
... ...
128.10.254.0
... ...
Directa
... ...
254
Figura 2.42.- Aplicacin de la operacin AND en el escenario del ejemplo.
2.10 Tipos de difusin

LIMITADA. Exclusivamente a todas las mquinas de la red local de acceso: 255.255.255.255/255.255.255.255 DIRIGIDA. Tres tipos (RFC-922):
1. Exclusivamente a una red: P.ej., a la red 128.1.0.0/255.255.0.0, sera 128.1.255.255/255.255.255.255 2. Exclusivamente a una subred: P.ej., a la subred 128.1.4.0/255.255.255.0, sera: 128.1.4.255/255.255.255.255 3a. A todas las subredes con un prefijo comn de subred (128.1) y una mscara comn de direccin de subred, por ejemplo, de tres octetos como 255.255.255.0: P.ej., a todas las subredes con un prefijo comn de 2 octetos (128.1) como 128.1.1, 128.1.2, 128.1.3, ..., 128.1.254 sera: 128.1.255.255/255.255.255.255 3b. A todas las subredes con un prefijo comn de subred (128.1) y una mscara comn de direccin de subred, por ejemplo, de ms de tres octetos como 255.255.255.252: P.ej., a todas las subredes con un prefijo comn de 2 octetos como 128.1.1.128, 128.1.1.192, ..., 128.1.1.252, 128.1.2.128, 128.1.2.192, ..., 128.1.2.252, , 128.1.254.128, 128.1.254.192, ..., 128.1.254.252 sera: 128.1.255.255/255.255.255.255 Si no hay subredes anidadas, una difusin a una subred tiene el mismo efecto que una difusin limitada En general las difusiones a subredes se estn convirtiendo en obsoletas y tienden a ser sustituidas por la multidifusin o multicast
Figura 2.43.- Tipos de difusin. Como ya se ha comentado con anterioridad, existen dos tipos de difusiones: Difusiones limitadas: Permiten enviar un mismo mensaje de difusin exclusivamente a todas las mquinas de la red o subred a la cual est conectada la mquina de origen de la difusin. 255.255.255.255 (difusin limitada)/255.255.255.255 (mscara de la difusin).
- 80 -
Difusiones dirigidas: Permiten enviar un mismo mensaje de difusin progresivamente a todas las mquinas y subredes conectadas a la subred de la mquina de origen de la difusin. Se recuerda que la difusin dirigida puede ser local (acceso directo) o remota, a diferencia de la difusin limitada que es siempre local o directa. Es importante tener en cuenta que el reconocimiento del tipo de difusin dirigida es siempre por la mscara de la direccin de red o subred correspondiente. A su vez, existen tres tipos diferentes de difusiones dirigidas: 1. Por ejemplo, a la red 128.1.0.0 (direccin de red)/255.255.0.0 (mscara de la direccin), sera 128.1.255.255 (direccin de difusin)/255.255.255.255 (mscara de la difusin). La mscara 255.255.0.0 de la direccin 128.1.0.0 implica que la difusin, 128.1.255.255/255.255.255.255, empieza y termina en la direccin especificada y delimitada por el primer y segundo octeto (el primer octeto describe el prefijo comn y el segundo una sola red de las 254 redes posibles). Una difusin dirigida a una red tiene el mismo efecto que una difusin limitada. 2. Por ejemplo, a la subred 128.1.4.0 (direccin de subred)/255.255.255.0 (mscara de la direccin), sera: 128.1.4.255 (direccin de difusin)/255.255.255.255 (mscara de la difusin). La mscara 255.255.255.0 de la direccin 128.1.4.0 implica que la difusin, 128.1.4.255/255.255.255.255, empieza y termina en la direccin especificada y delimitada por el primer, segundo y tercer octeto (el primer y segundo octeto describen el prefijo comn y el tercero una sola red de las 254 subredes posibles). Una difusin dirigida a una subred tiene el mismo efecto que una difusin limitada. 3a. Por ejemplo, a todas las subredes con un prefijo comn de 2 octetos (128.1) como 128.1.1.0, 128.1.2.0, 128.1.3.0, ..., 128.1.254.0 y con una mscara comn de direccin de 255.255.255.0 sera: 128.1.255.255 (direccin de difusin)/255.255.255.255 (mscara de la difusin). La mscara comn 255.255.255.0 de las direcciones de subred, implica que la difusin, 128.1.255.255/255.255.255.255, empieza y termina en la direccin especificada y delimitada por el primer, segundo y tercer octeto (el primer y segundo octeto describen el prefijo comn y el tercero las 254 subredes). Por consiguiente, las subredes anteriores (128.1.1.0, 128.1.2.0, 128.1.3.0, 128.1.4.0, ..., 128.1.254.0), soportan una difusin dirigida (128.1.255.255/255.255.255.255), si y slo si, tienen una mscara de 255.255.255.0
- 81 -
3b. Una variante del caso anterior, por ejemplo, sera a todas las subredes con un prefijo comn de 2 octetos (128.1) y mscara comn de direccin de subred de 255.255.255.252 (se dejan dos bits contiguos como parte local slo para identificar mquinas): 128.1.1.128, 128.1.1.192, 128.1.1.224, ..., 128.1.1.252 128.1.2.128, 128.1.2.192, 128.1.2.224, ..., 128.1.2.252. 128.1.3.128, 128.1.3.192, 128.1.3.224, ..., 128.1.3.252. 128.1.254.128, 128.1.254.192, 128.1.254.224, ..., 128.1.254.252.
La difusin dirigida para este ltimo ejemplo sera: 128.1.255.255 (direccin de difusin)/255.255.255.255 (mscara de la difusin). La mscara comn 255.255.255.252 de las direcciones de subred implica que la difusin, 128.1.255.255/255.255.255.255, empieza y termina en la direccin especificada y delimitada por el primer, segundo, tercer y 6 bits del cuarto octeto (el primer, segundo y tercer octeto describen el prefijo comn y los 6 bits del tercero las 252 subredes). Por consiguiente, las subredes anteriores soportan una difusin dirigida (128.1.255.255/255.255.255.255), si y slo si, tienen una mscara de 255.255.255.252.
Origen
1
Router 1
128.1.1.0
1
Router 2
128.1.2.0
1 1
128.1.3.0
Destino
128.1.255.255
Mscara
255.255.255.255
Ruta
Directa
Interfaz
1
Figura 2.44.- Un ejemplo de difusin dirigida a todas las subredes.
- 82 -
En la anterior Figura 2.44 se muestra el caso del envo de un mensaje desde una mquina de origen a la direccin de destino siguiente: 128.1.255.255. Dicho escenario se corresponde con el ejemplo de una difusin dirigida 128.1.255.255/255.255.255.255 a todas las subredes con un prefijo comn de 2 octetos (128.1). En este caso, 128.1.1.0, 128.1.2.0 y 128.1.3.0, las cuales disponen de una mscara comn de direccin de subred de 255.255.255.0. Como ya se ha comentado, la mscara comn 255.255.255.0 implica que la difusin, 128.1.255.255/255.255.255.255, empieza y termina en la direccin especificada y delimitada por el primer, segundo y tercer octeto. Las tablas de encaminamiento de la mquina de origen de la difusin, Router 1 y Router 2 deben tener una misma entrada para hacer progresar la difusin de un mismo mensaje a todas las mquinas de las subredes 128.1.1.0, 128.1.2.0 y 128.1.3.0. Para terminar con las difusiones dirigidas es importante tener en cuenta los siguientes puntos: Las difusiones dirigidas estn diseadas, fundamentalmente, para las subredes, aunque se puede enviar una difusin dirigida exclusivamente a una red o a una subred. Una difusin dirigida a subredes exige una difusin progresiva desde la primera subred al resto de las subredes conectadas. En el caso de subredes anidadas, la mquina de origen y todos los routers deben tener una misma entrada en la tabla de encaminamiento. Una difusin dirigida exclusivamente a una red o subred (sin subredes anidadas) tiene el mismo efecto que una difusin limitada. En general, las difusiones dirigidas a subredes se estn convirtiendo en obsoletas y tienden a ser sustituidas por la multidifusin o multicast. En este contexto, las difusiones se consideran un caso especial de las transmisiones multidifusin.
2.11 Mscaras de subred de longitud variable

Hasta el momento, en los ejemplos anteriormente vistos, se ha estado asignando una misma cantidad mxima de mquinas a todas las subredes que se han ido creando. Pero tambin es posible asignar un nmero variable de computadoras. Segn lo anterior, existen dos tipos de mscaras de subred:
- 83 -
De longitud fija: Se basa en una divisin esttica de subredes (subredes estticas). Todas las redes, lo necesiten o no, disponen del mismo rango de direcciones para mquinas. De longitud variable (VLSM: Variable Length Subnet Masks): Se fundamenta en una divisin dinmica o variable de subredes (subredes dinmicas). Proporciona al administrador una forma ms ptima y flexible de asignar direcciones numricas, permitindole identificar cantidades variables de mquinas a las subredes creadas.
Mscaras de subred de longitud fija: Slo permiten aplicar una mscara de subred a todas las subredes creadas, a partir de una direccin de red, con lo cual se asigna la misma cantidad de mquinas a dichas subredes Mscaras de subred de longitud variable (VLSM: Variable Length Subnet Masks), RFC-1878: Permiten aplicar diferentes mscaras a las subredes creadas, a partir de una direccin de red, proporcionando la capacidad de asignar cantidades variables de mquinas a dichas subredes
Figura 2.45.- Clases de mscaras de subred.
Router
Internet
220.10.15.0
Parte local
220.10.15.0
255.255.255.0
Organizacin
xx xx xxxx
22 = 4 > 3 redes
Se desea crear, a partir de la direccin y mscara oficial asignada, tres subredes con 100 mquinas en una y 50 mquinas en las dos restantes
26 2 = 62 < 100 mquinas
Figura 2.46.- Ejemplo de mscaras de subred de longitud variable.
- 84 -
En el ejemplo de la anterior Figura 2.46, se desean crear, a partir de la direccin y mscara oficial asignada, tres subredes con 100 mquinas en una y 50 mquinas en las dos restantes. Con 3 bits para subredes (RFC-950) quedan 5 bits para mquinas (25-2 = 30 mquinas) que son claramente insuficientes para los dos casos (100 mquinas en una subred y 50 en las dos restantes). Con 2 bits para subredes (segn muestra la anterior Figura 2.46), y sin seguir el documento RFC-950, quedan 6 bits para mquinas (26-2 = 62 mquinas) que son suficientes para uno de los dos casos (suficientes para las 50 mquinas en dos subredes pero no para las 100 mquinas en la otra subred). En este ejemplo, y ante la escasez de direcciones, se va a hacer uso de las direcciones reservadas (todo ceros y unos) para las subredes. Se recuerda que si se cogen tres bits slo quedan cinco para mquinas. Consecuentemente, todava hay que reducir ms la parte local de subredes y, adems, hay que tener en cuenta que se desea conectar un nmero diferente de mquinas en las subredes de la organizacin. Para ello, se introduce el concepto de VLSM en funcin de los dos pasos que se muestran a continuacin.
1.- Reducimos el n de bits para subredes con el objetivo de aumentar el n de bits para mquinas
220.10.15.0
X xxx xxxx
Subred
2 =
1
0 = 0000 0000 = 220.10.15.0 1 = 1000 0000 = 220.10.15.128
Mscara = 255.255.255.1000 0000 = 255.255.255.128

220.10.15.0 0000 0001 = 220.10.15.1
.... ...
.... ...
0111 1110 = 220.10.15.126
(220.10.15.0111 1111 = 220.10.15.127 = Es una difusin dirigida a la subred 220.10.15.0)
220.10.15.128
1000 0001 = 220.10.15.129
.... ...
1111 1110 = 220.10.15.254
.... ...
(220.10.15.1111 1111 = 220.10.15.255 = Es una difusin dirigida a la subred 220.10.15.128)
Figura 2.47.- Paso primero para obtener VLSM. En el paso 1 (ver Figura 2.47), se reduce el nmero de bits para subredes con el objetivo de aumentar el nnmero de bits para mquinas. Con 1 bit para subredes quedan 7 bits para mquinas (27-2 = 126 mquinas). Pero con 1 bit para subredes slo se puede identificar 2 subredes y se recuerda que se desean conectar 3 subredes. - 85 -
2.- Creamos nuevas subredes a partir de una cualquiera, de las obtenidas anteriormente, que disponga del suficiente nmero de mquinas con el objetivo de aumentar el n de bits para nuevas subredes y mquinas 220.10.15.128 1000 0000 Parte Local 1xxx xxxx 126 mquinas
Hay que crear dos subredes con 50 mquinas en cada una de ellas
26 2 = 62 > 50 mquinas
1 0 0 0 0 0 0 0 = 128 (220.10.15.128) 1 1 0 0 0 0 0 0 = 192 (220.10.15.192)
220.10.15.0 255.255.255.128
...... 100 mquinas
Internet
220.10.15.128 255.255.255.192
......
50 mquinas
220.10.15.192 255.255.255.192
......
50 mquinas
Figura 2.48.- Paso segundo para obtener VLSM. En el paso 2 (ver Figura 2.48), se crean nuevas subredes a partir de una cualquiera, de las obtenidas anteriormente. Eso s, debe disponer del suficiente nmero de mquinas con el objetivo de aumentar el n de bits para nuevas subredes y mquinas. Como slo se desean crear dos subredes, una va a ser la 128 (la de partida) y otra la 192. Es decir, se elige, por ejemplo, la 220.10.15.0 para conectar 100 mquinas y la 220.10.15.128, se usa, a su vez, para crear nuevas subredes. Asimismo, como slo se quieren crear dos subredes (se utiliza 1 bit), una subred va a ser la misma, la 220.10.15.128, y otra la 220.10.15.192. Con lo cual la mscara asociada (al usar dos bits) ser de 255.255.255.192.
2.12 Tablas de encaminamiento

Para una mayor comprensin del proceso de encaminamiento que se lleva a cabo en Internet, en la siguiente Figura 2.49 se muestra un ejemplo de 4 redes y 3 routers, as como la tabla de encaminamiento de uno de ellos. Dicha tabla dispone de los tres tipos posibles de encaminamiento: DIRECTO: Cuando la mquina de destino est conectada a la misma red de acceso y la direccin de red de dicha mquina destinataria es conocida46 al aplicar la pertinente mscara. En este caso, no se transmite la unidad de datos
46
Ya que dicha direccin est registrada en la tabla de encaminamiento.
- 86 -
(datagrama IP) a un router vecino o contiguo (cuya direccin est registrada en el campo de RUTA47 de la tabla de encaminamiento) ya que la propia mquina es capaz de efectuar dicho encaminamiento. Una mquina es vecina de otra, cuando est conectada a la misma red que la considerada. INDIRECTO: Cuando la mquina de destino no est conectada a la misma red de acceso. Adems, la direccin de red de dicha mquina destinataria es conocida y hay que pasar por un router vecino (RUTA). POR OMISIN: Cuando la mquina de destino no est conectada a la misma red de acceso. Adems, la direccin de red de dicha mquina destinataria no es conocida48 y hay que transmitir la unidad de datos (datagrama IP) a un router vecino (RUTA).
11.2.0.37
11.0.0.0
130.206.1.3
138.100.1.1
1 2
192.5.48.1
130.206.0.0
130.206.1.1
138.100.0.0
138.100.3.2
192.5.48.0
DESTINO 0.0.0.0 130.206.0.0 138.100.0.0 11.0.0.0 192.5.48.0
RUTA 138.100.3.2 DIRECTA DIRECTA 130.206.1.3 138.100.3.2
INTERFAZ 2 1 2 1 2
Figura 2.49.- Ejemplo sencillo de una tabla de encaminamiento. Teniendo en cuenta el escenario descrito en la Figura 2.49, es importante resaltar los siguientes aforismos: Cada router en su tabla de encaminamiento tiene registradas las direcciones numricas de sus routers vecinos (130.206.1.3 y 138.100.3.2). Mediante este procedimiento se van concatenando todas las redes-subredes que conforman la red Internet.
47
El campo de RUTA (PUERTA DE ENLACE en Windows) en la tabla de encaminamiento indica la siguiente mquina que debe tratar el encaminamiento de la unidad de datos. Esta mquina es la misma en encaminamientos directos o un router en encaminamientos indirectos o por omisin. Debido a que no est registrada en la tabla de encaminamiento.
48
- 87 -
Cada router dispone de dos o ms direcciones numricas (130.206.1.1 y 138.100.1.1) en funcin del nmero de redes (130.206.0.0 y 138.100.0.0) a las que est conectado. Un router puede saber si la mquina destinataria pertenece a su misma red de acceso comparando la direccin de red de dicha mquina con la suya. Si es la misma, transmite directamente y si no, indirectamente o por omisin a un router vecino. Como ya se ha comentado, la comparacin se lleva a cabo aplicando la operacin lgica AND a la direccin de la mquina destinataria y mscara correspondiente. Es importante resaltar que se aplica una a continuacin de otra todas las mscaras de la tabla hasta encontrar o no una direccin conocida o registrada en dicha tabla. Por tanto, un router excluyendo la mscara asociada al interfaz de entrada por donde ha llegado el datagrama, va aplicando, en un determinado orden49, las mscaras de cada interfaz de salida hasta obtener o no una direccin incluida en la tabla. En caso de no obtener una direccin conocida, se acta por omisin si la entrada 0.0.0.0 est incluida en la tabla50.
DESTINO
Dir1 Dir2
MSCARA
M1 M2
Direccin de destino del datagrama
D AN D AN
1 (entrada ms prioritaria) 2
n (entrada ms general) Problema: Si se obtiene como resultado Dir1 al aplicar M1 a una direccin de destino cuya direccin de red es diferente de Dir1
Figura 2.50.- Una tabla de encaminamiento genrica. En el ejemplo de la anterior Figura 2.50, y aplicando todas las mscaras de la tabla, por ejemplo, de arriba abajo (M1, M2, ); si al aplicar la operacin lgica AND a la direccin de destino del datagrama recibido y a la primera mscara M1, se obtiene la misma direccin Dir1 asociada a M1; entonces se analiza el resto de los campos de la entrada de Dir1 para efectuar el correspondiente encaminamiento. En el caso de que no se obtenga Dir1 se aplicar la operacin lgica AND a la direccin de destino del datagrama
49
En Windows se empieza por la ltima entrada de la tabla, es decir, se examina sta de ABAJO ARRIBA. Esta ltima entrada se corresponde con la ruta de ms prioridad o ms corta o ms pequea. Si la entrada 0.0.0.0 no est registrada en la tabla, se transmite a la mquina de origen un mensaje de control (ICMP) indicando destino inalcanzable. Esto ltimo ya se estudiar en su momento.
50
- 88 -
recibido y a la siguiente mscara M2, actuando de la misma manera. As se continuara sucesivamente hasta encontrar o no una direccin registrada en el campo de DESTINO de la tabla. Es importante resaltar que si se aplica M1 a una direccin de destino cuya direccin de red es diferente de Dir1 y se obtiene por resultado Dir1 es porque probablemente hay algo incorrecto ya sea en la mascara que se ha empleado o en el orden de las entradas en la tabla de encaminamiento. Seguidamente, se muestra a travs de un ejemplo lo anteriormente comentado. Una organizacin desea asociar, para cada una de sus dos subredes (149.192.64.0 y 149.192.66.0) una mscara que cubra el menor nmero de bits en la parte de subred y permita diferenciarlas sin ninguna ambigedad para poder conectar el mayor nmero de mquinas a cada una de ellas. En funcin de todo lo anterior, si se asocian las mscaras 255.255.192.0 y 255.255.254.0 respectivamente, segn se refleja en la siguiente Figura 2.51, se presentara el siguiente problema.
. . .
149.192.64.0 (255.255.192.0)
149.192.66.0 (255.255.254.0)
DESTINO
64
MSCARA
192 1 2
149.192.01000000.0 149.192.01000010.0 . . . 66
255.255.11000000.0 255.255.11111110.0 . . . 254
Figura 2.51.- Un ejemplo incorrecto de una tabla de encaminamiento. Si aparece un datagrama con la direccin de destino, 149.192.66.5 y se aplica la primera mscara, 255.255.192.0 de la tabla (p. ej., de arriba abajo), se obtiene como resultado la direccin 149.192.64.0 que es la direccin de la primera red. Obviamente, el resultado correcto hubiera sido 149.192.66.5, ya que la mquina destinataria 149.192.66.5 est conectada a la segunda red y no a la primera. Consecuentemente, hay algo incorrecto en la tabla de encaminamiento, ya sea con la mscara 255.255.192.0 empleada o con el orden de las entradas en dicha tabla.
- 89 -
MSCARA =
(255.255.192.0)
149 192 66 5 10010101 11000000 01000010 00000101 (OPERACIN AND) 11111111 11111111 11000000 00000000 10010101 11000000 01000000 00000000 149 192 64 0
INCORRECTO
Figura 2.52.- Aplicacin de la operacin AND en el escenario del ejemplo. Si en cambio se aplica la segunda mscara, 255.255.254.0, se obtiene como resultado la direccin 149.192.66.0 que es la direccin de la segunda red.
MSCARA =
(255.255.254.0)
149 192 66 5 10010101 11000000 01000010 00000101 (OPERACIN AND) 11111111 11111111 11111110 00000000 10010101 11000000 01000010 00000000 149 192 66 0
CORRECTO
Figura 2.53.- Aplicacin de la operacin AND en el escenario del ejemplo. En la Figura 2.54 y Figura 2.55 se muestra una posible solucin, para el escenario planteado anteriormente mediante el uso de una misma mscara (la mayor de las dos) que permita diferenciar dicha direccin del resto de direcciones de subred utilizadas. Visto de otra manera, se ordenan las direcciones de menor a mayor, seguidamente, se coge la direccin mayor (149.192.66.0) y se compara con la menor (149.192.64.0). Para ello, y de izquierda a derecha, se va buscando el primer bit del tercer octeto (subredes de la clase B) que distinga51 a una direccin de otra.
51
A la derecha del bit diferenciador tiene que estar todo a ceros.
- 90 -
149.192.64.0 = 149.192.010 0 00 0 0. 00000000

1111 1110 =254
149.192.66.0 = 149.192.010 0 00 1 0. 00000000

1111 1110 = 254
Figura 2.54.- Procedimiento de obtencin de una mscara.

. . .
149.192.64.0 (255.255.254.0)
149.192.66.0 (255.255.254.0)
DESTINO
64
MSCARA
254 1 2
149.192.01000000.0 149.192.01000010.0 . . . 66
255.255.11111110.0 255.255.11111110.0 . . . 254
Figura 2.55.- Un ejemplo correcto de tabla de encaminamiento. Otra posible solucin descrita en la siguiente Figura 2.56, consiste en alterar el orden de las entradas en la tabla en cuestin. Esta ltima solucin demuestra lo importante que es el orden que se estableza en una tabla de encaminamiento. Como ya se ha comentado, la primera entrada (ya sea de arriba abajo o de abajo arriba) debe ser la de ms prioridad y la ltima, la ms general52.
52
En la mayora de los casos se corresponde con la ruta por omisin (0.0.0.0).
- 91 -
. . .
149.192.64.0 (255.255.192.0)
149.192.66.0 (255.255.254.0)
DESTINO
66
MSCARA
254 1 2
149.192.01000010.0 149.192.01000000.0 . . . 64
255.255.11111110.0 255.255.11000000.0 . . . 192
Figura 2.56.- Otro ejemplo correcto de tabla de encaminamiento.
149.192.64.0
149.192.66.0
149.192.80.0
149.192.96.0
Figura 2.57.- Un escenario para la obtencin de mscaras. Para una mayor comprensin de lo anteriormente comentado, y en funcin del escenario recogido en la Figura 2.57 en donde aparecen cuatro subredes de la clase B; se va a proceder a la obtencin de la mscara asociada a cada subred teniendo en cuenta los dos siguientes puntos: 1. Se debe asignar el mayor nmero posible de mquinas a cada subred. 2. La mscara debe cubrir, para cada direccin de subred, el menor nmero de bits que permita diferenciar dicha direccin del resto de direcciones de subred utilizadas en la organizacin.
- 92 -
Como hay que distinguir cada mscara del resto (y no por parejas), y segn refleja la siguiente Figura 2.58 y Figura 2.59, se ordenan las direcciones de menor a mayor. A continuacin, se empieza por la ltima direccin que es la mayor (149.192.96.0) y se va comparando con el resto de direcciones (149.192.80.0, 149.192.66.0 y 149.192.64.0). Para ello, y de izquierda a derecha, se va buscando el primer bit del tercer octeto (subredes de la clase B) que distinga53 a la direccin de dicha subred del resto de direcciones de subredes. Seguidamente, se hace lo mismo para la penltima direccin (149.192.80.0) con respecto al resto (149.192.66.0 y 149.192.64.0). Finalmente, se procede de idntica forma con las dos que quedan, es decir, 149.192.66.0 y 149.192.64.0.
149.192.64.0 = 149.192.010 0 00 0 0. 00000000 149.192.66.0 = 149.192.010 0 00 1 0. 00000000 149.192.80.0 = 149.192.010 1 00 00. 00000000 149.192.96.0 = 149.192.011 0 00 00. 00000000
Figura 2.58.- Un procedimiento para la obtencin de mscaras.
149.192.64.0 = 149.192.010 0 00 0 0. 00000000

1111 1110 =254
149.192.66.0 = 149.192.010 0 00 1 0. 00000000

1111 1110 = 254
149.192.80.0 = 149.192.010 1 00 00. 00000000

1111 0000 =240
149.192.96.0 = 149.192.011 0 00 00. 00000000

1110 0000 = 224
Figura 2.59.- Continuacin del procedimiento de obtencin de mscaras. Segn refleja la Figura 2.59, la mscara de cada direccin contendr todo a unos en el tercer octeto hasta el ltimo 1 de dicho octeto. Por ejemplo, para la direccin 149.192.96.0, cuyo tercer octeto en binario es 0110 0000, la mscara de este tercer octeto ser 1110 0000. Obviamente, al ser una direccin de la clase B, los dos primeros
53
A la derecha del bit diferenciador tiene que estar todo a ceros.
- 93 -
octetos, por omisin, estarn a unos. El resultado final con la obtencin de cada una de las mscaras se refleja en la siguiente Figura 2.60:
149.192.64.0 255.255.254.0
149.192.66.0 255.255.254.0
149.192.80.0 255.255.240.0
149.192.96.0 255.255.224.0
Figura 2.60.- Finalizacin del procedimiento de obtencin de mscaras. Asimismo, es importante resaltar que: Un router encamina los datagramas IP segn la direccin de red o subred. La cantidad de informacin almacenada en un router es proporcional al nmero de redes. Un router es transparente al usuario. Obviamente, si los usuarios cada vez que quisieran conectarse con una mquina por Internet, tuvieran que conocer e identificar previamente las direcciones de los routers o sistemas intermedios que intervienen en el camino origen-destino, desistiran de intentarlo.
A
128.1.1.2
Router 1
128.1.1.1 128.1.2.1 128.1.2.2
Router 2
128.1.2.0 ...
128.1.1.0
DESTINO MSCARA 0.0.0.0 0.0.0.0 255.0.0.0 127.0.0.0 255.255.255.0 128.1.1.0 255.255.255.0 128.1.2.0 255.255.255.255 128.1.1.2 128.1.255.255 255.255.255.255 240.0.0.0 224.0.0.0 255.255.255.255 255.255.255.255
RUTA 128.1.1.1 127.0.0.1 128.1.1.2 128.1.1.1 127.0.0.1 128.1.1.2 128.1.1.2 128.1.1.2
INTERFAZ 128.1.1.2 127.0.0.1 128.1.1.2 128.1.1.2 127.0.0.1 128.1.1.2 128.1.1.2 128.1.1.2
Figura 2.61.- Un ejemplo completo de una tabla de encaminamiento.
- 94 -
Tomando como ejemplo el escenario indicado en la anterior Figura 2.61, se muestra una posible tabla de encaminamiento para la mquina A cuya direccin de Internet es, por ejemplo, la 128.1.1.2. A su vez, el Router 1 tiene dos direcciones, 128.1.1.1 y 128.1.2.1, al estar conectado a dos subredes (128.1.1.0 y 128.1.2.0). Asimismo, el Router 2 tiene la direccin 128.1.2.2 de cara a la red 128.1.2.0. DESTINO = 0.0.0.0: Es un encaminamiento POR OMISIN que se lleva a cabo cuando al aplicar la operacin AND a la pertinente direccin de la mquina destinataria y a las correspondientes mscaras de esta tabla de encaminamiento, se obtiene una direccin de red no conocida (no registrada en dicha tabla de encaminamiento), transmitindose la unidad de datos (datagrama IP) a un router vecino (RUTA o puerta de enlace = 128.1.1.1) y por el interfaz (o puerta de salida) 128.1.1.2. Se recuerda que el campo de RUTA (o puerta de enlace en Windows) indica la mquina que debe tratar el encaminamiento del datagrama IP. Esta mquina es la misma en encaminamientos directos o un router en encaminamientos indirectos o por omisin. DESTINO = 127.0.0.0: Es un encaminamiento DIRECTO por s mismo (RUTA o puerta de enlace = 127.0.0.1) y por el interfaz o puerta de salida 127.0.0.1 hacia una mquina ficticia (127.x.x.x) en donde se est ejecutando el correspondiente proceso servidor, mquina que tambin est conectada a la red ficticia de bucle 127.0.0.0. Como ya se ha sealado, esta entrada en la tabla de encaminamiento permite desarrollar aplicaciones cliente-servidor en pruebas de desarrollo sin penalizar el trfico por una red fsica determinada. Asimismo, se recuerda que esta direccin tambin se emplea para autochequeos, pruebas y comprobaciones de software. Segn esto ltimo, esta entrada permite comprobar, por ejemplo, si el proceso servidor de terminal remoto (telnet) est activo (p.ej., telnet 127.0.0.1). DESTINO = 128.1.1.0: Es un encaminamiento DIRECTO por s mismo (RUTA o puerta de enlace = 128.1.1.2) y por el interfaz o puerta de salida 128.1.1.2 hacia una mquina de la red 128.1.1.0. DESTINO = 128.1.2.0: Es un encaminamiento INDIRECTO a un router vecino (RUTA o puerta de enlace = 128.1.1.1) y por el interfaz o puerta de salida 128.1.1.2 hacia una mquina de la red 128.1.2.0. DESTINO = 128.1.1.2: Es un acceso a la misma mquina por la RED DE BUCLE. La mquina A encamina DIRECTAMENTE por s misma (RUTA o puerta de enlace = 127.0.0.1) y por el interfaz o puerta de salida 127.0.0.1. La direccin 127.0.0.1 es la direccin que, por ejemplo (los tres ltimos octetos
- 95 -
pueden tener cualquier valor), tiene esta mquina para esa red ficticia o de bucle cuya direccin es, a su vez, la 127.0.0.0. La MSCARA asociada est toda a unos (255.255.255.255) porque se utilizan todos los bits de la direccin de destino. Asimismo, esta entrada en la tabla de encaminamiento permitira comprobar, por ejemplo, si el proceso servidor de terminal remoto (telnet) est activo (p.ej., telnet 128.1.1.2). DESTINO = 128.1.255.255: Es una DIFUSIN DIRIGIDA a todas las subredes con un prefijo comn de 2 octetos (128.1) como 128.1.1.0, 128.1.2.0, 128.1.3.0, ..., procedente de la mquina A que encamina DIRECTAMENTE por s misma (RUTA o puerta de enlace = 128.1.1.2) y por el interfaz o puerta de salida 128.1.1.2. Se recuerda que para permitir esta difusin, todas estas subredes tienen una mscara de direccin de subred asociada de 255.255.255.0 (ojo!, no confundirla con la mscara de difusin 255.255.255.255). DESTINO = 224.0.0.0: Es una MULTIDIFUSIN a cualquier miembro activo de cualquier grupo en Internet que encamina DIRECTAMENTE la mquina A por s misma (RUTA o puerta de enlace = 128.1.1.2) y por el interfaz o puerta de salida 128.1.1.2. Para permitir este tipo de transmisin la mscara debe ser 240 (1111 0000). 0.0.0 ya que una direccin de multidifusin debe comenzar por 224 (1110 0000). Asimismo, dicha mscara permite diferenciar una hipottica direccin de la clase E. DESTINO = 255.255.255.255: Es una DIFUSIN LIMITADA o restringida procedente de la mquina A que encamina DIRECTAMENTE por s misma (RUTA o puerta de enlace = 128.1.1.2) y por el interfaz o puerta de salida 128.1.1.2, nicamente a todas las mquinas de la red local de acceso (128.1.1.0). La MSCARA asociada est toda a unos (255.255.255.255) porque se utilizan todos los bits de la direccin de destino.
organizacin
Router 1
A)
Internet
Red Interna
S1 S2 Router 1
B)
Internet
S3
S4
S5 S6
Figura 2.62.- Ejemplo del tpico router centralizado de una organizacin.
- 96 -
Es importante resaltar dentro del contexto de las tablas de encaminamiento, que cuando se crean subredes en una organizacin, su router debe tener tantas lneas, direcciones numricas y entradas en la tabla de encaminamiento como subredes se hayan creado (ver anterior Figura 2.62).
S1
Router 1
S2 S3 S4 S5
B)
Internet
S1
R1
S6
Destino Ruta
Destino
C)
Internet
Ruta
R2
S1 S2 S3 S4 S5 S6
OMISIN
DIR DIR R2 R2 R2 R2 ...
S4 S5
S3
R3
DIR DIR DIR R2
Destino
Ruta
S2
S6
OMISIN
S2 S3 S4 S5 S6
OMISIN
DIR DIR DIR R3 R3 R1

S4
S5
S6
Figura 2.63.- Anidamiento de routers y subredes. Una alternativa al escenario comentado es a travs de un anidamiento de routers y subredes como se muestra en la Figura 2.63. Consecuentemente, para evitar depender de un solo router y que ste se encargue de todas las tareas de encaminamiento de la organizacin, se puede emplear ms de uno, distribuyendo entre ellos todas las subredes. Cada router en su tabla contendr, como informaciones ms significativas, las direcciones de las subredes que conoce (Destino) y el tipo de acceso directo, indirecto o por omisin. Se asume que el router ms externo (R1) contendr ms informacin que el ms interno (R3). Incluso el router ms externo de la organizacin (R1) dispondr de una direccin por omisin a otro router vecino y superior en la jerarqua Internet para cualquier direccin externa a la organizacin. Se recuerda que una mquina es vecina de otra cuando est conectada a la misma red que la considerada.
- 97 -
2.13 Superredes Routing)
CIDR
(Classless
Internet
Domain
Problemas:
Inflexible la divisin del espacio de direcciones Internet o IPv4 en clases A, B y C:
Terminacin del espacio de direcciones Internet o IPv4
Aumento del tamao en las tablas de encaminamiento y de la informacin que se ha de intercambiar
Soluciones:
Asignar ms direcciones de red de clase C en vez de una sola de clase B: SUPERREDES. RFC-1338 Reducir la informacin de encaminamiento que los routers almacenan e intercambian: CIDR (Encaminamiento entre Dominios sin Clase). RFC-1518, 1519
Figura 2.64.- Soluciones a los problemas de direccionamiento IPv4. La experiencia ha demostrado que la divisin del espacio de direcciones numricas en clases A, B y C ha resultado ser bastante inflexible e ineficiente en muchos casos. Hay que tener en cuenta que muchas organizaciones utilizan ineficientemente los bits para identificar mquinas en las direcciones de red de la clase B, mientras que muchas otras necesitan ms direcciones para identificar sus computadoras que las que proporciona una direccin de red de la clase C. Si una organizacin que slo necesita unos cientos o unos pocos miles de direcciones de mquina, dispone de una direccin de la clase B (65.534 mquinas), se desperdician muchas direcciones. Por otra parte, si se le asigna una nica direccin de la clase C (254 mquinas) puede que no tenga suficientes bits para identificar sus mquinas. Sera preferible, y mucho ms ptimo, asignar a las mquinas de las distintas organizaciones el nmero de bits que realmente necesiten. Asimismo, si se hubiera asignado una direccin de red de la clase B (16.384 redes) a cada organizacin que necesite conectar ms de 254 mquinas, se habra agotado el espacio de direcciones de IP, debido al rpido crecimiento de Internet. Esto ltimo todava supone un caso ms extremo con las direcciones de red de la clase A (126 redes). Para evitar terminar con el espacio de direcciones de IP de la clase B y poder hacer un uso ms ptimo del espacio de direccionamiento en funcin del nmero de mquinas que, en realidad, se desea conectar; se ha creado el concepto de SUPERRED que se basa en una tcnica que permite combinar un conjunto variable de direcciones numricas contiguas de una clase (bsicamente de la clase C) en una misma direccin de esa clase para disponer de un espacio de direccionamiento superior sin necesidad de solicitar una direccin de rango superior (bsicamente de la clase B).
- 98 -
Por otro lado, si aumenta el nmero de redes de la clase C, provocara aumentar el nmero de entradas en las correspondientes tablas de encaminamiento de las mquinas de la organizacin e incluso de otras organizaciones. Asimismo, esto provocara tambin un aumento muy significativo en el intercambio dinmico de la informacin de encaminamiento en la misma organizacin y con respecto a otras. Consecuentemente, asignar muchas direcciones de la clase C en vez de una sola de la clase B, conserva las direcciones de la clase B y resuelve el problema inmediato de la terminacin del espacio de direcciones. Sin embargo, crea un nuevo problema: la informacin que los routers almacenan e intercambian aumenta dramticamente. Por todo lo anterior, en 1993 se elimin la restriccin del espacio de direcciones con clase, adoptndose un esquema en el que se utiliza una longitud de prefijo comn arbitraria para indicar la direccin comn de red de un bloque de direcciones de red contiguas, que se quieren resumir en una sola direccin de red. Este esquema o notacin o formato se conoce como encaminamiento entre dominios sin clase (CIDR) como alternativa al direccionamiento IP con clase. Por consiguiente, el concepto de clase A, B y C desaparece al usar prefijos diferentes a los prefijos obligatorios de dichas clases. Resumiendo, CIDR es una implementacin mediante una notacin del concepto de superred para evitar que aumente el tamao de las tablas de encaminamiento y el intercambio dinmico de la informacin de encaminamiento entre routers cuando se utilicen direcciones de la clase C. Consecuentemente, mediante el esquema CIDR se intenta superar el formato tradicional de direcciones de clases representado por un modelo jerrquico de direccionamiento esttico en dos niveles (redes y mquinas). Por consiguiente, CIDR represent un paso evolutivo que iba ms all de las tradicionales direcciones numricas con clase, esto es, redes de las clases A, B y C. El esquema o notacin o formato CIDR resume un grupo de direcciones contiguas, bsicamente, de la clase C en una sola direccin de red de la clase C y, por tanto, en una sola entrada en la tabla de encaminamiento. Para ello, se maneja una notacin en funcin de los siguientes dos parmetros: (direccin de red/longitud) en donde: Direccin de red: Representa la direccin ms baja del bloque o grupo contiguo de direcciones de IP que se quieren resumir en una nica direccin de destino o entrada en la tabla de encaminamiento. Longitud: Indica el nmero de bits que delimitan la mscara CIDR (o de prefijo o superred), que definen el prefijo comn formado por un nmero de bits contiguos y comunes, situados ms a la izquierda, y que comparten todas las - 99 -
direcciones de red del bloque de direcciones adyacentes que se desean resumir en una sola direccin. Dicho de otra forma, define el nmero de bits que se van a usar como prefijo comn del bloque contiguo de direcciones, cuya primera direccin es la direccin de red especificada (primer parmetro). En funcin de la mscara natural o por omisin, ste parmetro determina, a su vez, el bloque CIDR o nmero de direcciones de red contiguas que conforman el bloque o grupo de direcciones que se desea resumir en una sola direccin de red.
Formato CIDR = (220.1.0.0/22) = (220.1.0.0, 255.255.252.0)
Prefijo comn de 22 bits de longitud
220.1.0.0 = 11011100.00000001.00000000 .00000000

Mscara por omisin Mscara de superred = =
Mscara natural o por omisin
11111111.11111111. 11111111 .00000000

Mscara CIDR o de superred o de prefijo
11111111.11111111. 111111 xx .00000000

Bloque CIDR = 2 bits = 22 = 4 redes contiguas
220.1.0000 00xx.0 xx = 00 = 0; xx = 01 = 1 xx = 10 = 2; xx = 11 = 3
220.1.0.0; 220.1.1.0 220.1.2.0; 220.1.3.0
Una red se denomina SUPERRED cuando la mscara CIDR contiene menos bits que la mscara por omisin de la red.
Figura 2.65.- Ejemplo de formato y bloque CIDR. Como se puede comprobar en la Figura 2.65: Bloque CIDR = mscara por omisin mscara CIDR En donde la mscara CIDR es un nmero de 32 bits que contiene unos en los bits que identifican la direccin o prefijo comn de red del bloque de direcciones contiguas que se desea resumir. Si el bloque CIDR = 0, es porque la mscara por omisin es igual a la mscara de prefijo y, por tanto, la mscara est denotando una sola direccin de red. En el ejemplo de la Figura 2.65, se dispone del siguiente formato CIDR: Formato CIDR = (220.1.0.0/22) = (220.1.0.0, 255.255.252.0) Ambas notaciones (220.1.0.0/22) y (220.1.0.0, 255.255.252.0) son representaciones equivalentes del bloque CIDR.
- 100 -
En este ejemplo se utiliza una longitud de prefijo de 22 bits (/22) que son los 22 bits a unos de la mscara CIDR que definen un prefijo comn de 22 bits y que es equivalente en tamao a cuatro redes de la clase C. Como se ya se indic, en funcin de la mscara por omisin, la mscara CIDR define el nmero de bits que se va a utilizar para identificar las distintas direcciones de red del correspondiente bloque contiguo de direcciones que se desea resumir. En el ejemplo, Bloque CIDR = 24 bits (clase C) 22 bits = 2bits = 22 = 4 direcciones de redes contiguas. Asimismo, todas ellas tienen como prefijo comn: 11011100.00000001.000000xx. Una mscara CIDR aplicada a una direccin de red de la clase C (cuya mscara por omisin es siempre 255.255.255.0) significa que nicamente del tercer octeto se van a usar correlativamente y de forma contigua todos los bits cubiertos por la mscara por omisin y que no cubre la mscara CIDR. Por consiguiente, Direccin de superred = Prefijo comn (11011100.00000001.000000) + Bloque CIDR (xx). 220.1.0000 00xx.0 xx = 00 = 0 (decimal) = 220.1.0.0 xx = 01 = 1 (decimal) = 220.1.1.0 xx = 10 = 2 (decimal) = 220.1.2.0 xx = 11 = 3 (decimal) = 220.1.3.0 Este formato proporciona un mecanismo para reunir fcilmente todas las rutas ms especficas (220.1.0.0, 220.1.1.0, 220.1.2.0 y 220.1.3.0) definidas por la notacin 220.1.0.0/22, en una publicacin denominada agregada. Es fcil confundirse debido a la terminologa, especialmente porque los trminos agregado, bloque CIDR y superred, a menudo, se utilizan indistintamente. Generalmente, todos estos trminos indican que un grupo de redes IP contiguas se han resumido en una publicacin de ruta. Todas las redes que son un subconjunto de un agregado o bloque CIDR son conocidas como ms especficas porque proporcionan ms informacin sobre la ubicacin de una red. Esta tcnica de agregar rutas ha provocado una reduccin significativa en el crecimiento de las tablas de encaminamiento. Sin la implementacin de CIDR, el tamao de las tablas de encaminamiento en el ncleo de Internet hubiera superado varios cientos de miles de rutas.
- 101 -
Una red se denomina SUPERRED cuando la mscara CIDR contiene menos bits que la mscara por omisin de la red. Es decir, con una mscara ms corta que la mscara natural (22 es menor que 24), la red se define como superred. Por tanto, cuando una entidad IP detecte lo anterior en una entrada de la tabla de encaminamiento, sabe que no est ante una direccin de red sino, ante una direccin de superred (prefijo comn + bloque CIDR) que resume un bloque de direcciones adyacentes de red. Consecuentemente, las mquinas (de usuario y routers) que usan el direccionamiento de superred necesitan un software de encaminamiento no convencional que entienda los correspondientes rangos de direcciones.
I)
...
R2 R1 Organizacin
Direccin oficial IP: 140.100.0.0

N mx = 65.534 mquinas
...
Diestino Mscara Ruta 140.100.0.0, 255.255.0.0 R1 ...
...
(140.100.0.0, 255.255.0.0)
La organizacin desea conectar slo 1016 mquinas como mximo
II)
...
R2
1
Asignacin de redes contiguas
220.1.0.0 = 254 mquinas R1

1 2 3 4
220.1.1.0
= 254 mquinas
220.1.2.0 = 254 mquinas
Diestino Mscara Ruta Interfaz 220.1.0.0, 255.255.255.0 R1 1 220.1.1.0, 255.255.255.0 R1 1 220.1.2.0, 255.255.255.0 R1 1 220.1.3.0, 255.255.255.0 R1 1 ...
(220.1.0.0, 255.255.255.0) (220.1.1.0, 255.255.255.0) (220.1.2.0, 255.255.255.0) (220.1.3.0, 255.255.255.0)
220.1.3.0
= 254 mquinas
Figura 2.66.- Ejemplo de asignacin de redes contiguas. En la anterior Figura 2.66 se muestra la ineficiencia y falta de flexibilidad en la divisin del espacio de direcciones de IP en clases A, B y C. En la situacin I, del ejemplo, una organizacin desea conectar 1016 mquinas y se le ha asignado la direccin de IP oficial de la clase B: 140.100.0.0. A una direccin de red de la clase B se la pueden conectar 65.534 mquinas como mximo. Teniendo en cuenta que se desean conectar como mximo 1016 mquinas, sobran pues 64.510 potenciales direcciones, lo cual supone todo un desperdicio. Posteriormente, y suponiendo un encaminamiento dinmico (que ya se estudiar), R1 informa a R2 del nuevo destino 140.100.0.0. En la situacin II, (Asignacin de redes contiguas) del ejemplo, mediante el concepto de superred, se asigna a la organizacin cuatro direcciones contiguas de red de la clase C (4 x 254 = 1016). De esta forma, no se pierde una direccin de la clase B y el espacio de direccionamiento (mediante redes contiguas de la clase C) est ms aprovechado. Seguidamente, y suponiendo un encaminamiento dinmico (que ya se estudiar), R1 enva a R2 toda la informacin de encaminamiento con respecto a estas cuatro redes - 102 -
creadas. Con esta informacin R2 actualiza su correspondiente tabla, la cual ir creciendo a medida que vaya conociendo nuevos destinos procedentes de otros routers vecinos.
II)
R2 Asignacin de redes contiguas
1
220.1.0.0 = 254 mquinas R1

1 2 3 4
220.1.1.0
= 254 mquinas
...
Destino Mscara Ruta Interfaz 220.1.0.0, 255.255.255.0 R1 1 220.1.1.0, 255.255.255.0 R1 1 220.1.2.0, 255.255.255.0 R1 1 220.1.3.0, 255.255.255.0 R1 1 ...
220.1.2.0 = 254 mquinas
(220.1.0.0, 255.255.255.0) (220.1.1.0, 255.255.255.0) (220.1.2.0, 255.255.255.0) (220.1.3.0, 255.255.255.0)
220.1.3.0
= 254 mquinas
III)
R2
Superred con CIDR
R1
Diestino Mscara Ruta Interfaz 220.1.0.0, 255.255.255.0 Dir 1 220.1.1.0, 255.255.255.0 Dir 2 220.1.2.0, 255.255.255.0 Dir 3 220.1.3.0, 255.255.255.0 Dir 4
Destino Mscara Ruta Interfaz 220.1.0.0, 255.255.252.0 R1 1 ...
(220.1.0.0/22)
Figura 2.67.- Ejemplo de formato CIDR. En la situacin II, (Asignacin de redes contiguas) del ejemplo, se muestra el inconveniente, de tener que enviar ms informacin (ms direcciones de redes) de encaminamiento a los routers vecinos o contiguos. Consecuentemente, las tablas de encaminamiento aumentan en la misma medida. Segn se ha comentado con anterioridad, para solventar este ltimo problema se ha diseado el formato CIDR (situacin III de la Figura 2.67) que permite resumir un grupo de direcciones contiguas, bsicamente, de la clase C en una sola entrada en la tabla de encaminamiento con el objetivo de disminuir tanto el tamao de los mensajes con la informacin de encaminamiento como las mismas tablas de encaminamiento. La utilizacin de prefijos de longitud variable requiere que se busque en las tablas, entradas con el prefijo ms grande. Por ejemplo, una tabla de encaminamiento puede contener entradas para la superred del ejemplo, como las siguientes: 220.1.0.0/22 220.1.0.0/16. Un datagrama con direccin de destino de 220.1.1.1 produce una coincidencia en ambas entradas, de forma que el algoritmo debe seleccionar la coincidencia con el prefijo ms grande. Las tablas de encaminamiento pueden contener decenas de miles de entradas; entonces, para desarrollar dispositivos de encaminamiento rpidos se necesitan algoritmos rpidos y eficientes que busquen coincidencias con los prefijos ms grandes. En este contexto, se han implementado varios de estos algoritmos para routers rpidos.
- 103 -
2.14 Agotamiento del espacio de direcciones en Internet

Agotamiento de direcciones de la clase B:
Asignacin de direcciones de red IP: Asignacin de redes contiguas de clase C Superredes y CIDR: Combinacin de redes contiguas de clase C en una misma direccin de clase C
Agotamiento de cualquier direccin:

Direccionamiento IP privado y Traduccin de Direcciones de red (NAT: Network Address Traslation y PAT: Port and Address Translation) IP versin 6 (IPv6)
Figura 2.68.- Agotamiento del espacio de direcciones en Internet. La creciente demanda de direcciones numricas ha supuesto un problema en el modelo con clase. La mayora de las empresas que solicitan direcciones de red de la clase B han determinado que una direccin de clase B se ajustara mejor a sus necesidades por el equilibrio entre el nmero de redes y el nmero de mquinas que ofrece. En este contexto, una direccin de clase A suele ser excesiva, con ms de 16 millones de mquinas, y una de clase C tiene muy pocas mquinas por red. Hacia 1991, comenzaba a ser obvio que el consumo de direcciones de la clase B no estaba disminuyendo y era necesario tomar medidas para evitar su agotamiento. Entre las medidas propuestas se destacan las siguientes: AGOTAMIENTO DE DIRECCIONES DE LA CLASE B.- Soluciones: a. Asignacin consecutiva de direcciones de red IP de la clase C: Menos de 256 direcciones = 1 red de clase C Menos de 512, pero ms de 256 direcciones = 2 redes contiguas de clase C Menos de 1.024, pero ms de 512 direcciones = 4 redes contiguas de clase C Menos de 2048, pero ms de 1024 direcciones = 8 redes contiguas de clase C Menos de 4.096, pero ms de 2.048 direcciones = 16 redes contiguas de clase C - 104 -
Menos de 8.192, pero ms de 4.096 direcciones = 32 redes contiguas de clase C Menos de 16.384, pero ms de 8.192 direcciones = 64 redes contiguas de clase C b. Superredes y CIDR: Como ya se ha descrito con anterioridad, el concepto de superred basado en la notacin CIDR, se fundamenta en una combinacin de un conjunto de direcciones de IP contiguas de la clase C en una misma direccin de esa clase para disponer de un espacio de direccionamiento superior sin necesidad de solicitar una direccin de rango superior de la clase B para dicha organizacin. El objetivo es evitar que se agoten las direcciones de clase B y reducir el almacenamiento e intercambio de informacin de encaminamiento. AGOTAMIENTO DE CUALQUIER DIRECCIN.- Soluciones: c. Direccionamiento IP privado y Traduccin de direcciones de red (NAT y PAT): La mayora de las necesidades de conectividad de las organizaciones encajan en las siguientes categoras: Conectividad global: Todas las mquinas y redes de la organizacin disponen de direcciones numricas oficiales. Por tanto, las mquinas dentro de una organizacin tienen acceso tanto a mquinas internas como a mquinas externas de Internet. En este caso las mquinas tienen que configurarse con direcciones de IP globalmente nicas que sean reconocidas dentro y fuera de la organizacin. Las organizaciones que requieran conectividad global deben solicitar direcciones de IP a sus proveedores de servicio (ISP). Conectividad privada: Todas las mquinas y redes de la organizacin disponen de direcciones numricas privadas que se puede compartir con otras organizaciones y que por seguridad y privacidad se traducen por direcciones oficiales va NAT y PAT cuando se accede al exterior. Las mquinas privadas necesitan poseer direcciones de IP que sean nicas dentro de la organizacin. Para este tipo de conectividad, IANA (RFC-1918) ha reservado, para redes privadas, los tres bloques siguientes del espacio de direcciones de IP; lo que se conoce como internets privadas. Estos bloques son los siguientes:
- 105 -
10.0.0.0 hasta 10.255.255.255 (una nica direccin de red de clase A) 172.16.0.0 hasta 172.31.255.255 (16 direcciones de red contiguas de clase B) 192.168.0.0 hasta 192.168.255.255 (256 direcciones de red contiguas de clase C)
Consecuentemente, existen 2 tipos de direcciones, aqullas que son propias de Internet (oficiales o debidamente registradas para una conectividad global) y, por tanto, no pueden repetirse y otras reservadas (no registradas) para redes privadas (conectividad privada) que admiten la misma direccin en redes diferentes no conectadas entre s. Las mquinas que obtienen una direccin privada pueden conectarse a cualquier otra mquina de la organizacin sin pasar a travs de un dispositivo intermediario que haga de representante (proxy). Teniendo en cuenta que muchas organizaciones que construyen redes privadas pueden utilizar la misma direccin de IP privada, pocas direcciones de IP globales nicas necesitan ser asignadas. En este escenario, las mquinas que tengan direcciones privadas pueden coexistir con mquinas que tienen direcciones globales. Las organizaciones pueden elegir convertir en privadas la mayora de sus mquinas y mantener segmentos particulares con mquinas que tengan direcciones globales. Las organizaciones que migran de una direccin privada a un espacio de direcciones global pueden hacerlo con la ayuda de la tecnologa de un traductor de direcciones de red o NAT (RFC-1631). Un router NAT se coloca en la frontera del dominio de una organizacin, es decir, es el router ms externo o de salida de dicha organizacin. Su misin es traducir las direcciones privadas en direcciones globales oficiales, y viceversa cuando las mquinas internas necesitan comunicarse con destinos en Internet. Por tanto, un router NAT trabaja exclusivamente en el nivel de red realizando la traduccin de las direcciones de origen de los datagramas IP salientes y las direcciones de destino de los datagramas IP entrantes. Esta traduccin puede ser de dos clases: Dinmica: De un conjunto de direcciones interiores o locales a un conjunto de direcciones exteriores (u oficiales o registradas o globales). Lgicamente, este tipo de traduccin se utiliza para aquellas mquinas que no desean estar visibles desde el exterior. Consecuentemente, ahorra en direcciones oficiales.
- 106 -
Esttica (fija o manual): De direcciones interiores o locales a direcciones exteriores o globales. Este tipo de traduccin se utiliza para aquellas mquinas (servidores) que necesitan estar visibles desde el exterior. Otro tipo de software es el basado en un traductor de puertos (el concepto de puerto ya se estudiar ms adelante) y direcciones de red o PAT. Un router PAT, al igual que un router NAT, se sita en el lmite de una organizacin. Su objetivo consiste en traducir las direcciones privadas y nmeros de puerto privados en direcciones exteriores y nmeros de puerto exteriores, y viceversa cuando las mquinas internas necesitan comunicarse con destinos en Internet. Un router PAT puede representar con una sola direccin exterior u oficial, 65.535 mquinas asociando la direccin interna y nmero de puerto interno con una direccin externa y un nmero de puerto externo. Por consiguiente, un router PAT trabaja en el nivel de red y transporte. d. IP versin 6: Con las tcnicas anteriores se dispone de muchas ms direcciones que hace aos en Internet; sin embargo el problema se presenta con el uso creciente de los protocolos TCP/IP en nuevas reas (terminales electrnicos de puntos de venta en los comercios, receptores de TV y vdeo bajo demanda, electrodomsticos, telefona mvil, porttiles inalmbricos, etc.) que demandan direcciones de IP nicas. Consecuentemente, se necesita un espacio de direccionamiento superior y aqu juega un papel fundamental el protocolo IP en su nueva versin 6. IPv6 conserva y adapta el protocolo IPv4 buscando una mayor frexibilidad y rapidez en futuros encaminamientos por Internet. Concretamente, en el tema del direccionamiento se pasa de 4 a 16 octetos. Esto da origen a 2128 = 3,4 x 1038 mquinas, es decir, aproximadamente 340 cuatrillones de direcciones; si se asignara 1 milln de direcciones cada milisegundo, se tardara unos 20 aos en asignar todas las direcciones.
- 107 -
2.15 Arquitectura TCP/IP: Niveles y unidades de datos

Segn se muestra en la Figura 2.69, la arquitectura de comunicaciones TCP/IP se basa en una tcnica de estructuracin o estratificacin en cinco niveles de comunicaciones:
DATOS
APLICACIN
TRANSPORTE
mensaje
DATOS DATOS
segmento (TCP) y datagrama (UDP)
INTERNET
RED DE ACCESO
datagrama (IP)
DATOS
trama
DATOS
Figura 2.69.- Niveles y unidades de datos de la arquitectura TCP/IP. Nivel de Aplicacin: Aqu se ubican las entidades de software o programas o procesos o protocolos o servicios (transferencia de ficheros o FTP, correo electrnico o SMTP, navegacin Web o HTTP, etc.) con los que interacta directamente el usuario. Las unidades de datos manejadas por cualquier entidad del nivel de aplicacin se denominan mensajes y constan de una cabecera de informacin de control propia de la aplicacin correspondiente y unos potenciales (si existen) datos de usuario. Nivel de Transporte: Aqu se sitan dos entidades de software o protocolos denominados: TCP (Transmission Control Protocol) y UDP (User Datagram Protocol). La entidad del nivel de transporte, TCP o UDP, acepta en el sistema emisor los mensajes de aplicacin y los segmenta, si es el caso, en unas unidades ms pequeas a las cuales aade unas cabeceras de informacin de control que incluyen, entre otras informaciones, cdigos (nmeros de puerto) que identifican los procesos de aplicacin extremo a extremo. La unidad de datos resultante se denomina segmento TCP o segmento para el caso del protocolo TCP, y datagrama UDP o datagrama en el caso del protocolo UDP. Si el servicio ofrecido por el nivel de transporte es orientado a conexin, caso del protocolo TCP, se establece una conexin extremo a extremo entre dos entidades TCP entre la mquina de origen y la mquina de destino por donde fluyen, posteriormente, de manera ordenada todos los segmentos de informacin. En este tipo de servicio TCP, el nivel de transporte se encarga de la fiabilidad de la - 108 -
comunicacin extremo a extremo, independientemente de la tecnologa, topologa, nmero y tipo de redes que hayan intervenido. Por tanto, hay todo un control de errores fsicos (deteccin y recuperacin de segmentos que han cambiado fsicamente en algn bit) y lgicos (deteccin y recuperacin de segmentos perdidos, desordenados y duplicados). Asimismo, hay un control de flujo entre entidades TCP para impedir que una entidad transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Si el servicio ofrecido por el nivel de transporte no es orientado a conexin, caso del protocolo UDP, no se establece ninguna conexin extremo a extremo entre las dos entidades UDP. Consecuentemente, cada datagrama UDP se trata como una unidad independiente y se enva aisladamente de las dems. Por consiguiente, no se mantiene ningn tipo de control de errores (slo hay una deteccin de errores fsicos sin recuperacin) ni de flujo. Esto quiere decir, que los datagramas UDP pueden no llegar y en el caso de llegar, hacerlo de forma desordenada o duplicada. Es importante resaltar que a partir de este nivel todas las comunicaciones son extremo a extremo ya que no va a intervenir nunca una entidad TCP o UDP en el camino entre las dos entidades de transporte origen/destino. Nivel de Red o Internet: Fundamentalmente, aqu se ejecuta una entidad o protocolo que se denomina IP (Internet Protocol). La entidad del nivel de Internet o entidad IP acepta segmentos TCP o datagramas UDP del nivel de transporte y les aade una cabecera. La unidad de datos resultante se denomina datagrama IP o datagrama. A veces, los datagramas IP se denominan paquetes IP o paquetes para evitar la confusin con los datagramas UDP. Por intentar seguir la terminologa estandarizada en los documentos RFC, cuando haya una referencia a las unidades de datos del protocolo UDP, se utilizar expresamente el trmino datagrama UDP. En el caso de las unidades de datos del protocolo IP, se utilizarn indistintamente los trminos datagrama IP o datagrama. Posteriormente, este nivel encamina estos datagramas a travs de Internet usando un algoritmo y una tabla de encaminamiento para saber si el datagrama lo enva directamente a su propia red o lo pasa al router contiguo o vecino. Este nivel, ofrece siempre un servicio no orientado a conexin. Consecuentemente, no se mantiene ningn tipo de control de errores (slo hay una deteccin de errores fsicos sin recuperacin) ni de flujo. Se asume, por tanto, que si un datagrama se pierde, ser el protocolo TCP del nivel de transporte el encargado de su recuperacin (ya que ese datagrama encapsula un segmento TCP). Si la pertinente aplicacin est montada sobre UDP, sern los mecanismos fiables de la aplicacin en cuestin quienes lleven a cabo la citada recuperacin. Es importante resaltar que cada segmento TCP o datagrama UDP se encapsula en un nico datagrama IP. Aunque en este nivel, como ya se - 109 -
estudiar, existen ms protocolos; el protocolo IP es el protocolo clave o por excelencia del nivel en cuestin. Como ya se ha comentado, a una direccin de Internet o numrica, tambin se le suele denominar direccin IP. En el caso de los routers o sistemas intermedios, generalmente, este nivel es el ltimo de la arquitectura TCP/IP ya que se asume que no se ejecutan procesos de usuario y, por tanto, en un principio no se necesitan los niveles de aplicacin y transporte. Nivel del Interfaz de la Red de Acceso: Este es el nivel de software ms bajo de la arquitectura TCP/IP, el cual responsable de aceptar datagramas IP y de aadirles una cabecera de informacin de control para su transmisin a travs de una red de acceso especfica. A la unidad resultante se le denomina trama y cada trama encapsula un nico datagrama IP. Nivel Fsico o de Hardware: Define las caractersticas fsicas (tipo de conectores, nmero de pines, etc.) elctricas (tensin o voltaje en los cables) y funcionales (seales intercambiadas con el correspondiente dispositivo transmisor) para acceder al medio fsico de interconexin (red de acceso). En este nivel no se incluye ningn tipo de software. Se destaca, que aunque la arquitectura TCP/IP est formada por muchos protocolos y no slo por TCP (nivel de transporte) e IP (nivel Internet o de red); stos dos protocolos por su relevancia, dan nombre a toda la arquitectura de comunicaciones.
SISTEMA
A
mensajes
SISTEMA
APLICACIN TRANSPORTE INTERNET INTERFAZ DE RED

tramas
APLICACIN
TRANSPORTE INTERNET
segmentos
datagramas UDP
Datagramas IP
INTERFAZ DE RED
RED
tramas
Figura 2.70.- Comunicacin entre niveles de sistemas contiguos. La Figura 2.70 muestra dos mquinas o sistemas finales de usuario que se conectan a una misma red. El principio de estructuracin o estratificacin en niveles se disea de tal manera que el nivel n en el destino reciba exactamente la misma unidad de datos enviada por el nivel n en el origen.
- 110 -
SISTEMA A
APLICACIN
SISTEMA
mensajes
APLICACIN
TRANSPORTE INTERNET
Segmentos/Datagramas UDP
TRANSPORTE INTERNET
INTERNET
Datagramas IP Datagramas IP
INTERFAZ DE RED
tramas
RED
INTERFAZ DE RED
tramas
RED
INTERFAZ DE RED
ROUTER
Figura 2.71.- Comunicacin entre niveles de sistemas no contiguos. La Figura 2.71 muestra dos sistemas finales no vecinos, es decir, conectados a redes diferentes a travs de un router o sistema intermedio. Si estas redes son diferentes en cuanto a tecnologa, el intefaz de red del router se encargar de realizar un trabajo extra como es llevar a cabo las pertinentes conversiones, extrayendo y encapsulando el contenido del campo de datos de una trama a otra. Por lo dems, las unidades de datos restantes que se intercambian son las mismas a partir del nivel Internet o IP. Se recuerda que en un sistema intermedio o router, las nicas funciones de comunicaciones que se realizan son hasta el nivel de red o encaminamiento ya que se asume que, por regla general, en un sistema intermedio (de ah su nombre) no se ejecutan procesos de usuario y, por tanto, sobran los niveles de aplicacin y transporte (de los mensajes de aplicacin). La siguiente Figura 2.72 muestra una comparativa arquitectnica entre los diferentes mdulos o procesos TCP/IP y los niveles conceptuales TCP/IP y OSI. La arquitectura OSI (a excepcin de los protocolos X.2554) se utiliza como una referencia estandarizada para la descripcin conceptual de los niveles de comunicaciones de una determinada arquitectura de comunicaciones, facilitando la comprensin de sta. En este contexto, en el nivel de aplicacin se ubican los diferentes procesos de usuario (terminal remoto o telnet, transferencias de ficheros o ftp, correo electrnico o smtp, web o http, etc.). En el nivel de transporte estn las entidades o protocolos o servicios de transporte TCP y UDP. En el nivel de red, fundamentalmente, el protocolo IP. Se observa que el nivel de red OSI es mayor que el nivel de red TCP/IP porque en OSI estn definidos servicios
54
La normativa X.25 define una red de conmutacin de paquetes en funcin de los tres primeros niveles de OSI.
- 111 -
orientados a conexin y sin conexiones. En TCP/IP solo hay un servicio no orientado a conexin a nivel de red. El interfaz de acceso y el hardware (tambin conocidos como nivel de la red de acceso) abarca un poco del nivel de red OSI en el caso de que la red de acceso sea una X.25. Por consiguiente, en el caso de una red X.25, el nivel del interfaz de la red de acceso dispondra, a su vez, de los tres niveles de comunicaciones X.25.
Mdulos TCP/IP
Aplic. Aplic.
Aplic.
TCP/IP
Aplicacin
Aplicacin Presentacin Sesin
OSI
TCP
UDP
Transporte
Transporte Red
Enlace de Datos
IP
Internet Red de Acceso
Interfaz de Red
Hardware
Fsico
Figura 2.72.- Comparativa arquitectnica. A su vez, en la siguiente Figura 2.73 se muestran los niveles de comunicaciones de dos sistemas finales interconectados a travs de tres redes fsicas y dos routers.
APLICACIN
APLICACIN
TCP IP
INTERFAZ DE RED
INTERFAZ DE RED
TCP
IP
INTERFAZ DE RED
INTERFAZ DE RED
IP
INTERFAZ DE RED
IP
INTERFAZ DE
RED
Figura 2.73.- Comunicacin entre los diferentes niveles TCP/IP.
- 112 -
INTERNET
ICMP
Protocolo ROUTERS AVANZADOS (OSPF)
IGMP IP
RED DE ACCESO
PPP ARP
Interfaz de Red
SLIP RARP
Hardware
Figura 2.74.- Niveles inferiores de la arquitectura TCP/IP. La Figura 2.74 muestra con ms detalle los niveles inferiores de la arquitectura TCP/IP que se corresponden con los niveles: Internet y red de acceso. Nivel de Internet o red: Aparte del protocolo principal IP, tambin se encuentran en este nivel los siguientes protocolos: ICMP (Internet Control Message Protocol): Es el protocolo de envo de mensajes de control en Internet. Por ejemplo, cuando algo sospechoso ocurre con un datagrama, el protocolo ICMP se encarga de notificar el evento a la mquina de origen del datagrama en cuestin (p. ej., a travs del mensaje DESTINO INALCANZABLE, se indica que un router no logra localizar el destino). Los mensajes ICMP viajan en Internet en el campo de datos de los datagramas IP. Protocolos entre routers avanzados: Son los protocolos utilizados entre routers para distribuir y actualizar de forma dinmica la informacin de las tablas de encaminamiento. El objetivo de estos protocolos es no tener que actualizar manualmente55 las tablas de los routers de una organizacin ante potenciales cambios en cuanto a subredes o mquinas en dicha organizacin. Dependiendo del protocolo, y como ya se analizar ms adelante, se emplean diferentes tipos de estrategias de encaminamiento (vector distancia y estado
55
Parando el funcionamiento de las subredes que conforman la red corporativa en cuestin.
- 113 -
del enlace). Al igual que ICMP, los mensajes entre routers avanzados circulan por Internet en el campo de datos de los datagramas IP. Actualmente, OSPF es el protocolo, por excelencia, en este nivel para la distribucin y actualizacin de la informacin de encaminamiento en el escenario de las grandes organizaciones con un nmero elevado de routers. Tanto OSPF como ICMP, aun estando ubicados en el mismo nivel que el protocolo IP, estn situados en un estrato o subnivel superior al ocupado por IP. Todo paquete OSPF como ICMP se encapsula directamente en datagramas IP. IGMP (Internet Group Management Protocol): Protocolo de gestin de grupos en Internet para descubrir mquinas locales que pertenezcan a grupos de multidifusin. Asimismo, todo mensaje IGMP se encapsula directamente en un datagrama IP. Nivel del Interfaz de la Red de Acceso: Es el software de ms bajo nivel de la arquitectura TCP/IP. Aparte del protocolo de acceso a la correspondiente red de acceso (protocolo del interfaz de la red de acceso), tambin se encuentran en este nivel cuatro protocolos: ARP, RARP, SLIP y PPP que aun estando ubicados en el mismo nivel que el protocolo asociado al pertinente acceso al medio fsico de interconexin, estn situados en un estrato o subnivel superior al ocupado por dicho protocolo de acceso. Consecuentemente, todo mensaje ARP, RARP, SLIP y PPP se encapsula directamente en tramas de informacin del protocolo de la correspondiente red de acceso. Es importante resaltar que ARP y RARP se utilizan, nicamente, en redes o subredes de rea local IEEE 802 y que en el formato de la trama de informacin del correspondiente protocolo del nivel de enlace utilizado en dicha red o subred, debe haber un campo que especifique el protocolo superior (ARP o RARP) para el cual son los datos que se transportan en la citada trama de informacin. Por otra parte, SLIP y PPP se usan, a su vez, en lneas serie o punto a punto entre usuarios y proveedores (ISP), y entre routers contiguos.
- 114 -
2.16 Protocolos ARP, RARP, BOOTP y DHCP

TABLA DE ASIGNACIONES (MEMORIA TEMPORAL)
dir IP(B) => dir RAL(B) dir IP(B) => dir RAL(B) dir IP(C) => dir RAL(C) dir IP(C) => dir RAL(C) dir IP(D) => dir RAL(D) dir IP(D) => dir RAL(D) dir IP(E) => dir RAL(E) dir IP(E) => dir RAL(E) dir IP(F) => ? dir IP(F) => ?
RAL IEEE 802 (Red o subred
de rea Local)
Si A quiere comunicarse con F y solo conoce la dir. IP (F), debe obtener dir. RAL (F) A enva un mensaje ARP de solicitud de direccin RALen una trama RAL de difusin a todas las estaciones incluyendo dir. IP(A), dir. RAL(A) y dir. IP(F). F reconoce su dir. IP(F) y enva a A en como respuesta (en un mensaje ARP de respuesta encapsulado en una una trama RAL especfica de informacin ) su dir. RAL(F) que se almacena en la tabla (Cach ARP) de A
Figura 2.75.- Protocolo ARP de resolucin de direcciones. En la Figura 2.75 se muestra la filosofa operativa del protocolo de resolucin de direcciones ARP (ADDRESS RESOLUTION PROTOCOL). Este protocolo hace corresponder una direccin numrica en una direccin fsica o de tarjeta de red o MAC IEEE 802, por ejemplo, la de una red de rea local del tipo Ethernet. Es decir, a partir de una direccin numrica, obtiene una direccin fsica o de tarjeta de red IEEE 802. La idea es simple, si una mquina A quiere comunicarse con otra F, cuya direccin fsica no conoce, el mdulo ARP enva a la red una trama de difusin56 que contiene entre otras informaciones: si es una solicitud o respuesta de ARP, la direccin de IP de la mquina F y las direcciones de IP y de hardware de la mquina A. F reconocer su direccin de IP y enviar nicamente a la mquina A un mensaje de respuesta de ARP encapsulada en una trama especfica de informacin. Esta respuesta de ARP transporta las direcciones de hardware e IP del solicitante original (A) y de la mquina que responde (F). Es importante resaltar que una direccin de IP indica cmo acceder a la red a la cual est conectada una determinada mquina. Pero con una direccin de IP no se puede entrar fsicamente por el hardware de la mquina en cuestin. Para ello, es necesario conocer la direccin fsica de su tarjeta de red, la cual nada tiene que ver con los 4 octetos de la direccin IP de la mquina. Por otro lado, ARP utiliza una memoria
56
Si la red es una Ethernet, la direccin del destinatario est constituida por 48 bits a unos.
- 115 -
temporal57 o voltil local o memoria cach (de RAM) en donde existe una tabla de traducciones o asignaciones de direcciones de IP a fsicas. Esta tabla permite almacenar va ARP todas las direcciones fsicas de mquinas con las que se ha conectado anteriormente. El hecho de que ARP maneje temporalmente esta informacin, es para evitar tener datos de una estacin que falla o es reemplazada o no est operativa o encendida.
dir RAL(A) => dir IP(A) dir RAL(A) => dir IP(A) Servidor RARP dir RAL(B) => dir IP(B) dir RAL(B) => dir IP(B) dir RAL(C) => dir IP(C) dir RAL(C) => dir IP(C) dir RAL(D) => dir IP(D) dir RAL(D) => dir IP(D) dir RAL(E) => dir IP(E) dir RAL(E) => dir IP(E)
de rea Local)
A
dir IP (A) => ? dir IP (A) => ?
RAL IEEE 802 (Red o subred
A es una estacin sin disco que no dispone de su dir IP Se requiere un servidor RARP de direcciones IP A enva un mensaje RARP de solicitud de direccin IP (incluyendo la direccin RAL de A) en una trama RAL de difusin al servidor RARP. El servidor RARP transmite la respuesta a A en un mensaje RARP dentro de una trama RAL especfica de informacin
Figura 2.76.- Protocolo RARP de resolucin de direcciones. La Figura 2.76 muestra, a su vez, la filosofa operativa del protocolo inverso de resolucin de direcciones RARP (REVERSE ADDRESS RESOLUTION PROTOCOL o ARP al revs). Este protocolo como su nombre indica hace todo lo contrario que ARP, al hacer corresponder una direccin fsica o de tarjeta o MAC IEEE 802 en una direccin IP. Es decir, a partir de una direccin fsica de tarjeta de red IEEE 802, obtiene una direccin numrica. Se utiliza en redes de rea local con estaciones sin disco duro o que arrancan por primera vez en una red. Este protocolo se ha quedado obsoleto y est siendo sustituido por los protocolos BOOTP y DHCP. El funcionamiento del protocolo RARP es simple, si una mquina A sin disco no conoce su propia direccin IP, la pide mediante un mensaje RARP de solicitud de direccin IP que contiene entre otras informaciones la direccin de hardware de su tarjeta de red (A). Este mensaje RARP va encapsulado en una trama de difusin de la red de acceso IEEE 802. Slo una mquina (servidor RARP) est autorizada a responder un mensaje de esta clase con un mensaje RARP de respuesta encapsulado, a su vez, en una trama especfica de informacin dirigida nicamente a la mquina A.
57
Al apagar la mquina se pierde toda la informacin.
- 116 -
Conviene resaltar que una direccin fsica o de hardware viene con la tarjeta de red y, por tanto, con la mquina. Pero una direccin IP no viene con la mquina, se supone que una vez adquirida y conectada a la red, alguien debe asignarla. El problema es que si no se dispone ni de disco duro ni de una memoria no voltil o no temporal, no hay forma de almacenarla con carcter permanente. Por tanto, hay que preguntar por su direccin IP cada vez que la mquina se conecte a la pertinente red o subred IEEE 802.
Protocolos del nivel de aplicacin sobre UDP: BOOTP (BOOTstrap Protocol, RFC-951): Introduce ms informacin de arranque que RARP pero es un PROTOCOLO ESTTICO DE CONFIGURACIN DHCP (Dynamic Host Configuration Protocol, RFC-1541): Versin actualizada y mejorada del protocolo BOOTP al ser un PROTOCOLO DINMICO DE CONFIGURACIN
Figura 2.77.- Alternativas al protocolo RARP. Ha habido varias propuestas para automatizar ciertas informaciones especficas en el proceso de configuracin. Una mquina conectada a una red de rea local puede utilizar el protocolo RARP para descubrir su propia direccin de IP. Asimismo (como ya se analizar al estudiar el protocolo ICMP) mediante un mensaje de solicitud-respuesta de mscara de direccin se puede obtener la mscara de red o subred. Sin embargo, no se consigue ninguna ventaja significativa usando diferentes protocolos y mensajes para obtener la informacin que se puede obtener con una nica respuesta. As, para indicar en un solo mensaje, ms parmetros de informacin que la indicada por RARP (y otro protocolo como ICMP), actualmente, existen dos protocolos de arranque en el nivel de aplicacin de la arquitectura TCP/IP en el escenario de las redes de rea local IEEE 802: BOOTP (RFC-951): Protocolo de arranque que, entre otras informaciones, asigna direcciones de IP de una tabla de direcciones fsicas. Este protocolo que sigue el modelo cliente-servidor (modelo que se analizar en su momento) fue el primer estndar para el arranque automtico en un entorno TCP/IP. Ofrece a todas las mquinas sin disco duro o que arrancan por primera vez en una red, todos sus parmetros bsicos de configuracin, as como algunos parmetros especializados. Se resalta que toda mquina conectada a Internet o a una red privada TCP/IP debe conocer al menos su direccin IP, mscara de red, direccin IP del router y direccin IP del servidor de nombres. Asimismo, BOOTP tambin permite a un sistema descubrir de dnde puede conseguir - 117 -
descargar el software de arranque necesario (imagen de memoria inicial para su ejecucin), es decir, BOOTP no proporciona una imagen de memoria a los clientes, sino la informacin necesaria para obtener esa imagen. El protocolo BOOTP se dise sobre UDP para estaciones de trabajo sin disco, mediante una simple interaccin solicitud-respuesta. El primer objetivo era permitir un arranque automtico con TFTP (Trivial FTP), UDP e IP, los cuales se almacenaban en una memoria de slo lectura no voltil (ROM). TFTP es un protocolo TCP/IP del nivel de aplicacin (que ya se examinar) que permite descargar el software de arranque en la memoria y ejecutarlo. Este software de arranque puede proceder de la misma mquina servidora en donde se ejecuta el proceso servidor de BOOTP o incluso de otra mquina servidora independiente. El cliente local de BOOTP se identifica con el nmero de puerto58 68 y el proceso servidor con el 67 para el protocolo UDP. En la interaccin clienteservidor BOOTP, se usa el mismo formato para el mensaje de solicitud de arranque y respuesta de arranque. Como mximo los mensajes BOOTP son de 300 octetos (salvo el ltimo que tendr menos). Un cliente59 de arranque o cliente de BOOTP que no disponga de informacin previa, enviar, entre otras informaciones, las siguientes: Tipo (1) del mensaje BOOTP (tipo = 1 es una solicitud y tipo = 2, una respuesta). Identificador de transaccin para asociar solicitudes con respuestas (debe ser el mismo para la pertinente respuesta). Direccin de hardware del cliente. Direccin IP del cliente de BOOTP: 0.0.0.0 en el caso de que el cliente no conozca su propia direccin. Puede suceder que se haya preconfigurado un cliente de arranque con una direccin de IP o que dispone de una direccin de IP que se le dio en un proceso de arranque anterior. En este caso, el cliente rellena este campo con dicha direccin. Direccin IP del servidor de BOOTP: 255.255.255.255. En el caso de poner 32 bits a uno, un servidor de BOOTP, o varios, de la red de rea
58
El concepto de nmero de puerto, tambin, se estudiar ms adelante.
59
Completa los campos del mensaje de solicitud con toda la informacin con la que cuenta y deja los campos restantes a cero.
- 118 -
local del cliente, escucharn la solicitud. Si el cliente ha rellenado la direccin del servidor, slo responder dicho servidor. Se recuerda que si no se incluye ninguna direccin especfica de servidor, es decir, la direccin de destino es 255.255.255.255; puede que respondan varios servidores de BOOTP. En este ltimo caso, responder cualquier servidor que reciba la solicitud. Como UDP es un protocolo no fiable, el protocolo BOOTP tiene sus propios mecanismos de fiabilidad implementados en el nivel de aplicacin, y el cliente retransmitir si no recibe una respuesta en un plazo determinado. En este contexto, el servidor de arranque o servidor de BOOTP transmitir60, entre otras, las siguientes informaciones: Tipo (2) del mensaje BOOTP (tipo = 1 es una solicitud y tipo = 2, una respuesta). Identificador de transaccin para asociar solicitudes con respuestas (coincide con el que vena en la solicitud). Direccin de hardware del cliente (coincide con la que vena en la solicitud). Direccin IP del cliente de BOOTP: Coincide con la que vena en la solicitud, es decir, 0.0.0.0, si el cliente no conoca su propia direccin. La forma ms sencilla de enviar una respuesta de vuelta al cliente es: Usar una cabecera de IP con la nueva direccin de destino. Encapsular el datagrama en una trama dirigida a la direccin fsica del cliente.
Direccin IP del servidor de BOOTP: Coincide con la que vena en la solicitud, es decir, 255.255.255.255 o una direccin especfica de servidor BOOTP. Direccin IP del cliente proporcionada por el servidor. Direccin IP del servidor que dispone del fichero de arranque.
60
Se usa el mismo formato de mensaje para las solicitudes y respuestas.
- 119 -
Direccin IP del router. Direccin IP del servidor DNS. En este contexto, los administradores se dieron cuenta de que se podra aprovechar BOOTP para conseguir ms datos de configuracin y para configurar sistemas con discos sin necesidad del paso de descargar el software. No se tard mucho en incluir en los mensajes de BOOTP parmetros adicionales como la mscara de subred, las direcciones de los routers por omisin, las direcciones de los servidores de DNS, as como otras informaciones. Con este protocolo, el administrador tiene que crear la tabla de asociaciones manualmente en el servidor de BOOTP. Consecuentemente, BOOTP se basa en un protocolo esttico de configuracin fundamentado en una tabla esttica establecida de antemano y en donde las asociaciones direcciones fsicas-direcciones de IP se establecen previamente y manualmente por el administrador. DHCP (Dynamic Host Configuration Protocol, RFC-1541): Es la versin actualizada del protocolo BOOTP, que aparte de otras mejoras, permite automatizar completamente la asignacin de direcciones de IP. Se recuerda que BOOTP es un protocolo esttico de configuracin. En el caso de BOOTP, cuando un cliente solicita su direccin IP, el servidor busca en su tabla la entrada que coincida con la direccin fsica del cliente para obtener la direccin IP correspondiente. Esto implica que debe haber una ASOCIACIN PREDETERMINADA entre la direccin fsica y la direccin IP. Sin embargo, qu ocurre si la mquina cambia de una red fsica a otra?, qu sucede si una estacin quiere una direccin IP temporal? En este escenario entra a jugar un papel fundamental DHCP, el cual es un PROTOCOLO DINMICO DE CONFIGURACIN que asigna dinmicamente direcciones de IP temporales durante un tiempo limitado cuando una mquina se: Mueve de una red a otra. Conecta o desconecta desde una red.
Por tanto, DHCP es una actualizacin de BOOTP que mejora a ste y, adems, es compatible hacia atrs con l. Esto significa que una estacin que ejecuta el cliente de BOOTP puede solicitar una configuracin esttica de un servidor DHCP. El uso de BOOTP provoc que los administradores se dieran cuenta de que necesitaban ms funciones, como las que se mencionan a continuacin: Una administracin ms sencilla: Si el administrador lo desea, tan solo, indica el bloque de direcciones de IP que el servidor de DHCP puede asignar
- 120 -
a los clientes de la red de rea local. Tambin, puede introducir la mscara de red o subred, direcciones del servidor DNS, direcciones de los routers por omisin de la red de rea local. Si es necesario, el administrador tambin puede introducir parmetros adicionales especficos del sistema. De esta forma, si un cliente de DHCP solicita informacin de arranque al servidor, ste le asigna automticamente una direccin de IP del bloque y le enva el conjunto apropiado de parmetros. Una configuracin automtica de las direcciones de IP, sin necesidad de teclear y tener que mantener largas listas de direcciones de hardware y sus correspondientes direcciones de IP. Permitir cambios y traslados. Cuando un usuario desconecta su computadora y la traslada a otro edificio y la vuelve a conectar a una nueva red o subred, automticamente, cambia su direccin de IP y actualiza la mscara de red o subred, el router por omisin y el servidor de nombres de DNS, si lo requiere. Con DHCP, la configuracin manual es cosa del pasado. De hecho, DHCP permite tres tipos de asignacin de direcciones: Asignacin manual: Una direccin de IP que se ha introducido manualmente en el servidor se asigna permanentemente al cliente. Asignacin automtica: Se selecciona una direccin de IP de las que estn disponibles en el servidor y se asigna permanentemente al cliente. Asignacin dinmica: Se asigna una direccin de IP al cliente durante un tiempo limitado o hasta que el cliente la devuelve. Este es el caso de los usuarios que usan computadoras porttiles y las conectan espordicamente a la red de rea local de la organizacin puede que no necesiten direcciones permanentes o ni siquiera de larga duracin.
Permitir que el cliente solicite los valores de ciertos parmetros: DHCP hereda de BOOTP la posibilidad de ofrecer datos de configuracin concretos y detallados para identificar la imagen del software que hay que descargar. Una limitacin de BOOTP era que un cliente no tena control sobre los parmetros que obtena. Por tanto, DHCP permite que el cliente solicite parmetros concretos. El servidor de DHCP almacena la correspondencia entre el cliente y sus parmetros de configuracin. Nuevos tipos de mensajes de DHCP que soportan interacciones clienteservidor robustas. - 121 -
Permitir que un cliente de BOOTP pueda acceder a un servidor de DHCP (RFC-1584: Interoperabilidad entre DHCP y BOOTP). Para mantener la compatibilidad con BOOTP, el formato de los mensajes de DHCP es idntico a de BOOTP.
NIVELES SOFTWARE Y HARDWARE EN UNA RED DE ACCESO IEEE 802

IP
ARP RARP
Interfaz de Acceso a la Red IEEE 802 Driver de la Tarjeta de Red

RED IEEE 802 DE ACCESO
Software Hardware
Tarjeta adaptadora de Red Hardware de Red
Figura 2.78.- Niveles software y hardware en una red de acceso IEEE 802. En la Figura 2.78 se muestra el software de TCP/IP de ms bajo nivel, responsable de aceptar datagramas IP (y mensajes ARP y RARP), aadirles una cabecera y enviarlos a travs de una red especfica. Por consiguiente, este nivel se corresponde con un software especfico de red que se comunica con el driver (software) del dispositivo de red. De este modo, se proporciona, fundamentalmente al protocolo IP, un acceso consistente respecto a todos los adaptadores de red que se puedan presentar. Es importante resaltar que los usuarios, por regla general, no estn conectados a su ISP mediante una red de rea local IEEE 802 y s a travs de una lnea conmutada o lnea serie o punto a punto telefnica. En este escenario existen dos protocolos en el nivel del interfaz de acceso a la red de la arquitectura TCP/IP que son: SLIP y PPP (ver Figura 2.79). Estos mismos protocolos se utilizan tambin en lneas punto a punto entre routers.
- 122 -
Protocolos del Nivel de Enlace (Interfaz de acceso) usados en Internet:

SLIP (Serial Line IP) PPP (Point-to-Point Protocol)
Lneas Punto a Punto:

Lneas telefnicas anlgicas(RTC)/Digitales (RDSI) entre usuarios y proveedores del servicio de acceso a Internet Lneas alquiladas (routers contiguos)
Figura 2.79.- El protocolo del interfaz de red en lneas serie en Internet.

ROUTER ROUTER
RTC
mdem
Usuario
Aplic.
TCP/UDP
mdem
Proveedor
SLIP o PPP
IP
Internet
SLIP o PPP
IP Interfaz
Interfaz
Fsico
Fsico
Figura 2.80.- Escenario de uso del protocolo del interfaz de red en lneas serie. En la Figura 2.80 se muestra lo comentado anteriormente, y la posicin grfica que ocupan ambos protocolos en la arquitectura TCP/IP. Es importante resaltar que en toda lnea punto a punto siempre circulan tramas SLIP o PPP encapsulando datagramas IP. Como caractersticas generales de estos protocolos se destacan las siguientes: SLIP: Fue el primer protocolo usado en lneas serie o punto a punto. No detecta ni corrige errores fsicos (al no incorporar ninguna secuencia de verificacin de trama). No hay ningn tipo de asignacin dinmica de direcciones numricas durante el establecimiento del enlace (cada extremo debe conocer de antemano su direccin IP). No existe ningn mecanismo de autenticacin.
- 123 -
PPP: Ha sustituido al protocolo SLIP Opcionalmente, permite la deteccin y correccin de errores fsicos (y numeracin de tramas). Soporta la asignacin dinmica de direcciones numricas (negociacin de opciones de nivel de red mediante tramas especiales PPP). Soporta distintos mecanismos de autenticacin (protocolos CHAP, PAP, ...) cuyos mensajes se encapsulan en tramas PPP. Soporta mecanismos (mediante tramas especiales PPP) para probar el enlace y medir la calidad de la lnea.
2.17 Nmeros de puertos y sockets

La mayora de las aplicaciones en Internet funcionan segn el modelo cliente-servidor en donde un: Servidor: Es un programa o proceso que ofrece un servicio en la red. Cliente: Es un proceso que enva a un servidor una solicitud especfica de servicio. Segn se muestra en la Figura 2.81, cada proceso servidor (al igual que todo proceso cliente) del nivel de aplicacin viene definido por un nmero de puerto que lo identifica. Este nmero de puerto es un entero positivo que identifica tanto al proceso servidor como al proceso cliente donde se espera la respuesta. Tanto TCP como UDP tienen definidos un grupo determinado de nmeros de puerto, algunos de los cuales estn ya reservados para las aplicaciones estndares Internet. Tal es el caso, por ejemplo, del 23 (telnet), 21 (ftp), 25 (smtp) para TCP o del 69 (tftp) para UDP. Los puertos TCP son independientes61 de los puertos UDP, ya que la cabecera de IP especifica el tipo de protocolo. Los nmeros del 062 al 1023 estn siempre reservados para aplicaciones estndares Internet (aprobadas por el IAB). Del 102463 al 65535 para aplicaciones no estndares en Internet (una aplicacin privada TCP/IP desarrollada para
61
Por ejemplo, el puerto 840 de TCP es independiente del puerto 840 de UDP. Reservado para aplicaciones que interactan directamente sobre IP. Del 1024 al 5000 se asignan automticamente por el sistema operativo.
62
63
- 124 -
una organizacin) y para identificar procesos clientes. Se utilizan 65536 valores (del 0 al 65535) porque se emplean 16 bits como nmeros de puerto en las cabeceras de informacin de control TCP y UDP para identificar procesos clientes y servidores.
APLICACIN
Telnet
FTP
SMTP
TFTP
TRANSPORTE TRANSPORTE
23
21
TCP
25
69
UDP
INTERNET
IP
Datagrama
Figura 2.81.- Nmeros de puerto. Los procesos servidores indicados en la Figura 2.81 son los siguientes: TELNET (Terminal Network Protocol): Es un protocolo Internet del nivel de aplicacin que permite establecer una conexin con el proceso servidor telnet asociado al puerto TCP de una mquina remota, proporcionado un servicio de login o terminal remoto. FTP (File Transfer Protocol): Es un protocolo Internet del nivel de aplicacin que permite establecer una conexin con el proceso servidor ftp asociado al puerto TCP de una mquina remota, ofreciendo un servicio fiable de transferencia de ficheros. SMTP (Simple Mail Transfer Protocol): Es un protocolo Internet del nivel de aplicacin que permite establecer una conexin con el proceso servidor smtp asociado al puerto TCP de una mquina remota, proporcionando un servicio fiable de transmisin de correo electrnico. TFTP (Trivial FTP): Es un proceso Internet del nivel de aplicacin que permite establecer una conexin con el proceso servidor tftp asociado al puerto UDP de una mquina remota, ofreciendo un servicio no fiable (sin control de errores ni de flujo en el nivel de transporte) de transferencia de ficheros.
- 125 -
FTP (Servidor)
FTP (Cliente)
21
1500
TCP
TCP
Figura 2.82.- Ejemplo de una identificacin y comunicacin del cliente y servidor. A su vez, la Figura 2.82 muestra una comunicacin entre el proceso cliente de FTP de una mquina, identificado con el nmero de puerto 150064 y el proceso servidor de FTP de otra mquina definido por el nmero de puerto 21 reservado exclusivamente para dicho proceso.
Mquina A Mquina B
Servidor (TCP,A,21) TCP,A,21) Servidor (TCP,A,21) TCP,A,21)
Cliente (TCP,B,1500) TCP,B,1500) Cliente (TCP,B,1501) TCP,B,1501)
2 conexiones
Figura 2.83.- Dos conexiones va socket. En la Figura 2.83 se muestra el concepto de socket o punto de acceso a travs del cual se establece una comunicacin entre dos procesos (cliente y servidor) que se ejecutan en la misma mquina o en mquinas diferentes por la red (esto ltimo es lo ms habitual). Este punto de comunicacin, que sera equivalente al Punto de Acceso al Servicio del nivel de transporte en OSI (TSAP), queda definido por la direccin Internet o IP de la mquina, el protocolo del nivel de transporte (TCP o UDP) y, finalmente, el nmero de puerto asociado al servicio o aplicacin correspondiente. Por tanto, una conexin queda plenamente definida por una pareja de sockets que se comunican. En este contexto, la citada Figura 2.83 muestra dos conexiones va socket entre dos clientes en la mquina
64
Se elige el primer nmero libre fuera del rango de nmeros reservados para servicios o aplicaciones estndares de Internet.
- 126 -
B y un mismo proceso servidor de transferencia de ficheros en la mquina A cuyo nmero de puerto 21 est reservado exclusivamente para dicho proceso.
Informacin dependiente de la aplicacin
N Puerto Origen (16 bits) N Puerto Destino (16 bits)
Cabecera Mensaje
Datos
Mensaje
Direccin IP Origen (32 bits) Direccin IP Destino (32 bits)
TCP (UDP)
Direccin Ethernet Origen (48 bits) Direccin Ethernet Destino (48 bits)
Cabecera Cabecera Mensaje
Datos
Segmento TCP
(y Datagama UDP)
Cabecera Cabecera Cabecera TCP (UDP) Mensaje IP
Datos
Datagrama IP
Cabecera Cabecera Cabecera Cabecera TCP (UDP) Mensaje Ethernet IP
Datos
Trama Ethernet
Figura 2.84.- Informacin ms relevante en las cabeceras de informacin de control. Para finalizar, en la Figura 2.84 se muestra la informacin ms significativa que aparece en la cabecera de informacin de control en el nivel de aplicacin, transporte, red e interfaz de red (se asume que la red de acceso es, por ejemplo, una red de rea local del tipo Ethernet): La cabecera del mensaje contiene la informacin de control propia de la correspondiente aplicacin TCP/IP. Es importante resaltar que no tiene nada que ver, por ejemplo, la informacin de control de una aplicacin de transferencia de ficheros con otra de envo de correo. La cabecera de un segmento TCP o datagrama UDP contiene como informacin ms significativa, los nmeros de puerto origen-destino. La cabecera de un datagrama IP contiene como informacin ms relevante, las direcciones numricas de origen-destino La cabecera de una trama contiene como informacin ms significativa, las direcciones de origen-destino en la correspondiente red de acceso (p. ej., una red de rea local del tipo Ethernet).
- 127 -
2.18 Aplicaciones de TCP/IP

Interfaz de Interfaz de usuario usuario Interfaz de usuario Interfaz de usuario (WWW)
TELNET FTP SMTP HTTP ....
NFS ........... RPC
....
DNS
SNMP TFTP
....
TCP
Protocolos entre Routers Avanzados (OSPF)
ICMP
IP
HARDWARE
UDP
SLIP PPP
ARP
RARP
INTERFAZ DE RED
Figura 2.85.- Protocolos ms significativos de la arquitectura TCP/IP. La Figura 2.85 proporciona una visin panormica y global de las aplicaciones o protocolos ms representativos en cada uno de los niveles de la arquitectura TCP/IP. Continuando con la ascensin por la arquitectura TCP/IP, ha llegado el momento de ubicarse en el nivel de aplicacin o usuario, en donde podran estar ejecutndose los siguientes protocolos: TELNET: Ofrece un servicio de terminal remoto sobre TCP. FTP: Proporciona un servicio fiable de transferencia de ficheros sobre TCP. SMTP: Ofrece un servicio de envo de correo sobre TCP. HTTP: Proporciona un servicio sobre TCP de copiado de pginas en formato HTML (HyperText Markup Language) para su visualizacin o interpretacin local en la mquina del usuario. NFS: Ofrece un servicio de comparticin de ficheros en una red de rea local sobre TCP o UDP (lo ms habitual). DNS: Proporciona un servicio de nombres de dominio (traduccin del formato simblico al numrico) sobre UDP. SNMP: Ofrece un servicio de gestin de red sobre UDP. TFTP: Proporciona un servicio no fiable de transferencia de ficheros sobre UDP. ... - 128 -
APLICACIN
Aplicaciones que siguen o no el modelo cliente- servidor
TRANSPORTE
INTERNET
RED DE ACCESO
Figura 2.86.- El nivel de aplicacin de la arquitectura TCP/IP. En este contexto, conviene distinguir entre servicios del nivel de aplicacin que siguen o no el modelo cliente-servidor ya estudiado: Aplicaciones que siguen el modelo cliente-servidor: Telnet, FTP, SMTP, HTTP (Web), NFS, DNS, SNMP, TFTP, NSLOOKUP, etc. Aplicaciones que no siguen el modelo cliente-servidor65: PING, IPCONFIG (IFCONFIG en Unix), ARP, TRACERT (TRACEROUTE en Unix), etc.
2.18.1
Envo de correo electrnico: SMTP
En la siguiente Figura 2.87 se muestra grficamente el funcionamiento del protocolo SMTP (Simple Mail Transfer Protocol) que proporciona un servicio de envo de correo electrnico por Internet. Este protocolo permite a un usuario enviar correo a otros usuarios aunque stos no estn activos durante la comunicacin, es decir, no estn conectados simultneamente. Esto es as, ya que se adopta la idea del buzn electrnico, es decir, una zona o directorio particular en donde los mensajes se depositan hasta que el receptor, y dueo del mismo, se conecta y los recupera. Por regla general, cada usuario dispone de su propio buzn en la mquina servidora de correo de su organizacin (o de su ISP) en donde se est ejecutando un proceso servidor SMTP. Asimismo, el usuario en su computadora dispone del correspondiente cliente SMTP que se ejecuta en el entorno de su aplicacin de correo (agente de usuario). Cuando un primer usuario (usuario1) compone un mensaje y decide transmitirlo al buzn de otro
65
Se resalta que estas aplicaciones no estn montadas sobre TCP o UDP. Algunas de ellas realizan incluso llamadas directas a la entidad IP o ICMP.
- 129 -
usuario (usuario2), el proceso cliente SMTP del primero, identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para servicios o aplicaciones estndares en Internet), transfiere el mensaje a su proceso servidor SMTP, identificado siempre en cualquier mquina servidora con el nmero de puerto 25 asociado al protocolo TCP. El proceso servidor SMTP se ejecuta en una mquina servidora de la organizacin del usuario emisor (o de su ISP) en la cual est su buzn. Dicho proceso servidor SMTP procede a analizar la direccin de correo del destinatario (usuario2@identificador_mquina). Por el identificador de la mquina, en donde se ejecuta el proceso servidor SMTP, se da cuenta que el mensaje se debe transferir al buzn de otra mquina remota.
Aplicacin de correo (agente de usuario)
Envo de correo (SMTP)
LAN
Acce so al buzn
INTERNET
SMTP
Acce so al buzn
LAN
Buzn
SMTP
25
TCP
SMTP
Buzn
IP
LAN: Local Area Network o Red de rea Local
Figura 2.87.- Envo de correo electrnico va SMTP. El proceso servidor de SMTP del usuario1 se convierte en un proceso cliente de SMTP del proceso servidor de SMTP del usuario2. Seguidamente, el proceso servidor de SMTP del usuario 2 transfiere el mensaje al correspondiente buzn (usuario2). La citada Figura 2.87 muestra, en concreto, un ejemplo de dos usuarios conectados a la mquina servidora de correo de su organizacin a travs de una red de rea local. A su vez en la siguiente Figura 2.88 se muestra una extensin de software del correo electrnico Internet que se ejecuta dentro de la propia aplicacin de correo en la mquina del usuario. Dicha extensin se conoce con el nombre de MIME (Multipurpose Internet Mail Extensions) y permite enviar datos binarios codificados en ASCII (norma de codificacin en Internet). En consecuencia permite aadir y transferir cualquier tipo de fichero (texto, grficos, audio y vdeo) encapsulado en el cuerpo del mensaje
- 130 -
original66. Obviamente, se asume que existe un software de MIME en la aplicacin de correo del emisor y receptor.
Mensaje MIME (Multipurpose Internet Mail Extensions)
Cabecera del mensaje Texto Cuerpo del mensaje Audio Imagen Vdeo MIME RFC-1345 RFC-822
Figura 2.88.- Transmisin de datos binarios va MIME.
2.18.2
Recogida del correo electrnico: POP3

Cliente POP3
TCP
IP
Acce so al buzn (recoger correo)
LAN
INTERNET
SMTP
TCP
IP
LAN
Acce so al buzn (va POP3)
Servidor POP3
110
Buzn
25
Buzn
TCP
IP
SMTP
SMTP
LAN: Local Area Network o Red de rea Local
Figura 2.89.- Recogida del correo electrnico va POP3. La Figura 2.89 describe grficamente el funcionamiento del protocolo POP3 (Post Office Versin 3) que proporciona un servicio de recogida de mensajes del buzn de correo. Como se coment anteriormente, el buzn de un usuario se encuentra en la mquina servidora de correo y no en su computadora. Por tanto, se necesita de un protocolo como POP3 que recoja el correo del buzn y lo traiga a un directorio del disco duro de la computadora del usuario. El procedimiento consiste en que un proceso cliente POP3 identificado con un nmero de puerto TCP (un nmero libre fuera del
Todo mensaje consta de una cabecera con las direcciones y un cuerpo con el texto del mensaje correspondiente.
66
- 131 -
rango de nmeros reservados para aplicaciones estndares en Internet) se comunica (para recoger y traer el correo) con el proceso servidor POP3 identificado siempre en cualquier mquina servidora con el nmero de puerto 110 asociado al protocolo TCP. El proceso servidor POP3 se ejecuta en la mquina servidora de correo en donde, asimismo, se ejecuta el proceso servidor SMTP. En el caso del protocolo POP3, la aplicacin de correo, que se ejecuta en la propia mquina del usuario, dispone de un proceso cliente SMTP y un proceso cliente POP3. En la mquina servidora de correo, a su vez, se ejecutar un proceso servidor SMTP y POP3.
2.18.3
Gestin del correo electrnico: IMAP4
La siguiente Figura 2.90 describe grficamente el funcionamiento del protocolo IMAP4 (Internet Message Access Protocol Rev 4) que proporciona un servicio de gestin de mensajes en el mismo buzn de correo. Este protocolo permite al usuario gestionar todo su correo en su propio buzn sin necesidad de recoger todos los mensajes y traerlos al disco duro de su mquina como se haca por omisin con POP3. El protocolo IMAP4 permite eliminar, clasificar y distribuir su correo en distintas carpetas dentro de la propia mquina servidora de correo. Asimismo, permite copiar o mover mensajes previamente seleccionados desde el buzn hasta su computadora; por consiguiente, permite ms posibilidades que el protocolo POP3. Es importante resaltar que el correo no se lee a travs de la red sino que se trae va IMAP4 de forma temporal a un determinado directorio local en la mquina del usuario. El procedimiento de trabajo de este protocolo consiste en que un proceso cliente IMAP4 identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica (para la gestin del correo) con el proceso servidor IMAP4 identificado siempre en cualquier mquina servidora con el nmero de puerto 220 asociado al protocolo TCP. El proceso servidor IMAP4 se ejecuta en la mquina servidora de correo en donde se ejecuta asimismo el proceso servidor SMTP. En el caso del protocolo IMAP4, la aplicacin de correo, que se ejecuta en la propia mquina del usuario, dispone de un proceso cliente de SMTP y un proceso cliente de IMAP4. En la mquina servidora de correo se ejecutar un proceso servidor de SMTP y un proceso servidor de IMAP4.
- 132 -
Cliente Cliente IMAP4 IMAP4
Aplicacin de correo Aplicacin de correo (agente de usuario) (agente de usuario)

Envo de Envo de correo correo (SMTP) (SMTP)
Envo de Envo de correo correo (SMTP) (SMTP)
Aplicacin de correo Aplicacin de correo (agente de usuario) (agente de usuario)
TCP TCP
IP IP
Gestin Gestin del del buzn buzn
Servidor Servidor IMAP4 IMAP4
LAN LAN
INTERNET INTERNET
LAN LAN
Acce so al buzn Acce so al buzn (va POP3/IMAP4 o (va POP3/IMAP4 o Telnet) Telnet)
Buzn Buzn
Buzn Buzn
TCP TCP
IP IP
220 220
SMTP SMTP
SMTP SMTP
LAN: Local Area Network o Red de rea Local LAN: Local Area Network o Red de rea Local
Figura 2.90.- Gestin del correo electrnico va IMAP4.
2.18.4
Protocolo de acceso remoto: TELNET
La siguiente Figura 2.91 muestra grficamente el funcionamiento del protocolo Telnet67 el cual ofrece un servicio de terminal remoto, permitiendo que la mquina del usuario se convierta en un terminal de una mquina servidora por Internet o por una red privada TCP/IP. A travs de este protocolo, el usuario tiene la apariencia de estar sentado delante de la pantalla de la mquina servidora aunque sta est dispersa por Internet a miles de kilmetros. El procedimiento consiste en que un proceso cliente de Telnet identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica con el proceso servidor de Telnet identificado siempre en cualquier mquina servidora con el nmero de puerto 23 asociado al protocolo TCP. Se asume que el usuario dispone de cuenta (login/password) en la mquina servidora remota, es decir, est debidamente registrado por el administrador de dicha mquina.
67
Rlogin que est montado sobre TCP en el n de puerto 513 es un servicio equivalente entre mquinas Unix.
- 133 -
Telnet
TCP
IP
Telnet 23 TCP IP
Internet
> telnet x.x.x.x login: uuuuu Password: $
Figura 2.91.- El protocolo Telnet de acceso remoto. Segn se muestra, a su vez, en la siguiente Figura 2.92, el servicio de terminal remoto ofrecido por el protocolo Telnet se basa en unas secuencias de escape o caracteres de control ASCII pertenecientes a un Terminal Virtual de Red que permite una vez establecida la conexin TCP, negociar el modo de operacin (opciones de comunicacin) entre el proceso cliente y servidor de Telnet. La negociacin del modo de operacin permite indicar el tipo de terminal (p.ej., VT100, ANSI, ...), el tipo de comunicacin (dplex o semidplex), modo lnea o modo carcter, etc. Un terminal VT10068 o un terminal ANSI69 es un software (intrprete) incluido en el telnet cliente y servidor que permite interpretar las secuencias de escape para la definicin del nmero de filas y columnas en la pantalla del cliente, el movimiento del cursor, tabulados, retornos de carro, etc. Consecuentemente, una vez se ha definido el tipo de terminal, ya sea VT100 o ANSI, se transmiten secuencias de escape o caracteres de control especficos VT100 o ANSI.
Formato NVT Network Virtual Terminal) Servidor
Telnet 23 TCP IP
Terminal Real
Terminal Virtual
Figura 2.92.- El servicio de terminal remoto del protocolo Telnet.
68
Tpica emulacin soportada en el entorno Unix.
69
Tpica emulacin soportada en el entorno Windows y que dispone de un conjunto de caracteres de control ms reducido que en VT100.
- 134 -
2.18.5
Protocolo de transferencia de ficheros: FTP

Cliente ftp
Mdulo de transferencia de datos
Servidor ftp
Mdulo de control
21
Mdulo de transferencia de datos
Mdulo de control
TCP IP
TCP IP
20
Control de la conexin
Internet
Conexin de datos
Figura 2.93.- Los procesos internos del protocolo FTP. La Figura 2.93 describe grficamente el funcionamiento del protocolo FTP (File Transfer Protocol), el cual ofrece un servicio de transferencia de uno o ms ficheros (ASCII y binarios) entre dos mquinas. El protocolo FTP consiste en dos mdulos o proceso diferentes: Mdulo de Control: Basado en un mdulo o proceso cliente identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) que se comunica siempre con el correspondiente mdulo o proceso servidor identificado, en cualquier mquina servidora, con el nmero de puerto 21 asociado al protocolo TCP. Mdulo de Transferencia de Datos: Basado, a su vez, en un mdulo o proceso cliente identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) que se comunica con el correspondiente mdulo o proceso servidor identificado siempre en cualquier mquina servidora con el nmero de puerto 20 asociado al protocolo TCP. En consecuencia, el protocolo FTP utiliza dos nmeros de puerto, uno (21) para establecer la conexin entre dos entidades FTP y otro (20) para transferir ficheros (get/put) entre dichas mquinas sin salir de la conexin previamente establecida.
- 135 -
2.18.6
Protocolo simple de transferencia de ficheros: TFTP
tftp UDP IP
Cliente tftp
(p.ej.,512 octetos de datos)
Servidor tftp
tftp
69
UDP IP
Internet
Figura 2.94.- El protocolo simple TFTP de transferencia de ficheros. La Figura 2.94 muestra grficamente el funcionamiento del protocolo TFTP (Trivial FTP), el cual ofrece, al igual que FTP, un servicio de transferencia de ficheros entre dos mquinas, pero con las siguientes particularidades: No hay identificador de usuario/contrasea (login/password). El protocolo de transporte es UDP. Por tanto, el proceso cliente de TFTP identificado con un nmero de puerto UDP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica con el mdulo o proceso servidor de TFTP identificado siempre en cualquier mquina servidora con el nmero de puerto 69 asociado al protocolo UDP. Debe pasar, al protocolo UDP, bloques bien delimitados con una longitud mxima, por ejemplo, de 512 octetos. Incorpora ciertos mecanismos de fiabilidad (temporizadores, nmeros de secuencia, etc.) ya que est montado sobre UDP. El diseo de este protocolo se realiz para aquellas estaciones sin disco duro de una organizacin que necesitan traerse el software de arranque ubicado remotamente en una mquina servidora conectada a la red de rea local de dicha organizacin. Este protocolo junto con un subconjunto reducido de la arquitectura TCP/IP (UDP-IPinterfaz de red) se almacena en una memoria no voltil para poder iniciar el arranque como se ha comentado anteriormente. La falta de seguridad del protocolo se debe a su uso exclusivamente en el escenario de una determinada organizacin. Por tanto, no est pensado para su un uso general por Internet. De hecho, los administradores de mquinas servidoras por Internet lo tienen deshabilitado. - 136 -
2.18.7
Protocolo de comparticin de ficheros en red: NFS
NFS RPC/XDR TCP o UDP

IP
Cliente (disco local)
NFS RPC/XDR
Aplicacin
TCP o UDP
IP
Virtual File System
Servidor (disco local)
Virtual File System
H I
B C
S.O. local
Cliente NFS
Servidor NFS
S.O. local
B C
Figura 2.95.- El protocolo NFS de comparticin de ficheros en red. La Figura 2.95 describe grficamente el funcionamiento del protocolo NFS (Network File System), el cual ofrece un servicio de comparticin de ficheros en redes de rea local; permitiendo que un fichero remoto se vea como local en la propia mquina del usuario. El objetivo es proporcionar un acceso transparente a una parte o a la totalidad del sistema de ficheros de la correspondiente mquina servidora sin penalizar la capacidad de almacenamiento del disco duro de la propia mquina del usuario. En consecuencia, el usuario tiene la sensacin de que los directorios y ficheros remotos estn de forma local en su disco duro cuando en realidad se encuentran fsicamente en otra mquina. NFS fue desarrollado por Sun Microsystems y descansa sobre el protocolo RPC y la sintaxis XDR. Como ya se estudiar ms adelante, RPC es todo un sistema (incluyendo un protocolo de comunicaciones) que incorpora un interfaz de programacin que abstrae al programador de los detalles de interaccin con la red a travs de llamadas directas va el interfaz de sockets (interfaz que tambin se analizar en su momento). A su vez, XDR es la sintaxis comn de representacin y codificacin que permite que mquinas con arquitecturas fsicas diferentes se puedan entender. RPC se puede ejecutar sobre TCP, aunque lo normal es que sea sobre UDP teniendo en cuenta que el escenario NFS se monta en la red de rea local de una determinada organizacin. El procedimiento operativo se basa, fundamentalmente, en un componente denominado VFS (Virtual File System) que diferencia las llamadas a ficheros locales (pasando el control al sistema operativo) de las llamadas a ficheros remotos en cuyo caso pasa el control al proceso cliente NFS que se comunica con el proceso servidor NFS.
- 137 -
2.18.8 Protocolo de resolucin de direcciones simblicas en numricas: DNS
Cliente DNS
DNS
DNS
Servidor de Nombres (DNS)
UDP IP
UDP IP
53
Servidor de Nombres (DNS)
SOLICITUD
etsit.upm.es
SOLICITUD
etsit.upm.es
138.100.17.10 RESPUESTA
>telnet etsit.upm.es Trying 138.100.17.10
138.100.17.10 RESPUESTA
Figura 2.96.- Un ejemplo de resolucin de direcciones va DNS. La Figura 2.96 muestra grficamente, a travs de un ejemplo, el funcionamiento del protocolo DNS (Domain Name System), el cual ofrece un servicio de traduccin de una direccin simblica o nemotcnica en una direccin numrica o direccin IP de mquina. El procedimiento consiste en que un proceso cliente de DNS identificado con un nmero de puerto UDP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica con el proceso servidor de DNS identificado siempre en cualquier mquina servidora con el nmero de puerto 53 asociado al protocolo UDP. El proceso cliente de DNS se ejecuta en la propia mquina del usuario y el proceso servidor de DNS en la mquina servidora de la organizacin (o del proveedor de servicios). Si el proceso servidor de DNS, con el que interacta directamente el proceso cliente de DNS, no sabe traducir la direccin simblica en su formato numrico; entonces, se transforma en un proceso cliente de DNS de otro proceso servidor de DNS de superior jerarqua en la estructura por niveles del servicio DNS existente por Internet. Y as se proceder hasta encontrar (o no, dando por concluida la fase de bsqueda) la asociacin simblica-numrica invocada. Una vez encontrado el formato numrico solicitado, ste se transmite por el mismo camino de invocaciones. Es importante resaltar que en una organizacin se puede encontrar dos tipos de servidores DNS:
- 138 -
Servidores DNS primarios (Primary Name Servers): Almacenan la informacin de dominios en una base de datos local. Son responsables de mantener la informacin de los dominios actualizada, por lo que cualquier cambio en los datos o cualquier alta o baja de dominio debe ser comunicada a estos servidores. Servidores DNS secundarios (Secundary Name Servers): Se encuentran por debajo de los anteriores en la jerarqua, por lo que deben obtener de ellos los datos correspondientes a su zona de accin mediante un proceso de copia denominado transferencia de zona. Adems, estos servidores actan como sistemas de seguridad, al mantener la informacin de forma redundante, con lo que si un servidor DNS tiene problemas, la informacin se puede recuperar desde otro. Adems, evitan la sobrecarga del servidor principal, distribuyendo el trabajo entre distintos servidores situados estratgicamente con lo que se gana velocidad en las resoluciones.
2.18.9
Protocolo para el servicio Web: HTTP
En la Figura 2.97 se describe grficamente el protocolo HTTP (HyperText Transfer Protocol) del servicio World Wide Web (WWW o simplemente Web), el cual define un servicio distribuido de presentacin de la informacin basado en hiperenlaces que permite copiar una pgina en formato HTML (HyperText Markup Language) para su visualizacin o interpretacin local en la mquina del usuario. El procedimiento operativo consiste en que un proceso cliente de HTTP identificado con un nmero de puerto TCP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica con el proceso servidor de HTTP identificado siempre en cualquier mquina servidora con el nmero de puerto 80 asociado al protocolo TCP. En este contexto, es importante tener en cuenta que si un usuario desea disponer de su propio servidor Web y administrarlo no puede arrancarlo en el 80 porque es un nmero de puerto reservado exclusivamente para el administrador (root). Por tanto, una mquina servidora est controlada por un administrador que asocia a su servidor Web el nmero de puerto 80. De ese servidor Web cuelgan las pginas Web o ficheros de los usuarios. Pues bien, un usuario que quiera disponer de su propio servidor Web (servidor Web privado, el cual es diferente del servidor Web del administrador), y no slo de su pgina Web, arrancar dicho servidor en un nmero de puerto diferente al 80; generalmente, se suele poner el 8080 aunque se puede poner cualquier otro nmero no reservado como el 8000, el 3123, etc. Por ejemplo, en este caso la direccin sera http://nombre_mquina:8080, es decir, si no aparece al final de la direccin un nmero de puerto se asume por omisin el 80.
- 139 -
Hiperenlaces
HTTP
HTTP (HyperText Transfer Protocol) HTML (HyperText Markup Language) Cliente Web Servidor Web
HTTP
TCP
TCP IP
80
IP
Internet
Figura 2.97.- El servicio WWW. Por consiguiente, el proceso cliente HTTP se ejecuta en la propia mquina del usuario y el proceso servidor HTTP en la mquina servidora de la pgina Web solicitada. Como se ha indicado con anterioridad, la visualizacin de una pgina Web no se lleva a cabo de forma on line a travs de la red. Va HTTP se copia el cdigo HTML (HyperText Makeup Language) de la pgina en cuestin y se transporta por la red, almacenndose de forma temporal en un determinado directorio de la mquina local del usuario, que es, en realidad, en donde se visualiza sta. La sintaxis o el formato de direccin utilizado se conoce como URL (Universal Resource Locator) o localizador universal de recursos ya que permite referenciar a mquinas y servicios de manera uniforme. Consta de las dos partes (protocolo de acceso y referencia del objeto) que se muestran seguidamente.
2.18.9.1
Protocolo de acceso:// Referencia del objeto
Protocolo de acceso: Generalmente, se indica el protocolo HTTP (p.ej., http://nombre_computadora), pero podra referenciarse, por ejemplo, al protocolo FTP (p.ej., ftp://nombre_computadora) si se desean transferir ficheros de forma grfica y amigable (arrastrando con el ratn el correspondiente fichero desde la carpeta remota a la carpeta local), es decir, sin teclear comandos del tipo get/put. Asimismo, se puede invocar al protocolo TELNET (p.ej., telnet://nombre_mquina) para entrar directamente en el servicio de terminal remoto. Asimismo, tambin se podra mandar correo a un determinado usuario (p.ej., mailto: usuario2@identificador_mquina). Por consiguiente, el objetivo de este formato de direccin es claro: poder hacer uso de otros servicios de TCP/IP sin necesidad de salir del cliente Web o navegador del usuario.
- 140 -
Referencia del objeto: Su contenido depende del protocolo referenciado pero generalmente se suele poner nombre_mquina o nombre_mquina/directorio(s) o nombre_mquina/directorio(s)/fichero.
2.18.10
Protocolo de gestin de red: SNMP

CLIENTE (Gestor SNMP) Aplicacin de Gestin
Solicitudes Respuesta Suceso
SERVIDOR (Agente SNMP)

Manipulacin de objetos SNMP
Aplicacin de Gestin
Respuesta Solicitudes Suceso
MIB
Gestor SNMP
161 162
Mensajes SNMP
Agente SNMP
161
Management Information Base
UDP IP
UDP IP
Sistema SNMP gestor
Sistema SNMP gestionado
Figura 2.98.- Funcionamiento del protocolo SNMP. La Figura 2.98 muestra grficamente el protocolo SNMP (Simple Network Management Protocol) de gestin de red TCP/IP, el cual proporciona un servicio que permite recoger y transportar la informacin de gestin sobre los dispositivos conectados a una red TCP/IP. El procedimiento operativo consiste en que un proceso cliente de SNMP (gestor) identificado con un nmero de puerto UDP (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) se comunica con el proceso servidor de SNMP (agente) identificado siempre en cualquier mquina servidora con el nmero de puerto 161 asociado al protocolo UDP. Las respuestas salen por un nmero de puerto cualquiera (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) y entran siempre por el nmero de puerto 161. Asimismo, existen mensajes espontneos (Traps) transmitidos por el agente al gestor cuando detecta un suceso anormal o no habitual como puede ser la conexin o desconexin de una estacin o una alarma. En este ltimo caso, las respuestas salen por un nmero de puerto cualquiera (un nmero libre fuera del rango de nmeros reservados para aplicaciones estndares en Internet) y llegan siempre por el nmero de puerto 162. El gestor de SNMP recoge la informacin en forma de objetos o variables que se describen utilizando la sintaxis ASN.1 de OSI/ISO y se almacenan en una Base de Informacin de Gestin (MIB) soportada por la mquina que va a ser gestionada. Estas variables (MIB) tienen el mismo identificador en todas las mquinas. Una de las grandes ventajas de este protocolo de gestin frente a otros, es que se puede definir tantas variables como se deseen sin necesidad de aadir nuevos mensajes al protocolo. - 141 -
2.18.11
PING
Figura 2.99.- Opciones del servicio PING. Ping es un servicio70 del nivel de aplicacin que no sigue el modelo cliente-servidor y que permite, fundamentalmente, a un usuario comprobar en el nivel IP si una mquina est activa o en servicio en Internet o en una red privada TCP/IP. La visualizacin informativa sobre el servicio y opciones se lleva a cabo, segn se muestra en la Figura 2.99, mediante el comando ping o ping -?. En funcin del sistema operativo utilizado, aparecen ms o menos opciones. Por ejemplo, para Windows entre otras opciones se destacan las siguientes: -l: Permite especificar un nmero de octetos de longitud arbitraria en el campo de datos del mensaje ICMP de solicitud de eco (el cual ya se analizar). -f: Evita la fragmentacin del datagrama IP. -i: Especifica un nmero mximo de routers. -r: Permite registrar la ruta. -s: Permite especificar un sello o marca de tiempo.
70
No es un protocolo ya que no existe una entidad cliente Ping que interacte con otra entidad servidora Ping.
- 142 -
-k: Permite establecer un encaminamiento desde origen estricto (ya se estudiar ms adelante al analizar las opciones del protocolo IP). -j: Permite establecer un encaminamiento desde origen no estricto (tambin se estudiar ms adelante al analizar las opciones del protocolo IP). -... Como ya se analizar en su momento, ping l n_de_octetos f direccin_mquina_destino, proporciona la MTU71 (Maximum Transfer Unit) mnima en el camino desde un origen a un destino.
2.18.12
NETSTAT
Figura 2.100.- Opciones del servicio NETSTAT. Netstat es un servicio (y no un protocolo) del nivel de aplicacin que no sigue el modelo cliente-servidor y que permite a un usuario obtener estadsticas asociadas a algunos protocolos TCP/IP (IP, ICMP, TCP y UDP) y conexiones en curso. La visualizacin informativa sobre el servicio y opciones se lleva a cabo, tal y como se muestra en la Figura 2.100 mediante el comando netstat -?. En funcin del sistema operativo utilizado, aparecen ms o menos opciones. Por ejemplo, para Windows entre otras opciones se destacan las siguientes:
71
Unidad mxima de transferencia que cabe en el campo de datos de una trama
- 143 -
-a: Muestra todas las conexiones puertos de escucha. -e: Muestra estadsticas Ethernet. Se puede combinar con -s -n: Muestra nmeros de puertos y direcciones en formato numrico. -p proto: Muestra las conexiones del protocolo especificado por proto (TCP o UDP). -r: Muestra la tabla de encaminamiento. -s: Muestra las estadsticas de los protocolos IP, ICMP, TCP y UDP. -... Por ejemplo, si se teclea netstat a n se obtienen todos los sockets locales y remotos. Esto ltimo permite, entre otras acciones, comprobar de inmediato qu procesos servidores se estn ejecutando en la mquina local y a qu clientes se autoriza el acceso.
2.18.13
IPCONFIG
Figura 2.101.- Opciones del servicio IPCONFIG. IPCONFIG es un servicio (y no un protocolo) del nivel de aplicacin que no sigue el modelo cliente-servidor y que permite a un usuario obtener, entre otras informaciones, las relacionadas con el estado de los interfaces de red activos como puede ser, para cada interfaz, la direccin IP, mscara de subred, direccin de la tarjeta de red, etc. La visualizacin informativa sobre el servicio y opciones se lleva a cabo, tal y como se muestra en la correspondiente Figura 2.101, mediante el comando ipconfig -?. En
- 144 -
funcin del sistema operativo utilizado, aparecen ms o menos opciones. Por ejemplo, para Windows entre otras opciones se destaca la siguiente: -all: Muestra el nombre simblico local de la mquina, los servidores DNS (primario y secundario), direccin fsica local de la tarjeta de red de la mquina, direccin IP local de la mquina, mscara de subred, etc.
2.18.14
ARP
ARP es un servicio (y no un protocolo) del nivel de aplicacin que no sigue el modelo cliente-servidor y que, fundamentalmente, permite a un usuario obtener informacin sobre la tabla de traduccin de direcciones de IP a fsicas usadas por el protocolo de resolucin de direcciones (ARP). La visualizacin informativa sobre el servicio y opciones se lleva a cabo, tal y como se muestra en la Figura 2.102, mediante el comando arp o arp -?. En funcin del sistema operativo utilizado, aparecen ms o menos opciones. Por ejemplo, para Windows entre otras opciones se destaca la siguiente: -a: Muestra las entradas actuales de la tabla ARP.
Figura 2.102.- Opciones del servicio ARP.
2.18.15
TRACERT
Tracert (traceroute en Unix) es un servicio (y no un protocolo) del nivel de aplicacin que no sigue el modelo cliente-servidor y que, fundamentalmente, permite a un usuario conocer los routers que han intervenido en el camino origen-destino. El nico parmetro obligatorio es la mquina destinataria. La visualizacin informativa sobre el servicio y opciones se lleva a cabo, tal y como se muestra en la Figura 2.103, mediante el comando tracert o tracert -?. En funcin del sistema operativo utilizado, aparecen ms
- 145 -
o menos opciones. Por ejemplo, para Windows entre otras opciones se destacan las siguientes: -h mximo_de_saltos: Permite especificar la mxima cantidad de saltos en la bsqueda del objetivo.
Figura 2.103.- Opciones del servicio TRACERT. -j lista_de_hosts: Permite especificar un encaminamiento desde origen no estricto. Existen numerosos programas shareware y freeware que permiten realizar comandos TRACERT de forma grfica, mostrando en un mapa a nivel mundial la ruta que siguen los mensajes ICMP de solicitud de eco desde la mquina origen a la de destino.
2.18.16
ROUTE
Figura 2.104.- Opciones del servicio ROUTE. Route es un servicio (y no un protocolo) del nivel de aplicacin que no sigue el modelo cliente-servidor y que permite a un usuario gestionar la tabla de encaminamiento, es
- 146 -
decir, visualizarla o modificarla estticamente (manualmente). La visualizacin informativa sobre el servicio y opciones se lleva a cabo, tal y como se muestra en la Figura 2.104, mediante el comando route o route -?. En funcin del sistema operativo utilizado, aparecen ms o menos opciones. Por ejemplo, para Windows entre otras opciones se destacan las siguientes: Route PRINT: Muestra el contenido de la tabla de encaminamiento (netstat r tambin ofrece esa informacin). Route ADD: Agrega una ruta. Route DELETE: Elimina una ruta Route CHANGE: Modifica una ruta existente....
2.18.17
NSLOOKUP
Figura 2.105.- Opciones del servicio NSLOOKUP. NSLOOKUP es un protocolo del nivel de aplicacin que sigue72 el modelo clienteservidor y permite a un usuario73, resolver problemas con el Sistema de Nombres de Dominio (DNS), tales como la resolucin del nombre de una mquina (p. ej., obtener la
72
Se puede ver como una extensin del protocolo DNS. Por ejemplo con un sistema operativo Windows XP, 2000, NT o Unix (Windows 98 no lo soporta).
73
- 147 -
direccin simblica asociada a una direccin numrica). Este servicio permite consultar servidores de nombres de dominio mediante dos modos de operacin: Interactivo: Cuando se teclea slo nslookup sin argumentos. En este caso se utiliza el servidor DNS presente en la configuracin TCP/IP del equipo. Tambin se accede a este modo cuando el primer argumento es un guin y el segundo es el nombre simblico o la direccin IP de un servidor de nombres. No interactivo: Cuando se proporciona como primer argumento el nombre o la direccin IP del equipo del que se desea obtener informacin. El segundo argumento es entonces opcional y permite especificar el servidor DNS del que se desea obtener dicha informacin. Cuando se inicia nslookup en modo interactivo, ste muestra el nombre de la mquina y la direccin IP del servidor DNS que haya sido configurado en el sistema local (en la Figura 2.105, goofy.fi.upm.es/130.100.8.23), pasando a continuacin a mostrar un prompt >. Por ejemplo: >help: Muestra las diferentes opciones disponibles para este comando. Por ejemplo: nslookup nombre: Imprime informacin acerca del nombre de la mquina usando el servidor predeterminado. Consecuentemente, para buscar la direccin IP de un equipo a travs de DNS, se teclea el nombre del equipo y se pulsa INTRO. NSLOOKUP utilizar por omisin el servidor DNS configurado para la computadora en que est ejecutando; pero, si se desea, el comando puede configurarse para que utilice cualquier otro servidor DNS a travs del formato nslookup server <nombre>, en el que nombre es el nombre simblico del servidor que se desee utilizar.
- 148 -
2.19 Interfaces y computadoras virtuales

Hasta el momento se ha asumido que cuando una mquina est conectada a una red de comunicaciones como puede ser la red de rea local de una organizacin; dicha mquina dispone de una direccin IP asociada siempre a la direccin fsica o de tarjeta de red; lo cual es cierto en la mayora de los casos pero no siempre. En los sistemas operativos actuales existe la posibilidad de asignar ms de una direccin IP a un nico interfaz fsico o interfaz de la red de acceso, con lo cual se crea lo que se denomina en el argot como interfaz o computadora virtual. La idea es disponer de un interfaz virtual sobre el interfaz fsico existente y configurar ese interfaz virtual como si fuera real con el objetivo de tener ms de una direccin IP asociada a dicho interfaz fsico. O lo que es lo mismo, dar la apariencia de que existen dos o ms tarjetas de red o, visto tambin de otra forma, dar la sensacin de que existen dos o ms mquinas. Este tipo de configuracin, por ejemplo, es muy interesante para un ISP que a travs de su servidor HTTP o servidor Web puede mantener diferentes pginas Web de sus clientes en una misma mquina. Si la mquina en cuestin dispone, por ejemplo, de dos direcciones IP para el mismo interfaz fsico, podra mantener dos pginas Web distintas, es decir, una para cada direccin IP. Obviamente, en el servidor DNS del ISP tiene que estar registradas las correspondencias entre las dos direcciones simblicas y sus direcciones IP o numricas. Asimismo, y en funcin de lo anterior, el router del ISP tiene que ver dos mquinas diferentes en funcin de dichas direcciones IP. Seguidamente, se muestran dos ejemplos, el primero (ver Figura 2.106) haciendo uso de una direccin propia de la red del ISP, y en el segundo ejemplo (ver Figura 2.107) utilizando una direccin privada de la clase C.
ISP
220.10.1.1 A46EF45983AB TABLA ARP 220.10.1.2 A46EF45983AB DEL ROUTER . .
Mquina Virtual
220.10.1.1 220.10.1.2
eth0/eth0:1 eth0:1
220.10.1.3
Router
220.10.1.0
eth0
Internet
TABLA DE ENCAMINAMIENTO DEL ROUTER
eth0 220.10.1.6
220.10.1.4
220.10.1.5
Destino
220.10.1.0 220.10.1.0 ..
Ruta
Directa Directa .
Interfaz
eth0 eth0:1
Destino
220.10.1.0 ..
Ruta
Directa .
Interfaz
eth0
Interfaz Virtual Destino

220.10.1.0 ..
Ruta
Directa .
Interfaz
eth0
Figura 2.106.- Un interfaz virtual con una direccin propia de la red.
- 149 -
Con respecto a la anterior Figura 2.106, se muestra una mquina con dos direcciones 220.10.1.1 y 220.10.1.2 en la red de rea local del ISP (220.10.1.0). Las direcciones 220.10.1.1 y 220.10.1.2 son dos ms perteneciente a la misma red en cuestin. Sin embargo, la direccin 220.10.1.2 es una direccin que va a servir para especificar una direccin virtual que defina, a su vez, un interfaz o mquina virtual en la red 220.10.1.0. En el ejemplo se ha utilizado la nomenclatura del sistema operativo Linux para especificar los interfaces de salida. Por ejemplo, eth0 indica el interfaz fsico de la red de acceso y eth0:1, eth0:2, eth0:n, los correspondientes n interfaces virtuales de n mquinas virtuales. En relacin a la Figura 2.107, se muestra una mquina con dos direcciones 220.10.1.1 y 192.168.1.1 en la red de rea local del ISP (220.10.1.0). La direccin 220.10.1.1 es una ms perteneciente a la red en cuestin. Sin embargo, la direccin 192.168.1.1 es una direccin privada de la clase C que va a servir para especificar una direccin virtual que defina, a su vez, un interfaz o mquina virtual en la red 220.10.1.0.
ISP
220.10.1.1 A46EF45983AB TABLA ARP 192.168.1.1 A46EF45983AB DEL ROUTER . .
Mquina Virtual
eth0/eth0:1 eth0:1
220.10.1.3
Mquina Virtual
Router
192.168.1.0 220.10.1.0
eth0/eth0:1 eth0:1
Internet
220.10.1.1 192.168.1.1
220.10.1.4
eth0
192.168.1.6 220.10.1.6
220.10.1.5
Destino
220.10.1.0 192.168.1.0 ..
Ruta
Directa 220.10.1.6 .
Interfaz
eth0 eth0:1
Destino
220.10.1.0
192.168.1.0 ..
Ruta
Directa
Directa .
Interfaz
eth0
eth0:1
Interfaz Virtual Destino

220.10.1.0 192.168.1.0 ..
Ruta
Directa 220.10.1.6 .
Interfaz
eth0 eth0
Interfaz Virtual
Figura 2.107.- Un interfaz virtual con una direccin privada clase C. Como la organizacin desea seguir manteniendo su infraestructura fsica basada en una nica red de rea local, pero soportando dos direcciones IP74 (220.10.1.0 y 192.168.1.0), recurrre a la creacin de una mquina o interfaz virtual para la direccin 192.168.1.0. Como se puede apreciar, hay una mquina denominada virtual (192.168.1.1) con distinto direccionamiento que el del resto de mquinas que est conviviendo en la
74
Para el nivel de Internet o nivel IP de la arquitectura TCP/IP existen dos redes IP.
- 150 -
misma red; sin embargo dichas mquinas con respecto a la mquina virtual no se ven, es decir, no pueden comunicarse directamente si no es a travs del correspondiente router. A su vez, este router tiene que tener dos direcciones diferentes, por ejemplo, 220.10.1.6 y 192.168.1.6, una de cara a la red 220.10.1.0 y otra en funcin de la red 192.168.1.0. Otra aplicacin de los interfaces virtuales es, por ejemplo, cuando se agotan las direcciones oficiales de una organizacin y su ISP le proporciona un nuevo rango diferente de direcionamiento; pero la citada organizacin desea conservar la misma infraestructura de red sin crear otra nueva para soportar las nuevas direcciones. Este escenario, muy parecido al ltimo visto, se refleja en la siguiente Figura 2.108.
Organizacin
200.25.15.2 200.25.15.3
220.10.1.1 A5E648FF3AC2 TABLA ARP 200.25.15.1 00F5AB12CAB3 DEL ROUTER . .
Mquina Virtual
200.25.15.1
eth0
Router
200.25.15.0 220.10.1.0
220.10.1.1
220.10.1.2
eth0
eth0/eth0:1 eth0:1
Internet
220.10.1.3
200.25.15.6 220.10.1.6
Destino
220.10.1.0 200.25.15.0 ..
Ruta
Directa 220.10.1.6 .
Interfaz
eth0 eth0
Destino
220.10.1.0 200.25.15.0 ..
Ruta
Directa Directa .
Interfaz
eth0 eth0:1
Red Virtual
Destino
220.10.1.0 200.25.15.0 ..
Ruta
Directa 220.10.1.6 .
Interfaz
eth0 eth0
Interfaz Virtual
Figura 2.108.- Una misma red soportando dos direcciones IP. En esta Figura 2.108, se muestra una organizacin con una nica red de rea local y dos direcciones IP oficiales: 220.10.1.0 y 200.25.15.0. Esta organizacin dispona inicialmente de la direccin IP oficial 220.10.1.0 para conectar 254 mquinas que como mximo son las que se pueden conectar en una red de la clase C. Por consiguiente, solicita a su ISP un nuevo rango de direcionamiento, y recibe de ste, otras 254 direcciones nuevas a partir, ahora, de la direccin 200.25.15.0. Como la organizacin desea seguir manteniendo su infraestructura fsica basada en una nica red de rea local, pero soportando dos direcciones IP75 (220.10.1.0 y 200.25.15.0), recurrre a la creacin de mquinas o interfaces virtuales para la nueva direccin 200.25.15.0. Como se puede
75
Para el nivel de Internet o nivel IP de la arquitectura TCP/IP existen dos redes IP.
- 151 -
apreciar, existen mquinas con distinto direccionamiento que estn conviviendo en una misma red; sin embargo, al igual que antes, dichas mquinas no se ven unas a otras, es decir, no pueden comunicarse directamente si no es a travs del pertinente router. A su vez, este router tiene que tener dos direcciones diferentes, por ejemplo, 220.10.1.6 y 200.25.15.6, una de cara a la red 220.10.1.0 y otra en funcin de la red 200.25.15.0. Para finalizar, conviene resaltar que otra aplicacin muy til relacionada con los interfaces y computadoras virtuales es cuando un administrador desea llevar a cabo controles de acceso en el sentido de impedir a travs del router, el acceso de unas mquinas con un determinado direccionamiento a otras con un rango de direcciones diferente. Aparte, como ya se ha comentado, de poder configurar en una nica infraestructura de red diferentes redes virtuales sin necesidad de disponer de una red fsica diferente para cada rango distinto de direccionamiento. Esto ltimo puede ser muy til para llevar a cabo pruebas o experimentaciones sin coste alguno.
2.20 Escenarios bsicos para una configuracin TCP/IP

Seguidamente, y como complemento prctico, se va a proceder a llevar a cabo dos configuraciones76 TCP/IP para un mismo sistema final de usuario. Este sistema final va a disponer de dos tipos de conexiones con Internet que puede usar de forma alternativa y/o simultnea77: Una conexin a travs de la red de rea local de la organizacin, la cual est ya conectada a Internet Otra conexin alternativa y diferente a travs de un ISP mediante una lnea telefnica va mdem.
76
Para simplificar, se asume que la tarjeta adaptadora de red en un caso y el mdem en otro, han sido ya instalados y debidamente configurados. Previamente, existir una nica tabla de encaminamiento IP, inicialmente con la configuracin propia de la red de rea local de la organizacin. Posteriormente, esta tabla se actualizar dinmicamente, incluyendo otras entradas con la nueva informacin de encaminamiento que le transmite automticamente el ISP, va PPP, en funcin de su red y mquinas.
77
- 152 -
2.20.1 Conexin con Internet va una tarjeta de red

200.100.1.23 Servidor DNS principal
200.100.1.17
RED CORPORATIVA 200.100.1.0 255.255.255.0
200.100.1.1
Internet
Router externo
ganimedes.astros.com
Servidor DNS secundario 200.100.1.6

Organizacin
Figura 2.109.- Un ejemplo de escenario bsico para una configuracin TCP/IP. A continuacin, y en funcin del escenario definido en la Figura 2.109, se va a proceder a analizar78 los parmetros de la configuracin TCP/IP79 de una mquina de usuario cuyos datos son los siguientes: Direccin IP: 200.100.1.17 Mscara: 255.255.255.0 Nombre simblico: ganimedes.astros.com Dicho sistema final est conectado a la red de su organizacin (200.100.1.0/255.255.255.0), la cual dispone de dos servidores DNS y un router externo cuyos datos son, a su vez, los siguientes: Servidor DNS primario: 200.100.1.23 Servidor DNS secundario: 200.100.1.6 Router vecino (externo): 200.100.1.1
78
Por si es necesario cambiar alguno de ellos. P.ej., de Windows XP Professional de Microsoft.
79
- 153 -
Figura 2.110.- La configuracin TCP/IP del ejemplo. Primero y en la en la mquina de usuario (ver Figura 2.110), hay que seleccionar con el ratn, el botn Inicio (paso 1), y, seguidamente, la opcin Panel de control (paso 2).
Figura 2.111.- La configuracin TCP/IP del ejemplo. A continuacin (ver Figura 2.111), se selecciona (doble clic) la opcin Conexiones de red (paso 3) con el ratn.
- 154 -
4 5
Figura 2.112.- La configuracin TCP/IP del ejemplo. Seguidamente (ver Figura 2.112), aparece una ventana de Windows en donde se muestra un icono con el ttulo Conexin de rea local , el cual lo incluye Windows automticamente cuando se instala el sistema operativo80 y detecta la tarjeta adaptadora de red instalada en la mquina. A partir de ese momento, es decir, durante la instalacin del sistema operativo, Windows va solicitando al usuario los datos81 de la configuracin TCP/IP de dicha mquina. Posteriormente, se selecciona con el botn de la derecha (pasos 4 y 5) en el icono Conexin de rea local , la opcin de Propiedades para analizar y/o cambiar la configuracin ya realizada previamente durante la instalacin del citado sistema.
80
Windows XP incluye ya automticamente los protocolos TCP/IP durante la instalacin.
81
Direccin IP, Mscara de subred, Puerta de enlace predeterminada, Servidores DNS, etc. Estos datos, los cuales los registra el usuario durante la instalacin previa del sistema operativo, son los que se van a analizar seguidamente por si hay que cambiar alguno.
- 155 -
6 7
Figura 2.113.- La configuracin TCP/IP del ejemplo. Como resultado de todo lo anterior, aparece la ventana que se muestra en la Figura 2.113. A continuacin, se selecciona (paso 6) el elemento Protocolo Internet (TCP/IP) y, posteriormente, el botn de Propiedades (paso 7) que va a mostrar en otra ventana de Windows todos los parmetros de configuracin TCP/IP.
Figura 2.114.- La configuracin TCP/IP del ejemplo. Como resultado del paso anterior (paso 7), aparece una ventana con el ttulo Propiedades de Protocolo Internet (TCP/IP) y, por omisin, la solapa General (ver
- 156 -
anterior Figura 2.114). A partir de este momento se puede cambiar cualquier parmetro TCP/IP que se vaya mostrando. La opcin de Obtener una direccin IP automticamente se utiliza cuando se asigna una direccin IP al equipo desde un servidor de configuracin dinmica de mquina (DHCP) o desde una mquina de entrada de un ISP con acceso telefnico y protocolo punto a punto PPP. Esto ltimo es lo que tiene que estar seleccionado cuando el usuario est conectado en su casa a Internet a travs del telfono y mdem. Asimismo, se recuerda que se puede llevar a cabo un direccionamiento automtico (frente al direcconamiento esttico) a travs del protocolo de configuracin dinmica de mquina (DHCP) que asigna dinmicamente direcciones de IP privadas a todos los equipos de la red de la organizacin. A continuacin, si se pulsa en el botn de Opciones avanzadas (paso 8), aparece la ventana Configuracin avanzada de TCP/IP (ver Figura 2.115) a travs de la cual se pueden analizar o alterar otros parmetros de TCP/IP.
Figura 2.115.- La configuracin TCP/IP del ejemplo. En esta nueva ventana que se muestra en la Figura 2.115 se observa parte de las informaciones introducidas anteriormente como la direccin de la mquina del usuario y del router de entrada-salida de la organizacin o puerta de enlace (en terminologa Windows). Tambin, en esta nueva ventana se permite modificar un campo de la tabla de encaminamiento de IP llamado Mtrica que se utiliza para seleccionar automticamente el mejor enlace de entre varios (si existen) para llegar al mismo destino. Por ejemplo, si la mtrica est basada en el ancho de banda del enlace (mtrica
- 157 -
por omisin), el interfaz de mayor velocidad tiene la mtrica de interfaz ms baja. Resumiendo, si est activada82 la casilla de Mtrica automtica, la entidad IP selecciona automticamente el interfaz con la mtrica ms baja para un determinado destino.
10
11
12
Figura 2.116.- La configuracin TCP/IP del ejemplo. Si se selecciona la solapa de DNS (ver paso 10 en Figura 2.116), aparece toda la informacin relacionada con el sistema DNS de la organizacin. Seguidamente, pulsando con el ratn (paso 11) en Anexar estos sufijos DNS y en el botn Agregar (paso 12), se aade el formato o formatos simblicos que permiten buscar la direccin numrica de una mquina en los correspondientes servidores (primario-secundario) DNS. Por ejemplo, si se teclea ping ganmedes, la bsqueda se efectuar para ganmedes.astros.com. Los servidores se interrogarn en el orden de utilizacin especificado.
82
Por omisin, siempre est activada la opcin de Mtrica automtica.
- 158 -
2.20.2 Conexin con Internet va mdem a travs de un ISP
RED CORPORATIVA
(Ethernet)
Internet
mdem
DATOS DE LA CONEXIN
RED TELEFNICA
ISP
mdem
Nombre de usuario: gratis Contrasea: gratis DNS primario: 62.151.2.8 DNS secundario: 62.151.8.100 Nmero de nodo: 909274000
Figura 2.117.- Otro ejemplo de escenario bsico para una configuracin TCP/IP. Para efectuar una conexin con Internet va mdem a travs de un ISP, hay que realizar los pasos 1, 2 y 3 ya indicados en la anterior Figura 2.110 y Figura 2.111. Por tanto, para abrir Conexiones de red, se hace un clic en Inicio-Panel de control y, a continuacin, un doble clic en Conexiones de red. Una vez efectuado el paso 3 de la anterior Figura 2.111, para crear una conexin nueva telefnica va mdem se debe pulsar la opcin de Crear una conexin nueva (paso 4 de la Figura 2.118) en la ventana de Conexiones de red. Seguidamente, cuando aparece la ventana titulada Asistente para conexin nueva, se pulsa el botn Siguiente (paso 5 de la Figura 2.118).
- 159 -
Figura 2.118.- Una configuracin TCP/IP telefnica y va mdem. El resultado de todo lo anterior es la ventana de la Figura 2.119. Por omisin, est activada la opcin de Conectarse a Internet. A continuacin, se debe pulsar el botn Siguiente (paso 6).
Figura 2.119.- Una configuracin TCP/IP telefnica y va mdem. Seguidamente, en la nueva ventana que aparece (ver Figura 2.120), se selecciona la opcin Establecer mi conexin manualmente (paso 7) y se pulsa el botn Siguiente (paso 8).
- 160 -
Figura 2.120.- Una configuracin TCP/IP telefnica y va mdem. Despus de efectuar los pasos anteriores, el resultado es la nueva ventana que refleja la siguiente Figura 2.121. A continuacin, se pulsa la opcin Conectarse usando un mdem de acceso telefnico (paso 9) y el botn Siguiente (paso 10).
10
Figura 2.121.- Una configuracin TCP/IP telefnica y va mdem. En la ventana que refleja la siguiente Figura 2.122, se introduce el nombre del ISP (paso 11) y se pulsa de nuevo el botn Siguiente (paso 12).
- 161 -
11
12
Figura 2.122.- Una configuracin TCP/IP telefnica y va mdem. A continuacin, segn se indica en la siguiente Figura 2.123, se introduce el nmero de telfono del ISP (paso 13) y se pulsa otra vez el botn Siguiente (paso 14).
13
14
Figura 2.123.- Una configuracin TCP/IP telefnica y va mdem. Posteriormente, segn refleja la Figura 2.124, se introduce el nombre de usuario (paso 15), la contrasea correspondiente (pasos 16 y 17) y se pulsa el botn Siguiente (paso 18) para que el ISP distinga a este cliente de otros.
- 162 -
15 16 17
18 Figura 2.124.- Una configuracin TCP/IP telefnica y va mdem. El resultado de todo lo anterior es la ventana que se indica en la siguiente Figura 2.125. Los pasos 19 (agregar acceso directo en el escritorio) y 20 (Finalizar) terminan con este ltimo procedimiento de configuracin.
19 20
Figura 2.125.- Una configuracin TCP/IP telefnica y va mdem. Despus del paso 20, aparece la ventana que se describe en la siguiente Figura 2.126. A continuacin, se pulsa (paso 21) el botn de Propiedades.
- 163 -
21
Figura 2.126.- Una configuracin TCP/IP telefnica y va mdem. El resultado del paso anterior (paso 21), es la ventana que refleja la Figura 2.127, en la cual se debe seleccionar la solapa de Funciones de red (paso 22).
22
Figura 2.127.- Una configuracin TCP/IP telefnica y va mdem.
- 164 -
Seguidamente, en la nueva ventana que se muestra en la Figura 2.128, se selecciona (paso 23) el elemento Protocolo Internet (TCP/IP) y, posteriormente, el botn de Propiedades (paso 24) que va a mostrar en otra ventana de Windows todos los parmetros de la configuracin TCP/IP.
23
24
Figura 2.128.- Una configuracin TCP/IP telefnica y va mdem. Se resalta que en la anterior Figura 2.128, el protocolo PPP del interfaz de la red de acceso (Red Telefnica) con el ISP ya se seleccion durante la configuracin previa del mdem. Asimismo, se destaca que la ventana descrita en esta Figura 2.128, tambin se puede obtener a partir del paso 3 (ver Figura 2.111) comentado con anterioridad; y el resultado de dicha accin es la ventana que aparece en la siguiente Figura 2.129. En dicha ventana debe aparecer un icono telefnico con el nombre del ISP (Jazzfree), el estado (conectado o desconectado) y el tipo de mdem. Seguidamente, si se selecciona con el botn de la derecha (paso 21 bis) dicho icono telefnico para pulsar, posteriormente, con el botn de la izquierda (paso 22 bis) la opcin de Propiedades, aparece la misma ventana descrita en la anterior Figura 2.127. Dicho de otro modo, los pasos 21bis y 22bis de la Figura 2.129 equivalen al paso 21 de la Figura 2.126.
- 165 -
21bis
22 bis
Figura 2.129.- Una configuracin TCP/IP telefnica y va mdem. En definitiva, despus del paso 24 de la Figura 2.128 ya comentada, debe aparecer la ventana que muestra, a su vez, la Figura 2.130 con el objetivo de analizar, cambiar y/o incluir algunos parmetros de la configuracin ya realizada previamente durante la instalacin del mdem. No se debe alterar la opcin (por omisin) de Obtener una direccin IP automticamente y, en cambio, s se debe seleccionar la opcin que permite introducir los servidores DNS del ISP (pasos 25, 26 y 27).
25
26 27
Figura 2.130.- Una configuracin TCP/IP telefnica y va mdem.
- 166 -
2.21 Bibliografa
http://www.isoc.org/internet/history/brief.shtml: Leiner, B.; Cerf, V. G.; Clark, D.D.; Kahn, R. E.; , A Brief History of the Internet. http://www.rediris.es/rediris/boletin/32/enfoque2.html: Barber, J. Veinticinco aos de Internet: una retrospectiva autobiogrfica. Boletn de RedIRIS, 1995, pp. 23-34. RFC-1160: "The Internet Activities Board. TCP/IP Tutorial and Technical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Technical Support Organization, 2001. http://www.redbooks.ibm.com. http://www.aui.es/estadi/contini.htm: Asociacin de Usuarios en Internet. http://www.nic.es: Registro Delegado de Internet en Espaa. http://www.rediris.es: NOC de la Red Acadmica Espaola. http://www.ripe.net: Registro Delegado de Internet en Europa. http://www.iana.org: Autoridad de Asignacin de Recursos en Internet. http://www.icann.org: Entidad delegada de IANA. RFC-1160: The Internet Activities Board. http://ftp.rediris.es/ftp/docs/rfc/: Documentos RFC en RedIRIS (Red Espaola de I+D). http://www.rfc-editor.org/: RFC Editor Data Base. http://www.rfc-editor.org/rfcxx00.html: Documentos RFC no obsoletos. RFC-3000: Internet Official Protocolo Standards. RFC-2026: The Internet Standards Process -- Revision 3. RFC-2223: Instructions to RFC Authors. http://www.nic.es: Registro Delegado de Internet en Espaa. http://www.nominalia.es: Entidad Delegada del ICANN. http://www.iana.org: Autoridad de Asignacin de Recursos en Internet. http://www.icann.org: Entidad delegada de IANA. http://www.dnso.org/: DNSO http://www.dnso.org/constituency/gtld/gtld.html: gTLD registries RFC-1034: Domain Names - Concepts and Facilities. RFC-1035: Domain Names - Implementation and Specification. RFC-1032: Domain administrators guide. RFC-1033: Domain administrators operations guide. RFC-1591: Domain Name System Structure and Delegation. RFC-3071: Reflections on the DNS, RFC 1591, and Categories of Domains. RFC-1101: DNS Encoding of Network Names and Other Types. RFC-1480: The US Domain. RFC-1178: Choosing a Name for Your Computer. RFC-791: Internet Protocol. RFC-796: Address Mappings. RFC-1166: Internet Numbers. RFC-1700: Assigned Numbers.
- 167 -
RFC-3232: Assigned Numbers: RFC-1700 is Replaced by an On-line Database". RFC-2050: Internet Registry IP Allocation Guidelines. RFC-917: Internet Subnets". RFC-950: Internet Standard Subnetting Procedure. RFC-1219: On the Assignment of Subnet Numbers. RFC-1878: Variable Length Subnet Table For IPv4. RFC-919: Broadcasting Internet Datagrams. RFC-922: Broadcasting Internet Datagrams in the Presence of Subnets. RFC-1338: A Supernetting: an Address Assignment and Aggregation Strategy. RFC-1518: An Architecture for IP Address Allocation with CIDR. RFC-1519: Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy. RFC-1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment. RFC-1467: Status of CIDR Deployment in the Internet. RFC-1918: Address Allocation for Private Internets. RFC-1883: Internet Protocol, Version 6 (IPv6) Specification. RFC-1122: Requirements for Internet Hosts Communication Layers. RFC-1123: A Requirements for Internet Hosts -- Application and Support". RFC-2151: A Primer On Internet and TCP/IP Tools and Utilities. RFC-817: Modularity and Efficiency in Protocol Implementation. RFC-826: Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. RFC-903: Reverse Address Resolution Protocol. RFC-951: Bootstrap Protocol. RFC-2131: Dynamic Host Configuration Protocol. RFC-1055: Nonstandard for transmission of IP datagrams over serial lines: SLIP. RFC-1661: The Point-to-Point Protocol (PPP). RFC-2153: PPP Vendor Extensions. RFC-1334: PPP Authentication Protocols. TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Redes Globales de Informacin con Internet y TCP/IP, Principios bsicos, protocolos y arquitectura, Douglas E. Comer, 3 Edicin, Prentice Hall, 1996. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000. TCP/IP Illustrated Volume 1: The Protocols, R.W. Stevens, Addison-Wesley, 1994. Comunicaciones y Redes de Computadores, W. Stallings, 6 Edicin, Prentice Hall, 1997. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002.
- 168 -
Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. TCP/IP Arquitectura, protocolos e implementacin con IPv6 y seguridad de IP; Dr. Sydney Feit, Osborne McGraw-Hill, 1998.
- 169 -
- 170 -
Captulo 3. Nivel de Red de TCP/IP
3.
NIVEL DE RED DE TCP/IP
Seguidamente, se analizan las diferentes versiones existentes del protocolo IP para realizar el oportuno encaminamiento de datagramas desde un origen a un destino.
3.1
Protocolo IP de encaminamiento
INTERNET
Protocolos ROUTERS AVANZADOS (OSPF)
ICMP
IP
IGMP
ACCESO A RED
Interfaz de Red
Hardware
Figura 3.1.- El protocolo IP y sus vecinos en la arquitectura TCP/IP. IP es el protocolo por excelencia del nivel de red de la arquitectura TCP/IP y la clave o el quid tcnico del fenmeno Internet ya que a travs de l cualquier datagrama se puede encaminar por esta inmensa red de redes. Pero aparte de IP, existen ms vecinos o protocolos (como es el caso de OSPF, ICMP e IGMP) en el nivel de red (ver Figura 3.1), que se consideran como entidades ubicadas en un subnivel o estrato superior al encapsular sus mensajes en datagramas IP.
APLICACIN
APLICACIN
TCP
IP
INTERFAZ DE RED
INTERFAZ DE RED
TCP
IP
INTERFAZ DE RED
INTERFAZ DE RED
IP
INTERFAZ DE RED
IP
INTERFAZ DE RED
Figura 3.2.- Un ejemplo de escenario para IP.
- 171 -
Por consiguiente, el protocolo IP es el responsable del encaminamiento de datagramas por Internet entre una mquina de origen y otra mquina de destino, independientemente de que las mquinas de origen y destino se encuentren en la misma o en diferentes redes. La anterior Figura 3.2 muestra dos sistemas finales de usuario conectados, va IP, por tres subredes y dos dispositivos de encaminamiento.
Protocolo IPv4: RFC 791

Protocolo actual de encaminamiento TCP/IP mediante un servicio no orientado a conexin
Protocolo IPv6: RFCs 2460, 1809, 3513, 2874 y 1887

Protocolo futuro de encaminamiento TCP/IP mediante un servicio no orientado a conexin Adaptacin del Protocolo IP v4 para:
Incrementar el espacio de direcciones IP: 16 octetos Agilizar el encaminamiento La transmisin de audio y vdeo en tiempo real Transmisiones seguras
Figura 3.3.- Versiones del protocolo IP y sus caractersticas. Actualmente, para el encaminamiento por Internet existen dos tipos de versiones diferentes del protocolo IP (ver Figura 3.3), en concreto, las versiones 4 (que es la que funciona actualmente) y 6 (para futuros encaminamientos). Hubo en su momento una versin 5 para un protocolo IP experimental que no cuaj. Tanto IP en sus versiones 4 y 6, ofrecen siempre un servicio no orientado a conexin (no fiable) y, por tanto, sin control de errores ni de flujo. En este contexto, IPv6 conserva y adapta83 al protocolo IPv4, buscando una mayor frexibilidad y rapidez en futuros encaminamientos por Internet. Consecuentemente, la versin 6 se apoya84 en la versin 4 con las siguientes diferencias bsicas: Direccionamiento: Se pasa de 4 octetos a 16 octetos. Calidad de servicio: La versin 6 soporta mecanismos para la asignacin previa de recursos de red y poder ofrecer servicios de multimedia que requieran de unas garantas mnimas de ancho de banda y retardo de transmisin. Asimismo, la
83
Se queda con lo mejor y elimina lo peor. Comprendiendo bien la v4 es muy fcil entender la v6.
84
- 172 -
versin 6 proporciona mecanismos de seguridad para garantizar la autenticacin, confidencialidad, integridad y no repudio en las comunicaciones.
3.1.1 Protocolo IP versin 4
Protocolo clave de la arquitectura TCP/IP

Encaminamiento y fragmentacin
Ofrece un servicio no orientado a conexin

No hay control de errores ni flujo
Figura 3.4.- Caractersticas fundamentales del protocolo IPv4. Sgun se muestra en la Figura 3.4, IP ofrece siempre un servicio no fiable o no orientado a conexin y en su versin 4, aparte del encaminamiento, lleva a cabo funciones de: Fragmentacin : Por parte de las entidades IP intermedias (routers) Reensamblado: Por parte de la entidad IP de la mquina destinataria. Es importante resaltar que slo la entidad IP de la mquina destinataria reensambla un datagrama IP previamente fragmentado. Esto es as porque las entidades IP intermedias podran no tener todos los fragmentos ya que cada fragmento puede encaminarse de forma independiente. Asimismo, aun en el caso de que una entidad IP de un router reensamblara podra darse la potencial situacin de tener que fragmentar cuando la trama de informacin de la red de acceso no pueda contener, en su campo de datos, el datagrama reensamblado.
CABECERA
DATOS
Figura 3.5.- Formato del datagrama IPv4. Segn se describe en la Figura 3.5, el formato del protocolo IPv4 consta de dos tipos de informacin:
- 173 -
Cabecera: Tiene como mnimo, y por omisin, 20 octetos sin opciones de servicios adicionales. Datos: Encapsulan cabeceras de informacin de control de niveles superiores y potenciales datos de usuario que se han de transmitir. La longitud mxima de un datagrama (cabecera y datos) es de 64 KB (65.535 octetos).
4
VERSIN VERSI
4
Longitud Cabecera
8
TIPO DE SERVICIO
16
000 R C F 00
LONGITUD TOTAL
IDENTIFICADOR
TIEMPO DE VIDA
D M F F
DESPLAZAMIENTO
(TTL)
CABECERA
PROTOCOLO
SUMA DE COMPROBACIN COMPROBACI (CABECERA)
DIRECCIN ORIGEN DIRECCI DIRECCIN DESTINO DIRECCI

OPCIONES
RELLENO
DATOS
Figura 3.6.- Formato completo del datagrama IPv4. Los distintos campos de la cabecera de informacin de control de un datagrama IPv4 se muestran en la Figura 3.6. stos son los siguientes: Versin (4 bits): Indica la versin85 del protocolo IP. Longitud de la cabecera (4 bits): Especifica el nmero de bloques de 4 octetos de que consta la cabecera. Como mnimo la longitud es de 20 octetos (5 bloques de 4 octetos o un cinco como valor en decimal) sin opciones de servicios adicionales. Como mximo una cabecera de IP tiene 60 octetos (15 bloques de 4 octetos o un 15 en decimal o 1111 en binario) con todas las opciones de servicios adicionales posibles. Tipo o calidad de servicio del datagrama (8 bits):
85
Actualmente, la versin 4.
- 174 -
Los tres primeros bits indican la prioridad de procesamiento del datagrama en cuestin. Existen 8 niveles de prioridad: 000 (prioridad normal) - 111 (prioridad ms alta86). R: Bit de mnimo retardo de trnsito que la aplicacin desea para su datagrama desde un origen a un destino. Slo hay dos posibles valores: Normal o bajo. C: Bit de mximo caudal que la aplicacin desea para su datagrama desde un origen a un destino. Indica el nmero mximo deseado de bits transferidos por unidad de tiempo. Slo hay dos posibles valores: Normal o alto. F: Bit de mxima fiabilidad que la aplicacin desea para su datagrama desde un origen a un destino. Indica la proporcin deseada de datagramas perdidos, desordenados y duplicados frente al total enviado. Slo hay dos posibles valores: Normal o alta. Los dos bits que vienen a continuacin estn a cero (uso futuro). Actualmente (RFC-1349), de estos dos bits, se ha elegido el primero (o de mayor orden) para designar el coste monetario deseado por la aplicacin. Si est activo indica que se minimice dicho coste. Se pueden activar los parmetros de la cabecera de informacin de control IP o no por la correspondiente aplicacin, la cual pasa los valores asociados en una llamada al mdulo IP. En este contexto, la aplicacin slo puede activar un bit de los tres (R, C, F). Por ejemplo: Telnet: R = 1, C = 0, F = 0 FTP (control de la conexin): R = 1, C = 0, F = 0 FTP (datos): R = 0 , C = 1, F = 0 TFTP: R = 1, C = 0, F = 0 SNMP: R = 0, C = 0, F = 1 Cualquier IGP87 (RIP y OSPF): R = 0, C = 0, F = 1
86
Tpica prioridad del protocolo de gestin SNMP y de los protocolos IGP (Interior Gateway Protocol) de distribucin y actualizacin de la informacin de encaminamiento (que ya se estudiarn) como, por ejemplo, RIP y OSPF.
- 175 -
De esta manera, si un router dispone de varias lneas88 para alcanzar un determinado destino; entonces, elige aqulla que ms se ajuste al bit activado (R, C, F) de calidad de servicio para el correcto encaminamiento del datagrama en cuestin. Conviene resaltar, como ya se ha indicado, que existe un RFC-1349 que define una nueva mejora para el formato de la cabecera de control de IP. En concreto, en funcin de un nuevo valor en el campo del tipo de servicio (TOS), que minimiza el coste monetario de transmisin de un datagrama. El nuevo diseo definido, por el citado documento, es el que se muestra en la siguiente Figura 3.7.
0 1 2 3 4 5 6
7
PRECEDENCIA
TOS
Figura 3.7.- Nueva especificacin del campo TOS segn el documento RFC-1349. Ahora, el campo de TOS es de slo cuatro bits con el siguiente significado: 1000: Mnimiza el retardo. 0100: Mximiza el caudal. 0010: Maximiza la fiabilidad. 0001: Minimiza el coste monetario. 0000: Contenido del campo de TOS por omisin.
En este contexto, la precedencia se corresponde con los tres niveles de prioridad del documento RFC-791, mientras que el ltimo bit se deja para un uso futuro. Sin embargo, a pesar de tanta especificacin, conviene resaltar que en la prctica, la mayora de los routers ignoran todos los bits del campo de Tipo de Servicio especificado por los documentos RFC-791 y RFC-1349.
87
Como se ha comentado anteriormente un IGP (Interior Gateway Protocol) es un protocolo interno de actualizacin y distribucin de la informacin de encaminamiento. Su concepto se analizar ms adelante. Por ejemplo, una conexin va satlite de alta capacidad y retardo alto, una lnea telefnica de poca capacidad, etc.
88
- 176 -
Longitud total (16 bits): Indica la longitud mxima en octetos de un datagrama (cabecera y datos). Dicha longitud es de 64 KB (65.535 octetos = 11111111 11111111). Identificador (16 bits): Es el nmero asignado, por omisin, a todo datagrama e identifica a los potenciales fragmentos pertenecientes a un mismo datagrama. Un bit a cero (uso futuro). DF: Bit de no fragmentar. Est activado cuando la aplicacin no desea que se fragmente su datagrama por el camino ya que slo el datagrama completo es til. MF: Bit de ms fragmentos. Indica que, a continuacin, vienen ms fragmentos pertenecientes al mismo datagrama. El ltimo fragmento lleva este bit desactivado. Desplazamiento (13 bits): Indica el nmero de bloques de 8 octetos contenidos en el campo de datos en fragmentos anteriores. Tiempo de vida (TTL): Concepto abstracto que en realidad define el nmero mximo de routers (255) que el datagrama puede atravesar en Internet desde un origen a un destino. Cada entidad IP intermedia (router) decrementa en una unidad el valor almacenado en este campo. Si el resultado es cero, se elimina el datagrama. Si el valor es diferente de cero se actualiza el campo con el nuevo valor. Protocolo (8 bits): Es un nmero que identifica el protocolo superior (TCP = 6, UDP = 17, OSPF = 89, ICMP = 1, IGMP = 2...) al cual IP debe entregar los datos transportados por el datagrama. Suma de comprobacin (16 bits): Suma aritmtica binaria o en mdulo 2 sin acarreos de todos los bloques de 16 bits de que consta la cabecera (slo se aplica a la cabecera y no a los datos). Es importante resaltar que slo hay deteccin de errores fsicos y no recuperacin de stos ya que el servicio IP es no orientado a la conexin. Por tanto, si un datagrama aparece con errores fsicos en su cabecera, dicho datagrama se elimina y no se recupera en el nivel de red. Direccin de origen (32 bits): Los cuatro octetos que identifican a la mquina de origen del datagrama. Direccin de destino (32 bits): Los cuatro octetos que identifican a la mquina de destino del datagrama.
- 177 -
Opciones: Es un campo de informacin de control de longitud variable para servicios adicionales. Puede haber 0, 1 o ms opciones. Relleno: Son los bits que se aaden al campo de opciones para conseguir que la cabecera tenga una longitud total mltiplo de 4 octetos. Toda entidad IP en el camino origen-destino lleva a cabo una rutina de comprobacin de la cabecera que analiza los siguientes campos: Suma de comprobacin. Versin. Longitud de la cabecera. Longitud total. Tiempo de vida. Si todo es correcto, la entidad IP procede a encaminar el datagrama aplicando las mscaras y la informacin de su tabla de encaminamiento.
TIPO
8 bits
COPIA
LONGITUD
8 bits
CLASE
DATOS OPCIN
...
NMERO OPCIN
1 bit
2 bits
5 bits
SEGURIDAD: Nivel de confidencialidad ENCAMINAMIENTO DESDE ORIGEN: Estricto y no estricto REGISTRO DE RUTA: Identificacin IP de cada router SELLO DE TIEMPO: Identificacin del momento en que un router procesa un datagrama .............................................. ..............................................
Figura 3.8.- Formato de las opciones de servicio IP. La Figura 3.8 muestra el formato de las opciones de servicios adicionales IP en funcin de los siguientes campos: Tipo: Indica el tipo de la opcin en funcin, a su vez, de los siguientes tres campos. Copia (1 bit): Indica si el campo de opcin se debe copiar en todos los fragmentos (bit activado) o slo en el primero (bit desactivado). - 178 -
Clase (2 bits): Indica la clase general de la opcin. Bsicamente hay dos opciones: Control de red: Es la clase por excelencia y agrupa a todos los nmeros de opciones que se van a ver a continuacin. Depuracin y medicin (gestin).
Nmero de la opcin (5 bits): Entre las opciones ms significativas se destacan las siguientes: Seguridad: Nivel de confidencialidad y restricciones de manejo de la informacin transmitida para evitar el encaminamiento de un datagrama a un router potencialmente peligroso. Encaminamiento desde origen: Especificacin de las direcciones de IP de los routers por donde debe pasar el datagrama. Hay dos tipos: Estricto: Indica la ruta estricta de routers. El datagrama debe pasar por todos y cada uno de ellos, es decir, no debe haber otro router entre medias. No estricto: Indica el itinerario de routers por donde siempre debe atravesar el datagrama, pero entre medias se puede pasar por cualquier otro router.
Registro de ruta: Permite a la mquina de origen crear una lista vaca y con suficiente espacio (en el campo de Datos Opcin) para que cada router que procese ese datagrama incluya su propia direccin IP. Sello de tiempo: Permite a la mquina de origen crear una lista vaca y con suficiente espacio (en el campo de Datos Opcin) para que cada router que procese ese datagrama incluya su propia direccin IP y una marca de tiempo de 32 bits que indique el momento en que proces el datagrama.
Longitud: Es un campo de 8 bits que indica la longitud total en octetos de la opcin. Datos de la opcin: Informacin para poder procesar debidamente la opcin.
- 179 -
1500 bytes
ID = 12345 MF=0 DESPLA=0 LT=1500
1020 bytes
ID = 12345 MF=1 DESPLA=0 LT=1020
500 bytes
ID = 12345 MF=1 DESPLA=0 LT=500
LD=1480
LD=1000
ID = 12345 MF=0 DESPLA=125 LT=500
LD=480
ID = 12345 MF=1 DESPLA=60 LT=500
LD=480
LD=480
ID = 12345 MF=1 DESPLA=120 LT=60
Longitud del campo Datos del datagrama IP
LD=40
ID = 12345 MF=0 DESPLA=125 LT=500
LD=480
Figura 3.9.- Un ejemplo de fragmentacin IP. La Figura 3.9 muestra un ejemplo del proceso de fragmentacin que lleva a cabo el protocolo IP. En el ejemplo hay tres redes de diferentes MTU (Maximum Transfer Unit) y dos routers que llevan a cabo las correspondientes fragmentaciones. Antes de ver el ejemplo, seis precisiones: 1. Se entiende por MTU la unidad mxima de transferencia que cabe en el campo de datos de una trama de informacin y que coincide con la mxima longitud de un datagrama. Se recuerda que cada enlace89 en Internet tiene una MTU de 576 octetos o mayor, es decir, todo enlace en Internet debe disponer de tramas de datos para poder transmitir sin fragmentacin datagramas de al menos 576 octetos. 2. La fragmentacin aumenta el nmero de cabeceras de informacin de control por Internet. Lo cual, obviamente, no es nada deseable ya que aumenta a su vez la carga de proceso en la red. Hay que tener en cuenta que al fragmentar, aumenta el procesamiento90 de la informacin de control en el nivel de red y nivel del interfaz de acceso a la red91. 3. La probabilidad de perder un datagrama se incrementa con la fragmentacin ya que la prdida de un solo fragmento provoca la prdida del datagrama completo.
89
Por ejemplo, un lnea serie o una red de rea local del tipo Ethernet. Hay que procesar ms datagramas y ms campos de la cabecera de IP. Hay que procesar ms tramas.
90
91
- 180 -
4. La entidad IP de la mquina destinataria arranca un temporizador de reensamblado cuando recibe un primer fragmento. Si el temporizador termina antes de que todos los fragmentos lleguen, se elimina el resto del datagrama, con lo cual ste se pierde. 5. El protocolo IP no limita los datagramas a un tamao pequeo, ni garantiza que los datagramas grandes sean entregados sin fragmentacin. La mquina de origen puede seleccionar cualquier tamao de datagrama que considere ms apropiado. Las especificaciones de IP establecen que los routers pueden aceptar datagramas con la longitud correspondiente al valor mximo de la MTU de las redes a las que estn conectados. Asimismo, se recuerda que todo enlace en Internet es capaz de manejar datagramas de al menos 576 octetos. Esto significa que se puede enviar por Internet un datagrama de al menos 576 octetos sin que ste sea fragmentado. 6. Cada rectngulo en la anterior Figura 3.9 muestra slo los campos ms significativos de la cabecera de IP a efectos de fragmentacin y reensamblado. stos son ID (Identificador), MF (Ms Fragmentos), DESPLA (Desplazamiento), LT (Longitud Total). Se asume que no existen opciones de servicio, con lo cual la longitud de la cabecera de IP es de 20 octetos. Despus de la cabecera vienen los datos que transporta el datagrama en cuestin. La longitud del campo de datos viene denotado en octetos por LD92. En este escenario, el primer router recibe un datagrama de 1500 octetos (20 + 1480) que es superior a la MTU (1020 octetos) de la segunda red; con lo cual, este primer router debe dividir dicho datagrama en dos fragmentos, los cuales encamina a la segunda red. En todos los fragmentos, salvo el ltimo, se pone lo mximo que quepa en el campo de datos de la pertinente trama de informacin. A su vez, el segundo router divide el primer fragmento en tres fragmentos ms, al exceder dicho primer fragmento el tamao de la MTU (500 octetos) de la tercera red. Finalmente, cuando todos los fragmentos pertenecientes a un mismo datagrama (mismo ID) lleguen, aunque sea desordenados, a la entidad IP de la mquina destinataria; dicha entidad va concatenando dichos fragmentos como si fuera un puzzle, utilizando el campo Desplazamiento, el cual no puede aparecer repetido en fragmentos diferentes. Se resalta el hecho de que cuando se trocea un fragmento con MF93 igual a 1, todos los nuevos fragmentos llevan tambin MF
92
Longitud del campo de Datos: Este campo no pertenece al datagrama, slo se utiliza para aclarar el ejemplo.
Un datagrama siempre lleva MF igual a 0 y un fragmento puede llevar MF igual a 0 si es el ltimo o a 1 si no lo es.
93
- 181 -
igual a 1 (incluido el ltimo). Asimismo, se destaca que los fragmentos pueden ir por diferentes caminos y llegar desordenados (e incluso ms fragmentados) dentro del tiempo de reensamblado esperado. La entidad IP final no tendr ningn problema al reconstruir el datagrama original ya que los desplazamientos van de menos a ms y nunca pueden repetirse.
3.1.1.1
Protocolo ICMP versin 4 de envo de mensajes de control

INTERNET
ICMP
Mdulo ICMP Mdulo IP
IP
ACCESO A RED
Interfaz de Red
Hardware
Figura 3.10.- Ubicacin del protocolo ICMP en la arquitectura TCP/IP. ICMP (Internet Control Message Protocol) es el protocolo de envo de mensajes de control en Internet y est tan ntimamente ligado al protocolo IP, que de hecho se puede ver como un mdulo ms dentro del propio mdulo o proceso IP. Ya que se ha estudiado el protocolo IPv4 se analizar, por tanto, el protocolo ICMPv4 (para IPv6 existe su correspondiente ICMPv6).
RFC 792 Protocolo de envo de mensajes de control (errores, informacin y diagnstico) en Internet
Origen del mensaje: Router o mquina destinataria del datagrama Destino del mensaje: Mquina origen del datagrama Nunca se transmite un mensaje ICMP entre routers
ICMP no hace ms fiable a IP

Figura 3.11- Caractersticas ms significativas del protocolo ICMP.
- 182 -
Los mensajes de control ICMP en Internet estn relacionados con errores, informacin y diagnsticos. El destino de un mensaje ICMP de errores es siempre94 la mquina de origen del datagrama en cuestin. Nunca se transmite un mensaje ICMP de errores entre routers o sistemas intermedios. Se recuerda que un mensaje ICMP se utiliza para enviar mensajes de control o aviso y no para hacer ms fiable al protocolo IP, el cual jams podr recuperar un datagrama.
B R3 R4 R2
R3 no puede entregar el datagrama a B por una mala configuracin de su tabla de encaminamiento
... R5
. ..
El mensaje ICMP se enva al origen A
R1
...
Figura 3.12.- Ejemplo del envo de un mensaje ICMP. La Figura 3.12 muestra un ejemplo del envo de un datagrama IP desde la mquina A a la mquina B. El router R3 no dispone de suficiente informacin en su tabla de encaminamiento y es incapaz de encaminar dicho datagrama al destino B en cuestin. Consecuentemente, R3 elimina el datagrama y enva un mensaje ICMP a la mquina de origen A. El datagrama que encapsula dicho mensaje, incluso, no tiene porqu ir por el mismo itinerario de routers que el datagrama inicial.
Cabecera ICMP
Datos
Cabecera IP
Cabecera trama
Figura 3.13.- Encapsulacin desde ICMP.
94
Salvo, como ya se indicar, para los mensajes de informacin y diagnsticos de solicitud de sello de tiempo, mscara o eco.
- 183 -
Como la mquina de origen a la cual va destinado un mensaje ICMP puede ser una mquina remota por Internet, los mensajes ICMP se encapsulan siempre en datagramas IP (ver anterior Figura 3.13). De ah que ICMP ocupe un subnivel superior al ocupado por el protocolo IP en el mismo nivel de Internet o red de la arquitectura TCP/IP.
0
Tipo
8
Cdigo
16
Suma de Comprobacin
31
Contenido variable dependiendo del Tipo y Cdigo
Figura 3.14.- Formato general de un mensaje ICMPv4. Como se indica en la Figura 3.14, todo mensaje ICMPv4 dispone de un formato en funcin de tres campos fundamentales: Tipo del mensaje ICMP. Cdigo del error: Una informacin adicional y especfica sobre el tipo del mensaje ICMP. Suma de comprobacin95 (checksum): Se aplica a todo el mensaje ICMP. Al igual que en IP slo hay deteccin de errores fsicos (bits cambiados) y eliminacin del mensaje sin recuperacin del mismo. A los tres campos anteriores sigue un contenido variable dependiendo del tipo y cdigo.
95
Mismo mecanismo de suma que en IP.
- 184 -
0
Tipo
Cabecera
8
Cdigo
16
Suma de Comprobacin
31
Parmetros Opcionales (32 bits)
Datos
Contenido variable dependiendo del Tipo y Cdigo
Figura 3.15.- Formato especfico de un mensaje ICMPv4. Particularizando ms, toda cabecera de ICMP consta de 8 octetos (ver Figura 3.15): 4 octetos para el tipo (8 bits), cdigo (8 bits) y suma de comprobacin (16 bits). 4 octetos para parmetros opcionales que unos mensajes ICMP utilizan y otros no (en este ltimo caso los 32 bits a cero).
Servicios Principales ICMP
...
ECO
TIEMPO EXCEDIDO
PARMETRO ININTELIGIBLE
MSCARA DE DIRECCIN
FRENADO DE ORIGEN
SELLO DE TIEMPO
DESTINO INALCANZABLE
REDIRECCIONAR
Figura 3.16.- Principales servicios del protocolo ICMPv4. La Figura 3.16 muestra los principales servicios ICMP identificados por los correspondientes mensajes de:
- 185 -
Destino inalcanzable.- Mensaje que enva: Un router: Fundamentalmente, cuando no sabe o no puede reenviar un datagrama a una red. Una mquina de destino: Cuando el protocolo o puerto especificado no est activo. Frenado de origen.- Este mensaje representa un servicio de control de flujo muy bsico y rudimentario para evitar que una entidad IP transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Lo enva tanto un router como la mquina de destino. Tiempo excedido.- Mensaje que enva: Un router: Cuando se ha excedido el Tiempo de Vida (TTL) del datagrama. Una mquina de destino: Cuando se ha excedido el tiempo de reensamblaje de un datagrama fragmentado. Parmetro ininteligible.- Mensaje que enva tanto un router como la mquina de destino cuando ocurre un problema lxico o sintctico con la cabecera de informacin de control de un datagrama IP. Eco.- Mensaje enviado (por la aplicacin PING) para comprobar que una mquina est activa o en servicio. Mscara de direccin.- Mensaje utilizado, generalmente, por una mquina sin disco, la cual previamente ha obtenido su direccin IP mediante RARP para conocer la mscara de la direccin de la red a la cual est conectada. Sello de tiempo.- Mensaje para sincronizar relojes entre mquinas y calcular el tiempo de retardo de trnsito entre ellas, es decir, el tiempo total requerido de ida y vuelta desde que se manda una solicitud y se recibe una respuesta. Redireccionar.- Es un mensaje que permite a un router informar a un sistema final de usuario contiguo (conectado a la misma red de acceso) de que hay otro router mejor que l para llegar a un determinado destino.
- 186 -
a) MENSAJE DE DESTINO INALCANZABLE

0
Tipo = 3
8
Cdigo = 0-15 No utilizado = 0
16
Checksum
31
Cabecera IP + 8 primeros octetos del campo Datos del datagrama original
(Cdigo = 0-15) 0: Red no alcanzable 1: Mquina destinataria no alcanzable (sin respuesta ARP) 2: Protocolo no alcanzable 3: Puerto no alcanzable 4: Fragmentacin necesaria y no realizada (DF = 1) 5: Fallo en el encaminamiento desde origen ..............................................
.............................................. 9: Comunicacin con la red destinataria prohibida por el administrador 10: Comunicacin con la mquina destinataria prohibida por el administrador 11: Red destinataria inalcanzable por el tipo de servicio 12: Mquina destinataria inalcanzable por el tipo de servicio ..............................................
Figura 3.17.- Formato de los mensajes de destino inalcanzable. La Figura 3.17 muestra el formato de un mensaje de destino inalcanzable, definido por un Tipo = 3 y Cdigos del 0 al 15 que indican ms explcitamente la categora de dicho mensaje. Asimismo, para una mayor informacin en la mquina de origen, se copia la cabecera de IP y los 8 primeros octetos del campo de datos del datagrama original. Como se coment anteriormente, lo enva tanto un router (bsicamente, cuando no sabe o no puede reenviar un datagrama a una red) como la mquina de destino (cuando el protocolo o puerto especificado no est activo). Cdigo 0: Red no alcanzable.- Slo lo generan los routers cuando hay un error en la direccin IP de destino o no disponen de suficiente informacin en la tabla de encaminamiento para encaminar el pertinente datagrama. Cdigo 1: Mquina destinataria no alcanzable (sin respuesta de ARP): Slo lo genera el router final (conectado a la misma red de acceso que la mquina de destino) cuando no obtiene respuesta de ARP. Cdigo 2: Protocolo no alcanzable: Lo genera el nivel de red de la mquina destinataria cuando el protocolo superior (TCP, UDP, OSPF, etc.) indicado en la cabecera de IP (campo de Protocolo) no est disponible. Cdigo 3: Puerto no alcanzable: Se genera a partir del nivel de transporte de la mquina de destino cuando el puerto destino no se corresponde con algn proceso en uso. - 187 -
Cdigo 4: Fragmentacin necesaria y no realizada: Lo genera un router cuando es necesario fragmentar (el tamao del datagrama IP es superior a la MTU de la red) y el bit DF est activado en la cabecera de informacin de control IP. Cdigo 5: Fallo en el encaminamiento desde origen: Lo genera un router cuando es imposible transitar al router especificado en la pertinente opcin IP (encaminamiento desde origen). ... b) MENSAJE DE FRENADO DEL ORIGEN
0
Tipo = 4
8
Cdigo = 0
16
Checksum
31
No utilizado = 0
Figura 3.18.- Formato de un mensaje de frenado del origen. La Figura 3.18 muestra el formato de un mensaje de frenado del origen, definido por un Tipo = 4 y Cdigo = 0. Asimismo, para una mayor informacin en la mquina de origen, se copia la cabecera de IP y los 8 primeros octetos del campo de datos del datagrama original. Como se coment anteriormente, lo enva tanto un router como la mquina de destino como servicio muy bsico de control de flujo para evitar que una entidad IP transmita ms rpidamente de lo que otra es capaz de almacenar y procesar. Por cada datagrama eliminado se transmite un mensaje ICMP. El origen ralentiza el trfico hasta que no reciba ms mensajes ICMP.
- 188 -
c) MENSAJE DE TIEMPO EXCEDIDO

0
Tipo = 11
8
Cdigo = 0 1 No utilizado = 0
16
Checksum
31
(Cdigo = 0-1) 0: Tiempo de Vida (TTL) del Datagrama Excedido 1: Tiempo de Reensamblado Excedido
Figura 3.19.- Formato de los mensajes de tiempo excedido. La Figura 3.19 describe el formato de un mensaje de tiempo excedido, definido por un Tipo = 11 y Cdigos del 0 al 1 que indican ms explcitamente la categora de dicho mensaje. Asimismo, para una mayor informacin en la mquina de origen, se copia la cabecera de IP y los 8 primeros octetos del campo de datos del datagrama original. Segn se ha indicado, lo enva tanto un router96 como una mquina de destino97. d) MENSAJE DE PARMETRO ININTELIGIBLE
0
Tipo = 12
Puntero
8
Cdigo = 0 1
16
Checksum
31
No utilizado = 0
(Cdigo = 0-1) 0: Falla un Parmetro (puntero identifica el octeto que caus el problema) 1: Falta un Parmetro (sin puntero)
Figura 3.20.- Formato de los mensajes de parmetro ininteligible.
96
Cuando se ha excedido el Tiempo de Vida (TTL) del datagrama. Cuando se ha excedido el tiempo de reensamblaje de un datagrama fragmentado.
97
- 189 -
La anterior Figura 3.20 muestra el formato de un mensaje de parmetro ininteligible, definido por un Tipo = 12 y Cdigos del 0 al 1 que especifican ms explcitamente la categora de dicho mensaje. Parte de la cabecera contiene un puntero (8 bits) que indica el octeto problemtico. Asimismo, para una mayor informacin en la mquina de origen, se copia la cabecera de IP y los 8 primeros octetos del campo de datos del datagrama original. Como ya se ha comentado, lo enva tanto un router como la mquina de destino cuando ocurre un problema lxico o sintctico (falla o falta un parmetro o campo) con la cabecera de informacin de control de un datagrama IP. e) MENSAJES DE SELLO DE TIEMPO: SINCRONIZACIN DE RELOJES Y ESTIMACIN DEL TIEMPO DE TRNSITO
0
Tipo = 13 14
8
Cdigo = 0
16
Checksum
31
Identificador
Nmero de Secuencia
Originar Sello de Tiempo
Recibir Sello de Tiempo
Transmitir Sello de Tiempo
(Tipo = 13-14) 13: Solicitud de Sello de Tiempo 14: Respuesta de Sello de Tiempo
Figura 3.21.- Formato de los mensajes de sello de tiempo. La Figura 3.21 describe el formato de los mensajes de solicitud y respuesta de sello de tiempo, definidos por un Tipo = 13 14 (solicitud o respuesta) y Cdigo = 0. Parte de la cabecera contiene un Identificador (16 bits) y un Nmero de secuencia (16 bits) para asociar solicitudes con respuestas. A su vez, el campo de datos del mensaje contiene los siguientes campos: Originar sello de tiempo: Lo rellena la mquina de origen justo antes de transmitir el mensaje de solicitud (mensaje de ida). Recibir sello de tiempo: Lo completa la mquina de destino justo despus de recibir el mensaje de solicitud (mensaje de vuelta). Transmitir sello de tiempo: Lo incluye la mquina de destino justo antes de transmitir el mensaje de respuesta (mensaje de vuelta). Los tiempos anteriores indican el nmero de milisegundos desde la medianoche en Tiempo Universal o UT (antes Tiempo del Meridiano de Grennwich o GMT). Como se - 190 -
indic con anterioridad, es el mensaje utilizado para sincronizar relojes entre mquinas y calcular el tiempo de retardo de trnsito entre ellas, es decir, el tiempo total requerido de ida y vuelta desde que se manda una solicitud hasta que se recibe una respuesta. Es importante resaltar que las mquinas en Internet mantienen su propia nocin de la hora actual. En este contexto, los relojes pueden variar demasiado y confundir a los usuarios especialmente en entornos de sistemas distribuidos. Mediante este tipo de mensajes ICMP (una de las tcnicas ms sencillas), se pueden sincronizar los correspondientes relojes; sin embargo, TCP/IP incluye otros protocolos ms sofisticados y diseados especialmente para estas labores como es el caso, por ejemplo, del protocolo NTP (Network Time Protocol). f) MENSAJES DE MSCARA
0
Tipo = 17 18
8
Cdigo = 0
16
Checksum Nmero de Secuencia
31
Identificador Mscara de Direccin
(Tipo = 17-18) 17: Solicitud de la Mscara de Direccin de Red 18: Respuesta de la Mscara de Direccin de Red
Figura 3.22.- Formato de los mensajes de mscara. La Figura 3.22 muestra el formato de los mensajes de mscara (solicitud y respuesta) de direccin de red, definidos por un Tipo = 17 18 (solicitud o respuesta) y Cdigo = 0. Parte de la cabecera contiene un Identificador (16 bits) y un Nmero de secuencia (16 bits) para asociar solicitudes (el nmero de solicitudes es configurable) con respuestas. A su vez, el campo de datos del mensaje en la respuesta contiene la correspondiente mscara de 32 bits. Como ya se ha comentado, es el mensaje utilizado, generalmente, por una mquina sin disco para conocer la mscara de la direccin de la red a la cual est conectada. Dicha mquina previamente ha obtenido su direccin IP mediante RARP.
- 191 -
g) MENSAJE DE REDIRECCIONAR
0
Tipo = 5
(Cdigo = 0-3) 0: Redireccionar para la Red 1: Redireccionar para la Mquina 2: Redireccionar por Tipo de Servicio y Red 3: Redireccionar por Tipo de Servicio y Mquina
8
Cdigo = 0-3
Direccin IP del Router
16
Checksum
31
R2 Datagrama Dirigido al router ptimo A R1 R3
Mensaje ICMP de Redireccionar (slo se enva a los sistemas finales de usuario)
Figura 3.23.- Formato de los mensajes de redireccionar. La Figura 3.23 describe el formato de un mensaje de redireccionar, definido por un Tipo = 5 y Cdigos del 0 al 3, en funcin del tipo de destino (red o mquina) y tipo de servicio de la cabecera de IP, que indican ms explcitamente la categora de dicho mensaje. Parte de la cabecera contiene la direccin IP del router (32 bits) ms ptimo para llegar al pertinente destino. Asimismo, para una mayor informacin en la mquina de origen, se copia la cabecera de IP y los 8 primeros octetos del campo de datos del datagrama original. Como se coment anteriormente, es un mensaje que permite a un router informar a un sistema final de usuario contiguo (conectado a la misma red) de que hay otro router mejor98 que l para llegar a un determinado destino. En la citada Figura 3.23, R1 al recibir un datagrama para un destino B, y partiendo de su informacin de encaminamiento, indica a la mquina A que R2 es un router ms recomendable (hay menos saltos) para llegar a dicho destino.
98
O bien porque la ruta es ms corta o, simplemente, porque a travs de l no existe ningn trayecto.
- 192 -
h) MENSAJES DE ECO
0
Tipo = 8 0
(Tipo = 8 0) 8: Solicitud de Eco 0: Respuesta de Eco
8
Cdigo = 0
16
Checksum Nmero de Secuencia
31
Identificador
Datos opcionales de longitud arbitraria
PING/Solicitud de Eco (tipo 8)

A B
PING/Respuesta de Eco (tipo 8)
Figura 3.24.- Formato de los mensajes de eco. Finalmente, la Figura 3.24 muestra el formato de los mensajes de solicitud y respuesta de eco, definidos por un Tipo = 8 0 (solicitud o respuesta) y Cdigo = 0. Parte de la cabecera contiene un Identificador (16 bits) y un Nmero de secuencia (16 bits) para asociar solicitudes (el nmero de solicitudes es configurable) con respuestas. A su vez, el campo de datos del mensaje contiene unos octetos arbitrarios que introduce la propia implementacin y cuya longitud99 puede especificar el usuario. Como se ha indicado, es el mensaje utilizado por la aplicacin PING para comprobar que una mquina est activa o en servicio en Internet o en una red privada TCP/IP. Esto ltimo ocurre cuando se enva una solicitud y se recibe el eco (copia) de lo transmitido. Asimismo, ya se ha sealado que se pueden mandar tamaos diferentes de datos en cada solicitud de eco. El objetivo es el clculo de la MTU mnima en el trayecto origendestino para evitar potenciales fragmentaciones en el posterior envo de datagramas. Para ello, se indica en la correspondiente opcin (ping l n de octetos dir_IP destino) la longitud de la MTU de la red de acceso, especificando un DF = 1 (ping f dir_IP destino) para la cabecera de IP. Por consiguiente, si se teclea ping l n_de_octetos f direccin_mquina_destino y se reciben mensajes ICMP de destino inalcanzable definidos por un Tipo = 3 y Cdigo = 4 (fragmentacin necesaria y no realizada) es que hay que poner un tamao de datos inferior y as, se va procediendo sucesivamente, hasta no recibir ms mensajes ICMP notificando este tipo de error.
99
Por omisin, es de 32 octetos.
- 193 -
Ping: Servicios ICMP Solicitud y Respuesta de Eco IP: Cambiar el TTL No fragmentar un datagrama Encaminamiento desde origen: estricto y no estricto Registro de ruta Sello de tiempo ... Traceroute (Unix) o tracert (Windows): IP, ICMP y UDP IP TTL=1, TTL=2, ... Encaminamiento desde origen no estricto Servicios ICMP Solicitud y Respuesta de eco (slo tracert) Tiempo Excedido (tiempo de vida o TTL excedido) Destino Inalcanzable (puerto no alcanzable) (slo traceroute) Datagramas UDP a puertos desconocidos (slo traceroute)
Figura 3.25- Aplicaciones ICMPv4. La Figura 3.25 muestra dos aplicaciones, Ping y Traceroute (Unix) o Tracert (Windows), que hacen uso de los servicios IP e ICMP. En concreto, segn se coment en su momento, la aplicacin Ping para conocer si una mquina est activa, emplea directamente el servicio de solicitud y respuesta de eco del protocolo ICMP. Asimismo, desde Ping y haciendo uso de sus correspondientes opciones, se puede especificar lo siguiente: TTL mediante ping i n de routers (por omisin 255). No fragmentar un datagrama (DF = 1) a travs de ping f. Encaminamiento desde origen: estricto (ping k lista_routers) y no estricto (ping j lista_routers). Registro de ruta mediante ping r Sello de tiempo mediante ping s ... Igualmente, hay otra aplicacin denominada Traceroute (en Unix) o Tracert (en Windows) que hace uso, a su vez, de los servicios:
- 194 -
IP e ICMP (solicitud-respuesta de eco y TTL excedido) en Windows. IP, UDP (datagrama UDP a un puerto no alcanzable o desconocido) e ICMP (TTL excedido) en Unix100. El objetivo es conocer los routers que han intervenido en el camino origen-destino. Dichos procedimientos se analizan a continuacin: 1. ENTORNO MICROSOFT (WINDOWS): La mquina origen transmite datagramas IP (con TTL = 1, 2, 3, etc.), encapsulando en todos ellos el mismo mensaje ICMP de solicitud de eco. Los routers responden con mensajes de ICMP de TTL excedido y, finalmente, la mquina destinataria hace lo propio con un mensaje ICMP de respuesta de eco. Concretamente, se acta de la manera siguiente: Tracert enva un primer datagrama IP con un TTL = 1 y encapsula en el campo de datos de dicho datagrama un mensaje ICMP de solicitud de eco. Como resultado de lo anterior, la entidad IP del primer router elimina el datagrama y enva a la mquina de origen un mensaje ICMP de tiempo excedido definido por un Tipo = 11 y Cdigo = 0 (Tiempo de vida o TTL excedido). Como el mensaje va encapsulado en un datagrama IP, de la cabecera de este datagrama se extrae la direccin del primer router (direccin de origen). Seguidamente, la aplicacin transmite un segundo datagrama con un TTL = 2, y encapsula nuevamente un mensaje ICMP de solicitud de eco en el campo de datos de dicho datagrama. Por tanto, la mquina de origen recibe del segundo router otro mensaje ICMP de TTL excedido con lo cual obtiene la direccin IP del segundo router. Y as se va procediendo sucesivamente hasta que se llega al destino. Como la entidad IP del sistema final no decrementa TTL en una unidad porque se ha llegado ya al destino, pasa el contenido del campo de datos (mensaje ICMP de solicitud de eco) a la entidad ICMP de dicho sistema. La mquina de destino responde a la mquina de origen con otro mensaje ICMP, en este caso de respuesta de eco (Tipo = 0 y Cdigo = 0). Como el mensaje va encapsulado en un datagrama IP, la mquina de origen extrae la direccin del sistema final (direccin de origen) de la cabecera de este datagrama. Consecuentemente, la informacin anterior indica a la aplicacin que se ha llegado al destino final.
100
Algunas distribuciones de Unix pueden disponer de las dos versiones de traceroute (con ICMP y UDP), tal es el caso de algunas versiones de Linux. En este ltimo caso, la eleccin depender del usuario final.
- 195 -
2. ENTORNO UNIX: La mquina origen transmite datagramas IP (con TTL = 1, 2, 3, etc.), encapsulando en todos ellos el mismo datagrama UDP a un puerto desconocido. Los routers responden con mensajes de ICMP de TTL excedido y, finalmente, la mquina destinataria hace lo propio con un mensaje ICMP de destino inalcanzable por puerto no alcanzable. En concreto, el procedimiento es como sigue: Traceroute enva un primer datagrama IP con un TTL = 1 y encapsula en el campo de datos de dicho datagrama IP, un datagrama UDP con un nmero de puerto destino (p.ej., el 62115) que se asuma que no est asociado con ningn proceso servidor operativo en la mquina de destino. Como resultado de lo anterior, la mquina de origen recibe del primer router un mensaje ICMP de tiempo excedido definido por un Tipo = 11 y Cdigo = 0 (Tiempo de vida o TTL excedido). Como el mensaje va encapsulado en un datagrama IP, de la cabecera de este datagrama se extrae la direccin del primer router (direccin de origen). Seguidamente, la aplicacin transmite un segundo datagrama con un TTL = 2, y encapsula, nuevamente en el campo de datos de dicho datagrama IP, un datagrama UDP con un nmero de puerto destino (p.ej., el 62115) que se asuma que no est asociado con ningn proceso servidor operativo en la mquina de destino. Por tanto, la mquina de origen recibe del segundo router otro mensaje ICMP de TTL excedido con lo cual obtiene la direccin IP del segundo router. Y as se va actuando sucesivamente hasta que se llega al destino. Como la entidad IP del sistema final no decrementa TTL en una unidad porque se ha llegado ya al sistema destinatario, pasa el contenido del campo de datos (datagrama UDP) a la entidad UDP de dicho sistema. La mquina de destino responde a la mquina de origen con otro mensaje ICMP, en este caso de destino inalcanzable por puerto no alcanzable (Tipo = 3 y Cdigo = 3). Como el mensaje ICMP va encapsulado en un datagrama IP, la mquina de origen extrae, de la cabecera de este datagrama, la direccin del sistema final (direccin de origen). Por consiguiente, la informacin anterior indica a la aplicacin que se ha llegado al destino final. Finalmente, conviene resaltar que esta aplicacin (tracert o traceroute), tanto en Windows como en Unix, permite especificar, como opcin IP, un encaminamiento desde origen no estricto. Adems, por cuestiones de seguridad algunos routers tienen deshabilitadas algunas respuestas del protocolo ICMP. Por ejemplo: Mensajes ICMP de tiempo excedido definido por un Tipo = 11 y Cdigo = 0 (Tiempo de vida o TTL excedido). Por ejemplo, de esta forma, algunos routers imposibilitan que a travs de un tracert se vean todas las mquinas activas desde un origen a un destino.
- 196 -
Mensajes ICMP de respuesta de eco (Tipo = 0 y Cdigo = 0). Por ejemplo, de esta manera algunas mquinas (routers y sistemas finales) no permiten que mediante un Ping alguien se entere de si una computadora est activa o no para posteriormente atacarla. Cualquier tipo de encaminamiento de cualquier mensaje ICMP. De esta manera se evita que por algunos itinerarios de routers en Internet, alguien quiera saber ms de lo que debe. Resumiendo, existe el riesgo de que al hacer un tracert (Windows), los routers tengan deshabilitados los mensajes ICMP de tiempo excedido con lo cual no se puede obtener la informacin deseada. La situacin todava se complica ms si, adems, son los sistemas finales los que tienen, a su vez, deshabilitados los mensajes ICMP de respuesta de eco. En el caso de traceroute (Unix) se est ante la misma situacin si los routers tienen deshabilitados los mensajes ICMP de tiempo excedido por mucho que el sistema final slo maneje mensajes ICMP de destino inalcanzable por puerto no alcanzable.
3.1.2 Protocolo IP versin 6
SERVICIOS MULTIMEDIA
Nuevo protocolo de interconexin de redes y encaminamiento para aplicaciones multimedia en Internet: IPv6
Diferencias con respecto al IPv4

Direccionamiento Calidad de servicio
Figura 3.26.- Caractersticas generales del protocolo IPv6. Como ya se ha comentado con anterioridad, el protocolo IP en su versin 4 ha sido y es de momento la clave del funcionamiento de Internet y la arquitectura TCP/IP. Pero esta versin est alcanzando el final de su vida til y, por tanto, ha sido necesario definir una nueva versin (IPv6) para dicho protocolo con el objetivo de que, en ltima instancia, reemplace a la ya existente. Todo ello, especialmente, cuando se trate de dar soporte de forma ms eficiente a las nuevas aplicaciones o servicios de multimedia que van apareciendo en Internet y que se basan en transmisiones de audio y vdeo en tiempo real con unas garantas mnimas de ancho de banda y retardo de propagacin. Es importante resaltar que, actualmente, en Internet ha aumentado espectacularmente el ancho de banda debido a las nuevas tecnologas de redes de comunicaciones basadas fundamentalmente en una infraestructura fsica de fibra ptica. - 197 -
El protocolo IPv6 conserva lo mejor y elimina lo peor de la anterior versin, aadiendo nuevas caractersticas all donde se necesiten. Se recuerda que las diferencias bsicas de la versin 6 con respecto a la versin 4 se resumen en dos apartados: Direccionamiento.- Se pasa de 4 octetos (32 bits) a 16 octetos (128 bits). Calidad de servicio.- La versin 6 soporta, entre otros mecanismos, la asignacin previa de recursos en la red con el objetivo de poder ofrecer una determinada calidad a los servicios de multimedia actuales. Concretando, el protocolo IPv6 se dise para un escenario operativo basado en lo siguientes puntos: Transmisiones de audio y vdeo en tiempo real.- Este tipo de transmisiones exigen unas garantas mnimas de ancho de banda y retardo de propagacin. Por consiguiente, lo anterior implica una asignacin previa de recursos por la red en el pertinente trayecto origen-destino. Mecanismos y servicios de seguridad: Autenticacin, confidencialidad, integridad y no repudio.- Cada vez ms, las aplicaciones exigen unos servicios de seguridad que garanticen la salvaguardia de las transmisiones por la red. Incremento de la carga de trfico en Internet.- Muchas de las aplicaciones actuales requieren de un encaminamiento por el tipo de informacin transmitida y no slo por la direccin destinataria. En este contexto, no es lo mismo transmitir un simple mensaje de texto que un vdeo bajo demanda. Uso creciente de los protocolos TCP/IP en nuevas reas.- Actualmente TCP/IP se ha introducido en distintos escenarios como, por ejemplo, los siguientes: Terminales electrnicos de puntos de venta en los comercios. Receptores de televisin y vdeo bajo demanda. Electrodomsticos (p.ej., un frigorfico conectado va Internet al supermercado de El Corte Ingls y al servicio de reparacin tcnica del aparato) Telefona mvil y ordenadores porttiles inalmbricos. Esto quiere decir que cada da se hace ms necesario asignar direcciones de IP de forma permanente y nica a todas las mquinas de diferentes tipos, tecnologas y servicios que desean conectarse a Internet. Por consiguiente, dicha
- 198 -
necesidad centrada en una demanda de direcciones nicas IP, implica un nuevo diseo del protocolo IPv4 en cuanto a: Incrementar el espacio de direcciones de IP. Modificar el formato de direcciones.- La estructura en dos niveles (redmquina) del protocolo IPv4 es muy poco econmica. Muchas veces las organizaciones no aprovechan todo el espacio de direccionamiento que les ha sido asignado. En respuesta a todas estas necesidades, el IETF emiti una solicitud de propuestas para un IP de nueva generacin (IPng) en julio de 1992. Se recibieron las siguientes tres propuestas: TCP sobre CLNS (ConnectionLess Network Service) de ISO.- El objetivo consista en montar TCP sobre el servicio de red no orientado a conexin del modelo OSI de ISO. Un nuevo IP muy sofisticado.- El resultado era un protocolo IP muy complejo que incrementaba demasiado el procesamiento de los datagramas. Conservar IPv4 y adaptarlo (1993).- A travs de una serie de extensiones se emiti una propuesta extendida que incluy la combinacin de ideas de otras propuestas. Esta propuesta fue la ganadora y su contenido defina un Protocolo Simple de Internet Mejorado (SIPP: Simple Internet Protocolo Plus) que pas a denominarse IPv6. El diseo original se conoci como SIP (Simple IP) y constituy la base para una propuesta extendida (SIPP: SIP Plus) que inclua ideas de otras propuestas.
TCP sobre CLNS de ISO Un nuevo IP muy sofisticado Conservar IPv4 y adaptarlo (1993): Propuesta extendida que incluy la combinacin de ideas de otras propuestas
Protocolo Simple de Internet Mejorado (SIPP: Simple Internet Protocol Plus) = IPv6
Figura 3.27.- Solicitud de propuestas para un IPng. La documentacin del protocolo IPv6 se basa en los siguientes RFC:
- 199 -
RFC-2460: Especificacin general RFC-1809: Etiquetas de flujo en la cabecera RFC-3513, 2874 y 1887: Direccionamiento RFC-2463: ICMPv6.- Este documento RFC describe el protocolo de envo de mensajes de control en Internet para IPv6, cuyas principales caractersticas se indican a continuacin: Mismo formato de cabecera que en ICMPv4 (8 octetos: tipo(1), cdigo(1), suma de comprobacin(2) y parmetros (4)). Tamao mximo de los mensajes incluyendo cabeceras de 1280 octetos101 (generalmente 36 octetos102 en ICMPv4). Mensajes de error: Destino inalcanzable, Paquete demasiado grande, Tiempo excedido, Problemas de parmetros.
Con respecto a las caractersticas fundamentales del protocolo IPv6, stas son casi idnticas que las del protocolo IPv4: Protocolo responsable del encaminamiento por Internet. Ofrece un servicio no orientado a conexin. No hay control de errores ni de flujo. Los cambios del protocolo IPv6 se resumen en una simplificacin de la cabecera, fundamentalmente, en cuanto a que en el caso de IPv6, sta se basa en un formato flexible de cabeceras de extensin opcionales que busca como uno de sus principales objetivos, reducir el tiempo de procesamiento del datagrama en los routers y, por consiguiente, agilizar el correspondiente encaminamiento. Alineacin en mltiplos de 8 octetos (en IPv4 eran 4 octetos)
En el RFC-1883 (IPv6), la MTU mnima era de 576 octetos. Posteriormente, en el RFC-2460 (IPv6) que deja obsoleto al RFC-1883, se indica una MTU mnima de 1280 octetos.
102
101
Teniendo en cuenta los 8 primeros octetos de la cabecera de ICMPv4 ms el contenido del campo de datos de ICMP que incluye en la mayora de los mensajes de ICMP, los 20 octetos de la cabecera de IP y los 8 primeros octetos de campo de datos del datagrama original.
- 200 -
El campo denominado Longitud Cabecera en IPv4 se ha eliminado en IPv6 que dispone de una cabecera fija y obligatoria de 40 octetos. El campo denominado Longitud Total en IPv4 (65.535 octetos) se redenomina Longitud de Carga til en IPv6 (65.535 octetos). Dicho campo excluye la cabecera fija de IPv6 e incluye las correspondientes cabeceras opcionales y la unidad de datos del protocolo o PDU (Protocol Data Unit). Los campos de Direccin de Origen y Destino de IPv6 son de 16 octetos. La Informacin de Fragmentacin se ha movido de campos fijos (IPv4) a una Cabecera de Extensin Opcional en IPv6. La Suma de Comprobacin (IPv4) se ha eliminado103 en IPv6. El campo de TTL en IPv4 (8 bits) se redenomina Lmite de Saltos en IPv6 (8 bits). Ahora el nombre indica lo que en realidad significa. El campo de TOS en IPv4 (8 bits) se redenomina Etiqueta de Flujo en IPv6 (16 bits). El campo de Protocolo en IPv4 (8 bits) se redenomina Cabecera Siguiente en IPv6 (8 bits) Las mejoras del protocolo IPv6 se cimentan en lo siguiente: Espacio de direcciones ampliado: 16 octetos (128 bits). Prcticamente, se dispone de un espacio ilimitado de direcciones de IP para las nuevas necesidades actuales de asignacin de direcciones ya comentadas. Nuevo mecanismo de opciones de servicio adicionales: Formato flexible de cabeceras de extensin opcionales Un ejemplo, es la informacin de fragmentacin que se ha movido, como ya se ha indicado, a una cabecera de extensin opcional con el objetivo de que la fragmentacin y reensamblado se lleve a cabo slo en los sistemas finales. Dado que por la propia infraestructura de las redes fsicas que conforman Internet, es necesario realizar la no deseada fragmentacin; sta slo se va llevar a cabo en la mquina de origen, dejando el reensamblado para la mquina de destino.
103
El protocolo TCP ya realiza su propia deteccin de errores fsicos. UDP lo realiza opcionalmente.
- 201 -
Formato flexible de direccionamiento. Existen tres tipos de direcciones de IPv6: Unidifusin o unicast.- Se basa en un proceso de envo de uno o ms datagramas IP desde un origen a un nico destinatario o receptor final. Multidifusin o multicast.- Se basa en un nico proceso de envo104 de uno o ms datagramas IP desde un origen a todos los miembros de un grupo de potenciales destinatarios que comparten una misma direccin de multidifusin y, posiblemente, dispersos geogrficamente en mltiples redes por Internet. Segn se coment en su momento, los routers intermedios de multidifusin tienen que poseer la capacidad necesaria para hacer las copias necesarias, de la informacin transmitida, desde el origen a las correspondientes mquinas destinatarias. La difusin (broadcast) en IPv6 se considera un caso particular o una forma especial de la multidifusin. Por tanto, IPv6 no emplea el trmino difusin o broadcast sino el trmino multidifusin. Consecuentemente, todas las mquinas de una red se consideran como un grupo de multidifusin y, por tanto, una direccin de difusin se puede soportar con una direccin de multidifusin. Monodifusin o anycast.- Se basa en un nico proceso de envo de uno o ms datagramas IP desde un origen al miembro ms cercano de un grupo de potenciales destinatarios que comparten una misma direccin de monodifusin. Una direccin de monodifusin aunque identifica a varios interfaces se enva slo al interfaz ms cercano al origen. Por tanto, si una direccin de multidifusin se utiliza para una comunicacin de 1 a n con una entrega a n interfaces; una direccin de monodifusin se utiliza, a su vez, para una comunicacin de 1 a n con entrega a un nico interfaz. Con el objetivo de facilitar la entrega al miembro del grupo de monodifusin ms cercano, se tienen que tener en cuenta las distancias a todos los interfaces del grupo en trminos de mtricas de encaminamiento. Consecuentemente, cuando una mquina de origen desea enviar un datagrama a una direccin de monodifusin debe utilizar un mecanismo de descubrimiento de la mquina ms cercana propietaria de la direccin. Las direcciones de monodifusin an tienen algunas limitaciones segn se va progresando en su investigacin. Actualmente,
104
Sin transmitir desde el origen una copia por separado de cada datagrama a cada destinatario.
- 202 -
estas direcciones slo se usan como direcciones de destino y se asignan slo a los routers de una organizacin y no a sus sistemas finales. Por consiguiente, la comunicacin se establece entre la mquina de origen y el router ms cercano configurado con la correspondiente direccin de monodifusin. Un ejemplo de aplicacin potencial para este tipo de transmisin podra ser el caso de un servidor de hora o de monitorizacin de noticias. Se podra tener un grupo de monodifusin de servidores de hora o de noticias y que slo enviara la informacin correspondiente el servidor ms cercano. Si ste no estuviera operativo, contestara el siguiente ms cercano y as sucesivamente. Soporte para la asignacin previa de recursos en red. Como ya se ha comentado, el objetivo es ofrecer unas garantas mnimas de ancho de banda y retardo de propagacin. Capacidades de seguridad. Se implementan unos mecanismos de seguridad que ofrezcan los correspondientes servicios de autenticacin, confidencialidad, integridad y no repudio. Particularizando un poco ms, el diseo del formato de un datagrama IPv6 se basa en que: Las cabeceras de extensin IPv6 se han definido de forma similar a las opciones IPv4, pero con las siguientes diferencias: Existen nuevas opciones que incluyen servicios adicionales. Se evita que los datagramas compartan campos que no utilizan. Por ejemplo, la informacin de fragmentacin cuando sta no es necesaria. Los routers hacen caso omiso de opciones no dirigidas a ellos. La cabecera fija y las de extensin opcionales incluyen el campo de cabecera siguiente que identifica el tipo de cabecera de extensin que viene a continuacin o el identificador del protocolo de nivel superior al cual IP debe entregar los datos transportados por el datagrama en cuestin. En este diseo, la primera cabecera de informacin de control es obligatoria con un tamao fijo de 40 octetos seguida de cero o ms cabeceras de extensin opcionales. Se han definido hasta el momento 6 tipos de cabeceras de extensin. Algunas tienen un formato fijo y otras contienen un nmero variable de campos de longitud tambin variable en funcin de la estructura: tipo, longitud y valor. Consecuentemente, el formato de estas cabeceras puede ser de dos clases: - 203 -
Fijo. Variable: Basndose en los campos siguientes (estructura TLV105): Tipo, longitud y valor (datos de la opcin).
40 octetos
Cabecera Fija
Cabecera de extensin 1
...
0 o ms
Cabecera de extensin n
PDU del Protocolo Superior
opcional
Las cabeceras de extensin IPv6 son similares a las opciones IPv4 Nuevas opciones que incluyen servicios adicionales Evitan que los datagramas compartan campos que no utilizan Routers hacen caso omiso de opciones no dirigidas a ellos La cabecera fija y las de extensin opcionales incluyen el campo cabecera siguiente que identifica el tipo de cabecera de extensin que viene a continuacin o el identificador del protocolo de nivel superior 6 tipos de cabeceras de extensin: formato fijo Formato variable : Tipo, longitud y valor (datos de la opcin)
Figura 3.28.- Formato de los datagramas IPv6. Las seis cabeceras de extensin opcionales aprobadas hasta el momento son las siguientes: Cabecera de opciones de salto a salto: Informacin especial para los routers en cada salto. Por tanto, contiene informacin de control que requiere procesarse en cada salto. Actualmente, slo existe la opcin, que ya se estudiar, de la carga til del jumbo o jumbograma (para datagramas de ms de 65.535 octetos). Cabecera de encaminamiento: Ruta total o parcial que se ha de seguir. Es el equivalente al encaminamiento desde origen estricto y no estricto de IPv4. Cabecera de fragmentacin: Informacin de fragmentacin (origen) y reensamblaje (destino). Esta informacin de control no se transmite desde el origen a los routers sino nicamente a la mquina destinataria. Cabecera de autenticacin: Verificacin de la autenticidad del emisor (RFC2401 y RFC-2406).
105
Type-Length-Value.
- 204 -
Cabecera de encapsulado de seguridad de la carga til: Informacin sobre los tipos de mecanismos de seguridad utilizados para garantizar los servicios de confidencialidad e integridad del contenido cifrado en el campo de datos del datagrama (RFC-2401 y RFC-2406). Cabecera de opciones para el destino: Informacin opcional que debe ser procesada por el destino final del datagrama.
0
Versin
4
Prioridad
16
Etiqueta de flujo
Cabecera siguiente
24
31
Longitud de la carga til
Lmite de saltos
Direccin de origen (16 octetos)
40 octetos
Direccin de destino (16 octetos)
Aunque cabecera IPv6 (40 octetos) > cabecera IPv4 (20 octetos) contiene la mitad de campos (8 en IPv6 frente a 16 en IPv4) = Se procesa con ms rapidez y se agiliza el encaminamiento
Figura 3.29.- Formato de la cabecera fija IPv6. Segn se refleja en la Figura 3.29, los campos de la cabecera fija de IPv6 son los que se describen a continuacin: Versin (4 bits).- Indica la versin 6 del protocolo IP. Prioridad (4 bits).- Define la prioridad de procesamiento o de transmisin y entrega (por una entidad IPv6) del datagrama en cuestin. Existen 16 niveles de prioridad que originan dos tipos de trfico (con control y sin control de congestin) que se estudiarn ms adelante. Etiqueta de flujo (24 bits).- Es un campo todava en fase experimental y pendiente de definicin (RFC-1809) que sustituye al campo de tipo de servicio (TOS) de IPv4. Este campo indica la calidad de servicio y el procesamiento especial que la aplicacin desea para su datagrama en los routers por donde pase en el trayecto origen-destino. En este escenario, un flujo se define como una secuencia ordenada de datagramas que siguen una misma ruta por Internet desde un origen a un destino, y que requieren de un tratamiento especial por los routers por donde pasan. Un ejemplo de una aplicacin que requiera el uso de la etiqueta de flujo sera una aplicacin de - 205 -
transmisin de vdeo (flujo de vdeo) que exige para todos sus datagramas que se entreguen con un ancho de banda y retardo determinado. Para todas aquellas aplicaciones que no soportan un flujo, se establece un campo de etiqueta de flujo igual a cero. Por consiguiente, este campo distingue entre aplicaciones que soportan o no el pertinente flujo. Todo flujo queda identificado por la combinacin: direccin de origen, direccin de destino y una etiqueta de flujo (diferente de cero). Longitud de la carga til (16 bits).- Define la longitud total en octetos del resto del datagrama, excluyendo la cabecera fija que es obligatoria. Al igual que en IPv4, dicha longitud es de 64 KB (65.535 octetos = 11111111 11111111). Cabecera siguiente (8 bits): Muy parecido al campo protocolo de IPv4. Por tanto, es un nmero que identifica el tipo de cabecera de extensin que viene a continuacin o al protocolo superior al cual IP debe entregar los datos transportados por el datagrama. Lmite de saltos (8 bits): Equivalente al campo TTL de IPv4. Ahora el nombre indica lo que en realidad significa, es decir, el nmero mximo de routers (255) que el datagrama puede atravesar en Internet desde un origen a un destino. Cada entidad IP intermedia (router) decrementa en una unidad el valor almacenado en este campo. Si el resultado es cero, se elimina el datagrama. Si el valor es diferente de cero, se actualiza el campo con el nuevo valor. Direccin de origen (128 bits): Los ocho octetos que identifican a la mquina de origen del datagrama. Direccin de destino (128 bits): Los ocho octetos que identifican a la mquina de destino del datagrama. Aunque la cabecera de IPv6 dispone de una longitud de 40 octetos frente a los 20 octetos de IPv4, dicha cabecera contiene casi la mitad de los campos que en IPv4 (8 en IPv6 frente a 14 en IPv4106); con lo cual, se reduce el tiempo de procesamiento acelerando el correspondiente encaminamiento.
Versin + Longitud cabecera + Tipo de servicio + Longitud total + Identificador + 0 + DF + MF + Desplazamiento + TTL + Protocolo + Suma de comprobacin + Direccin origen + Direccin destino.
106
- 206 -
Trfico con control de congestin

0 1 2 3 4 5 6 7 Trfico no caracterizado Trfico de relleno (p.ej., news) Transferencia de datos que no son esperados (p.ej., correo) (Reservado) Transferencia de gran cantidad de informacin esperada (p.ej., FTP, HTTP) (Reservado) Trfico interactivo (p.ej., Telnet) Trfico de control de Internet (p.ej., RIP, OSPF, BGP, , SNMP) 8
Trfico sin control de congestin

Ms dispuestos a ser descartados (p.ej., video de alta calidad)
. . .
15 Menos dispuestos a ser descartados (p.ej., audio de baja calidad)
Figura 3.30.- Los dos tipos de trfico definidos por el campo de prioridad. El campo de prioridad de la cabecera fija de informacin de control, que define 16 niveles de prioridad, establece dos tipos de trfico desde origen (ver Figura 3.30): con control y sin control de la congestin. Trfico desde origen con control de la congestin: No se mantiene un flujo de entrega constante sino que en caso de congestin, el origen realiza una reduccin107 en la transmisin de datagramas en respuesta a dicha congestin. Segn se muestra en la Figura 3.30, se definen ocho niveles de prioridad de entrega: 0 (Trfico no caracterizado).- Es el nivel de prioridad ms bajo y se aplica por omisin cuando la aplicacin no indica nada sobre la prioridad que desea para sus datagramas. 8 (Trfico de control en Internet).- Es el nivel de prioridad ms alto y se aplica al trfico de control ms importante de Intenet, como es el caso de los protocolos de actualizacin y distribucin de la informacin de encaminamiento (p.ej., RIP, OSPF BGP, etc.) o de gestin TCP/IP (p.ej., SNMP). Por consiguiente, todos los datagramas de dichos protocolos no se descartan sino que hay que encaminarlos y entregarlos antes que otros, especialmente, en momentos de gran congestin.
107
Se est ante el caso de que por encima del protocolo IP se disponga de TCP (o bien de UDP y una aplicacin orientada a conexin).
- 207 -
Trfico desde origen sin control de la congestin: Se mantiene un flujo de entrega constante aunque todos los paquetes se estn perdiendo108. Segn se muestra en la Figura 3.30, se definen, a su vez, ocho niveles de prioridad de entrega: 8 (Ms dispuestos a ser descartados).- Es el nivel de prioridad ms bajo y se aplica a los datagramas de aquellas aplicaciones que contienen una importante redundancia y la prdida de unos pocos datagramas es inapreciable. Tal es el caso de la transmisin de audio y vdeo en tiempo real, en donde es ms importante mantener un flujo de entrega constante que estar pendiente de la retransmisin (en el nivel de trasporte con TCP) de las correspondientes unidades de datos perdidas, desordenadas o duplicadas. Resumiendo, en caso de congestin en la red, no se realiza ningn tipo de reduccin en la transmisin de datagramas en respuesta a dicha congestin. ... 15 (Menos dispuestos a ser descartados).- Es el nivel de prioridad ms alto y se aplica al trfico de control ms importante de Internet, en este contexto (sin control de la congestin), como es el caso de la transmisin de audio en donde la prdida de unos cuantos datagramas puede originar los tpicos crujidos, chasquidos y zumbidos en recepcin.
Tipo de direcciones
Reservado (compatible IPv4) No asignado Reservado (OSI/NSAP) Reservado (IPX/Novell Netware) No asignado ................. ................. Basadas en el proveedor No asignado Basadas en la geografa No asignado ................. ................. De enlace local De zona local Multicast
Prefijo
0000 0000 0000 0001 0000 001 0000 010 0000 011 ................. ................. 010 011 100 101 ................. ................. 1111 1110 10 1111 1110 11 1111 1111
Figura 3.31.- Los prefijos de las direcciones de IPv6.
108
Se est ante el caso de que por encima del protocolo IP se disponga de UDP (y una aplicacin no orientada a conexin).
- 208 -
Seguidamente, en la anterior Figura 3.31 se muestran los prefijos binarios109 que identifican los distintos tipos de direcciones de IPv6. Se entiende por prefijo, la direccin que determina la localizacin e interpretacin de los restantes campos de la direccin. Alrededor del 72 % del espacio de direcciones no ha sido asignado todava, reservndolo para usos futuros. Entre las direcciones asignadas se destacan las siguientes: 0000 0000 (compatible IPv4).- Prefijo para utilizar direcciones de IPv4 en el formato IPv6. 0000 001 (OSI/NSAP).- Prefijo para utilizar direcciones de OSI en el formato IPv6, es decir, para poder utilizar aplicaciones de OSI montadas sobre el nivel de transporte TCP/IP. 0000 010 (Novell Netware).- Prefijo para utilizar direcciones Novell Netware en el formato IPv6. 010 (basadas en el proveedor).- Prefijo para utilizar direcciones basadas en el identificador del correspondiente proveedor de servicios de Internet (ISP). 100 (basadas en la geografa).- Prefijo para utilizar direcciones basadas en la jerarqua geogrfica-administrativa actual de Internet. Estas direcciones geogrficas representan el modelo actual en Internet en el que los proveedores o ISP no desempean un papel importante.
Seguidamente, se indican dos prefijos para direcciones locales utilizadas por mquinas que no desean de momento conectarse a Internet por cuestiones de seguridad y privacidad. Existen dos tipos: 1111 1110 10 (enlace local).- Prefijo para utilizar localmente direcciones de IPv6 en un enlace110. Slo disponen de un significado local y no pueden
109
Bits de mayor orden o ms significativos o ms a la izquierda. Lnea serie o red punto a punto, red de difusin o no difusin.
110
- 209 -
propagarse fuera de la organizacin. Son direcciones pensadas para un enlace aislado sin conexin con un router. 1111 1110 11 (zona local).- Prefijo para utilizar localmente direcciones de IPv6 pero con un formato tal que posteriormente se puedan integrar en el esquema de direcciones globales sin un gran esfuerzo de reconfiguracin. Son direcciones pensadas en un principio para un enlace111 conectado a un router pero sin conexin con un ISP. El diseo de IPv6 de direcciones locales permite, como se analizar ms adelante, que una organizacin que necesite ms adelante conectarse al mundo externo no tenga que realizar un gran trabajo en la configuracin de sus tablas de encaminamiento. Actualmente, con IPv4, si una red desea mantener un direccionamiento privado112 con Internet, debe hacer uso de una traduccin de direcciones de red (NAT y PAT).
La Figura 3.32 y Figura 3.33 muestran los diferentes tipos de direcciones de unidifusin o punto a punto.
IPv6 divide las direcciones en TIPOS de forma anloga a como el IPv4 las divide en CLASES
Globales basadas en el proveedor Globales basadas en la geografa De enlace local De zona local Compatibles IPv4 De bucle
Figura 3.32.- Direcciones de unidifusin.
111
Igual que antes, un enlace puede ser una lnea serie o red punto a punto, red de difusin o no difusin. Por ejemplo, con las direcciones 10.0.0.0, 172.16.0.0 y 192.168.0.0 entre otras.
112
- 210 -
Bits
125-n-m-o-p
010 ID de registro ID de proveedor

Bits
ID de subscriptor ID de subred ID de interfaz
Formato 1.- Direccin basada en el proveedor
10
n
0 Formato 2.- Direccin de enlace local
118-n
ID de interfaz
1111111010
Bits
10
n
0 Formato 3.- Direccin de zona local
118-n-m
ID de subred ID de interfaz
1111111011
Bits
80
Formato 4.- Direccin compatible IPv4
16
XXX...X
32
Direccin IPv4
00000......................................................................... 0000
Bits
120
Formato 5.- Direccin de bucle
00000............................................................................................................................ 00000001
Figura 3.33.- Formatos de direcciones de unidifusin de IPv6. La Figura 3.33 muestra los formatos ms significativos de direcciones de IPv6. Por su relevancia, se destaca en primer lugar el formato 1 que muestra la estructura de la direccin basada en el proveedor en donde se establece la siguiente jerarqua: ID de registro.- Es el identificador de la autoridad de registro que asigna la parte de direccin del proveedor (ID de proveedor). Por tanto, el prefijo o direccin de registro es igual a 010 + ID de registro. ID de proveedor.- Es el identificador del proveedor que asigna la parte de direccin del subscriptor o cliente. Por tanto, el prefijo o direccin de proveedor es igual a 010 + ID de registro + ID de proveedor. Este identificador permite al proveedor distinguirse entre varios proveedores que comparten el mismo prefijo o direccin de registro (010+ID de registro) ID de subscriptor.- Es el identificador del cliente que asigna la parte de direccin de subred e interfaz y le permite distinguirse entre varios clientes que comparten el mismo prefijo o direccin de proveedor (010+ID de registro + ID proveedor). Por tanto, el prefijo o direccin de subscriptor es igual a 010 + ID de registro + ID de proveedor + ID de subscriptor. ID de subred.- Es el identificador de un conjunto de mquinas conectadas a la subred del subscriptor o cliente. Por consiguiente, es el identificador que distingue a una subred de otras que comparten el mismo (ID de subscriptor). Por tanto, el prefijo o direccin de subred es igual a 010 + ID de registro + ID de proveedor + ID de subscriptor + ID de subred.
- 211 -
ID de interfaz.- Es el identificador que distingue a una mquina de forma individual. Por tanto, el prefijo o direccin de interfaz es igual a 010 + ID de registro + ID de proveedor + ID de subscriptor + ID de subred + ID de interfaz. Se recomienda que este campo contenga, por lo menos, 48 bits para permitir que se utilice el direccionamiento del tipo 802 de IEEE.
128 bits Bits 3
125-n-m-o-p
010 ID de registro ID de proveedor ID de subscriptor ID de subred ID de interfaz

Prefijo de registro Prefijo de proveedor Prefijo de suscriptor Prefijo de subred
Prefijo de interfaz
Figura 3.34.- Prefijos de la direccin basada en el proveedor. La Figura 3.34 muestra la jerarqua de direcciones de IPv6 para una direccin asignada por un proveedor. Con esta estructura se permite que cada proveedor pueda asignar direcciones de subscriptor y que, a su vez, cada subscriptor pueda asignar direcciones de subred y mquina. As, la correspondiente autoridad de Internet asigna a cada proveedor un identificador nico o prefijo o direccin de proveedor (010+ID de registro + ID proveedor). A su vez, el proveedor puede entonces asignar a cada subscriptor o cliente un identificador nico (ID de subscriptor). Finalmente, el subscriptor o cliente puede asignar un identificador nico para cada red fsica (ID de subred) y computadora (ID de interfaz). Como ya se ha sealado, los formatos 2 (Direccin de enlace local) y 3 (Direccin de zona local) en la Figura 3.33 se identifican por los correspondientes prefijos, 1111 1110 10 y 1111 1110 11 respectivamente. Tambin, segn se indic con anterioridad, es ms fcil que con IPv4, automatizar las direcciones de un enlace sin conexin con un router (Direccin de enlace local) o con conexin a un router113 (Direccin de zona local). En el ltimo caso (Direccin de zona local), los routers detectan el prefijo del enlace e incluyen los ID de subred y de interfaz. Con esto, se facilita la migracin a una conectividad de ISP ya que slo hay que configurar el router con un nuevo prefijo que incluya los ID de registro, proveedor y subscriptor junto con los ID o nmeros de
113
Sin conexin con el pertinente ISP.
- 212 -
subred e interfaz. De esta forma, no ser necesario modificar ninguna parte de las direcciones asignadas previamente al entorno. Como se puede ver, uno de los objetivos de la versin 6 es proporcionar un procedimiento efectivo de inicializacin automtica. En este contexto, se resalta que se est trabajando actualmente (Internet Draft) en un DHCPv6 diseado expresamente para el protocolo IPv6. A su vez, el formato 4 (direccin compatible IPv4) en la Figura 3.33, se basa en una direccin que comienza con 80 bits a ceros, seguidos por 16 bits a unos o tambin a ceros y, finalmente, la correspondiente direccin IPv4 en los 32 bits de orden inferior. Este ltimo formato permite encapsular direcciones de IPv4 en direcciones de IPv6. Para terminar, el formato 5 (Direccin de bucle) de la citada Figura 3.33 se corresponde con 120 bits a ceros y en el ltimo octeto el contenido 0000 0001.
Bits
n
Prefijo de subred Formato 1.- Direccin de monodifusin o anycast
128-n
000......0000000
010/100
Bits 8
11111111
4 000 T
4 Alcance
112 Identificador de grupo
Alcance o lmite del grupo de multidifusin: Nmero entero de 4 bits. 0: reservado; 1: Nodo local o en la propia mquina; 2: enlace local; ; 5: sitio local; ; 8: organizacin local (compuestas de varios sitios); T (transitorio o transient) = 0: Direccin no transitoria o asignada permanentemente por IANA/ICANN T (transitorio o transient) = 1: Direccin transitoria o no asignada permanentemente
Formato 2.- Direccin de multidifusin o multicast
Figura 3.35.- Otras direcciones de IPv6. El formato 1 de la Figura 3.35, muestra el formato de las direcciones de monodifusin, las cuales se alojan dentro del espacio de direcciones de unidifusin, usando cualquiera de los formatos de estas ltimas direcciones. Por tanto, una direccin de monodifusin no se puede distinguir de otra de unidifusin. Consecuentemente, cuando una direccin de unidifusin se asigna a ms de un interfaz, entonces se convierte en una direccin de monodifusin y las mquinas a las cuales se les ha asignado dicha direccin, deben estar explcitamente configuradas para saber que tienen dicha direccin. A su vez, el formato 2 de la misma Figura 3.35 describe el formato de las direcciones de multidifusin de IPv6 en donde: Indicadores: Los tres primeros bits del campo estn reservados (a cero). Si el cuarto indicador es cero, significa una direccin de multidifusin asignada permanentemente; si es uno, esta direccin es temporal o no ha sido asignada por IANA/ICANN. - 213 -
Alcance: Los valores de alcance limitan el mbito de los grupos de multidifusin. 0000 y 1111: Reservados 1: Alcance de nodo local o en la propia mquina. 2: Alcance de enlace local. 5: Alcance de sitio local. 8: Alcance de la organizacin (compuesta de varios sitios).
Las direcciones de 16 octetos se escriben como 8 grupos de 4 dgitos (2 octetos = 1 grupo de 4 dgitos) hexadecimales separados por : 104.230.140.100.255.255.255.255.100.17.100.128.150.10.255.255
68E6:8C64:FFFF:FFFF:6411:6480:96A:FFFF
grupo
0000:0000:0000:0000:0000:0000:0000:0001 = 0:0:0:0:0:0:0:1= ::1 Direccin IPv4 = 0:0:0:0:0:0::138.100.8.16

Los ceros a la izquierda de un grupo pueden omitirse y 1 ms grupos de 16 ceros pueden reemplazarse por una pareja de dos puntos ::
Figura 3.36.- Formato de representacin de las direcciones de IPv6. Es evidente que la notacin decimal con puntos empleada en la comunicacin entre personas es ms bien larga cuando se aplica a las direcciones de IPv6. Una notacin ms compacta es a travs del uso de cuatro dgitos hexadecimales cada dos octetos formando un grupo de los ocho grupos totales de cuatro dgitos hexadecimales separados por :. En la Figura 3.36, se describe el formato de representacin en hexadecimal de los 16 octetos de una direccin IPv6. Como ya se ha indicado, las direcciones de IPv6 tienen 16 octetos (128 bits) en decimal que se representan como ocho grupos de cuatro dgitos hexadecimales separados por dos puntos (:). Por tanto, cada dos octetos (16 bits) en decimal se corresponde con un grupo de cuatro dgitos hexadecimales. Consecuentemente, un octeto en decimal se corresponde, a su vez, con dos dgitos en hexadecimal con excepcin, obviamente, del cero en decimal que se
- 214 -
corresponde con otro cero en hexadecimal114. Por tanto, en este ltimo caso, dos octetos a ceros en decimal se corresponden con un grupo de cuatro ceros en hexadecimal. Si a la izquierda de un grupo de cuatro dgitos hexadecimales, existe uno o ms ceros, se puede suprimir stos, con lo cual se comprime un poco ms la correspondiente direccin. Por consiguiente, se resalta que se puede eliminar los ceros de la izquierda de un campo (p. ej., se pone 0 en lugar de 0000 7 en lugar de 0007). El formato es susceptible de comprimirse ms eliminando una serie de campos a ceros en hexadecimal por ::; es decir, todava es posible una notacin ms compacta cuando aparecen grupos de ceros consecutivos. Por ejemplo, los 16 octetos siguientes de una direccin IPv6: 120.190.0.0.0.0.0.0.0.7.240.255.220.170.165.125, se corresponden con: 78BE:0000:0000:0000:0007:F0FF:DCAA:A57D, comprimiendo los ceros de la izquierda: 78BE:0:0:0:7:F0FF:DCAA:A57D El formato se puede comprimir ms eliminando una serie de grupos a ceros por ::, 78BE::7:F0FF:DCAA:A57D Por ltimo, y como ya se ha indicado, a veces las direcciones de la versin 4 de IP se insertan en los ltimos cuatro octetos de las direcciones de la versin 6. Se puede escribir usando un formato de direcciones que utiliza tanto la notacin de punto a punto como de dos puntos. Por ejemplo: 0:0:0:0:0:0:138.100.8.16 (0:0:0:0:0:FFFF:138.100.8.16) Las dos direcciones anteriores se han obtenido partiendo de la direccin compatible IPv4 (el formato 4 ya visto en la Figura 3.33) en donde los primeros 80 bits a ceros de orden superior se corresponden con diez octetos en decimal o cinco grupos de cuatro dgitos en hexadecimal (cinco grupos de un cero en hexadecimal o 0:0:0:0:0). Posteriormente, aparecen 16 bits a unos o tambin a ceros (como se muestra en el
114
En el formato IPv6 seran dos ceros en hexadecimal por cada octeto a cero en decimal.
- 215 -
ejemplo) que se corresponden, a su vez, con dos octetos en decimal o un grupo de cuatro dgitos en hexadecimal115. El formato se puede comprimir ms eliminando una serie de grupos a ceros por ::: ::138.100.8.16 (::FFFF:138.100.8.16)
3.1.2.1
Cabeceras de extensin de IPv6
El uso de un formato flexible de cabeceras de extensin opcionales es una idea innovadora que permite ir aadiendo funcionalidades de forma paulatina. Por tanto, este diseo aporta una gran eficiencia y flexibilidad ya que se puede definir nuevas opciones en cualquier momento a medida que se vayan necesitando entre la cabecera fija y la carga til. Hasta el momento, existen 6 tipos de cabeceras de extensin, en donde la cabecera fija y las de extensin opcionales incluyen el campo de cabecera siguiente que identifica el tipo de cabecera de extensin que viene a continuacin o el identificador del protocolo de nivel superior (p.ej., 6 para TCP, 17 para UDP, etc.). Por consiguiente, las cabeceras de extensin se van encadenando utilizando el campo de cabecera siguiente que aparece tanto en la cabecera fija como en cada una de las citadas cabeceras de extensin. Como resultado de la secuencia anterior, dichas cabeceras de extensin se tienen que procesar en el mismo orden en que aparecen en el datagrama. Todas o parte de estas cabeceras de extensin tienen que ubicarse en el datagrama en el orden especificado en la Figura 3.37, es decir: 1. Cabecera de opciones de salto a salto: Cdigo 0. 2. Cabecera de encaminamiento: Cdigo 43. 3. Cabecera de fragmentacin: Cdigo 44. 4. Cabecera de autenticacin: Codigo 51. 5. Cabecera de encapsulado de seguridad de la carga til: Cdigo 50. 6. Cabecera de opciones para el destino: Cdigo 60.
115
Un grupo de un cero en hexadecimal o :0 o :FFFF si los citados 16 bits de la direccin estn a uno.
- 216 -
40 octetos
Cabecera Fija
Cabecera de extensin 1
...
0 o ms
Cabecera de extensin n
PDU del Protocolo Superior
opcional
Cabecera Fija Cabecera Siguiente=TCP
Segmento TCP
(Sin cabeceras de extensin opcionales)
Cabecera de Cabecera de Cabecera Fija Cabecera de Cabecera de Cabecera de autenticacin encapsulado de seguridad salto a salto encaminamiento fragmentacin de la carga til Siguiente=0 Siguiente=43 Siguiente=44 Siguiente=51 Siguiente=50 Siguiente=60
Cdigo de la cabecera
0 43 44 51 50 60
Tipo de cabecera
Salto a salto Encaminamiento Fragmentacin Autenticacin Encapsulado de seguridad de la carga til Opciones para el destino
Cabecera de opciones para el destino
Siguiente=6
Segmento TCP
Figura 3.37.- Secuencia de cabeceras en un datagrama IPv6. Seguidamente, se muestran algunas cabeceras de extensin del protocolo IPv6. a) CABECERA DE OPCIONES DE SALTO A SALTO Contiene una informacin especial que debe ser procesada por los correspondientes routers en cada salto en el trayecto origen-destino. Por tanto, transporta una informacin de control que requiere procesarse en cada sistema intermedio o salto de la ruta que se establezca.
Bits
0
8 Longitud cabecera 16
31
Cabecera siguiente
Una o ms opciones
8 bits TIPO
8 bits LONGITUD
n bits VALOR
XXxxxxxx
00: Ignorar esta opcin y continuar procesando la cabecera 01: Eliminar datagrama y no enviar un mensaje ICMP 10: Eliminar datagrama y enviar un mensaje ICMP de problema
de parmetro
11: Eliminar datagrama y no enviar un mensaje ICMP de

problema de parmetro a una direccin multicast
Figura 3.38.- Formato de la cabecera de salto a salto.
- 217 -
La cabecera de salto a salto (ver anterior Figura 3.38) que se identifica con el valor 0 en el campo cabecera siguiente de la cabecera de IPv6 tiene el siguiente formato: Cabecera siguiente (8 bits): Identifica el tipo de cabecera de extensin que viene a continuacin o el identificador del protocolo del nivel superior al cual IP debe entregar los datos transportados por el datagrama en cuestin Longitud de la cabecera (8 bits): Indica la longitud en octetos (0 a 255 octetos) de la cabecera de opciones de salto a salto en unidades de 8 octetos sin incluir los primeros 8 octetos116 que son obligatorios. Por tanto, si aparece un cero la longitud de la cabecera es de 8 octetos, es decir, hay al menos una opcin. A su vez, si aparece un uno hay 16 octetos, tambin conteniendo una o ms opciones y as sucesivamente117. Obviamente, si no hubiera ninguna opcin no existira la cabecera de salto a salto y la primera cabecera despus de la cabecera fija sera otra, por ejemplo, la cabecera de encaminamiento segn la secuencia definida en el protocolo IPv6. Opciones (n bits): Campo de longitud variable de tal forma que la longitud sea un mltiplo de 8 octetos. Contiene una o ms opciones codificadas, al igual que en IPv4, segn el formato TLV (Tipo-Longitud-Valor)118. Consecuentemente, esta cabecera contiene un nmero variable de opciones de longitud tambin variable, cada una de las cuales se codifica en los tres campos siguientes: Tipo de opcin (8 bits): Los dos bits de orden superior de cada opcin (ver Figura 3.38) de este campo especifican a los routers, que no saben cmo procesar dicha opcin, lo que tienen que hacer al respecto. Por ejemplo, una opcin, que se analizar a continuacin, es el de la carga til del jumbo o jumbograma (para datagramas con una carga til de ms de 65.535 octetos). Tamao de la opcin (8 bits): Indica la longitud en octetos (0 a 255 octetos) del campo Valor o datos de la opcin. Valor de la opcin (n bits): Los datos de la correspondiente opcin. Como mximo una opcin tiene 255 octetos.
116
Cabecera siguiente (8 bits) + Longitud cabecera (8 bits) + Tipo (8 bits) + Longitud (8 bits) + Valor (los primeros 32 bits) = 8 octetos. Longitud cabecera x 8 octetos + 8 octetos = N de octetos de la cabecera de opciones de salto a salto. Type-Length-Value.
117
118
- 218 -
a1) CABECERA DE OPCIONES DE SALTO A SALTO PARA JUMBOGRAMAS

Bits 0
Cabecera siguiente 8 0 16 194 24 31
Longitud jumbo=4
Longitud de la carga til jumbo
Figura 3.39.- Cabecera de opciones de salto a salto para jumbogramas. En la Figura 3.39 se muestra el formato de la cabecera de extensin IPv6 correspondiente a la opcin de salto a salto para datagramas grandes o jumbogramas, es decir, datagramas de ms de 64 KB o 65.535 octetos. Las caractersticas de esta cabecera se resumen en los siguientes apartados: No se permiten tamaos menores de 65.535 octetos. Para aplicaciones de supercomputadoras que deben transmitir gigabytes de datos por Internet. La longitud de la carga til en la cabecera obligatoria debe ser 0. La longitud de la cabecera debe ser 0 (de momento, slo existe la opcin de jumbograma como cabecera de opciones de salto a salto). El campo de TIPO debe ser 194 (opcin jumbograma). El campo de LONGITUD (jumbo) que especifica la longitud en octetos del campo VALOR (Longitud de la carga til jumbo), debe ser 4 octetos. El campo de VALOR es de 32 bits (longitud de la carga til jumbo) el tamao de la carga til puede ser de hasta119 232 = 4.294.967.295 octetos (aproximadamente 4000 millones de octetos o 4 GB).
b) CABECERA DE FRAGMENTACIN El protocolo IPv6 maneja la fragmentacin de forma parecida a como lo hace a su vez el protocolo IPv4. En IPv6, a diferencia de IPv4, slo la mquina de origen puede fragmentar un datagrama y, por tanto, slo la mquina destinataria (como en IPv4) puede reensamblar; con las ventajas aadidas de una mayor rapidez, menor carga de
119
232 4 GB (11111111 11111111 11111111 11111111), 230 1 GB (0011111111 11111111 11111111 11111111), , 224 = 16.777.216 octetos (00000000 11111111 11111111 11111111),
- 219 -
proceso y menor probabilidad de perder un datagrama. Si un router encuentra un datagrama demasiado grande, lo descarta y devuelve al origen un mensaje ICMPv6 de paquete demasiado grande indicando la MTU del enlace de salida. Con esta informacin, la mquina de origen fragmenta el datagrama en funcin de la MTU indicada y no como haba hecho antes basndose en su MTU de salida. Si el origen tienen que fragmentar un datagrama, ste incluir una cabecera de extensin de fragmentacin (ver Figura 3.40) para cada fragmento de dicho datagrama. IPv6 requiere que cada enlace en Internet tenga una MTU de 1280 octetos o mayor. Por consiguiente, se ha cambiado la mnima MTU de IPv6 de 576 octetos (RFC-1883: IPv6) a 1280 octetos (RFC-2460: IPv6). Por consiguiente, los enlaces que tengan una MTU configurable (p.ej., un enlace PPP) deben usar una longitud de al menos 1280 octetos, recomendndose que se haga con 1500 o ms120 para evitar la tan temida fragmentacin. Los campos de Desplazamiento, M (ms fragmentos) e Identificador tienen el mismo significado y propsito que en IPv4, excepto que en IPv6 el campo Identificador se extiende hasta los 32 bits (en IPv4 era de 16 bits). Los bits del 8 al 15 y del 29 al 30 estn reservados para un uso futuro.
Bits
8
Reservado Identificador
16 Desplazamiento
29
31
Cabecera siguiente
Res. M
Figura 3.40.- Cabecera de fragmentacin. Los campos de esta cabecera se describen a continuacin: Cabecera siguiente (8 bits). Reservado (8 bits): Uso futuro. Desplazamiento del fragmento (13 bits): Nmero de bloques de 8 octetos contenidos en el campo de datos de fragmentos anteriores. Reservado (2 bits): Uso futuro.
Se recuerda que 1500 octetos es el tamao mximo del campo de datos de las tramas de informacin de la red Ethernet que por otro lado es la tpica red de comunicaciones en Internet.
120
- 220 -
Indicador M (1 bit): Indica si a continuacin vienen ms fragmentos pertenecientes al mismo datagrama. Identificador (32 bits): Identifica a los fragmentos pertenecientes a un mismo datagrama.
c) CABECERA DE ENCAMINAMIENTO
Bits
0 8 16 24 31
Cabecera siguiente Longitud cabecera Tipo de encamin. Direcciones restantes Reservado Mscara de bits estrictos/indiferente Direccin 1
Direccin n
Figura 3.41.- Formato de la cabecera de encaminamiento. Como en IPv4, el protocolo IPv6 permite especificar la ruta que se ha de seguir de forma total o parcial hasta llegar a un determinado destino. Es el equivalente al encaminamiento desde origen estricto y no estricto de IPv4. La Figura 3.41 muestra el correspondiente formato de la cabecera de encaminamiento IPv6. Los campos de esta cabecera se describen a continuacin: Cabecera siguiente (8 bits). Longitud cabecera (8 bits): Longitud de la cabecera en bloques de 8 octetos sin incluir los primeros 8 octetos. Tipo de encaminamiento (8 bits): Actualmente slo se ha definido el tipo cero. Direcciones restantes (8 bits): El nmero mximo es de 23. Reservado (8 bits): Uso futuro. Mscara de bits estricto (24 bits): Indica si la direccin siguiente debe seguirse estrictamente (bit a 1) o indiferentemente (bit a 0). Direcciones 1 n (32 bits): Direcciones de 128 bits numerados de 1 a n.
- 221 -
3.1.2.2
Protocolo ICMP versin 6 de envo de mensajes de control

RFC 2463 Misma estrategia y objetivos que la versin 4 Es un ICMPv4 modificado para adecuarlo a IPv6 Algunos protocolos independientes (ARP e IGMP) en IPv4/ICMPv4 son parte de de los mensajes IPv6/ICMPv6
Figura 3.42.- Caractersticas bsicas de ICMPv6.
La versin 6 del protocolo de envo de mensajes de control en Internet (RFC-2463) sigue la misma estrategia y objetivos que la versin 4. ICMPv6 conserva gran parte de la funcionalidad de ICMPv4, pero con la introduccin de algunos cambios relevantes entre los que se destacan los siguientes: Automatiza el descubrimiento de la MTU mnima en el camino origen-destino. Dispone de nuevos mensajes que sustituyen a los protocolos ARP e IGMP121. Elimina el mensaje ICMPv4 de frenado del origen. Consecuentemente, no se genera ningn mensaje ICMPv6 si un datagrama se elimina por una congestin. Dispone de mensajes que permiten la configuracin automtica de direcciones.
Internet Group Management Protocol o protocolo de gestin de grupos en Internet para descubrir mquinas locales que pertenezcan a grupos de multidifusin.
121
- 222 -
MENSAJES ICMPv6
DE ERRORES
DE INFORMACIN
DESTINO INALCANZABLE PAQUETE DEMASIADO GRANDE
PROBLEMAS CON LOS PARMETROS TIEMPO EXCEDIDO
SOLICITUD Y RESPUESTA DE ECO
PERTENENCIA A UN GRUPO
Figura 3.43.- Los mensajes bsicos de ICMPv6. La Figura 3.43 muestra los mensajes bsicos122 de ICMPv6 clasificados en mensajes de errores e informacin. Mensajes de errores (los tipos de estos mensajes estn en el intervalo del 0 al 127): Destino inalcanzable: Tipo 1. Paquete demasiado grande: Tipo 2. Tiempo excedido: Tipo 3. Problemas con los parmetros: Tipo 4. Mensajes de informacin (los tipos de estos mensajes estn, a su vez, en el intervalo del 128 al 255): Solicitud y respuesta de eco: Tipos 128 y 129 respectivamente. Pertenencia a un grupo. Solicitud de pertenencia a un grupo: Tipo 130. Informe de pertenencia a un grupo: Tipo 131. Reduccin de pertenencia a un grupo: Tipo 132.
Existen otros mensajes de ICMPv6 no considerados como bsicos, como es el caso, por ejemplo, de los mensajes de redireccin (similares a ICMPv4) o los mensajes de anuncio y solicitud de vecindad que sustituyen a las antiguas peticiones de direcciones de ARP, etc.
122
- 223 -
a) MENSAJE DE DESTINO INALCANZABLE

0
Tipo = 1
8
Cdigo = 0-4 No utilizado = 0
16
Checksum
31
Copia de la mxima cantidad de datos del datagrama originario del error sin exceder el tamao mximo de la MTU
(Cdigo = 0-4) 0: Sin ruta al destino 1: La comunicacin con el destino est prohibida por el administrador 2: Sin vecino 3: Direccin inalcanzable 4: Puerto inalcanzable
Figura 3.44.- Mensaje ICMPv6 de destino inalcanzable. La Figura 3.44 muestra el formato de un mensaje ICMPv6 de destino inalcanzable, definido por un Tipo = 1 y Cdigos del 0 al 4 que indican ms explcitamente la categora de dicho mensaje. Despus de la suma de control o comprobacin aparecen 32 bits a cero puestos por el origen e ignorados por el receptor. Asimismo, para una mayor informacin en la mquina de origen, se copian todos los octetos que se puedan del datagrama original sin que el total del mensaje ICMP exceda de 1280 octetos (antes 576 octetos). Este mensaje lo enva tanto un router (bsicamente, cuando no sabe o no puede reenviar un datagrama a una red) o una mquina de destino (cuando el protocolo o puerto especificado no est activo). Cdigo 0: Sin ruta al destino.- Este mensaje lo generan los routers (e incluso la entidad IPv6 en la mquina de origen) cuando hay un error en la direccin IP de destino o no se dispone de suficiente informacin en la tabla de encaminamiento para encaminar el pertinente datagrama. Cdigo 1: La comunicacin con el destino est prohibida por el administrador.Tpico mensaje debido, por ejemplo, al filtro de un firewall (cortafuegos). Cdigo 2: Sin vecino.- Mensaje transmitido cuando el siguiente destino en la cabecera de encaminamiento no es un vecino y est activado el bit estricto para esa direccin. Cdigo 3: Direccin inalcanzable.- Lo genera la mquina destinataria cuando el protocolo superior (TCP, UDP, OSPF, etc.) indicado en el correspondiente campo (cabecera siguiente) no est disponible.
- 224 -
Cdigo 4: Puerto inalcanzable.- Lo genera la mquina destinataria va su nivel de transporte (TCP/UDP) cuando el puerto destino no se corresponde con el puerto de algn proceso en uso. b) MENSAJE DE PAQUETE DEMASIADO GRANDE
0
Tipo = 2
8
Cdigo = 0
MTU
16
Checksum
31
Figura 3.45.- Mensaje ICMPv6 de paquete demasiado grande. La Figura 3.45 describe el formato de un mensaje ICMPv6 de paquete demasiado grande, definido por un Tipo = 1 y Cdigo = 0. Este mensaje slo lo transmite un router a la mquina de origen cuando el datagrama recibido es mayor que la MTU del enlace de salida y, por tanto, debe eliminar dicho datagrama. Curiosamente, en ICMPv4 se informaba de lo mismo (sin indicar la MTU de salida) a travs de un mensaje de destino inalcanzable (tipo 3, cdigo 4) de fragmentacin necesaria y no realizada (por bit DF = 1). En el caso del protocolo ICMPv6, se informa con exactitud de la MTU del enlace (campo de 32 bits en el mensaje ICMPv6) que se puede usar en el siguiente salto. La informacin de este mensaje se utiliza como parte del proceso de descubrimiento de la MTU en el trayecto origen-destino (Path MTU Discovery Process) reflejado en el documento RFC-1191. Asimismo, para una mayor informacin en la mquina de origen, se copian todos los octetos que se puedan del datagrama original sin que el total del mensaje ICMP exceda de 1280 octetos (antes123 576 octetos). Cuando una mquina de origen recibe un mensaje ICMP de paquete demasiado grande indicndole, por ejemplo, una MTU de 1280 octetos, sabe que dispone de 1232 octetos como mximo de longitud de la carga til (40 octetos se corresponden con la cabecera fija de control). Se
El documento RFC-1885 (ICMPv6) especificaba 576 octetos. Actualmente, el documento RFC-2403 (ICMPv6) que deja obsoleto al RFC-1885 se ajusta a la nueva definicin de MTU mnima (1280 octetos) del actual RFC-2460 (IPv6).
123
- 225 -
recuerda que IPv6 requiere que cada enlace en Internet tenga una MTU de 1280 octetos o mayor. c) MENSAJE DE TIEMPO EXCEDIDO
0
Tipo = 3
8
Cdigo = 0 1 No utilizado = 0
16
Checksum
31
(Cdigo = 0-1) 0: Lmite de saltos en trnsito excedido 1: Tiempo de reensamblado excedido
Figura 3.46.- Mensaje ICMPv6 de tiempo excedido. La Figura 3.46 muestra el formato de un mensaje de tiempo excedido definido por un Tipo = 3 y Cdigos del 0 al 1 que definen ms explcitamente la categora de dicho mensaje. Asimismo, para una mayor informacin en la mquina de origen, se copian todos los octetos que se puedan del datagrama original sin que el total del mensaje ICMP exceda de 1280 octetos (antes 576 octetos). Este mensaje lo enva un router124 o una mquina de destino125.
124
Cuando se ha excedido el lmite de saltos en trnsito excedido. Cuando se ha excedido el tiempo de reensamblaje de un datagrama fragmentado.
125
- 226 -
d) MENSAJE DE PROBLEMA CON LOS PARMETROS

0
Tipo =4
8
Cdigo = 0-2 PUNTERO
16
Checksum
31
(Cdigo = 0-2) 0: Se ha encontrado un campo errneo en la cabecera 1: No se reconoce el tipo de cabecera siguiente 2: No se reconoce una opcin IPv6
Figura 3.47.- Mensaje ICMPv6 de problema con los parmetros. La Figura 3.47 describe el formato de un mensaje de problema con los parmetros definido por un Tipo = 4 y Cdigos del 0 al 2 que definen ms explcitamente la categora de dicho mensaje. Parte de la cabecera contiene un puntero (32 bits) que indica el octeto que ha causado el problema. Asimismo, para una mayor informacin en la mquina de origen, se copian todos los octetos que se puedan del datagrama original sin que el total del mensaje ICMP exceda de 1280 octetos (antes 576 octetos). e) MENSAJES DE ECO
0
Tipo = 128 129
(Tipo = 128 129) 128: Solicitud de Eco 129: Respuesta de Eco
8
Cdigo = 0
16
Checksum
Nmero de Secuencia
31
Identificador
Datos opcionales de longitud arbitraria
Figura 3.48.- Mensaje ICMPv6 de solicitud y respuesta de eco. Finalmente, la Figura 3.48 muestra el formato de los mensajes de solicitud y respuesta de eco definido por un Tipo = 128 129 (solicitud o respuesta) y Cdigo = 0. Parte de la cabecera contiene un Identificador (16 bits) y un Nmero de secuencia (16 bits) para asociar solicitudes con respuestas. A su vez, el campo de datos del mensaje contiene unos octetos arbitrarios y aleatorios que introduce la propia implementacin. Como se puede ver, los mensajes de solicitud y respuesta de eco tienen formatos idnticos a los
- 227 -
mensajes de la versin 4, excepto que cambian los nmeros para las solicitudes y respuestas.
3.1.3 Transicin de IPv4 a IPv6

Teniendo en cuenta el uso tan extendido del protocolo IP debido a la enorme expansin de Internet y los protocolos TCP/IP, resulta complicado aventurarse cuando se pasar de la versin 4 a la versin 6. Actualmente, los usuarios no estn reclamando el protocolo IPv6 porque no hay muchas implementaciones comerciales de aplicaciones que soporten la versin 6, amn de que todava no existe de forma masiva redes nativas IPv6. Est claro que no se puede forzar a las organizaciones conectadas a Internet a abandonar sus direcciones actuales. Es ms, las organizaciones deben ser capaces de actualizar algunas mquinas, dejando otras sin cambiar. En general, la transicin debe ser sencilla de comprender y llevar a cabo para todo el mundo. Por estos motivos, es obvio que la transicin ser un proceso largo y gradual, facilitando en un primer momento la interconexin de mquinas IPv6 con mquinas IPv4. La clave de que se efecte con xito dicha transicin consistir en mantener la compatibilidad con la mayora de mquinas que todava soportan IPv4. Durante los ltimos aos se han propuesto diferentes estrategias o tcnicas126 para facilitar la transicin en Internet de la versin 4 a la versin 6 del protocolo IP. Dichas estrategias o tcnicas se basan en: Una traduccin de protocolos (informacin de control) y direcciones de red. Una pila de IP dual. Tneles de IPv6 sobre IPv4. Segn lo anterior, una solucin consistira en realizar una traslacin o traduccin de direcciones de red y protocolos entre sistemas finales IPv6 e IPv4 sin realizar ningn cambio en dichas mquinas. Esta solucin implica la prdida de informacin de control debido a que las cabeceras de IPv6 e IPv4 son totalmente incompatibles. IPv6 elimina aproximadamente la mitad de los campos de cabecera de IPv4 y carece de soporte para la fragmentacin de datagramas IPv4 en trnsito. En el caso de las traducciones de direcciones, no se puede hacer directamente con todas las direcciones; incluso puede haber por el medio un traductor de direcciones de red o router NAT o PAT (RFC-1631) que complica an ms el escenario en cuestin En este escenario, existen tres mecanismos de traduccin de protocolos:
126
Adems de realizar las oportunas extensiones en el servicio DNS.
- 228 -
Pasarela de protocolos en el nivel de red o Internet entre redes IPv6 e IPv4 para realizar la pertinente conversin de cabeceras de IP (ver Figura 3.49). Este mecanismo de traduccin de protocolos y direcciones de red es el que ms se ha utilizado. Pasarela de protocolos en el nivel de transporte que termine una conexin IPv6 y comience otra IPv4 y viceversa. Mediante un representante o proxy de aplicaciones o pasarela de aplicacin entre redes IPv6 e IPv4.
A
IPv6
B
IPv4
C
IPv4
D
IPv6
IPv6
Flujo: x Origen: A Destino: E datos
IPv6
Origen: A Destino: E datos
IPv4
IPv6
Flujo: ??? Origen: A Destino: E datos
IPv6
A a B: IPv6
B a C: IPv4
C a D: IPv4
D a E: IPv6
Figura 3.49.- Ejemplo de traduccin de protocolos y direcciones de red. En el ejemplo de la Figura 3.49, se muestra lo que se entiende por una traduccin de protocolos (traduccin de informacin de control de IPv6 a IPv4 y viceversa) y direcciones de red (de 16 a 4 octetos y viceversa) mediante una pasarela de protocolos y direcciones de red. En el caso de la traduccin de informacin de control, algunos campos son trasladables de una versin a otra pero la mayora no, con lo cual dicha informacin de control se pierde. Por ejemplo, algunos campos fcilmente traducibles seran: Longitud de carga til (IPv6: 65535 octetos) por longitud total (IPv4: 65535 octetos). Lmite de saltos (IPv6: 8 bits) por TTL (IPv4: 8 bits). Cabecera siguiente (IPv6: 8 bits) por Protocolo (IPv4: 8 bits). Versin (IPv6: 4 bits) por versin (IPv4: 4 bits). - 229 -
En el citado ejemplo, si la mquina A (IPv6) desea enviar un datagrama IPv6 a la mquina E (IPv6), el router B (IPv6/IPv4) debe crear un datagrama IPv4 para envirselo a C (IPv4). Evidentemente, el campo de datos del datagrama IPv6 en cuestin debe copiarse127 en el campo de datos del datagrama IPv4, realizndose la correspondiente traduccin o traslacin (mapping) de direcciones. Sin embargo, al realizar dicha conversin de IPv6 a IPv4, habr campos especficos de control en el datagrama IPv6 (p. ej., el campo de Etiqueta de flujo) que no tienen correspondencia con ningn campo de control de la cabecera de IPv4. Por consiguiente, dicha informacin se pierde irremediablemente. As, aunque D y E puedan intercambiar datagramas, los que lleguen a E no contendrn todos los campos de control incluidos en el datagrama original enviado por A. Asimismo, se ha supuesto que al llegar el datagrama IPv6 a B, su tamao es menor o igual que el de la MTU de la red de acceso de B. En caso contrario, la entidad IPv6 de B lo descarta y devuelve al origen un mensaje ICMPv6 de paquete demasiado grande, indicando la MTU de salida. Con esta informacin, la mquina de origen (A) fragmenta el datagrama en funcin de la MTU indicada y no como haba hecho antes basndose en su MTU de salida. La entidad IPv6 de A incluir una cabecera de extensin de fragmentacin para cada fragmento de dicho datagrama. Se recuerda que con IPv6, slo la mquina de origen (A) puede fragmentar un datagrama y, por tanto, slo la mquina destinataria (E) puede reensamblar.
A
APLICACIN TCP/UDP
(Traduccin de direcciones y de informacin de control IPv6/IPv4)
E
APLICACIN
B IPv6 IPv4
Interfaz Interfaz de red de red
Hardware Hardware
C IPv4
Hardware Hardware
D IPv4 IPv6
Hardware Hardware
TCP/UDP
IPv6
Interfaz de red Hardware
IPv6
IPv6
IPv4
IPv4
IPv6
Figura 3.50.- Arquitectura de comunicaciones del ejemplo.
127
Suponiendo que el tamao del datagrama es menor o igual que el tamao de la MTU de la red de acceso.
- 230 -
Es importante resaltar que, B no tiene porqu conocer previamente la asociacin de la direccin de 16 octetos a 4 octetos de A. El router B puede asignar dinmicamente128 a A una direccin de 16 octetos y asociarla a una de 4 octetos que es la que, finalmente, aparece en la cabecera del datagrama que se transmite de B a D. Pero s es obligado que B conozca previamente la asociacin de la direccin de 16 octetos en 4 octetos de E para incluirla en la cabecera del datagrama que se enva de B a D. De la misma forma, D no tiene porqu conocer previamente la asociacin de la direccin de 4 octetos a 16 octetos de A. El router D puede asignar dinmicamente una direccin de 16 octetos a la direccin de 4 octetos que le llegado de A que es la que aparece en la cabecera del datagrama que se transmite de D a E. Pero al igual que antes, la mquina D est obligada a conocer previamente la asociacin de la direccin de 4 octetos en 16 octetos de E para incluirla en la cabecera del datagrama que se enva de D a E. En la anterior Figura 3.50 se muestra la correspondiente arquitectura de protocolos de las mquinas del citado ejemplo. En la siguiente Figura 3.51 se muestra, a su vez, la arquitectura de protocolos para un ejemplo de una pila dual, slo en la mquina A, que intenta conectarse con otras mquinas va IPv6 e IPv4 mediante cuatro redes de rea local. Asimismo, se transita por el router multiprotocolo B para cualquier mquina no conectada a Red 1. Se dice que una pila o arquitectura de comunicaciones es dual (pila de IPv6 y pila de IPv4) cuando se envan o reciben datagramas IPv6 e IPv4 indistintamente para el mismo interfaz de la red de acceso. Los datagramas IPv6 irn exclusivamente por la pila de IPv6 (nivel de aplicacin hasta el nivel de hardware pasando por el nivel de IPv6) y los datagramas IPv4 por la de IPv4 (nivel de aplicacin hasta el nivel de hardware pasando por el nivel de IPv4). En este contexto, se dice que un router es de multiprotocolo IPv6-IPv4 cuando dispone en una nica pila de un protocolo IPv6 y otro IPv4 para el mismo software del interfaz de la red de acceso. En este caso el router B dispone de los protocolos IPv6 e IPv4 tanto para el software de acceso de Red 1 como para el de Red 2. No son pilas separadas, es la misma pila que dipone por un lado de IPv6 e IPv4 para el software de acceso de Red 1 y por el otro lado de la misma pila de IPv6 e IPv4 para el software de acceso de Red 2. Para una mayor comprensin ver, por ejemplo, el router B en la Figura 3.50, el cual tiene una nica pila, una parte de dicha pila se corresponde con el protocolo IPv6 para el interfaz con A y otra parte de la misma pila con el protocolo IPv4 para el interfaz con C.
De forma parecida a como un router NAT o PAT asocia una direccin privada y compartida por otras organizaciones en una direccin IP oficial para salir por Internet.
128
- 231 -
La tcnica de pila de IP dual proporciona un soporte completo para ambas versiones de IP en cualquier mquina (sistemas finales e intermedios) en Internet. Esta solucin implica disponer de las implementaciones IPv4 e IPv6 de forma completa, permitiendo la transmisin y recepcin tanto de datagramas IPv4 como IPv6. A este tipo de mquinas se las denomina routers o nodos o sistemas intermedios de IPv6/IPv4.
A
APLICACIN APLICACIN
Router multiprotocolo
B
IPv6 IPv4
Interfaz Interfaz de red 1 de red 2
(sin ningn tipo de traduccin) ning traducci
E
APLICACIN
TCP/ UDP
TCP/ UDP
C IPv4
Hardware Hardware
D IPv4
Hardware Hardware
TCP/UDP
IPv6 IPv4
Interfaz de red 1 Hardware Red 1
IPv4
Interfaz de red 4 Hardware
Hardware Hardware
Red 2
Red 3
Red 4
v6
v4
v6
v4
v4
v4
Figura 3.51.- Pila dual en un sistema final con un router multiprotocolo. En funcin de lo comentado, la mquina A dispone de dos pilas completas de TCP/IP separadas129; una pila para IPv6 y otra diferente para IPv4. A travs de la Red 1 (IPv6/IPv4) se puede transitar directamente (por la correspondiente direccin IP de destino) a una mquina con la pila completa TCP/IP para IPv6 (F) o con la pila completa TCP/IP para IPv4 (G). A su vez, a travs de la Red 1 (IPv6/IPv4) y Red 2 (IPv6/IPv4) se puede transitar indirectamente (por la correspondiente direccin IP de destino), va el router multiprotocolo B, a una mquina con la pila completa TCP/IP para IPv6 (H) o con la pila completa TCP/IP para IPv4 (I). Finalmente, a travs de la Red 1, Red 2, Red 3 (IPv4) y Red 4 (IPv4) se puede transitar indirectamente (por la correspondiente direccin IP de destino), va el router multiprotocolo B, y los routers IPv4, C y D, a una mquina conectada a Red 3 o Red 4 (p. ej., E) con la pila completa TCP/IP para IPv4. Es importante resaltar que la mayora de las redes de comunicaciones en Internet son del tipo Ethernet DIX (Digital, Intel y Xerox) o su equivalente IEEE 802 en las cuales, cuando un datagrama de IPv6 llega, por ejemplo, de Red 1 hacia B, el software del
129
Y, por supuesto, de dos direcciones: IPv6 e IPv4.
- 232 -
interfaz de la red de acceso de Red 1 en B analiza el campo denominado de tipo130 de trama o SAP131 de destino para saber a quien (IPv6 o IPv4) tiene que pasar los datos transportados por dicha trama.
A
APLICACIN
E
APLICACIN
TCP/ UDP
TCP/ UDP
C IPv4 B1
IPv6
Hardware Hardware
D IPv4
Hardware Hardware
TCP/UDP
IPv6 IPv4
Interfaz de red 1 Hardware Red 1
IPv4
Interfaz de red 4 Hardware

Hardware Hardware
IPv4
Hardware Hardware
Red 2
Red 3
Red 4
v6 v4
G
v6 v4
H
v4
v4
B2
Figura 3.52.- Pila dual en un sistema final con dos routers. En lugar de un router multiprotocolo (B), otra solucin equivalente (ver Figura 3.52) hubiera sido disponer de dos routers (B1 y B2); uno para encaminar a IPv6 (p. ej., B1) y otro para encaminar IPv4 (p. ej., B2). Obviamente, la salida desde A a B1 o B2 se lleva a cabo por la direccin de destino y la informacin de la pertinente tabla de encaminamiento. Se dice que esta solucin es equivalente porque, de hecho, el router multiprotocolo B no es ms que los routers B1 y B2 juntos.
En tramas de Ethernet aparece un campo de tipo de trama (Frame Type) despus del campo de direccin de destino. En tramas de IEEE 802, el campo de tipo de trama de Ethernet se sustituye por el de longitud del campo de datos. En el campo de datos aparece una primera cabecera de LLC (Logical Link Control) que contiene a su vez el SAP de destino.
131
130
- 233 -
A IPv6 IPv6
Flujo: x Origen: A Destino: E
B IPv4 IPv6
Origen: B Destino: D
Flujo: x
C IPv4 IPv4
Origen: B Destino:D
Flujo: x Origen: A Destino: E datos
D IPv6 IPv6
Flujo: x Origen: A Destino: E
IPv6
datos
datos
A a B: IPv6
B a C: IPv4
Encapsulado IPv6 en IPv4
C a D: IPv4
Encapsulado IPv6 en IPv4
D a E: IPv6
Figura 3.53.-Tnel de IPv6 sobre IPv4. Finalmente, la ltima alternativa (especialmente, frente a la pila de IP dual) consistira en aplicar tneles de IPv6 sobre IPv4 (ver Figura 3.53), resolviendo la problemtica de la prdida de informacin de control de IPv6 antes comentada. Un tnel de IPv6 sobre IPv4 consiste en encapsular un datagrama de IPv6 en un datagarama de IPv4. En la Figura 3.53 se resume esta tcnica. En dicho ejemplo si la mquina A (IPv6) desea enviar un datagrama de IPv6 a la mquina E (IPv6), el router B encapsula132 dicho datagrama en un datagrama de IPv4 para envirselo a C (IPv4). Evidentemente, cambian las direcciones de origen y destino de la cabecera de informacin de control del datagrama de IPv4. Ahora, el origen y destino de dicho datagrama IPv4 sern B y D. Por ejemplo, B, por ser el extremo transmisor en el tnel, es decir, por realizar el primer encapsulado y D por ser el extremo receptor del tnel, es decir por llevar a cabo, a su vez el desencapsulado final del datagrama del ejemplo en cuestin. El resultado es que, finalmente, llega a E el datagrama original IPv6 tal y como sali de origen (A) sin la prdida de ninguna informacin de control. En este ejemplo, al igual que en el anterior, se ha supuesto que al llegar el datagrama IPv6 a B, su tamao es menor o igual que el de la MTU de la red de acceso de B. En caso contrario, se recuerda que la entidad IPv6 de B lo descarta y devuelve al origen un mensaje ICMPv6 de paquete demasiado grande, indicando la MTU de salida. Con esta informacin, la mquina de origen (A) fragmenta el datagrama en funcin de la MTU indicada y no como haba hecho antes basndose en su MTU de salida. De
132
Suponiendo que el tamao del datagrama es menor o igual que el tamao de la MTU de la red de acceso.
- 234 -
nuevo, la entidad IPv6 de A incluir una cabecera de extensin de fragmentacin por cada fragmento de dicho datagrama. En la siguiente Figura 3.54 se muestra la arquitectura de protocolos de las mquinas del citado ejemplo. Es importante resaltar que, en el ejemplo, se ha realizado un tnel para dos redes IPv6 (a las cuales se conectan A y E respectivamente), es decir, dicho tnel permite conectar a cualquier mquina de una red IPv6 (p. ej., A) con cualquier otra mquina (p. ej., E) de la otra red IPv6. Esta solucin tiene un inconveniente y es que no se puede comunicar ni A ni E con ninguna otra mquina conectada a una red IPv4.
A
APLICACIN TCP/UDP
(ENCAPSULADO IPv6/IPv4)
E
(DESENCAPSULADO APLICACIN IPv6/IPv4)
IPv6
B IPv6
C
IPv4
IPv4
Hardware Hardware
IPv4
D IPv6
TCP/UDP
IPv6

Hardware Hardware

Hardware Hardware
IPv6
IPv4
IPv4
IPv6
Figura 3.54.- Arquitectura de comunicaciones del ejemplo. Segn muestra la siguiente Figura 3.55, para poder establecer un tnel de IPv6 sobre IPv4, es decir, encapsular IPv6 sobre IPv4, es necesario insertar un 41 en binario (00101001) en el campo PROTOCOLO de la primera cabecera de informacin de control (IPv4) que es la que establece el correspondiente tnel.
- 235 -
4
VERSIN
4
Longitud Cabecera
8
TIPO DE SERVICIO
16
LONGITUD TOTAL
000 R C F 00
IDENTIFICADOR
TIEMPO DE VIDA
D M F F
DESPLAZAMIENTO
(TTL)
00101001
SUMA DE COMPROBACIN (CABECERA)
CABECERA IPv4 (tnel)
DIRECCIN ORIGEN (INICIO DEL TNEL) DIRECCIN DESTINO (FINAL DEL TNEL) OPCIONES
RELLENO
16
Cabecera siguiente
24
Lmite de saltos
31
Versin Prioridad
Etiqueta de flujo
Longitud de la carga til

CABECERA FIJA IPv6 (nativa)
Direccin de origen real (16 octetos)
Direccin de destino real (16 octetos)
Figura 3.55.- Encapsulacin de IPv6 sobre IPv4. En este contexto, se puede distinguir los siguientes tneles: Tnel entre dos redes IPv6 (visto anteriormente). Tnel entre una red IPv6 y una mquina en una red IPv4. Tnel entre dos mquinas en una red IPv4.
Los dos ltimos tneles se describen en la siguiente Figura 3.56.

A
APLICACIN TCP/UDP
(ENCAPSULADO IPv6/IPv4) (DESENCAPSULADO IPv6/IPv4)
E
APLICACIN
TCP/UDP
IPv6
B IPv6
C
IPv4
IPv4
Hardware Hardware
IPv4
D IPv6
IPv6

Hardware Hardware

Hardware Hardware
IPv6
IPv4
APLICACIN
IPv4
APLICACIN TCP/UDP
IPv6
IPv6 IPv4
TCP/UDP
Interfaz de red
IPv6 IPv4
Interfaz de red
Hardware
Hardware
Figura 3.56.- Ejemplo de otros posibles tneles. - 236 -
Tnel entre cualquier mquina de una red IPv6 y una nica mquina en una red IPv4. Para poder comunicar (ver Figura 3.56), por ejemplo, A con una nica mquina en una red IPv4, por ejemplo J, se necesita hacer un tnel entre B y J.
Tnel entre dos mquinas de una red IPv4. Para poder comunicar (ver Figura 3.56), por ejemplo, J con L, se necesita hacer un tnel entre J y L.
3.1.4 IP mvil
Las computadoras y dispositivos mviles, tales como porttiles, computadoras de mano y toda clase de asistentes digitales personales133, tienen muchas veces la necesidad de conectarse a Internet segn se van trasladando de un sitio a otro. En la oficina, un porttil se conecta a Internet va una red de rea local a travs del router o routers de la organizacin. Asimismo, dicho porttil podra conectarse a Internet desde cualquier otro sitio134, por ejemplo, va un telfono mvil135 o fijo136, es decir, a travs de una red telefnica137. En un escenario en donde los porttiles son cada vez ms potentes y ms baratos y, por consiguiente, al alcance de cada vez ms personas que antes se conectaban nicamente de manera fija con Internet; es lgico que aumente la necesidad de realizar cada vez ms conexiones con dicha red de redes. Por otro lado, el simple acceso a Internet no hace imprescindible que un porttil retenga una nica direccin. Para ello, se dise el protocolo DHCP, el cual como ya se coment, hace posible que una mquina recin conectada, adquiera del servidor DHCP una direccin de IP temporal y las direcciones de recursos locales como, por ejemplo, un servidor de DNS. Sin embargo, un porttil puede disponer de ficheros y dems recursos susceptibles de ser utilizados por otros o bien puede ser parte del software de una aplicacin distribuida. Consecuentemente, si un porttil debe permanecer accesible
133
PDA: Personal Digital Assistant En el coche, autobs, tren, etc.
134
En una ranura del porttil se instala una tarjeta especial (cellular data card) que se conecta mediante un cable a un telfono mvil.
136
135
Mediante un mdem. Para comunicaciones mviles o fijas.
137
- 237 -
a otros cuando se mueve entre redes y/o subredes, debe conservar una direccin IP nica; pero segn se ha estudiado, el encaminamiento IP est basado en las direcciones de las redes-subredes. Si se cambia de red o subred se cambia de direccin IP. En principio y para IPv4, una solucin al problema comentado es lo que se entiende por IP mvil que permite que una computadora porttil denominada computadora mvil138, MH (Mobile Host), se mueva de un sitio a otro manteniendo todas sus sesiones de comunicaciones como si estuvieran en un lugar fijo. Obviamente, un requisito bsico de IP mvil es que no se modifique cualquier otra mquina que se est comunicando con una MH as como los routers intermedios que participen. Este requisito implica que una MH debe utilizar continuamente su direccin IP, incluso si se mueve entre localizaciones diferentes. La reserva permanente de una direccin IP para un porttil mediante el uso transparente de direcciones provisionales y el encaminamiento IP mvil, se describe a continuacin.
(COMPUTADORA MVIL)
MH
(AGENTE FORNEO) (AGENTE DE CASA)
FA
HA
Red Exterior
Red Local Base
2 3
Internet
(COMPUTADORA CORRESPONSAL)
CH
1
Figura 3.57.- Mecanismo bsico de encaminamiento de IP mvil. Como se muestra en la Figura 3.57, cuando una MH est conectada a Internet fuera de su dominio local o emplazamiento base o casa, dos procesos o agentes que se ejecutan en un router de MH son responsables de reencaminar los correspondientes datagramas. Estos agentes son el agente casa, HA (Home Agent) y el agente forneo, FA (Foreign Agent). Dichos procesos se ejecutan en el sitio base y en la ubicacin actual de la MH respectivamente. En este contexto:
138
Tambin, Nodo Mvil (Mobile Node) o Agente Mvil (Mobile Agent).
- 238 -
HA es el responsable de registrar la localizacin actual de MH, es decir, la direccin IP que dispone en un momento dado en funcin de su nueva ubicacin. As, cuando MH abandona su emplazamiento base o dominio local o casa, debe informar a HA, el cual durante la ausencia de MH se comportar como su representante o proxy. Para ello, HA informa a los routers locales de que eliminen cualquier registro asociado a la direccin IP de MH. Mientras HA acta como proxy, responder a las solicitudes de ARP referidas a la direccin IP de MH con su propia direccin de red como si fuera la direccin de red de la citada MH. Cuando MH est en su, casa, los datagramas se encaminan hacia su red o subred de la forma habitual. De esta manera, cuando un potencial emisor o computadora corresponsal, CH (Correspondent Host), desea enviar un datagrama a dicha MH, lo transmite registrando su direccin como la direccin IP de origen, y la direccin de MH como la direccin IP de destino. Este datagrama ser interceptado por el router de MH denominado HA que gestiona en su red o subred todas las MH existentes y que lleva un registro de sus actuales ubicaciones. Si MH se localiza en su red o subred, HA simplemente reenva el datagrama a su red o subred local base. Cuando MH se mueve a una red o subred exterior, informa a FA de su nueva ubicacin. FA le asigna una direccin IP temporal y provisional en funcin de dicha red o subred exterior. Generalmente, dicha direccin que refleja la localizacin actual de MH, es la direccin de FA. Seguidamente, FA139 contacta con HA proporcionndole la direccin IP base de MH y la direccin que se ha reservado para l. Una vez que HA conoce la nueva direccin de MH, HA puede enviar el datagrama hacia MH a travs de FA. HA tambin enva la direccin provisional de MH a CH. Si ste es capaz de gestionar IP mvil, tendr en cuenta dicha direccin para las siguientes comunicaciones con MH. Esto ltimo, evitar las sobrecargas de reencaminar hacia HA. Si no es as, entonces ignorar el cambio de direccin y las siguientes transmisiones continuarn siendo reencaminadas a travs de HA.
139
Tambin podra ser MH quien contactara con HA.
- 239 -
Permanente
HA
(200.1.2.1)
FA
ICMPv4 tipo 9 de descubrimiento de router (anuncio de agente )
MH (200.1.2.5)
(208.10.1.4) Provisional
(208.10.1.1) Dir_provisional: 208.10.1.1, 208.10.1.2, ...,208.10.1.4,

Solicitud de registro (UDP-434)
Solicitud de registro (UDP-434)
Dir_provisional: 208.10.1.4 HA: 200.1.2.1 MH: 200.1.2.5
Dir_provisional: 208.10.1.4 HA: 200.1.2.1 MH: 200.1.2.5

Respuesta de registro (UDP-434)
HA: 200.1.2.1 MH: 200.1.2.5
Respuesta de registro (UDP-434)
HA: 200.1.2.1 MH: 200.1.2.5
Figura 3.58.- El registro con HA. La Figura 3.58 describe el registro con HA mediante las distintas interacciones efectuadas entre FA, MH y HA a travs del intercambio de los correspondientes mensajes de control. El objetivo es reservar una direccin IP de manera fija a MH y efectuar posteriormente el encaminamiento de IP mvil entre una potencial mquina CH y MH. Los mensajes de informacin de control anteriormente citados son los que se describen a continuacin: 1. Una vez MH (200.1.2.5) se ha marchado de su RAL (Red de rea Local) nativa y despedido de HA (200.1.2.1), llega a una RAL remota. Cuando MH se conecta a la nueva RAL, descubre que existe un FA al recibir por difusin un mensaje de ICMPv4 (tipo 9 y cdigo 0) de descubrimiento de router o anuncio de router140, el cual encapsula, a su vez, un mensaje de anuncio de agente con una informacin especfica para la mquina MH. El resultado del envo anterior se basa fundamentalmente en la siguiente informacin: Direccin IP del router (en el mensaje ICMP de descubrimiento de router).
140
Igualmente, hay unos mensajes de ICMPv4 (tipo 10 y cdigo 0) de solicitud de mensajes de descubrimiento de router, los cuales los puede enviar MH por difusin sin necesidad de esperar a recibir un mensaje de anuncio de agente. Posteriormente, FA transmite por unidifusin a MH la respuesta correspondiente.
- 240 -
Un bit de control activado (en el mensaje encapsulado de anuncio de agente) indicando si el router hace el papel de FA o de HA. Una lista de direcciones provisionales de IP (en el mensaje encapsulado de anuncio de agente) proporcionadas por FA141 para asignarlas de forma temporal. De todas estas direcciones, MH selecciona una (p.ej., 208.10.1.4). Un tiempo de vida de registro (de 16 bits en el mensaje encapsulado de anuncio de agente) que permite especificar el tiempo en segundos en que cualquiera de las direcciones provisionales son vlidas.
2. Seguidamente, MH transmite a FA un mensaje de control de solicitud de registro propio de su aplicacin de IP mvil la cual se monta sobre UDP en el puerto 434. En este mensaje se indica la direccin provisional seleccionada por MH (208.10.1.4), la direccin IP de HA (200.1.2.1) y la direccin local o nativa o permanente de MH (200.1.2.5). 3. A continuacin, FA enva a HA el mismo mensaje anterior (paso 2.) que recibi de MH. Como ya se ha indicado, este mismo mensaje lo podra haber mandado directamente MH a HA una vez se lo ha enviado a FA. A partir de ahora, HA sabe que FA es su extremo de tnel para todo mensaje que tenga como destino MH. 4. Seguidamente, HA transmite a FA142 otro mensaje de control de respuesta de registro confirmando su direccin de HA (200.1.2.1) y la provisional de MH (200.1.2.5). 5. Finalmente, FA enva a MH el mismo mensaje anterior (paso 4.) que recibi de HA. Para que HA pueda enviar datagramas directamente a MH se utiliza un mecanismo de tnel cuyo procedimiento se describe en la Figura 3.59. Si CH desea enviar un datagrama a MH, HA encapsula dicho datagrama en otro datagrama para envirselo a FA. Evidentemente, cambian las direcciones de origen y destino de la cabecera de
141
Una de las posibles direcciones puede ser la propia de FA. De la cabecera de IP, que encapsula el mensaje de solicitud de registro, obtiene la direccin IP de FA.
142
- 241 -
informacin de control del datagrama. Ahora, el origen y destino de dicho datagrama sern HA y FA; HA por ser el extremo transmisor en el tnel, es decir, por realizar el primer encapsulado y FA por ser el extremo receptor del tnel, es decir por llevar a cabo, a su vez, el desencapsulado final del datagrama. Se resalta de nuevo que la direccin de destino FA o direccin del otro extremo del tnel es la direccin provisional de MH. Ahora, FA puede entregar el datagrama a MH. Por consiguiente, el resultado es que, finalmente, llega a MH el datagrama original tal y como sali del origen CH y, lo ms importante, sin que CH se haya dado cuenta de la nueva ubicacin de MH.
CH
Internet
HA
HA
Internet
FA
Red Exterior
MH
FA
Tnel de IP mvil
Inicio y Final del tnel de IP mvil
Origen: A Destino: MH Destino: E
Flujo: CH Origen: x
Origen: HA Destino: FA
Origen: CH Destino: MH
Origen: HA Destino: FA
Origen: CH Destino: MH datos
Origen: A Destino: MH Destino: E
Flujo: CH Origen: x
datos datos
datos
Origen y Destino reales
datos datos
Figura 3.59.- Encapsulamiento IP sobre IP para un tnel de IP mvil. En la siguiente Figura 3.60 se describe con ms detalle la transmisin de un datagrama IP desde CH hasta MH va el tnel de HA y FA y la respuesta correspondiente a travs de FA. Cuando FA desencapsula el datagrama original y lo transmite a MH, cambia el campo de destino; ahora, elimina la direccin fija o permanente de MH (200.1.2.5) y pone su direccin actual o provisional (208.10.1.4), manteniendo la direccin de origen (CH). A su vez, cuando FA recibe el datagrama de respuesta de MH, cambia la direccin de origen provisional de MH y pone la fija o permanente de sta. Finalmente, FA encamina dicho datagrama por Internet hasta CH. Se resalta que MH no puede alterar el contenido del campo de origen y poner directamente su direccin fija o nativa; primero, porque debe responder a cualquier solicitud de ARP con su direccin provisional y, segundo, porque FA puede disponer de un cortafuegos (firewall) que no deje pasar datagramas con direcciones de origen diferentes a las de su RAL.
- 242 -
Permanente
CH
(215.100.12.16)
Datagrama IP
HA
Origen: 215.100.12.16 Destino: 200.1.2.5
(asociacin) (200.1.2.5/208.10.1.4)
FA
(asociacin) (208.10.1.4/200.1.2.5)
MH (200.1.2.5)
(208.10.1.4)
(200.1.2.1)
tnel
Datagrama IP
(208.10.1.1)
Origen (tnel): 200.1.2.1 Destino (tnel): 208.10.1.1 Origen real: 215.100.12.16 Destino real: 200.1.2.5
Provisional
Datagrama IP
Cambiado por FA
Origen: 215.100.12.16 Destino: 208.10.1.4
Datagrama IP
Cambiado por FA
Datagrama IP
Origen: 208.10.1.4 Destino: 215.100.12.16
Origen: 200.1.2.5 Destino: 215.100.12.16
Figura 3.60.- Un ejemplo de encaminamiento de IP mvil. Para terminar, en la siguiente Figura 3.61 se muestra lo que se indic con anterioridad para el caso de que CH sea capaz de gestionar IP mvil. Una vez que recibe de HA la direccin provisional de MH y la direccin de FA, CH tendr en cuenta dichas direcciones para las siguientes comunicaciones con MH. Ahora el tnel ser entre CH y FA. El resto de las acciones de FA son las que se describen en la anterior Figura 3.60. Como se coment, esto ltimo evitar las sobrecargas de reencaminar hacia HA.
(COMPUTADORA MVIL)
Primer datagrama dirigido al FA (mediante un tnel)
MH
(AGENTE FORNEO)
(AGENTE DE CASA)
FA
HA
Red Exterior
Red Local Base
Internet
1a
Direccin del FA devuelta al emisor va el HA
l) ne 2 (t
3 (tnel)
Siguientes datagramas dirigidos directamente al FA (mediante un tnel)
CH
(COMPUTADORA CORRESPONSAL)
Figura 3.61.- Otro mecanismo de encaminamiento de IP mvil.
- 243 -
IP mvil fue originariamente definido para IPv4, antes de que IPv6 existiera. Sin embargo, las soluciones de IPv4 mvil e IPv6 mvil comparten ideas similares aunque su implementacin es diferente. En la solucin de IP mvil para IPv6, desaparecen los FA mediante un procedimiento basado en una autoconfiguracin automtica a travs de la recepcin de mensajes ICMPv6 de anuncios de router. Por tanto, los elementos que intervienen en la movilidad en IPv6 son los HA y MH. Como conclusin se puede afirmar que la solucin de IP mvil es efectiva, pero no demasiado eficiente. Obviamente, sera preferible una solucin143 que permitiera viajar a las MH por Internet sin previo aviso y encaminar los datagramas sin el uso de tneles.
3.1.5 Multidifusin IP en Internet: Protocolo IGMP de gestin de grupos de Internet

Segn se indic al tratar las direcciones de la clase D de IPv4, la multidifusin permite la transmisin de un nico datagrama IP desde el origen a un conjunto de mquinas destinatarias que forma un nico grupo de multidifusin y que no tienen porqu estar conectadas a la misma red de rea local. Incluso, dichas mquinas pueden estar en redes fsicamente separadas por Internet. La multidifusin IP emplea el mismo concepto de entrega con el mejor esfuerzo que en otras entregas de datagramas IP. Por consiguiente, puede que los datagramas de multidifusin se pierdan, se borren, se dupliquen o lleguen de forma desordenada. En este escenario, la pertenencia a un grupo de multidifusin es un proceso dinmico, es decir, una mquina puede unirse o abandonar un grupo en cualquier momento. Asimismo, una mquina puede ser miembro de un nmero indeterminado de grupos de multidifusin. Adems, una mquina puede enviar datagramas hacia un grupo de multidifusin sin ser un miembro de dicho grupo. La multidifusin IP puede utilizarse en una sola red fsica o a travs de una red de redes. En este ltimo caso, existen unos dispositivos especiales de encaminamiento conocidos como routers de multidifusin que son los encargados de realizar el oportuno envo. Dichos routers difunden informacin sobre la pertenencia de grupos de manera que cada miembro de un grupo de multidifusin recibe una copia de todos los datagramas enviados al grupo. Las mquinas comunican su pertenencia, a un grupo, a los routers locales de multidifusin mediante el protocolo IGMP (Internet Group Management Protocol) de Gestin de Grupos de Internet (RFC-1112). Concretamente, los mecanismos de este protocolo permiten dos acciones fundamentales:
Algo as a la solucin aportada en las redes de telefona celular, donde los telfonos mviles no cambian sus nmeros de telfono segn se van moviendo entre clulas o incluso entre pases. Simplemente, notifican a la estacin base de la clula local su presencia cada cierto tiempo.
143
- 244 -
1. Que las mquinas destinatarias o sistemas finales en una red de rea local (IEEE 802) informen a sus routers locales de que desean unirse a un grupo especfico de multidifusin, es decir, desean recibir transmisiones dirigidas a dicho grupo. 2. Que los routers de multidifusin interroguen o sondeen peridicamente a su red de rea local para saber si los miembros, de un grupo conocido, continan an activos. Si hay ms de un router de multidifusin, uno de ellos se selecciona como emisor de este tipo de mensajes. Concretando an ms conceptualmente, el protocolo IGMP consta de dos fases: Fase I.- Cuando una mquina se une a un nuevo grupo de multidifusin, enva un mensaje o informe IGMP (tipo 2) de pertenencia a grupo (Host Membership Report) con la direccin de destino IP conteniendo la direccin de multidifusin del grupo al que pertenece la mquina de origen. Este mensaje IGMP tambin lo escuchan los routers locales de multidifusin, en la misma red de acceso, para realizar el correspondiente registro de pertenencia. Asimismo, el datagrama IP que encapsula dicho informe lleva un TTL = 1 para indicar expresamente que este tipo de mensaje IGMP se transmite directamente a la red de acceso y no debe ser reenviado por ningn otro router de multidifusin. A su vez, el router o routers locales se ponen en contacto con otros routers de multidifusin, pasando la correspondiente informacin y registrando, en sus tablas, las oportunas rutas en funcin de dichas pertenencias para la posterior fase de transferencia de datos. Una mquina slo tiene que emitir un informe IGMP de pertenencia por cada grupo al que pertenezca. Cuando una mquina final o destinataria se une a un determinado grupo de multidifusin, enva inmediatamente un informe de pertenencia sin esperar al siguiente sondeo. Fase II.- Debido a que la pertenencia es dinmica, los routers locales de multidifusin sondean de forma peridica, mediante un mensaje IGMP (tipo 1) de solicitud de pertenencia a grupo (Host Membership Query message) a las mquinas vecinas de su red de rea local para determinar aqullas que se mantienen como miembros de grupos. Este mensaje IGMP de solicitud o sondeo se enva en un datagrama IP con la direccin de destino IP conteniendo la direccin reservada de multidifusin, 224.0.0.1, que semnticamente quiere decir a todas las mquinas en esta red de rea local. Asimismo, dicho datagrama IP lleva un TTL = 1 para indicar que este tipo de mensaje IGMP no debe ser reenviado por ningn otro router de multidifusin. Tambin, de esta forma, una aplicacin puede realizar una
- 245 -
bsqueda expandida de un determinado servidor. El primer datagrama llevar un TTL = 1. Si no hay respuesta, se enva otro datagrama con TTL = 2 y as sucesivamente. Mediante este procedimiento, la aplicacin puede acceder al servidor ms cercano en trminos de saltos. En este contexto, para que un router de multidifusin pueda difundir alguna informacin de pertenencia a otros routers anlogos, debe determinar si una o ms mquinas, en su red de rea local, han decidido unirse a un grupo de multidifusin. Si en un grupo no se reciben informes de miembros despus de varios sondeos, el router de multidifusin asume que no hay destinatarios en la red que se mantengan en el grupo y deja de anunciar miembros del grupo a otros routers de multidifusin. Cuando una mquina destinataria recibe una solicitud, debe responder con un informe por cada grupo al que pertenece. Asimismo, una mquina destinataria no emite ningn informe si quiere abandonar el grupo. Se resalta, adems, que un router no tiene porqu conocer cuntas mquinas pertenencen a un grupo particular; slo le debe interesar saber que al menos una mquina pertenece a un determinado grupo. Como se puede ver, intercambiando solicitudes IGMP (entre routers y mquinas destinatarias en la misma red) e informes IGMP (entre mquinas destinatarias y routers en la misma red), un router de multidifusin puede conocer los grupos de multidifusin que estn activos en su propias redes. De esta manera, dicho router puede reenviar un datagrama entrante a las mquinas destinatarias, pertenecientes al grupo en cuestin, por los enlaces implicados.
M2 M3
G1
R2
G2
R1
M1
ORIGEN
M4
R3
R5
M5
G1
R4
2 datagramas IP de unidifusin Flujo de multidifusin Flujo de unidifusin
M6
G2
G3
Figura 3.62. Multidifusin IP frente a unidifusin IP.
- 246 -
En la anterior Figura 3.62, el origen (mquina M1) desea transmitir a los destinos pertenecientes al grupo de multidifusin G1. Aunque M1 puede enviar cada copia del datagrama separadamente a cada destino utilizando el encaminamiento unidifusin convencional; un mtodo, ms eficiente, sera minimizar el nmero de copias. Por ejemplo, cuando el router R1 recibe un datagrama de M1, lo enva simultneamente a los routers R2 y R3. Seguidamente, R2 lo enva144 a su red de rea local y R3, a su vez, lo retransmite a R5. Finalmente, el datagrama ser recibido por cada uno de los destinos deseados. Obviamente, se supone que tanto R2 como R3, han recibido previamente de R5, informacin con la pertenencia de la mquina destinataria M4 al grupo G1. Asimismo, R2 ha tenido que recibir, con anterioridad, un informe transmitido por M2 de su pertenencia al grupo G1. En el encaminamiento por multidifusin cada datagrama se transmite una sola vez por cada enlace. Si se utilizara un encaminamiento por unidifusin, el enlace entre el origen M1 y el router R1 transportara dos copias por cada datagrama transmitido. Generalmente, un encaminamiento por multidifusin ahorra ancho de banda conforme se incrementan los destinos. Mediante la multidifusin, el origen del flujo se independiza del nmero de receptores y se optimiza el uso de los diferentes recursos en la red (p.ej., el ancho de banda ya mencionado)
M2 M3
G1
R2
G2
M3 no est interesado en el datagrama IP de difusin
R1
M1
ORIGEN
M4
R3
R5
M5
G1
R4
M5 no est interesado
G2
en el datagrama IP de difusin
1 datagrama IP de unidifusin
M6
M6 no est interesado
Flujo de multidifusin Flujo de difusin
en el datagrama IP de difusin
G3
Figura 3.63.- Multidifusin IP frente a difusin IP.
Como ya se estudiar, R2 no transmite una copia a R5 porque tiene constancia de que existe otro envo de la misma informacin por otro camino (R1-R3-R5).
144
- 247 -
Segn se describe en la anterior Figura 3.63, en el encaminamiento por difusin, al igual que por multidifusin, cada datagrama se transmite una sola vez por cada enlace; pero de una forma menos selectiva. Por tanto, en la difusin, el envo de la informacin se realiza de una manera indiscriminada a todos los destinos, mientras que en multidifusin, slo se difunde la informacin a los destinos que hayan manifestado expresamente su inters en recibirla.
INTERNET
IGMP
Mdulo IGMP Mdulo IP
IP
ACCESO A RED
Interfaz de Red
Hardware
Figura 3.64.- Ubicacin del protocolo IGMP en la arquitectura TCP/IP. Como ya se ha indicado, IGMP permite que una computadora indique a su router vecino de multidifusin (conectado a la misma red de acceso) su pertenencia a un grupo de multidifusin. Visto de otra forma, el protocolo IGMP se emplea por los routers de multidifusin para encontrar miembros de cualquier grupo de multidifusin en las redes de rea local a las cuales estn conectados dichos routers. En este contexto, y segn se muestra en la Figura 3.64, el protocolo IGMP es anlogo al ICMP. Al igual que el protocolo ICMP, IGMP est tan ntimamente ligado al protocolo IP145, que de hecho se puede ver como una parte integral de IP (no como un protocolo separado), es decir, un mdulo ms dentro del propio mdulo o proceso IP.
145
Funciona directamente sobre IP utilizando el tipo de protocolo 2.
- 248 -
DATAGRAMA IGMP DE DIFUSIN
Cabecera IGMP
Datos
DATAGRAMA IP
Cabecera IP
Datos
Cabecera trama
Datos
Figura 3.65.- Encapsulacin de un mensaje IGMP. Segn se describe en la Figura 3.65, el protocolo IGMP encapsula un mensaje IGMP en un datagrama IP. De ah que IGMP ocupe un subnivel superior al ocupado por el protocolo IP en el mismo nivel de Internet o red de la arquitectura TCP/IP. Como tambin se ha estudiado, las direcciones de multidifusin (clase D) slo pueden emplearse como direcciones de IP de destino. stas nunca aparecen en el campo de direccin del origen de un datagrama. Sin embargo no se generan mensajes de error ICMP relacionados con datagramas de multidifusin. Cuando se encapsula un mensaje IGMP o datagrama IGMP para su transmisin, la direccin de destino IP es la direccin de multidifusin, por ejemplo, 224.0.0.1 224.0.0.2 o grupo al que se est informando. As, los datagramas que transportan mensajes IGMP son transmitidos mediante un hardware de multidifusin si ste est disponible. Ms en concreto, lo que tiene que estar disponible es el software del interfaz de la red de acceso, capaz de transformar una direccin IP de multidifusin en la correspondiente direccin de hardware de multidifusin. Consecuentemente, en aquellas redes que no soporten el hardware de multidifusin IP nunca recibirn mensajes IGMP.
- 249 -
5 bits de la direccin IP de multidifusin no usados en la direccin Ethernet
Direccin IPv4 Clase D
1110xxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
23 bits de menor orden de la direccin IP de multidifusin copiados en la direccin Ethernet
00000001
00000000
01011110
01
00 HEXADECIMAL
5E
48 bits de una direccin IEEE 802

Figura 3.66.- Traslacin (mapping) IPv4 Clase D en multidifusin IEEE 802. En la Figura 3.66 se muestra la traslacin (mapping) de una direccin IPv4 clase D en una direccin MAC IEEE 802146 de multidifusin, por ejemplo, en una direccin Ethernet147 (IEEE 802.3). La citada traslacin se ajusta al siguiente procedimiento: Se incluyen los 23 bits de menor orden o menos significativos de la direccin de multidifusin IP148 dentro de los 23 bits de orden inferior de la direccin de multidifusin Ethernet. Los diseadores utilizaron 23 de los 28 bits para una direccin de hardware porque la mayor parte de las direcciones de multidifusin estn incluidas. El conjunto de direcciones es lo suficientemente extenso149 como para que la posibilidad de que dos grupos seleccionen direcciones idnticas con los 23 bits de orden inferior sea muy pequea. La consecuencia de este diseo es que algunos datagramas de multidifusin pueden recibirse en una mquina, aunque los datagramas no estn destinados a tal mquina. Ser la entidad IP quien verifique cuidadosamente las direcciones en todos los datagramas entrantes y elimine cualquier datagrama no esperado.
146
Una direccin MAC IEEE 802 consta de 48 bits.
147
Quiere decir esto, que una red de rea local del tipo Ethernet (IEEE 802.3) soporta multidifusin en el protocolo del interfaz de acceso a dicha red.
Se recuerda que una direccin IP de multidifusin (clase D) comienza por 1110 y, a continuacin, aparecen los 28 bits restantes de identificacin del grupo. Por consiguiente, quedan 9 bits sin usar; quiere decir esto, que potencialmente puede haber 29 512 grupos potenciales que selecciones idnticas direcciones.
149
148
- 250 -
Todas las direcciones Ethernet (IEEE 802.3) de multidifusin disponen de los mismos 25 primeros bits, 00000001 00000000 01011110 0. Ms en concreto, 0x01-00-5E (00000001 00000000 01011110) es la notacin en hexadecimal de los tres primeros octetos que se correponden con el identificador nico del fabricante de la tarjeta. El bit a continuacin, que siempre est a cero, pertenece al siguiente bloque de 24 bits que identifican a la tarjeta del fabricante en cuestin. Por consiguiente, el rango completo de direcciones MAC IEEE 802 de multidifusin es de 01:00:5e:00:00:00 a 01:00:5e:7f:ff:ff. Obviamente, para poder participar en una multidifusin IP, una mquina debe poseer el software que le permita enviar y recibir datagramas de multidifusin. El software de IP debe permitir a una aplicacin especificar una direccin de multidifusin como una direccin IP de destino. Asimismo, como ya se ha indicado, el software del interfaz de la red de acceso debe ser capaz de transformar una direccin de multidifusin IP en la correspondiente direccin de multidifusin150 de hardware. A su vez, el formato de una direccin IPv6 de multidifusin es el que se muestra en la Figura 3.67.
Bits 8
11111111
4 000 T
4 Alcance
112 Identificador de grupo
Alcance o lmite del grupo de multidifusin: Nmero entero de 4 bits. 0: reservado; 1: Nodo local o en la propia mquina; 2: enlace local; ; 5: sitio local; ; 8: organizacin local (compuestas de varios sitios);
T (transitorio o transient) = 0: Direccin no transitoria o asignada permanentemente por IANA/ICANN T (transitorio o transient) = 1: Direccin transitoria o no asignada permanentemente
Figura 3.67.- Formato de la direccin IPv6 de multidifusin. Actualmente, para trasladar una direccin IPv6 de multidifusin en una direccin MAC IEEE 802, se cogen los 32 bits de menor orden de la direccin IPv6.
150
O utilizar la difusin si el hardware no soporta la multidifusin.
- 251 -
Bits 8
11111111
4 000 T
4 Alcance
80
32
Identificador de grupo
000..0
Todo a ceros
Alcance o lmite del grupo de multidifusin: Nmero entero de 4 bits. 0: reservado; 1: Nodo local o en la propia mquina; 2: enlace local; ; 5: sitio local; ; 8: organizacin local (compuestas de varios sitios);
T (transitorio o transient) = 0: Direccin no transitoria o asignada permanentemente por IANA/ICANN T (transitorio o transient) = 1: Direccin transitoria o no asignada permanentemente
Figura 3.68.- Formato actual de la direccin IPv6 de multidifusin. Pero de esos 32 bits, slo se puede incluir los 23 bits151 anteriormente citados en la direccin de multidifusin de la red Ethernet. Como ya se ha indicado, ser la entidad IP quien verifique cuidadosamente las direcciones de grupo de todos los datagramas entrantes y elimine cualquier datagrama perteneciente a grupos de multidifusin inexistentes en la correspondiente mquina.
Bits
0 Versin
4 Tipo
8 Sin uso
16 Suma de comprobacin
31
Direccin de grupo clase D (cero en solicitud)
Figura 3.69.- Formato de un mensaje IGMP. Como se puede ver en la Figura 3.69, el formato de un mensaje IGMP (8 octetos) es muy simple, en funcin de los siguientes campos: Versin (4 bits).- Identifica el nmero de versin (la versin actual es la 2)152. Tipo (4 bits).- Indica el tipo de mensaje. Existen dos tipos de mensaje:
151
Por consiguiente, al igual que con IPv4, quedan 9 bits sin usar; quiere decir esto, que potencialmente puede haber 29 512 grupos potenciales que selecciones idnticas direcciones. Actualmente, existen tres versiones (1, 2 y 3), de las cuales, la versin 1 es la base fundamental de las otras dos que se mencionan ms adelante en este libro. La versin 2 es la versin actual incorporada en la mayora de los sistemas operativos.
152
- 252 -
Tipo 1.- Indica un mensaje, de solicitud de pertenencia a grupo, enviado por un router de multidifusin a todas las mquinas conectadas a la misma red de acceso. Tipo 2.- Indica un informe de pertenencia a grupo enviado por una mquina destinataria incluida en dicho grupo al resto de mquinas, tambin, pertenecientes al citado grupo en la misma red de acceso. Sin uso (8 bits).- Todo a ceros. Suma de comprobacin (16 bits).- Se aplica a todo el mensaje IGMP (8 octetos). Se calcula con el mismo algoritmo que el utilizado para IP y TCP. Direccin de grupo (32 bits).- Esta es la direccin IPv4 de la clase D. Contiene todo a ceros en un mensaje de solicitud, o bien una direccin de grupo en una respuesta. El protocolo IGMP se ha diseado con el objetivo de evitar una congestin en una red de rea local en funcin de los siguientes apartados: Toda la comunicacin entre mquinas destinatarias y routers de multidifusin utilizan multidifusin IP. Un router de multidifusin no enva mensajes de solicitudes individuales para cada grupo de multidifusin, sino un mensaje de solicitud (sondeo) para solicitar informacin relacionada con la pertenencia en todos los grupos. Las mquinas que son miembros de varios grupos no envan respuestas mltiples al mismo tiempo. Cuando un mensaje de solicitud de IGMP llega desde un router de multidifusin, la mquina asigna un retardo aleatorio entre 0 y 10 segundos para cada grupo, y enva una respuesta al correspondiente grupo despus del retardo. As, una mquina separa sus respuestas aleatoriamente dentro de un lapso de 10 segundos. Resumiendo, cuando un router de multidifusin enva un mensaje de solicitud, todas las mquinas destinatarias, en la misma red de rea local, asignan un retardo aleatorio para las respuestas. Las mquinas escuchan las respuestas de otras mquinas y no envan respuestas innecesarias. En este contexto, es importante resaltar que los routers no necesitan conservar un registro exacto de los miembros de un grupo porque todas las transmisiones hacia el grupo se envan mediante un hardware de multidifusin. Slo tienen que saber si existe al menos una mquina de un grupo en particular. Cuando la mquina con el retardo ms pequeo enva su - 253 -
respuesta mediante multidifusin, otras mquinas participantes reciben una copia. Cada mquina asume que el router de multidifusin tambin recibi una copia de la primera respuesta y cancela su respuesta. Resumiendo, se puede mejorar la eficiencia si las mquinas monitorizan si otra enva el mismo informe antes de la transmisin programada. Si otra mquina ha enviado el mismo informe, la primera cancela el suyo. As en la prctica, slo una mquina de cada grupo responde a un mensaje de solicitud desde el router de multidifusin.
Me callo porque he escuchado el informe de M1
G1
M4
G2
M2
Solicitud de pertenencia a grupos Origen IP=R1 Destino IP=224.0.0.1 TTL=1 Grupo IGMP=0 Informe de pertenencia a G1 Origen IP=M1 Destino IP=G1
R1
M3
M1
TTL=1 Grupo IGMP=G1
G3
G1
Figura 3.70.- Envo de solicitudes e informes de pertenencias a grupos. En el ejemplo de la Figura 3.70, el router de multidifusin R1 enva un mensaje IGMP de solicitud de pertenencia al grupo G1. Suponiendo que M1 dispone de un retardo de respuesta inferior a M4, M1 responde con un mensaje IGMP que contiene un informe de pertenencia al grupo G1. Este ltimo mensaje se transmite slo al grupo G1, al que pertenece la mquina de origen, con el objetivo de que el resto de mquinas de dicho grupo escuchen el mensaje y desactiven sus temporizadores de respuesta para no tener que mandar otro informe repetido. Por consiguiente, aparte de R1, este ltimo mensaje tambin lo escucha la mquina M4; pero sta no transmite otro mensaje similar ya que a R1 le basta con saber que al menos una mquina (en este caso M1) pertenece a G1. Mediante esta tcnica de supresin de informes IGMP de pertenencias a grupos se impide que la red se sature.
- 254 -
Actualmente, existen varias versiones del protocolo IGMP: IGMP Versin 1 (RFC-1112).- Recoge todo lo que se ha estudiado hasta el momento. IGMP Versin 2 (RFC-2236).- Es la versin actualizada y mejorada de IGMPv1. Mantiene la compatibilidad con IGMPv1, introduciendo nuevos mensajes, mecanismos y mejoras que ayudan a que el encaminamiento de multidifusin sea ms ptimo y escalable. Por ejemplo, define un procedimiento propio para la eleccin del nico router que debe sondear en cada red de rea local. Incluso permite al router que sondea, establecer en la cabecera de sus mensajes un tiempo mximo de respuesta. La especificacin completa se puede encontrar en draft-ietfidmr-igmp-v2-01.txt. IGMP Versin 3 (RFC-3376).- Se asume que es la versin actualizada y mejorada para un futuro de IGMPv2 e IGMPv1. De momento, se est trabajando en dicha versin y, por tanto, todava es pronto para indicar sus peculiaridades ms bsicas. Para mayores detalles se puede encontrar su especificacin en draft-cain-igmp-00-txt.
La multidifusin IP en funcin del protocolo IGMP es un estndar en la arquitectura TCP/IP; sin embargo, no existe un estndar para la difusin de informacin de encaminamiento entre routers de multidifusin. Ya se estudiar que existen otros protocolos (RPB, RPM y DVMRP) que pueden ser utilizados por los routers de multidifusin para difundir, entre ellos, la informacin de pertenencia a grupos. Se valen de esta informacin para establecer rutas y, as, entregar la copia de un datagrama de multidifusin a todos los miembros de todos los grupos de multidifusin. Finalmente, conviene recordara que IGMP es el protocolo de gestin de grupos de Internet para IPv4. El equivalente para IPv6 se denomina MLD (Multicast Listener Discovery) y se recoge en el documento RFC-2710.
- 255 -
3.2

Bibliografa
RFC-791: Internet Protocol. RFC-1700: Assigned Numbers RFC-1349: Type of Service in the Internet Protocol Suite. RFC-2050: "Internet Registry IP Allocation Guidelines". RFC-1812: "Requirements for IP Version 4 Routers". RFC-792: "Internet Control Message Protocol". RFC-950: "Internet Standard Subnetting Procedure" (actualiza el documento RFC 792). RFC-896: "Congestion Control in IP/TCP Internetworks". RFC-1191: "Path MTU discovery". RFC-1435: "IESG Advice from Experience with Path MTU Discovery". RFC-1256: "ICMP Router Discovery Messages". RFC-2460: "Internet Protocol, Version 6 (IPv6) Specification". RFC-1809: Using the Flow Label Field in IPv6. RFC-3513: IP Version 6 Addressing Architecture. RFC-2463: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC-2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering. RFC 2401: Security Architecture for the Internet Protocol, 1998. RFC-2406: IP Encapsulating Security Payload (ESP), 1998. RFC-1887: An Architecture for IPv6 Unicast Address Allocation. RFC-2893: Transition Mechanisms for IPv6 Hosts and Routers. RFC-3056: Connection of IPv6 Domains via IPv4 Clouds. RFC-2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. RFC-2185: "Routing Aspects of IPv6 Transition. INTERNET DRAFT: Dynamic Host Configuration Protocol for IPv6 (DHCPv6), http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt. RFC-1112: Host extensions for IP multicasting. RFC-1122: Requirements for Internet Hosts - Communication Layers. RFC-2236: Internet Group Management Protocol, Version 2. RFC-2710: Multicast Listener Discovery (MLD) for IPv6. RFC-3344: IP Mobility Support for IPv4. RFC-3376: Internet Group Management Protocol, Version 3. Sistemas Distribuidos: Conceptos y Diseo, G. Coulouris, J. Dollimore, T. Kindberg, 3 edicin, Addison-Wesley, 2001. TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Redes Globales de Informacin con Internet y TCP/IP, Principios bsicos, protocolos y arquitectura, Douglas E. Comer, 3 Edicin, Prentice Hall, 1996. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000.
- 256 -
TCP/IP Illustrated Volume 1: The Protocols, R.W. Stevens, Addison-Wesley, 1994. Comunicaciones y Redes de Computadores, W. Stallings, 6 Edicin, Prentice Hall, 1997. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. TCP/IP Arquitectura, protocolos e implementacin con IPv6 y seguridad de IP; Dr. Sydney Feit, Osborne McGraw-Hill, 1998.
- 257 -
- 258 -
Captulo 4. Encaminamiento Dinmico de Unidfusin
4. ENCAMINAMIENTO UNIDIFUSIN
DINMICO
DE
A continuacin, se analizan las estrategias y los protocolos ms relevantes a la hora de facilitar el encaminamiento de forma dinmica por Internet
4.1
Algoritmos y protocolos de encaminamiento dinmico
INTERNET
Protocolos ROUTERS AVANZADOS (OSPF)
IP
ACCESO A RED
Interfaz de Red
Hardware
Figura 4.1.- El protocolo OSPF en la arquitectura TCP/IP. La Figura 4.1 muestra la posicin que ocupa uno de los protocolos ms significativos (OSPF) para encaminar dinmicamente por los routers internos de una organizacin. En concreto, el protocolo OSPF est ubicado en el nivel de red, un estrato superior al ocupado por IP, ya que sus mensajes se encapsulan directamente en datagramas IP. Las estrategias de encaminamiento en Internet se clasifican en dos clases: ESTTICAS: Estas estrategias no adaptativas se basan en unas rutas fijas establecidas de antemano y en donde las decisiones o informaciones de encaminamiento se determinan previamente fuera de lnea y, posteriormente, se cargan en los routers de la organizacin. Estas informaciones de encaminamiento no varan aunque la red s lo haga, es decir, estas estrategias no se adaptan a los cambios que pueda sufrir la red durante su funcionamiento. Por - 259 -
ejemplo, si hay que introducir un nuevo destino o eliminar uno ya existente, hay que parar la red para actualizar debidamente todos los routers de la organizacin. DINMICAS: Estas estrategias adaptativas se basan en unas rutas dinmicas (no establecidas de antemano) y en donde las informaciones de encaminamiento varan en la medida en que lo haga la red. Por ejemplo, si hay que introducir un nuevo destino o eliminar uno ya existente, se actualizan dinmicamente todos los routers de la organizacin sin necesidad de parar la red. Por consiguiente, estas estrategias se adaptan a los cambios que pueda sufrir la red durante su funcionamiento. En este escenario, y para una mayor comprensin, se puede clasificar a los sistemas intermedios en dos tipos: ROUTERS ESTTICOS O BSICOS: Basados en una estrategia de encaminamiento esttica o no adaptativa. ROUTERS DINMICOS O AVANZADOS: Basados en una estrategia de encaminamiento dinmica o adaptativa. Posteriormente, independientemente de que las informaciones de encaminamiento se introduzcan o actualicen a mano (parando la red) o se registren automticamente; el encaminamiento que lleva a cabo el protocolo IP es basndose en los encaminamientos directos, indirectos o por omisin ya analizados. En este contexto, se dice que dos routers son vecinos o contiguos si disponen de un interfaz a una red comn. Los routers dinmicos o avanzados pueden utilizar diferentes protocolos basados en diferentes algoritmos o estrategias de encaminamiento dinmicas. Estos algoritmos son los siguientes: I. VECTOR DE DISTANCIA: Tambin denominado de Bellman y Ford en honor a sus creadores, el cual usa una mtrica basada, fundamentalmente, en el nmero de saltos, o nmero de routers que hay que atravesar hasta llegar a un destino. Es decir, se asocia un mismo coste a cada enlace con una mtrica de cuenta de saltos, normalmente, igual a 1, o lo que es lo mismo, a cada salto en la red se le asigna un coste de salto de 1. Quiere decir esto, que si la mtrica total (distancia) es igual a 1 hay que pasar por un router hasta llegar al destino. A su vez, si la mtrica total (distancia) es igual a 2 hay que atravesar dos routers, y as sucesivamente. Por tanto, la mtrica total a un destino (distancia) es la suma de los costes de salto. En este contexto, cada router intercambia con sus vecinos una copia de la tabla completa que disponga puntualmente. El trmino vector de
- 260 -
distancia se deriva del hecho de que el protocolo incluye un vector (lista) de distancias (nmero de saltos u otras mtricas) a todos los destinos conocidos en una organizacin, el cual est asociado con cada destino prefijado en el mensaje de encaminamiento. II. ESTADO DEL ENLACE (LS: Link State) o PRIMER CAMINO MS CORTO (SPF: Shortest-Path First): Tambin denominado de Dijkstra en honor a su creador y a que es, generalmente, el algoritmo (se puede utilizar otros algoritmos de encaminamiento) LS o SPF ms utilizado. Dicho algoritmo usa una mtrica de enlace basada en asociar un coste igual o diferente a cada enlace en funcin de ciertos objetivos de diseo para determinar, posteriormente, la ruta del coste mnimo a un determinado destino. Si los costes son diferentes se obtiene un rbol para cada origen con los caminos de menor coste a todos los destinos. Si los costes son idnticos se obtiene, a su vez, un rbol para cada origen con los caminos ms cortos a todos los destinos. El coste puede usar distintas mtricas como por ejemplo: La distancia o longitud del enlace. El retardo de trnsito. La capacidad del enlace. El retardo en cola de salida para usar el enlace.
En este escenario, si el coste usa una mtrica basada en la capacidad o ancho de banda del enlace, entonces se asignan costes ms bajos a los enlaces de ms alta capacidad (p.ej., un coste 1 a un enlace de 128 Kbps, un coste 2 a un enlace de 64 Kbps, etc.). As, la ruta de coste mnimo proporcionara el mximo caudal de datos. En cada router se ejecuta un mismo protocolo basado en el algoritmo SPF, el cual calcula el camino ms corto en funcin de la informacin de estado del enlace que se obtiene del envo de paquetes LSP (link state packets o de estado del enlace) tambin conocidos como avisos LS. Los protocolos de estado del enlace se fundamentan en que los routers intercambian elementos de informacin llamados estados de enlace que transportan informacin sobre enlaces y routers en el dominio de encaminamiento de una organizacin. Esto significa que los routers que ejecutan este tipo de protocolos no intercambian tablas de encaminamiento como hacen los protocolos basados en el vector de distancia. En su lugar, intercambian una
- 261 -
informacin sobre enlaces y mquinas en el correspondiente dominio. Ya se estudiar que un dominio de encaminamiento es un conjunto de routers vecinos y no vecinos dentro de una organizacin que ejecutan un mismo protocolo de actualizacin y distribucin de la informacin de encaminamiento. Tambin se estudiar, que en el caso de un dominio basado en el estado del enlace, se puede dividir en diferentes reas de routers, segn el nmero de encaminadores que disponga la organizacin. Tambin se analizar que el objetivo de esto ltimo es optimizar la distribucin de la informacin de encaminamiento. En el rea de un dominio basado en el estado del enlace, puede haber routers vecinos y no vecinos, es decir, contiguos o no. Cada router calcula la ruta de coste mnimo a cada destino del rea, situndose a s mismo en la raz. Estas informaciones se intercambian entre todas las reas de tal manera que todo router de la organizacin conozca la topologa completa con las mejores rutas a cada destino de la organizacin. Consecuentemente, una forma de ver los protocolos de estado del enlace es como un rompecabezas. Cada router de la red genera una pieza del puzzle (estado del enlace) que se describe a s misma y que se conecta a piezas del puzzle adyacentes. La pieza del puzzle del router local se distribuye por todas las redes o subredes de la organizacin hasta que todos los routers hayan recibido una copia de dicha pieza. Cuando se completa la distribucin, cada router de la organizacin tiene una copia de cada pieza que almacena en lo que se llama una base de datos de estados del enlace. Posteriormente, cada router construye autnomamente el puzzle completo; el resultado es una copia idntica del puzzle completo en cada router de la organizacin. Seguidamente, se muestra las ventajas que proporciona los protocolos de estado del enlace: Sin nmero de saltos: Por tanto, no hay lmites en el nmero de saltos de una ruta ya que se utilizan mtricas de enlace en lugar de un nmero de saltos. Los costes asignados a cada enlace pueden ser iguales o diferentes: Por ejemplo, se puede factorizar manual o dinmicamente la capacidad o los retardos cuando se calcula la ruta ms corta hacia un destino determinado. Esto conduce a un mejor equilibrado de la carga basado en el coste del enlace en lugar del nmero de saltos. Mejor convergencia: Los cambios de enlace y mquina son inmediatamente introducidos en el dominio mediante actualizaciones del estado del enlace. Todos los routers del dominio actualizarn instantneamente sus tablas de encaminamiento. - 262 -
Soporte para VLSM y CIDR: Los protocolos de estado del enlace intercambian informacin de mscara como parte de los elementos de informacin que son introducidos en el dominio. Como resultado, las redes con mscara de subred de longitud variable pueden ser fcilmente identificadas. Mejor jerarqua: Mientras las redes por vector de distancia son redes planas, los protocolos de estado del enlace proporcionan mecanismos para dividir el dominio de encaminamiento en diferentes niveles o reas.
a2
a1
b1
B
b2
DESTINO
b1
DISTANCIA RUTA
1 B
d1
D
d2
C
c2
c1
b2
a1
a2
c1
c2
d1
3 3
C C
d2
Figura 4.2.- Un escenario basado en el vector de distancia. La Figura 4.2 muestra el ejemplo de una organizacin, con un nico dominio de encaminamiento, que engloba cuatro routers dinmicos, los cuales hacen uso de un mismo protocolo basado en el algoritmo o estrategia del vector de distancia. Asimismo, se muestra la tabla de encaminamiento ptima (con las mejores rutas) del router B. Los enlaces entre estos routers se basan en lneas punto a punto pero podran haber sido redes153. En el ejemplo, los destinos son las direcciones de red IP de ocho redes o subredes de rea local. Como denominador en comn de este tipo de protocolos: Los destinos pueden ser direcciones de red o subred o direcciones particulares de mquinas de usuario. La distancia es 1 cuando slo aparece un router (el considerado) hasta el destino.
Generalmente una red de difusin de rea local, ya que se asume que se est en el mbito de una determinada organizacin.
153
- 263 -
La ruta indica el siguiente router vecino hasta llegar un destino en particular. Inicialmente cada router slo conoce la distancia (nmero de routers) a los destinos a los cuales est directamente conectado. Seguidamente, una copia completa de esta informacin se intercambia por difusin (p.ej., en el caso de redes de rea local interconectando routers) o por inundacin (lneas serie o punto a punto) entre todos los routers vecinos o contiguos. Si es por inundacin, que es un tipo especial de difusin, una copia de cada mensaje se enva por todos los interfaces de salida salvo por el de entrada. Independientemente de cmo sea el envo de la informacin, cada router vecino calcula, tambin, la mejor ruta para cada destino posible, notificndolo de nuevo a sus vecinos. En este contexto, un router actualiza su tabla de encaminamiento cuando aparece: Un destino nuevo. Una distancia ms corta (buenas noticias) a un destino a travs de otro router vecino ya insertado o no en la tabla para dicho destino. Una distancia ms larga (malas noticias) a un destino a travs de un router vecino ya insertado en la tabla para dicho destino. ste es el caso de un router R2 que para acceder a un destino dado siempre debe pasar por R1. Por tanto, R2 ha aprendido dicho destino mediante un mensaje de R1. Consecuentemente, si un router (R2) aprende un destino a travs de otro router vecino (R1) y ste aumenta el nmero de saltos, aqul (R2) tambin aumenta en una unidad el nmero de saltos; siempre y cuando no aparezca otra ruta ms corta al mismo destino a travs de otro router vecino diferente. El problema, asociado a un protocolo basado en este algoritmo de encaminamiento, es que sus mensajes son generalmente grandes (especialmente si hay muchos destinos) y se difunden lentamente. Asimismo, todos los routers deben participar con lo cual si la organizacin dispone de un nmero elevado de routers, se puede dar una gran sobrecarga en la red. Esto se traduce en que el correspondiente protocolo no se adapta rpidamente a los cambios que pueda sufrir la red corporativa de la organizacin durante su funcionamiento puntual. Otro problema ya comentado es que cualquier protocolo basado en el vector de distancia tiene un lmite en el nmero de saltos o lo que es lo mismo en el nmero de routers que se pueden atravesar en la organizacin. Consecuentemente, este tipo de protocolos estn pensados para organizaciones pequeas con un nmero reducido de dispositivos de encaminamiento.
- 264 -
1 1 A 1
a1
b1
B 4 3 C 1
o1
2
DESTINO
A
COSTE
4 5 1 2 1 3 4 3
RUTA
C B A B B C B B
E 1 D 1
o2
o1 o2 a1 b1 B C D E
Figura 4.3.- Un escenario basado en el estado del enlace. La Figura 4.3 muestra el ejemplo de una organizacin, con un nico dominio de encaminamiento y con una nica rea que engloba cinco routers dinmicos, los cuales hacen uso de un mismo protocolo basado en el algoritmo del estado del enlace. Asimismo, se muestra la tabla de encaminamiento ptima (con las mejores rutas) del router A. Igual que en el ejemplo anterior, los enlaces entre estos routers se basan en lneas punto a punto pero podran haber sido redes154. En el ejemplo, los destinos son las direcciones de red IP de dos redes o subredes de rea local (a1 y b1) y dos mquinas o sistemas finales de usuario (o1 y o2). Como denominador en comn de este tipo de protocolos se destaca lo siguiente: Los destinos pueden ser direcciones de red o subred o direcciones particulares de mquinas de usuario. Asimismo, se consideran como destinos al resto de los routers de la organizacin ya que en este tipo de protocolos se debe tener un conocimiento completo de toda la topologa de la organizacin. El coste puede usar diferentes mtricas (capacidad, retardo de trnsito del enlace, etc.) y es el administrador de la organizacin quien decide su seleccin y asignacin a cada enlace. Asimismo, el coste asignado a cada enlace en funcin de la mtrica seleccionada puede ser igual o diferente. La ruta indica el siguiente router vecino hasta llegar un destino en particular.
Generalmente una red de difusin de rea local, ya que se asume que se est en el mbito de una determinada organizacin.
154
- 265 -
Se obtiene un rbol diferente para cada origen155 con los caminos156 con el menor coste a cada destino. Todo router de la organizacin es la raz de su propio rbol. Por tanto, en el ejemplo de la Figura 4.3 habr un rbol diferente para los routers A, B, C, D y E. El procedimiento operativo de un protocolo basado en el estado del enlace consiste, fundamentalmente, en que para calcular el coste a un destino de un router no vecino hay que calcular todos los costes pasando por todos sus routers vecinos. Inicialmente, cada router slo conoce el coste a los destinos a los cuales est directamente conectado. Seguidamente, una copia de esta informacin contenida en la respectiva tabla de encaminamiento, se intercambia por difusin157 o por inundacin158 o por otra tcnica159 entre todos los routers vecinos o contiguos. As para calcular, en el ejemplo, el coste a o2, el router A ha tenido que calcular todos los costes pasando por sus routers vecinos B, C y E; seleccionando finalmente la ruta de coste mnimo a dicho destino o2. Para ello, A ha tenido que recibir mensajes de B, C y E con el coste de la ruta a o2. Previamente, D ha informado a C y E. A su vez, C ha hecho lo propio con A y E lo mismo con B y A. Como se ha comentado con anterioridad, una de las ventajas que proporciona un protocolo basado en la estrategia del estado del enlace es que no hay lmite en el nmero de saltos de una ruta. Es decir, el protocolo trabaja con mtricas de enlaces iguales o diferentes en lugar de hacerlo con una misma mtrica basada en el nmero de saltos. Por consiguiente, este tipo de protocolos estn especialmente pensados para organizaciones que manejen un nmero elevado de routers. Asimismo, slo se envan actualizaciones, salvo en el momento inicial en donde cada router transmite a sus vecinos todo lo que conoce160. Consecuentemente, los mensajes suelen ser cortos, con lo cual estos protocolos se adaptan a los cambios puntuales que pueda sufrir la red corporativa de la organizacin en cuanto a su funcionamiento.
Cada origen es un router conectado o no directamente a un sistema final debido a que todo router posee un mapa topolgico completo de la organizacin.
156
155
Cada camino o ruta tiene uno o ms enlaces. Por ejemplo, en el caso de redes de rea local interconectando routers. Por ejemplo, lneas serie o punto a punto interconectando routers. Por ejemplo, en el caso de redes X.25, Frame Relay, ATM, etc., interconectando routers. Los destinos a los que est conectado directamente.
157
158
159
160
- 266 -
4.1.1 Sistemas autnomos

El modelo de encaminamiento de Internet divide a esta inmensa red de redes en unidades conocidas como sistemas autnomos con el objetivo de proporcionar una visin ms estructurada mediante redes ms pequeas y gestionables. En este escenario, un sistema autnomo (SA o AS: Autonomous System) tpico son los routers de una organizacin o de un proveedor (ISP). Para el mundo exterior161, el SA se ve como una nica entidad que se comunica con otros SA. As, para que el conjunto de los routers de una organizacin se considere como un SA, se debe cumplir lo siguiente: La organizacin debe disponer de un conjunto de routers avanzados o dinmicos que utilicen, en un nico dominio, un mismo protocolo de router interno o IGP (Interior Gateway Protocol) para la distribucin y actualizacin de la informacin de encaminamiento. En este contexto, se define (segn se ha comentado con anterioridad) un dominio de encaminamiento, o simplemente dominio, como un conjunto de routers que ejecutan un mismo IGP. Un SA representa uno o ms dominios bajo una nica administracin que tiene una poltica de encaminamiento unificada con otros SA. Generalmente, un SA dispone de un nico dominio de encaminamiento. En este contexto, un SA es un conjunto de routers controlados por una nica autoridad administrativa y que utilizan, en un dominio, un mismo protocolo interno entre routers o IGP. Para lograr que las redes-subredes ocultas dentro de una organizacin sean accesibles a otras organizaciones, se deben difundir las direcciones de dichas redes-subredes mediante un router externo (generalmente, el que ocupa la posicin ms externa en la organizacin) y un protocolo de router externo o EGP (Exterior Gateway Protocol). De esta forma, se van conectando todos los SA en Internet y, adems, se controla la expansin de las tablas de encaminamiento. Las redes-subredes de la organizacin se deben controlar bajo una nica administracin tcnica que define toda la poltica de encaminamiento interno y externo. El administrador de la organizacin toma sus propias decisiones sobre los tipos de routers que usar dentro de su red y sobre el protocolo o protocolos de encaminamiento que emplearn. Dichas redes pueden implementar su propio conjunto de reglas y polticas que distinguirn de forma nica sus redes de otras.
En la actualidad, no interesa un SA que no se comunique con otro SA y funcione aisladamente como un SA privado.
161
- 267 -
Cada SA tiene un nmero identificador de 16 bits para reconocer a todo un grupo de redes-subredes. Este nmero se usa como un ndice para la informacin que se utiliza para definir su poltica de encaminamiento. Un nmero de SA se asigna, bsicamente, de tres formas: 1. Mediante un registro delegado de Internet (p.ej., RIPE NCC, http://www.rip.net, en el caso de los pases europeos) para SA pblicos. El resultado de la solicitud es un nmero nico y pblico de SA. 2. A travs de un proveedor de servicios (ISP) en el caso de los SA privados. As, los routers de una organizacin forman un sistema autnomo privado cuando intercambian informacin de encaminamiento entre ellos, pero no con otros. Obviamente, se asume que el ISP tiene soporte para el uso de SA privados. Cuando un SA se conecta al exterior a travs de un ISP, se le denomina SA de conexin nica. Es decir, alcanza las redes exteriores a su dominio a travs de un nico punto de salida mediante una poltica de encaminamiento simple (RFC-2270). Dado que slo hay una salida, todo el trfico puede ir por omisin a su ISP. Cuando se usa esta configuracin162, el ISP puede utilizar diferentes mtodos para aprender todos los destinos de su cliente y publicar sus rutas a otras organizaciones. Estos mtodos son los siguientes: Registrar estticamente las subredes del cliente en su tabla de encaminamiento. Posteriormente, el ISP publicar dichas entradas en Internet a travs de un protocolo de router externo o EGP. Utilizar un IGP entre el cliente y el ISP. Intercambio de destinos propios del cliente y su ISP. Utilizar un EGP entre el cliente y el ISP. Ejecutar un EGP con el cliente tiene muchas ventajas como controlar la propagacin y el filtrado de rutas.
De igual manera que existen unos rangos de direcciones IP reservados que pueden ser compartidos por las distintas organizaciones conectadas a Internet; existe un rango de nmeros de SA reservados para SA
- 268 -
privados. El ISP ser quien proporcione al cliente este nmero de SA de uso privado en el intervalo del 64512 al 65535 (reservados por IANA/ICANN). Este nmero que identifica a un SA privado no tiene ninguna relevancia para el resto de Internet ya que los routers de dicho SA no intercambian informacin con ningn otro. El documento RFC1930 ofrece un conjunto de normativas para la creacin, seleccin y registro de nmeros de SA. Actualmente, muchas de las organizaciones conectadas a Internet siguen una poltica de encaminamiento simple. Por consiguiente, para el encaminamiento es suficiente un mismo nmero de SA para identificar a los routers del ISP y sus clientes. 3. A travs de ms de un ISP. En este caso se asume que una organizacin puede contar con mltiples ISP y permite trfico de trnsito o no a travs de dicha organizacin. Un SA sin trnsito slo publicar sus propias rutas y no propagar rutas que haya aprendido de otros SA. Esto asegura que el trfico hacia cualquier destino que no pertenezca al SA no ser dirigido hacia el SA. Un SA de trnsito publicar a un SA las rutas que haya aprendido de otro SA. De esta forma, el SA de trnsito se abrir permitiendo que pase trfico por sus redes-subredes hacia otros SA. Tanto si el SA es de trnsito como si no, debera obtener un nmero propio de SA.
4.1.2 Protocolos especficos en el ambiente Internet

RIP, IGRP, EIGRP (Vector Distancia)
IGP (Interior Gateway Protocol)

EGP (Exterior Gateway Protocol)
SISTEMA AUTNOMO (SA1)
R2 ral 1 R1 ral 2 R4
OSPF, IS-IS (Estado del Enlace)
BGP (Vector Distancia)

R6 ral 5 R5 ral 6 R8
IGP (RIP)
R3 ral 3 ral 4
EGP
ral 7
IGP (OSPF)
R7 ral 8
Gateways/Routers Exteriores
Figura 4.4.- Un ejemplo de escenario con protocolos de encaminamiento. Con el objetivo de poder encaminar datagramas IP en un mismo dominio desde una mquina de una red de un SA a otra mquina remota en el mismo SA, los routers usan un mismo protocolo de router interno o IGP que posteriormente el protocolo IP
- 269 -
utilizar para realizar sus funciones de encaminamiento. Asimismo, si se desean encaminar datagramas IP desde una mquina de una red de un SA a otra mquina de otro SA, los SA se conectan entre s mediante routers externos que usan un mismo protocolo de router externo o EGP que, a su vez y posteriormente, el protocolo IP utilizar para realizar, asimismo, sus funciones de encaminamiento. Tanto IGP como EGP son trminos genricos que engloban a diferentes protocolos ya sean internos (p.ej., RIP basado en el vector distancia y OSPF basado en el estado del enlace) o externos (p.ej., BGP basado en el vector distancia) respectivamente. Como ya se ha sealado, mediante el concepto de SA y, por tanto, dividendo el mundo en administraciones se consigue, a su vez, dividir una gran red163 en redes ms pequeas y gestionables. Dichas redes, representadas como SA, pueden implementar su propio conjunto de reglas y polticas que distinguirn sus propias redes y servicios de otras redes. Consecuentemente, cada SA puede ejecutar su propio conjunto de protocolos de IGP independientemente de los IGP de otros SA. En este escenario, todo router externo dispone de al menos dos tablas de encaminamiento. En el caso ms simple descrito en la anterior Figura 4.4, cada SA dispone de un nico dominio de encaminamiento, y un nico IGP por dominio. Asimismo, en el ejemplo citado, cada SA se comunica slo con otro SA. En este escenario, las tablas mencionadas son las siguientes: Una tabla de encaminamiento interna164: Mantenida por el correspondiente protocolo de router interno o IGP para encaminar internamente por un dominio especfico del propio SA. Obviamente, todos los routers internos pertenecientes a un dominio de encaminamiento de un SA slo disponen de una nica tabla de encaminamiento interna actualizada por el IGP de dicho dominio. En este contexto, el router externo puede tener tener tantas tablas internas como protocolos IGP existan o lo que es lo mismo como dominios de encaminamiento posea el SA. Una tabla de encaminamiento externa165: Mantenida por el correspondiente protocolo externo para encaminar hacia otro SA. Si un SA est conectado a un nmero n de sistemas SA, un router externo dispondr de n tablas externas, tantas como sistemas SA a los cuales est conectado.
163
Internet podra haber sido una gran red OSPF o IS-IS. En el caso ms simple, es decir, un SA con un dominio. En el caso ms simple, es decir, un SA conectado nicamente a otro SA.
164
165
- 270 -
En la anterior Figura 4.4, aparecen cuatro redes de rea local y cuatro routers por sistema autnomo. En este escenario, si una mquina en ral 1 (SA1), enva, por ejemplo, un mensaje a una direccin IP en ral 8 (SA2), es decir, fuera del sistema autnomo; el datagrama ir por omisin (tabla de RIP) a R2, y desde R2, por omisin (tabla RIP), a R4. Como R4 dispone de informacin adicional (tabla externa de BGP), lo sabr encaminar por omisin (tabla BGP) al router externo R5 para que ste en funcin de su tabla interna OSPF, lo encamine interna e indirectamente a R7. Finalmente, R7 lo enviar directamente por ral8 (va tabla OSPF) a la mquina correspondiente.
Protocolos internos IGP (Interior Gateway Protocol)
Vector de Distancia:
RIP (Routing Information Protocol, RFC-1058 para la versin 1 y RFC-1723 para la versin 2): ISOC/IAB IGRP (Internet Gateway Routing Protocol, www.cisco.com): Cisco EIGRP (Enhanced IGRP, www.cisco.com): Cisco
Estado del Enlace:
OSPF (Open Shortest Path First Protocol, RFC-1583): ISOC/IAB IS-IS (Intermediate System to Intermediate System, ISO DP 10589, RFC-1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments): ISO
Protocolos externos EGP (Exterior Gateway Protocol)

Vector Distancia
BGP (Border Gateway Protocol, RFC-1771): ISOC/IAB
Figura 4.5.- Los protocolos ms relevantes IGP y EGP. La Figura 4.5 muestra los protocolos ms significativos para la distribucin y actualizacin de la informacin de encaminamiento. Segn se coment, existen dos tipos de protocolos: De router interno o IGP (Interior Gateway Protocol): Protocolo interno de encaminamiento166 que se utiliza, por tanto, internamente para intercambiar informacin entre los routers de un dominio de encaminamiento de un SA. De router externo o EGP (Exterior Gateway Protocol): Protocolo externo de encaminamiento167 usado, por tanto, externamente para intercambiar informacin de encaminamiento entre los SA.
En realidad, no encaminan sino que ayudan a actualizar la tabla de encaminamiento que utiliza el protocolo IP que es el que realiza el pertinente encaminamiento.
167
166
Tampoco un EGP encamina, se limita a actualizar la tabla de encaminamiento que utiliza el protocolo
IP.
- 271 -
Es importante resaltar el diseo que se hizo en su da, separando la forma en que se actualizan las tablas de encaminamiento y el protocolo IPv4 que hace uso de esa informacin para encaminar datagramas IP. Mientras los protocolos de encaminamiento dinmico se han hecho ms sofisticados y eficientes; el protocolo IPv4 ha permanecido inalterable con respecto a las continuas mejoras que han ido presentando dichos protocolos de actualizacin y distribucin. Con respecto a los protocolos IGP, se han ido desarrollando con el tiempo distintos IGP y versiones mejoradas para los mismos por grupos de normalizacin de Iure (ISO)/Facto (ISOC/IAB) y fabricantes de routers. En este contexto, el administrador de un SA tiene una completa libertad a la hora de seleccionar uno u otro en funcin de sus requisitos internos, es decir, del escenario de su organizacin; fundamentalmente, en relacin con la topologa, infraestructura de conexin y nmero de routers que intervienen en dicho SA. En este escenario, es importante, como ya se ha sealado, tener en cuenta que un SA puede disponer de uno (lo ms tpico) o ms dominios de encaminamiento. As, un SA representa uno o ms dominios bajo una nica administracin. Consecuentemente, un SA puede disponer de ms de un IGP, uno por dominio. Seguidamente, se ofrece una pequea descripcin de los protocolos IGP ms relevantes. Estos protocolos admiten dos estrategias de encaminamiento dinmico de datagramas IP: Vector de Distancia: RIP (Routing Information Protocol): Normalizado y aprobado para un SA en Internet por ISOC/IAB. Es el IGP ms popular, especialmente, en un SA con un nmero reducido de routers. IGRP (Internet Gateway Routing Protocol): Protocolo propietario del fabricante de routers Cisco y que representa una versin mejorada del protocolo RIP. El administrado de un SA con routers de Cisco, suele optar por este protocolo si va incorporado en dichos routers. Este protocolo utiliza sofisticadas medidas de coste o mtricas de cuenta (el coste es el mismo, generalmente igual a 1) a travs de un mtrica compuesta que maneja diversos factores, incluyendo el ancho de banda y el retardo. En el caso de RIP, ste se configura generalmente con un coste de 1 para cada salto aunque dicho salto sea una conexin telefnica lenta o un enlace de alta velocidad por fibra ptica. EIGRP (Enhanced IGRP): Es el IGRP mejorado de Cisco. El administrado de un SA con routers de Cisco, suele optar por este protocolo si va incorporado en dichos routers.
- 272 -
Estado del Enlace: OSPF (Open Shortest Path First Protocol): Normalizado y aprobado para un SA en Internet por ISOC/IAB. Se puede utilizar en cualquier SA, pero est especialmente diseado para un SA con un nmero grande de routers. IS-IS (Intermediate System to Intermediate System): Protocolo normalizado y aprobado por el organismo ISO para su propio protocolo de encaminamiento no orientado a conexin168. Por tanto, se puede utilizar para distribuir y actualizar la informacin de encaminamiento en una red OSI y en una red TCP/IP al disponer de soporte de direccionamiento OSI e IP. Con respecto a los protocolos EGP, es importante indicar que al contrario de los protocolos IGP, los cuales se eligen libremente; en los protocolos EGP, debe haber un estndar cuando se atraviesan los SA de las organizaciones y los proveedores (ISP). Actualmente, el estndar en Internet es el protocolo BGP el cual se basa en la estrategia del vector de distancia. Se espera que en un futuro (con IPv6) el protocolo de encaminamiento interdominios (IDRP: Inter-Domain Routing Protocol) de ISO para su arquitectura OSI, suplante a BGP. IDRP es una versin mejorada de BGP con soporte de direccionamiento para IPv4 e IPv6. Vector de Distancia: BGP (Border Gateway Protocol): Normalizado y aprobado para un SA en Internet por ISOC/IAB. Es el EGP utilizado, actualmente, para un encaminamiento dinmico entre los SA de Internet.
CLNP (Connectionless Network Protocol) es el equivalente al protocolo IP en TCP/IP pero en la arquitectura OSI.
168
- 273 -
4.1.3 Protocolo RIP (Routing Information Control)

Protocolo RIP (Routing Information Control) Adaptacin, por la Universidad de Berkeley para el Unix BSD, del XNS RIP de Xerox (despus se convirti en el RFC 1058) Vector Distancia
Mtrica: Nmero de saltos (mnimo 1, mximo 15) N de saltos = 1 en conexiones directas 16 saltos (red inalcanzable)
UDP y puerto 520 Routers activos y pasivos Difusin (Broadcast) de tablas cada 30 segundos Rutas borradas si en 180 segundos no hay noticias Problemas: Convergencia lenta/Cuenta al infinito
Figura 4.6.- Caractersticas ms relevantes del protocolo RIP. La Figura 4.6 muestra las caractersticas fundamentales de un protocolo de router interno (IGP), denominado RIP (RFC-1058), usado para distribuir y actualizar la informacin de encaminamiento entre routers avanzados o dinmicos en un mismo dominio de encaminamiento de un SA mediante el algoritmo o estrategia de encaminamiento del vector distancia. El protocolo RIP de la arquitectura TCP/IP deriva del RIP original (XNS RIP) de la arquitectura XNS de Xerox desarrollado por su centro de investigacin en Palo Alto (California). La Universidad de Berkeley lo adapt e incluy en la arquitectura TCP/IP dentro del Unix BSD. Este protocolo fue adoptado y adaptado antes de que fuera un RFC (una excepcin a la regla), es decir, RIP se utiliz bastante durante algunos aos antes de crearse el documento RFC-1058. Una de las caractersticas de este protocolo es que est ubicado en el nivel de aplicacin por encima de UDP y en donde las solicitudes y respuestas se identifican a travs del mismo nmero de puerto (520). Las actualizaciones regulares de RIP se envan va UDP desde el puerto origen 520 al puerto destino 520. Sin embargo, se puede enviar las solicitudes de actualizacin desde cualquier otro puerto y las respuestas se deberan enviar de vuelta al puerto desde donde se solicitaron. Al estar montado sobre UDP, RIP dispone en el nivel de aplicacin de los correspondientes mecanismos fiables que UDP no proporciona. RIP calcula las rutas usando un algoritmo de encaminamiento del vector distancia. A cada salto en la red se le asigna un coste con una mtrica de cuenta de saltos, normalmente, de 1. La mtrica total a un destino es la suma de los costes de salto. Una entidad RIP elige el siguiente salto para que los datagramas sigan un camino de coste mnimo Un destino se considera inalcanzable cuando el nmero mximo de saltos es de 16 que significa no puedo llegar hasta all, por tanto, el nmero mximo de saltos o cuenta - 274 -
mxima de saltos es igual a 15 (para una organizacin con un nmero reducido de routers). En este contexto el valor 16 se reserva para representar un infinito pequeo. Asimismo, RIP distingue entre routers activos (envan y reciben informacin de encaminamiento) y routers pasivos (habitualmente sistemas finales de usuario que slo reciben informacin de encaminamiento). Los routers vecinos intercambian sus tablas de encaminamiento cada 30 segundos por omisin. Para tratar los cambios en la topologa como es la cada de un enlace, un router espera recibir, en el peor caso, al menos un mensaje de actualizacin de cada vecino en 180 segundos. La razn para elegir un valor ms grande que 30 segundos es que RIP utiliza UDP, que es un protocolo no fiable. De esta forma, se puede perder algunos mensajes y nunca alcanzar a sus vecinos. Si un router A ha estado enviando trfico a un destino a travs de un router B, pero no ha recibido ninguna actualizacin durante tres minutos (180 segundos); el router A supone que el router B ha quedado fuera de servicio y marca todas sus rutas a travs de B como inalcanzables, dndoles una mtrica de 16. Si no se descubre una nueva ruta a un destino marcado como inalcanzable en dos minutos, su entrada se elimina. A esta operacin se la denomina como recogida de basura. Si por el contrario, dentro de los dos minutos, recibe de otro vecino un coste mnimo vlido a un destino, el router reemplaza el infinito con el coste mnimo nuevo. Siempre que llegue una actualizacin de un vecino, se comprueba la tabla y se ve si se puede aadir o mejorar alguna entrada. Lo ptimo sera que las rutas fuesen cada vez mejores, pero a veces un enlace o un router pueden quedar fuera de servicio y el trfico ha de seguir un camino ms largo. Estas malas noticias se descubren de dos maneras: El router A ha estado enviando trfico a un destino a travs de un router B y B enva una actualizacin donde se anuncia que el nmero de saltos a dicho destino ha aumentado, o quizs que no se puede llegar al destino en cuestin. Por tanto, el router A actualiza su correspondiente entrada. Como se ha comentado con anterioridad, si un router A ha estado enviando trfico a un destino a travs de un router B, pero no ha recibido ninguna actualizacin durante tres minutos; el router A supone que el router B ha quedado fuera de servicio y marca todas sus rutas a travs de B como inalcanzables, dndoles una mtrica de 16. Si no se descubre una nueva ruta a un destino inalcanzable en dos minutos, su entrada se elimina. Mientras tanto, las actualizaciones del router A indican al resto de los sistemas que el router A no puede llegar al destino correspondiente. Para finalizar unos problemas asociados a los protocolos basados en el algoritmo del vector distancia son los de la convergencia lenta y cuenta al infinito que provocan - 275 -
inconsistencias en la tabla de encaminamiento. Dichas inconsistencias se producen debido a que los mensajes de actualizacin son generalmente grandes con la correspondiente carga de proceso y, adems, se difunden lentamente a travs de una red. Asimismo, estos protocolos provocan los tpicos bucles o viajes en crculo (problema de la cuenta al infinito) que se resuelven, aunque no se eliminan, mediante la seleccin de un infinito pequeo (16). Resumiendo los puntos fuertes de RIP son su simplicidad y disponibilidad (RIP se encuentra en cualquier Unix). Muchas veces no existen razones de peso para utilizar otro protocolo ms funcional o complicado, especialmente en una organizacin pequea (con un nmero reducido de routers) o con una topologa simple. Sin embargo para redes grandes y complejas, RIP presenta serias desventajas: La mtrica mxima para cualquier camino es de 15. RIP se suele configurar con un coste de 1 para cada salto aunque, como ya se ha indicado, ese salto sea una conexin telefnica lenta o un enlace de alta velocidad por fibra ptica. Tras un cambio, por ejemplo, si se pierde algn tipo de conectividad o corte en la red, RIP suele ser lento para restablecer las rutas ptimas y hay cierta tendencia a que el trfico se transmita en crculos. De hecho, tras un corte en algn enlace, el trfico de datagramas puede vagar en crculos durante algn tiempo. Esto ltimo provoca que, despus de un cambio, se puede tardar algn tiempo hasta que todos los routers estn actualizados con la informacin correcta. RIP no puede responder a los cambios en retrasos o carga en los enlaces. Consecuentemente, no puede distribuir el trfico para balancear la carga. Actualmente existe un RFC-2080 (proposed standard) que define un RIPng para IPv6. RIPng se basa, igualmente, en el algoritmo del vector de distancia y es similar al RIPv2 para IPv4.
- 276 -
R1
R2
R3
Red 1
R1
Mximo: 15 saltos
R2
R3
Red 1
Bucle al fallar la conexin de R1 con Red 1
Figura 4.7.- Resolucin de bucles: Seleccin de un infinito pequeo. La Figura 4.7 muestra un ejemplo de cmo el protocolo RIP resuelve un bucle. En un principio, el router R1 tiene una conexin directa con Red 1 y, por tanto, en su tabla tiene una entrada para ese destino con una distancia igual a 1. R2 (vecino de R1) al recibir la informacin anterior de R1, pondr en su tabla una distancia igual a 2 (si R1 necesita un salto, R2 necesita un salto ms). A su vez, R3 (vecino de R2) al recibir de R2 la distancia de 2 a Red 1 pondr en su tabla la distancia de 3 (si R2 necesita dos saltos, R3 necesita un salto ms). Suponiendo que en un momento dado la lnea fsica con Red 1 deja de estar operativa, R1 actualiza la entrada correspondiente de Red 1 en su tabla de encaminamiento, registrando para dicho destino una distancia de 16 (destino inalcanzable). Pero si antes de mandar a su vecino R2 esta informacin, recibe de ste que para llegar a Red 1 hay que realizar dos saltos (la informacin que R2 tiene en su tabla de encaminamiento y que aprendi de R1 en su momento), R1 actualiza su tabla y pone que para llegar a Red 1 necesita un salto ms, es decir tres saltos y manda esta informacin a R2. A su vez, R2 vuelve a actualizar su tabla y registra que para llegar a Red 1 necesita cuatro saltos y manda esta informacin a R1 que acta en consecuencia y aade un salto ms a la distancia. El proceso continuara hasta el infinito si no se termina en un punto y a ste se llega cuando se alcanza el valor 16. Como se puede ver, existe una ventaja de tener una cuenta mxima de saltos pequea. Un destino inalcanzable a veces origina un bucle de encaminamiento temporal. Las mtricas de los mensajes de actualizacin en el bucle aumentan rpidamente hasta 16, y en ese momento se rompe el bucle. Un lmite mayor ralentizara recuperarse del hipottico bucle.
- 277 -
Horizonte Dividido (Split Horizon) Retorno Envenenado (Poison Reverse) Actualizaciones Engatilladas (Triggered Updates)
Figura 4.8.- Mecanismos de resolucin de bucles. Mediante un infinito pequeo (16) se solucionan los viajes en crculo pero no se eliminan. Para evitar el problema de los bucles o de la cuenta al infinito se han propuesto varias modificaciones al algoritmo, stas son las siguientes: Horizonte Dividido (Split Horizon). Los routers no comunican a sus vecinos las rutas aprendidas de ellos. Por tanto, no se transmite ninguna informacin a un vecino si ste es el router siguiente en el camino ms corto. Por ejemplo, si el router A considera que la mejor ruta al destino C es la que pasa por B, entonces el router A no enviar su nmero mnimo de saltos al router B. En el ejemplo de la Figura 4.7 que se vio anteriormente, cuando R2 recibe de R1 que para llegar a Red 1 necesita emplear 1 salto, R2 no comunica nada a R1 ya que el destino Red 1 lo aprendi de R1. Por tanto, R2 no transmite a R1 que emplea 2 saltos (uno ms que R1 por ser contiguo) para llegar a Red 1. Horizonte dividido con Retorno Envenenado (Poison Reverse). En este caso, los routers s comunican a sus vecinos las rutas aprendidas de ellos pero con la cuenta mxima de saltos (16) para su eliminacin inmediata y, as, evitar malentendidos (no intentes llegar all a travs de m). Por tanto, se permite a un router el envo del nmero mnimo de saltos a todos sus vecinos, pero este valor se hace infinito (16) si uno de los vecinos es el router siguiente en la ruta ms corta a dicho destino. En el ejemplo anterior, cuando R2 recibe de R1 que para llegar a Red 1 necesita emplear 1 salto, R2 transmite que para llegar a Red 1 necesita, a su vez, 16. El retorno envenenado es una mejora sobre el horizonte dividido y aporta una mayor seguridad que empleando, nicamente, el horizonte dividido ya que permite romper, inmediatamente, rutas de bucle169 errneas.
169
Se resalta que el mecanismo del horizonte dividido con retorno envenenado elimina bucles en donde estn implicados dos routers. Pero, puede ocurrir que hayan bucles implicando a tres o ms routers. Por
- 278 -
Actualizaciones Engatilladas (Triggered Updates). Mediante este mecanismo se acelera el proceso de descubrir los cambios, es decir, se acelera el tiempo de convergencia en las tablas de encaminamiento y, por tanto, se reduce el periodo de tiempo durante el cual estn presentes en la red los correspondientes bucles errneos. En este contexto, la convergencia se acelera solicitando que un router implemente una actualizacin engatillada o por disparo. Siempre que un router cambie su mtrica en una ruta, enva inmediatamente actualizaciones anunciando el cambio. Por consiguiente, cualquier modificacin en la tabla se comunica lo ms rpido posible a sus vecinos sin esperar los tpicos 30 segundos. Es importante tener en cuenta, que en este escenario, una nueva actualizacin desencadenar otras que, a su vez, desencadenarn otras ms. Sin embargo, esta cascada de mensajes evitar que haya un montn de trfico de los usuarios vagando por rutas equivocadas. Asimismo, se podra elegir retrasar aleatoriamente los mensajes de actualizacin engatilladas para evitar cargar la red excesivamente. Como habr una tendencia a muchas actualizaciones simultneas, cada router espera un plazo de tiempo al azar antes de enviarlas. Adems, se puede reducir el ancho de banda usado para las actualizaciones enviando slo aquellas entradas que realmente han cambiado, en lugar de toda la tabla. Tambin, en este contexto, se puede recibir mensajes obsoletos, es decir, un router ha descubierto que un destino es inalcanzable pero puede recibir un mensaje que indique un camino hacia ese destino a travs de un router que actualmente est inactivo. Si se acepta esta actualizacin, no slo se sustituye informacin incorrecta, sino que se desencadenarn actualizaciones que expandirn informacin errnea. Consecuentemente, algunos fabricantes implementan una regla de mantenimiento que fija un perodo de tiempo durante el cual se ignoran las actualizaciones de un destino que acaba de marcarse como inalcanzable. Existen docenas de versiones de RIP para todo tipo de equipo. Por tanto, no se puede esperar que haya un horizonte dividido, un retorno envenenado o actualizaciones engatilladas en todos los routers existentes que trabajen con RIP. As, hay versiones de RIP que utilizan un horizonte dividido con retorno envenenado para eliminar bucles y, asimismo, hacer que la convergencia sea ms rpida. En general un horizonte dividido con retorno envenenado es ms seguro que un simple horizonte dividido. Si dos routers tienen rutas que atraviesan a ambos, el aviso de rutas aprendidas mediante una mtrica
ejemplo, A puede creer que tiene un camino a un determinado destino a travs de B, B a travs de C y C a travs de A. La eliminacin de este bucle slo puede realizarse por el vencimiento del temporizador (timeout) que se activa cuando comienza la cuenta al infinito.
- 279 -
de 16 romper el bucle inmediatamente. Si las rutas aprendidas, simplemente, no se avisan; entonces, las rutas errneas tienen que eliminarse a travs de un temporizador. En este contexto, las tcnicas de horizonte dividido con retorno envenenado previenen de cualquier bucle de encaminamiento que implique slo a dos routers.
Red1 Dir 1
R1
Red2 Dir 1
Red1
R2
Red2
R3
Red1 Dir 1 Red3 Dir 1 Red2 R1 2
Red3
R4
Red2 Dir 1 Red3 Dir 1 Red3 Dir 1 Red4 Dir 1 Red1 R1 2
Red4
Figura 4.9.- Un ejemplo (I) conceptual del funcionamiento del protocolo RIP. La Figura 4.9 muestra el ejemplo de un SA con un dominio de encaminamiento y cuatro routers conectados a travs de sendas redes de rea local. Inicialmente, cada router slo conoce la distancia (nmero de routers) a los destinos a los cuales est directamente conectado. Seguidamente, una copia completa de estas tablas se intercambia por difusin entre todos los routers vecinos o contiguos. Como ya se seal, un router actualiza su tabla de encaminamiento, fundamentalmente, cuando aparece un destino nuevo o una distancia ms corta a un destino. En las tablas se visualizan las informaciones ms significativas (Destino, Ruta, Distancia). Al empezar, R1 conoce slo los destinos (Red1 y Red2) a los que est conectado directamente (a travs de l mismo) mediante 1 salto o pasando por un solo router (distancia = 1) y transmite dicha informacin a sus vecinos R2 y R3. De esta ltima informacin, R2 descubre un destino nuevo (Red2) al cual se accede por R1 a travs de dos saltos. A su vez, R3 descubre un destino nuevo (Red1) al cual se accede por R1 a travs de dos saltos.
- 280 -
Red1 Dir 1
R1
Red2 Dir 1 Red3 R2 2
Red1
R2
Red2
R3
Red3
R4
Red2 Dir 1 Red3 Dir 1 Red3 Dir 1 Red4 Dir 1 Red1 R2 2 Red2 R2 3 Red1 R1 2
Red4
Figura 4.10.- Un ejemplo (II) conceptual del funcionamiento del protocolo RIP. Seguidamente, y suponiendo que es R2 quien enva su informacin de encaminamiento a sus vecinos R1 y R4 (ver Figura 4.10). De esta ltima informacin, R1 descubre un destino nuevo (Red3) al cual se accede por R2 a travs de dos saltos. A su vez, R4 descubre dos destinos nuevos (Red1 y Red2) a los cuales se accede por R2 a travs de dos y tres saltos respectivamente. Posteriormente, R3 enva su informacin de encaminamiento a sus vecinos R1 y R4 (ver Figura 4.11). De esta ltima informacin, R4 actualiza su tabla para la entrada de Red2 al encontrar un mejor camino por R3. Seguidamente, R4 enva su informacin de encaminamiento a sus vecinos R2 y R3 (ver Figura 4.12). De esta ltima informacin, R2 descubre un destino nuevo (Red4) al cual se accede por R4 a travs de dos saltos. A su vez, R3 descubre un destino nuevo (Red4) va R4 a travs de dos saltos. Posteriormente, R1 enva su informacin de encaminamiento a sus vecinos R2 y R3 que no detectan nada nuevo y, por tanto, no realizan ningn tipo de actualizacin (ver Figura 4.13).
- 281 -
Red1 Dir 1
R1
Red1
R2
Red2
R3
Red3
R4
Red2 Dir 1 Red3 Dir 1 Red3 Dir 1 Red4 Dir 1 Red1 R2 2 Red2 R3 2 Red1 R1 2
Red4
Figura 4.11.- Un ejemplo (III) conceptual del funcionamiento del protocolo RIP.
Red1 Dir 1
R1
Red1
R2
Red1 Dir 1 Red3 Dir 1 Red2 R1 2 Red4 R4 2
Red2
R3
Red3
R4
Red2 Dir 1 Red3 Dir 1 Red3 Dir 1 Red4 Dir 1 Red1 R2 2 Red2 R3 2 Red1 R1 2 Red4 R4 2
Red4
Figura 4.12.- Un ejemplo (IV) conceptual del funcionamiento del protocolo RIP.
Red1 Dir 1
R1
Red1
R2
Red2
R3
Red3
R4
Red2 Dir 1 Red3 Dir 1 Red3 Dir 1 Red4 Dir 1 Red1 R2 2 Red2 R3 2 Red1 R1 2 Red4 R4 2
Red4
Figura 4.13.- Un ejemplo (V) conceptual del funcionamiento del protocolo RIP.
- 282 -
Red1 Dir 1 Red2 Dir 1

R1
Red3 R2 2 Red4 R2 3
Red1
R2
Red2
R3
Red3
R4

Red1 R1 2 Red4 R4 2
Red4
Figura 4.14.- Un ejemplo (VI) conceptual del funcionamiento del protocolo RIP. A continuacin, R2 enva su informacin de encaminamiento a sus vecinos R1 y R4 (ver Figura 4.14). De esta ltima informacin, R1 descubre un destino nuevo (Red4) al cual se accede por R2 a travs de tres saltos. Seguidamente, R3 enva su informacin de encaminamiento a sus vecinos R1 y R4 (ver Figura 4.15) que no detectan nada nuevo y, por tanto, no realizan ningn tipo de actualizacin.
R1
Red3 R2 2 Red4 R2 3
Red1
R2
Red2
R3
Red3
R4

Red1 R1 2 Red4 R4 2
Red4
Figura 4.15.- Un ejemplo (VII) conceptual del funcionamiento del protocolo RIP.
- 283 -

R1
Red3 R2 2 Red4 R2 3
Red1
R2
Red2
R3
Red3
R4

Red1 R1 2 Red4 R4 2
Red4
Figura 4.16.- Un ejemplo (VIII) conceptual del funcionamiento del protocolo RIP. Posteriormente, R4 enva su informacin de encaminamiento a sus vecinos R2 y R3 (ver Figura 4.16) que de nuevo no detectan nada nuevo y, por tanto, no llevan a cabo ningn tipo de actualizacin. Y as, se continuara sucesivamente.
0 8 16
31
Comando
Versin (1)
Familia de Direcciones de la Red 1 = 2
Cero Cero
Direccin IP de Destino 1 Cero Cero Distancia al Destino 1 (Mtrica)

Cero
Direccin IP de Destino 2 Cero Cero Distancia al Destino 2 (Mtrica) ...
Figura 4.17.- Formato de los mensajes RIP v1. Bsicamente, un mensaje RIP (ver Figura 4.17) consta de una secuencia de pares y cada par consiste en una direccin IP de red y la distancia a esa direccin. En primer lugar aparece una cabecera de RIP de 32 bits con los siguientes campos: Comando (8 bits): Indica si es una solicitud de informacin de encaminamiento (1) o una respuesta a una solicitud previa o una actualizacin espontnea (2). Una actualizacin contiene todos los registros y mtricas de la tabla de encaminamiento del router origen. Si hay una sola entrada con una Familia de Direcciones de la Red igual a 0 y una mtrica de 16, se est pidiendo una actualizacin de la tabla completa de encaminamiento. Como se ha comentado antes, se envan mensajes de actualizacin a intervalos regulares entre los routers
- 284 -
RIP. Adems, se pueden transmitir mensajes de peticin a un vecino para solicitar informacin de encaminamiento como puede ser durante la inicializacin del sistema, por una prdida de datos o cuando se realiza una funcin de seguimiento de las subredes de la organizacin. En el caso de una actualizacin, sta se enva a intervalos regulares de 30 segundos. En la mayora de los casos, los routers difunden peridicamente mensajes de respuestas no solicitadas. Versin (8 bits): Indica la versin del protocolo. Este formato de mensaje se corresponde con la versin 1. Reservado (16bits): A cero. Seguidamente, aparecen los siguientes campos: Familia de red (16 bits): Identificador del formato de la direccin del nivel de red ya que el protocolo RIP puede trabajar con distintas arquitecturas de comunicaciones. En el caso de TCP/IP, este campo contiene un 2 y slo se usan 4 octetos para definir la correspondiente direccin IP. Si fuera una direccin XNS RIP (14 octetos) se aprovecharan todos los bits a cero que la direccin IP no utiliza y que son los 14 octetos que vienen a continuacin: 2 octetos (16 bits) a cero en el caso de una direccin IP (campo Reservado). 4 octetos (32 bits) a cero en el caso de una direccin IP (Direccin IP de Destino 1). 4 octetos (32 bits) a cero en el caso de una direccin IP (campo Reservado). 4 octetos (32 bits) a cero en el caso de una direccin IP (campo Reservado). Reservado (16 bits): A cero en el caso de una direccin IP. Direccin IP de Destino 1 (32 bits): Direccin de red o subred o mquina de usuario. Reservado (16 bits): A cero en el caso de una direccin IP. Reservado (16 bits): A cero en el caso de una direccin IP.
- 285 -
Distancia al Destino 1 (32 bits): Nmero de saltos o routers encontrados hasta llegar al Destino 1. Los seis campos anteriores170 a continuacin de la cabecera de 4 octetos, definen una entrada. El mensaje puede contener hasta 25 entradas de direcciones. El tamao mximo de un mensaje es de 512 octetos171. Si se necesita enviar ms de 25 entradas, se utilizan varios mensajes. Como principales inconvenientes de la versin 1 de RIP, se destacan los siguientes: Mscaras de subred de longitud fija: Es importante resaltar que no se incluyen mscaras de subred en la versin 1. As, si la parte de mquina no est a ceros, un router no puede saber si una direccin representa una subred o una direccin de mquina. Durante mucho tiempo los fabricantes de routers resolvieron ese problema obligando a que las organizaciones utilizaran mscaras de subred de longitud fija. Difusiones (broadcast): No existen multidifusiones (multicast). Quiere decir esto que se obliga a todas las mquinas (RIP y no RIP), es decir, a todos los interfaces de la red de rea local a recoger y examinar el mensaje. Sin distincin en la capacidad de los enlaces: Se permite que un administrador asigne manualmente una cuenta de saltos a un enlace. Por ejemplo, se podra asignar una cuenta de saltos de 5 a un enlace punto a punto de 64.000 bits por segundo para indicar que tiene menos capacidad que un enlace de una red de rea local a 10.000.000 bits por segundo. Pero cuando los saltos suman ms de 15, los destinos se vuelven inalcanzables. Por eso, los administradores asignan la misma cuenta de saltos (igual a 1) a los enlaces lentos y rpidos. Exceso de trfico: La transmisin de la tabla de encaminamiento completa puede imponer una gran sobrecarga en las subredes de la organizacin. Asimismo, los routers tambin se ven ralentizados si tienen que procesar docenas o cientos de entradas de los mensajes de actualizacin, la mayora de los cuales no han cambiado.
170
20 octetos: Familia de direcciones, Reservado o a ceros, Direccin IP de Destino 1, Reservado o a ceros, Reservado o a ceros.
25 entradas x 20 octetos (cada entrada o par direccin-distancia) + 4 octetos (cabecera RIP) = 504 octetos < 512 octetos (una entrada ms de 20 octetos excedera dicho tamao mximo).
171
- 286 -
16
31
Cero Etiqueta de Ruta Direccin IP de Destino 1 Mscara de Subred Siguiente Salto Distancia al Destino 1 (Mtrica) Familia de Direcciones de la Red 2 = 2 Cero Direccin IP de Destino 2 Mscara de Subred Siguiente Salto Distancia al Destino 2 (Mtrica) ...
Comando Versin (2)
Figura 4.18.- Formato de los mensajes RIP v2. Aunque el documento RFC-1058 que contena la definicin de la versin 1 de RIP se public en 1983, la versin 2 de RIP, RFC-2453, no apareci hasta 1993 (ver Figura 4.18). Se haba declarado la versin 1 de histrica y los administradores deban actualizarse a la versin 2, la cual ofreca soluciones simples a los problemas bsicos de la versin 1. Sin embargo, los cambios eran modestos con el objetivo de conservar la interoperabilidad con routers que soportaban (y soportan) la versin 1 de RIP. El nmero de puerto segua siendo el mismo (520), la cuenta mxima de saltos segua en 15 y se continuaba intercambiando las tablas completas de encaminamiento cada 30 segundos. Pero se pueden transmitir las tablas mediante multidifusin (multicast) en lugar de slo por difusin (broadcast). Por tanto, aquellas mquinas que no soporten RIPv2 no tienen porqu escuchar el mensaje. Es ms, RIPv2 soporta mejor la multidifusin que la difusin. Asimismo, RIP v2 soporta una autenticacin previa por contrasea. Adems, a diferencia de RIPv1, se puede utilizar con CIDR. En este contexto, la mayora de los cambios de la versin 2 se basan en empaquetar ms informacin en los mensajes de actualizacin; pero manteniendo la misma cabecera de 20 octetos. Esta nueva informacin consiste en los siguientes campos: Etiqueta de ruta: Contiene un nmero arbitrario que identifica a un dominio de encaminamiento dentro del mismo SA. Tambin se utiliza para contener el nmero que identifica al SA (p.ej., para que un ISP guarde los destinos de un SA privado va un IGP). El objetivo de este campo es proporcionar datos sobre quin es el origen de la informacin de la ruta en cuestin, permitiendo la interoperabilidad entre RIP de diferentes versiones y otros protocolos de encaminamiento. Por consiguiente, a travs de este campo se pretende separar rutas IP internas (rutas para redes dentro de un dominio de encaminamiento RIP) de rutas RIP externas que se hayan importado desde un EGP o desde otro IGP. - 287 -
Mscara de subred: Es la mscara de la correspondiente direccin IP insertada en el campo anterior. En la versin 1, los routers deben calcular (haciendo uso de la mscara que conocen) dicha mscara, siempre y cuando sea una mscara de subred de longitud fija (misma mscara asociada a las diferentes subredes de una organizacin). Por consiguiente, en la versin 2 se admiten mscaras de subredes de longitud variable. Siguiente salto: Direccin de router para una ruta alternativa al destino especificado en el pertinente campo de Direccin IP de Destino.
16
31
Comando
Versin (2)
Informacin de Autenticacin
Cero
Tipo de Autenticacin
Familia de Direcciones = XFFFF
Figura 4.19.- Formato de autenticacin de RIP v2. Segn se muestra en la Figura 4.19, la caracterstica fundamental de la versin 2 del protocolo RIP es que tiene implementada una seguridad basndose en un simple mecanismo de autenticacin entre routers vecinos mediante una palabra clave (password o contrasea). Si en el campo de Familia de Direcciones aparecen 16 bits a unos, es que se est mandando un mensaje de autenticacin previo al envo de la informacin de encaminamiento. En el campo de Tipo de Autenticacin aparece la clase de autenticacin empleada. Actualmente, slo se ha definido un tipo (valor 2) basado en el envo sin cifrar de una palabra clave compartida por los correspondientes routers vecinos172. Si el tipo de autenticacin es 0, significa que no hay autenticacin. En los 16 octetos siguientes se almacena la palabra clave en cuestin. Si aparece un cero en el campo de Tipo de Autenticacin es que no se enva ninguna palabra clave.
172
Los fabricantes de routers se estn inclinando hacia una autenticacin con la funcin hash MD5.
- 288 -
4.1.4 Protocolo OSPF (Open Shortest Path First)
Protocolo OSPF (Open Shortest Path First)

Desarrollado por el OSPF Working Group del IETF: RFC 2328 IGP estndar para sustituir al RIP Estado del Enlace Sin intervencin de un protocolo de transporte (tipo de protocolo = 89) Protocolo de encaminamiento para sistemas autnomos de todos los tamaos
Acepta crecimientos en la red difundiendo rpidamente la informacin de encaminamiento Baja sobrecarga mediante actualizaciones que informan de los cambios en lugar de todas las rutas Un SA divide sus redes y routers en subconjuntos denominados REAS
rea: Una red autnoma o un conjunto autnomo de redes contiguas Un SA que use OSPF est constituido por una o ms reas La topologa de un rea est oculta para otras reas Cada router en un rea dispone de su propia base de datos de encaminamiento
Encaminamiento segn el tipo de servicio (p.e. retardo bajo) del datagrama IP Balance de carga Seguridad: Todos los intercambios entre routers estn autenticados
Figura 4.20.- Caractersticas ms relevantes del protocolo OSPF. En la Figura 4.20 se muestran las caractersticas fundamentales de un protocolo de router interno (IGP) denominado OSPF (Open Shortest Path First) o protocolo abierto del camino ms corto (RFC-2328) usado para para distribuir y actualizar la informacin de encaminamiento entre routers avanzados o dinmicos en un mismo dominio de encaminamiento de un SA. Todo ello, independientemente del tamao del SA, y basndose en el algoritmo o estrategia de encaminamiento del estado del enlace. En 1988, el IETF empez a trabajar con OSPF como un nuevo protocolo para sustituir a RIP. Posteriormente, se recomend OSPF como propuesta estandarizada173 para solucionar algunas deficiencias de RIP como, por ejemplo, toda la problemtica en cuanto a la escalabilidad de ste (15 saltos como mximo). El diseo de OSPF se centraba, fundamentalmente, en permitir aumentar el nmero de subredes de la organizacin y en distribuir y actualizar rpidamente la informacin de encaminamiento. Asimismo, a diferencia de RIP, donde cada router aprende de sus vecinos slo la distancia a cada destino; OSPF permite que cada router aprenda la topologa completa de las subredes de la organizacin. Es importante tener en cuenta, que un router, basado en el estado del enlace, descubre las rutas creando un mapa topolgico de las subredes y usando dicho mapa para construir el rbol del camino ms corto que permite construir la tabla de encaminamiento. En este escenario, en la raz de
173
La versin 2 se public a mediados de 1991 y en marzo de 1994 apareci una versin 2 revisada.
- 289 -
dicho rbol de rutas aparece el propio router. As, se obtiene un rbol diferente para cada origen con los caminos con el menor coste a cada destino. Todo router de la organizacin es la raz de su propio rbol Una de las caractersticas bsicas de este protocolo es que est ubicado en el nivel de red, un estrato superior al ocupado por IP, ya que sus paquetes se encapsulan directamente en datagramas IP (en el campo de protocolo de la cabecera de IP debe aparecer un 89). En este contexto, los aspectos ms significativos en el diseo del protocolo OSPF son los siguientes: Mayor flexibilidad en el coste del enlace: Se especifica un coste dentro del rango de 1 a 65535 (RIP usa un mismo valor para todos los enlaces), el cual puede estar basado en cualquier tipo de mtrica. En este contexto, OSPF usa tanto mtricas basadas en el estado del enlace como en la distancia. En el caso de la distancia se puede asociar un valor diferente a cada enlace en funcin de las caractersticas propias del enlace en cuestin. Mayor escalabilidad: Para mejorar la escalabilidad, OSPF introduce una jerarqua de dos niveles que permite dividir un SA en una o ms reas, las cuales se interconectan por un rea troncal o central. Por tanto, el SA debe tener al menos un rea, el rea troncal o central y tantas reas adicionales como se necesiten en funcin de la topologa de las subredes de la organizacin. As, se entiende por rea una red o un conjunto de redes y mquinas (sistemas finales y routers) con interfaces a dichas redes. Asimismo, el objetivo es proporcionar una mayor rapidez en el encaminamiento, reduciendo la transmisin de la informacin de estado (destino-coste) por el SA y los clculos que debe llevar a cabo cada router para obtener la ruta de coste mnimo a cada destino de dicho SA. En un principio, cada router en un rea dispone de una tabla de encaminamiento slo para dicho rea que luego puede ir incrementando con todos los destinos del SA. Por consiguiente, dentro de un rea de OSPF todos los routers mantienen la misma base de datos, intercambiando informacin de estado del enlace para mantener su sincronizacin. Mayor rapidez en la convergencia: Debido a que la informacin de estado del enlace proporciona una mayor informacin que la ofrecida por la estrategia del vector-distancia, OSPF converge normalmente ms rpidamente que RIP cuando
- 290 -
se produce un fallo en la red. Asimismo, se detectan ms deprisa174 los cambios en la topologa y se restablecen ms rpidamente los caminos sin bucles. Mscaras de subred de longitud variable (VLSM). Mediante la inclusin de la mscara de subred en el paquete OSPF. Como el trmino red puede denotar una red o subred de IP. En este contexto, una mscara de red puede identificar una red o una subred. Mscaras de superred (CIDR). Como el trmino red puede significar una superred CIDR. En este contexto, una mscara de red puede identificar una superred CIDR. Encaminamiento segn el tipo de servicio. Este rasgo de diseo permite a un administrador que implante fsicamente, a un mismo destino, diferentes caminos con distintos tipos de servicio IP (TOS) incluidos en paquetes de OSPF175. Consecuentemente, se pueden llevar a cabo los clculos mediante una combinacin TOS/coste. As, se calcula el valor de la mtrica para cada ruta y se selecciona la ruta o rutas ptimas para el tipo de servicio de IP, que es una entrada adicional ms en la tabla de encaminamiento. Por consiguiente, OSPF permite varias entradas (rutas) en la tabla de encaminamiento para un mismo destino y costes diferentes debido a que puede incluir, como se ver ms adelante, en el cuerpo de paquetes especficos de OSPF, un tipo de servicio (TOS) IP para el clculo de diferentes caminos a un determinado destino; uno para cada tipo de servicio. Teniendo en cuenta que un router, previo clculo del valor de la mtrica correspondiente, puede obtener distintos caminos con igual coste a un destino; selecciona, en este caso, el ms ptimo mediante la aplicacin del citado tipo de servicio. Esta funcionalidad proporciona una flexibilidad adicional que no est presente en el protocolo RIP. Balance de carga. Mediante la distribucin del trfico por enlaces o caminos con igual coste. Multidifusin (multicast) en redes de rea local. Para reducir la carga en los sistemas que no soportan OSPF y que por difusin (broadcast) se veran
Tras un cambio o interrupcin en la red, la informacin de encaminamiento global se restablece muy rpidamente, normalmente, en unos pocos segundos comparados con los minutos de otros protocolos. Concretamente, se anuncia que hay un TOS asociado a un enlace en un paquete de tipo 2 (Descripcin de la base de datos) y se indica expresamente en un paquete de tipo 4 (Actualizacin del Estado del Enlace).
175
174
- 291 -
obligados a escuchar la informacin de dicho protocolo. Obviamente, tambin se permite utilizar la difusin a la direccin 255.255.255.255. En este contexto, especialmente, en redes de difusin (p.ej., una red de rea local) y como ya se analizar, se utilizan routers designados (y designados de respaldo) para, incluso, reducir el nmero de paquetes OSPF que se intercambian va multidifusin o difusin. Los paquetes OSPF se envan a la direccin de multidifusin 224.0.0.5, que se reconoce como la direccin de todos los routers OSPF en enlaces punto a punto y en redes multiacceso de difusin. En redes multiacceso sin difusin, los paquetes se tienen que enviar a direcciones especficas. Router designado (y designado de respaldo) en redes multiacceso (de difusin y no difusin) con el objetivo de reducir el nmero de paquetes OSPF intercambiados. Autenticacin. Por omisin, OSPF admite (al igual que la versin 2 de RIP) una seguridad basndose en un simple mecanismo de autenticacin entre routers vecinos mediante una palabra clave o contrasea. En la actualidad existe un protocolo OSPF para IPv6 definido en el documento RFC2740 (proposed standard).
Cada router dispone de un mapa topolgico de la red entera
Informacin de todos los routers y redes conectadas Se representa como un grafo dirigido en el cual los routers son los nodos y las redes son los arcos o enlaces entre nodos Cada enlace tiene dos costes de salida que pueden ser iguales o diferentes para cada lado del interfaz
Los routers son vecinos si comparten un mismo enlace o red:

Punto a punto Difusin No difusin
Figura 4.21.- Ms caractersticas del protocolo OSPF. Mediante OSPF, la topologa de las subredes de una organizacin se muestra conceptualmente mediante un grafo dirigido en donde los routers son los nodos y los enlaces, los arcos o redes entre nodos. En este contexto, el protocolo OSPF distribuye, bsicamente, las redes o enlaces en los siguientes tipos: Punto a punto (lnea serie): Dos routers conectados fsicamente de manera directa.
- 292 -
Redes multiacceso de: Difusin (p.ej., una red de rea local del tipo Ethernet). No difusin (p.ej., una red X.25, ATM, etc.).
Una red de multiacceso es, simplemente, un conjunto de routers que se pueden comunicar directamente unos con otros. En una red de multiacceso de difusin, los routers se comunican unos con otros utilizando la red de difusin como es el caso de una red de rea local del tipo Ethernet. Por otra parte, en redes multiacceso que no son de difusin los routers comunican a travs de una red sin multiacceso176. Como ya se seal, en la norma de OSPF, el trmino red significa una red o subred de IP o una superred CIDR. De forma anloga, una mscara de red identifica una red, una subred o una superred CIDR Asimismo, cada enlace tiene dos interfaces con un coste de salida por cada lado del interfaz, los cuales pueden ser iguales o diferentes.
Red 2
R1
R4
Mapa topolgico
R1
Red 3 Red 1 Red 5
Re d2
R4
Red 3
R2
Red 4
R3
Red 1
Red 5
Red 4
R2
R3
Figura 4.22.- Un ejemplo del mapa topolgico del protocolo OSPF. La Figura 4.22 muestra un ejemplo, de lo comentado anteriormente, en donde los routers son los nodos y las redes son los arcos o enlaces entre nodos. A su vez, en la siguiente Figura 4.23 se muestra grficamente un ejemplo de lo que se entiende como rea troncal en el escenario OSPF, el cual interconecta al resto de reas en el SA. Segn se indic en su momento, para mejorar la escalabilidad, OSPF,
176
Por ejemplo, una red de conmutacin de paquetes (X.25) o de celdas (ATM).
- 293 -
introduce una jerarqua de dos niveles que permite dividir un SA en una o ms reas, las cuales se interconectan por un rea troncal o central. Se recuerda que inicialmente, cada router en un rea dispone de una base de datos o tabla de encaminamiento de OSPF slo para dicho rea que luego va incrementando con todos los destinos del SA. La base de datos se utiliza para construir el mapa del rea, e incluye el estado de todos los routers, sus interfaces, sus routers vecinos y redes o subredes conectadas. Un router que est arrancando, obtiene una copia de la base de datos actual de encaminamiento de su vecino contiguo. Seguidamente, slo se comunican los cambios, los cuales se distribuyen rpidamente por el rea y por otras reas debido al propio diseo del protocolo OSPF que permite que un router, como se ver ms adelante, lleve a cabo slo dos procesos diferentes mediante el clculo: De las rutas de coste mnimo a los destinos internos dentro de su rea, aplicando estrictamente el algoritmo de estado del enlace. Basado en aadir, simplemente, el correspondiente coste de su interfaz de salida a todos los destinos externos (fuera de su rea) que reciba de forma resumida.
rea 0 Red Troncal
rea 1
rea 2
El rea 0 o rea troncal distribuye la informacin de encaminamiento entre reas.
Figura 4.23.- Un ejemplo de una red troncal y dos reas. El encaminamiento dentro de un rea se basa en un mapa completo del estado del enlace de dicho rea. El crecimiento de las subredes de la organizacin, o lo que es lo mismo la mejora de la escalabilidad de la red corporativa, se lleva a cabo porque un router slo necesita conocer la topologa detallada y la informacin de mtricas del rea al que pertenece. Segn se ha indicado, todos lo routers con OSPF en un rea mantienen una base de datos de encaminamiento idntica que describe la topologa y estado de todos los elementos de dicho rea. Siempre que se produzca un cambio, como cuando un enlace se interrumpe, esta informacin se propaga por el rea en cuestin. De esta forma, se informa con precisin y se da una rpida solucin a los problemas. Teniendo en cuenta, que la topologa de un rea est oculta para el resto del SA; la informacin de - 294 -
otras reas la resumen los routers en frontera de rea (Area Border Routers) que tienen conexiones a mltiples reas. El concepto de rea permite que OSPF proporcione una jerarqua de dos niveles donde las diferentes reas intercambian paquetes de OSPF a travs del rea troncal. Como puede haber ms de un rea en un SA, es necesario recurrir a una identificacin. En este escenario, un rea se identifica por un nmero de 32 bits que representa el identificador del rea. As, el rea troncal se identifica por el nmero 0.0.0.0.
rea Troncal (backbone): Parte de un sistema autnomo que transmite mensajes OSPF entre reas. Todo SA tiene un rea troncal denominada rea 0
A cada rea se le asigna un nmero El rea troncal es contiguo al resto de las reas
Router Interno: Un encaminador que tiene nicamente conexiones a enlaces dentro del mismo rea Router en Frontera de rea: Un encaminador que puede estar conectado a mltiples reas, es decir, puede tener conexiones a enlaces dentro de dos o ms reas incluyendo siempre al rea 0 Router Troncal: Un encaminador que tiene todos o parte de sus enlaces conectados a la red troncal Router en Frontera de SA (Router Lmite): Un encaminador que intercambia informacin de accesibilidad con routers de otros SA
Figura 4.24.- Definicin de rea troncal y clases de routers OSPF. La Figura 4.24 muestra las definiciones de rea troncal o central o rea 0 y de los distintos routers que contempla OSPF. El rea troncal o central es parte de un SA que conecta todas las reas de dicho SA y, por tanto, transmite informacin de encaminamiento mediante paquetes OSPF entre las reas del SA en cuestin. Se recuerda que un rea se identifica por un nmero de 32 bits que representa su identificador. As, todo SA tiene todas las reas numeradas (0.0.0.0, 0.0.0.1, 0.0.0.2, etc.) y, en concreto, un rea troncal que se identifica por el nmero 0.0.0.0 (rea 0). Asimismo, el rea o red troncal contiene todos los routers que pertenecen a mltiples reas, as como las redes y routers no asignados a ninguna rea. Consecuentemente, cuando un SA se divide en reas de OSPF, se definen, a su vez, cuatro tipos de routers: Router interno (Intra-Area Router): Es un dispositivo de encaminamiento que tiene nicamente conexiones con enlaces dentro de un solo rea. Router en frontera de rea (Area Border Router): Es un dispositivo de encaminamiento que puede estar conectado a mltiples reas, es decir, puede tener conexiones a enlaces dentro de dos o ms reas incluyendo siempre al rea 0. En el caso ms simple, slo est conectado al rea 0 y a otro rea Consecuentemente, este tipo de router pertenece a una o ms reas y al rea - 295 -
troncal. Por consiguiente, conoce (aplicando el algoritmo de estado del enlace) la topologa completa de las reas a las que est conectado. Asimismo, al estar conectado al rea troncal conoce la topologa completa de la red troncal. Un router en frontera de rea resume las informaciones de las reas no troncales a las que est conectado y las transmite de forma resumida a los otros routers de la red troncal. Adems, resume las informaciones de estado de otras reas a las que no est conectado y las transmite a las reas no troncales a las que est conectado. De esta manera, todos los routers en frontera de rea pueden calcular las distancias a los destinos fuera de sus propias reas y transmitir dicha informacin dentro de sus propias reas. Router troncal (Backbone router): Es un dispositivo de encaminamiento que tiene todos o parte de sus enlaces conectados al troncal. Esta categora incluye a todos los routers que dispongan de un interfaz a ms de un rea (routers en frontera de rea). Router en frontera de SA (AS Border Router): Es un dispositivo de encaminamiento lmite de OSPF que tiene sus enlaces conectados a otro SA. Obviamente, se asume que el SA est conectado al mundo exterior. Los routers en frontera de SA aprenden rutas fuera del SA, es decir, se comunican con otros SA en Internet a travs de un EGP, como por ejemplo, el protocolo BGP. Un router en frontera de SA puede ser de cualquier tipo de los indicados anteriormente, es decir, interno, en frontera de rea o troncal. Asimismo, puede existir ms de un router de este tipo en un SA.
- 296 -
Router Frontera de rea: Puede estar conectado a mltiples reas incluyendo siempre al rea 0. Asimismo, informa de forma resumida a su(s) rea(s) de todos los destinos externos procedentes de otras reas.
Router Frontera de SA R1
Router Frontera de rea R2 R3
rea 0 (0.0.0.0)
o Red Troncal
Hacia otros sistemas autnomos (BGP)
R5 R4
R6
El rea troncal (rea 0) permite el intercambio de informacin resumida entre dos routers frontera de rea. Cada router frontera lleva a cabo el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea. Asimismo, aade el coste de su interfaz de salida a todos los destinos externos (fuera de su rea) que reciba.
R8 R7
rea 1
(0.0.0.1)
rea 2
(0.0.0.2)
Router Interno
.
Router Interno: Tiene todos sus enlaces conectados a las redes dentro del mismo rea.
Figura 4.25.- Un ejemplo de routers y reas en un sistema autnomo. En la Figura 4.25 se muestran las reas y routers de una organizacin bajo OSPF. El rea 0 o red troncal incluye los routers R2, R3, R5, R6 y R1. A su vez, el rea 1 incluye los routers R3 y R4. Finalmente, el rea 2 incluye los routers R5, R6, R7 y R8. En este escenario: R2, R4, R7 y R8 son routers internos. R3, R5 y R6 son routers en frontera de rea. R1, R2, R3, R5 y R6 son routers troncales. R1 es un router en frontera de SA o router lmite del SA. Como se puede comprobar, hay routers que son, indistintamente, de varios tipos: R1 es un router troncal y en frontera de SA (router lmite del SA). R2 es un router interno y troncal. R3, R5 y R6 son routers en frontera de rea y troncales. Consecuentemente, R4, R7 y R8 son, nicamente, routers internos. El router R3 (frontera de rea y troncal) conoce la topologa completa del rea 1 y de la red troncal. Asimismo, los routers R5 y R6 conocen la topologa completa del rea 2 y de la red troncal. Es importante tener en cuenta, que un router en frontera de rea conoce la topologa completa de las reas a las que est conectado. Se recuerda que - 297 -
todos los routers en frontera de rea pertenecen a la red troncal, por lo que tambin conocen la topologa completa de sta. En este escenario, R3 aplica el algoritmo de estado del enlace, es decir, el clculo de las rutas de coste mnimo a todos los destinos internos dentro de sus reas (rea 1 y rea 0). Por tanto, dispone de una base de datos para rea 1 y rea 0. Con respecto a los destinos de rea 2 aade el coste de su interfaz con rea 0. A su vez, R3 resume la informacin de rea 1y la transmite al rea 0, es decir, a todos los routers troncales. Concretamente, a R2 que la distribuye a R1, R5 y R6. Posteriormente, R5 y R6 distribuyen dicha informacin resumida al resto de los routers de rea 2. R5 y R6 aplican el mismo procedimiento con respecto a rea 2 y rea 0, es decir, aplican el algoritmo del estado del enlace a todos los destinos internos pertenecientes a dichas dos reas. Seguidamente, resumen la informacin de rea 2 y la transmiten al rea 0, es decir, a todos los routers troncales. Concretamente, a R2 que se queda con la mejor informacin ya sea de R5 o R6 y la distribuye a R3 y R1. Posteriormente, R3 distribuye dicha informacin resumida al resto de routers de rea 1, es decir, a R4. Consecuentemente, disponen de una base de datos para rea 2 y 0. Con respecto a los destinos de rea 1, suman el coste de su interfaz con rea 0. Los resmenes incluyen un identificador de red, subred o superred, una mscara de red, subred o superred y el coste desde el router a la red externa. Por ejemplo, en la siguiente Figura 4.26 se supone que el router R7 quiere acceder a una red destino, Red1, conectada directamente al router R4. En este contexto, R7 usa su base de datos para descubrir la ruta de coste mnimo hasta llegar a Red1. Para ello, previamente R7 ha debido recibir de R5 y R6 un resumen, en concreto, con el coste a Red1 desde R5 y R6. A su vez, R7 suma el coste de R7 a R5, al coste a Red1 desde R5. A su vez, R7 suma el coste de R7 a R6 al coste a Red1 desde R6. Finalmente, R7 compara los dos resultados anteriores para seleccionar la ruta de coste mnimo hasta Red1. En el ejemplo, el router R3 no debera preocuparse de transmitir resmenes de informacin de coste dentro del rea 1. Con esto, se evita el envo de informacin de encaminamiento por la red y procesar dicha informacin en las mquinas involucradas. En este caso, R3 es el nico camino hacia fuera del rea, por lo que R3 es el router por omisin de R4 para todos los destinos externos a rea 1. Si un rea tiene un nico router en frontera, o si no importa cul de ellos se usa, se denomina a dicho rea como rea extrema (stub area), y se puede indicar uno o ms routers por omisin para llegar a los destinos externos. Por consiguiente, un rea extrema o de resguardo es un rea, en la cual se ha configurado el uso de un encaminamiento por omisin para destinos externos pertenecientes a otras reas. El objetivo es reducir el tamao de las tablas de
- 298 -
encaminamiento, especialmente, en el caso de muchos destinos dentro de la organizacin.

Router Frontera de rea: Puede estar conectado a mltiples reas incluyendo siempre al rea 0. Asimismo, informa de forma resumida a su(s) rea(s) de todos los destinos externos procedentes de otras reas.
Router Frontera de SA R1
Router Frontera de rea

R2 R3
rea 0 (0.0.0.0)
o Red Troncal
Hacia otros sistemas autnomos (BGP)
R5 R4
R6
El rea troncal (rea 0) permite el intercambio de informacin resumida entre dos routers frontera de rea. Cada router frontera lleva a cabo el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea. Asimismo, aade el coste de su interfaz de salida a todos los destinos externos (fuera de su rea) que reciba.
R8
Red 1
rea 1
(0.0.0.1)
R7
rea 2
(0.0.0.2)
Router Interno
.
Router Interno: Tiene todos sus
enlaces conectados a las redes dentro del mismo rea.
Figura 4.26.- Un ejemplo de routers y reas en un sistema autnomo. Como ya se ha sealado, la red troncal o rea 0 debe ser contigua al resto de las reas. De este modo, si ante un fallo en un equipo, la red troncal o parte de la red troncal se corta, se pueden usar enlaces virtuales entre dos routers de la red troncal con un interfaz a la misma rea para volver a unir los trozos de la red troncal. Este enlace virtual se trata como un enlace punto a punto lgico. Por ejemplo, si el enlace de R2 a R5 se interrumpe, R5 no podra volver a conectarse al resto de routers (R2, R3, R6 y R1) de la red troncal. En este escenario, se podra usar el enlace virtual R5, R7 y R6 para restablecer la conectividad de la red troncal. Por tanto, se usara el enlace virtual entre R5 y R6 (pasando por R7) ya que R5 y R6 son routers troncales con interfaces al mismo rea 2. Resumiendo, todo router en frontera de rea puede definirse como router en frontera de rea por omisin dentro de dicho rea. El objetivo es evitar la transmisin de informacin resumida de otras reas y reducir el tamao de las tablas de encaminamiento del resto de los routers en el rea en cuestin. A este tipo de rea se la denomina rea de Resguardo (Stub Area), la cual dispone de al menos un router en frontera de rea por omisin.
- 299 -
rea 0
SA1
Router Frontera de rea
SA2
rea 0
BGP BGP BGP

rea 0 Router Lmite de rea rea 0
Internet
BGP
SA4
SA3
Router Interno
Figura 4.27.- Un ejemplo de rutas intrarea, interrea e interSA. La Figura 4.27 muestra un escenario de conexin y encaminamiento entre diferentes sistemas autnomos en Internet. Se aprovecha la citada figura para definir tres tipos de rutas en el escenario OSPF: Intrarea: Cuando el destino est en el mismo rea que el origen. Interrea: Cuando hay que pasar por el rea 0 para llegar al destino (ruta en 3 pasos). Es decir, al rea origen y destino les conecta el rea 0. InterSA: Cuando el rea origen y destino pertenecen a sistemas autnomos diferentes. Conviene resaltar que segn la terminologa OSPF la comunicacin interSA tambin puede referirse a la conectividad entre un dominio de encaminamiento OSPF y otro que puede estar incluso dentro del mismo SA.
- 300 -
Cada enlace tiene dos costes de salida (iguales o diferentes), uno por cada lado del interfaz
O1 O1
R1 1 R2 1
rea 1
SA
R3 R4
8 8 6 6
R6 1
rea 2
R7
Red 4
Red 2
Red 5
Red 1
2
Red 3
R5 2
rea 0
BGP
Figura 4.28.- Un ejemplo de SA. La Figura 4.28 describe un ejemplo de un SA que va a servir para explicar los dos tipos de procesos de clculo que lleva a cabo un router con OSPF y que se han indicado con anterioridad: Clculo de los destinos dentro de su propia rea: Basado en aplicar, estrictamente, el algoritmo del estado del enlace, es decir, el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea. Clculo de los destinos fuera de su propia rea: Basado en aadir, simplemente, el correspondiente coste de su interfaz de salida a todos los destinos externos (fuera de su rea) que reciba de manera resumida.
- 301 -
Los arcos que van de las redes a los routers tienen siempre coste 0 No existen arcos de salida para destinos finales R1 1 R2 1
Red 2
SA
R3 1
8 8
O1
R4
6 6
R6 1
Red 4
R7 2 1
Red 5
Red 1
2
Red 3
2 R5
BGP
Figura 4.29.- El grafo dirigido con arcos del ejemplo del SA. En la Figura 4.29 se muestra que cada enlace tiene dos costes de salida (iguales o diferentes), uno por cada lado del interfaz. Asimismo, se describen las reas y routers de una organizacin bajo OSPF. El rea 0 o red troncal incluye los routers R3, R4, R5 y R6. A su vez, el rea 1 incluye los routers R1, R2 y R3. Finalmente, el rea 2 incluye los routers R6 y R7. En este escenario: R1, R2 y R7 son routers internos. R3 y R6 son routers en frontera de rea. R3, R4, R5 y R6 son routers troncales. R5 es un router en frontera de SA o router lmite del SA. Como se puede comprobar, hay routers que son, indistintamente, de varios tipos: R3 y R6 son routers troncales y en frontera de SA. R5 es un router troncal y en frontera de SA (router lmite del SA). Consecuentemente, R1, R2 y R7 son, nicamente, routers internos. El router R3 (frontera de rea y troncal) conoce la topologa completa del rea y de la red troncal. Asimismo, el router R6 conoce la topologa completa del rea 2 y de la red troncal. Es importante tener en cuenta que un router en frontera de rea conoce la topologa completa de las reas a las que est conectado. Se recuerda que todos los
- 302 -
routers en frontera de rea pertenecen a la red troncal, por lo que tambin conocen la topologa completa de sta. Teniendo en cuenta, que un router en frontera de rea resume la informacin de su propia rea y la transmite a los otros routers de la red troncal; es por lo que R3 realiza el clculo de las rutas de coste mnimo a los destinos internos dentro de rea 1 y rea 0. Asimismo, aade el correspondiente coste (8) de su interfaz de salida a todos los destinos externos procedentes de rea 2, los cuales recibe de manera resumida va R4. Asimismo, R3 resume hacia R4 todos los destinos internos dentro de su rea 1. De igual manera, R4 y R6 actan, con respecto a los destinos internos y externos, tal y como se ha comentado para R3. As, R4 realiza el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea 0 y aade los correspondientes costes (8 y 6) de sus interfaces de salida a todos los destinos externos procedentes de rea 1 y rea 2, los cuales recibe de manera resumida va R3 y R6, respectivamente. A su vez, R6 realiza el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea 2 y rea 0. Asimismo, aade el correspondiente coste (6) de su interfaz de salida a todos los destinos externos procedentes de rea 1, los cuales recibe de manera resumida va R4. Adems, R6 resume hacia R4 todos los destinos internos dentro de su rea 2. De esta manera, todos los routers en frontera de rea (R3 y R6) pueden calcular las distancias a los destinos fuera de sus propias reas y transmitir dicha informacin dentro de sus propias reas. Como ya se ha indicado, R3 aade el correspondiente coste (8) de su interfaz de salida a todos los destinos externos procedentes de rea 2, los cuales recibi de manera resumida va R4. Se recuerda que todo router en frontera de rea puede evitar la transmisin de resmenes de informacin de coste dentro de su propia rea (no troncal). Este es el caso del router R3 que no enva resmenes de informacin de coste dentro del rea 1. En este caso, R3 es el nico camino hacia fuera del rea, por lo que R3 es el router por omisin para R1 y R2 para todos los destinos externos a rea 1. Al rea 1 se la denomina de resguardo. A su vez, R6 aade el correspondiente coste (6) de su interfaz de salida a todos los destinos externos procedentes de rea 1, los cuales recibi de manera resumida va R4. Al igual que antes con R3, R6 puede evitar la transmisin de resmenes de informacin de coste dentro de su propia rea 2. En este caso, R6 es el nico camino hacia fuera del rea, por lo que R6 es el router por omisin para R7. Asimismo, al rea 2 se la denomina de resguardo. Por otro lado, R4 que realiz el clculo de las rutas de coste mnimo a los destinos internos dentro de su rea 0, aade los correspondientes costes (8 y 6) de sus interfaces de salida a todos los destinos externos procedentes de rea 1 y rea 2, los cuales recibi de manera resumida va R3 y R6, respectivamente; procede, a continuacin, a informar de manera resumida a R5. R5 realiza el clculo de las rutas de coste mnimo a los destinos internos dentro de su
- 303 -
rea 0 y aade el correspondiente coste (2) de su interfaz de salida a todos los destinos externos procedentes de rea 1 y rea 2, los cuales recibe de manera resumida va R4. Asimismo, se recuerda que R5 aparte de la tabla interna de OSPF para todos los destinos del SA, tendr, a su vez, tantas tablas externas de BGP como conexiones externas tenga con otros SA. Es importante recordar que los routers R3 y R6 son los nicos routers frontera del rea 1 y rea 2, respectivamente. Por tanto, segn ya se ha indicado, podran no transmitir resmenes de informacin de coste dentro de sus correspondientes reas. Esto es debido a que R3 es el nico camino hacia fuera del rea 1, por lo que R3 como router por omisin es suficiente para todos los destinos externos. Asimismo, R6 es el nico camino hacia fuera del rea 2, por lo que R6 como router por omisin es suficiente para todos los destinos externos. En este caso, rea 1 y rea 2 son reas de resguardo (stub areas). Por tanto, se asume que R5 dispondr, en su tabla de OSPF, de la informacin correspondiente a los destinos internos y de una entrada por omisin a R4 para cualquier destino externo de la red troncal. A su vez, R4 tendr en su tabla OSPF dos encaminamientos indirectos con respecto a R3 (para destinos de rea 1) y R6 (para destinos de rea 2). La anterior Figura 4.29 muestra la topologa (con los interfaces y costes) del SA ya comentado. Se recuerda que la topologa de la red se describe conceptualmente mediante un grafo dirigido en donde los routers son los nodos y los enlaces, los arcos entre nodos. Asimismo, cada enlace tiene dos costes de salida que pueden ser iguales o diferentes para cada lado del interfaz. Es importante resaltar que: Los arcos de salida que van de las redes a los routers tienen siempre coste 0 ya que se consideran una prolongacin de los arcos de entrada. No existen arcos de salida para destinos finales.
- 304 -
O1 O1
R1
rea 1
SA
rea 2
Red 1
R2
Red 2
R3 1
R4
8
6
R6 1
Red 4
R7 2
Red 5
2
Red 3
R3
DESTINO COSTE RUTA
R5
rea 0
O1 Red 1 Red 2 R1 R2 Red 3 R4 R5 Red 4 Red 5 R6 R7
4 3 1 1 1 10 8 10 15 17 14 15
R1 R2 R3 R3 R3 R4 R3 R4 R4 R4 R4 R4
BGP
R6 anuncia las actualizaciones de su BD a R4, el cual incorpora los nuevos datos a su propia BD, sumando el coste 6 a todos los destinos de rea 2 presentados por R6. A su vez, R3 hace lo propio con R4, al repetir el proceso sumando el coste 8 a todos los destinos presentados por R4 A travs del rea 0 cada router frontera escucha los resmenes de reas de todos los routers frontera para calcular el coste a todos los destinos exteriores a su rea aadiendo el coste hasta la red troncal
Figura 4.30.- rbol podado desde R3 y su base de datos. La Figura 4.30 muestra cmo el router R3 aprende nuevos destinos externos (rea 2) recibidos de forma resumida va R4-R6 y cmo, nicamente, aade el coste de su interfaz de salida a dichos destinos externos. A su vez, para los destinos internos (red troncal), R4 aplica estrictamente el algoritmo del estado del enlace. En este contexto, el router R3 utiliza su base de datos para construir un rbol de caminos ms cortos y colocarse a s mismo en la raz. Como ya se ha indicado, este rbol se usa para construir la correspondiente tabla de encaminamiento. A travs del rea 0 cada router en frontera escucha directa o indirectamente los resmenes de reas de todos los routers frontera para calcular, aadiendo el coste de su interfaz de salida a rea 0, todos los destinos exteriores a su rea o red troncal. As, R6 resume hacia R4 todos los destinos internos dentro de su rea 2. R6 ha obtenido dicha informacin al aplicar el algoritmo del estado del enlace, es decir, el clculo de las rutas de coste mnimo a los destinos internos dentro del rea 2. A su vez, R4 que aadi el correspondiente coste (6) de su interfaz de salida a todos los destinos externos procedentes de rea 2, los cuales recibi de manera resumida va R4; procede, a continuacin, a informar de manera resumida a R3 y R5. R3 realiza el clculo de las rutas de coste mnimo a los destinos internos dentro de rea 1 y rea 0 y aade el correspondiente coste (8) de su interfaz de salida a todos los destinos externos procedentes de rea 2, los cuales recibi de manera resumida va R4.
- 305 -
Recapitulando, R6 anuncia las actualizaciones de su base de datos (BD) a R4, el cual incorpora los nuevos datos a su propia BD, sumando el coste 6 a todos los destinos de rea 2 presentados por R6. A su vez, R4 hace lo propio con R3, el cual repite el proceso sumando el coste 8 a todos los destinos de rea 2 presentados por R4.
0
Versin
Cabecera comn OSPF
8
Tipo
16
Longitud del Paquete
31
Identificador del Router Emisor

Identificador del rea Suma de Comprobacin Tipo de Autenticacin
Datos de Autenticacin
Cuerpo del paquete OSPF
Datos de Autenticacin
Datos
Tipo
1 2
Descripcin
Saludo (Hello) Descripcin de la Base de Datos OSPF mediante cabebceras de avisos de estados de enlaces LSA (Link-State Advertisement)
(Datos = cabecera1 LSA + ... + cabeceran LSA )
3 4 5
Solicitud del Estado del Enlace Actualizacin del Estado del Enlace Confirmacin del Estado del Enlace
Figura 4.31.- Cabecera fija de un paquete: Tipos de paquetes. Segn se muestra en la Figura 4.31, todo paquete OSPF consta de una cabecera fija de 24 octetos con los siguientes campos: Versin: Especifica la versin del protocolo. La versin ms actual es la 2. Tipo: Indica el tipo del paquete OSPF. Se definen cinco tipos diferentes que se analizan ms adelante. Longitud del paquete: Especifica la longitud total del paquete OSPF en octetos, incluyendo la cabecera de OSPF. Identificador del router emisor: Define al router emisor, especialmente, cuando ste tiene ms de un interfaz o direccin IP. Todos los routers estn configurados con un identificador nico177. Identificador del rea: Identifica el rea al que pertenece el router.
Una posible implementacin para el identificador del router, consiste en aplicar la parte menor o menos significativa de la direccin IP del router como identificador nico.
177
- 306 -
Suma de comprobacin: Detecta errores en el contenido entero del paquete OSPF, comenzando con la cabecera (excluyendo los 64 bits de autenticacin) y siguiendo con el cuerpo del paquete. Tipo de autenticacin y datos de autenticacin: La combinacin de estos campos permite la autenticacin de los pertinentes routers. Para el tipo de autenticacin existen dos posibles valores: 0: Sin autenticacin. 1: Simple contrasea: En este caso la contrasea se almacena en el ltimo campo de la cabecera denominado datos de autenticacin.
Como ya se ha comentado, en el campo de Tipo se define la clase del paquete OSPF. Existen 5 clases de paquetes OSPF: Tipo 1.- Saludo (Hello): Permite que dos vecinos se detecten automticamente. Es un paquete (ver Figura 4.32) que se enva al arrancar y, luego, peridicamente entre routers contiguos para descubrir, establecer y mantener relaciones de vecindad. Por tanto, se usa fundamentalmente para identificar y probar la accesibilidad de los vecinos y para enviar paquetes al resto de routers contiguos, indicando estoy vivo. En este contexto, y como ya se ha comentado, dos routers son vecinos si tienen un interfaz a una red comn. Cada router difunde un paquete de saludo peridicamente en su red, es decir, los paquetes se envan por cada interfaz, normalmente cada 10 segundos. As, cuando un router recibe un paquete de saludo, responde con otro de saludo que contiene el identificador de cada vecino que se ha escuchado. El router se asegura que la comunicacin con el emisor es bidireccional cuando recibe un paquete de saludo que contiene su identificador de router en uno de los campos de vecinos de dicho paquete. Tambin se envan paquetes de saludo al otro extremo de un enlace punto a punto o circuito virtual para que los correspondientes vecinos sepan que siguen activos. As, un paquete de saludo contiene la lista de todos los identificadores de los vecinos cuyos saludos ha escuchado el emisor. De esta forma, todos los routers saben si sus paquetes se estn escuchando. Asimismo, los paquetes de saludo tambin se usan para identificar a un router designado (lder del grupo) en una red de multiacceso.
- 307 -
0
Cabecera comn OSPF
16 Cabecera de Tipo = 1
24
31
Cuerpo del paquete de saludo
Mscara de Red Intervalo de Saludo Opciones Intervalo de Cese Router Designado Router Designado de Respaldo Vecino1 Vecino2
Prioridad
...
Vecinon
Toda red de difusin que tenga al menos 2 routers conectados (routers vecinos) dispone de un Router Designado encargado de distribuir la informacin de encaminamiento por la red impidiendo la comunicacin directa entre routers vecinos y reduciendo el pertinente trfico. No todos los routers vecinos forman una relacin de adyacencia, slo un Router Designado y el correspondiente router vecino en una red de difusin disponen de esa relacin para el intercambio de informacin de encaminamiento
Figura 4.32.- Formato del paquete de saludo OSPF. Un router designado es un router vecino a los dems (en la misma red) y que intercambia informacin directamente con ellos para impedir que dos routers contiguos cualesquiera intercambien informacin directamente entre ellos mismos. Quiere decir esto, que OSPF utiliza un router designado (y otro designado de respaldo) en redes multiacceso. Es importante tener en cuenta que una difusin e incluso una multidifusin por una red del tipo Ethernet penalizan el trfico por la red y la capacidad de procesamiento de las mquinas conectadas a sta (obligadas a escuchar los pertinentes paquetes). Consecuentemente, gracias a este tipo de router, se reduce el nmero de paquetes OSPF intercambiados por la red en cuestin. Un router designado realiza dos funciones: Genera avisos de estados de los enlaces de la red en nombre de dicha red. Por tanto, actualiza a todos sus vecinos adyacentes con la informacin de encaminamiento ms reciente de la topologa de la red. El router designado acta como experto local y mantiene actualizada la topologa local completa. Posteriormente, comunica dicha topologa a los routers contiguos. Por ejemplo, A, B, C y D son cuatro routers conectados a una misma red de difusin. Siendo A el router designado, B, C y D mantienen sus propias bases de datos sincronizadas dialogando con A. De este modo, no tienen que hablar uno con otro consumiendo recursos. Dos routers se denominan adyacentes cuando sincronizan sus bases de datos a travs del intercambio de informacin de estado del enlace. En este escenario, los vecinos en enlaces punto a punto llegan a ser adyacentes. A su vez, los vecinos en redes multiacceso llegan a ser adyacentes a los routers designados. En el ejemplo anterior, B y C son vecinos pero no son adyacentes uno del otro. Si un router designado queda fuera - 308 -
de servicio, podra ser perjudicial. Es por esto que existe, asimismo, un router designado de respaldo (backup), cuyo identificador se especifica, tambin, en el cuerpo del paquete de saludo. Como se ha comentado, los routers conectados por redes punto a punto y enlaces virtuales se convierten siempre en adyacentes. Routers en redes multiacceso forman adyacencias slo con los routers designado y de respaldo. Informa de todos los routers vecinos conectados a la misma red. El router designado se elige a travs de un mecanismo especificado mediante el protocolo Hello en el documento RFC-2328. Dicho protocolo especifica un paquete Hello con un campo de Prioridad, en el cuerpo de dicho paquete, que permite, junto con el campo de Identificador del Router Emisor, la seleccin del router en cuestin, una vez intercambiados previamente los paquetes de saludo pertinentes. Si en el campo que especifica el router designado, en el cuerpo del paquete Hello, aparece 0.0.0.0 es que no hay un router designado (dem para el campo de router designado de respaldo). En redes de no difusin, la configuracin del protocolo de saludo se lleva a cabo de manera esttica. Concretando un poco ms, el proceso de eleccin de un router designado, bsicamente, es como sigue: 1. Se inicializan a 0.0.0.0 los valores actuales para Router Designado y Router Designado de Respaldo. 2. De los paquetes de saludo recibidos procedentes de los routers vecinos, se anotan, los valores actuales de los campos: Identificador del Router Emisor, Prioridad (del router), Router Designado y Router Designado de Respaldo. 3. Eleccin del Router Designado: El Router Designado ser el que tenga la ms alta Prioridad en uno de los siguientes dos casos: Cuando se haya declarado como Router Designado. Cuando no se haya declarado ningn Router Designado. 4. Eleccin del Router Designado de Respaldo: Todo router que haya sido declarado como designado no puede ser de respaldo. El Router Designado de Respaldo ser el que tenga la ms alta Prioridad en uno de los siguientes dos casos: Cuando se haya declarado como Router Designado de Respaldo.
- 309 -
Cuando no se haya declarado ningn Router Designado de Respaldo. Una vez elegidos los anteriores routers, los pasos descritos se siguen ejecutando para asegurar que ningn router puede declararse asimismo como designado y a la vez como de respaldo. Como ya se ha sealado, una vez se hayan seleccionado los routers designado y de respaldo, stos proceden a establecer las correspondientes adyacencias con el resto de los routers de la red multiacceso. Volviendo al ejemplo comentado con anterioridad en donde A, B, C y D son cuatro routers conectados a una misma red de difusin. Teniendo en cuenta que A es el router designado, B, C y D mantendrn sus propias bases de datos sincronizadas dialogando con A. De este modo, no tendrn que hablar uno con otro consumiendo recursos. Consecuentemente, y asumiendo que B acaba de arrancar; en primer lugar, B escucha los paquetes de saludo para descubrir quines son sus vecinos y, adems, quin es el router designado (A); finalmente, B dialoga con A, intercambiando paquetes de descripcin de la base de datos que contienen la informacin que tiene cada uno en su base de datos. Resumiendo, el protocolo OSPF especifica las siguientes etapas: a) En redes multiacceso, los vecinos se descubren mediante el envo de paquetes de saludo y se elige, a continuacin, el router designado. Por consiguiente, los routers designados se seleccionan automticamente en cada red multiacceso despus de que se hayan descubierto los pertinentes routers vecinos a travs del protocolo Hello. b) Independientemente del tipo de red (punto a punto o multiacceso), se establecen adyacencias y se sincronizan las bases de datos de estado del enlace, intercambiando avisos de estado del enlace OSPF, LSA (LinkState Advertisements) mediante paquetes de descripcin de la base datos (tipo 2) que contienen una lista de lo que cada uno tiene en su base de datos. Cada router transmite al adyacente te aviso de lo que tengo. OSPF implica el establecimiento de adyacencias entre un conjunto de routers vecinos en un mismo SA. Slo los routers que establecen adyacencias participan en la operacin OSPF. Resumiendo, una vez que dos routers vecinos y adyacentes establecen la conectividad entre ellos, intercambian paquetes (tipo 2) con la descripcin de la base de datos para sincronizar sus respectivas bases de datos. Asimismo, los routers adyacentes se intercambian anuncios de estado del enlace, LSA, para permitir que se mantengan las bases de datos topolgicas y para anunciar, incluso, las rutas interrea e interSA.
- 310 -
c) Entre los routers adyacentes se difunde informacin de encaminamiento mediante paquetes de solicitud y actualizacin de estado del enlace (Tipos 3 y 4). Un paquete de saludo comienza con la cabecera comn de OSPF de 24 octetos, seguida de la siguiente informacin (cuerpo): Mscara de Red (32 bits): Mscara asociada al interfaz por donde se enva el paquete. Intervalo de Saludo (16 bits): Tiempo en segundos entre paquetes de saludo. Opciones (8 bits): Capacidades opcionales que soporta el router. Prioridad (8 bits): Especifica la prioridad del router. Se utiliza para elegir el router designado (de respaldo). Si est desactivado, este dispositivo no se puede elegir como router designado (de respaldo). Intervalo de saludo (32 bits): Tiempo en segundos (tiempo de vida) despus del cual se considera sin actividad (apagado) a un vecino que no responde. Router Designado (32 bits): Identifica el router designado para esta red. Se pone a 0.0.0.0 si no hay un router designado. Router Designado de Respaldo (32 bits): dem que para router designado. Vecino1 (32 bits), Vecino2 (32 bits), etc.: Identificadores de todos los vecinos de los que el emisor ha recibido recientemente paquetes de saludo a travs de un interfaz especfico. Los campos de Mscara de Red, Prioridad (del router), Intervalo de Saludo e Intervalo de Cese se configuran para cada interfaz en un router OSPF.
- 311 -
0
Cabecera comn OSPF
24
29
31
MTU del interfaz
Opciones
A cero I M
MS
Nmero de Secuencia de la Descripcin de la BD
Edad de LS
Cabecera LSA o de Aviso de Estado del Enlace (repetido por cada Aviso)
Opciones
Identificador de LS
Tipo de LS
Cuerpo del paquete de Descripcin de la Base de Datos
Router Anunciador de LS
Nmero de Secuencia de LS
Suma de Comprobacin de LS
Longitud
Tipo de LS (Link State) 1 2 3 4 5
Significado
Enlaces del Router (n de enlaces, tipo de enlace, TOS, mtrica, ...) Enlaces de Red (Routers conectados a la red) Resmenes del Enlace (Rutas a los destinos de interrea) Resumenes del Enlace (Rutas a Routers Lmites de reas) Enlaces Externos a SA (rutas a redes externas de otros SA)
Figura 4.33.- Formato del paquete de descripcin de la base de datos. Tipo 2.- Descripcin de la Base de Datos: Es un paquete (ver Figura 4.33) que intercambian los routers vecinos adyacentes para inicializar sus tablas de encaminamiento. Por tanto, el objetivo de este paquete es resumir (mediante cabeceras LSA o de aviso del estado del enlace) el contenido inicial de la base de datos que cada router posee. Consecuentemente, durante el inicio, se usa para intercambiar informacin de manera que un router pueda descubrir los datos que le faltan en su base de datos. El router emisor (primero en transmitir) es el maestro o principal mientras que el receptor es el esclavo o secundario, encargado ste ltimo de transmitir los oportunos acuses de recibo. Un paquete de descripcin de la base de datos comienza con la cabecera comn de OSPF de 24 octetos, seguida de la siguiente informacin (cuerpo): MTU del interfaz (16 bits): Unidad Mxima de Transferencia que puede enviarse por el interfaz sin fragmentacin. Este campo est a cero en el caso de paquetes de descripcin de la base de datos enviados por enlaces virtuales. Opciones (8 bits): Capacidades opcionales que soporta el router. Reservado (5 bits): A cero. Bit I: Bit puesto a 1 en el paquete inicial. Por tanto, se activa si este paquete es el primero en la secuencia de paquetes de descripcin de la base de datos. Bit M: Bit puesto a 1 si siguen paquetes adicionales. Por tanto, se activa si a este paquete le siguen ms paquetes de descripcin de la base de datos. Bit MS: El bit Maestro/Esclavo indica el papel que juega el router. Si est activado es el router principal o maestro, es decir, el que transmite. De otra forma, es el router secundario o esclavo, es decir, el que recibe. - 312 -
Nmero de Secuencia de la Descripcin de la Base de Datos (32 bits): Identifica secuencialmente los paquetes de la base de datos, de forma que el receptor pueda detectar paquetes perdidos. El resto del paquete consiste en una lista de una cabecera (20 octetos) o ms cabeceras LSA: Cabecera(s) LSA= LSA1, LSA2, ..., LSAn: El paquete con la descripcin de la base de datos puede contener una o ms cabeceras LSA. Quiere decir esto, que el paquete tipo 2 contendr tantos avisos de estados de los enlaces o LSA (LinkState Advertisements) como enlaces existan en la correspondiente base da datos. Cada aviso de enlace o LSA consta de una cabecera LSA. Por consiguiente, es posible utilizar varios paquetes para describir la base de datos de estado del enlace y en cada paquete se pueden incluir varios LSA (cada uno de ellos con su propia cabecera LSA). Resumiendo, el router designado genera el aviso de estado LSA, con los informes del estado de la red, a todos los vecinos en dicha red, especificando los routers conectados a su red multiacceso. Los routers envan slo sus cabeceras LSA, en lugar de las bases de datos completas. De esta manera, el vecino puede solicitar el LSA que no tenga. Los campos de la cabecera comn LSA (20 octetos) son los siguientes: Edad de LS o de estado del enlace (16 bits): Describe el tiempo en segundos desde que se gener el LSA. Cuando alcanza un mximo valor el aviso LSA se descarta. Asimismo, este campo se utiliza para determinar cul es la copia LSA ms reciente para su instalacin en la base de datos. Opciones (8 bits): Capacidades opcionales que puede soportar el router. Actualmente se han asignado 5 bits de los cuales slo el bit E (segundo bit menos significativo o ms a la derecha) est ms descrito y documentado en el documento RFC-2328. Este bit que describe capacidades externas de encaminamiento, ms en concreto cmo se transmiten avisos LSA externos del SA (reas de resguardo o stub areas), se usa slo como informacin y, por tanto, no afecta a la tabla de encaminamiento. Tipo de LS o de estado del enlace (8 bits): Especifica el tipo de LSA. Cada tipo tiene un formato de aviso separado, existiendo cinco tipos posibles: Tipo 1.- LSA de router (enlaces o interfaces del router): Es el tipo de aviso utilizado por todos los routers OSPF para describir el estado (n de enlaces, tipo de enlace TOS, mtrica...) de sus interfaces dentro de un
- 313 -
rea. Slo se difunde dentro del rea correspondiente. OSPF utiliza nicamente este tipo cuando es una red de routers conectados por enlaces punto a punto. Tipo 2.- LSA de red (enlaces de red): Es el tipo utilizado por el router designado en una red multiacceso para proporcionar la lista de routers conectados a dicha red. Tipo 3.- LSA resumen de redes (enlaces de resumen de redes): Es el tipo utilizado por los routers en frontera de rea para informar, a todo el rea, de rutas a destinos externos, es decir, dentro del SA pero fuera del correspondiente rea. Tipo 4.- LSA resumen de router lmite (enlace de resumen de routers lmites): Es el tipo utilizado por los routers en frontera de rea para informar, a todo el rea, de caminos a routers en frontera de SA. Tipo 5.- LSA resumen de red externa del SA: Es el tipo utilizado por el router en frontera de SA para proporcionar, a todo el SA, una ruta a un destino externo en otro SA. Por tanto, se difunde en todas las reas de la organizacin. Identificador de LS o de estado del enlace (32 bits): Contiene una identificacin para el enlace que puede ser la direccin IP de un router o de una red dependiendo del Tipo de LS. 1 y 4: Identificador del router. 3 y 5: Direccin IP de una red. 2: Direccin IP del router designado. Router anunciador (32 bits): Identificador del router que origina el LSA. Este campo contiene el identificador de: LS para avisos LSA del tipo 1. Un router designado de red para avisos LSA del tipo 2. Un router en frontera de rea para avisos LSA del tipo 3 y 4. Un router en frontera de SA para avisos LSA del tipo 5.
- 314 -
Nmero de secuencia LS o de estado del enlace (32 bits): Este campo numera los LSA secuencialmente, y se puede utilizar para detectar LSA obsoletos o duplicados. Suma de comprobacin LS o de estado del enlace (16 bits): Incluye el contenido entero del LSA, excepto la edad del estado del enlace. Longitud (16 bits): Especifica la longitud en octetos del LSA (cabecera LSA + cuerpo LSA) incluyendo los 20 octetos de la cabecera LSA. La cabecera LSA contiene suficiente informacin como para identificar el aviso LSA (Tipo de LS, Identificador de LS y Router Anunciador). Si hay varias copias o instancias de un aviso LSA, se selecciona la ms reciente examinando los campos: Edad de LS, Nmero de Secuencia de LS y Suma de Comprobacin de LS. Tipo 3.- Solicitud de Estado del Enlace: Es un paquete (ver Figura 4.34) utilizado entre routers vecinos para averiguar una determinada informacin de encaminamiento. Ms concretamente, es el paquete que se transmite cuando se ha perdido o se desean actualizar las correspondientes entradas de la base de datos de estado del enlace. Un paquete de solicitud comienza con la cabecera comn de OSPF de 24 octetos.
Un router enva este paquete hacia un vecino para solicitar informacin actualizada sobre
un conjunto especfico de enlaces.
0
Cabecera comn OSPF
Tipo de LS
24
31
Cuerpo del paquete de solicitud
Identificador de LS
Router Anunciador de LS
Se repite para cada aviso LS (LSA)
Tipo de LS (Link State) 1 2 3 4 5
Significado
Enlaces del Router (n de enlaces, tipo de enlace, TOS, mtrica, ...) Enlaces de Red (Routers conectados a la red) Resmenes del Enlace (Rutas a los destinos de interrea) Resumenes del Enlace (Rutas a Routers Lmites de reas) Enlaces Externos a SA (rutas a redes externas de otros SA)
Figura 4.34.- Formato del paquete de solicitud de estado del enlace. El resto del paquete (cuerpo) se construye con una o ms solicitudes de avisos, cada una de los cuales contiene los tres campos siguientes: Tipo de aviso LS o de estado del enlace (32 bits): Tipo de LSA (uno de los cinco tipos ya comentados).
- 315 -
Identificador de LS o de estado del enlace (32 bits): Tal y como se ha comentado con anterioridad, contiene una identificacin para el enlace que puede ser la direccin IP de un router o de una red dependiendo del tipo de estado del enlace. 1 y 4: Identificador del router. 3 y 5: Direccin IP de una red. 2: Direccin IP del router designado. Router anunciador de LS (32 bits): Identificador del router que origina el LSA. Segn se ha indicado, este campo contiene el identificador de: LS para avisos LSA del tipo 1. Un router designado de red para avisos LSA del tipo 2. Un router en frontera de rea para avisos LSA del tipo 3 y 4. Un router en frontera de SA para avisos LSA del tipo 5.
0
Cabecera comn OSPF
24
31
Nmero de Avisos del Estado del Enlace

Aviso de LS1 (LSA1)
Aviso de LS2 (LSA2)
...
Cuerpo del paquete de actualizacin
Aviso de LSn (LSAn)
Cabecera LSAn o de Aviso del Estado del Enlace (repetido por cada Aviso)
Edad de LSn
Opciones
Tipo de LSn
Identificador de LSn
Router Anunciador de LSn
Nmero de Secuencia de LSn
Suma de Comprobacin de LSn

Cuerpo LSA n
Longitud
Datos de LSn
A la cabecera LSA le sigue el resto del paquete de estado del enlace (Datos de LS o cuerpo LSA)
Figura 4.35.- Formato del paquete de actualizacin de estado del enlace. Tipo 4.- Actualizacin del Estado del Enlace: La informacin sobre la topologa de un SA con OSPF se pasa de router a router, es decir, entre routers adyacentes en forma de avisos LSA contenidos en paquetes de tipo 4 (ver Figura 4.35). As, este tipo de paquetes los enva un router mediante inundacin por todos sus enlaces (menos por el enlace de entrada) como respuesta a los paquetes de solicitud de estado del enlace y, tambin, para informar dinmicamente de cualquier cambio surgido en el escenario del SA. Esto se lleva a cabo en respuesta a una solicitud de estado del enlace o cuando un router descubre que su estado del enlace ha cambiado. Se pueden transmitir estos - 316 -
paquetes mediante multidifusin (multicast) o difusin (broadcast) en redes que soportan dichos mecanismos de transmisin en el nivel de enlace. Si algn router no recibe estos paquetes, se envan stos mediante unidifusin o punto a punto (unicast). Segn se analiz anteriormente, cada actualizacin consiste en una lista de avisos y cada aviso (LSA) tiene su propio formato comn de cabecera LSA (20 octetos). A continuacin de la cabecera, en el campo de datos de LS, se incluye uno de los cinco posibles formatos. En cualquier caso, el campo de tipo de LS en la cabecera, especifica cul de los formatos se ha utilizado. En este contexto, un paquete de actualizacin comienza con la cabecera comn OSPF de 24 octetos. El resto del paquete (cuerpo) consta de los siguientes campos: Nmero de LSA: Indica el nmero de avisos LSA (cabecera y cuerpo) incluidos a continuacin. LSA1, LSA2, ..., LSAn: Cada LSA con su cabecera (20 octetos) y cuerpo178. Asimismo, cada router retransmite peridicamente un LSA a un vecino hasta que recibe de ste la correspondiente confirmacin. OSPF requiere que todos los que originan LSA refresquen sus LSA cada 30 minutos. Esta prctica protege contra la corrupcin accidental de la base de datos.
0
Cabecera comn OSPF
24
31
Cabecera de Aviso de LS1(LSA1)
...
Edad de LS
Cabecera LSA1 o de Aviso del Estado del Enlace1 (repetido por cada LSA o aviso recibido)
Opciones
Tipo de LS
Identificador de LS1
Router Anunciador de LS1
Nmero de Secuencia de LS1
Suma de Comprobacin de LS1
Longitud
Cada aviso del estado del enlace se debe confirmar separadamente. Las confirmaciones
mltiples se pueden agrupar en un mismo paquete de acuse de recibo
Figura 4.36.- Formato del paquete de confirmacin de estado del enlace.
Para ms informacin sobre el campo de datos del cuerpo ver el documento RFC-2328, secciones: A.4.2, A.4.3, A.4.4, A.4.5.
178
- 317 -
Tipo 5.- Confirmacin del Estado del Enlace: Es el paquete (ver anterior Figura 4.36) utilizado para confirmar la recepcin de una actualizacin de estado del enlace. El emisor retransmitir hasta que se confirme. Un paquete puede contener una o ms confirmaciones, una para cada aviso de estado del enlace recibido. Por tanto, la confirmacin consta de una copia de la cabecera (LSA) por aviso (cabecera LSA + cuerpo LSA) recibido. Finalmente, las bases de datos quedan sincronizadas tras un intercambio completo de informacin con las pertinentes confirmaciones. En este contexto, un paquete de confirmacin comienza con la cabecera comn OSPF de 24 octetos. El resto del paquete (cuerpo) consta de una o ms cabeceras LSA (20 octetos): Cabecera LSA1, cabecera LSA2, ..., cabecera LSAn. Con el objetivo de mantener la integridad de la base de datos, es fundamental comprobar rigurosamente la validez de todos los avisos LSA. Por consiguiente, un aviso LSA se elimina si: La Suma de Comprobacin de LS es incorrecta. El Tipo de LS es invlido. La Edad de LS ha alcanzado el mximo tiempo. El aviso LSA es el mismo o ms viejo que uno ya almacenado en la base de datos. Si un aviso LSA pasa las anteriores comprobaciones, se transmite una confirmacin al router emisor. Si el emisor no ha recibido ninguna confirmacin, entonces, se retransmite cada paquete Tipo 4 al vencimiento de su correspondiente temporizador. Una vez se acepta un aviso LSA, ste se transmite por inundacin hasta que haya sido recibido por todos los routers de un rea. Como ya se ha comentado, los avisos LSA se identifican por su Tipo de LS, Identificador de LS y Router anunciador de LS. Seguidamente, se distinguen unos de otros, seleccionando la copia LSA ms reciente por su Nmero de Secuencia de LS, Edad de LS y Suma de Comprobacin de LS. Se debe calcular la Edad de LS para determinar si el aviso LSA debera instalarse en la base de datos del router en cuestin. Slo el aviso LSA ms reciente es el que se acepta e instala en la base de datos. Todo esto provoca que el mapa o grafo topolgico se recalcule y la tabla de encaminamiento se actualice.
- 318 -
4.1.5 Protocolo BGP (Border Gateway Protocol)

(Exterior Gateway Protocol)
R2 ral 1 R1 ral 2 R4 R5 ral 5
BGP (Vector Distancia)

R6 ral 6 R8
IGP (RIP)
R3 ral 3 ral 4
EGP
ral 7
IGP (OSPF)
R7 ral 8
Gateways/Routers en Frontera de rea (Exteriores)
Figura 4.37.- Un ejemplo de escenario para el protocolo BGP. Segn se ha reflejado anteriormente, y con el objetivo de poder encaminar datagramas IP desde una mquina de una red de un SA a otra mquina de otro SA, los SA se conectan entre s mediante routers externos (ver Figura 4.37) que usan un mismo protocolo externo o EGP (Exterior Gateway Protocol). El protocolo EGP de Internet es el protocolo denominado BGP, el cual est basado en el vector distancia. Aparte de una tabla interna de encaminamiento por dominio mantenida por un IGP (Interior Gateway Protocol), un router externo dispone de tantas tablas externas, mantenidas por BGP, como los SA a los cuales dicho router est conectado. En el ejemplo179, los routers externos R4 y R5 disponen cada uno de ellos de dos tablas de encaminamiento: una interna para encaminar datagramas IP por el sistema autnomo 1 (R1) y el sistema autnomo 2 (R2) respectivamente, y otra externa para encaminar a cualquier mquina de SA2 (desde R1) y SA1 (desde R2). La nomenclatura para el trmino router externo es algo variada. Como ya se ha indicado, el documento RFC-2328 que describe el protocolo OSPF, utiliza el trmino router en frontera de SA (AS boundary router). Los documentos RFC-1771 y RFC-1772 que describen el protocolo BGP, usan, a su vez, los trminos router/gateway en frontera. Por mantener trminos ya estandarizados, en esta documentacin se utilizar el trmino router en frontera de SA en un escenario OSPF y/o BGP. Segn se indic al tratar el protocolo OSPF, en un SA puede haber ms de router en frontera de SA y, por tanto, ms de una ruta alternativa para salir al exterior.
179
SA1 y SA2 disponen de un nico dominio de encaminamiento.
- 319 -
BGP-4: RFC 1771 Protocolo de distribucin y actualizacin de informacin de encaminamiento entre routers de SA diferentes Vector distancia
No hay comunicacin de distancias mtricas
TCP y puerto 179 Revela la cadena completa de SA que hay que atravesar para llegar a un destino (informacin de accesibilidad). Se elige siempre la cadena o camino o ruta de SA ms corta o con el menor n de identificadores un aviso con su propio identificador no tiene ms que eliminar dicha informacin) Autenticacin Ponderaciones de polticas de encaminamiento, que no forman parte del protocolo, complementan su uso RIPE Routing Registry: http://www.ripe.net/db Soporte de CIDR
Cada router no slo guarda el siguiente salto a un destino sino la ruta completa (registro de la trayectoria seguida) evitando que se formen bucles (fcil deteccin de bucles: si un router externo recibe
Figura 4.38.- Caractersticas ms relevantes del protocolo BGP. La Figura 4.38 muestra las caractersticas fundamentales de un protocolo externo (EGP), denominado BGP (RFC-1771), usado para el encaminamiento dinmico entre routers avanzados o dinmicos externos o en frontera de SA pertenecientes a diferentes SA. Fue desarrollado por el grupo de trabajo (Working Group) IDR/BGP del IETF y est basado en el algoritmo o estrategia de encaminamiento del vector distancia. Una de sus caractersticas es que est ubicado en el nivel de aplicacin por encima de TCP y en donde las solicitudes y respuestas se identifican a travs del mismo nmero de puerto (179). Al estar montado sobre TCP, BGP requiere de toda la fiabilidad proporcionada por el nivel de transporte de la arquitectura TCP/IP. Asimismo, se simplifica el protocolo ya que no hay que implementar los pertinentes mecanismos de fiabilidad como, por ejemplo, la gestin de los temporizadores. Adems, las actualizaciones de las tablas de encaminamientos son, obviamente, ms fiables. A pesar de que BGP est basado en el algoritmo de encaminamiento del vector distancia, no hay comunicacin de distancias mtricas o del nmero exacto de saltos que hay que realizar hasta llegar al destino; pero s se usa como mtrica, para la seleccin de rutas, el nmero de identificadores de SA consecutivos (Camino_SA) para llegar a los destinos finales indicados. En consecuencia cuantos menos identificadores de SA aparezcan, para llegar a un destino final, mucho mejor, ya que la ruta ser ms corta. El problema asociado a los protocolos basados en el algoritmo del vector distancia, como es el de la formacin de bucles (cuenta al infinito), se elimina con BGP ya que el correspondiente router externo descarta todas las rutas de los SA que pasen por l, las cuales han sido enviadas por routers BGP vecinos.
- 320 -
Otra de las caractersticas importantes es que BGP soporta el formato CIDR y, por tanto, permite la identificacin de superredes. Asimismo, si dentro de una organizacin es importante que los routers vecinos se autentiquen (especialmente si estn gestionados por diferentes administradores), mucho ms lo es si pertenecen a diferentes SA (incluso pertenecientes a diferentes pases). Por consiguiente, BGP por omisin tambin contempla un servicio bsico de autenticacin. Entre los sistemas que intercambian informacin de encaminamiento puede aparecer sistemas finales de usuario, es decir, no slo routers. Una configuracin posible es convertir un sistema final de usuario en un servidor de encaminamiento que acte como router externo y se comunique con otros routers externos en los SA vecinos. Es importante tambin mencionar que todo SA debe tener un nmero asignado que lo identifica. Aparte de este nmero, el administrador puede definir una poltica de encaminamiento englobando todo tipo de consideraciones o ponderaciones tcnicas180, polticas, sociales, econmicas o de seguridad asociadas a un SA que puede aparecer en un determinado itinerario para acceder a un destino. Con esta informacin, el administrador de un SA tiene una informacin extra asociada a la indicada por la correspondiente tabla de encaminamiento. Es decir, si un SA est conectado a otro perteneciente a un pas potencialmente peligroso, el administrador puede elegir otra ruta alternativa (pasando por otro SA). En este contexto, las polticas o ponderaciones de encaminamiento que no forman parte de BGP se configuran manualmente o estticamente en cada router externo haciendo uso de herramientas de ayuda. Estas informaciones extras no forman parte del protocolo BGP aunque complementan su uso. En la direccin Web, http://www.ripe.net/db (RIPE NCC) se pueden encontrar herramientas de ayuda para manejar estas informaciones (en paralelo con la tabla BGP). Asimismo, en dicha direccin se puede encontrar los SA europeos, aparte de otras informaciones relacionadas con un SA de inters para todo administrador.Como se puede ver y debido a que cada SA tiene su propio control administrativo, el objetivo de BGP est ms en cuestiones polticas (acerca del tipo de informacin que puede atravesar una determinada frontera) que en optimizar caminos. En la actualidad existe un protocolo BGP-4 para IPv6 definido en el documento RFC2545 (proposed standard). Como ya se ha comentado, existen herramientas que permiten complementar el uso de las polticas de encaminamiento con la informacin de las tablas de encaminamiento y, por ejemplo, no dejar salir ciertos datagramas que tienen un destino determinado (supuestamente peligroso) indicado por la correspondiente tabla. A continuacin, se indican algunas de las cuestiones que debiera resolver previamente el administrador de un SA:
180
Trfico, retardos, peligro de congestin, etc.
- 321 -
Qu rutas o itinerarios de SA se anuncian al exterior y a qu vecinos? Qu rutas se aceptan desde el exterior y desde qu vecinos? Criterios de preferencia en caso de caminos alternativos. Encaminamientos por omisin. Especifica qu tipo de SA se va a emplear: SA Extremo. SA Multiconectado. SA de Trnsito. ... Asimismo, BGP puede forzar polticas modificando la seleccin de diferentes caminos hacia un destino y controlando la redistribucin de la informacin de encaminamiento. Por ejemplo, si el SA A rechaza transportar trfico a otro SA B, A puede forzar una poltica que prohba pasar por B. Una de las primeras preguntas que debe hacerse un administrador de SA es: qu tipo de SA va a ser su organizacin: un SA extremo o multiconectado o de trnsito? Las definiciones de estos tipos de SA se muestran seguidamente: SA Extremo (Stub AS): Slo tiene una conexin interSA con otro SA. SA Multiconectado: Dispone de conexiones con ms de un SA pero se niega a transportar trfico de trnsito de terceros. SA de Trnsito: Dispone de conexiones con ms de un SA y transporta trfico de trnsito local y de terceros, pudiendo imponer polticas de restriccin.
- 322 -
.BGP ..
SA1
Red 2
R8
...
SA3
BGP
RIP/OSPF
R7
R2 R1
Red 3
RIP/OSPF
Red 1
Red 5
R6
BGP
R4 R5
Red 7
Red 8
R3
Red 4
SA2
Red 6
Figura 4.39.- Un ejemplo entre routers BGP. En la Figura 4.39 se muestra un ejemplo de tres SA (SA1, SA2 y SA3) intercambiando informacin de encaminamiento va BGP. Se asume que, por ejemplo, R1 y R4 se conectan a travs de un enlace punto a punto.
BGP .. .
R8
RIP/OSPF
SA3
Red 2
SA1
Red 1
BGP
Red 5
R7 R6
Red 8
R2
Red 3 RIP/OSPF
R1
BGP
R4 R5
RIP/OSPF
R3
Red 4
Red 7
SA2
Red 6
Camino_SA = SA1
MENSAJE DE ACTUALIZACIN de R1 a R4
Siguiente_Salto = R1 Destinos = Red1 Red2 Red3 Red4

Camino_SA = SA2, SA1 Siguiente_Salto = R4
Destinos = Red1 Red2 Red3 Red4
MENSAJE DE ACTUALIZACIN de R4 a R8
Figura 4.40.- Los mensajes de actualizacin en el escenario del ejemplo. Apoyndose en el mismo escenario anterior, se describe cmo transmiten los mensajes de actualizacin los routers R1, R2 y R3 a travs del protocolo BGP (ver Figura 4.40). El proceso consiste en los siguientes pasos: 1. R1 le indica a R4 que para acceder a todos los destinos indicados dentro de SA1 hay que pasar por R1 a travs de SA1.
- 323 -
2. A su vez, R4 le indica a R8 que para acceder a todos los destinos indicados dentro de SA1 hay que pasar por R4 a travs del itinerario SA2 SA1. 3. Seguidamente, R8 indicara a otro potencial router vecino BGP que para acceder a todos los destinos indicados dentro de SA1 hay que pasar por R8 a travs del itinerario SA3 SA2 SA1. 4. ...
B A
SA1
C
SA3 SA6
BGP BGP
F
SA4
SA9
G
SA7
E
SA2
BGP BGP
H
BGP
I
SA5 SA8
SA10
Para la Ruta SA4 SA7 SA6 SA9 (FGCD), el router externo F (SA4) recibe de sus vecinos:
De B: SA3 SA6 SA9 De G: SA7 SA6 SA9 De H: SA5 SA4 SA7 SA6 SA9 (ruta descartada al pasar a travs
de F)
De E: SA2 SA4 SA7 SA6 SA9 (ruta descartada al pasar a travs

de F) LA DECISIN CONSISTIR EN PASAR POR
SA6 SA9)
SA3 (SA4 SA3 SA7 (SA7 SA6 SA9)DEPENDIENDO DE LA
POLTICA DE ENCAMINAMIENTO
Figura 4.41.- Un ejemplo de un escenario BGP. La Figura 4.41 describe un conjunto de diez SA conectados a travs de routers BGP por Internet, y cmo el router externo "F" toma una decisin de encaminamiento para llegar al SA9 en funcin de las rutas que le indican sus routers vecinos "B", "G", "H" y "E". Al final "F" dispone va BGP de dos alternativas igual de buenas. Es el administrador del SA4 quien finalmente decide por una u otra segn las informaciones adicionales que disponga mediante una herramienta de ayuda. Estas informaciones son complementarias al uso del protocolo BGP y, como ya se ha indicado, pueden estar relacionadas con consideraciones tcnicas, polticas, sociales, econmicas o de seguridad. En la citada Figura 4.41 se puede ver lo fcil que es detectar y evitar bucles. Si el router externo de un SA recibe un aviso y ve su propio identificador de SA en la ruta, no tiene ms que eliminar dicha informacin. Es decir, si el nmero de SA del interlocutor de BGP est ya contenido en la lista de nmeros de SA, esa ruta ya ha pasado por all y, por tanto, se debe rechazar. Se recuerda que uno de los objetivos de BGP es el encaminamiento por una cadena de SA evitando que se formen los citados bucles.
- 324 -
FUNCIONES BSICAS:
Adquisicin de Vecino: Un
Router Externo se pone en contacto con otro para intercambiar informacin de encaminamiento (mensaje de Abrir)
TIPOS DE MENSAJES:
Abrir (Open):
Establecer una relacin segura (autenticada) de vecindad con otro router externo
Actualizar (Update):
Deteccin de Vecino Alcanzable: Verificacin
peridica de que los routers externos y sus conexiones de red funcionan correctamente (mensaje de Continuar)
Transmitir informacin de destinos finales (anunciar y eliminar) a travs de una nica ruta (lista de routers externos)
Continuar (Keepalive):
Confirmar un mensaje de Abrir y confirmar peridicamente la relacin de vecindad
Deteccin de Red Alcanzable: Registro de un

destino final (mensaje de Actualizar)
(Notification): Responder a
un mensaje incorrecto, a una condicin de error o excepcin
Figura 4.42.- Procedimientos funcionales y mensajes asociados BGP. En el argot del protocolo, a los routers de BGP se les denomina interlocutores de BGP (BGP speakers). As cada interlocutor de BGP establece una conexin TCP con uno o ms interlocutores de BGP. En cada conexin TCP, un par de interlocutores de BGP intercambian mensajes BGP (ver Figura 4.42) que establecen una sesin BGP para: Intercambiar informacin sobre nuevas rutas que actualmente estn activas, es decir, estn siendo utilizadas para alcanzar la direccin o direcciones especificadas181. Intercambiar informacin sobre rutas obsoletas que actualmente ya no estn activas. Informar sobre condiciones de error que obligan a liberar la conexin TCP. Como ya se ha mencionado, la informacin intercambiada contiene una secuencia de los SA que los datagramas IP deben atravesar para llegar a la red destino o a un grupo de redes. Esta informacin intercambiada entre intrelocutores BGP permite a un router construir un grafo podado de conectividad SA. Inicialmente, las parejas BGP intercambian la tabla de encaminamiento de BGP completa y, despus, se envan slo las actualizaciones182.
181
Utilizando el formato CIDR para un grupo de redes.
- 325 -
El protocolo BGP realiza, bsicamente, las siguientes tres funciones: Adquisicin de Vecino: Mediante esta funcin, un router BGP conoce a su vecino o vecinos, es decir, un router en frontera de SA se pone en contacto con otro u otros para intercambiar informacin de alcanzabilidad. Es evidente, que se requiere de un procedimiento formal ya que el otro router podra no querer participar. Deteccin de Vecino Alcanzable: A travs de esta otra funcin, cada vecino comprueba peridicamente que su pareja BGP existe y desea mantener la relacin. Por tanto, se verifica que los routers BGP vecinos y sus conexiones de red funcionan correctamente. Deteccin de Red Alcanzable: Mediante esta funcin, se transmite al correspondiente vecino la informacin de acceso es decir, el anuncio o eliminacin de un destino o destinos finales. Para manejar las tres funciones anteriores, BGP hace uso de cuatro tipos de mensajes: Abrir (Open): Establece una relacin segura (autenticada) de vecindad con otro router BGP. Actualizar (Update): Transmite informacin de destinos finales (anunciar y eliminar) a travs de una nica ruta (lista de routers en frontera de SA). Continuar (Keepalive): Confirma un mensaje de Abrir y, adems, confirma peridicamente la relacin de vecindad para indicar que sta se mantiene viva. Notificacin (Notification): Responde a un mensaje incorrecto o a una condicin de error o excepcin. Segn se describe en la siguiente Figura 4.43, todo mensaje de BGP consta de una cabecera de tamao fijo de 19 octetos con los siguientes campos: Marcador (16 octetos): Reservado para proporcionar un servicio de autenticacin de lo mensajes BGP y detectar una prdida de sincronizacin entre una pareja de routers BGP. Si el mensaje es del tipo Abrir, el emisor puede insertar un valor183 que el receptor debe verificar para comprobar su identidad.
En lugar de hacer refrescos peridicos como se hace en RIP u OSPF. Esto reduce el uso del ancho de banda y el procesamiento suplementario.
183
182
Palabra clave o el resultado de una funcin hash como MD5 aplicada a un secreto compartido.
- 326 -
Esta campo contiene todo a unos si el mensaje de Abrir no transporta autenticacin Longitud: Especifica el nmero de octetos del mensaje. El valor del campo de longitud debe estar comprendido entre 19 y 4096 octetos. Tipo: Define cuatro clases de mensajes de BGP: Abrir (Open): Para la autenticacin con otro router externo e informar de la versin del protocolo (4) del numero de SA y establecer (negociar) unos parmetros operativos. Actualizar (Update): Para anunciar nuevos destinos y eliminar destinos previamente divulgados. Continuar (Keepalive): Para confirmar un mensaje de Abrir (Open) o de relacin de vecindad, la cual se va confirmando peridicamente. Notificacin (Notification): Para responder a mensajes incorrectos o a situaciones anmalas.
Continuar (Keepalive)
CABECERA FIJA DE 19 OCTETOS
16
MARCADOR
=
16
MARCADOR
2 1
LONGITUD TIPO
2 1
LONGITUD TIPO
Abrir (Open)
1 2 2 4 1 VERSIN MI SISTEMA AUTNOMO TIEMPO DE RELACIN
2 2
Actualizar (Update)
LONGITUD DE RUTAS RETIRADAS
RUTAS RETIRADAS
LONGITUD TOTAL DE LOS ATRIBUTOS DEL CAMINO
ATRIBUTOS DE CAMINO
INFORMACIN DE ACCESIBILIDAD DEL NIVEL DE RED
Notificacin (Notification)
1 1
CDIGO DE ERROR
SUBCDIGO DE ERROR
DATOS
IDENTIFICADOR BGP
LONG. PARM. OPCIONALES
PARMETROS OPCIONALES
Figura 4.43.- Formato de los mensajes BGP.
- 327 -
1. MENSAJE DE ABRIR (OPEN)
16
MARCADOR
2 1 1
LONGITUD TIPO = Abrir VERSIN
2 2
MI SISTEMA AUTNOMO TIEMPO DE RELACIN
Cuerpo (Abrir)
4 IDENTIFICADOR BGP
1 LONG. PARM. OPCIONALES PARMETROS OPCIONALES
Figura 4.44.- Formato del mensaje BGP de abrir (open). Es el primer mensaje (ver Figura 4.44) enviado por un router BGP despus de que se haya establecido la conexin del protocolo de transporte TCP. El objetivo de este tipo de mensaje es permitir la autenticacin de los mensajes intercambiados con otros routers BGP y establecer los siguientes parmetros operativos: Versin (1 octeto): Nmero de versin del protocolo BGP del mensaje. El nmero actual es 4. Mi Sistema Autnomo (2 octetos): Nmero de SA del router emisor. Tiempo de Relacin (2 octetos): Nmero mximo de segundos, propuesto por el router BGP emisor, que puede transcurrir entre la recepcin de mensajes sucesivos de Continuar (Keepalive) y/o Actualizar (Update). Cuando el receptor recibe el tiempo de relacin o mantenimiento indicado por el router emisor, calcula el valor de dicho tiempo en funcin del tiempo recibido en el mensaje de Abrir y del menor tiempo que tiene en su configuracin. Este tiempo puede ser igual a cero o, al menos, a tres segundos. Un valor igual a cero indica que no se deben intercambiar los mensajes indicados. Identificador BGP (4 octetos): Identifica el router BGP emisor cuando ste tiene ms de un interfaz o direccin IP. El valor (p.ej., la direccin IP ms alta) est determinado por una direccin IP de las interfaces locales del router BGP, y es la utilizada por todas las parejas, independientemente de interfaz utilizado para transmitir los mensajes BGP. Longitud de los Parmetros Opcionales (1 octeto): Nmero de octetos del campo de parmetros opcionales. Este campo est a cero si no hay parmetros opcionales.
- 328 -
Parmetros Opcionales: Campo de longitud variable que contiene una lista de parmetros opcionales codificados en una estructura TLV: Tipo, Longitud y Valor del parmetro. Actualmente, slo est definido un tipo de parmetro (Tipo de parmetro = 1) que contiene un campo de Cdigo de Autenticacin de 8 bits seguido por un campo de Datos de Autenticacin de longitud variable en funcin del Cdigo de Autenticacin indicado. En el supuesto de manejar como mecanismo de autenticacin la funcin hash MD5, en el primer campo (Cdigo de Autenticacin) ira el cdigo asociado al mecanismo empleado y en el siguiente campo (Datos de Autenticacin), el resultado de aplicar dicha funcin hash a un valor secreto y previamente conocido por las partes implicadas. La longitud mnima de un mensaje de Abrir (Open) es de 29 octetos (incluyendo la cabecera del mensaje). Una vez un router BGP transmite el mensaje de Abrir y ste se acepta en el otro extremo de la conexin TCP, entonces el router remoto enva un mensaje de Continuar como mensaje de confirmacin. Despus de que el mensaje de Abrir ha sido confirmado, seguidamente, se transmiten los mensajes de Actualizar, Continuar y Notificacin. 2. MENSAJE DE ACTUALIZAR (UPDATE)
16
MARCADOR
2 1
2
LONGITUD TIPO = Actualizar LONGITUD DE RUTAS RETIRADAS

RUTAS RETIRADAS
Cuerpo (Actualizar)
LONGITUD TOTAL DE LOS ATRIBUTOS DELCAMINO
... Camino_SA: Los SA que se han atravesado para recibir este mensaje de actualizacin. I Siguiente_Salto: Direccin IP del siguiente Router en frontera de SA por el que se debe pasar para llegar al destino especificado en el campo NLRI. ...
ATRIBUTOS DEL CAMINO

INFORMACIN DE ACCESIBILIDAD DEL NIVEL DE RED
NLRI (Network Layer Reachibility Information )= Redes Destinatarias
Figura 4.45.- Formato del mensaje BGP de actualizar (update). Mediante este tipo de mensaje (ver Figura 4.45), y una vez se ha establecido la correspondiente conexin BGP, las parejas intercambian informacin de
- 329 -
encaminamiento para anunciar nuevos destinos y eliminar destinos previamente divulgados, construyendo un grafo de conectividad de SA. Mediante este mensaje se puede anunciar una nica ruta y/o eliminar una lista de rutas. Un mensaje de actualizar puede contener la siguiente informacin: Longitud de rutas retiradas (2 octetos): Nmero de octetos del campo de rutas retiradas. Si un router no desea eliminar ninguna ruta, entonces, este campo est a cero y el campo de rutas retiradas no est presente. Rutas retiradas: Campo de longitud variable que indica una lista de prefijos (longitud/prefijo) de direcciones de IP que se corresponden con las rutas que deben eliminarse de las tablas de encaminamiento BGP. Longitud de los atributos del camino (2 octetos): Nmero de octetos del campo de atributos del camino. Si este campo est a cero, entonces, el campo de atributos del camino no est presente. Atributos del Camino: Campo de longitud variable de atributos del camino. Estos atributos describen las caractersticas de las rutas y se utilizan para modificar el comportamiento del encaminamiento. Cada atributo viene definido por una estructura: Tipo, Longitud y Valor del atributo. A su vez, en el Tipo de atributo aparecen los siguientes campos ms significativos: O (1 bit): Es el bit Opcional (y de mayor orden) e indica si el atributo es opcional (O = 1) o bien-conocido (O = 0) por todos los interlocutores BGP. ... E (1 bit): Es el bit de longitud Extendida e indica si la longitud de un atributo es de un octeto (E = 0) o dos octetos (E = 1). En el ltimo caso (E = 1), la longitud del atributo es de ms de 255 octetos. ... Cdigo de Tipo del Atributo: Contiene el cdigo del atributo. Los cdigos definidos son los siguientes: Origen (cdigo tipo = 1): Es un atributo bien-conocido (wellknown) y obligatorio que define el origen de la informacin de accesibilidad del nivel de red (NLRI: Network Layer Reachability Information), es decir, la fuente de informacin de las redes destinatarias. En funcin del origen de la informacin de - 330 -
accesibilidad NLRI, el valor del atributo puede tener uno de los siguientes tres valores: 0: El origen de la informacin fue un protocolo IGP del SA original. 1: El origen de la informacin fue el protocolo BGP. 2: La informacin se ha aprendido por otros medios.
Camino_SA (cdigo tipo = 2): Es un atributo bien-conocido (well-known) y obligatorio que especifica la ruta o secuencia de los SA que se han atravesado para recibir este mensaje de actualizacin. Cuando un interlocutor de BGP origina la ruta, ste incorpora su nmero de SA cuando enva la ruta a sus parejas externas. Cuando un interlocutor de BGP propaga una ruta que ha aprendido de otro interlocutor de BGP, el locutor propagador incorpora su propio nmero de SA en la primera posicin de la secuencia de la lista Camino_SA. BGP utiliza el atributo Camino_SA para detectar bucles potenciales. Como ya se ha comentado, si el nmero de SA del interlocutor de BGP est ya contenido en la lista de nmeros SA, esa ruta ya ha pasado por all y, por lo tanto, se debe eliminar. Cuando un cliente utiliza un nmero de SA privado (64512-65535), el ISP debe asegurarse de que ha eliminado dicho nmero de la lista Camino_SA, ya que estos nmeros no son globalmente nicos. Siguiente_Salto: Es un atributo bien-conocido (well-known) y obligatorio que especifica la direccin IP del siguiente Router en frontera de SA por el que se debe pasar para llegar al destino especificado en el campo de NLRI. Informacin de Accesibilidad del Nivel de Red (NLRI: Network Layer Reachability Information): Campo de longitud variable que contiene una lista de prefijos de direcciones de IP (segn el formato: longitud, prefijo) de redes destinatarias que se alcanzan por la ruta especificada. Si el campo de NLRI est presente, el campo de Longitud Total de los Atributos del Camino indica, en octetos, la longitud total del campo de Atributos del Camino. En caso contrario, este campo vale cero, lo que indica que no se anuncian rutas.
- 331 -
3. MENSAJE DE CONTINUAR (KEEPALIVE)
16
MARCADOR
2 1
LONGITUD TIPO = Continuar
Figura 4.46.- Formato del mensaje BGP de continuar (keepalive). Este mensaje (ver Figura 4.46) se utiliza en los siguientes dos casos: Para confirmar un mensaje de Abrir. Para confirmar peridicamente la relacin de vecindad: Los interlocutores BGP monitorizan continuamente la alcanzabilidad de sus parejas mediante el intercambio peridico de este tipo de mensajes. Estos mensajes se intercambian con frecuencia para evitar que expire el temporizador del Tiempo de Relacin. Un tiempo recomendado entre sucesivos mensajes de continuar es un tercio del intervalo del Tiempo de Relacin. Este valor asegura que los mensajes de Continuar lleguen al router receptor casi siempre antes de que expire el temporizador del Tiempo de Relacin, incluso si el retardo de transmisin de TCP es variable. Si el Tiempo de Relacin es cero, los mensajes de Continuar no se transmiten. El formato del mensaje de Continuar es exactamente la cabecera comn de BGP con el campo de Tipo especificando la clase del mensaje (Continuar o tipo = 4).
- 332 -
4. MENSAJE DE NOTIFICACIN (NOTIFICATION)
16
MARCADOR
2 1 1 1
LONGITUD TIPO= Notificacin CDIGO DE ERROR SUBCDIGO DE ERROR DATOS
Cuerpo (Notificacin)
Figura 4.47.- Formato del mensaje BGP de notificacin (notification). Este mensaje se transmite cuando se recibe, a su vez, un mensaje incorrecto o una condicin de error o excepcin. Despus de que el correspondiente interlocutor de BGP haya transmitido dicho mensaje, libera la conexin TCP. El cuerpo del mensaje tiene los siguientes campos: Cdigo de Error: Especifica el tipo de error. Error en la cabecera del mensaje. Error en el mensaje de Abrir. Error en el mensaje de Actualizar. Vencimiento del temporizador del Tiempo de Relacin. ... Subcdigo de Error: Proporciona una informacin ms especfica sobre la naturaleza del error. Por ejemplo, un error en el mensaje de Abrir puede estar motivado por un nmero no soportado de versin. Datos: Describe la razn de la notificacin. El contenido depende del Cdigo y Subcdigo de Error. La longitud mnima de un mensaje de Notificacin es de 21 octetos. - 333 -
RFC- 2080: RIPng for IPv6 RFC-2740: OSPF for IPv6 RFC-2545: BGP-4 for IPv6
Figura 4.48.- Protocolos para el encaminamiento dinmico de IPv6. Por ltimo, se vuelve a recordar que los protocolos estudiados hasta el momento se utilizan para facilitar el encaminamiento de IPv4. Para la distribucin y actualizacin de la informacin de encaminamiento manejada por las entidades IPv6 existen a su vez unas extensiones de los mismos protocolos cuyos documentos RFC se indican en la Figura 4.48.
- 334 -
4.2

Bibliografa
RFC-1930: Guidelines for creation. selection, and registration of an Autonomous System (AS). RFC-2270: Using a Dedicated AS for Sites Homed to a Single Provider. http://www.cisco.com/: IGRP y EIGRP. RFC-1195: Use of OSI IS-IS for routing in TCP/IP and dual environments. RFC-1058: Routing Information Protocol. RFC-2453: RIP Version 2. RFC-1724: RIP Version 2 MIB Extension. RFC-2080: RIPng for Ipv6, 1997. RFC-2328: OSPF Version 2. RFC-1245: OSPF Protocol Analysis. RFC-1246: Experience with the OSPF Protocol. RFC-1850: OSPF Version 2 Management Information Base. RFC-2740 : OSPF for IPv6 RFC-1771: A Border Gateway Protocol 4 (BGP-4). RFC-1772: Application of the Border Gateway Protocol in the Internet. RFC-1773: Experience with the BGP-4 protocol. RFC-1403: BGP OSPF Interaction. RFC-2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, 1999. TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Redes Globales de Informacin con Internet y TCP/IP, Principios bsicos, protocolos y arquitectura, Douglas E. Comer, 3 Edicin, Prentice Hall, 1996. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000. TCP/IP Illustrated Volume 1: The Protocols, R.W. Stevens, Addison-Wesley, 1994. Comunicaciones y Redes de Computadores, W. Stallings, 6 Edicin, Prentice Hall, 1997. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. TCP/IP Arquitectura, protocolos e implementacin con IPv6 y seguridad de IP; Dr. Sydney Feit, Osborne McGraw-Hill, 1998.
- 335 -
- 336 -
Captulo 5. Encaminamiento Dinmico de Multidifusin
5. ENCAMINAMIENTO MULTIDIFUSIN
DINMICO
DE
Los protocolos de distribucin y actualizacin de la informacin de encaminamiento estudiados, hasta ahora, se utilizan para el encaminamiento IP de aquellas aplicaciones TCP/IP que hacen uso de transmisiones de unidifusin en donde un origen transmite sus datagramas a un nico destino. Pero existen aplicaciones184 que necesitan transmitir simultneamente datagramas a mltiples destinos, es decir, a un nmero de receptores superior a uno y, adems, sin necesidad de enviar desde el origen una misma informacin por separado a cada miembro del grupo. Para estos casos existen unos protocolos que facilitan el encaminamiento IP dinmico de multidifusin y que estn basados en diferentes algoritmos o estrategias de encaminamiento. A continuacin, y para una mayor comprensin, se resume la problemtica del encaminamiento de multidifusin antes de analizar tanto los algoritmos empleados como los protocolos ms relevantes que hacen uso de ellos.
5.1 El problema del encaminamiento de multidifusin

A B
Router de multidifusin Mquina de Grupo
G1
Mquina de Grupo
G2
Figura 5.1.- Un ejemplo de un escenario de multidifusin.

184
Por ejemplo, aplicaciones multimedia en tiempo real: audioconferencias y videoconferencias.
- 337 -
La anterior Figura 5.1 describe el problema fundamental de este tipo de encaminamiento. En ella se muestran seis routers de multidifusin (A, B, C, D, E y F) y los sistemas finales pertenencientes a los grupos de multidifusin G1 o G2. Se considera que slo los routers que estn conectados directamente a las mquinas del grupo G1 (A, B, E y F) pueden enviar y recibir trfico dirigido a dicho grupo. Por consiguiente, slo un subconjunto (A, B, E y F) del total de routers (A, B, C, D, E y F) necesita recibir trfico de multidifusin (A, B, E y F). Consecuentemente, ni C ni D tienen necesidad de recibir dicho trfico. En este escenario, el objetivo del encaminamiento de multidifusin es encontrar un rbol de enlaces o rbol de multidifusin que conecte a todos los routers de multidifusin con mquinas pertenecientes al grupo de multidifusin al cual se va a dirigir el correspondiente trfico. Obviamente, el rbol puede contener routers que no estn directamente conectados a mquinas del grupo en cuestin. ste es el caso de los routers C y D ya que es imposible conectar a los routers A, B, E y F en un mismo rbol sin implicar a C y/o D. En la prctica, hay bsicamente dos soluciones para determinar el rbol del encaminamiento de multidifusin en funcin de si se usa un nico rbol compartido de grupo para la distribucin del trfico procedente de todos los orgenes o emisores185 del grupo; o bien se usa como alternativa un rbol especfico en funcin de un origen186 en particular y, por tanto, diferente e independiente para cada potencial emisor.
5.1.1 Un rbol de grupo compartido por todos los orgenes

En esta primera solucin, todos los datagramas transmitidos a un grupo en particular se encaminan, independientemente del origen (router origen de la multidifusin), por el mismo y nico rbol de multidifusin. Por tanto, hay que encontrar un rbol dentro de la red que conecte a todos los routers de multidifusin con al menos una mquina pertenenciente al grupo de destino.
185
Routers orgenes de la multidifusin. Router origen de la multidifusin.
186
- 338 -
G1
Mquina de Grupo
G2
Figura 5.2.- Un nico rbol compartido calculando las rutas ms cortas. En la Figura 5.2 se muestra, a travs de enlaces gruesos o ms resaltados, el rbol compartido187 del grupo de multidifusin G1. Dicho rbol est compuesto por cuatro routers conectados a mquinas de G1 (A, B, E y F) y un router que no lo est (C). El rbol en cuestin se ha obtenido188 calculando las rutas ms cortas o con menos enlaces o saltos o routers encontrados segn una estrategia del vector de distancia. Este rbol debe conectar a todos los routers de multidifusin con miembros activos de G1 (A, B, E y F), aunque haya que pasar por routers de multidifusin sin miembros de G1 (C). Todo ello, sin que exista ms de un camino (con uno o ms enlaces) conectando dos routers de multidifusin cualesquiera. Alternativamente, y segn se describe en la siguiente Figura 5.3, se puede calcular el rbol compartido en funcin de las rutas de coste mnimo o lo que es lo mismo en funcin de una estrategia de estado del enlace. Dicho rbol189 est compuesto por cuatro routers que estn conectados a mquinas de G1 (A, B, E y F) y un router que no lo est (D). En este caso, se calculan las rutas de coste mnimo que conecten a todos los routers de multidifusin con miembros activos de G1 (A, B, E y F), aunque haya que pasar por routers de multidifusin sin miembros de G1 (D). Todo ello, al igual que en el caso anterior, sin que exista ms de un camino (con uno o ms enlaces) conectando dos routers de multidifusin cualesquiera.
187
Por los routers orgenes de multidifusin: A, B, E y F. Se podra haber obtenido otros rboles similares tambin con slo cuatro enlaces implicados. El rbol resultante es el que tiene menor coste al sumar los costes de los enlaces implicados.
188
189
- 339 -
A
4
F
1
G1
Mquina de Grupo
G2
Figura 5.3.- Un nico rbol compartido calculando las rutas de coste mnimo. El problema de encontrar un rbol de coste mnimo se conoce como el problema del rbol de Steiner cuyo algoritmo difiere del ya estudiado en el estado del enlace a travs del algoritmo de Dijkstra. El clculo de Dijkstra consiste en encontrar un rbol diferente para cada origen con los caminos con menor coste a cada destino. El algoritmo de Steiner se basa en encontrar un mismo rbol de multidifusn compartido por todos los orgenes. Por consiguiente, el clculo de Steiner consiste en encontrar el rbol compartido de menor coste en funcin de sumar los costes de los enlaces que pasen por todos los routers con miembros activos del grupo de destino. En el clculo anterior, el rbol puede estar formado por enlaces que pasen por routers de multidifusin sin miembros del grupo de destino; pero que es obligado pasar por ellos para llegar al resto de los routers de multidifusin con miembros activos del grupo en cuestin. Este es el caso de los enlaces B-D y E-D para el router D en la Figura 5.3. En dicha Figura 5.3, el lector puede intentar buscar algn otro rbol que conecte a los routers A, B, E y F con una suma de coste igual o inferior a 7 (4+1+1+1) y ver que no existe. Otra alternativa al rbol de Steiner se basa en el concepto de nodos centrales de multidifusin formando una red troncal de compartida por todos los orgenes de multidifusin. Aquellos routers que dispongan de miembros activos de un grupo de multidifusin deben solicitar a un nodo central190 de dicha red troncal, mediante los mensajes de unidifusin oportunos, que se les conecte al rbol compartido de multidifusin.
190
Seguramente el ms cercano.
- 340 -
Ejemplos de rboles compartidos por todos los orgenes son los algoritmos del rbol de expansin (spanning tree) y rboles basados en ncleos (Core-Based Trees: CBT) que se analizarn seguidamente.
5.1.2 Un rbol de grupo basado en el origen

Esta segunda solucin se fundamenta en la creacin de un rbol del encaminamiento de multidifusin diferente para cada origen. Es importante resaltar que esta solucin sigue el algoritmo de estado del enlace (algoritmo de Dijkstra) en donde cada router de multidifusin se coloca en la raz de su rbol con los caminos de menor coste a cada destino. Ejemplos de rboles diferentes para cada origen son los algoritmos de difusin por el camino inverso (Reverse Path Broadcasting: RPB), difusin por el camino inverso truncado (Truncated- RPB: TRPB) y multidifusin por el camino inverso (Reverse Path Multicast: RPM) que se estudiarn a continuacin.
5.2 Algoritmos para envos de multidifusin

Como se mencion en su momento, el protocolo IGMP no est relacionado con la entrega de datagramas de multidifusin entre routers contiguos o vecinos en una red de redes. Quiere esto decir que, para proporcionar un servicio de entrega por Internet, es necesario definir una serie de protocolos de encaminamiento de multidifusin. Estos protocolos deben ser responsables de la construccin de los correspondientes rboles de entrega de datagramas mediante el uso de algoritmos para envos de multidifusin. Entre los algoritmos ms representativos propuestos para los citados protocolos se destacan los siguientes:
5.2.1 Inundacin (Flooding)

Es el algoritmo ms sencillo y conocido. Cuando un router recibe un datagrama dirigido a un grupo de multidifusin, determina si es la primera vez que le ha llegado. Si es as, lo enva por todas sus interfaces exceptuando el interfaz por el que lleg. En caso contrario, lo descarta.
- 341 -
Mquina de Grupo
R6
R7
Mquina de Grupo
G1
R2
2 2
G2
R8
ORIGEN
R1
Mquina de Grupo
R3
R5
G1
R9
3
G1
1
Mquina de Grupo
R4
2
G2
Routers: R1, R2, R3,, R9 Datagrama
Mquina de Grupo
G3
Figura 5.4.- Un ejemplo del algoritmo de inundacin. En la Figura 5.4, los nmeros de las flechas indican las secuencias del datagrama en cada salto. R4, R7 y R9 no reenvan datagramas porque va IGMP saben que en su enlace no hay miembros del grupo G1. El algoritmo de inundacin para envos de multidifusin es muy fcil de implementar ya que un router no tiene que mantener una tabla de encaminamiento, y slo necesita tener constancia de los datagramas que han pasado recientemente por l. El inconveniente es que es un algoritmo poco escalable puesto que se pueden generar muchos datagramas duplicados con el correspondiente consumo de ancho de banda.
5.2.2 rbol de expansin (Spanning Tree)

Una solucin ms efectiva que la vista anteriormente, a travs del algoritmo de inundacin, es la basada en seleccionar un subconjunto de la topologa completa de Internet mediante un rbol de expansin que define una estructura arborescente (tree structure) en la cual slo existe un camino191 activo que conecte dos routers de multidifusin cualesquiera para cada par (origen-destino). Exceptuando el interfaz de llegada, cada router de multidifusin enva los datagramas recibidos a travs de los interfaces que forman parte del citado rbol. Un problema asociado con este algoritmo es que centraliza el trfico en un pequeo nmero de enlaces, pudiendo no incluir el camino ms eficiente entre el origen y los correspondientes miembros del grupo. La
191
Formado por uno o ms enlaces.
- 342 -
implementacin de este algoritmo es relativamente sencilla de llevar a cabo por la experiencia que hay en Internet con protocolos basados en dicho algoritmo. Asimismo, se resalta que se utiliza en los puentes transparentes de las redes de rea local IEEE 802.3192.
Mquina de Grupo
R6
R7
Mquina de Grupo
G1
R2
G2
R8
ORIGEN
Mquina de Grupo
R1
R3
R5
G1
R9 G1
Mquina de Grupo
R4
G2
Routers: R1, R2, R3,, R9 Rama inactiva Rama activa Mquina de Grupo Datagrama
G3
Figura 5.5.- Un ejemplo del algoritmo del rbol de expansin. Como se puede apreciar en la Figura 5.5, el router R2 no enva el datagrama por el enlace R2-R5 porque ya existe el camino R2-R1-R3-R5 entre R2 y R5. Asimismo, el router R4 no enva, a su vez, el datagrama por el enlace R4-R5 porque ya existe el camino R4-R1-R3-R5 entre R4 y R5. Aunque la Figura 5.5 muestra el rbol del encaminamiento de multidifusin para el origen R1, ste es el mismo para el resto de potenciales orgenes (R6 y R8). Consecuentemente, los enlaces en grueso o ms resaltados se corresponden con el nico rbol de grupo compartido por todos los orgenes: R1, R6 y R8.
5.2.3 Difusin por el camino inverso (Reverse Path Broadcasting: RPB)

Otra solucin alternativa a la construccin de un nico rbol de expansin (spanning tree) para toda la red Internet, consiste en construir un rbol de expansin por cada par (origen, grupo). Se define como raz del mismo, un router conectado al enlace que contiene al origen. Debido a que, potencialmente, puede haber muchos orgenes para un determinado grupo, se construye un rbol de expansin diferente para cada par (origen,
192
MAC-layer Spanning Trees.
- 343 -
grupo). Al algoritmo fundamental que crea estos rboles, se le denomina Difusin por el Camino Inverso o RPB (Reverse Path Broadcasting) y es una modificacin del rbol de expansin (spannig tree). Segn se muestra en la Figura 5.6, este algoritmo se fundamenta en que el conjunto de caminos ms cortos desde los routers conectados directamente a miembros activos de un grupo hacia un origen forman un rbol de expansin por el camino ms corto.
RBOL DEL CAMINO MS CORTO A R6

R2 R3 R4 R6 R5
R2 R3 R4 R6
R1
R1
R5
Routers: R1, R2, R3,, R6
Figura 5.6.- Fundamento operativo de RPB. Ms en concreto su funcionamiento se basa en que: Cuando un router recibe un datagrama de multidifusin, registra la direccin de origen de dicho datagrama y el interfaz por donde ha llegado. Para cada par (origen, grupo), si un datagrama llega por un enlace (enlace padre) a un router (Ri) y ste tiene constancia de que existe, por otro enlace suyo (enlace hijo), un router vecino (Ri+1) que considera a dicho enlace (enlace hijo de Ri) como su enlace padre193 para el origen considerado; entonces el anterior router (Ri) enva el datagrama en cuestin por ese interfaz (que le une con Ri+1) y por todos194 los interfaces de salida (enlaces hijos) excepto por el de llegada. En caso contrario descarta dicho datagrama.
193
Es decir, considera que es el camino de regreso ms corto hasta el origen del datagrama. Si se cumple lo anterior.
194
- 344 -
El enlace por donde el router espera recibir datagramas de multidifusin procedentes de un determinado origen se denomina enlace padre. El enlace por donde el router enva datagramas de multidifusin se denomina enlace hijo. Una mejora a este algoritmo consiste en no difundir el datagrama por aquellos enlaces hijos que no son considerados, por los routers vecinos, enlaces padre para el origen en cuestin. Por consiguiente, si un router observa que un router vecino, unido por un enlace hijo, considera que dicho enlace es un enlace padre para el correspondiente par (origen, grupo), enva el datagrama por dicho enlace. En caso contrario, no lo utiliza, dado que el router vecino lo va a descartar ms tarde. La ventaja de RPB es que los bucles en el encaminamiento se suprimen y cada datagrama se reenva por un router una sola vez. El algoritmo RPB parte del hecho de que el camino ms corto desde un origen a un router es el mismo que desde el router al origen. Por tanto, asume que cada enlace es simtrico (mismo coste). Si el enlace no fuera simtrico, el router debe calcular el camino ms corto desde el origen al router mediante un protocolo basado en el estado del enlace. En la Figura 5.7, el router R2 no enva el datagrama al router R5 por el enlace R2-R5, porque tiene un conocimiento previo de que dicho enlace no es un enlace padre para R5 con respecto al origen, es decir, no pertenece al camino de regreso ms corto desde R5 hasta el origen (existe ya un camino, R5-R3-R1, en este caso con el mismo nmero de enlaces o saltos). Asimismo, el router R4 no enva, a su vez, el datagrama al router R5 por el enlace R4-R5, porque tambin tiene conocimiento de que dicho enlace no es un enlace padre para R5 con respecto al origen, es decir, no pertenece al camino de regreso ms corto desde R5 hasta el origen (existe ya un camino, R5-R3-R1, tambin con el mismo nmero de enlaces o saltos).
Mquina de Grupo
R6
R2
R7
Mquina de Grupo
G1
G2
R8
ORIGEN
Mquina de Grupo
R1
R3
R5
G1
R9 G1
R4
Mquina de Grupo
G2
G3
Figura 5.7.- Un ejemplo del algoritmo RPB. - 345 -
Una de las mayores limitaciones del algoritmo RPB es que no tiene en cuenta la pertenencia a un grupo de multidifusin cuando construye el rbol de distribucin para un par (origen, grupo). Consecuentemente, si no hay constancia de que exista un camino entre dos routers, se pueden enviar los datagramas por enlaces que no tienen pertenencias con el correspondiente grupo de destino. En el ejemplo de la anterior Figura 5.7, los routers R4 y R7 pertenecen a diferentes grupos de multidifusin y, sin embargo, reciben datagramas directamente de R1 y R2, respectivamente. Quiere esto decir, que se gasta un ancho de banda innecesario, independientemente del grupo de multidifusin.
5.2.4 Difusin por el camino inverso truncado (Truncated- RPB: TRPB)

Este algoritmo fue desarrollado para superar las limitaciones de RPB. Con la ayuda del protocolo IGMP, los routers de multidifusin determinan en un primer momento los grupos activos en cada enlace hoja y, por tanto, evitan posteriormente el envo de datagramas de multidifusin a aquellos enlaces que no tienen miembros activos del grupo al que van dirigidos dichos datagramas. Consecuentemente, el truncamiento slo se realiza en los routers hojas es decir en aqullos que estn conectados directamente a enlaces hojas. El procedimiento operativo de este algoritmo consiste en una difusin previa inundando a todos los routers hojas con al menos un datagrama para posteriormente mandar una informacin de poda (enlace podado) desde el router hoja hasta el router padre. Como se muestra en la Figura 5.8, el router R2 no enva el datagrama al router R7 porque no hay ningn miembro activo del grupo G1 en el enlace de R7 (enlace hoja). Por la misma razn, R5 tampoco transmite a R9. A su vez, R1 tampoco enva el datagrama al router R4 porque no hay ningn miembro activo del grupo G1 en el enlace de R4 (enlace hoja).
Mquina de Grupo
R6
R2
R7
Mquina de Grupo
G1
G2
R8
ORIGEN
Mquina de Grupo
R1
R3
R5
G1
Mquina de Grupo
R9
R4
Mquina de Grupo
G1
G2
G3
Figura 5.8.- Un ejemplo del algoritmo TRPB. - 346 -
5.2.5 Multidifusin por el camino inverso (Reverse Path Multicast: RPM)

Este algoritmo es una mejora del TRPB en el sentido de que se adapta a los envos de multidifusin basados en el origen. A diferencia de TRPB que realiza el truncamiento slo en los routers hojas (conectados directamente a enlaces hojas), RPM (Reverse Path Multicast) enva un datagrama de multidifusin slo a aquel router que es capaz de transmitirlo a un router hoja con miembros de grupo. Por cada par (origen, grupo) se crea un rbol de expansin cuyas ramas abarcan tan solo: Enlaces con miembros del grupo Routers y enlaces pertenecientes al camino ms corto hacia enlaces que contengan miembros del grupo El procedimiento operativo de este algoritmo consiste en una difusin previa inundando a todos los routers hojas para posteriormente mandar una informacin de poda desde el router hoja hasta el router origen. En este contexto, y en sentido contrario al flujo de datagramas, se produce una poda sucesiva (upstream) hacia el origen de routers conectados a enlaces sin miembros activos del grupo considerado, Ms en concreto, el procedimiento operativo de este algoritmo es como sigue: Cada router reenva el primer datagrama para una pareja (origen, grupo). Todos los routers hojas reciben al menos el primer datagrama de multidifusin. Si un router hoja no encuentra un miembro para ese grupo en ninguno de sus interfaces, entonces enviar, hacia arriba, un mensaje de poda dando instrucciones a los pertinentes routers para que no reenven los datagramas siguientes de la pareja (origen, grupo) en cuestin. Consecuentemente, si un router padre recibe un mensaje de poda de todos sus routers hijos transmitir, a su vez, un mensaje de poda a todos sus routers padres.
Mquina de Grupo
R6
R2
R7
Mquina de Grupo
G1
G2
R8
ORIGEN
Mquina de Grupo
R1
R3
R5
G1
Mquina de Grupo
R9
R4
Mquina de Grupo
G1
Routers: R1, R2, R3,, R9 Rama podada Rama inactiva Rama activa Datagrama
Mquina de Grupo
G2
G3
Figura 5.9.- Un ejemplo del algoritmo RPM. - 347 -
Teniendo en cuenta que en un principio todos los routers hojas reciben al menos el primer datagrama de multidifusin; en la anterior Figura 5.9 el router R4 enva, a los routers R1 (raz) y R5, un mensaje de poda para mquinas que sean del grupo G1. Cuando R1 recibe este mensaje, deja de reenviar los datagramas de multidifusin siguientes por el interfaz hacia R4, es decir, el enlace R1-R4 es un enlace podado (rama podada del rbol). Asimismo, el router R9 enva un mensaje de poda a R5. Sin embargo, R5 no sigue transmitiendo hacia arriba dicho mensaje de poda porque tiene un enlace hacia R8 que es un router hoja con un miembro activo de G1. El enlace R5R9 se considera tambin un enlace podado (rama podada del rbol). A su vez, el enlace R2-R5 es un enlace inactivo (rama inactiva del rbol) porque R2 tiene constancia de que existe un camino ms corto de regreso o con el mismo nmero de saltos) desde R5 hasta el origen. Asimismo, el enlace R4-R5 se considera tambin inactivo porque, a su vez, R4 tiene constancia de que existe un camino ms corto de regreso o con el mismo nmero de saltos) desde R5 hasta el origen. Se recuerda que R4 mand a R1 un mensaje de poda por el enlace R1-R4 para mquinas del grupo G1; pero por dicho enlace pueden ir datagramas para otros grupos (G3 y G2). Finalmente, el router R7 enva un mensaje de poda a R2; sin embargo, R2 no sigue transmitiendo hacia arriba dicho mensaje de poda porque tiene un enlace hacia R6 que es un router hoja. Consecuentemente, el enlace R2-R7 se considera tambin un enlace podado (rama podada del rbol).
Mquina de Grupo
R2
R7
Mquina de Grupo
G1
R5
G1
R9
ORIGEN
Mquina de Grupo
R1
R4
R8
G1
Mquina de Grupo
R10 Mquina de Grupo
G1
R3
R6
Mquina de Grupo
G1
Routers: R1, R2, R3,, R9 Rama podada Rama inactiva Rama activa Datagrama
G2
Mquina de Grupo
G2
Figura 5.10.- Otro ejemplo del algoritmo RPM. Otro ejemplo de escenario de aplicacin del algoritmo RPM es el que se muestra en la Figura 5.10, en la cual el router R3 enva un mensaje de poda a los routers R1 y R4. - 348 -
Cuando R1 recibe este mensaje, deja de reenviar los datagramas de multidifusin siguientes por el interfaz hacia R3. El enlace R1-R3 en un enlace podado. A su vez, R6 enva un mensaje de poda a R4 y R5. Cuando R4 tiene constancia de que ha recibido mensajes de poda en todos sus routers hacia abajo (R3 y R6), transmite un mensaje de poda a R1, el cual deja de reenviar datagramas a R4. Los enlaces R4-R3, R4-R6, R5-R6 y R1-R3 son enlaces podados. A su vez, los enlaces R2-R7, R2-R5 y R7-R8 son enlaces inactivos porque existen ya otros caminos de regresos ms cortos (o con el mismo nmero de saltos) hasta el origen desde R7, R5 y R8 respectivamente. Cada informacin de poda se registra en un router durante un determinado tiempo. Cuando expira un temporizador de cancelacin, dicho router elimina la informacin y comienza a reenviar datagramas de multidifusin a sus vecinos flujo abajo. Asimismo, el algoritmo contempla un injerto de ramas podadas, de tal forma que una mquina puede unirse a un grupo de multidifusin despus de que un router hoja haya enviado un mensaje de poda. En este caso, el router hoja enviara hacia arriba un mensaje de injerto a su router vecino para anular un mensaje de poda previo. Cuando recibe el mensaje de injerto, el primer router flujo arriba enviar los datagramas de multidifusin siguientes a este router. Si el primer router flujo arriba tambin envi un mensaje de poda, el siguiente router har lo propio y as sucesivamente. Finalmente, un router en el rbol de multidifusin reactivar sus interfaces afectados para que los datagramas de multidifusin viajen flujo abajo hacia la pertinente mquina de grupo. Una desventaja seria de este algoritmo es que no es conveniente inundar a todos los routers hojas de Internet con el primer datagrama de multidifusin para una pareja (origen, grupo). Aunque tambin es verdad que la reinundacin peridica debida a los mecanismos de estado flexible asociados con la informacin de poda proporciona una solucin al problema.
5.2.6 rboles basados en ncleos (Core-Based Trees: CBT)

Este algoritmo construye, por cada grupo, un nico rbol de envo basado en ncleos y compartido por todos los miembros del grupo en cuestin. Un ncleo es un router CBT (Core-Based Trees) que entiende un protocolo basado en el algoritmo CBT, el cual se fundamenta, a su vez, en otro utilizado en la construccin de rboles de expansin (spanning tree). Por tanto, ambos son similares con la diferencia de que CBT permite crear un mismo rbol basado en ncleos para cada grupo e independientemente del origen. Quiere decir esto, que el trfico de multidifusin para cada grupo se enva y recibe por el mismo rbol de entrega o distribucin, es decir, hay un mismo rbol por grupo sin importar el nmero de orgenes.
- 349 -
Un ncleo CBT o troncal CBT puede incluir uno o ms routers de ncleo y cero, uno o ms routers195 que no son de ncleo. A su vez, cada grupo est soportado por uno o ms routers de ncleo, y un router de ncleo puede servir a mltiples grupos. En la Figura 5.11 se muestra, como ejemplo, una regin196 CBT con un conjunto de cuatro routers de ncleo, cada uno de ellos sirviendo a su propio conjunto de grupos.
Regin CBT
G2
G3
G1 G8 G9 G6
G5 G4
G7
Router de ncleo
Figura 5.11.- Un ejemplo de regin CBT. Se deja a la eleccin del protocolo que implementa este algoritmo, decidir si se desarrolla un mecanismo que descubra esttica o dinmicamente los grupos conocidos en cada uno de los ncleos. Como se coment con anterioridad, el algoritmo CBT permite crear un mismo rbol basado en ncleos para cada grupo e independientemente del origen. En este escenario, un ncleo o troncal CBT es la base para la creacin del citado rbol.
195
Todos los routers, ya sean de ncleo o no, son de multidifusin.
Se entiende por regin CBT, un conjunto de routers controlados por una nica autoridad administrativa y que utilizan un mismo protocolo CBT.
196
- 350 -
R4
Informe IGMP
R1 Solicitud R2 Solicitud
CBT CBT OK! OK!
R3
Primer Router CBT
Router de ncleo
Router de multidifusin
Informe IGMP Informe IGMP de pertenencia Solicitud CBT Solicitud CBT de pertenencia OK!
Confirmacin a la Solicitud CBT de pertenencia Troncal CBT
Figura 5.12.- Ejemplo de la progresin de una solicitud de CBT de pertenencia. Cuando una mquina desea unirse a un grupo se establece un procedimiento de solicitud basado en un envo de unidifusin dirigido al rbol de ncleos del correspondiente grupo de multidifusin. Para ello, el router local de multidifusin conectado a la misma red de acceso debe conocer la direccin de uno de los routers de ncleo del citado rbol. En concreto y como muestra la Figura 5.12, cuando una mquina A desea unirse a un nuevo grupo de multidifusin para recibir trfico dirigido a dicho grupo; enva a su router local de multidifusin R1, un informe IGMP (tipo 2) de pertenencia a grupo (Host Membership Report) con la direccin de destino IP que contiene la direccin de multidifusin del citado grupo. Seguidamente, en un mensaje especfico definido por el protocolo que implementa el algoritmo CBT, el router R1 transmite la informacin anterior a un router de ncleo que conozca197, por ejemplo, R4. Se resalta el hecho de que R1 debe conocer previamente la direccin IP de un router de ncleo para poder encaminar el mensaje CBT a dicho router. El citado mensaje se encamina hacia R4 transitando por los routers R2 y R3. Por tanto, dicho mensaje lo van procesando todos los routers intermedios de multidifusin198 que identifican el interfaz por el que se ha
197
Generalmente, el ms cercano.
Se recuerda que todos los routers son, al menos, de multidifusin ya que deben manejar, valga la redundancia, direcciones origen-destino de multidifusin.
198
- 351 -
recibido hasta llegar a R3. En este caso, R3199 se considera que es el primer router de multidifusin dentro del ncleo o troncal perteneciente al rbol CBT.
Cada datagrama de multidifusin se transmite por unidifusin hasta el primer router perteneciente al CBT, a partir del cual se enva mediante multidifusin por las pertinentes interfaces
Datagrama de multidifusin de entrega para un grupo

Primer Router CBT
unidifusin
Router de ncleo Router de multidifusin Datagrama de multidifusin Troncal CBT
Figura 5.13.- Una transmisin de multidifusin basada en ncleos Posteriormente, cada datagrama de multidifusin se transmite por unidifusin hasta el primer router perteneciente al CBT, a partir del cual se enva mediante multidifusin por las pertinentes interfaces, que son parte del rbol, excepto por la que se recibi. Esto garantiza que todos los datagramas de multidifusin se reenvan a todos los routers en el rbol de distribucin. En trminos de escalabilidad, CBT presenta una serie de ventajas frente a otros algoritmos como es el caso de RPM. El algoritmo CBT hace un uso ms eficiente de los recursos de un router ya que slo requiere que ste mantenga la informacin de estado de cada grupo y no por cada pareja (origen, grupo). Segn se coment, CBT permite que haya un mismo rbol por grupo sin importar el nmero de orgenes200. Tambin, CBT ahorra ancho de banda ya que no requiere que los datagramas de multidifusin sean peridicamente dirigidos a todos los routers de multidifusin en la red. Una potencial desventaja con este algoritmo es que quizs la ruta final a una determinada mquina a travs del rbol de ncleos no sea la ms corta o ms optima. Desde luego, una de sus grandes ventajas es que es escalable permitiendo que se incorporen con ms facilidad por Internet nuevas mquinas a los distintos grupos creados; incluso, que estas mquinas puedan estar muy dispersas geogrficamente.
199
Asimismo, se destaca que si R3 no es un router de multidifusin de ncleo, pero est incluido en el rbol compartido de grupo; entonces, R3 transmite tambin un mensaje CBT de confirmacin a R1.
Se recuerda que en RPM si hay, por ejemplo, 50 orgenes, existen 50 rboles de distribucin diferentes.
200
- 352 -
5.3 Protocolos de encaminamiento de multidifusin

Dependiendo de la distribucin de las mquinas o sistemas finales que son miembros de algn grupo, se pueden clasificar los protocolos de disribucin y actualizacin de la informacin de multidifusin en dos grandes grupos: 1. Protocolos que consideran que los miembros del grupo estn distribuidos densamente201. Para ello, mediante una tcnica de difusin y poda (broadcast & prune) construyen rboles de distribucin basados en el origen, en concreto, en parejas (origen, grupo). Este es el caso de los protocolos: DVMRP (DistanceVector Multicast Routing Protocol), PIM-DM (Protocol-Independent MulticastDense Mode) y MOSPF (Multicast Extensions to OSPF). 2. Protocolos que consideran que los miembros del grupo estn muy esparcidos. Por consiguiente, utilizan mecanismos ms selectivos que la difusin y poda para construir el correspondiente rbol de encaminamiento. Para ello, mediante una tcnica de rboles compartidos construyen rboles que se comparten con un punto central al cual se asocian explcitamente todos los destinos antes de que se origine cualquier flujo de datos. Todo el trfico destinado a los grupos procede de dicho punto central. Esto ltimo mejora la escalabilidad y conserva el ancho de banda a costa de incrementar la congestin en puntos cercanos al ncleo y aumentar el retardo. Este es el caso, a su vez, de los protocolos: CBT (CoreBased Trees) y PIM-SM (Protocol-Independent Multicast-Sparse Mode). Todo protocolo para el encaminamiento de multidifusin se responsabiliza de la construccin de los rboles de distribucin (delivery trees) y reenvo (forwarding) de datagramas de multidifusin. Todos estos protocolos hacen uso del protocolo IGMP para conocer la filiacin de los equipos finales a cada determinado grupo de multidifusin. Sin embargo, difieren en la forma de intercambiar dicha informacin entre los routers de multidifusin (mrouters o multicast routers) vecinos, as como en las tcnicas empleadas en la construccin de los rboles de distribucin. Igualmente, para el encaminamiento de multidifusin se distinguen dos grandes tipos de familias de protocolos: Protocolos de vector de distancia: Se fundamentan en el algoritmo del camino ms corto de Bellman-Ford, en el que cada mrouter distribuye todo el mapa de encaminamiento a sus vecinos de forma peridica, de tal forma que cada mrouter se va haciendo una imagen de la red en su conjunto. Cada mrouter
201
En muchas subredes hay algn miembro del grupo.
- 353 -
asigna un peso o mtrica a cada ruta en funcin de los saltos necesarios para alcanzar a otro mrouter. Se recuerda que su principal ventaja es la sencillez de operacin y, por tanto, de implementacin. Por otro lado, su mayor desventaja es su problema de escalabilidad. A medida que la red se hace mayor y ms compleja, el algoritmo se vuelve menos eficiente y se produce un mayor consumo de ancho de banda. Tambin, es posible la formacin de bucles. Protocolos de estado del enlace: Se basan en el concepto de un mapa distribuido, es decir, que todos los mrouters tienen una copia del mapa de la red, que se actualiza peridicamente. Se han desarrollado a partir del algoritmo propuesto por Dijkstra, denominado el primer camino ms corto (shortest path first), el cual es ms eficiente que el de Bellman-Ford. Se recuerda que algunas de sus principales ventajas son: el soporte de mtricas (costes asociados a un determinado enlace), el soporte, a su vez, de mltiples rutas a un mismo destino, la rpida convergencia a la descripcin real del estado de la red, la ausencia de creacin de bucles, etc. Por otro lado, requieren un mayor procesamiento en los mrouters y son complejos de implementar y/o configurar. Se resalta que los protocolos de encaminamiento de multidifusin son, por lo general, bastante ms complejos que sus homlogos en unidifusin. Adems, su desarrollo ha sido ms tardo, por lo que tienen an mayores deficiencias, sobre todo cuando se aplican a redes complejas y, especialmente, a Internet. Sin embargo, su evolucin ha sido ms rpida, debido en gran medida, al gran inters que han despertado y a sus enormes posibilidades de aplicacin en el contexto de los servicios de multimedia.
5.3.1 Protocolo DVMRP (Distance-Vector Multicast Routing Protocol)

Este protocolo fundamentado en la estrategia del vector de distancia (RFC-1075)202, construye rboles de distribucin basados en el origen mediante la implementacin de algoritmos cimentados en la combinacin de RIP y RPM. DVMRP deriva del protocolo RIP y est especialmente diseado para su uso como protocolo IGP (Interior Gateway Protocol) dentro del dominio de encaminamiento de un sistema autnomo (SA) y no
Aunque ha sido uno de los primeros protocolos de encaminamiento de multidifusin, todava hoy es un protocolo experimental. Fue desarrollado por Steve Deering en la Universidad de Stanford que describi el concepto de multidifusin en su tesis doctoral. Otros investigadores se interesaron por este estudio para su implantacin experimental en Internet. El resultado fue la publicacin del documento RFC -1112 en el que se definen los requisitos necesarios que debe cumplir un equipo para soportar IP de multidifusin.
202
- 354 -
entre diferentes SA. DVMRP construye su propia tabla de encaminamiento de una forma similar a RIP. Una de las principales diferencias entre RIP y DVMRP es que RIP determina el siguiente salto hacia un destino, mientras que DVMRP determina el siguiente salto hacia el origen. Consecuentemente, en lugar de calcular el siguiente salto, calcula el salto anterior perteneciente al camino ms corto de regreso al origen. Segn el algoritmo RPM, el primer datagrama de multidifusin para cualquier pareja (origen, grupo) se difunde a travs de toda la red. Despus de recibir este datagrama, los routers hojas transmiten mensajes de poda hacia el origen si no tienen conectados miembros del grupo. Estos mensajes de poda proporcionan el correspondiente rbol mnimo de expansin (origen, grupo). Asimismo, para poder extender el mbito de la distribucin de multidifusin a travs de routers que no son capaces de entender este tipo de trfico, DVMRP utiliza un mecanismo de envo a travs de tneles203 para atravesar las redes que no soportan multidifusin. De esta forma, se pueden interconectar entre s las distintas subredes o islas de multidifusin a travs de medios fsicos de transporte convencional de unidifusin. En este escenario, un router DVMRP intercambia peridicamente sus tablas de encaminamiento de multidifusin con sus routers homlogos vecinos. Obviamente, dichas tablas son diferentes204 a las creadas por los algoritmos de encaminamiento tradicionales (RIP u OSPF). Asimismo, conviene destacar que DVMRP es el protocolo para el encaminamiento dinmico de multidifusin ms utilizado entre sistemas autnomos. Uno de los principales inconvenientes de DVMRP es su incapacidad para operar en grandes redes, debido fundamentalmente a que el nmero mximo de saltos se limita a 15. Adems, como ya se ha reiterado, no es conveniente inundar a todos los routers hojas de Internet con el primer datagrama de multidifusin para una pareja (origen, grupo); aunque con la informacin de poda se resuelva en parte este otro inconveniente. El desarrollo de la primera implementacin del DVMRP fue lo que permiti el nacimiento de lo que hoy es la red MBone (que se analizar ms adelante). En marzo de 1992 se produjo la primera transmisin de audio y vdeo en tiempo real a travs de dicha red.
203
Se configuran manualmente entre dos routers de multidifusin (mrouters).

Por ejemplo, contienen campos del tipo subred origen y router origen.
204
- 355 -
Con el objetivo de superar las limitaciones del protocolo DVMRP, el grupo IETF ha investigado con otros protocolos de multidifusin como MOSPF, CBT205 y PIM206. Aunque todos estos protocolos han sido implementados y tanto MOSPF como PIM se han utilizado en distintas partes de la red MBone, todos ellos son experimentales, es decir, ninguno de ellos es actualmente un estndar. Como ya se ha indicado, actualmente, la mayor parte de estos protocolos cohabitan en MBone y la tnica general es la implantacin de PIM-DM, DVMRP o MOSPF en entornos corporativos, y la conexin de estas islas de multidifusin a travs de tneles de DVMRP. Se resalta de nuevo el hecho de que la interrelacin de estos protocolos est an en periodo de estudio y experimentacin. Existe un grupo de trabajo del IETF que pretende definir los requisitos que se deben cumplir en la interaccin de distintos protocolos de encaminamiento de multidifusin.
5.3.2 Protocolo MOSPF (Multicast Extensions to OSPF)

El protocolo MOSPF (RFC-1584)207 es la extensin de multidifusin del protocolo OSPF versin 2 de unidifusin que permite a un router encaminar trfico IP de multidifusin por un dominio de encaminamiento208. Por consiguiente, slo trabaja como protocolo IGP en aquellas organizaciones cuyas subredes operan con el protocolo OSPF. La ventaja de este esquema es que el protocolo de encaminamiento de multidifusin se aprovecha del protocolo de unidifusin. Por tanto, al igual que su homlogo, MOSPF es un protocolo diseado para operar dentro del mbito de una red
205
CBT (Core-Based Trees) es un protocolo de encaminamiento de multidifusin del nivel de red definido en los documentos RFC-2201 y RFC-2189.
PIM-DM (Protocol-Independent Multicast-Dense Mode) usa al igual que DVMRP el algoritmo RPM pero con algunas diferencias para obtener una mayor eficiencia en el caso de que los miembros de los grupos de multidifusin estn prximos entre s y el ancho de banda no sea un recurso escaso. A su vez, la razn principal del desarrollo de PIM-SM (Protocol-Independent Multicast-Sparse Mode), definido en el documento RFC-2362, ha sido el intentar paliar las deficiencias presentadas por DVMRP y MOSPF en los casos en que los enlaces entre mrouters estn dispersos a lo largo de amplias zonas y que los miembros de cada grupo de multidifusin no estn concentrados en las proximidades de los mrouters; situacin que se presenta en las topologas de red extensa (WAN).
207
206
Desarrollado por el grupo de trabajo MOSPF Working Group del IETF.
Se recuerda que un dominio de encaminamiento es un conjunto de routers que ejecuta un mismo IGP. Un SA representa uno o ms dominios bajo una nica administracin que tiene una poltica de encaminamiento unificada con otros SA. Generalmente, un SA dispone de un nico dominio de encaminamiento.
208
- 356 -
TCP/IP privada (intranet), y no soporta el uso de tneles. Por consiguiente, su diseo est especialmente pensado para aquellos escenarios en donde hay un nmero pequeo de grupos de multidifusin, es decir, existen pocas parejas activas (origen-grupo). Bsicamente, el protocolo MOSPF slo aade la informacin de origen y grupo de multidifusin a los mensajes de estado del enlace con los que el protocolo OSPF crea su mapa de la topologa de red. En este contexto, cada router calcula las correspondientes rutas de coste mnimo desde el origen a todos los posibles miembros de un grupo, es decir, calcula las rutas para cada pareja (origen-grupo) cuando recibe trfico para una pareja (origen-grupo) determinada. En concreto, cada router calcula un rbol de expansin en el cual el origen de la multidifusin est en la raz y los miembros del grupo en las hojas de dicho rbol. Consecuentemente, este rbol es el camino usado para encaminar trfico de multidifusin desde el origen a cada uno de los miembros del grupo. Un router OSPF/MOSPF209 se puede configurar como un: Router interno de multidifusin (RIM)210 que establece relaciones de vecindad con routers contiguos dentro de un rea. Router en frontera de rea de multidifusin (RFAM)211 con interfaces a dos o ms reas, incluyendo siempre al rea troncal. Por tanto, responsable de reenviar informacin de pertenencia a grupo y datagramas de multidifusin entre reas. Router en frontera de SA de multidifusin (RFSAM)212con uno o ms interfaces a otros sistemas autnomos.
209
En adelante, routers MOSPF. Multicast Intra-Area Router (MIR). Multicast Area Border Router (MABR). Multicast AS Border Router (MASBR).
210
211
212
- 357 -
RIM
REA 0.0.0.0
RIM: Router interno de multidifusin RFAM: Router en Frontera de rea de Multidifusin RFSAM: Router en Frontera de SA de multidifusin
RFAM
RFAM
RIM
RIM RFSAM
REA 0.0.0.2
REA 0.0.0.1
A otro SA (DVMRP)
Figura 5.14.- Un sistema autnomo de tres reas con routers MOSPF. La Figura 5.14 muestra un ejemplo de un sistema autnomo con routers MOSPF basado en dos reas OSPF conectadas por un troncal OSPF. Se pueden combinar los routers MOSPF con routers OSPF con el objetivo de permitir el empleo gradual de MOSPF y experimentar con encaminamientos de multidifusin. Cuando se combinan ambos tipos de routers dentro de un SA, todos los routers interoperarn en el envo de datagramas de unidifusin. MOSPF soporta los siguientes tipos de multidifusin : Multidifusin intrarea para routers internos (RIM). Multidifusin intrarea e interrea para routers en frontera de rea (RFAM). Multidifusin intrarea e interSA para routers en frontera de SA (RFSAM).
MOSPF utiliza un nuevo tipo OSPF de LSA213 denominado LSA de pertenencia a grupo (Group-Membership LSA) que advierte de la existencia de miembros de grupo en las correspondientes subredes. Estos avisos LSA de pertenencia a grupo se envan peridicamente por inundacin a travs de un rea de la misma forma que se transmiten los tpicos avisos LSA de OSPF.
213
Aviso de estado del enlace OSPF: LSA (Link-State Advertisement).
- 358 -
Igual que el resto de los protocolos de encaminamiento de multidifusin, los routers MOSPF utilizan el protocolo IGMP para monitorizar la pertenencia a grupos de multidifusin en subredes directamente conectadas. Los routers MOSPF mantienen una base de datos local de grupo, la cual proporciona los diferentes grupos y determina el router local que va a tener la responsabilidad de entregar datagramas de multidifusin a dichos grupos. En cualquier subred, la transmisin de un mensaje IGMP (tipo 1) de solicitud de pertenencia a grupo (Host Membership Query message) la lleva a cabo nicamente el router designado OSPF. Sin embargo, la responsabilidad de escuchar un mensaje o informe IGMP (tipo 2) de pertenencia a grupo (Host Membership Report) lo realiza tanto el router designado como el de respaldo (backup). El router designado OSPF es responsable de comunicar la informacin de pertenencia a grupo al resto de routers en el rea OSPF mediante una inundacin de avisos LSA de pertenencia a grupo. Como se indic con anterioridad, el rbol del camino ms corto desde el origen, describe la ruta tomada por el datagrama de multidifusin, mientras viaja por el rea, desde la subred de origen a cada una de las subredes de los miembros del grupo. Dicho rbol se construye, para cada pareja (origen, grupo), cuando un router recibe el primer datagrama de multidifusin para una determinada pareja. As, cuando llega un datagrama, la subred de origen se localiza en la base de datos MOSPF de estado del enlace. Dicha base de datos es simplemente la base de datos estndar OSPF aumentada con los avisos LSA de pertenencia a grupo. Debido a que las localizaciones de los miembros de los grupos son conocidas dentro de la topologa, el rbol se construye a travs del correspondiente router de tal manera que sus ramas lleven slo a las subredes a las cuales estn conectados los miembros del grupo en cuestin. Por consiguiente, para reenviar datagramas a miembros de un grupo ubicados hacia abajo en el rbol, cada router debe determinar su posicin en el rbol. Resumiendo, para todo datagrama de multidifusin, todos los routers dentro de un rea OSPF deben calcular el mismo rbol del camino ms corto desde el origen.
- 359 -
RFAM1
REA 0.0.0.0
RFAM2
Avisos LSA de pertenencia a grupo
MB
MA
REA 0.0.01
MB
MA
REA 0.0.0.2
MA
Figura 5.15.- Ejemplo de un sistema autnomo MOSPF. En la Figura 5.15, el rea 0.0.0.1 slo posee miembros de los grupos A y B. Los routers que disponen de miembros directamente conectados, generan los avisos LSA de pertenencia a grupo, anunciando la existencia de dichos miembros en sus subredes. Estos avisos se transmiten por inundacin en el citado rea 0.0.0.1 sin que pasen del rea 0.0.0.1 al rea 0.0.0.2. Una vez que todos los routers del rea 0.0.0.1 han aprendido donde estn ubicados los correspondientes miembros de grupos en la topologa de dicho rea, es posible llevar a cabo la construccin de los rboles de los caminos ms cortos desde el origen para el trfico de multidifusin. En la siguiente Figura 5.16, el origen O1 en el rea 0.0.0.1 comienza a transmitir trfico de multidifusin a todos los miembros del grupo B (O1, B). A medida que los datagramas alcanzan los diferentes routers en el rea, cada uno de ellos ejecuta el algoritmo de Dijkstra y crea el rbol del camino ms corto desde el origen O1. Dicho rbol abarca a todos los miembros del grupo B y se utiliza para dirigir el pertinente trfico de multidifusin al citado grupo. A su vez, el origen O2 en el rea 0.0.0.2 comienza a transmitir trfico de multidifusin a todos los miembros del grupo A (O2, A). De nuevo los routers en dicho rea utilizan la informacin de la pertenencia a grupo en su base de datos MOSPF para realizar los oportunos clculos, construir el rbol del camino ms corto desde el origen O2 y transmitir el trfico a todos los miembros del citado grupo, segn se muestra en la Figura 5.16.
- 360 -
Sin embargo, los routers del rea 0.0.0.1 no tienen constancia de los miembros del grupo A en el rea 0.0.0.2 debido a que los avisos LSA de pertenencia a grupo no se han pasado entre dichas reas. Lo mismo ocurre para las routers del rea 0.0.0.2 con respecto a los miembros del grupo B en el rea 0.0.0.1. El trfico interrea se maneja a travs de otro mecanismo que se comenta a continuacin.
RFAM1
REA 0.0.0.0
RFAM2
MB
MA
NO RECIBE TRFICO (O2, A)
MB
(O1, B)
MA
REA 0.0.0.2
MA
(O2, A)
REA 0.0.01
Figura 5.16.- Ejemplos de multidifusiones intrreas. En la siguiente Figura 5.17, el router en frontera de rea RFAM1 se aade como una rama ms en el rbol del camino ms corto desde cualquier origen activo en un rea no troncal. Por tanto, RFAM1 se aade a dicho rbol para cualquier trfico de multidifusin (O1, B). De la misma manera, RFAM2 se aade al rbol para cualquier trfico de multidifusin (O2, A). Consecuentemente, todo el trfico de origen en el rea se enva hacia el router en frontera de dicho rea (RFAM) de tal forma que pueda ser enviado al rea troncal.
- 361 -
RFAM1
REA 0.0.0.0
RFAM2
MB
MA
MB
(O1, B)
MA
REA 0.0.0.2
MA
(O2, A)
REA 0.0.01
Figura 5.17.- Ejemplo de envos de trficos de origen hacia el RFAM. Asimismo, se utiliza el aviso LSA de resumen de pertenencia a grupo para resumir la informacin de pertenencia a grupos en un determinado rea (ver siguiente Figura 5.18). Esta informacin se introduce en el rea troncal de manera que sus routers tengan constancia de los miembros de grupos en otras reas.
Aviso LSA de resumen de pertenencia a grupo
(GA, GB)
RFAM1
REA 0.0.0.0
(GA)
Aviso LSA de resumen de pertenencia a grupo
RFAM2
MB
MA
MB
(O1, B)
MA
REA 0.0.0.2
MA
(O2, A)
REA 0.0.01
Figura 5.18.- Ejemplos de paso de avisos LSA de resmenes de pertenencia.
- 362 -
En la anterior Figura 5.18, el router en frontera de rea RFAM1 introduce en el rea troncal, mediante un aviso LSA de resumen de pertenencia a grupo, la informacin de la existencia de miembros del grupo A y B en el rea 0.0.0.1. A su vez, el router en frontera de rea RFA2 hace lo propio en el rea 0.0.0.2 con respecto a miembros del grupo A. Por consiguiente, los routers en el rea troncal utilizan la informacin de estos avisos de resmenes en sus clculos, empleando el algoritmo de Dijkstra para conocer los RFAM que deben incluir en el rbol troncal del camino ms corto con respecto a los diferentes orgenes.
RFAM1
REA 0.0.0.0
RFAM2
MB
MA
REA 0.0.01
MB
(O1, B)
MA
REA 0.0.0.2
MA
(O2, A)
Figura 5.19.- Ejemplo de una multidifusin interrea. En la Figura 5.19, el trfico (O2, A) est pasando va RFAM2 del rea 0.0.0.2 al rea troncal (rea 0.0.0.0). A su vez, los routers en el rea troncal reenvan este trfico a RFAM1 que es el responsable de transmitirlo en el rea 0.0.0.1. Seguidamente, los routers dentro del rea 0.0.0.1 ejecutan el algoritmo de Dijkstra para el trfico (O2, A) con el objetivo de construir el rbol del camino ms corto para (O2, A) dentro del rea 0.0.0.1 y, as, poder encaminar debidamente el correspondiente trfico a miembros del grupo A. Segn se ha comentado, es importante resaltar que los RFAM resumen, al rea troncal, la informacin de pertenencias a grupos de las reas a las cuales estn directamente conectados. Todo ello lo hacen creando y enviando al rea troncal nuevos avisos LSA de resumen de pertenencia a grupo. Se destaca que el envo de dicho resumen es asimtrico en el sentido de que se transmite desde un rea no troncal al rea troncal pero no al revs.
- 363 -
Segn se describe en la siguiente Figura 5.20, el trfico interSA o entre sistemas autnomos es bsicamente lo mismo que el trfico interrea. Cuando el trfico llega de otro sistema autnomo a travs del Router en frontera de SA de multidifusin (RFSAM), dicho trfico se reenva a travs del rea troncal a los pertinentes RFAM en funcin de los avisos LSA de resmenes de pertenencias a grupo que se han introducido en el rea.
RFSAM
Otros sistemas autnomos (DVMRP)
RFAM1
REA 0.0.0.0
RFAM2
(O1, A) (O2, B)
MB
MA
REA 0.0.01
MB
MA
REA 0.0.0.2
MA
Figura 5.20.- Ejemplos de multidifusiones interSA. Conviene resaltar que segn la terminologa OSPF la comunicacin interSA tambin puede referirse a la conectividad entre un dominio de encaminamiento OSPF y otro que puede estar incluso dentro del mismo SA. Asimismo, MOSPF asume que cada RFSAM ejecuta un protocolo de encaminamiento de multidifusin entre sistemas autnomos (p.ej., DVMRP). As, cuando un datagrama de multidifusin llega a un RFSAM es responsabilidad suya determinar si el datagrama debe ser reenviado a otro SA. Por ltimo, indicar que MOSPF tienen problemas de escalabilidad directamente relacionados con los clculos reiterados del algoritmo de Dijkstra para cada origen de multidifusin. Por tanto, MOSPF no es apropiado para organizaciones con enlaces inestables y, segn se ha mencionado ya, con muchas parejas activas (origen, grupo).
- 364 -
5.4 Red troncal de multidifusin en Internet: MBone

MBone (Multicast Backbone On Internet) es una red troncal y virtual para las comunicaciones en grupo construida en Internet para envos214 de multidifusin y formada por diferentes conjuntos de subredes o islas conectadas mediante tneles (ver Figura 5.21). En este escenario, cada isla o regin es una subred de rea local o un conjunto de subredes de rea local interconectadas mediante tneles de IP sobre IP que propagan datagramas MBone entre dichas islas. A su vez, cada isla contiene uno o ms routers especiales denominados routers de multidifusin (mrouters o multicast routers). Estos mrouters se comunican virtualmente mediante tneles va routers IP por medio de la encapsulacin de datagramas IP de multidifusin en datagramas IP de unidifusin. Por consiguiente, los datagramas MBone se envan como datagramas IP de unidifusin a la direccin IP del mrouter del destino. Obviamente, si todos los routers en Internet soportaran la multidifusin no sera necesario el uso de los citados tneles. Los tneles no existen fsicamente, se definen mediante tablas en los mrouters y pueden agregarse, eliminarse o moverse con slo cambiar dichas tablas.
ISLA C1 ISLA DE LA ORGANIZACIN A
ISLA C2
ISLA C4
ISLA C3 ORGANIZACIN C
ISLA DE LA ORGANIZACIN B
TRONCAL MBONE
Mrouter IP Tnel de multidifusin
Figura 5.21.- Un ejemplo de un posible escenario MBone.
Fundamentalmente de audio y vdeo aunque tambin para cualquier tipo de informacin de multimedia.
214
- 365 -
En la Figura 5.22 se muestra un ejemplo de cmo se forma un tnel de multidifusin mediante la encapsulacin de datagramas IP de multidifusin en datagramas IP de unidifusin.
A B C D E
A
Tnel de multidifusin Inicio y Final del tnel (direcciones IP de unidifusin)
Origen: A Destino: E
Origen y Destino de la multidifusin (direcciones IP de multidifusin)
Mrouter IP router IP
Figura 5.22.- Un ejemplo de tnel entre dos routers de multidifusin. Segn muestra la siguiente Figura 5.23, para poder establecer un tnel de multidifusin sobre IPv4, es decir, encapsular IP sobre IP, es necesario insertar un cuatro en binario (00000100) en el campo de PROTOCOLO en la primera cabecera de informacin de control IP que es la que establece el correspondiente tnel.
4
VERSIN
4
Longitud Cabecera
8
TIPO DE SERVICIO
16
LONGITUD TOTAL
000 R C F 00
IDENTIFICADOR
TIEMPO DE VIDA
D M F F
DESPLAZAMIENTO
(TTL)
00000100
CABECERA (tnel)
DIRECCIN ORIGEN (INICIO DEL TNEL) DIRECCIN DESTINO (FINAL DEL TNEL) OPCIONES
VERSIN
RELLENO
Longitud Cabecera
TIPO DE SERVICIO
000 R C F 00
LONGITUD TOTAL
IDENTIFICADOR
TIEMPO DE VIDA
D M F F
DESPLAZAMIENTO
(TTL)
PROTOCOLO
CABECERA (nativa)
DIRECCIN ORIGEN DE LA MULTIDIFUSIN DIRECCIN DESTINO DE LA MULTIDIFUSIN OPCIONES

RELLENO
DATOS
Figura 5.23.- Cabeceras IP de un datagrama de multidifusin encapsulado.
- 366 -
Un mrouter debe cumplir dos requisitos bsicos: Tener un mecanismo (protocolo IGMP) para conocer en todo momento los equipos que pertenecen a un determinado grupo de multidifusin en cada una de las subredes que interconecta. Saber para cada pareja (origen, grupo) cmo encaminar los datagramas enviados desde el origen a las subredes en donde haya otros miembros de ese grupo de multidifusin. Teniendo en cuenta que MBone es una red abstracta montada sobre otra red abstracta que es Internet y que ambas redes virtuales tienen diferentes topologas, los routers de multidifusin ejecutan distintos protocolos de encaminamiento para el correcto envo del trfico de multidifusin. La mayora de las islas de MBone estn interconectadas por el protocolo DVMRP. Sin embargo, en cada isla se puede ejecutar cualquier otro protocolo como es el caso de MOSPF, PIM, CBT o, incluso, DVMRP. Se recuerda que tanto MOSPF como PIM se han utilizado en distintas partes de la red MBone y que la mayor parte de todos los protocolos anteriormente mencionados cohabitan en dicha red.
ISLA DE LA ORGANIZACIN A ISLA C2 ISLA C1
MOSPF MOSPF DVMRP
DVMRP
ISLA C3
ISLA C4
MOSPF DVMRP
ISLA DE LA ORGANIZACIN B
MOSPF
MOSPF
ORGANIZACIN C
DVMRP DVMRP DVMRP
MOSPF
TRONCAL MBONE
DVMRP
...
Mrouter IP router IP
...
Figura 5.24.- Un ejemplo ms detallado de un escenario MBone. MBone existe desde 1992 como una red virtual para la experimentacin de la multidifusin IP en Internet. Esta red se ha empleado mayoritariamente para el diseo y creacin de aplicaciones de audio/vdeo, pero puede ser utilizada para el intercambio de cualquier tipo de informacin de multimedia. Aunque hace aos que se implant esta red virtual, an no ha abandonado su calificacin de red experimental por Internet. Esto
- 367 -
ltimo, principalmente, por el hecho ya indicado de ser una red virtual formada por mltiples islas interconectadas entre s. Actualmente, es el nivel de red de multidifusin donde ms trabajo se est realizando en la red MBone. En este contexto, se est utilizando preferentemente la tcnica de difusin y poda (broadcast & prune) que origina una gran cantidad de problemas derivados de la correspondiente poda. As, se est realizando la migracin del protocolo DVMRP al protocolo PIM-DM tambin del tipo de difusin y poda con la intencin de pasar posteriormente al protocolo PIM-SM ms eficiente en el sentido de que se basa en la construccin de un rbol de distribucin a partir de un router central. Sin embargo, el hecho de que PIM-SM est basado en el uso de dicho router central provoca problemas de escalabilidad, impidiendo su utilizacin para la evolucin hacia una red nativa de multidifusin. La necesidad de facilitar la escalabilidad y la administracin de la infraestructura de encaminamiento de multidifusin ha provocado el establecimiento de una jerarqua de encaminamiento en dos niveles: una basada en el uso de protocolos con polticas de encaminamiento interior y otra basada, a su vez, en el uso de protocolos con polticas de encaminamiento exterior. De aqu, que estn surgiendo nuevos protocolos como es el caso del protocolo BGP4+ o MBGP (Multicast Border Gateway Protocol) (RFC-2858) que se basa en el mismo procedimiento operativo que BGP pero en el contexto de la multidifusin. Por consiguiente, BGP4+ es una mejora de BGP que permite intercambios de rutas de IP de multidifusin mediante el transporte de dos conjuntos de rutas: uno para el encaminamiento de unidifusin215 (Network Layer Reachability Information o NLRI) y otro para el encaminamiento de multidifusin (multicast source NLRI). El conjunto de rutas para el encaminamiento de multidifusin son utilizadas por el protocolo PIM216 para la construccin de los rboles de distribucin. Todo ello, permite tener una topologa de unidifusin diferente a la de multidifusin. Se resalta que la tabla de encaminamiento de multidifusin BGP+ est separada totalmente de la tabla de encaminamiento BGP. Generalmente, cada pas integrado en MBone dispone de una red troncal con una serie de islas conectadas a dicha red. Cuando aparece una nueva isla que desea integrarse a MBone, su administrador enva un mensaje anunciando su existencia a una lista cercana de correo de MBone. Seguidamente, los administradores de las islas
215
IPv4 de unidifusin, IPv4 de multidifusin e IPv6 de unidifusin.
El protocolo que construya los rboles de distribucin utilizar las tablas de encaminamiento generadas por BGP4+.
216
- 368 -
cercanas se ponen en contacto para establecer los pertinentes tneles. Un usuario217 en su casa en principio puede conectarse a MBone siempre y cuando su ISP est conectado a dicha red y reconfigure sus routers para permitir el pretendido acceso. En Espaa hay que contactar con RedIRIS (http://www.rediris.es/mmedia/) para poder tener acceso a la red MBone mediante el servicio IRIS-MBone. Por el momento, esta red no puede ser usada sin una peticin previa y por motivos justificados. Entre otras cosas, debido a que la multidifusin no est implantada en todas partes y hay que utilizar tneles. Usar estos tneles requiere la intervencin humana en ambos extremos y, a veces, puede pasar un tiempo ms o menos largo desde que se decide emplear la red MBone hasta que sta se puede utilizar. Otro problema aadido es el ancho de banda, por ejemplo, el mnimo establecido por RedIRIS como uno de los requisitos de acceso es de 2 Mbps. Finalmente, indicar que actualmente el encaminamiento de multidifusin en Internet es un servicio estrictamente experimental; muy pocos ISP lo soportan realmente. En este contexto, IETF ha creado un grupo de trabajo denominado MBone Deployment o MBoneD working group para resolver todos los temas operativos que permitan extender la red MBone y, finalmente, tener como resultado una red Internet de multidifusin nativa sin necesidad de establecer tneles. Por ltimo, se destaca que la red MBone est transitando actualmente hacia el protocolo IPv6 (6bone)218.
El usuario debe tener una mquina con un sistema operativo con soporte TCP/IP capaz de enviar y recibir datagramas IP de multidifusin. Este es el caso de Windows95, NT, 2000, XP, Unix (en todas sus variantes), MacOS, etc.
218
217
6bone es actualmente un proyecto colaborativo e informal que empez como una red virtual utilizando encapsulacin (tnel) IPv6 sobre IPv4 y que est migrando actualmente a enlaces nativos IPv6.
- 369 -
Figura 5.25.- La red MBone en Espaa: IRIS-IPv6.
5.4.1 Algunas aplicaciones para Mbone

A continuacin, se muestran algunas aplicaciones para conferencia en la red MBone, desarrolladas y/o recomendadas por el grupo de trabajo de investigacin en multimedia de la University College London (UCL Networked Multimedia Research Group) que a travs de su pgina Web (http://www-mice.cs.ucl.ac.uk/multimedia/software/)219 proporciona la necesaria informacin para descargar e instalar dichas aplicaciones. RAT: Robust Audio Tool. Desarrollada en el UCL de Londres dentro del proyecto MERCI. Es una aplicacin para conferencias de audio. VIC: VideoConferencing. Desarrollada por Van Jacobson y su grupo de trabajo en el Lawrence Berkeley National Laboratory (LBNL) in Berkeley, California. SDR: Session Directory Tool. Desarrollada por el UCL (University College London) dentro del proyecto MERCI. Est basado en otro software anterior, llamado SD, original del grupo de Van Jacobson en el LBNL (Lawrence Berkeley National Laboratory). Es una herramienta que muestra un directorio de las sesiones de MBone activas y permite
219
Tambin se puede descargar del mirror de RedIRIS: ftp://ftp.rediris.es/mirror/videoconference/
- 370 -
unirse a una determinada sesin lanzando automticamente las aplicaciones adecuadas. WB: White Board. Desarrollada por Van Jacobson en el LBNL. Es una pizarra electrnica compartida.
- 371 -
5.5

BIBLIOGRAFA
RFC-1112: Host extensions for IP multicasting. RFC-1122: Requirements for Internet Hosts - Communication Layers. RFC-1700: Assigned Numbers. RFC-3232: Assigned Numbers: RFC 1700 is Replaced by an On-line Database. RFC-1075: Distance Vector Multicast Routing Protocol. RFC-1584: Multicast Extensions to OSPF. RFC-2362: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. RFC-2201: Core Based Trees (CBT) Multicast Routing Architecture. RFC-2189: Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification. RFC-2858: Multiprotocol Extensions for BGP-4. Redes de datos de banda ancha, C. Fernndez del Val, G. Lpez, N. Barcia, Servicio de publicaciones de la UPM, 2002. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Multi-Casting-MOSPF, University College London, http://www.hep.ucl.ac.uk/~ytl/multi-cast/. MBone: Arquitectura y Aplicaciones, Juan Antonio Garca, http://www.rediris.es/rediris/boletin/43/enfoque3.html, 2000. Mbone Conferencing Applications, UCL Networked Multimedia Research Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/ Deploying IP Multicast in the Enterprise, T. A. Maufer, Prentice Hall, 1998. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000.
- 372 -
Captulo 6. Nivel de Transporte de TCP/IP
6.
NIVEL DE TRANSPORTE DE TCP/IP
Una vez se han analizado los principales protocolos que facilitan el encaminamiento IP del nivel de Internet en la arquitectura TCP/IP tanto para transmisiones de unidifusin como de multidifusin; es el momento de ascender por la arquitectura de comunicaciones TCP/IP y analizar los protocolos del nivel de transporte de dicha pila de comunicaciones.
6.1
Protocolo TCP (Transmisin Control Protocol)

A
APLICACIN TCP IP
INTERFAZ DE RED
INTERFAZ DE RED
B
APLICACIN
FIABILIDAD
TCP
IP
INTERFAZ DE RED
INTERFAZ DE RED
IP
INTERFAZ DE RED
IP
INTERFAZ DE RED
Figura 6.1.- Un ejemplo de escenario para TCP. La Figura 6.1 muestra un ejemplo de escenario del protocolo TCP (RFC-793 y 1122), el cual ofrece, aparte de otras funciones y extremo a extremo, un servicio orientado a conexin y, por tanto, fiable y sin congestiones de nivel de transporte independientemente de las redes y routers que hayan intervenido entre dos sistemas finales o mquinas de usuario. En dicha figura aparecen tres redes y dos routers entre los dos sistemas finales A y B.
- 373 -
TRANSFERENCIAS DE FLUJO OCTETOS (BYTE-STREAM) ORIENTADO A LA CONEXIN

Control de errores (Fiabilidad) Control de flujo (sin congestiones)
DE
MULTIPLEXADO TRANSFERENCIAS SIMULTNEAS EN LOS DOS SENTIDOS (Full-dplex)
Figura 6.2.- Caractersticas ms relevantes del protocolo TCP. El protocolo de control de la transmisin TCP (Transmission Control Protocol) proporciona, al correspondiente proceso de aplicacin, un servicio de flujo de octetos (byte-stream), orientado a la conexin y, por tanto, fiable, y sin congestiones. Asimismo, ofrece un servicio multiplexado y dplex (en los dos sentidos). Estas caractersticas de TCP (ver Figura 6.2) se desglosan a continuacin: Flujo de octetos (byte-stream): La entidad TCP emisora permite al proceso de aplicacin (emisor) transmitir un flujo continuo de octetos que la entidad TCP emisora va recogiendo, numerando y agrupando en unidades de datos denominadas segmentos, de tal manera que la entidad TCP receptora pase al proceso de aplicacin (receptor) exactamente la misma secuencia de octetos y en el mismo orden (sin prdidas ni duplicaciones). Por tanto, el proceso de aplicacin emisor se despreocupa de delimitar los datos que quiere transmitir; simplemente, los va pasando octeto a octeto de forma continua para que el proceso TCP emisor los vaya agrupando en segmentos. En este contexto, la entidad TCP calcula un MSS (Maximum Segment Size o campo de datos del segmento) de tal forma que los datagramas IP se correspondan con la MTU de la red de acceso. Esta es una de las principales diferencias con respecto al protocolo UDP (de nivel de transporte), al cual hay que mandarle bloques de una longitud mxima fija220 y bien delimitados en su principo y final. Orientado a conexin (conexiones lgicas): Mediante la conexin entre la correspondiente pareja de sockets (cliente-servidor), la entidad TCP emisora se pone de acuerdo con la entidad TCP receptora para llevar a cabo todas las funciones de control de errores y flujo en la fase posterior de transferencia de datos.
Por ejemplo, en bloques de 512 octetos de longitud mxima salvo el ltimo que, generalmente, tendr menos.
220
- 374 -
Control de errores: Abarca tanto los errores lgicos como fsicos. Errores lgicos (octetos de datos perdidos, desordenados y duplicados221): Se controlan mediante el uso de los siguientes mecanismos: Temporizadores: Son los plazos de espera de las pertinentes confirmaciones de los octetos de datos contenidos en los segmentos de informacin (campo de datos) transmitidos. Los octetos del campo de datos de cada segmento de informacin tienen asociados su correspondiente temporizador y a su vencimiento, es decir, si el temporizador expira antes de que se confirme cualquier octeto del segmento, se retransmite el segmento en cuestin. El protocolo TCP utiliza una tcnica adaptativa basada en un algoritmo adaptable de retransmisin para establecer el valor de dicho temporizador. Esta tcnica se basa en medir el tiempo del viaje de ida y vuelta (RTT: Round Trip Time) desde que se enva un segmento de informacin hasta que se recibe su confirmacin. Ms concretamente, se basa en la transmisin previa de un octeto de datos en un segmento de informacin y en la recepcin de la oportuna confirmacin. Esta confirmacin debe cubrir el nmero de secuencia del citado octeto. Nmeros de secuencia: Se asignan a cada octeto transmitido (y nunca a los segmentos que transportan dichos octetos). Cada octeto tiene su propio nmero de secuencia. Confirmaciones: Permiten a la entidad TCP emisora girar su ventana de transmisin222 para seguir enviando datos. Este giro permite liberar el espacio de almacenamiento del bfer de trabajo y, por tanto, eliminar la copia de los octetos transmitidos. El campo de datos de cada segmento de informacin tiene asociado una confirmacin al igual que dispone de su correspondiente temporizador. Consecuentemente, una confirmacin (individual por
La duplicacin se produce cuando no llega en el plazo establecido la confirmacin de los datos de un segmento de informacin de TCP y se retransmite de nuevo dicho segmento. Los octetos de datos del nuevo segmento se pueden confundir con los del anterior. Como se estudiar seguidamente, TCP usa el concepto de ventana deslizante como mecanismo de control de flujo.
222
221
- 375 -
segmento) valida todos los octetos del campo de informacin del pertinente segmento. Errores fsicos (bits desvirtuados o cambiados): Consistente en dos procesos: Deteccin: Mediante un mecanismo de suma de comprobacin que se aplica a todo el segmento. Correccin: A travs de retransmisiones al vencimiento de los correspondientes temporizadores. La entidad TCP receptora elimina el segmento afectado y no enva una solicitud de retransmisin. Al vencimiento del temporizador, la entidad TCP emisora vuelve a transmitir de nuevo los octetos afectados.
Control de flujo: Este servicio impide que una entidad TCP emisora B transmita ms rpidamente de lo que otra entidad TCP receptora A es capaz de almacenar y procesar. Se basa en un mecanismo de ventana deslizante de recepcin223 que define un sistema de crditos de transmisin de octetos, pendientes de confirmacin, que A concede al otro extremo B para que cuando la entidad B transmita no colapse a la entidad A. Este sistema de crditos indica el nmero de octetos que la entidad A puede recibir y manejar en funcin del tamao puntual de su bfer de recepcin. Al igual que los nmeros de secuencia se asignan a cada octeto transmitido, el sistema de crditos se asigna por octetos y no por segmentos. Multiplexacin: TCP ofrece un servicio multiplexado a los diferentes procesos de aplicacin a travs de los nmeros de puerto que identifican a dichos procesos. La multiplexacin se refiere a que una entidad TCP puede dar servicio a varios procesos de aplicacin simultneamente o en paralelo. Full-dplex: La transmisin de informacin entre entidades TCP es bidireccional y simultnea.
223
Habr una ventana de transmisin complementaria en el otro extremo de la comunicacin.
- 376 -
CABECERA
DATOS (Variable)
Maximum Segment Size (MSS)
BUFFER DE TRANSMISIN
N SEC = n Primer octeto N SEC = n+1 N SEC = n+2 Segundo octeto Tercer octeto
...
Figura 6.3.- Formato de un segmento TCP. Segn se describe en la Figura 6.3, un segmento TCP engloba dos tipos de informacin: Cabecera de informacin de control: Contiene la informacin de control que manejan las entidades TCP para llevar a cabo sus respectivas funciones. Sin opciones de servicios adicionales, tiene una longitud mnima, por omisin, de 20 octetos y mxima de 60 octetos (incluyendo opciones). Datos: Incluye la cabecera de informacin de control de la correspondiente aplicacin y los potenciales datos del mensaje de dicha aplicacin (si existen). Este campo de datos se corresponde con lo que se entiende como Tamao Mximo del Segmento (MSS: Maximum Segment Size). Como ya se ha comentado, la entidad TCP calcula un MSS de tal forma que los datagramas IP se correspondan con la MTU (Maximum Transfer Unit) de la red de acceso. Consecuentemente, este campo tiene una longitud de tamao variable. Para usar los trozos del tamao adecuado es necesario que TCP disponga de un temporizador que le permita recoger una cantidad razonable de octetos de datos antes de crear el oportuno segmento de informacin o datos. Por tanto, la aplicacin enva de forma continua los datos que quiere transmitir y TCP recoge, numera, almacena estos datos en un bfer de envo y, finalmente, los agrupa en segmentos. Es decir, previamente guarda copia de dichos datos por si hay problemas en el envo y debe retransmitirlos. Posteriormente, la entidad TCP emisora, una vez se ha llenado el bfer de transmisin, toma un trozo de los datos almacenados y le aade una cabecera, creando un segmento. Finalmente, dicha entidad TCP emisora pasa el segmento al vecino del piso inferior o entidad IP para que lo entregue como un nico datagrama IP.
- 377 -
0 PUERTO ORIGEN
15 16 PUERTO DESTINO
31
NMERO DE SECUENCIA NMERO DE CONFIRMACIN (ACK)

CABECERA TCP DESP RESERVADO URG ACK PSH RST SYN FIN
VENTANA PUNTERO URGENTE RELLENO
SUMA DE COMPROBACIN OPCIONES
DATOS (Variable)
Figura 6.4.- Formato de la cabecera de un segmento TCP con todos sus campos. La Figura 6.4 muestra los distintos campos que conforman la cabecera de informacin de control de TCP. stos son los siguientes: Puerto de Origen (16 bits): Identifica al proceso de aplicacin emisor que enva un segmento TCP; por ejemplo, en un momento dado, al proceso cliente que realiza una solicitud de establecimiento de la conexin. Puerto de Destino (16 bits): Identifica al proceso de aplicacin receptor que recibe un segmento TCP; por ejemplo, en un momento dado, al proceso servidor que recibe una solicitud de establecimiento de la conexin. Nmero de Secuencia (32 bits): Indica el primer octeto del campo de datos (si tiene un octeto o ms) del segmento de informacin que se va enviar. Como el nmero de secuencia es de 32 bits, se trabaja en mdulo 232. Esto ltimo quiere decir que los octetos se numeran cclicamente del 0 al 232-1 (0, 1, 2, , 232-1, 0, 1, 2, ), es decir, el nmero de secuencia vuelve a 0 despus de 232-1. Nmero de Confirmacin (32 bits): Indica el primer octeto del campo de datos del siguiente segmento de informacin que se espera recibir. Desplazamiento de Datos (Data Offset) o longitud de la cabecera (4 bits): Indica el nmero de bloques de cuatro octetos (palabras de 32 bits) que ocupa la cabecera. Por omisin (sin opciones de servicios adicionales) tiene una longitud de 20 octetos (5 bloques o 0101de 4 octetos). El tamao mximo ser de 60 octetos (15 bloques o 1111 de 4 octetos). Al igual que para el protocolo IP, ste es un campo necesario para reconocer el inicio del campo de datos de usuario, ya que el campo de opciones es de longitud variable. Reservado (6 bits): Seis bits a cero reservados para un uso futuro.
- 378 -
URG (Urgent Pointer) o puntero urgente (1 bit): Si est activo indica que el campo de Puntero Urgente o Puntero de Datos Urgentes es un campo vlido y significativo que la entidad TCP receptora debe analizar debidamente. ACK (ACKnowledgment) o confirmacin (1 bit): Si est activo indica que el campo de Nmero de Confirmacin o Nmero de ACK es un campo significativo que la entidad TCP receptora debe analizar debidamente. PSH (Push) o empuje (1 bit): Es un mecanismo de empuje que proporciona un servicio forzado de transferencia, obligando a que la entidad TCP emisora transmita sin esperar a que se llene su bfer de transmisin. A su vez, esto evita que la entidad TCP receptora almacene temporalmente el segmento hasta llenar su bfer de recepcin. Por consiguiente, cuando la entidad TCP receptora recibe un segmento con el bit Push activado, sabe que la entidad TCP emisora se ha visto obligada a transmitir sin haber llenado su bfer de transmisin y, por tanto, empuja inmediatamente los datos al proceso de aplicacin sin esperar, en este caso, a que se llene su correspondiente bfer de recepcin. Este bit se puede utilizar en el caso de interacciones cliente-servidor en aplicaciones que manejan bloques reducidos de datos. Por ejemplo, en el caso de un cliente que ha iniciado una sesin interactiva con un servidor remoto y el usuario ha tecleado un comando o una determinada informacin; y, seguidamente, ha pulsado retorno de carro. En este escenario, el programa cliente desea que los datos se enven a la mquina remota y se entreguen inmediatamente al proceso servidor. En una tpica sesin interactiva pueden aparecer muchos segmentos de informacin que contienen muy pocos datos y con el bit PSH activado. Asimismo, no tendra mucho sentido usar este bit para una transferencia de ficheros ya que la entidad TCP emisora no podra agrupar los octetos de datos en segmentos del tamao adecuado. RST (Reset) o reinicio (1 bit): Bit de reinicio que si est activo indica al mdulo TCP receptor que abandone la comunicacin debido a un error o a una situacin anormal o simplemente se usa como respuesta para rechazar una solicitud de establecimiento de una conexin TCP. Por ejemplo, se usa en la recepcin de un segmento no apropiado o cuando llega una solicitud de conexin para un proceso de aplicacin que no est preparado en un puerto dado, etc. Esto obliga a reiniciar y resincronizar la comunicacin. Como se ha indicado, tambin, se utiliza para rechazar una solicitud de conexin TCP y para un cierre abrupto de sta en cualquier momento posterior a la fase de establecimiento de la conexin. SYN (Synchronize) o sincronizacin (1 bit): Bit de sincronizacin que si est activo indica que se est estableciendo o procesando una conexin TCP.
- 379 -
Asimismo, sincroniza los nmeros de secuencia empleados por las entidades TCP extremo a extremo. Combinndose con el bit ACK proporciona dos segmentos especficos de control TCP (sin datos de usuario) SYN = 1, ACK = 0: Solicitud de establecimiento de una conexin TCP. SYN = 1, ACK = 1: Respuesta afirmativa (OK!) a la solicitud previa de establecimiento de una conexin TCP. FIN (Finalize) o liberacin (1 bit): Bit de finalizacin o liberacin de la transmisin. La conexin se libera completamente cuando se transmite en cada sentido un segmento sin datos con dicho bit activado. Consecuentemente, un lado de la conexin se puede liberar y el otro seguir activo transmitiendo datos, es decir, una entidad TCP puede seguir recibiendo datos hasta que procese este bit. Ventana (16 bits): Es la ventana deslizante de recepcin del emisor del segmento que transporta dicha informacin. Se utiliza como mecanismo de control de flujo, y como ya se ha indicado, se basa en un sistema de crditos de transmisin de octetos, pendientes de confirmacin, que se concede al otro extremo para que pueda transmitir. Dicho sistema de crditos indica el nmero de octetos pendientes de confirmacin que el receptor224 puede manejar en funcin del tamao puntual de su bfer de recepcin. Concretamente, indica cuntos octetos, pendientes de confirmacin, se conceden al otro extremo a partir del primer octeto de datos indicado por el campo de Nmero de Confirmacin (Acknowledgment Number). La ventana puede ser de 1 octeto, 2 octetos, 3 octetos, , hasta 216-1 octetos (65.535 octetos o 16 unos) como mximo. Quiere esto decir, que el bfer de recepcin es como mximo de 65.535 octetos. En el establecimiento de la conexin cada entidad TCP define el tamao mximo de la ventana que desea. Posteriormente, durante la fase de transferencia de datos, este tamao puede ir variando (se introducen nuevos valores en el campo de Ventana) hasta el mximo definido previamente en la fase de establecimiento. Aparte de la ventana de recepcin, tanto la entidad TCP emisora como la entidad TCP receptora, disponen de otra ventana denominada de transmisin, la cual es complementaria a la de recepcin. En consecuencia toda entidad TCP dispone de dos tipos de ventanas:
224
Emisor del segmento con la informacin de ventana.
- 380 -
Ventana de transmisin: Controla la numeracin de los octetos de datos almacenados en el bfer de transmisin. Esta ventana define una lista de nmeros de secuencia consecutivos que se corresponden con los octetos que en un momento dado el emisor ha enviado sin haber recibido confirmacin. El bfer de transmisin guarda copia de los octetos contenidos en el campo de datos de cada segmento de informacin transmitido225. Antes de la comunicacin, cada parte llama a una subrutina que crea un bloque de memoria para el almacenamiento de los parmetros TCP e IP durante la conexin como las direcciones de los sockets, los nmeros actuales de secuencia, etc. Como ya se ha comentado, mientras la aplicacin enva de forma continua los datos que quiere transmitir, TCP recoge, numera y almacena estos datos en un bfer de envo. Seguidamente, la entidad TCP emisora agrupa los octetos de datos almacenados en trozos y les aade una cabecera creando los segmentos que pasa a la entidad IP del nivel inmediatamente inferior. A medida que se van recibiendo las confirmaciones, se va liberando espacio en la memoria intermedia de trabajo (girando o deslizando la ventana) para dejar sitio a nuevas copias de otros octetos que se desean transmitir. Si no se recibe una confirmacin, al vencimiento del temporizador (cada segmento de datos tiene su propio temporizador) se retransmite la copia de los datos del correspondiente segmento.
A Aplicacin
Envo
Buffer de Transmisin (Ventana de Transmisin)
B Aplicacin
Envo
Buffer de Transmisin (Ventana de Transmisin)
TCP
Recepcin
Buffer de Recepcin
TCP
Recepcin
Buffer de Recepcin
(Ventana de Recepcin)
(Ventana de Recepcin)
IP
IP
BUFFER DE TRANSMISIN N SEC = n Primer octeto N SEC = n+1 N SEC = n+2 Segundo octeto Tercer octeto
...
Figura 6.5.- Intercambio de flujos de octetos entre aplicaciones.
225
Los datos de la cabecera se copian en un registro asociado al temporizador.
- 381 -
Conviene no confundir el tamao del campo de datos de un segmento de informacin y el tamao del bfer de transmisin. Por ejemplo, se puede disponer de un bfer de transmisin de 4096 octetos y que el tamao mximo del campo de datos de un segmento de informacin (MSS) sea de 1024 octetos. En este ejemplo se puede guardar copia de los octetos agrupados, posteriormente, en cuatro segmentos de informacin. Ventana de recepcin: Controla la numeracin de los octetos de datos almacenados en el bfer de recepcin. Esta ventana define una lista de nmeros de secuencia consecutivos que se corresponden con los octetos que en un momento el receptor puede aceptar. Cualquier octeto cuyo nmero de secuencia est fuera del rango esperado de nmeros de secuencia, es automticamente eliminado. Suma de Comprobacin (16 bits): Suma aritmtica binaria o en mdulo 2 (sin acarreo o suma OR exclusiva) de todos los bloques de 16 bits del segmento completo (cabecera y datos). El procedimiento de clculo de la suma de comprobacin es similar al utilizado para calcular la suma de comprobacin de IP salvo por los dos siguientes puntos: En primer lugar, cuando la longitud del segmento no es un mltiplo de 16 bits. En este caso, el segmento se rellena de ceros hasta hacerlo mltiplo de 16 bits; sin embargo, el segmento real que se ha de enviar no se modifica por lo anterior. En segundo lugar, porque se incluye una pseudocabecera al inicio del segmento cuando se calcula la suma de comprobacin (ver siguiente Figura 6.6). Esta pseudocabecera que tampoco se transmite, se crea en el origen y destino durante el proceso de clculo. Dicho procedimiento le permite al mdulo TCP, por un lado, identificar inmediatamente la conexin a la cual pertenece el segmento y, por otro lado, asegurarse de que el segmento ha alcanzado realmente la mquina de destino y el pertinente puerto. Amn, de que el tipo de protocolo es TCP ya que tiene asignado el valor 6.
- 382 -
0
SEUDOCABECERA TCP
15 16
31
DIRECCIN IP ORIGEN
DIRECCIN IP DESTINO
00000000 PROTOCOLO = 6 LONGITUD DEL SEGMENTO TCP CABECERA TCP
DATOS (Variable)
Figura 6.6.- Pseudocabecera TCP. Puntero Urgente o Puntero de Datos Urgentes (16 bits): Cuando el bit URG est activo, el valor del campo de Puntero Urgente sumado al valor del campo de Nmero de Secuencia, apunta al ltimo octeto de los datos urgentes de control; los cuales, requieren un procesamiento especial por parte de la aplicacin. Por tanto, a travs de este campo, se indica dnde terminan los datos urgentes y empiezan los normales. El primer octeto de los datos urgentes nunca se define explcitamente. Teniendo en cuenta que la entidad TCP receptora pasa los datos en secuencia a la correspondiente aplicacin, cualquier octeto en el bfer de recepcin, hasta el ltimo octeto de los datos urgentes, debe considerarse como urgente. Por consiguiente, ser la propia aplicacin la que diferencie los datos normales de los caracteres de control. Se asume que estos datos urgentes pueden ser avisos, interrupciones o datos de control (p.ej., caracteres de control o secuencias de escape) de la propia aplicacin que pueden ir entremezclados con los datos normales de sta y se desean que aparezcan antes que dichos datos normales. Conviene no confundir la entrega inmediata al proceso servidor de los datos normales de informacin ms relevantes mediante el bit PSH (Push); y la entrega226 ms la diferenciacin de los datos normales y los datos urgentes de control227 de la propia aplicacin mediante el bit URG.
226
En el momento correspondiente. Mezclados con los datos de informacin.
227
- 383 -
Opciones (variable): El campo de opciones de servicios adicionales es un campo de informacin de control de longitud variable concebido para futuras mejoras o extensiones del protocolo TCP y que contiene opciones de servicios extras de dicho protocolo. Hasta el momento las opciones que se utilizan se especifican en la fase de establecimiento de la conexin228. Dichas opciones son las siguientes: Tamao Mximo de Segmento (MSS): Se usa para indicar el nmero de octetos de la carga til o campo de datos del segmento que el emisor (del segmento que transporta esta opcin) desea recibir para un procesamiento ms ptimo. Esta es la opcin ms importante y, por tanto, ms utilizada con el objetivo de permitir la escalabilidad de los protocolos TCP/IP. Es importante tener en cuenta la inmensa diversidad de mquinas de diferentes modelos y fabricantes con distintas capacidades de proceso y almacenamiento229 que hay por Internet. Consecuentemente, TCP incorpora en su diseo la posibilidad de manejar diferentes tamaos de bferes y segmentos de datos230. Escalado de Ventana: Permite el uso (escalar) de un tamao mayor de Ventana (de recepcin). Generalmente, el tamao mximo de Ventana es de 216-1 octetos (65.535 octetos). Se puede llegar hasta 1.073.725.440 octetos (1 GB aproximadamente). Marca de Tiempo: Permite al emisor incluir una marca de tiempo en cada segmento para conexiones de alta velocidad en donde los nmeros de secuencia pueden dar la vuelta durante el tiempo de vida de la conexin. Por tanto, permite reconocer octetos diferentes con el mismo nmero de secuencia en la misma conexin. Relleno (variable): Bits que se aaden al campo de opciones para conseguir que la cabecera tenga una longitud mltiplo de 4 octetos.
Como se analizar, a continuacin, son opciones que se usan slo en los dos primeros segmentos transmitidos (los cuales deben llevar el bit SYN activado). Por la estructura de la memoria, una simple mquina de usuario o PC (Personal Computer) puede tener un pequeo bfer de recepcin, mientras que una gran mquina servidora puede disponer de un bfer muy grande. Un PC puede limitar el tamao de los trozos de datos a 1 KB, mientras que una "supercomputadora" puede manejar segmentos de mayor tamao.
230 229
228
- 384 -
Datos (variable): Como se ha indicado con anterioridad, el protocolo TCP calcula un MSS de tal forma que los datagramas IP resultantes se correspondan con la MTU de la red de acceso.
TCP A (Cliente)
SYN= VENT A 1, ACK NA=p =0, SE C =n
TCP B (Servidor)
DATO S=0
SEC=m F= n+1, =1, CON ACK SYN=1, TOS=0 A=q DA ENTAN V

SYN= 0, ACK=
1, CON F=m+ 1, SEC VENT =n+1 ANA= p DATO S=0
Figura 6.7.- Fase de establecimiento de una conexin TCP sin opciones. En la Figura 6.7 se muestra el establecimiento de una conexin entre dos entidades TCP denominadas A (cliente) y B (servidor) en funcin de un procedimiento inicial de saludo o dilogo basado en el intercambio de tres segmentos de control (sin datos o Datos=0). Slo se indican los campos ms significativos que aparecen en las correspondientes cabeceras de informacin de control. En este contexto, SYN=1 y/o ACK=1 significa que el correspondiente bit est activado. A su vez, SYN=0 y/o ACK=0 denota, a su vez, que el pertinente bit no est activado. Primer segmento (SYN = 1, SEC = n, ...): Se usa para que la entidad TCP A avise a la entidad TCP B de que hay que llevar a cabo todas las funciones de control de errores y flujo en la fase posterior de transferencia de datos. Adems, indica el Nmero de Secuencia n (SEC = n) que desea usar la entidad TCP A. Segundo segmento (SYN = 1, ACK = 1, CONF = n+1, SEC=m, ...): Se usa para confirmar (CONF = n+1) el nmero de secuencia n que desea emplear el otro extremo de la comunicacin (A), y para indicar el nmero de secuencia m (SEC = m) que va a emplear la entidad TCP B. Por tanto, el primer octeto de datos, enviado por A, se numerar con el valor n+1. Tercer segmento (ACK = 1, CONF = m+1, ...): Se usa para confirmar (CONF = m+1) el nmero de secuencia m que va a utilizar el otro extremo de la comunicacin. Por tanto, el primer octeto de datos, enviado por B, se numerar con el valor m+1. - 385 -
Entre otras cosas, este intercambio permite a las dos entidades TCP ponerse de acuerdo en cuanto a los nmeros de secuencia iniciales empleados en ambos extremos de la comunicacin. Dichos nmeros no se reutilizan durante un tiempo prudencial para evitar que los octetos de datos de los segmentos de informacin de una conexin se confundan con los de otra, especialmente, cuando se cierren y abran conexiones inmediatamente. Si una entidad TCP siempre utiliza el mismo nmero de secuencia inicial, los segmentos obsoletos no se distinguen de los actuales ya que los segmentos TCP, aparte de perderse, puede que se retrasen o dupliquen. Esta es la razn por la que no se comienza siempre desde el mismo nmero (p.ej., el cero). Por consiguiente, durante un tiempo prudencial, el nmero de secuencia es diferente cada vez que la aplicacin de una mquina solicita una conexin de transporte. Asimismo, durante la fase de establecimiento de una conexin TCP, se indica el tamao mximo de la ventana de recepcin y, opcionalmente, por ejemplo, el tamao del campo de datos (MSS) de los segmentos de informacin que se esperan recibir. En concreto, el anuncio de las ventanas y MSS se realiza con segmentos en los cuales est activado el bit SYN. En relacin a la ventana mxima de recepcin, sta se anuncia en la fase de establecimiento y durante la fase de transferencia de datos se indica, en cada segmento transmitido, el tamao puntual de dicha ventana.
TCP A (Cliente)
SYN= 1, ACK =0, SE VENT C=n ANA= p, OPC IN M DATO SS=r S=0
TCP B (Servidor)
EC= m = n+1, S , CONF ACK=1 SYN=1, SS= s CIN M A=q, OP N VENTA DATOS=0
SYN= 0, ACK =1, CO NF=m +1, SE C= n+ 1 VENT A NA= p DATO S=0
Figura 6.8.- Fase de establecimiento de una conexin TCP con la opcin MSS. En el ejemplo anterior de la Figura 6.8: En el primer segmento, la entidad TCP A indica, a la entidad TCP B, el tamao de su Ventana (Ventana = p, por ejemplo, 4096 octetos) y, opcionalmente, el MSS que espera recibir (MSS = r, por ejemplo, 1024 octetos).
- 386 -
En el segundo segmento, la entidad TCP B indica, a la entidad TCP A, el tamao de su Ventana (Ventana = q, por ejemplo, 6144 octetos) y, opcionalmente, el MSS que espera recibir (MSS = s, por ejemplo, 256 octetos). Si durante la fase de establecimiento de la conexin la entidad TCP B decide rechazar la solicitud, enviar un segmento de rechazo con el bit RST (Reset) activado.
TCP A (Cliente)
SYN= 1, ACK =0, SE VENT C=2 ANA= 300, D ATOS =0
TCP B (Servidor)
0 EC=150 NF= 3, S K=1, CO AC SYN=1, TOS=0 900, DA TANA= VEN

SYN= 0, ACK =1, CO NF=15 01, SE VENTA C= 3 NA=30 0, DA T OS=0
Figura 6.9.- Un ejemplo de una fase de establecimiento de una conexin TCP. En la anterior Figura 6.9 se describe un ejemplo del establecimiento de una conexin entre dos entidades TCP denominadas A (cliente) y B (servidor). Para una mayor comprensin no se usan opciones (opcin MSS) y slo se indican los campos ms significativos que aparecen en las correspondientes cabeceras de informacin de control. Primer segmento (SYN = 1, SEC = 2, ...): Se usa para que la entidad TCP A se ponga de acuerdo con la entidad TCP B con el objetivo de llevar a cabo todas las funciones de control de errores y flujo en la fase posterior de transferencia de datos. Adems, indica el Nmero de Secuencia (SEC = 2) que desea usar la entidad TCP A. Asimismo, la entidad TCP A indica, a la entidad TCP B, el tamao de su Ventana (300 octetos). Segundo segmento (SYN = 1, ACK = 1, CONF = 3, SEC = 1500, ...): Se usa para confirmar (CONF = 3) el nmero de secuencia 2 que desea emplear el otro extremo de la comunicacin (A), y para indicar el nmero de secuencia 1500 (SEC = 1500) que va a emplear la entidad TCP B. Por tanto, el primer octeto de datos, enviado por A, se numerar con el valor 3. Asimismo, la
- 387 -
entidad TCP B indica, a la entidad TCP A, el tamao de su Ventana (900 octetos). Tercer segmento (ACK = 1, CONF = 1501, ...): Se usa para confirmar (CONF = 1501) el nmero de secuencia 1500 que va a utilizar el otro extremo de la comunicacin. Por tanto, el primer octeto de datos, enviado por B, se numerar con el valor 1501. Asimismo, la entidad TCP A recuerda, a la entidad TCP B, el tamao de su Ventana (300 octetos).
TCP A
(Cliente)
TCP B (Servidor)
0, DAT
SEC=3 , ACK =1, CO VENT NF=15 ANA= 01 30
01 C=15 3, SE F=30 , DATOS=0 ON =1, C TANA=900 ACK N

VE
OS=30 0
SEC=3 03,
CK=1, VENT CONF ANA= = 1501 300, D ATOS =300
O DA =1, C TANA=900, ACK VEN

. . .
01 C=15 03, SE OS=0 T NF=6
Figura 6.10.- Un ejemplo de una fase de transferencia de datos TCP sin errores. Continuando con el mismo ejemplo, la anterior Figura 6.10 muestra, en este caso (fase de transferencia de datos), una transmisin unidireccional de segmentos de informacin o datos siempre de la entidad TCP A a la entidad TCP B en modo semidplex (por una mayor simplificacin y comprensin del ejemplo). Asimismo, se supone que en dicha transmisin no se producen errores y se dispone de una ventana mxima de recepcin en A de 300 octetos y en B de 900 octetos. Se indican, nicamente, los campos ms significativos de la cabecera de informacin de control de cada segmento de informacin. Primer segmento de A a B (SEC = 3, ACK = 1, ...): La entidad TCP A transmite un primer segmento de informacin conteniendo 300 octetos en el campo de datos (DATOS = 300). El primer octeto de dicho campo de datos est identificado con el nmero 3 (SEC = 3). Asimismo, confirma (CONF = 1501) el nmero de secuencia 1501 que va a utilizar B y recuerda, a la entidad TCP B, el tamao de su Ventana (300 octetos).
- 388 -
Segundo segmento de B a A (ACK = 1, CONF = 303, ...): La entidad TCP B enva un segmento sin datos (DATOS = 0) en cuya cabecera de informacin confirma todos los octetos recibidos a travs del campo Nmero de Confirmacin (CONF = 303). Este campo contiene el siguiente nmero de octeto que espera recibir, con lo cual A entiende que todos los anteriores octetos que ha enviado a B han llegado correctamente. En funcin de lo anterior, A libera su bfer de transmisin para guardar copia de los datos que, a continuacin, va a transmitir en el siguiente segmento de informacin. Asimismo, B recuerda, a la entidad TCP A, el nmero de secuencia (SEC = 1501) que va a utilizar y su tamao de su Ventana (900 octetos). Tercer segmento de A a B (SEC = 303, ACK = 1, ...): La entidad TCP A transmite un tercer segmento de informacin conteniendo 300 octetos en el campo de datos (DATOS = 300). El primer octeto de dicho campo de datos est identificado con el nmero 303 (SEC = 303). Asimismo, vuelve a confirmar (CONF = 1501) el nmero de secuencia 1501 que va a utilizar B y de nuevo recuerda, a la entidad TCP B, el tamao de su Ventana (300 octetos). Cuarto segmento de B a A (ACK = 1, CONF = 603, ...): La entidad TCP B enva un segmento sin datos (DATOS = 0) en cuya cabecera de informacin confirma implcitamente todos los octetos recibidos a travs del campo Nmero de Confirmacin (CONF = 603). Dicho campo contiene el siguiente nmero de octeto que espera recibir, con lo cual A entiende que todos los anteriores octetos que ha enviado a B han llegado correctamente. En funcin de lo anterior, A libera su bfer de transmisin para guardar copia de los datos que, a continuacin, va a transmitir en el siguiente segmento de informacin. Asimismo, B vuelve a recordar, a la entidad TCP A, el nmero de secuencia (SEC = 1501) que va a utilizar y su tamao de su Ventana (900 octetos). ... Continuando con el mismo ejemplo anterior, la Figura 6.11 muestra en este caso (fase de transferencia de datos) una transmisin unidireccional de datos (siempre de la entidad TCP A a la entidad TCP B). Asimismo, se asume que en dicha transmisin se producen errores, disponindose de una ventana mxima de recepcin231 en A de 300 octetos y en B de 900 octetos. Se indican nicamente los campos ms significativos de la cabecera de informacin de control de cada segmento de informacin (Nmero de Secuencia y Nmero de Confirmacin). En este escenario, la
231
A su vez, la ventana mxima de transmisin en A es de 900 octetos y en B de 300 octetos.
- 389 -
entidad TCP A transmite 900 octetos (agrupados en tres segmentos) pendientes de confirmacin. As, el primer octeto est identificado con el nmero 3 (SEC = 3). Se asume que el datagrama que encapsula el segundo segmento se pierde por el camino. La entidad TCP B ante la llegada de los 300 primeros octetos procede a confirmarlos (Nmero de Confirmacin=303). La llegada a la entidad TCP A de la primera confirmacin (Nmero de Confirmacin=303) no produce una retransmisin (sta slo se produce tras el vencimiento del pertinente temporizador) sino una eliminacin en el bfer de transmisin de la copia de los 300 primeros octetos. Cuando llega a la entidad TCP B el tercer segmento de informacin, vuelve a transmitir la anterior confirmacin (Nmero de Confirmacin=303). Hay que hacer hincapi en que no se transmite un Nmero de Confirmacin=903 porque esto confirmara los octetos del segundo segmento. Al vencer los temporizadores (por no recibir las confirmaciones correspondientes) de los dos ltimos segmentos de informacin enviados por A, stos se transmiten de nuevo.
TCP A (Cliente)
SEC=303, AC K= 1,
(d ato s=300 octetos)
TCP B
CONF=1501
(Servidor)
(dat os=300 octet os)
SEC=3, AC K=1,
CONF=150 1
=1501 t os) te 3 , SEC F=30 atos=0 oc CON d (
time-out
3, ACK= (dat os=30 1, CON 0 octetos) F=1

=1501
SEC=60
1501
03, SEC CONF=3 (datos=0 octetos)

(dat os=300 octetos)
SEC=303, AC
time-out
(dat os=300 octet os)
SEC=603 , AC
K=1, CO NF=1501 1501
K=1, CO NF=
=1501 903, SEC octetos) CONF= (dat os=0
Figura 6.11.- Un ejemplo de una fase de transferencia de datos TCP con errores. Posteriormente, B confirma todos los octetos recibidos con CONF= 903. Esta ltima confirmacin ha agrupado a los dos ltimos segmentos (es el caso de los dos ltimos segmentos de informacin con SEC = 303 y SEC = 603) para mostrar otro tipo de confirmacin232 que puede tener diseada la correspondiente implementacin TCP/IP que se disponga. El documento RFC-793 da libertad para confirmar individualmente o por grupo. Obviamente, cuando se confirma por grupo se ahorra ancho de banda.
Aparte de la individual por segmento recibido como es el caso del primer segmento de informacin con SEC = 3.
232
- 390 -
Es importante resaltar que si una entidad TCP, por ejemplo B no tiene en un momento dado ningn octeto de datos que transmitir, y llegan octetos de datos desde el otro extremo (TCP A); la entidad TCP B necesita confirmarlos. Para ello, TCP B transmite una cabecera y ningn dato. Lgicamente, en la cabecera va el Nmero de Confirmacin correspondiente (p. ej., CONF = 303) y, a su vez, el campo Nmero de Secuencia contiene el nmero del primer octeto de datos que B pretende enviar (SEC = 1501) cuando disponga de informacin que transmitir. Cuando B transmita datos ms tarde, la nueva cabecera tambin tendr el mismo Nmero de Secuencia (SEC = 1501) especificado anteriormente. Con respecto a los valores que tienen que tener los temporizadores de espera de respuesta, no es lo mismo que el emisor y el receptor estn en una misma red de rea local o dispersos geogrficamente por Internet. Como ya se ha comentado con anterioridad, toda implementacin TCP/IP debe disponer de un algoritmo adaptable de retransmisin para calcular el tiempo estimado de viaje o tiempo de ida y vuelta e ir adaptando los correspondientes temporizadores en funcin de los diferentes destinos. Este proceso consiste, bsicamente, en calcular el tiempo desde que se transmite un segmento de informacin con un solo octeto de datos hasta que se recibe la confirmacin de dicho segmento. El estndar especifica que TCP debe usar una tcnica conocida como algoritmo de Karn para controlar el valor del temporizador de retransmisin mediante estimaciones dinmicas. Hay que tener en cuenta que el control de este valor en el nivel de transporte es ms complejo que en los protocolos del nivel de enlace (interfaz de la red de acceso). En el caso del nivel de enlace, el retardo esperado es muy predecible dado que las confirmaciones de recepcin se retrasan pocas veces. La ausencia de una confirmacin de recepcin en el momento esperado significa en la mayora de los casos que la trama de informacin o la confirmacin de recepcin se han perdido. En este contexto, el protocolo TCP se enfrenta a un escenario totalmente diferente. La solucin es usar un algoritmo muy dinmico que ajuste constantemente el intervalo de expiracin del temporizador mediante mediciones continuas.
- 391 -
TCP A
(Cliente)
TCP B (Servidor)
n,
FIN=1 , SEC= DATO S=0
NF=n+1 ACK=1, CO DATOS=0
C= m FIN=1, SE 0 DATO S=
AC K=1 ,
CONF= m+1 DATO S=0
Figura 6.12.- Fase de liberacin de una conexin TCP. Una vez terminada la fase de transferencia de datos, se procede a liberar de forma ordenada la conexin previamente establecida (ver Figura 6.12). Para liberar cada lado de la conexin, es necesario haber recibido previamente una confirmacin de todos los octetos enviados. Esta liberacin ordenada implica un cierre independiente en cada direccin de la conexin mediante un proceso de dilogo similar al del establecimiento. Cualquiera de las partes puede solicitar la liberacin de la conexin. Conceptualmente, este proceso suele ser el siguiente: 1. TCP A: He terminado (FIN). No tengo ms datos que transmitir. 2. TCP B: OK. 3. TCPB: Yo tambin he terminado (FIN). No tengo ms datos que transmitir. 4. TCP A: OK. En el caso de la liberacin indicada anteriormente, que suele ser la ms habitual; la conexin finaliza completamente cuando se transmite en cada sentido un segmento sin datos con el bit FIN activado. En la Figura 6.12 se indican los campos ms significativos de la cabecera de control. Primer segmento de A a B (FIN = 1, SEC = n, ...): La entidad TCP A no dispone de ms datos para transmitir y enva un segmento sin datos con el bit FIN activado (FIN = 1). Se destaca que el nmero de secuencia SEC = n tiene que tener el mismo valor que la ltima confirmacin recibida.
- 392 -
Segundo segmento de B a A (ACK = 1, CONF = n+1, ...): La entidad TCP B informa a su aplicacin de que la otra entidad ha terminado su transmisin de datos y confirma (ACK = 1, CONF = n+1) la solicitud de liberacin propuesta por el otro extremo de la comunicacin. Tercer segmento de B a A (FIN = 1, SEC = n, ...): La entidad TCP B no dispone de ms datos para transmitir y enva un segmento sin datos con el bit FIN activado. Cuarto segmento de A a B (ACK = 1, CONF = n+1, ...): La entidad TCP A confirma (ACK = 1, CONF = m+1) la solicitud de liberacin propuesta por el otro extremo de la comunicacin. A su vez, la entidad TCP A informa a su aplicacin de que la otra entidad ha terminado su transmisin de datos. Las dos partes pueden iniciar la liberacin simultneamente. En este caso, dicha liberacin de la conexin se completa cuando una de las partes ha enviado una confirmacin (ACK = 1, ...). Como no hay confirmaciones (ACK = 1, ...) de confirmaciones (ACK = 1, ...), al transmitirse la ltima confirmacin, se lanza un temporizador (ver Figura 6.13) con un tiempo de estimacin de la llegada de dicha confirmacin al destino. Este tiempo es variable en funcin de la implementacin de TCP/IP que se disponga y si se est transmitiendo por una red privada TCP/IP o por Internet. Al vencer el citado plazo de espera se libera oficialmente la conexin. Con este temporizador se da tiempo a que llegue la confirmacin (ACK = 1, ...) a su destino y a recibir potenciales segmentos retrasados u obsoletos para su eliminacin inmediata. Asimismo, se asume que durante este tiempo no se deben usar unos mismos nmeros de secuencia como medida de proteccin contra segmentos retrasados u obsoletos. En la siguiente Figura 6.13, el nico segmento vlido que puede llegar a la entidad TCP A mientras est en estado de espera, es una retransmisin desde B del segmento con el bit FIN activado. Esto ltimo ocurre si se perdi la confirmacin de A y expir el temporizador de B. La entidad TCP A arranca un temporizador con un valor inicial dos veces el tiempo mximo de vida del segmento (MSL: Maximum Segment Lifetime). Se entiende por MSL, el tiempo mximo que puede permanecer un segmento en la red antes de que sea descartado. El primer MSL tiene en cuenta el tiempo mximo que puede permanecer en la red un segmento en una direccin. El segundo MSL tiene en cuenta, a su vez, el tiempo mximo que puede permanecer en la red una respuesta en la otra direccin. La especificacin original propona un tiempo de vida mximo de un segmento de 2 minutos.
- 393 -
TCP A
(Cliente)
TCP B (Servidor)
n,
FIN=1 , SEC= DATO S=0
CONEXIN CERRADA
ONF=n+1 ACK=1, C DATOS=0
C= m FIN=1, SE DATOS=0
AC K=1 ,C
CONF= m+1 DATO S=0

CONEXIN CERRADA en B
TEMPORIZADOR
CONEXIN LIBERADA
Figura 6.13.- El temporizador final en una liberacin TCP. En una situacin normal, el procedimiento de liberacin de la conexin TCP consta de una transmisin de una confirmacin final (ACK = 1, ...) desde A hasta B. Cuando dicha confirmacin llega a B se cierra la conexin TCP por el lado de B. Finalmente, A cierra, a su vez, la suya despus de que expire su temporizador. Sin embargo es posible e inevitable (se recuerda que no hay confirmaciones de confirmaciones) que previamente se pierdan todas las retransmisiones233 efectuadas por B de segmentos finales (FIN = 1), de forma que A cierra su conexin antes de que B reciba su confirmacin final. Por tanto, B retransmite su segmento final (FIN = 1) un determinado nmero de veces y despus sale sin recibir la confirmacin de A. Asimismo, cualquiera de las partes puede invocar una liberacin abrupta, es decir, finalizar en cualquier momento de la fase de transferencia de datos y liberacin. Este tipo de terminacin se produce cuando una de las partes ha detectado un problema irrecuperable. Dicha liberacin se lleva a cabo mediante el envo de uno o ms segmentos de control con el bit RST (RESET) activado. Esto causa que TCP descarte cualquier dato almacenado en el bfer de transmisin listo para su salida.
233
Debido a que previamente se han perdido las confirmaciones de A.
- 394 -
TCP A
(Cliente)
TCP B (Servidor)
FIN=1 , SEC=
903, A CK=1, CONF DATO =1501 S=0
F=904 K=1, CON =1501, AC SEC DATOS=0

F=904 K=1, CON =1501, AC C FIN=1, SE DATOS=0
SEC=9 0 4, ACK =1, CO
DATO S=0
NF=15 02
Figura 6.14.- Un ejemplo de una fase de liberacin TCP sin datos. La Figura 6.14 muestra un tpico ejemplo de liberacin TCP sin transmisin de datos por una de las partes. Segn se ha sealado, la conexin se libera completamente cuando se transmite en cada sentido un segmento con el bit FIN activado. En dicha figura se indican los campos ms significativos de las cabeceras de control correspondientes. Primer segmento de A a B (FIN = 1, SEC = 903, ...): La entidad TCP A transmite un segmento sin datos con el bit F activado. Se resalta que el nmero de secuencia SEC=903 tiene que tener el mismo valor que la ltima confirmacin recibida en fase de transferencia de datos. Segundo segmento de B a A (ACK = 1, SEC = 1501, CONF = 904, ...): La entidad TCP B confirma (CONF = 904), con un segmento sin datos, la solicitud de liberacin propuesta por el otro extremo A de la comunicacin. Tercer segmento de B a A (FIN = 1, SEC = 1501, ...): La entidad TCP B transmite un segmento sin datos con el bit F activado. Cuarto segmento de A a B (ACK = 1, CONF = n+1, ...): La entidad TCP B confirma (CONF = 1502) la solicitud de liberacin propuesta por el otro extremo de la comunicacin.
- 395 -
TCP A
1
(Cliente)
TCP B (Servidor)
SEC=n , CON F =m S=0 SEC=m ONF=n+1, ACK=1, C 0 DATOS= DATO

ONF=n+1 SEC=m, C DATOS=p
, CON
FIN=1 ,
2 3
Entrega por parte de B de p octetos de datos
F=m+p , SEC= n+1 S=0 1 CONF=n+ C=m+p, FIN=1, SE DATOS=0 ACK=1 , CONF =m+p+ DATO 1, SEC= S=0 n+1
ACK=1
DATO
Figura 6.15.- Un ejemplo genrico de una fase de liberacin TCP con datos. Como se coment con anterioridad, otra posibilidad en la fase de liberacin de una conexin TCP es que una de las conexiones se puede cerrar porque ha terminado de transmitir datos y la otra continuar abierta (ver Figura 6.15). Es decir, una de las conexiones se puede liberar porque ha terminado de enviar informacin mientras que la otra puede continuar transmitiendo mientras tenga octetos de datos que enviar. Por ejemplo, la entidad TCP A puede cerrar su lado de la conexin transmitiendo un segmento (1) sin datos con el bit FIN activado y SEC=n ya que el contenido n del campo SEC debe coincidir con el valor de la ltima confirmacin recibida procedente de B en fase de transferencia de datos que tambin debi ser n. A su vez, si CONF=m es porque si B transmiti234 datos, el ltimo octeto de datos recibido en A ha sido m-1. Como contestacin, la entidad TCP B enva, seguidamente, otro segmento (2) con CONF=n+1. Posteriormente, B sigue transmitiendo datos y cuando termina procede, a su vez, a cerrar su lado de la conexin. Para ello, B enva un segmento (5) sin datos con el bit FIN activado y SEC=m+p. Finalmente, la entidad TCP A transmite un ltimo segmento (6) con CONF=m+p+1, completndose la liberacin de dicha conexin TCP. Se recuerda que la confirmacin del segmento 5 es CONF = n+1 y no n+1+1, debido a que el segmento 4 pertenece todava a una fase de transferencia de datos de B a A (segmentos 3 y 4). De haber confirmado B en el segmento 5 con n+1+1 implicara que, segn B, ha llegado un octeto de datos identificado con SEC=n+1, lo cual no es cierto. Consecuentemente, no se deben confundir las confirmaciones en fase de transferencia de datos con las confirmaciones en fase de establecimiento de la conexin y liberacin (en el ejemplo, las
234
En caso de que B no hubiera transmitido datos, m se corresponde con el primer octeto de datos esperado en A, lo cual ya se negoci en la fase de establecimiento de la conexin.
- 396 -
confirmaciones de los segmentos 2 y 6), en las cuales el campo de datos siempre est vaco.
TCP A
FIN=1
(Cliente)
TCP B (Servidor)
903, A CK=1,C ONF= 150 1
DATO S= 0
, SEC=
ONF=904 , ACK=1, C SEC=1501 DATOS=0 ONF=904 , ACK=1, C SEC=1501

DATO S= 0
ACK=1 , CON
300 DATOS=
F=1801 ,
SEC=9 04
Entrega por parte de B de 300 octetos de datos
NF=904 CK=1, CO C=1801, A DATOS=0 FIN=1, SE ACK=1 , CONF =1802, DATO SEC=90 S= 0 4
Figura 6.16.- Un ejemplo concreto de una fase de liberacin TCP con datos. Finalmente, la Figura 6.16 describe un ejemplo de liberacin de la conexin TCP para la fase de transferencia de datos de la Figura 6.11, en donde una de las partes (B) transmite datos despus de que la otra (A) haya enviado un segmento con el bit FIN activado. Por tanto, el lado de la conexin de A a B se cierra. Sin embargo, la conexin de B a A contina abierta ya que B desea transmitir octetos de datos a la entidad A. En el ejemplo, la entidad TCP A enva un primer segmento sin datos con el bit FIN activado, SEC=903 (A pone como nmero de secuencia el mismo valor recibido en la ltima confirmacin por parte de B) y CONF=1501 (A no confirma con 1502 porque si lo hiciera confirmara el octeto de datos 1501 transmitido por B, lo cual no es cierto ya que B en el ejemplo de la Figura 6.11 no enva informacin). Seguidamente, la entidad TCP B transmite un segmento con CONF=904. Posteriormente, B transmite un segmento de 300 octetos de datos, los cuales son confirmados por A. Una vez la entidad TCP B termina de transmitir toda su informacin, procede a enviar un segmento sin datos con el bit FIN activado, SEC=1801 y CONF=904 (B no confirma con 905 porque si lo hiciera confirmara el octeto de datos 904 transmitido por A, lo cual no es cierto ya que A ya ha cerrado su lado de la conexin). Finalmente, la entidad TCP A transmite un ltimo segmento con CONF=1802, completndose la liberacin de la conexin TCP. Como se coment anteriormente, no se deben confundir las confirmacines en fase de transferencia de datos con las confirmacines en las fases de establecimiento y liberacin de la conexin.
- 397 -
FASE DE ESTABLECIMIENTO DE LA CONEXIN Si, por ejemplo, la entidad TCP B transmite una confirmacin n+1 (ver Figura 6.7 y Figura 6.8), significa que la otra entidad TCP A va a utilizar el nmero n+1 como primer nmero de secuencia para identificar su primer octeto de datos en la posterior fase de transferencia de informacin. Por consiguiente, una confirmacin n+1 no valida ningn octeto de datos transmitido porque en fase de establecimiento de la conexin, los segmentos de control implicados no transportan ningn dato (DATOS=0). FASE DE TRANSFERENCIA DE DATOS Si una entidad TCP B transmite una confirmacin n+1, valida todos los octetos de datos enviados por A hasta el octeto n inclusive. FASE DE LIBERACIN DE LA CONEXIN Si, por ejemplo, la entidad TCP B transmite una confirmacin n+1 (ver Figura 6.12 y Figura 6.13), significa que valida el nmero de secuencia n de la otra entidad TCP A (A pone como nmero de secuencia n el mismo valor recibido en la ltima confirmacin por parte de B en fase de transferencia de datos).
- 398 -
6.2
Protocolo UDP (User Datagram Protocol)

A
APLICACIN
B
APLICACIN
SERVICIO NO FIABLE
UDP IP
INTERFAZ DE RED
INTERFAZ DE RED
UDP
IP
INTERFAZ DE RED
INTERFAZ DE RED
IP
INTERFAZ DE RED
IP
INTERFAZ DE RED
Figura 6.17.- Un ejemplo de escenario para UDP. La Figura 6.17 muestra un ejemplo de un potencial escenario del protocolo UDP (RFC768), el cual ofrece, extremo a extremo, un servicio no orientado a conexin y, por tanto, no fiable y sin control de congestiones en el nivel de transporte. En dicha figura aparecen tres redes y dos routers entre los dos sistemas finales A y B.
SERVICIO NO CONEXIN
ORIENTADO
Sin control (deteccin y recuperacin) de errores lgicos (datagramas UDP perdidos y desordenados) Con deteccin (opcional) y no recuperacin de errores fsicos Sin control de flujo Multiplexacin/Demultiplexacin Transferencias simltneas en los dos sentidos (fulldplex)
Figura 6.18.- Caratersticas ms relevantes del protocolo UDP. El protocolo de datagramas de usuario UDP (User Datagram Protocol) es un protocolo muy simple del nivel de transporte que ofrece, como ya se ha comentado anteriormente, a las correspondientes entidades del nivel de aplicacin, un servicio no orientado a conexin y, por tanto, no fiable y sin control de la congestin. Es un protocolo que proporciona dos servicios que no ofrece el protocolo IP:
- 399 -
Deteccin opcional, y sin recuperacin, de errores fsicos: Se comprueba opcionalmente la integridad del datagrama UDP completo, es decir, cabecera y datos. Se recuerda que el protocolo IP slo verifica la integridad de su cabecera de control. Para efectuar este servicio, el protocolo UDP utiliza un mecanismo de suma de comprobacin similar al empleado por el protocolo IP. Multiplexacin (origen) y demultiplexacin (destino) en funcin de los nmeros de puerto. Estas funciones principales, del protocolo UDP, proporcionan un servicio aadido al protocolo IP, el cual es capaz de entregar datagramas IP a una mquina determinada en Internet; pero incapaz de hacer lo propio con respecto a los procesos de usuario del nivel de aplicacin. Para llevar a cabo dichas funciones, UDP utiliza un mecanismo basado en nmeros de puerto.
Asimismo, y al contrario que con el protocolo TCP, la entidad del nivel de aplicacin debe pasar los datos bien delimitados235, es decir no ofrece un servicio de flujo de octetos (byte-stream). Teniendo en cuenta lo poco que ofrece el protocolo UDP, qu motivos ha habido para haber diseado este protocolo en el nivel de transporte? La respuesta es que gracias a este protocolo se evita toda la sobrecarga aadida de enviar y recibir las mltiples unidades de datos necesarias para establecer y liberar una conexin. Muchas aplicaciones236 se basan en un simple mecanismo de solicitud y respuesta con el intercambio de muy poca informacin. Asimismo, este es el protocolo ideal para aplicaciones de difusin y multidifusin al eliminar el trabajo extra de retransmitir. Consecuentemente, dichas aplicaciones no necesitan montarse sobre el protocolo TCP y s sobre otro tipo de protocolo de transporte que ofrezca una mayor rapidez en la entrega de los mensajes. Dado que los protocolos IP y UDP proporcionan servicios no orientados a conexin, puede ser necesario implementar en el propio protocolo de aplicacin todos los mecanismos de fiabilidad que no ofrecen los protocolos TCP/IP de los niveles inferiores.
Por ejemplo, en bloques de 512 octetos de longitud mxima salvo el ltimo que, generalmente, tendr menos. Por ejemplo, en el entorno de una una red de rea local, para consultas rpidas de una base de datos, servidor de fecha y hora, servidor DNS, o bien para aplicaciones de monitorizacin, gestin y prueba, etc.
236
235
- 400 -
CABECERA
DATOS
Figura 6.19.- Formato de un datagrama UDP. Segn se muestra en la Figura 6.19, un datagrama UDP engloba dos tipos de informacin: Cabecera de informacin de control: Contiene la informacin que manejan las entidades UDP para llevar a cabo sus respectivas funciones. Por las mnimas funciones de transporte que realiza, la cabecera de UDP es muy simple comparada con la cabecera de TCP. Como mnimo un datagrama UDP tiene una longitud de 8 octetos. Datos: Incluye la cabecera de informacin de control de la correspondiente aplicacin y los potenciales datos del mensaje de dicha aplicacin (si existen). Como ya se ha sealado, la entidad del nivel de aplicacin debe pasar los datos en bloques bien delimitados ya que no existe un servicio de flujo de octetos (byte-stream) como en TCP.
0
CABECERA UDP
15 16 PUERTO ORIGEN LONGITUD UDP PUERTO DESTINO
31
SUMA DE COMPROBACIN
DATOS
Figura 6.20.- Formato de la cabecera de un datagrama UDP con todos sus campos. Concretamente, (ver Figura 6.20), los campos de esta cabecera de informacin de control son los siguientes: Puerto de Origen (16 bits): Identifica al proceso de aplicacin emisor que enva un datagrama UDP; por ejemplo, en un momento dado, al proceso cliente que solicita un servicio.
- 401 -
Puerto de Destino (16 bits): Identifica al proceso de aplicacin receptor que recibe un datagrama UDP; por ejemplo, en un momento dado, al proceso servidor que proporciona el servicio solicitado. Longitud UDP (16 bits): Indica la longitud en octetos del datagrama UDP completo (cabecera y datos). Como mnimo un datagrama UDP tiene una longitud de 8 octetos. Suma de Comprobacin (16 bits): Suma aritmtica binaria o en mdulo 2 (sin acarreo o suma OR exclusiva) de todos los bloques de 16 bits del datagrama UDP completo (cabecera y datos). Si la longitud del datagrama no es mltiplo de 16 bits, el datagrama se rellena de ceros hasta hacerlo mltiplo de 16 bits. Si se detecta un datagrama UDP con errores fsicos se elimina y no se entrega al proceso de aplicacin. Su uso es opcional, es decir, si una entidad UDP de origen no desea calcular la suma de comprobacin, este campo debe contener slo ceros, de forma que la entidad UDP de destino sepa que la suma de comprobacin no se ha calculado. Puede suceder que la entidad UDP de origen calcule la suma de comprobacin y encuentre que el resultado es cero. En este caso se establece un campo de suma de comprobacin con todo a unos. Al igual que en TCP, el procedimiento de clculo es similar al utilizado por IP salvo por los dos siguientes puntos: En primer lugar, cuando la longitud del datagrama UDP no es un mltiplo de 16 bits. En este caso, el datagrama se rellena de ceros hasta hacerlo mltiplo de 16 bits; sin embargo, el datagrama real que se ha de enviar no se modifica por lo anterior. En segundo lugar, porque se incluye una pseudocabecera al inicio del datagrama UDP cuando se calcula la suma de comprobacin (ver siguiente Figura 6.21). Esta pseudocabecera que tampoco se transmite, se crea en el origen y destino durante el proceso de clculo. Dicho procedimiento le permite al mdulo UDP, por un lado, identificar inmediatamente la comunicacin a la cual pertenece el datagrama y, por otro lado, asegurarse de que el datagrama UDP ha alcanzado realmente la mquina de destino y el pertinente puerto. Amn, de que el tipo de protocolo es UDP ya que tiene asignado el valor 17.
- 402 -
0
SEUDOCABECERA UDP
15 16
31
DIRECCIN IP ORIGEN
DIRECCIN IP DESTINO
00000000 PROTOCOLO = 17 LONGITUD DEL DATAGRAMA UDP CABECERA UDP
DATOS (Variable)
Figura 6.21.- Pseudocabecera UDP.
- 403 -
6.3

Bibliografa
RFC-793: "Transmission Control Protocol". RFC-1323: "TCP Extensions for High Performance". RFC-1122: "Requirements for Internet Hosts - Communication Layers". RFC-768: "User Datagram Protocol". RFC-862: "Echo Protocol". RFC-863: "Discard Protocol". RFC-864: "Character Generator Protocol". RFC-865: "Quote of the Day Protocol". RFC-866: "Active Users". RFC-867: "Daytime Protocol". RFC-868: "Time Protocol". TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Redes Globales de Informacin con Internet y TCP/IP, Principios bsicos, protocolos y arquitectura, Douglas E. Comer, 3 Edicin, Prentice Hall, 1996. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000. TCP/IP Illustrated Volume 1: The Protocols, R.W. Stevens, Addison-Wesley, 1994. Comunicaciones y Redes de Computadores, W. Stallings, 6 Edicin, Prentice Hall, 1997. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. TCP/IP Arquitectura, protocolos e implementacin con IPv6 y seguridad de IP; Dr. Sydney Feit, Osborne McGraw-Hill, 1998.
- 404 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real
7. APLICACIONES TIEMPO REAL
DE
MULTIMEDIA
EN
Tcnicas capaces de facilitar una comunicacin interactiva integrando datos, audio y vdeo Contenidos multimedia
Radio y televisin en directo Reproducir un vdeo bajo demanda Telefona: Voz sobre IP Establecer una videoconferencia
Problemas en Internet (conmutacin de paquetes)

Retardo, prdida y entrega desordenada de los paquetes, La red y los servidores saturados Garantas mnimas de ancho de banda, retardo de propagacin y fiabilidad de la red
Soluciones:
Mejorar la velocidad de transmisin de la propia red Desarrollar y emplear mtodos de codificacin y compresin: PCM, ADPCM, RA (audio), MPEG-1, MPEG-2 (vdeo y audio), Nuevos protocolos de transporte: RTP/RTCP
Figura 7.1.- Escenario de aplicacin. En el mundo de la informtica cuando se habla de aplicaciones de multimedia, se referencia, en general, a las tcnicas y tecnologas capaces de facilitar una comunicacin interactiva con el ser humano, integrando datos, audio y vdeo. El contenido de multimedia es la parte ms popular de Internet; cada vez es ms frecuente, por ejemplo, escuchar la radio en directo, reproducir automticamente un vdeo mientras se reciben sus paquetes o entablar una vdeoconferencia con un amigo disperso geogrficamente por esa inmensa red de redes. En este escenario, uno de los mayores problemas al que hay que enfrentarse es la velocidad de conexin; por ejemplo, no todo el mundo dispone desde casa de un enlace rpido RDSI o ADSL. Adems, an disponiendo de este enlace, muchos servidores y la propia red se hallan tan saturados en determinados momentos que difcilmente se puede aprovechar la correspondiente velocidad de conexin. Por todo ello, existen bsicamente dos soluciones: Mejorar la velocidad de la propia red (algo caso imposible de forma inmediata). Desarrollar mtodos o formatos de codificacin y compresin (PCM, ADPCM, RA, MPEG-1, MPEG-2, etc), amn de nuevos protocolos de transporte (RTP/RTCP, etc.), que permitan la transmisin de la informacin multimedia con el ancho de banda actual. - 405 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real Es importante tener en cuenta que la transmisin multimedia en tiempo real exige unas garantas mnimas de ancho de banda y retardo de propagacin adems de la pertinente fiabilidad de la red. En el contexto de la fiabilidad y transmisin en tiempo real, el control de errores por parte de la red en los niveles de enlace y encaminamiento, puede ser negativa debido al retraso que producira las retransmisiones de paquetes. Por consiguiente, dicho control no lo debera efectuar la red y s los sistemas finales en los niveles superiores de su arquitectura de comunicaciones. Como parmetros de fiabilidad de la red se destacan los siguientes: Latencia en la red: Tiempo desde que se enva una informacin hasta que se recibe la oportuna respuesta. Parmetro vital para aplicaciones interactivas (p. ej., audioconferencias y vdeoconferencias) pero no, por ejemplo, para la transmisin de una pelcula. Un problema significativo es la congestin con trfico en tiempo real que empeora el correspondiente tiempo de respuesta. Capacidad en los bferes de recepcin de los sistemas intermedios: Debe haber la suficiente capacidad de almacenamiento para que no se produzca el tpico overflow. Fidelidad en la red: Parmetro variable en funcin de la correspondiente aplicacin237. Por ejemplo: La transmisin de imgenes mdicas: Exigen una fidelidad mxima (distorsin mnima) ya que son aplicaciones que no toleran ninguna variacin en la fidelidad de la imagen. Transmisin de pelculas, msica o voz: Exigen una fidelidad variable (distorsin variable) ya que son aplicaciones de multimedia que requieren que la transmisin sea en tiempo real (p. ej., las aplicaciones de voz sobre IP). En Internet, que se puede considerar como una red virtual no orientada a conexin de conmutacin de paquetes o datagramas IP238, no se garantiza que los datos de audio y vdeo vayan continuamente unos detrs de otros. Si los datos no llegan a tiempo, lo que el usuario ver y/o escuchar no estar relacionado. Para ello, se necesitan nuevos protocolos de transporte (p. ej., RTP/RTCP) responsables de que los datos de audio y vdeo vayan por la actual red Internet debidamente sincronizados y en su orden. En este contexto, es fundamental que los datos de audio y vdeo se reproduzcan en el mismo
La mayora de las veces se transmite una gran cantidad de informacin redundante y la prdida de unos cuantos paquetes puede ser inapreciable en el resultado final.
238
237
Que se pueden encaminar de forma independiente.
- 406 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real rgimen en que han sido muestreados. Se resalta que las redes de conmutacin de paquetes se desarrollaron para el transporte de datos que no tenan especiales requisitos de temporizacin. Sin embargo, los avances en diferentes campos239 hacen posible las comunicaciones en tiempo real a travs de estas redes. Pero dicha transmisin de paquetes en tiempo real, debe solventar las dificultades inherentes como: retardo de los paquetes, dispersin temporal, prdida y entrega desordenada de paquetes amn de los firewalls o cortafuegos240 que haya por el camino.
7.1
Protocolo de transporte en tiempo real: RTP

Proporciona extremo a extremo soporte para el transporte de datos (audio y vdeo interactivo) en tiempo real No proporciona garantas de calidad de servicio Incorporado en las aplicaciones sin necesidad de implementarse en un nivel separado Se encapsula sobre UDP
Multiplexado y suma de comprobacin de UDP Ms importante recibir la informacin en el momento adecuado que la fiabilidad del transporte
Cabecera de informacin de control:

Identificador de carga til (payload): Formato de los datos Marca de tiempo (Timestamp): Momento en que el primer octeto del paquete fue muestreado. Receptor reconstruye la temporizacin y reproduce los datos a la velocidad correcta Numeracin secuencial: Controlar paquetes perdidos y desordenados
Figura 7.2.- Caractersticas del protocolo RTP. RTP (Real Time Protocol), definido en el documento RFC-1889, es un protocolo de la arquitectura TCP/IP que proporciona, extremo a extremo, soporte para el transporte de datos en tiempo real como streams de audio y vdeo en envos punto a punto (unidifusin)241 o a todos los miembros de un grupo de multidifusin242. Con el trmino
Como los algoritmos de compresin, potencia de clculo en las mquinas, ancho de banda, capacidad de conmutacin de paquetes, etc. Debido a que la mayor parte de firewalls o cortafuegos bloquean al protocolo UDP, los usuarios detrs de un firewall pueden que no reciban los streams. Esto tambin se puede extender a routers NAT y PAT. Para solventar esta situacin en el caso de los firewalls, se necesita un programa de servidor proxy o en general encapsular paquetes RTP en el interior de mensajes HTTP (http tunnelling). Esto ltimo, permitir a los streams pasar a travs de firewalls o routers NAT y PAT. La mayora de las aplicaciones de streaming actuales permiten cambiar los parmetros, marcando generalmente una casilla (use http) y establecer el puerto 80 u otro usado para los transportes HTTP por los correspondientes servidores de streaming. Servicios interactivos (p.ej., telefona por Internet) y transmisiones de unidifusin o unidireccionales o unicast (p. ej., vdeo bajo demanda).
241
239
240
- 407 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real anglosajn (de difcil traduccin) de streaming se indica que se necesita un flujo secuencial, continuo y mantenido de los datos que, por otra parte, son los requisitos que requieren los servicios de multimedia en redes en tiempo real. En vez de almacenar grandes ficheros de multimedia, y reproducirlos, los datos se transmiten secuencialmente en streams por Internet. El proceso de streaming divide los datos multimedia en paquetes del tamao adecuado para su correcta transmisin entre el servidor y cliente de streaming. De esta forma, un cliente de streaming puede reproducir el primer paquete, mientras decodifica el segundo y recibe el tercero. As, dicho cliente de streaming puede disfrutar de los contenidos de multimedia sin esperar a que finalice la transmisin. Conviene resaltar la diferencia que existe con los servicios de descarga, en los cuales se realiza en primer lugar el envo de los datos y, posteriormente, se accede a los contenidos. En el streaming, el transporte, recepcin, decodificacin y reproduccin, es decir, el transporte y reproduccin de los datos se llevan a cabo de forma simultnea. Para una mayor aclaracin, se puede establecer una comparacin con los servicios de televisin: la descarga se parece al visionado de una pelcula de vdeo, donde los contenidos ya se encuentran de manera local en el receptor; mientras que el streaming se correspondera con la recepcin de un canal de televisin. RTP ha sido diseado para datos en tiempo real en donde la fiabilidad del transporte no es tan importante como la recepcin en el tiempo adecuado (se exige altos requisitos de mnimo retardo).
a
NIVEL DE APLICACIN
b
APLICACIN RTP
NIVEL DE TRANSPORTE
APLICACIN RTP
Socket UDP
INTERNET
UDP
INTERNET
RED DE ACCESO
RED DE ACCESO
Figura 7.3.- Dos vistas equivalentes de la ubicacin RTP en TCP/IP.
242
RTP se ha diseado especialmente para las transmisiones de multidifusin o multidirecciones o multicast.
- 408 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real RTP es un protocolo que intencionadamente no se ha especificado de forma completa y est ideado para ser lo suficientemente flexible como para poder ser incorporado en las aplicaciones sin necesidad de implementarse en un nivel separado. Por consiguiente, en la prctica, RTP se implementa generalmente dentro de la aplicacin ya que, por ejemplo, la recuperacin de paquetes perdidos debe implementarse en el nivel de aplicacin De ah, que tanto RTP como RTCP (que se analizar seguidamente) se han diseado para que sean independientes de los niveles subyacentes de transporte y red. Por este motivo, al ser RTP un protocolo genrico e independiente de la correspondiente aplicacin, no est ubicado en un nivel de comunicaciones independiente de la arquitectura TCP/IP. De hecho, tal y como se muestra en la anterior Figura 7.3, son totalmente vlidas conceptualmente cualquiera de las dos ubicaciones del protocolo RTP ya sea en el nivel de aplicacin o transporte de la arquitectura TCP/IP. En cualquier caso, RTP interacta va sockets a travs del protocolo UDP. RTP que no proporciona garantas de calidad de servicio, se ejecuta fundamentalmente sobre el protocolo UDP por varias razones: RTP hace uso de las funciones de multiplexado y suma de comprobacin de UDP. RTP se ha diseado pensando en los servicios de multidifusin. Consecuentemente, una conexin TCP no es lo ms apropiado por problemas de escalabilidad. Asimismo, una de las grandes desventajas del uso del protocolo UDP, para el transporte de contenidos multimedia en tiempo real, es la imposibilidad de garantizar la llegada ordenada de los paquetes de informacin a su destino. RTP ha sido diseado para datos en tiempo real. Por tanto, la fiabilidad del transporte no es tan importante como la recepcin en el tiempo adecuado. Es ms, TCP implementa la fiabilidad de la transmisin, usando retransmisin de paquetes, lo cual en el caso de trfico de datos en tiempo real es un inconveniente. Se resalta que en el caso de una congestin de la red, los paquetes perdidos ocasionarn una calidad inferior, pero aceptable. Si se retransmitieran dichos paquetes, el retardo aumentar seguramente, degradndose an ms la calidad de servicio.
- 409 -

Emisor Aplicacin Receptor Aplicacin
Vdeo (V)
RTP
Audio (A)
Vdeo (V)
RTP
Audio (A)
Cabecera RTP
SSRC
Tipo de Marca N de de Tiempo Secuencia Carga til Versin
UDP
Carga til
UDP RTP
A
UDP IP
IP
A V
IP
V A
Figura 7.4.- Un ejemplo de un envo de paquetes RTP. RTP incluye en su cabecera (ver Figura 7.4), informaciones de control que identifican el contenido o tipo de informacin transportada (carga til). Asimismo, estas informaciones sincronizan la imagen y el sonido mediante la inclusin de marcas de tiempo que reconstruyen los temporizadores y recuperan la oportuna seal de reloj. Se resalta que las aplicaciones de multimedia requieren temporizaciones apropiadas en la transmisin de datos y su reproduccin. Adems, las informaciones en la cabecera de RTP controlan la numeracin secuencial para llevar a cabo en el bfer de recepcin la reordenacin243 de los paquetes RTP si procede dentro del pertinente tiempo de espera de los mismos. Se resalta que en ningn momento hay recuperacin de paquetes RTP perdidos. Por consiguiente, RTP descarta los paquetes perdidos y no fuerza retransmisiones. Si se desea un mayor control de errores hay que implementar el mecanismo o mecanismos necesarios en el correspondiente protocolo de la aplicacin. Como campos ms representativos de la cabecera de informacin de control244 del protocolo RTP se destacan los siguientes: Versin (2 bits): Identifica la versin del protocolo RTP. La versin actual es la 2.
243
Todo ello, antes de pasarlos a la correspondiente aplicacin. La cabecera RTP es generalmente de 12 octetos.
244
- 410 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real El identificador o tipo de la carga til o payload type (7 bits): Especifica el formato de los datos, as como el esquema245 de compresin-descompresin. Obviamente, con dicho identificador, la aplicacin receptora sabe cmo interpretar y reproducir los correspondientes datos. Se resalta que en un momento dado de la transmisin, un emisor slo puede enviar un tipo de carga. Nmero de secuencia (16 bits): Nmero utilizado por el receptor para detectar paquetes perdidos y desordenados. El valor inicial se elige de forma aleatoria. Marca de tiempo (32 bits): La temporizacin es la informacin ms importante en las aplicaciones de tiempo real. As, el emisor asigna una marca temporal (timestamp) en funcin del momento en que el primer octeto del paquete fue muestreado. El receptor utiliza esta marca temporal para reconstruir la temporizacin y reproducir los datos a la velocidad correcta. Asimismo, como ya se ha comentado, las marcas temporales tambin se usan para sincronizar distintas secuencias de datos (audio y vdeo). Sin embargo, RTP por s mismo, no es responsable de la sincronizacin, ya que debe realizarse por protocolos superiores de la aplicacin. En algunos formatos de vdeo, cuando una imagen se parte en varios paquetes RTP, todos ellos llevarn la misma marca temporal; de ah que estas marcas no sean suficientes para mantener la ordenacin de paquetes y s sea necesario controlar la pertinente numeracin secuencial. Identificador SSRC o synchronization source identifier (32 bits): Es un nmero aleatorio que se utiliza para identificar la fuente o el origen246 del stream RTP, es decir, las fuentes de sincronizacin dentro de la misma sesin RTP. Indica dnde se combinaron los datos, o bien la fuente de los mismos en el caso de que hubiera una sola fuente. Por tanto, en una sesin RTP cada stream RTP dispone de su propio e inequvoco SSRC. Quiere decir esto, que el SSRC no es slo la direccin IP del emisor sino un nmero que el origen asigna aleatoriamente247 cuando se crea un nuevo stream.
245
AUDIO: 0 o PCM (64 Kbps), 3 o GSM (13 Kbps), 9 o G.722 (48-64 Kbps), 14 o MPEG audio, 15 o G.728 (16 kbps), etc., y VDEO: 26 o motion JPEG, 31 o H.261, 32 o MPEG 1 vdeo, 33 o MPEG 2 vdeo. Cmara de vdeo, micrfono, etc.
246
La probabilidad de que dos streams tengan asignados el mismo SSRC es muy pequea. Si esto sucediera las dos fuentes deben elegir un nuevo valor.
247
- 411 -
7.2
Protocolo de control RTP: RTCP

Diseado para trabajar conjuntamente con RTP Monitorizacin de la calidad de servicio: Para que el emisor pueda ajustar su transmisin, los participantes se envan peridicamente paquetes RTCP para informar, fundamentalmente, sobre la calidad de la recepcin de los paquetes RTP:
N ms alto de secuencia recibido N de paquetes perdidos N de paquetes desordenados Marcas temporales
Se encapsula sobre UDP

Figura 7.5.- Caractersticas del protocolo RTCP. RTCP (RTP Control Protocol), definido en el documento RFC-1889, es un protocolo de la arquitectura TCP/IP diseado para trabajar conjuntamente con RTP. Su objetivo es monitorizar la calidad de servicio y congestin de la red. Por consiguiente, un paquete RTCP no encapsula trozos de audio o vdeo, sino informacin del emisor y/o receptor con estadsticas que pueden ser muy tiles a la correspondiente aplicacin. En una sesin RTP, los participantes se envan peridicamente248 paquetes RTCP (ver siguiente Figura 7.6) con el objetivo de tener realimentacin, a su vez, sobre la calidad de recepcin de los paquetes RTP y para que se sepa quines estn escuchando. Esta informacin249 es muy til para que el emisor ajuste su transmisin. En este contexto, se definen cinco tipos de paquetes RTCP para transportar informacin de control. De entre ellos, se destacan los siguientes: Informe del receptor o Receiver Report (RR).- Enviado por los participantes que no son emisores activos. Dichos informes contienen datos acerca de la calidad de recepcin, es decir, acerca de cmo se estn recibiendo los paquetes RTP. Esta informacin incluye, fundamentalmente, el nmero ms alto de secuencia recibido, el nmero de paquetes perdidos, la informacin sobre paquetes
248
Las estadsticas de recepcin (en RR o SR) deben enviarse tan a menudo como lo permita el ancho de banda para maximizar la resolucin de las estadsticas.
Nmero ms alto de secuencia recibido, nmero de paquetes perdidos, nmero de paquetes desordenados, marcas temporales, etc.
249
- 412 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real desordenados y las marcas temporales para calcular el retardo de ida y vuelta entre el receptor y emisor. Informe del emisor o Sender Report (SR).- Informe transmitido por los participantes que son emisores activos. Adems de los datos sobre la calidad de recepcin (al igual que en los RR), contiene datos de sincronizacin intermedia, contadores acumulativos de paquetes y nmero de octetos enviados. BYE.- Indica el fin de la participacin.
Receptor
C RT P
Origen RTCP RTCP
Internet
Receptor
RT CP
Figura 7.6.- Un ejemplo de un envo de paquetes RTCP.
APLICACIN
N de puerto = n N de puerto = n+1
APLICACIN
N de puerto = x N de puerto = x+1
RTP UDP IP
RTCP
RTP UDP IP
RTCP
Figura 7.7.- Ubicacin de los protocolos RTP y RTCP en la arquitectura TCP/IP.
- 413 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real La anterior Figura 7.7 muestra la ubicacin250 de los protocolos RTP y RTCP en la arquitectura TCP/IP para el envo y recepcin de sus paquetes. Como se puede ver, no existe ningn nmero de puerto fijo UDP para RTP y RTCP; eso s, los receptores deben usar el mismo nmero de puerto UDP. En este contexto, el primer nmero de puerto (par) es para RTP y el siguiente (impar) para RTCP. En transmisiones de unidifusin, cada extremo de la comunicacin indica al otro el nmero de puerto en donde quiere recibir paquetes RTP. Por consiguiente, estos nmeros de puerto se distribuyen entre los participantes mediante procedimientos ajenos a RTP como es el caso del protocolo de descripcin de sesin SDP251 (Session Description Protocol, RFC-2327) del nivel de aplicacin TCP/IP. Mediante mensajes SDP se negocian las caractersticas concretas de una sesin multimedia de unidifusin o multidifusin sobre UDP (opcionalmente tambin sobre TCP) como el anuncio de la sesin, la invitacin a la sesin y otras formas de inicio de dicha sesin multimedia. Ms en concreto, se indica, entre otras informaciones, lo siguiente: nombre de la sesin, motivo (p.ej., Un seminario por la red), inicio y final de la sesin (from 1:00 pm to 2:00 PM om mon, wed, fri, in every week, for 4 month), protocolos de transporte (p.ej., RTP/UDP/IP, H.320, etc.), formatos (H.261 video, MPEG video, etc.), direcciones IP y nmeros de puerto UDP para el flujo RTP, etc. A su vez, para proporcionar informacin de la descripcin de la sesin slo para transmisiones de multidifusin, existe, en el nivel de aplicacin TCP/IP, otro protocolo de anuncio de sesin, SAP (Session Announcement Protocol, RFC-2974) que trabaja sobre UDP. Un servidor SAP, peridicamente y mediante multidifusin, transmite un paquete SAP de anuncio a una direccin especfica de multidifusin y a un nmero de puerto reservado tambin para este tipo de transmisiones. Asimismo, existe, en el nivel de aplicacin TCP/IP y sobre UDP o TCP, otro protocolo denominado SIP (Session Initiation Protocol, RFC-3261) o protocolo de iniciacin de la sesin, que soporta mecanismos de establecimiento, mantenimiento y liberacin de sesiones de multimedia o llamadas a uno o ms participantes252. Las sesiones de
Otra alternativa, como ya se coment con respecto a RTP, es situarlos en el nivel de transporte por encima de UDP.
251
250
Desarrollado por el grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) del IETF. Este grupo de trabajo se encarga de desarrollar recomendaciones relacionadas con el soporte de conferencias y fue el responsable de implementar aplicaciones para la red MBONE. Uno de los objetivos del grupo consiste en desarrollar mecanismos para informar a los usuarios acerca de las sesiones existentes en la red, requisitos de los medios, direcciones, etc.
SIP puede establecer sesiones de dos partes (llamadas telefnicas convencionales) y mltiples partes (en donde todos pueden hablar y escuchar).
252
- 414 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real multimedia pueden ser llamadas de telefona por Internet253 (voz sobre IP o VoIP254), videoconferencias y, en general, cualquier tipo de distribucin de contenidos de multimedia. La aplicacin ms tpica del protocolo SIP es la telefona por Internet, de hecho, SIP es la propuesta del IETF para la transmisin de voz sobre IP. El protocolo SIP no slo invita a un usuario o a ms usuarios a participar de una sesin de multimedia, sino que adems informa sobre parmetros fundamentales para poder participar en la sesin correspondiente. Consecuentemente, aparte de la invitacin a participar, SIP a travs del correspondiente mensaje255 y en el caso de telefona por Internet, indica, entre otras informaciones, la direccin del llamante y llamado, el tema de la llamada, y las preferencias de la respuesta que espera recibir como por ejemplo: una indicacin de que lo que desea recibir (p.ej., audio), el formato y codificacin pertinente (p.ej., PCM o GSM), el protocolo de transporte (RTP), el nmero de puerto donde espera recibir la citada informacin, etc. Asimismo, el otro lado, tambin a travs de otro mensaje anlogo, informa sobre sobre sus parmetros bsicos de recepcin. Por consiguiente, el cuerpo de la invitacin contiene una descripcin del contenido de la sesin. Opcionalmente, se puede usar el formato del protocolo de descripcin de la sesin, SDP, para realizar la citada descripcin. Asimismo, se pueden utilizar otros formatos posibles para esta misma funcionalidad; por ejemplo, los descriptores del H.245 de UIT-T. Para finalizar, conviene resaltar que el protocolo SIP slo maneja el establecimiento, control y la terminacin de sesiones, es decir, para el transporte de datos se usan otros protocolos como RTP/RTCP. Una alternativa ms compleja y sofisticada256 que lo visto a travs del protocolo SIP, es el conjunto de estndares257 o protocolos H.323 de UIT-T que permite comunicaciones
253
Los trminos de telefona por Internet y telefona IP describen dos enfoques diferentes. En la telefona por Internet, el control del servicio est en el sistema final de usuario. En este caso, el protocolo SIP dota a los sistemas finales de los mecanismos de control del servicio de telefona. Sin embargo, en el caso de la telefona IP, el establecimiento de la llamada a travs de la red se lleva a cabo por conmutadores o procesadores inteligentes conectados a los equipos terminales.
A grandes rasgos, el funcionamiento de VoIP consiste en convertir la seal analgica de la voz en un formato digital que permita comprimir y traducir la seal original en datagramas IP. Estos datagramas sern transmitidos a travs de Internet hacia el sistema final del destinatario que los transformar de nuevo en sonido.
255
254
Siempre por el nmero de puerto 5060 para SIP. SIP usa una solicitud simple que contiene toda la informacin necesaria.
256
H.245 define los mensajes de control que soportan sealizacin extremo a extremo entre dos puntos para intercambiar capacidades o prestaciones y establecer los canales RTP; H.225 para el establecimiento
257
- 415 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real multimedia en tiempo real en redes de conmutacin de paquetes y redes de rea local que no ofrezcan garantas de servicio. Al igual que SIP, soporta negociacin de parmetros, codificacin y los protocolos RTP/RTCP. H.323 no naci expresamente para Internet, sin embargo, dada la ubicuidad de esta inmensa red de redes, la mayora de las implementaciones de H.323 ya estn basadas en IP. H.323 requiere un servicio TCP extremo a extremo fiable para documentar y controlar las funciones mientras que el transporte de audio y vdeo se hace va RTP/UDP/IP. Asimismo, mediante pasarelas258 o sistemas intermedios se puede facilitar la interconexin de terminales H.323 situados en una red de paquetes (p.ej., Internet, intranets o una red privada TCP/IP) con otro tipo de terminales como los tpicos telfonos convencionales de una red telefnica pblica. Resumiendo, existen dos procedimientos para identificar y participar en sesiones multimedia: Anuncios: En su forma ms bsica las sesiones se anuncian a travs del correo electrnico, pginas Web, grupos de noticias. Una alternativa ms sofisticada es mediante protocolos del tipo SDP y SAP. Invitaciones: Mediante este procedimiento, los usuarios son invitados e informados para que puedan participar en la correspondiente sesin a travs de protocolos del tipo SIP y H323.
7.3
Protocolo de presentacin en tiempo real: RTSP
RTSP (Real Time Streaming Protocol), definido en el documento RFC-2326, es el protocolo de streaming o de presentacin de multimedia en tiempo real que permite el envo controlado de datos de multimedia en Internet. Proporciona un interfaz al estilo de un reproductor de vdeo con funciones de control remoto como pausa, avance rpido, atrs, e ir a posicin. Se ubica en el nivel de aplicacin y est diseado para interactuar con protocolos de bajo nivel como RTP. Se puede utilizar tanto para
de la llamada o conexin en redes H.323 mediante mensajes Q.931; H.235 para ofrecer servicios de seguridad (autenticacin, confidencialidad, integridad, etc); H.332 para conferencias multipunto; T.120 para la transmisin de datos (ficheros y grficos) en conferencias multimedia con mltiples usuarios; etc. Asimismo, los codecs (codificacin-decodificacin) de audio de varas calidades se rigen bajo las normas G.711 (56 y 64Kbps), G.722 (48 y 64 Kbps), G.723 (48, 56 y 64 Kbps), G.728 (16 Kbps) y G.729 (8 Kbps). A su vez, los codecs (codificacin-decodificacin) de vdeo se rigen bajo las normas H.261 (64 kbps) y H.263 (20 Kbps para vdeo y 6,5 Kbps para audio). Transmiten la informacin de sealizacin desde la red de paquetes a otras redes. En aplicaciones de telefona llevan a cabo el establecimiento de la llamada entre las redes de paquetes y las redes pblicas de telefona.
258
- 416 -
Captulo 7. Aplicaciones Multimedia en Tiempo Real unidifusin (unicast) como multidifusin (multicast). RTSP pretende proporcionar para presentaciones de multimedia, los mismos servicios que HTTP ofrece para textos y grficos. De hecho, se ha diseado intencionadamente con una sintaxis similar, de tal modo que se puede aadir a RTSP la mayor parte de los mecanismos de extensin de HTTP. En RTSP cada presentacin y stream se identifica por una direccin de URLRTSP. Sin embargo, RTSP difiere de HTTP en ciertos aspectos. En primer lugar, HTTP es un protocolo sin estados y RTSP ha de mantener los estados de la sesin para enlazar las solicitudes con los streams relacionados. En segundo lugar, HTTP es asimtrico en el sentido semidplex (transmisin bidireccional simultnea) de que toda respuesta de servicio necesita previamente de una solicitud; es decir, cuando el cliente realiza una solicitud, el servidor responde; mientras que en RSTP, ambos, cliente y servidor pueden realizar solicitudes. Las solicitudes RTSP se transmiten, como norma general por un canal independiente del canal de datos. Fundamentalmente, trabaja sobre UDP pero tambin puede hacerlo sobre TCP.
7.4
Los protocolos de multimedia en TCP/IP
Para una mayor comprensin, en la siguiente Figura 7.8 se muestra una panormica de la ubicacin de los diferentes protocolos de multimedia, anteriormente comentados, en el contexto de la arquitectura TCP/IP.
H.261, MPEG
G.711
PCM
SDP SIP
H.323
RTSP
SAP RTCP
RTP
TCP
IP
ARP INTERFAZ DE RED HARDWARE ICMP
UDP
PPP
Figura 7.8.- Los niveles multimedia TCP/IP.
- 417 -
7.5

Bibliografa
RFC-1889: RTP: A Transport Protocol for Real-Time Applications, AudioVideo Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. RFC-2326: Real Time Streaming Protocol (RTSP), H Schulzrinne, A. Rao, R. Lanphier, April 1998. RFC-2327: SDP: Session Description Protocol. RFC-3266: Support for IPv6 in Session Description Protocol (SDP). RFC-2974: Session Announcement Protocol. RFC-3261: SIP: Session Initiation Protocol. RFC-3265: Session Initiation Protocol (SIP)-Specific Event Notification Computer Networks. Cuarta edicin. A. S. Tanenbaum. Ed. International 2003. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Servicios de vdeo sobre redes mviles de nueva generacin, R. Bernrdez, J. Lpez, A. Ferreras, J.L. Garca (Telefnica Investigacin y Desarrollo) y J. Lpez, J. Lorente (Telefnica Mviles Espaa), Comunicaciones de Telefnica I+D, 21, junio 2001.
- 418 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones
8. ARQUITECTURAS DE SOFTWARE Y NIVELES INTERMEDIOS (MIDDLEWARE) DE COMUNICACIONES PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS
Este captulo tiene como objetivo presentar de manera muy conceptual los principales modelos o tecnologas en el desarrollo de aplicaciones en red. Consecuentemente, se pretende, como objetivo fundamental, proporcionar los conocimientos bsicos para el desarrollo de software en redes de comunicaciones teniendo en cuenta los mecanismos de comunicaciones ms relevantes y los diferentes protocolos de transporte TCP/IP utilizados. Es importante resaltar que por encima del nivel de transporte de la arquitectura TCP/IP existen unos niveles intermedios (middleware) de comunicaciones que basan su funcionamiento en distintos protocolos de comunicaciones259 que conviene conocer y diferenciar.
Modelos de cliente/servidor orientados a:

Llamadas a funciones: sockets Llamadas a procedimientos remotos: RPC Llamadas a objetos distribuidos: RMI, JINI, CORBA,
COM + y Enterprise Java Beans
Servicios Web distribuidos: XML, SOAP, WSDL y UDDI. Agentes Mviles: Programacin remota
Figura 8.1.- Alternativas en el desarrollo de aplicaciones en red. Para el desarrollo de aplicaciones distribuidas o en red segn el modelo clienteservidor, existen los siguientes modelos:
Stub cliente-stub servidor en RPC, stub-skeleton en RMI, IIOP entre el ORB cliente y servidor en CORBA, SOAP entre clientes y servidores Web distribuidos, etc.
259
- 419 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Modelos basados en llamadas a funciones: Interfaz de Sockets de la Universidad de Berkeley: Para el entorno Unix. Interfaz de Windows Sockets (Winsock API) de Microsoft Corporation: Para el entorno Windows de Microsoft. Muy similar al interfaz de sockets de la Universidad de Berkeley. Interfaz de Sockets en Java de Sun Microsystems: Para el entorno Java (multiplataforma). Se llama a las funciones del pertinente interfaz de sockets a travs de clases Java. Modelos basados en llamadas a procedimientos remotos: RPC (Remote Procedure Call) de Sun Microsystems (Sun RPC): Aunque existen otros sistemas RPC similares260, ste es el sistema RPC ms extendido y utilizado. Proporciona un software o nivel intermedio (middleware) entre el cliente y el servidor que aisla al programador de tener que trabajar directamente con el correspondiente interfaz de sockets y, por tanto, con las correspondientes funciones de comunicaciones. Ahora, es el propio sistema RPC el que hace las llamadas directas al interfaz de sockets que siempre est por debajo. Es importante resaltar que RPC es la filosofa operativa que encierra los fundamentos de base de otros modelos de desarrollo de aplicaciones en red en el contexto de los objetos o componentes distribuidos y en el desarrollo de servicios Web distribuidos. Dichos modelos se mencionan a continuacin. Modelos basados en llamadas a objetos distribuidos: RMI (Remote Method Invocation): Creado por Sun Microsystems como mecanismo de comunicacin entre objetos remotos Java. JINI: Creado por Sun Microsystems como mecanismo de comunicacin basado en eventos distribuidos entre objetos remotos Java. Se fundamenta en un procedimiento de publicaciones de eventos, suscripciones a los mismos, y notificaciones de dichos eventos. Por tanto, sin interacciones de solicitud-respuesta. Concretamente, un objeto que genera eventos, publica los tipos de eventos que estarn accesibles remotamente por observacin para otros objetos. As, los objetos que quieran recibir notificaciones de un
260
RPC del DCE (Distributed Computing Environment) de X/OPEN y RPC de Xerox Courier.
- 420 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones objeto remoto que ha publicado sus eventos, se suscriben a los tipos de eventos en los que estn interesados. JINI es ms ambicioso que RMI al incluir no slo RMI sino unos servicios propios y una metodologa de desarrollo con roles totalmente definidos. CORBA: (Common Object Request Broker Architecture) Diseado por el grupo OMG (Object Management Group) como mecanismo de comunicacin, a travs de su middleware de comunicaciones o bus de objetos ORB (Object Request Broker), entre objetos remotos heterogneos para el entorno de objetos escritos en cualquier lenguaje de programacin e independientemente de su ubicacin fsica, del tipo de mquina y sistema operativo, de los protocolos de comunicaciones subyacentes, etc. COM+ (Common Object Model Plus): Creado por Microsoft Corporation en el entorno Windows orientado a objetos y que dispone de su propio bus de objetos totalmente incompatible al ORB de CORBA. Es la evolucin de DCOM (Distributed Component Object Model) y representa el modelo de componentes distribuidos para la plataforma .NET. Por tanto, es una clara alternativa a CORBA pero en el contexto de plataformas Windows orientadas a objetos. El escenario bsico es un componente COM cliente interactuando con un componente COM servidor a travs de una red de rea local va el sistema DCE (Distributed Computing Environment) RPC del grupo X/OPEN. Enterprise Java Beans: Creado por Sun Microsystems para el entorno Java de desarrollo de componentes proporcionando funcionalidades empresariales especficas (lgica y datos del negocio). Permite integrar fcilmente aplicaciones clientes con bases de datos encerrando reglas empresariales o la lgica y datos del negocio. Es el modelo de componentes distribuidos de Sun para su plataforma de desarrollo J2EE (Java 2 Enterprise Edition)261. Por tanto, a travs de esta tecnologa los usuarios, sin necesidad de ser programadores profesionales, pueden desarrollar aplicaciones personalizadas a partir de componentes reutilizables.
J2EE (Java 2 Enterprise Edition): Plataforma avanzada de desarrollo en Java cuyo modelo de componentes, va RMI (o RMI IIOP para integrarse con CORBA), es Enterprise JavaBeans. Java 2 SDK (Software Development Kit) Standard Edition es la plataforma bsica para el desarrollo de pequeas aplicaciones distribuidas.
261
- 421 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Modelo basado en servicios Web distribuidos: Es una tecnologa que, a su vez, utiliza los siguientes estndares: XML: Lenguaje de codificacin que define la sintaxis de los mensajes entre clientes y servidores Web distribuidos. SOAP: Protocolo de envo de mensajes XML entre clientes y servidores Web distribuidos. WSDL: Lenguaje de descripcin de servicios Web distribuidos. UDDI: Protocolo de localizacin y publicacin de servicios Web distribuidos. Modelos basados en agentes mviles: Representan, a travs del concepto de programacin remota, un nuevo paradigma de programacin para el desarrollo de aplicaciones en red; alternativo a los modelos indicados anteriormente. En determinadas aplicaciones distribuidas es la solucin ideal para el diseo, implementacin y mantenimiento de las mismas mediante una delegacin de tareas que requieren la visita de diversas plataformas o entornos de ejecucin por la red.
8.1
Desarrollo de aplicaciones en red: Sistemas distribuidos

servidor
cliente
Enva al proceso servidor una solicitud especfica de servicio
Proporciona un servicio en la red
PROCESO CLIENTE
PROCESO SERVIDOR
Figura 8.2.- Procesos bsicos de interaccin en red. Como ya se ha indicado, la mayora de las aplicaciones en red funcionan segn el modelo de cliente-servidor. En este escenario un cliente es un proceso que enva al proceso servidor una solicitud especfica de servicio, y un servidor es, a su vez, un proceso que proporciona el correspondiente servicio en la red.
- 422 -

I) TERMINALES CONECTADOS PUNTO A PUNTO A UN SISTEMA CENTRAL
II) ORDENADORES PERSONALES EN REDES DE REA LOCAL

Cliente Cliente Servidor
Cliente
Cliente
(Red de rea Local)
RAL
Servidor Cliente
Un servidor (mainframe) y terminales sin disco duro
Cliente Cliente n clientes : 1 servidor
Figura 8.3.- Evolucin en el acceso a los servicios (I). En este escenario basado en interacciones entre procesos clientes y servidores ha habido una clara evolucin en la forma en que se accede a los diferentes servicios proporcionados por un determinado proceso servidor. PRIMERA ETAPA: ARQUITECTURA CENTRALIZADA.- Surgen los primeros terminales conectados punto a punto a un sistema central que se encarga de toda la carga de proceso y computo. Dichos terminales ni siquiera disponan de CPU y disco duro con lo cual se limitaban, bsicamente, a la visualizacin por pantalla de los resultados del servicio ofrecido por el servidor. SEGUNDA ETAPA: ORDENADORES PERSONALES EN REDES DE REA LOCAL.- Posteriormente, aparecieron los ordenadores personales que contribuyeron al asentamiento de las tecnologas cliente-servidor en redes de rea local mediante la tpica interaccin entre n clientes y un solo servidor. TERCERA ETAPA: INTERNET (e intranets).- Seguidamente, surgieron los sistemas distribuidos con la aparicin de Internet como red mundial de redes y las redes intranets como redes privadas TCP/IP conectadas a Internet. Pues bien, el desarrollo del fenmeno de Internet, junto con los avances tcnicos en el campo de las tecnologas de la informacin, permitieron la creacin de un nuevo tipo de aplicaciones: las llamadas aplicaciones distribuidas en las que se integran multitud de clientes y servidores a travs de n clientes y m servidores. Por consiguiente, en este nuevo escenario un servicio puede estar soportado por mltiples servidores.
- 423 -

III) INTERNET
n clientes : m servidores Cliente
Cliente
Cliente
Servidor
Servidor
INTERNET (intranets)
Cliente Servidor Servidor Cliente
Cliente
Figura 8.4.- Evolucin en el acceso a los servicios (II). En la siguiente Figura 8.5 se muestra el escenario de servicios tan tpicos en Internet como Web, SMTP, DNS, News, etc., en los cuales un proceso servidor se transforma, a su vez, en cliente de otro proceso servidor. En definitiva, son servicios soportados por mltiples procesos servidores.
cliente
SERVICIO
servidor
PROCESO SERVIDOR
cliente
PROCESO CLIENTE PROCESO SERVIDOR PROCESO CLIENTE PROCESO SERVIDOR
servidor
servidor
Servicios: Web, DNS, News, ...
Figura 8.5.- Un servicio proporcionado por mltiples servidores.
- 424 -
ARQUITECTURAS DE CLIENTE/SERVIDOR EN DOS NIVELES

Cliente grande/Servidor pequeo Cliente pequeo/Servidor grande Cliente /Servidor compensados
ARQUITECTURAS DE CLIENTE/SERVIDOR EN TRES NIVELES

Middleware: Software intermedio entre el cliente y el servidor
RPC, RMI, ORB, Agencias (agentes mviles), JDBC, ODBC, ...
Figura 8.6.- Tipos de arquitecturas de cliente-servidor. Partiendo del hecho de que el modelo de cliente-servidor divide una aplicacin en dos o ms componentes o procesos especializados, distribuyendo la ejecucin de los mismos entre uno o ms equipos; la variante ms sencilla de dicha arquitectura es la denominada de dos niveles. En una arquitectura de cliente-servidor de dos niveles, el cdigo de la aplicacin se encuentra repartido en mayor o menor medida entre el proceso cliente y el proceso servidor dando lugar a tres variantes: Cliente grande-servidor pequeo262, cliente pequeo-servidor grande263 y cliente-servidor compensados264. A medida que las aplicaciones han crecido en complejidad, han ido apareciendo nuevas necesidades de procesamiento solventadas mediante una arquitectura de clienteservidor de tres niveles. Esta ltima arquitectura introduce un nivel intermedio que facilita265 la labor del programador que ya no tiene que trabajar a bajo nivel con las funciones de comunicaciones Dicho nivel intermedio es lo que se conoce como middleware o software intermedio entre el cliente y el servidor. Ahora, por ejemplo, el cliente no accede directamente al servicio proporcionado por el servidor sino que delega en el citado middleware el acceso a dicho servicio. Se pueden citar como ejemplos ms
262
La mayor parte de la lgica de la aplicacin se encuentra en el lado del cliente. La mayor parte de la lgica de la aplicacin se encuentra en el lado del servidor. El cdigo de la aplicacin se encuentra repartido de forma equitativa entre el cliente y servidor.
263
264
Adems de independizar al proceso cliente de cualquier cambio realizado en el proceso servidor. Esto ltimo plantea una situacin especialmente crtica en un modelo de dos niveles con un cliente grande en donde la mayor parte del cdigo se ejecuta en dicho cliente.
265
- 425 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones representativos de middleware, los siguientes: RPC, RMI, JINI, ORB266, agencias267, JDBC-ODBC268, etc.
APLICACIONES O SERVICIOS
MIDDLEWARE
SISTEMA OPERATIVO
PLATAFORMA
Servicios especficos: ORB, RMI, JDBC, ...
General: TCP/IP, SPX/IPX, ...,
HARDWARE: Computadora y red
Figura 8.7.- Niveles de servicio de software y hardware. La anterior Figura 8.7 muestra la arquitectura de niveles de software y hardware en el contexto de los sistemas distribuidos. A su vez, se hace una clara distincin entre un middleware de servicios especficos (ORB, RMI, CORBA, JDBC, etc.) y un middleware general que ocupa un subnivel inferior en la arquitectura en cuestin. Dicho middleware general se relaciona con los protocolos de comunicaciones empleados.
Web
......
Internet
SMTP DNS
Web
......
Web
SMTP
Figura 8.8.- Ejemplos de sistemas distribuidos por Internet.
266
Object Request Broker o intermediario de solicitudes entre objetos en la arquitectura CORBA. Entornos de ejecucin de los agentes mviles. Para conectar aplicaciones Java (JDBC) o en otro lenguaje (ODBC) con bases de datos.
267
268
- 426 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Un sistema distribuido se puede definir como un conjunto cooperante y transparente de componentes de hardware y software remotos que se comunican entre s mediante el intercambio de mensajes y que presenta dos caractersticas fundamentales: Est basado en una arquitectura en dos y tres niveles. Define un servicio particular ofrecido en una red de computadoras. Por ejemplo, y como muestra la anterior Figura 8.8, los servicios Web (HTTP), DNS, News, correo (SMTP), etc., los cuales se consideran servicios particulares o propios de Internet. El objetivo de un escenario de este tipo es aplicar soluciones distribuidas a diferentes problemas computacionales que se puedan dividir en distintos subproblemas cuyo tratamiento se pueda efectuar en diferentes mquinas por Internet. A la hora de crear un sistema distribuido o lo que es lo mismo una aplicacin en red, es importante tener en cuenta los siguientes retos de diseo que debe cumplir el sistema en cuestin. As, en el mejor de los casos, un sistema distribuido tiene que ser: Heterogneo: El acceso al servicio debe ser independiente de las redes, mquinas, protocolos de comunicaciones, sistemas operativos, lenguajes de programacin e implementaciones. Abierto: Especificacin, documentacin y publicacin de los interfaces de los componentes clave. Seguro: Con mecanismos que ofrezcan servicios de seguridad como autenticacin, control de acceso, confidencialidad, integridad y no repudio. Escalable: Facilidad para incrementar el nmero de componentes y recursos. Controlable en fallos: Con mecanismos de deteccin, recuperacin, redundancia269 y aviso de cadas de componentes y recursos de informacin y computacin. Concurrente: Comparticin de componente y recursos entre usuarios. Transparente: El sistema distribuido debe verse como un todo y no como un conjunto de componentes aislados e independientes.
269
O duplicidad de componentes y recursos
- 427 -
8.2
Modelos de llamadas a funciones: Interfaces de sockets

APLICACIN
TRANSPORTE
Sockets
INTERNET
RED DE ACCESO
Figura 8.9.- Interfaz entre el nivel de transporte y aplicacin. Este modelo se va a centrar en el interfaz bsico o frontera entre el nivel de transporte y nivel de aplicacin. Este lmite est representado por los llamados puntos de acceso o sockets a travs de los cuales se establecen comunicaciones entre procesos clientes y servidores de las correspondientes aplicaciones. Como ya se ha estudiado, por cada proceso cliente-servidor existe una pareja de sockets, es decir, un socket en el lado cliente y otro en el lado servidor. Durante el desarrollo y evolucin de los protocolos TCP/IP y all en la dcada de los 80, la Universidad de Berkeley (California) desarroll un interfaz de programacin de aplicaciones (API de sockets) basado en unas libreras de funciones270 escritas en el lenguaje C para facilitar, especialmente271, la creacin e integracin de nuevas aplicaciones en la arquitectura TCP/IP y, por tanto, en Internet. Un interfaz de sockets es, bsicamente, un conjunto de funciones y estructuras a las cuales debe llamar directamente el programador de la aplicacin desde la parte cliente y servidora para poder montar la aplicacin sobre TCP o UDP.
270
<sys/socket.h>, <netdb.h> y <netinet/in.h>.
271
En realidad, los diseadores de Berkeley crearon un interfaz basado en un conjunto de funciones que soportaran las comunicaciones en red de un modo general con el objetivo de acomodar otras pilas de protocolos (protocolos XNS de Xerox, DECnet de Digital, SNA de IBM, etc.) y no slo TCP/IP.
- 428 -

Aplicacin de Usuario
Interfaz de Sockets
TCP
UDP
IP
Interfaz de Acceso y Hardware
Red
Figura 8.10.- Ubicacin del interfaz de sockets en la arquitectura TCP/IP. Con respecto a los modelos de cliente-servidor orientados a llamadas a funciones o modelos basados en la programacin directa con sockets; el primer interfaz que se desarroll fue el de la Universidad de Berkeley y representa, por tanto, la base de otros interfaces como el Interfaz de Windows Sockets (Winsock API) de Microsoft Corporation y el Interfaz de Sockets en Java de Sun Microsystems. Como se ha comentado con anterioridad, el Interfaz de Sockets de la Universidad de Berkeley est basado en un conjunto de libreras de funciones escritas en el lenguaje C (para el sistema operativo Unix) que definen funciones y estructuras a las cuales debe llamar el programador desde el programa del cliente y servidor. Estas funciones (ver siguiente Figura 8.11) en el lado del cliente son las siguientes: Socket: Mediante la llamada a esta funcin, y a travs de los correspondientes parmetros de la llamada272, se obtiene un valor entero o descriptor273 (sockfd)
272
FAMILIA DE DIRECCIONES o Address Family (p.ej., direcciones TCP/IP y ms en concreto: AF_INET para IPv4 o AF_INET6 para IPv6), TIPO DE SOCKET en funcin del tipo de servicio deseado (p.ej., SOCK_STREAM que indica un servicio orientado a conexin o a bytes en el nivel de transporte o SOCK_DGRAM que indica un servicio no orientado a conexin o a datagramas en el nivel de transporte o SOCK_RAW que indica un servicio no orientado a conexin o a mensajes en el nivel Internet o IP. SOCK_RAW se usa para el acceso directo a protocolos de ms bajo nivel como es el caso de IP o ICMP. En estos casos, el nmero de puerto es 0 ya que no existe el nivel de transporte), y TIPO DE PROTOCOLO DE COMUNICACIONES (p.ej., IPPROTO_TCP o IPPROTO_UDP o IPPROTO_IP o 0 y, en este ltimo caso, el sistema elige automticamente el protocolo en funcin del tipo de socket indicado como segundo parmetro. Sin embargo, hay aplicaciones especializadas que indican un valor del protocolo para usar un protocolo especfico, como es el caso del 1 para IPPROTO_ICMP).
- 429 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones que identifica el socket. Posteriormente, el programador, en su lado del cliente, escribe el cdigo274 del socket o punto de acceso haciendo uso de una estructura (sockaddr_in) incluida en otra librera del interfaz (netinet/in.h). Si ocurre un error275, el resultado de la llamada a esta funcin devuelve el valor -1.
CL NTE IE
Seleccin protocolo
SE RVIDOR
Seleccin protocolo
Socket
Seleccin puerto
Socket
Bind
Seleccin puerto
Bind
TCP
Seleccin destino
UDP
TCP
Definicin cola
UDP
Lectura
Conexin TCP
Listen
Connect
Proceso peticin
Recvfrom
Envo
Accept
Envo
Lectura
Envo
Lectura
Sendto
Write
Read
Sendto Recvfrom
Lectura
Read
Envo
Send
Liberar
Close
Liberar
Close
Figura 8.11.- Programando con el interfaz de sockets.
Por ejemplo, el programador escribe en el cdigo del cliente: descriptor = socket (AF_INET, SOCK_STREAM, 0). El sistema de gestin de ficheros (File System Management) de Unix localiza los descriptores de sockets en la misma tabla de descriptores de ficheros como si fuera otro fichero. Por tanto, no puede haber un descriptor de fichero y socket con el mismo nmero. En la estructura de datos para el socket (sockaddr_in) se define la Familia de direcciones (p.ej., AF_INET), tipo de socket (p.ej., SOCK_STREAM), direccin IP local, nmero de puerto local, direccin IP remota y nmero de puerto remoto.
274
273
Por ejemplo, nom.sin_port = *port (contenido apuntado por la direccin almacenada en la variable port), nom.sin_addr.s_addr = INADOR_ANY (cualquier direccin de cualquier interfaz de E/S de la mquina), nom.sin_port = AF_INET. Tabla de descriptores llena o permiso denegado para crear un socket o el sistema no tiene espacio en bfer disponible o un error en los parmetros.
275
- 430 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Bind: Mediante la llamada a esta funcin, y a travs de los correspondientes parmetros de la llamada276, se enlaza un especfico y determinado nmero de puerto local y la direccin IP local del cliente al socket del cliente cuyo descriptor se ha obtenido en la llamada a la funcin socket anterior. Este paso es opcional en el proceso cliente y de no realizarse, que es lo ms habitual, el sistema operativo asignar dinmicamente un nmero de puerto libre (fuera del rango de nmeros reservados) y junto con la direccin IP lo enlazar al descriptor del socket del cliente. Connect: Mediante la llamada a esta funcin, y a travs de los correspondientes parmetros de la llamada277, el proceso del cliente TCP establece una conexin con el proceso del servidor TCP, conectando el socket del cliente y el socket del servidor TCP mediante el intercambio de los tres segmentos de establecimiento de una conexin de TCP. El protocolo UDP, aunque utiliza los sockets para identificar cada punto de acceso en la comunicacin, no establece conexiones entre sockets ya que el servicio es no orientado a conexin; pero s puede, opcionalmente, hacer uso de la funcin connect para no tener que repetir la direccin IP remota y el nmero de puerto remoto con cada llamada a una funcin de comunicacin (p.ej., write) posterior. Write278 y Read279: Para enviar datos y recibir datos del socket remoto, respectivamente, va TCP y UDP. Sendto280 y Recvfrom281: Para enviar datos y recibir datos del socket remoto, respectivamente, va UDP.
276
Descriptor del socket del cliente, direccin IP, nmero de puerto local y longitud del parmetro anterior (addrlen) debido a que se pueden usar diferentes formatos de direcciones. En realidad, el segundo y tercer parmetro es un puntero (*myaddr) con la direccin a una estructura (sockaddr_in) que contiene la direccin IP remota y el nmero de puerto remoto.
Descriptor del socket del cliente, direccin IP remota, nmero de puerto remoto y longitud del parmetro anterior (addrlen) debido a que se pueden usar diferentes formatos de direcciones. En realidad, el segundo y tercer parmetro es un puntero (*servaddr) con la direccin a una estructura (sockaddr_in) que contiene la direccin IP remota y el nmero de puerto remoto.
278
277
Los parmetros de la llamada a esta funcin son: el descriptor del socket local, el puntero con la direccin donde se encuentran los datos que se van a enviar y el nmero de octetos que se van a transmitir. La llamada a esta funcin retorna el valor -1 si los datos escritos exceden la capacidad del sistema o es un intento de escribir en un socket stream no conectado o los parmetros son invlidos o es un error de E/S. Los parmetros de la llamada a esta funcin son: el descriptor del socket local, el puntero con la direccin donde se almacenarn los datos que se van a recibir y la longitud del bfer. La llamada a esta funcin retorna el valor -1 si los parmetros son invlidos o es un error de E/S
279
- 431 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Close282: Para liberar o cerrar el socket del cliente de la conexin TCP283. El sistema debe asegurarse que se enve cualquier dato dentro del kernel que todava no haya sido transmitido y que est en cola. Esta funcin devuelve un 0 si tiene xito y un -1 para indicar que ha ocurrido un error.
A su vez, las funciones que hay que llamar desde el lado servidor (ver anterior Figura 8.11) son las siguientes: Socket: El servidor tiene un papel meramente pasivo en el establecimiento de la comunicacin con el pertinente proceso del cliente. Pero al igual que en el lado del cliente, y mediante la llamada a esta funcin a travs de los correspondientes parmetros de la llamada284, se obtiene un valor entero o descriptor que identifica el socket. Posteriormente, el programador en su lado del servidor escribe el cdigo del socket o punto de acceso haciendo uso de una estructura (sockaddr_in) incluida en otra librera del interfaz (netinet/in.h). Bind: Mediante la llamada a esta funcin, y a travs de los correspondientes parmetros de la llamada285, se enlaza el nmero de puerto local y la direccin IP local del servidor al socket del servidor cuyo descriptor se ha obtenido en la llamada a la funcin socket anterior. Listen: A travs de la llamada a la funcin de escucha de la cola de solicitudes de conexin, y a travs de los correspondientes parmetros de la llamada286, el
Los tres primeros parmetros son similares a los indicados para la funcin write. Seguidamente, aparece un puntero (*to) a una estructura (sockaddr_in) en donde se guarda la direccin IP de la mquina remota y el nmero de puerto remoto. Finalmente, el ltimo parmetro es la longitud del parmetro anterior (addrlen) debido a que se pueden usar diferentes formatos de direcciones. Esta funcin devuelve el nmero de octetos enviados si tiene xito y un -1 para indicar que ha ocurrido un error. Los tres primeros parmetros son similares a los indicados para la funcin read. Seguidamente, aparece un puntero (*from) a una estructura (sockaddr_in) en donde se guarda la direccin IP de la mquina remota y nmero de puerto. Finalmente, el ltimo parmetro es la longitud del parmetro anterior (addrlen) debido a que se pueden usar diferentes formatos de direcciones. Esta funcin devuelve el nmero de octetos enviados si tiene xito y un -1 para indicar que ha ocurrido un error
282 281
280
El nico parmetro de la llamada es el descriptor del socket local. A travs del envo de un segmento con el bit de control FIN activado. Mismos parmetros que en la llamada a la funcin socket en el lado del cliente. Mismos parmetros que en la llamada opcional a la funcin bind en el lado del cliente.
283
284
285
Descriptor del socket local y nmero de solicitudes de conexin que pueden ser encoladas por el sistema. Generalmente, este valor suele ser 5. Esta funcin devuelve un 0 si tiene xito y un -1 para
286
- 432 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones proceso del servidor convierte el descriptor de su socket en un socket pasivo de escucha; indicando al sistema operativo que acepte un nmero mximo de solicitudes de conexin pendientes de aceptacin y proceso. El software del servidor consta de un lazo infinito que acepta la prxima conexin entrante, la trata y, entonces, vuelve a procesar la siguiente. Accept: Mediante la llamada a esta funcin, y a travs de los correspondientes parmetros de la llamada287, el proceso del servidor obtiene la direccin IP remota y el nmero de puerto remoto. En UDP no hay llamada a esta funcin, por tanto, la direccin IP remota y el nmero de puerto remoto se obtienen de otra funcin (Recvfrom). Write288 y Read289: Para enviar datos y recibir datos del socket remoto, respectivamente, va TCP. Sendto290 y Recvfrom291: Para enviar datos y recibir datos del socket remoto, respectivamente, va UDP. Close292: Para liberar o cerrar el lado del servidor de la conexin TCP293.
indicar que ha ocurrido un error o por parmetro invlido o porque el tipo de socket no soporta a esta funcin.
287
Descriptor del socket del servidor, direccin IP remota, nmero de puerto remoto y longitud del parmetro anterior (addrlen) debido a que se pueden usar diferentes formatos de direcciones. En realidad, el segundo y tercer parmetro es un puntero (*peer) con la direccin a una estructura (sockaddr_in) que contiene la direccin IP remota y el nmero de puerto remoto. Mismos parmetros que en la llamada a la funcin write en el lado del cliente Mismos parmetros que en la llamada a la funcin read en el lado del cliente Mismos parmetros que en la llamada a la funcin sendto en el lado del cliente. Mismos parmetros que en la llamada a la funcin recvfrom en el lado del cliente El nico parmetro de la llamada es el descriptor del socket local. A travs del envo de un segmento con el bit de control FIN activado.
288
289
290
291
292
293
- 433 -
SERVIDOR
socket( )
CLIENTE
bind( )
socket( )
listen( )
ESTABLECIMIENTO CONEXIN
connect( )
write( )
accept( )
BLOQUEO HASTA RECIBIR CONEXIN DEL CLIENTE
DATOS (SOLICITUD)
read( )
PROCESAMIENTO SOLICITUD
read( )
close( )
DATOS (RESPUESTA)
write( )
close( )
Figura 8.12.- Las funciones del interfaz de sockets para TCP.
SERVIDOR
CLIENTE
socket( )
bind( )
recvfrom( )
BLOQUEO
socket( )
sendto( )
BLOQUEO
DATOS (SOLICITUD)
PROCESAMIENTO SOLICITUD
recvfrom( )
DATOS (RESPUESTA)
sendto( )
Figura 8.13.- Las funciones del interfaz de sockets para UDP.
- 434 -
8.3 Modelos de Sistemas RPC
llamadas
procedimientos
remotos:
Aparte del modelo bsico orientado a llamadas a funciones, otra manera ms cmoda de desarrollar aplicaciones TCP/IP, segn el modelo de cliente-servidor, es mediante llamadas a procedimientos remotos a travs de un sistema RPC (Remote Procedure Call). Como muestra la Figura 8.14, un sistema RPC proporciona un nivel intermedio o middleware de comunicaciones en la arquitectura TCP/IP con el objetivo de hacer las llamadas correspondientes al interfaz de sockets (nivel inmediatamente inferior) y poder desarrollar e integrar aplicaciones en la arquitectura TCP/IP de una forma ms sencilla.
RPC
Interfaz de sockets
TCP IP
UDP
Red
Figura 8.14.- Ubicacin de un sistema RPC en la arquitectura TCP/IP. Segn este modelo de desarrollo, el programador no tiene que interactuar directamente con el interfaz de sockets porque es el sistema RPC el que lo hace. Por tanto, el programador se centra totalmente en lo que es el diseo de su aplicacin, olvidndose completamente de cmo hay que trabajar con la red.
- 435 -
Cliente( ) {
RED
Solicitud (parmetros) Respuesta (resultados)
...
Funcin Remota( );
Servidor( ) {} Funcin Remota( ); {
... }
... }
Objetivo: Aislar al programador de los detalles de interaccin con la red (sockets)

Figura 8.15.- Descripcin grfica del funcionamiento de un sistema RPC. Como se refleja en la Figura 8.15, un sistema RPC se basa en llamadas a procedimientos remotos que el proceso cliente siempre ve como llamadas directas a procedimientos locales294. El objetivo es abstraer al programador de los detalles de interaccin con la red, es decir, de tener que trabajar directamente con las funciones de comunicaciones como se hace a travs de un API de sockets, en donde el programador debe conocer las funciones de comunicaciones y saber cmo llamarlas. Otro objetivo consiste en que el proceso cliente vea al proceso servidor como un procedimiento local ms en su propia mquina cuando en realidad dicho servidor se est ejecutando remotamente por la red. Mediante un sistema RPC, el programador se centra nicamente en el desarrollo de su aplicacin tanto en su parte cliente como servidora; pero dejando a un lado todo lo relacionado con las comunicaciones entre dichas partes. Ser el correspondiente sistema RPC el encargado de comunicar las distintas partes desarrolladas por el programador. Consecuentemente, la filosofa operativa de un sistema RPC parte del modelo conceptual para llamadas a procedimientos convencionales que se muestra en la siguiente Figura 8.16. Dicho modelo conceptual se basa en el tpico modelo convencional debidamente estructurado en diferentes funciones o procedimientos que se ejecutan en una misma mquina.
Aun cuando estos procedimientos servidores remotos se ejecutan realmente en mquinas dispersas por Internet.
294
- 436 -
PROGRAMA CONVENCIONAL main
proc1
proc2
proc3
proc4
proc5
proc6
proc8
proc7
Figura 8.16.- Modelo conceptual para llamadas a procedimientos convencionales.
Mquina 1
Mquina 2
main
proc1
proc2
proc3
proc4
proc5
proc6
proc8
proc7
Figura 8.17.- Una extensin al modelo de procedimientos. Pues bien una pequea extensin distribuida del modelo convencional de procedimientos que se describe en la Figura 8.16 es la que se refleja, a su vez, en la Figura 8.17. Si se contina repartiendo las funciones o procedimientos en distintas mquinas y se intentan comunicar dichos procedimientos, se obtiene el modelo mostrado en la siguiente Figura 8.18. Dicho modelo, que da origen al tpico sistema distribuido, se basa en llamadas a procedimientos remotos que se ejecutan en diferentes mquinas y que desde el punto de vista RPC, el cliente siempre los ve como procedimientos locales, interactuando con todos ellos mediante llamadas directas.
- 437 -

Cliente cdigo para el prograrma main Servidor
cdigo para el procedimiento A
Servidor
cdigo para el procedimiento B
main
call proc. remoto A
call proc. remoto B
Exit
Respuesta al llamante
Respuesta al llamante
Figura 8.18.- Modelo de procedimientos en sistemas distribuidos. Utilizando el modelo OSI como una referencia estndar de niveles de comunicaciones (ver siguiente Figura 8.19), se puede apreciar el nivel en el que estn ubicados los distintos elementos del sistema RPC de Sun Microsystems. Se recuerda que ste es el sistema RPC ms extendido y utilizado.
7. Aplicacin 6. Presentacin 5. Sesin 4. Transporte 3. Red 1 y2. Enlace/Fsico

TCP
XDR
RPC
sockets
UDP
IP
Red
Figura 8.19.- El sistema RPC de Sun y el modelo OSI. En el nivel de presentacin est la correspondiente sintaxis comn de codificacin, representacin y transferencia que se ocupa, a su vez, de la sintaxis de las informaciones intercambiadas entre las pertinentes entidades del nivel de aplicacin. Mediante este mtodo comn de representacin y codificacin se independiza la sintaxis local de cada mquina y se consigue que todas entiendan un mismo lenguaje. En este contexto, hay que tener en cuenta que existen mquinas que utilizan:
- 438 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Diferentes mtodos para numerar sus enteros (Big Endian/Little Endian): Por ejemplo, las mquinas de IBM numeran sus octetos a partir del octeto ms significativo o de mayor orden o ms a la izquierda (Big Endian). sta es tambin la numeracin que se utiliza en Internet. Distintos cdigos, que codifican los caracteres con uno o dos octetos, Distintos mtodos para representar los nmeros en coma flotante, etc. En este escenario, el emisor realiza un marshalling, es decir, codifica los datos a un formato o sintaxis comn de representacin y transferencia. El receptor, realiza a su vez el proceso contrario o unmarshalling, es decir, decodifica los datos al formato nativo. As, segn se muestra en la siguiente Figura 8.20, todo sistema RPC se cimenta en un software interno estucturado en dos procedimientos o mdulos de comunicaciones del sistema conocidos como stubs (cabos). De tal manera que cuando el proceso cliente solicita un servicio, hace una llamada a un procedimiento del proceso servidor pasndole los parmetros necesarios para su ejecucin. Esta llamada provoca, a su vez, la ejecucin del stub del cliente (dentro del propio proceso cliente) que intercepta la llamada y realiza el marshalling, encapsulando los resultados procedentes del proceso servidor en un mensaje en el formato (distribucin de campos) definido por el protocolo entre el stub del cliente y el stub del servidor segn la sintaxis XDR (si se utiliza el sistema RPC de Sun). A su vez, este mensaje XDR se encapsula en un segmento TCP o datagrama UDP, el cual a su vez se incluye en un datagrama IP para su encapsulacin final en la pertinente trama. Seguidamente, cuando el mensaje en sintaxis XDR llega al stub del servidor, dicho mdulo realiza a su vez el unmarshalling, desencapsulando los parmetros para hacer una llamada en la forma normal al proceso servidor. Finalmente, el stub del servidor realiza el marshalling, encapsulando los resultados procedentes del proceso servidor en un mensaje en el formato (distribucin de campos) definido por el protocolo entre el stub del cliente y el stub del servidor segn la sintaxis XDR que pasa a la correspondiente entidad del nivel de transporte (TCP o UDP) para su envo al proceso cliente invocador del servicio. Por consiguiente, todo sistema RPC se fundamenta en un protocolo de comunicaciones entre el stub del cliente y stub del servidor que define la estructura de los mensajes intercambiados, as como las oportunas acciones que hay que realizar al respecto. Consecuentemente, sera totalmente incompatible conectar el stub del cliente de un sistema RPC con el stub del servidor de otro sistema, debido a que los protocolos manejados por ambos, aunque parecidos, son completamente diferentes y, por tanto, los mensajes y su sintaxis tambin. Asimismo, se resalta la importancia del concepto IDL que se analiza seguidamente, ya que a travs de este lenguaje, la especificacin de un servicio es puramente declarativa, - 439 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones es decir, est separada de su implementacin. De esta forma, para el cliente es totalmente transparente cmo est implementado el servicio. Lo realmente importante es que el stub del cliente y stub del servidor utilicen un mismo formato de mensajes (mensajes del protocolo) con una sintaxis comn y, por tanto, se puedan entender a travs de un mismo protocolo de comunicaciones (protocolo stub cliente-stub servidor). Por consiguiente, si el sistema RPC dispone de los compiladores adecuados, se puede implementar un cliente en un lenguaje y el servidor en otro. Este concepto es de una enorme importancia como ya se ver al estudiar CORBA.
Cliente
1
10
Stub del cliente

2
9
Stub del servidor

7
5 6
Servidor
Entidad de transporte
3 8
RED
Figura 8.20.- Procesamiento de una llamada a un procedimiento remoto. A su vez, la siguiente Figura 8.21 muestra la programacin en RPC a travs de un sistema RPC genrico. Mediante un lenguaje de descripcin del interfaz o IDL (RPCL en el sistema RPC de Sun) se define el interfaz de acceso al proceso servidor, indicando: el identificador de dicho proceso servidor, su nmero de versin, los procedimientos de servicio y los tipos de datos de los parmetros de entrada y salida. Seguidamente, se compila el anterior fichero IDL con el correspondiente compilador IDL para el lenguaje en el que se va a desarrollar tanto el cliente como el servidor. Como resultado de la compilacin anterior, se obtienen los stubs del cliente y servidor, as como un fichero cabecera295 que hay que incluir en los ficheros fuentes del cliente y servidor y, tambin, en los correspondientes stubs. Posteriormente, se compilan los ficheros fuentes del cliente y servidor, as como los stubs de stos. Finalmente, se montan los objetos cliente-servidor y objetos stubs con la librera en tiempo de ejecucin RPC (RTL), la cual contiene todas las funciones RPC, incluyendo el interfaz de sockets con todas las funciones de comunicaciones y la librera de sintaxis XDR. El resultado, de todo lo anterior, son los ejecutables del cliente y servidor, que se puede instalar en la misma mquina o en mquinas dispersas por Internet.
295
Con las redefiniciones de tipos de datos IDL al lenguaje de desarrollo utilizado.
- 440 -
Fichero fuente IDL

Compilador IDL Stub cliente
Cabecera
Stub servidor
Fuente cliente
Runtime library (RTL)
Compilador
Fuente servidor
Compilador Objetos servidor y stub
Objetos cliente y stub
Montador Ejecutable cliente
Montador Ejecutable servidor
Figura 8.21.- La programacin mediante un RPC genrico.
Sistema Local
Proceso Cliente
call A parms
Prog ver proc xid parm parm
Sistema Remoto
Proceso Servidor A Procedimiento de Servicio
Stub cliente
xid parm parm
Stub servidor
Sistema Local
Proceso Cliente
call A parms
Sistema Remoto
2 3 Portmapper
Proceso Servidor A
Procedimiento de Servicio
Stub cliente
1 Stub servidor
Figura 8.22.- RPC: Portmapper y puertos dinmicos. Finalmente, la anterior Figura 8.22 muestra un componente adicional RPC llamado Portmapper, fundamental en los servidores RPC cuyos nmeros de puerto, en la mayora de los casos, se asignan dinmicamente por el sistema operativo. Esto ltimo elimina la necesidad de usar puertos predefinidos. El Portmapper es un servidor RPC con el mismo nmero de puerto, el 111, tanto para TCP como UDP. La comunicacin entre un proceso cliente y servidor RPC se lleva a cabo a travs de los siguientes tres pasos:
- 441 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones 1. Previamente, va stub del servidor, el proceso servidor RPC se registra automticamente ante el servidor Portmapper (ver anterior Figura 8.22), indicando su identificador de programa, nmero de versin, protocolo de transporte y nmero de puerto296. Seguidamente, a travs del stub del servidor se queda a la escucha de cualquier potencial cliente. 2. El proceso cliente transmite, va stub del cliente, un mensaje especial RPC (ver anterior Figura 8.22) para averiguar el nmero de puerto asignado previamente al proceso servidor. El servidor Portmapper responde a dicha solicitud con la correspondiente informacin que llega al proceso cliente a travs de su stub cliente. 3. El cliente, a travs de su stub, (ver anterior Figura 8.22) enva un mensaje XDR (en el sistema RPC de Sun) con la siguiente informacin: identificador del proceso servidor (prog), nmero de versin (ver), nmero de procedimiento o funcin (proc), identificador de transaccin297 (xid) y parmetros de la llamada (parm). Este mensaje llega al proceso servidor mediante su propio stub. A su vez, el servidor, a travs del stub, construye otro mensaje XDR (en el sistema RPC de Sun) con la respuesta correspondiente: identificador de transaccin (xid) y resultados del servicio (parm). Se vuelve a recordar que todo sistema RPC se fundamenta en un protocolo de comunicaciones entre el stub del cliente y el stub del servidor que define el formato de los mensajes intercambiados, as como las oportunas acciones que hay que realizar a la llegada de dichos mensajes.
296
Asignado por el sistema operativo
Para asociar solicitudes con respuestas: Toda respuesta tiene que tener el mismo identificador que la solicitud.
297
- 442 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones En la siguiente Figura 8.23 se muestra otra forma ms concreta de representar grficamente lo anteriormente comentado.
Red Stub de Cliente Transporte Portmapper
(Servidor RPC) Puerto 111 (TCP/UDP) registro
Cliente
Stub Servidor Servidor
1 2
A la escucha
n de puerto del servidor?
4
Ah va!
solicitud de servicio en formato XDR
6
resultados del servicio en formato XDR
Figura 8.23.- Diagrama de interaccin de RPC. Seguidamente, se comentan las caractersticas fundamentales de un sistema RPC. Modo de operacin: Asimtrico (semidplex).- Toda respuesta necesita previamente de una solicitud. Sncrono: Existe una parada y espera desde que se enva una solicitud hasta que se recibe una respuesta. Slo soporta solicitudes sncronas para transmisiones de unidifusin298 o unicast sobre TCP o UDP. Servidor RPC: Pseudoconcurrente.- Atiende mltiples clientes a la vez pero los va procesando de uno en uno. Iterativo.- Atiende una operacin y no procesa otra hasta que no acaba la primera.
En el caso del sistema RPC de Sun, existe la opcin de la difusin (broadcast) sobre UDP. Por ejemplo, para el caso de un proceso servidor que transmite un aviso general como puede ser una impresora transmitiendo el mensaje de que no hay papel. La difusin sobre TCP implicara una enorme sobrecarga por los establecimientos de conexin y potenciales retransmisiones.
298
- 443 -

CLIENTE RPC SERVIDOR RPC
SO LIC ITU D
ASIMTRICO
(SEMIDPLEX)
TA ES U SP RE
Figura 8.24.- Modo de operacin asimtrico.

CLIENTE RPC SERVIDOR RPC
SO L IC ITU D
(PARADA Y ESPERA)
SNCRONO
A ST UE SP RE
Figura 8.25.- Modo de operacin sncrono. Finalmente, como se indic con anterioridad, existen diversos sistemas RPC, totalmente incompatibles299 entre ellos. En concreto, existen tres que se indican a continuacin: RPC de Sun (Sun Microsystems ONC: Open Network Computing, 1985). RPC de X/OPEN (X/OPEN DCE: Distributed Computing Environment): Procede a su vez del sistema RPC de HP (Hewlett Packard), el cual proviene a su vez del sistema RPC de Apollo (RPC/NCA: Network Computing Architecture/NCS: Network Computing System, 1985). RPC de Xerox (Xerox Courier o RPC Courier, 1981).
299
Como ya se ha mencionado, sera totalmente incompatible conectar el stub del cliente de un sistema RPC con el stub del servidor de otro sistema. Lo anterior es consecuencia de que los protocolos manejados por ambos, aunque parecidos, son completamente diferentes.
- 444 -
8.3.1 Sistema RPC de Sun Microsystems

El sistema RPC de Sun definido en los documentos RFC-1831 (RPC v2) y RFC-1832 (XDR) como sistema que es, dispone de los siguientes elementos: RPCL.- Es el IDL300 de acceso a un programa servidor, el cual incluye la sintaxis XDR, adems del identificador de dicho proceso servidor, su nmero de versin, los procedimientos de servicio y los tipos de datos de los parmetros de entrada y salida. Esta sintaxis XDR define los tipos de datos avanzados (enumeraciones, uniones, estructuras, tipos definidos por el usuario, etc.). RPCGEN.- Es el compilador IDL. Existen tres compiladores: C ANSI C K&R C ++ Quiere decir esto que va IDL, los clientes y servidores que se desarrollen se puede implementar en cualquiera de esos tres lenguajes. Protocolo de comunicaciones entre el stub del cliente y el stub del servidor que define el formato de los mensajes intercambiados (solicitudes y respuestas); amn de las acciones que hay que llevar a cabo posteriormente. XDR (External Data Representation) que define la sintaxis comn de codificacin, representacin y transferencia. Como se indic anteriormente es un subconjunto de RPCL. RTL (Run Time Library).- Es la librera en tiempo de ejecucin que contiene todas las funciones necesarias que necesita el sistema RPC y el programador, incluyendo entre otros elementos las libreras de XDR y del interfaz de sockets. Portmapper.
300
El lenguaje de descripcin del interfaz es muy prximo al lenguaje C.
- 445 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones A su vez, como ya se describi para el caso de la programacin en RPC a travs de un sistema RPC genrico (ver Figura 8.21), la Figura 8.26 muestra la programacin en RPC a travs del sistema RPC de Sun.
Fichero fuente IDL

Compilador IDL (pma.h)
(pma.x)
(pma_clnt.c) Stub cliente
(pma_svc.c) Stub servidor
Cabecera
Fuente cliente
Compilador
Fuente servidor
Compilador Objetos servidor y stub
Objetos cliente y stub
Montador Ejecutable cliente
Montador Ejecutable servidor
Figura 8.26.- La programacin mediante el sistema RPC de Sun.
- 446 -
8.4
Modelos orientados a objetos distribuidos
No hay duda de que Internet ha entrado ya en la era de los objetos301, fundamentalmente de los objetos Java302, y, hoy en da, una gran cantidad de la programacin en red se lleva a cabo mediante dicha tecnologa303. Pues bien, el fundamento operativo visto en las llamadas a procedimientos se traslada a este nuevo tipo de programacin mediante las invocaciones a mtodos, aprovechando todas sus ventajas.
Objeto Cliente Objeto Servidor
Objeto Cliente
Objeto Cliente
RED
Objeto Cliente
Objeto Servidor
Objeto Servidor
Objeto Cliente
Figura 8.27.- Modelo cliente-servidor con objetos distribuidos (I). En la Figura 8.27 se muestra un ejemplo de diferentes interacciones entre objetos clientes y objetos servidores ejecutndose en distintas mquinas. Sin embargo, tal y como se describe en la siguiente Figura 8.28, los objetos servidores tambin pueden ser objetos clientes de otros objetos servidores que se ejecutan en la misma mquina o en mquinas diferentes por la red.
301
Y de los componentes distribuidos como se estudiar ms adelante al hablar de CORBA.
Java se ha consolidado durante los ltimos aos como uno de los lenguajes ms populares en el contexto de Internet ya que proporciona a los programadores la flexibilidad, potencia y portabilidad que las aplicaciones Web necesitan.
303
302
El ejemplo ms tangible de la absorcin del paradigma de objetos es el servicio Web cuya evolucin tuvo su origen en la difusin electrnica de documentos HTML.
- 447 -
CS
CS C
S C S C
S C C
Figura 8.28.- Modelo cliente-servidor con objetos distribuidos (II). En este escenario basado en llamadas o invocaciones a mtodos remotos se pasa, a continuacin, a analizar los mecanismos de middleware de comunicaciones ms relevantes orientados a objetos distribuidos.
8.4.1 JAVA RMI

La tecnologa de middleware RMI (Remote Method Invocation) desarrollada por Sun Microsystem es similar a la tecnologa RPC pero en Java en el sentido de que se basa en invocaciones a mtodos remotos que el cliente siempre ve como invocaciones directas a mtodos locales. RMI no es propiamente un modelo de objetos distribuidos sino una tcnica para comunicar objetos Java entre s por medio de la invocacin a mtodos remotos de forma transparente a los clientes. Fundamentalmente, la tecnologa RMI se aplica al desarrollo de pequeas aplicaciones distribuidas ya que RMI no proporciona ningn servicio aadido salvo un esquema de localizacin y nombrado de objetos en forma de servicio de nombres (RMI Registry304). Pero al igual que para un sistema RPC, el objetivo bsico de RMI es facilitar la labor en este caso al programador de objetos y que ste se asle mediante una serie de niveles de abstraccin de todos los detalles de interaccin con la red.
En RMI se implementa un registro (Registry) que acta como servidor de nombres y permite la localizacin de objetos remotos.
304
- 448 -

Llamada a un Mtodo Remoto Valor de Retorno
Objeto Cliente Mquina Virtual X
Objeto Servidor Mquina Virtual Z
RMI
RMI
TCP/IP
Computadora 1
TCP/IP
Computadora 2
INTERNET
Figura 8.29.- Procesamiento de una llamada a un mtodo remoto. Como muestra la Figura 8.29, existe un objeto que realiza una llamada a un mtodo de un objeto remoto. Al objeto que realiza la llamada se le denomina objeto cliente y al objeto sobre el que acta el mtodo se le denomina objeto remoto u objeto servidor. Por consiguiente, segn se muestra en la siguiente Figura 8.30, RMI se cimenta en un software interno basado en dos objetos de comunicaciones del sistema conocidos como stub (cabo del cliente) y skeleton (esqueleto del servidor). De tal manera que cuando el objeto cliente solicita un servicio, hace una invocacin a un mtodo del objeto servidor, pasndole los parmetros del mtodo necesarios para su ejecucin. Esta invocacin provoca, a su vez, la ejecucin del objeto stub del cliente (dentro del propio objeto cliente) que intercepta la llamada y encapsula los parmetros de dicha invocacin en un mensaje en el formato de la mquina virtual Java (JVM: Java Virtual Machine). A su vez, este mensaje JVM se encapsula en un segmento TCP o datagrama UDP, el cual a su vez se incluye en un datagrama IP para su encapsulacin final en la pertinente trama. Seguidamente, cuando el mensaje XDR llega al objeto stub del servidor, dicho objeto desencapsula los parmetros para hacer una llamada en la forma normal al mtodo objeto servidor. Finalmente, una vez se ha ejecutado el mtodo remoto, el objeto stub del servidor captura y encapsula el valor de retorno del mtodo del objeto servidor en un mensaje en formato JVM que pasa a la correspondiente entidad del nivel de transporte (TCP o UDP) para su envo al objeto cliente invocador del servicio.
- 449 -

valor de retorno
parmetros
Stub
2
9
parmetros
Skeleton
7
bloque de datos empaquetados de retorno
Objeto Cliente
bloque de datos empaquetados
1
10
5 6
Objeto Servidor
valor de retorno
3 8
RED
Figura 8.30.- Mecanismo de comunicacin entre el stub y skeleton. Es importante resaltar que en RMI no existe IDL ya que slo hay un lenguaje que es Java. Por consiguiente, como ya se ver, a diferencia de CORBA que implementa los interfaces en IDL, en RMI, los interfaces se desarrollan en Java que es el nico lenguaje soportado por dicha tecnologa. Asimismo, no hay marshalling o codificacin a una sintaxis comn ni unmarshalling o decodificacin ya que el formato es JVM. Obviamente, si existe todo un protocolo de comunicaciones entre el stub y skeleton que define el formato de los mensajes intercambiados (solicitudes y respuestas). Para poder programar en RMI es imprescindible en primer lugar descargarse del sitio de Sun el paquete Java 2 SDK (Software Development Kit) Standard Edition en su ltima versin305. Seguidamente, se realizan los siguientes pasos: 1. Se escribe el cdigo del interfaz del objeto servidor (interfaz.java) y se compila (con javac) obtenindose el correspondiente cdigo objeto (interfaz.class). 2. Se escribe el cdigo del objeto servidor que implementa el interfaz (servidor.java) y se compila (con javac), obtenindose el correspondiente cdigo objeto (servidor.class). 3. Se compila el resultado del paso anterior, es decir, servidor.class con el compilador de RMI (rmic) y se obtiene el stub.class y skeleton.class. Como se puede ver, el procedimiento que se sigue es diferente que en RPC. Aqu, a partir de la implementacin del servidor se obtiene el stub del cliente y el skeleton del servidor.
305
Actualmente la versin 1.4.1_01.
- 450 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones 4. Se escribe el cdigo del objeto cliente (cliente.java) que va a usar el citado interfaz y se compila (con javac), obtenindose el correspondiente cdigo objeto (cliente.class). 5. Se incluye el stub.class en el mismo directorio que el cliente o se descarga automticamente con classloader. Para finalizar, indicar que el sistema RMI consta de cinco paquetes de interfaces y clases: 1. java.rmi: Contiene clases, interfaces y excepciones para los clientes. 2. java.rmi.server: Contiene clases, interfaces y excepciones para los servidores. 3. java.rmi.registry: Contiene clases, interfaces y excepciones tiles para localizar y registrar objetos remotos. 4. java.rmi.dgc: Contiene clases, interfaces y excepciones para la recoleccin de basura. 5. java.rmi.activation: Contiene clases, interfaces y excepciones para la activacin de objetos remotos.
8.4.2 CORBA
La tecnologa o modelo CORBA (Common Object Request Broker Architecture) o Arquitectura Comn para la Mediacin de Solicitudes entre Objetos, es una arquitectura comn de componentes distribuidos que se basa fundamentalmente en un nivel intermedio o middleware de comunicaciones denominado bus de objetos ORB (Object Request Broker) o intermediario o tratante de las solicitudes entre objetos. La arquitectura CORBA ha sido desarrollada por el grupo OMG (Object Management Group) en 1990 para hacer frente a las necesidades actuales de interoperabilidad entre productos hardware y software. Con el objetivo de que el lector se haga una idea rpida de su funcionamiento, CORBA se puede definir como un RPC sobre el bus ORB con una serie de servicios aadidos para facilitar la programacin de aplicaciones en red. Ms en concreto, CORBA es una especificacin abierta que define una arquitectura comn de componentes distribuidos con el objetivo de permitir la comunicacin e interoperabilidad entre objetos remotos heterogneos a travs de su bus de objetos ORB para la creacin de sistemas distribuidos mediante llamadas a mtodos remotos independientemente: Del lenguaje de implementacin de los objetos. De la localizacin fsica de los objetos. - 451 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Del estado de ejecucin de los objetos. De la arquitectura o hardware de la plataforma de ejecucin y su sistema operativo. De los protocolos de comunicaciones subyacentes. Y de cualquier otro aspecto que no est definido en el interfaz de acceso al servicio.
Por consiguiente, las necesidades de interoperabilidad, mencionadas anteriormente, llev al grupo OMG a disear dicha arquitectura para facilitar el desarrollo de sistemas distribuidos mediante la tecnologa de objetos; pero objetos implementados en cualquier lenguaje de programacin y que se comunican va IDL (Interface Definition Lenguaje) independientemente de cualquier lenguaje especfico de implementacin y, como ya se ha indicado, a travs de su bus de objetos ORB. Se destaca que CORBA slo conecta objetos y no implementaciones. Asimismo, se recuerda que CORBA es una especificacin que representa el estndar de facto de una arquitectura abierta para la especificacin del aspecto y la interoperabilidad (descubrimiento y relaciones) de los componentes que habitan su bus de objetos ORB. Adems, y como ya se ver ms adelante, OMG ha definido un extenso conjunto de servicios distribuidos. Antes de continuar, conviene destacar que el grupo OMG es una organizacin internacional creada en 1989 y formada por fabricantes (multinacionales) de sistemas y equipos informticos, fabricantes o desarrolladores de software, compaas consultoras y comerciales, universidades, laboratorios y centros de investigacin, representantes de usuario, etc. En definitiva un enorme abanico en el contexto de la computacin, a excepcin hecha de Microsoft que a travs de su COM+ o modelo de componentes distribuidos para la plataforma .NET, dispone de su propio bus de objetos, y representa una clara alternativa a CORBA pero en el escenario de las plataformas Windows orientadas a objetos. Por tanto, se puede afirmar que actualmente CORBA es el lider en el contexto de los componentes distribuidos ya que COM+ a diferencia de CORBA no es una especificacin general para guiar las diferentes implementaciones de diferentes fabricantes. En este aspecto, COM+ es un modelo de componentes menos ambicioso que CORBA.
- 452 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Conviene resaltar que OMG no desarrolla software, slo especificaciones, es decir, CORBA es una especificacin abierta o gua de diseo y no una implementacin306. Por tanto, para el desarrollo de las oportunas especificaciones dentro de CORBA, el grupo OMG est estructurado en diferentes grupos de trabajo (Task Force) que se reparten en distintas reas: Diseo y anlisis de objetos, servicios y facilidades. Dichos grupos generan unos documentos, dentro de su rea, conocidos como solicitudes de propuestas RFP (Request For Proposals) que no son ms que solicitudes a los miembros del grupo OMG de soluciones software (implementaciones) a ciertas necesidades. A partir de todas las soluciones aportadas, se vota la mejor y se genera la pertinente especificacin OMG. En 1991 se gener la primera especificacin de una arquitectura ORB conocida como CORBA (CORBA1.0). Seguidamente, en agosto de 1996 apareci la especificacin de CORBA 2.0 para solventar la falta de interoperabilidad entre los ORB de diferentes fabricantes. Esto era as porque con la primera arquitectura ORB no se usaba una misma sintaxis normalizada de intercambio de mensajes de solicitudes y respuestas entre el ORB cliente y el ORB servidor. Adems, el formato de las referencias a objetos tambin era diferente. Ante esta situacin, dentro de la especificacin de CORBA 2.0 apareci el protocolo GIOP (General Inter-ORB protocol) o protocolo General InterORB que puede implementarse sobre cualquier nivel de transporte orientado a conexin de cualquier arquitectura de comunicaciones. GIOP es un protocolo de solicitudrespuesta que define un formato estndar de los mensajes para referenciar y localizar objetos remotos, indicar errores, etc. Para el caso de Internet y TCP/IP se dise a su vez un GIOP sobre TCP que se denomin protocolo IIOP (Internet Inter-ORB Protocol o protocolo Internet Inter-ORB. Consecuentemente, IIOP est diseado para ser usado directamente sobre TCP a diferencia de GIOP que puede ser usado con cualquier protocolo de transporte orientado a conexin. El objetivo de GIOP e IIOP es el mismo, es decir, que se use una misma sintaxis de los mensajes para los ORB del mismo o diferente fabricante, comunicndose en la misma o en diferentes mquinas. Finalmente, en la evolucin de CORBA surgieron las versiones: CORBA/IIOP 2.1 (septiembre de 1997). CORBA/IIOP 2.2 (febrero de 1998). CORBA/IIOP 2.3 (diciembre de 1998). CORBA/IIOP 2.3.1 (junio de 1999).
Actualmente existen ms de 70 implementaciones comerciales de productos ORB (implementaciones de CORBA) que incluyen servicios de objetos y facilidades siguiendo las directrices de la especificacin de CORBA. Ms adelante se indican algunos de ellos.
306
- 453 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones CORBA/IIOP 2.4 (octubre de 2000). CORBA/IIOP 2.4.1 (noviembre de 2000). CORBA/IIOP 2.4.2 (febrero de 2001). CORBA/IIOP 2.5 (septiembre de 2001). CORBA/IIOP 2.6 (diciembre de 2001). En dichas versiones se incluyeron nuevos servicios y facilidades. Posteriormente, ha aparecido una nueva versin ms de la especificacin de CORBA conocida como CORBA 3.0; actualmente, CORBA/IIOP 3.0.2 (diciembre de 2002) en donde se proporciona un soporte ms completo para componentes y una mayor definicin de interfaces de servicios. En este contexto y antes de seguir avanzando conviene diferenciar entre objetos y componentes. Un componente es un objeto u elemento integrable, interoperable y reutilizable de un sistema a otro y que dispone de una serie de propiedades como, por ejemplo, la irrelevancia de su lenguaje de programacin, localizacin fsica y, adems, su interfaz de interaccin se descubre dinmicamente.
Implementacin real Implementacin real
CLIENTE
Implementacin ficticia IDL del objeto cliente
SERVIDOR
Interfaz de servicio del objeto serviodr
Stub IDL cliente
Implementacin ficticia IDL del objeto servidor Invocacin mtodo remoto
Skeleton
IDL servidor
ORB local cliente
ORB local servidor

Resultados
IIOP (formato de los mensajes)

Figura 8.31.- Protocolo IIOP (Internet Inter-ORB Protocol). Tal y como se describe en la Figura 8.31, cualquier programa puede pasar por un objeto del ORB a travs del IDL. Para ello, los clientes y servidores se encapsulan en mdulos IDL de tal manera que el stub IDL del cliente (cabo IDL del cliente) y el skeleton IDL del servidor (esqueleto IDL del servidor) representan la implementacin ficticia va IDL de los objetos del cliente y servidor respectivamente. Se recuerda que mediante el lenguaje IDL la especificacin de un servicio es puramente declarativa y separada de su - 454 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones implementacin. Lo realmente importante es que el ORB del cliente y ORB del servidor utilicen un mismo formato de mensajes (mensajes IIOP) segn una sintaxis comn de codificacin, representacin y transferencia de CORBA y, por tanto, se puedan entender a travs de un mismo protocolo de comunicaciones (IIOP). Consecuentemente, IIOP es el protocolo que define las interacciones entre el ORB del cliente y el ORB del servidor, amn del formato o estructuracin de campos de los mensajes cuya sintaxis, como se ha indicado antes, es propia de CORBA. De esta forma, para el cliente es totalmente transparente cmo est implementado el servicio. Todos los objetos se comunican mediante interfaces IDL va ORB (ver Figura 8.32). Es importante tener en cuenta que CORBA no obliga a reescribir las aplicaciones que no se desarrollaron bajo sus auspicios ya que permite encapsular una aplicacin ya programada307 en un mdulo IDL que defina las las pertinentes operaciones. En la siguiente Figura 8.32 se muestra una visin global de lo comentado anteriormente.
C++
Small Talk
Ada
Cobol
Java
C++
Small Talk
Ada
Cobol
Java
IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL
CLIENTE
SERVIDOR
Intermediario de Solicitudes entre Objetos (ORB)

Figura 8.32.- Interoperabilidad cliente-servidor va IDL y ORB. La gramtica del IDL de OMG es un subconjunto de la gramtica del lenguaje C++ ampliado con un conjunto de palabras reservadas para su adaptacin a los entornos distribuidos. Se recuerda que el cliente no necesita conocer ningn aspecto que no sea parte del interfaz del objeto servidor. El cliente slo ve el interfaz del objeto y nunca su implementacin. Por consiguiente, el interfaz es la parte sintctica del contrato que el
Con unos pequeos cambios en el cdigo fuente del cliente y servidor en funcin del skeleton generado en la compilacin.
307
- 455 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones objeto servidor ofrece a los clientes que le invocan. En este contexto, OMG ha estandarizado correspondencias de IDL a: C, C++, Java, Cobol, Smalltalk, Ada, Lisp, Phyton, e IDLscript. Antes de seguir avanzando, conviene destacar que a partir de CORBA se ha desarrollado otra arquitectura, tambin del grupo OMG, conocida como Arquitectura de Gestin de Objetos OMA (Object Management Architecture) y que aade a los propios componentes de CORBA, que se analizarn ms adelante, un conjunto de servicios y facilidades para hacer ms fcil la labor al programador que est trabajando con CORBA. De ah, que se considere a CORBA como una subarquitectura o un subconjunto de OMA en donde el bus ORB es el centro o ncleo de OMA. Siendo ms precisos, CORBA va ORB define el modelo de comunicaciones de OMA y, ms en concreto, su modelo arquitectnico de referencia. Se resalta que la arquitectura OMA consta de un: MODELO DE OBJETOS: Proporciona la definicin formal y abstracta, es decir, independiente de cualquier implementacin, de toda la terminologa asociada a los objetos o componentes distribuidos en entornos heterogneos. MODELO DE REFERENCIA: Define las interacciones entre objetos Resumiendo, OMA es la visin del OMG basada en la arquitectura CORBA para la creacin y el plug and play de un entorno de componentes con el objetivo de desarrollar sistemas distribuidos mediante el acceso va ORB a un conjunto comn de servicios y facilidades a travs de interfaces de componentes estandarizados. Por consiguiente, OMA es la clave para entender CORBA.
s Objeto de s acione Aplic
Facilidades Comunes Verticales
Facilid ade Comun s Horizo es ntales
Intermediario de Solicitudes entre Objetos (ORB)
Servicios de Objetos
Figura 8.33.- Componentes del modelo de referencia OMA. - 456 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones En concreto, segn se muestra en la anterior Figura 8.33, el modelo o la arquitectura OMA consta de los siguientes cinco componentes308: ORB: Bus de objetos. Servicios de objetos (servicios CORBA de bajo nivel).- Fundamentales y obligatorios, soportando funciones bsicas independientes del dominio de aplicacin. Son los servicios utilizados para el desarrollo de aplicaciones distribuidas desde su inicio. Servicios de facilidades comunes (servicios CORBA de nivel intermedio).- Son servicios opcionales utilizados para aumentar la funcionalidad en aplicaciones distribuidas ya desarrolladas. Se distinguen las siguientes facilidades comunes: Horizontales (generales).- Adicionales y opcionales soportando funciones no bsicas y generales aplicables de manera compartida a distintos entornos o dominios de aplicacin. Verticales (especficos) o de dominios (interfaces de dominio).Especficos y opcionales soportando funciones no bsicas y concretas, aplicables de forma compartida en un determinado entorno o dominio de aplicacin. En este contexto, se han definido a su vez los siguientes dominios: Finanzas, comercio electrnico, transporte (trfico aereo), salud, etc. Objetos de aplicaciones.- Objetos especficos y especializados (no estandarizados) que ejecutan la aplicacin, proporcionando el correspondiente servicio.
308
E implcitamente del resto de los componentes de CORBA.
- 457 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones En la Figura 8.34 se muestran algunos de los componentes especficos del modelo de referencia OMA/OMG.
de Objetos s i on e Aplicac
Fac Facilidad ilidades Comune s es Comu nes Verti cales Finanzas

Salud Facilida des Com unes H Internacionalizacin Facilidad orizonta Internacionalizaci les y Tiempo
de Agentes Mviles M
(MASIF)
ORB
Nombres Objetos persistentes Ciclo de Concurrencia Vida Seguridad Negociacin Negociaci de objetos Eventos Propiedades Externalizacin Externalizaci
Figura 8.34.- Componentes especficos del modelo de referencia OMA/OMG. Servicios de objetos: Nombres.- Este componente permite localizar objetos por su nombre simblico. Cuando se crea un objeto CORBA se le asocia implcitamente una referencia que lo identifica de forma nica durante todo su ciclo de vida. Pues bien, si a esta referencia se le asocia un nombre simblico, se puede buscar a dicho objeto, o por su nombre simblico o por su referencia. Negociacin de objetos.- Este componente es una especie de servicio de pginas amarillas que permite localizar servicios (objetos servidores) en funcin de los atributos309 (propiedades o caractersticas) de los objetos. Ciclo de vida.- Este componente define mtodos para crear, copiar, eliminar, mover, suspender y reanudar objetos. Seguridad.- Este componente define mecanismos para proporcionar servicios de seguridad de autenticacin, control de acceso, confidencialidad, integridad y no repudio.
309
Definidos en la descripcin del IDL.
- 458 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Externalizacin.- Este componente permite obtener una representacin serializable y transferible del estado y cdigo de un objeto para poder moverlo por la red. Eventos.- Este componente ofrece una serie de mtodos para las publicaciones de eventos, suscripciones a los mismos, y notificaciones de dichos eventos. Propiedades.- Este componente permite definir en tiempo de ejecucin atributos asociados a un objeto fuera del IDL esttico. Concurrencia.- Este componente permite compartir recursos entre usuarios.
Facilidades comunes horizontales: Internacionalizacin y tiempo.- Este componente proporciona mtodos para crear objetos que manejen distintos formatos de fechas, tiempos y datos numricos en funcin de las preferencias culturales e idiomticas de los usuarios. Facilidad de agentes mviles (MASIF: Mobile Agent System Interoperability Facilities).- Es una facilidad accesible va ORB a travs de dos interfaces o componentes, MAFAgentSystem y MAFFinder, que definen operaciones normalizadas con un mismo formato de sintaxis para la gestin (creacin, suspensin, reanudacin, recepcin y eliminacin) y el registro y localizacin de agentes mviles respectivamente.
Facilidades comunes verticales: Finanzas.- Este componente ofrece mtodos para crear objetos para los distintos tipos de monedas y cambios existentes. Comercio electrnico.- Este componente proporciona mtodos para crear objetos para la negociacin y compra de productos. Transporte.- Este componente ofrece mtodos que permiten crar objetos para el trfico areo. Salud.- Este componente proporciona mtodos para crear objetos que permitan la gestin documental (historial de los enfermos) y manejo de imgenes mdicas. - 459 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones En la Figura 8.35 se muestran en niveles todos los componentes del modelo OMA/OMG y las distintas posibilidades que se ofrecen al programador en el uso de dichos componentes a la hora de desarrollar su sistema distribuido.
OBJETOS DE APLICACIONES
FACILIDADES VERTICALES
FACILIDADES HORIZONTALES
SERVICIOS DE OBJETOS
SERVICIOS DE OBJETOS
CORBA (ORB)
TCP/IP SISTEMA OPERATIVO
Figura 8.35.- Modelo OMA/OMG en niveles.
Cliente
Implementacin de Objetos
Stub IDL del Cliente
Interfaz del ORB
Skeleton IDL
Adaptador de objetos (Interfaz POA)
Ncleo del ORB

-Middleware o nivel intermedio -Intermediario de solicitudes entre objetos -Bus de objetos a travs del cual pueden interoperar objetos heterogneos independientemente de cualquier aspecto no contemplado en el interfaz del objeto (servidor) -Generacin e interpretacin de referencias de objetos -Registro de implementaciones de objetos -Activacin de objetos -Redireccin de solicitudes a travs del skeleton IDL a la implementacin real del objeto -
Figura 8.36.- Arquitectura de CORBA: Componentes bsicos.
- 460 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Segn se muestra en la anterior Figura 8.36, la arquitectura de CORBA consta de los siguientes cuatro componentes bsicos: ORB: Bus de objetos Stub IDL del cliente: Representacin ficticia va IDL del objeto cliente, independientemente de su implementacin real. Generado por el compilador IDL al lenguaje de programacin del cliente y que define el modo en que ste debe invocar estticamente en fase de compilacin un mtodo del interfaz de servicio de un objeto servidor remoto. Cuando el cliente solicita un servicio, lanza la invocacin a un mtodo del interfaz. Marshalling o codificacin del formato nativo de los parmetros al formato de sintaxix comn de codificacin, representacin y transferencia de CORBA (y unmarshalling o decodificacin en la respuesta).
SKELETON IDL: Representacin ficticia va IDL del objeto servidor, independientemente de su implementacin real. En concreto, es la representacin del interfaz de servicio del objeto servidor. Generado por el compilador IDL al lenguaje de programacin del servidor y que define el modo en que se llama estticamente en fase de compilacin a una operacin (mtodo, funcin, procedimiento) de la implementacin real del objeto servidor remoto. Lleva a cabo el unmarshalling o decodificacin del formato de sintaxix comn de codificacin, representacin y transferencia de CORBA al formato nativo de los parmetros (y marshalling o codificacin en la respuesta)
ADAPTADOR DE OBJETOS: Componente intermediario que acta como nexo de unin entre la implementacin real del objeto y el ncleo del ORB, permitiendo que un objeto cliente encuentre el interfaz de servicio (skeleton) de un objeto servidor remoto. - 461 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Acta escuchando permanentemente las solicitudes de los objetos clientes va stub sobre los objetos registrados en el; redirigiendo dichas solicitudes a la implementacin real del objeto a travs del skeleton IDL correspondiente. Obviamente, para que se pueda llevar a cabo tales operaciones, es necesario que el objeto cliente disponga de la referencia del objeto servidor. Si el objeto cliente no tiene esta referencia, al menos debe conocer el nombre simblico del objeto servidor para que va ORB acceda al servidor de nombres de CORBA y obtenga la referencia en cuestin. Resumiendo, las principales funciones u operaciones que realiza son las siguientes: Generacin e interpretacin de referencias de objetos. Registro de implementaciones de objetos. Activacin de objetos. Invocacin de mtodos y devolucin de resultados. OMG no restringe la posibilidad de usar diferentes adaptadores de objetos de distintos fabricantes siempre y cuando respondan a un conjunto mnimo de funcionalidades; pero para evitar la excesiva proliferacin de diferentes modelos de adaptadores, OMG especific el adaptador de objetos bsico, BOA (Basic Object Adapter) para poder ser implementado en diferentes lenguajes. El adaptador BOA debe ser el mismo (con un mnimo de funcionalidades iguales) independientemente de que est escrito en C o C++ o Cobol. Si el objeto est escrito en Pascal se necesita un adaptador de objetos con un API310 en Pascal. Si el objeto est escrito en Cobol se necesita un adaptador de objetos con un API en Cobol, y as sucesivamente. Si los clientes y servidores estn escritos en C++ se necesita un API o libreras de funciones para C++ con el objetivo de poder acceder a las funcionalidades del adaptador BOA311. Es decir, el adaptador BOA debe ser el mismo, independientemente del lenguaje de programacin en el que est implementado y desde el que se llame. Lo que tiene que haber es una especificacin lo suficientemente libre para poder ser realizada para los
310
Las funciones en Pascal de la librera llaman a su vez a las funciones del ORB que pueden estar escritas en cualquier otro lenguaje, por ejemplo, C. Para ello, el cliente debe disponer de un API en Pascal ampliado para poder interactuar con el API en C del ORB. Por tanto, todo ello depender del compilador utilizado y las opciones de compatibilidad entre lenguajes. Se recuerda que puede estar implementado en cualquier otro lenguaje.
311
- 462 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones diferentes lenguajes de programacin en funcin del lenguaje de los clientes y servidores. El problema es que se dise un adaptador BOA que no daba soporte a todos los lenguajes de programacin y que las implementaciones eran muy dependientes del lenguaje. Por tanto, los objetos diseados para un BOA de un determinado lenguaje eran difcilmente portables al BOA de otro lenguaje. Este problema de portabilidad de objetos entre diferentes implementaciones de BOA se solucion con la especificacin POA (Portable Object Adaptor) que era mucho ms concreta y solucionaba el problema anteriormente comentado. Este ltimo adaptador se incluye ya en CORBA 3.0. Es importante resaltar que un objeto servidor puede tener n interfaces, cada interfaz se asocia a un servicio y cada servicio puede tener n mtodos. A su vez, cada servicio tiene asociado su correspondiente skeleton y, finalmente, cada skeleton tiene asociado su pertinente stub.
Cliente
Stub
ORB
BOA/POA
IOR
registrarse
Implementacin
2 4 4 1
Skeleton
3 5
Cliente
Interfaz del ORB
3 4
Stub IDL
Skeleton IDL
Ncleo del ORB
Figura 8.37.- Diagrama de interaccin y ruta de invocacin de objetos. En la Figura 8.37, se muestra la comunicacin en CORBA entre un objeto cliente y un objeto servidor. Inicialmente, el objeto servidor debe registrarse a travs del BOA/POA312 mediante el interfaz de ste. La respuesta es una referencia IOR (Inter-
Haciendo una analoga con RPC en esta operacin, el adaptador de objetos de CORBA es parecido al portmapper de RPC.
312
- 463 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones operable Object Reference) que lo identifica frente a otros objetos. Inmediatamente, el BOA/POA procede a desactivar al objeto en cuestin. Se resalta que un objeto cliente no puede acceder a un objeto servidor que no se haya registrado en el BOA/POA. Posteriormente, se lleva a cabo dicha comunicacin a travs de los siguientes cinco pasos: 1. El objeto cliente transmite al objeto servidor (cuyo IOR conoce previamente), va stub IDL y ORB, una solicitud de servicio en un mensaje IIOP. 2. Este mensaje, llega al BOA/POA que procede a localizar y activar al objeto servidor en cuestin. 3. Seguidamente, el objeto servidor a travs del BOA/POA se queda a la escucha del potencial objeto cliente. 4. A continuacin, el adaptador BOA/POA redirige la solicitud a la implementacin real del objeto a travs del skeleton IDL correspondiente. 5. A su vez, el objeto servidor, a travs de su skeleton IDL, construye otro mensaje IIOP con la respuesta correspondiente que se transmite va BOA/POA, ORB y stub IDL al objeto cliente.
Cliente
Depsito
Depsito de
de
Interfaces
Interfaz de Stub IDL Invocacin Dinmica (DII) del Cliente
Interfaz del ORB
Interfaz de Skeletons Skeleton Dinmicos IDL (DSI)
Implementaciones
Ncleo del ORB

Figura 8.38.- Arquitectura de CORBA: Componentes.
- 464 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones CORBA especifica para sus servicios: INTERFACES ESTTICOS: Basados en una invocacin esttica de mtodos en fase de compilacin. INTERFACES DINMICOS: Basados en una invocacin dinmica de mtodos en fase de ejecucin, es decir, sin conocimiento del interfaz IDL en fase de compilacin. Las invocaciones dinmicas requieren tres componentes adicionales: Interfaz de Invocacin Dinmica (DII Dynamic Invocation Interface). Es un componente de CORBA que define el modo en que el cliente debe invocar dinmicamente, en fase de ejecucin, un mtodo del interfaz de servicio de un objeto servidor remoto. Todo ello, sin necesidad de tener conocimiento de su interfaz IDL en tiempo de compilacin y, por tanto, sin necesidad de acceder a un stub IDL esttico. Por consiguiente, este componente es muy til para aquellos objetos servidores interactivos para los cuales no es muy prctico tener que recompilar su cdigo cada vez que proporcione nuevas operaciones que varan con el tiempo. Tambin, es muy til cuando un objeto cliente recibe una referencia remota del interfaz de servicio de un nuevo objeto servidor CORBA y no dispone del stub IDL del interfaz de acceso a dicho objeto CORBA. En esta situacin, el objeto cliente interroga va DII/ORB al depsito de interfaces para conocer los mtodos del objeto y los tipos de datos de los parmetros de entrada y salida. Resumiendo, el DII permite que el objeto cliente interrogue va ORB313 al depsito de interfaces de manera que cuando el cliente accede al DII, el ORB accede, a su vez, de manera transparente a dicho depsito de interfaces. Interfaz comn para todos los clientes de un ORB. Independiente del interfaz del objeto. Genera stubs dinmicos.
313
El DII accede al ORB mediante una llamada al API o interfaz de dicho ORB.
- 465 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Depsito de Interfaces (IR: Interface Repositary): Es un componente de CORBA que almacena un conjunto de funciones para la gestin y consulta de las definiciones314 de los interfaces de servicio que un objeto cliente potencialmente puede conocer en fase de ejecucin. Interfaz de Skeletons Dinmicos (DSI: Dynamic Skeletons Interface) Es un componente de CORBA que procesa dinmicamente, en tiempo de ejecucin, las solicitudes de los clientes va DII/ORB. Su objetivo es analizar previamente los parmetros de la peticin y, as, poder generar dinmicamente el interfaz de servicio del objeto servidor. Genera skeletons dinmicos.
Asimismo, e independientemente de si el interfaz es esttico o dinmico, un componente adicional de CORBA es el denominado: DEPSITO DE IMPLEMENTACIONES (IR: Implementation Repositary): Permite al adaptador BOA/POA registrar previamente informacin adicional asociada con la instalacin de las implementacines de los objetos servidores como, por ejemplo, la direccin de la mquina donde se encuentran almacenados dichos objetos y las rutas de directorios o pathname. Posteriormente, y gracias a estas informaciones, este componente es capaz de localizar y activar dichas implementaciones.
Para finalizar, y antes de indicar algunos productos CORBA u ORB de libre distribucin existentes actualmente, es preciso resaltar que generalmente un producto ORB (implementacin de CORBA) suele ofrecer: Un compilador IDL para uno o varios lenguajes de programacin, por ejemplo, C++. Un API en C++ o conjunto de libreras en C++ (o en los lenguajes de programacin soportados) para hacer las llamadas al ORB315.
Nombres de los mtodos para cada interfaz de servicio y, a su vez, para cada mtodo, los tipos de los parmetros de E/S.
315
314
Se vuelve a recordar que puede estar implementado en cualquier otro lenguaje. Lo importante del bus ORB no es como est implementado sino que lleve a cabo las funciones segn el estndar.
- 466 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones El bus ORB (ORB cliente y ORB servidor). Puede que algn o algunos servicios. Como productos CORBA u ORB de libre distribucin ms significativos se destacan: MICO (MICO Is CORBA: http://www.mico.org/): Es una implementacin completa y totalmente gratuita del estndar CORBA bajo licencia GNU para la versin 2.3.10 (mayo de 2003). Por tanto, todo el cdigo fuente est disponible sin necesitar libreras propietarias o especializadas. Hace uso del estndar C++ para la pertinente implementacin. Para los que estn interesados en la implementacin libre del estndar CORBA mediante Java existe otro paquete conocido como Jac ORB. La versin 2.3.10 se puede ejecutar en Sun Solaris, IBM AIX, HP-UX, Linux, Digital Unix, Ultrix, Windows NT/2000/XP, PocketPC, etc. Asimismo, se podra portar a otras plataformas sin demasiada dificultad. ORBit (http://orbit-resource.sourceforge.net/): Tambin es una implementacin completa y totalmente gratuita del estndar CORBA. ORBit2 es un producto ORB que cumple con CORBA 2.4. El ncleo de ORB est escrito en C y se puede ejecutar en Linux, UNIX (BSD, Solaris, HP-UX, ...), y Windows. Admite varios lenguajes: C, C++, Python, Perl, Lisp, Pascal, Ruby y TCL. Esta implementacin procede del proyecto GNOME316 cuyo objetivo inicial era desarrollar una arquitectura de escritorio mediante un sistema de componentes. As, un primer paso fue la bsqueda de una implementacin de CORBA que cumpliera todos los requisitos que se necesitaban: libre y ligera. Las primeras pruebas se hicieron con MICO, una implementacin que cumpla el primer objetivo (libre), pero que, despus de unas cuantas pruebas, demostr claramente que no cumpla el segundo objetivo (ligera). Resultaba ser bastante lento para ser usado en un escritorio, en donde todas las aplicaciones usaran, de una forma u otra, CORBA. As que, los desarrolladores del proyecto GNOME, y ms concretamente Elliot Lee, de RedHat, se pusieron a desarrollar un nuevo ORB (implementacin de CORBA), y as naci ORBit. ORBit cumple con los dos requisitos del proyecto GNOME: es libre, y es uno de los bus ORB ms rpidos317 que existen, aparte de que es muy ligero318. Como el resto de partes
316
GNOME, junto a KDE, son los escritorios grficos en los sistemas GNU/Linux
Consigue una velocidad casi idntica a una simple llamada a funcin cuando se usa en local, pues detecta automticamente que las comunicaciones se estn realizando en la misma mquina, desactivando en ese caso gran parte de la complejidad del protocolo de comunicaciones usado en CORBA (GIOP/IIOP).
317
- 467 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones bsicas de la arquitectura de GNOME, ORBit est implementado en C, y el lenguaje que soporta es C precisamente pero hay que destacar que existe soporte para otros lenguajes de programacin, como C++, Perl, PHP.
8.5
Modelo orientado a servicios Web distribuidos
Seguidamente, se analizan los servicios Web distribuidos como tecnologa de ltima generacin para el desarrollo de aplicaciones en red, y en funcin de los ltimos estndares en servicios Web: XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) y UDDI (Universal Description Discovery and Integration). Los servicios Web distribuidos o servicios XML o simplemente servicios o aplicaciones Web son componentes de software alojados en servidores Web pblicos o privados por Internet a los que se accede mediante mensajes del protocolo SOAP codificados en formato XML319 a travs de protocolos estndares de aplicacin (p.ej., HTTP, SMTP, FTP, ) y que proporcionan un servicio a los correspondientes clientes de software. Visto de otra manera, un servicio Web es un componente de software que se comunica con otros componentes a travs de mensajes codificados en XML. Estos servicios Web distribuidos estn diseados para facilitar la interoperabilidad entre distintas plataformas, sistemas operativos y lenguajes. Asimismo, como se ha citado anteriormente, dichos servicios se basan en los estndares: XML, SOAP, WSDL, UDDI. Para rpidamente hacerse una idea del funcionamiento de los citados servicios, se puede definir un servicio Web distribuido como un servidor RPC basado en HTTP/SOAPXML.
Slo aade 70 KB a los programas que lo usan, lo cual lo hace ideal para ser usado en un escritorio como GNOME
319
318
Lenguaje futuro para la interaccin entre componentes y soportado por cualquier sistema.
- 468 -
DESCUBRIMIENTO Y PUBLICACIN DEL SERVICIO
UDDI
DESCRIPCIN DEL SERVICIO
WSDL
MENSAJERA
SOAP, XML,
TRANSPORTE
HTTP, SMTP, FTP,
-UDDI (Universal Description Discovery and Integration) -WSDL (Web Service Description Language) -SOAP (Simple Object Access Protocol) -XML (eXtensible Markup Language)
Figura 8.39.- Arquitectura de estndares para los servicios Web distribuidos. Los servicios Web estn diseados para facilitar la interoperabilidad entre distintas plataformas, sistemas operativos y lenguajes. Para ello, estn basados en estndares, los cuales forman una pila o arquitectura de comunicaciones, segn se muestra en la anterior Figura 8.39, desde la transmisin de datos de bajo nivel hasta los servicios de alto nivel. En el nivel de transporte de esta arquitectura, estn los protocolos320 de Internet existentes que permiten activar servicios Web. En el nivel de mensajera se sitan los estndares SOAP y XML, es decir, el protocolo simple de acceso a objetos y el lenguaje de marcado extensible que indican cmo se comunican los mensajes entre clientes y servidores y la sintaxis de dichos mensajes, respectivamente, de modo que ambos extremos de la comunicacin puedan comprenderlos. Consecuentemente, este nivel es el responsable de la creacin, codificacin-decodificacin en un formato XML y envo de los correspondientes datos. Los mensajes en los servicios Web suelen
320
A su vez, del nivel de aplicacin de la arquitectura TCP/IP.
- 469 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones ser los parmetros321 pasados en una operacin de un servicio o el resultado de esa operacin. El nivel de definicin o descripcin del servicio es un nivel intermedio importante para que los servicios Web pasen del nivel de mensajera al nivel ms alto de descubrimiento y publicacin. Aqu el lenguaje WSDL de definicin de servicios Web proporciona una serie de mecanismos para que un proveedor de servicios publique un documento WSDL con detalles sobre un servicio en particular y cmo efectuar el acceso. El nivel de descubrimiento y publicacin del servicio se utiliza para encontrar y publicar los servicios Web que proporcionan un servicio determinado. El protocolo universal de descripcin, descubrimiento e integracin universal, UDDI, es una especificacin de un servicio de directorio o servicio Web al que puede acceder la mquina que proporciona estos servicios. De hecho, los registros UDDI son servicios Web y se accede a ellos a travs de SOAP/XML va HTTP. Seguidamente, se concretan un poco ms los citados estndares para los citados servicios Web distribuidos: XML (eXtensible Markup Language): Lenguaje de marcado322 extensible soportado por cualquier sistema y considerado el lenguaje futuro para la interaccin entre componentes. En 1996, el World Wide Web Consortium (W3C, http://www.w3c.org) comenz a desarrollar un nuevo lenguaje de marcado estndar que fuera ms sencillo de utilizar que SGML (Standard Generalized Markup Language) pero con una estructura ms rgida323 que HTML (Hypertext
Igual que con mtodos Java, estos parmetros y resultados pueden ser simples piezas de datos, como enteros o cadenas, o pueden ser complejas estructuras de datos, en forma de objetos.
322
321
Es un lenguaje de marcado estndar igual que lo son el lenguaje de marcado de hipertexto, HTML (Hypertext Markup Language), y el lenguaje de marcado generalizado estndar, SGML (Standard Generalized Markup Language). Un lenguaje de marcado (markup language) usa una notacin especial para marcar las diferentes secciones de un documento. En los documentos HTML, por ejemplo, los parntesis angulares (<>) se utilizan para marcar las distintas secciones de texto.
La estructura y almacenamiento de datos de HTML son defectuosos. Por ejemplo, es posible poner etiquetas de encabezado 3 (<h3>) antes que las etiquetas de encabezado 2 (<h2>). Dentro de la etiqueta <body>, es posible insertar cualquier etiqueta legtima en el lugar que se desee. Si se dejan sin poner las etiquetas de finalizacin, el navegador tratar de averiguar dnde deberan estar para arreglarlas. Por tanto, es posible crear cdigo HTML que no est escrito correctamente y que, a pesar de ello, el navegador lo interpretar correctamente. Otro problema surge cuando se intenta poner datos, como por ejemplo, la informacin de una base de datos en un documento HTML. Esto ltimo puede llegar a ser muy complejo.
323
- 470 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Markup Language). HTML result adecuado para el nacimiento de Internet, pero actualmente ya no es capaz de satisfacer todas sus necesidades. En cambio, SGML es una herramienta excelente y de gran potencia, capaz de documentar sistemas complejos pero, desgraciadamente, es demasiado complicada para las necesidades actuales de Internet. En este escenario, XML es un lenguaje de marcado ligero, sencillo, flexible y fcil de usar. Por consiguiente, XML es ideal para la prxima generacin de aplicaciones de Internet. En concreto, el desarrollo de XML pretende, entre otros, cumplir con los siguientes objetivos: Debe ser utilizable directamente en Internet.- Actualmente, lo soportan los principales navegadores Web (Internet Explorer, Netscape Navigator, etc.). Debe admitir una gran variedad de aplicaciones.- Actualmente, hay una gran cantidad de aplicaciones para ver y editar contenido XML. Debe ser sencillo escribir programas para procesar documentos XML.Para que XML sea ampliamente aceptado, las aplicaciones que procesan documentos XML deben ser fciles de construir. Si dichas aplicaciones son sencillas, ser rentable utilizar XML. La especificacin actual cumple este objetivo, especialmente cuando se utiliza un analizador sintctico (parser) como los proporcionados por Microsoft e IBM. Debe ser sencillo crear documentos XML. XML es slo un poco ms complicado que HTML. Actualmente, existen diversos editores que hacen sencilla la creacin de documentos XML. Tambin es posible crar un editor de XML personalizado. Deben ser legibles los documentos XML para las personas y razonablemente claro. Lo ideal sera abrir un documento XML en cualquier editor de texto y determinar el contenido de dicho documento. Con un conocimiento bsico de XML es posible leer un documento XML. Debe tener un nmero de caractersticas opcionales lo ms pequeo posible, idealmente cero. Cuantas ms caractersticas opcionales, ms difcil ser utilizar XML. Cuanto ms complejo es un lenguaje, ms cuesta realizar desarrollos con l y mayor es el rechazo a utilizarlo. El estndar XML ha logrado este objetivo. Todos estos objetivos han contribuido para hacer de XML el medio ideal de creacin de aplicaciones Web. Segn se ha indicado anteriormente, como beneficio adicional, XML tambin permitir la creacin estndar de mensajes y para pasar stos en las llamadas a mtodos entre clientes y servidores Web. - 471 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones SOAP (Simple Object Access Protocol): Es el protocolo simple de acceso a objetos que define la interaccin mediante solicitudes (cliente) y respuestas (servidores Web) entre un cliente y un servidor Web. Por tanto, define el formato estndar de dichos mensajes cuya sintaxis es XML, es decir, especifica el conjunto de campos de los mensajes codificados en XML. Consecuentemente, permite que los objetos se codifiquen como datos XML para realizar llamadas a mtodos de una computadora remota en Internet. Los mensajes SOAP/XML se encapsulan, a su vez, en mensajes HTTP324. WSDL (Web Service Description Language): Lenguaje que proporciona unos mecanismos para que un proveedor de servicios pueda crear un documento WSDL y describir un servicio Web mediante un vocabulario XML. Para una mayor comprensin de WSDL, es un IDL en XML, por lo que es el lenguaje que permite describir el correspondiente interfaz de servicio. Asimismo, WSDL permite que dicho documento se publique junto al servicio Web en un servidor Web pblico. Un documento WSDL es un fichero para que una mquina pueda leer los detalles acerca de cmo se puede acceder a un determinado servicio, a qu tipo de mensajes responder y con qu protocolos, y qu formato van a tomar las correspondientes respuestas. Dicho fichero lo puede bajar o descargar un programador que intenta escribir un cliente del servicio Web para generar automticamente el cdigo de las comunicaciones; dejando a dicho programador que se centre slo en el desarrollo de la lgica de la aplicacin. UDDI (Universal Description Discovery and Integration): Estndar de un protocolo de descripcin, descubrimiento e integracin universal que especifica un servicio de directorio o servicio Web. De hecho, los registros UDDI son servicios Web y se accede a ellos, tanto para publicar como para descubrir un servicio Web, a travs de SOAP/XML va HTTP. Por tanto, UDDI dispone de un conjunto de mtodos u operaciones325 para registrar y consultar datos. Haciendo una analoga con los motores de bsqueda, los cuales permiten encontrar sitios Web tiles, los registros o motores de bsqueda UDDI permiten, asimismo, encontrar servicios Web tiles. UDDI permite a los programadores y programas buscar servicios Web en tiempo de diseo o ejecucin. Evidentemente, para que UDDI aporte todo su potencial es necesario que exista un nmero significativo de servicios Web. Existen dos tipos de registros UDDI:
Se recuerda que una pgina Web no es ms que un documento en formato HTML encapsulado en un mensaje HTTP. En el caso de los servicios Web distribuidos, stos suelen activarse a travs de HTTP con los mtodos tradicionales (solicitudes GET y POST).
325
324
Mtodos Find, Get, Save y Delete.
- 472 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Pblicos.- Controlados por una determinada organizacin para ofrecer servicios de bsqueda de servicios Web alojados en servidores Web pblicos. Privados.- Controlados por una organizacin en particular para ofrecer servicios de bsqueda de servicios Web publicados internamente, es decir, alojados en servidores Web privados. Un registro UDDI proporciona tres clases de servicio de bsqueda: Pginas blancas.- Descubre detalles de contacto fsico de entidades empresariales conocidas por el nombre. Pginas amarillas.- Descubre entidades empresariales que proporcionan un determinado tipo de servicios Web. Pginas verdes.- Descubre especificaciones tcnicas para acceder a determinados servicios Web. Segn lo anterior, se puede efectuar bsquedas generales de alto nivel de organizaciones por nombre y tipo de servicio; para despus profundizar y descubrir cmo se accede exactamente a un determinado servicio Web; es decir, cmo se obtiene el documento WSDL publicado junto al servicio Web en un servidor Web pblico (o privado), el cual describe la implementacin del servicio. Como se indic anteriormente, los registros UDDI ofrecen un conjunto pequeo de operaciones para registrar y consultar datos. Dichas operaciones se describen a continuacin: Mtodos de autenticacin y verificacin. Mtodos Find.- Realizan una bsqueda de una entidad determinada en funcin de una serie de cualidades. Mtodos Get.- Recogen informacin detallada acerca de una entidad. Mtodos Save.- Crean o corrigen una entidad en el registro. Mtodos Delete.- Eliminan una entidad del registro.
- 473 -
Servidor Web
REGISTRO DEL SERVICIO

Descubrimiento del servicio
(mensajes XML estandarizados Va SOAP sobre HTTP)
Servidor UDDI (Registro UDDI pblico o privado)
CLIENTE
CONSUMIDOR DEL SERVICIO

Clientes de servicios Web: Aplicacin Java AplicAcin C++
Publicacin del servicio (mensajes XML estandarizados va SOAP sobre HTTP) Documentos Documentos Invocacin (o solicitud) WSDL WSDL del servicio SOAP (XML)/HTTP
3
Respuesta (resultado) del servicio SOAP (XML)/HTTP
PROVEEDOR DEL SERVICIO
Servidor Web
Figura 8.40.- Escenario de los estndares para servicios Web distribuidos. En la Figura 8.40, se resume grficamente las distintas interacciones que se llevan a cabo mediante los estndares anteriormente analizados. En este contexto, Microsoft, Sun Microsystem326 e IBM327 son los fabricantes ms avanzados en cuanto a la construccin de un juego completo de herramientas de desarrollo para servicios Web. Las herramientas de Microsoft estn dirigidas para su utilizacin en su plataforma .NET. A su vez, las de Sun e IBM estn pensadas para programadores en Java ya que dichas herramientas estn desarrolladas precisamente en Java. Se resalta que .NET es una plataforma de desarrollo multilenguaje y monoplataforma328 (Windows) frente a las plataformas de desarrollo de Sun e IBM, las cuales son monolenguaje y multiplataforma (Java). La plataforma .NET se basa fundamentalmente en su modelo de componentes COM+ y en su CLR (Common Language Runtime) y CIL (Common Intermediate Language) que seran el equivalente
Se recuerda que J2EE (Java 2 Enterprise Edition) es una plataforma avanzada de desarrollo en Java cuyo modelo de componentes, va RMI (o RMI IIOP para integrarse con CORBA), es Enterprise JavaBeans. Asimismo, se recuerda que Java 2 SDK (Software Development Kit) Standard Edition es la plataforma bsica para el desarrollo de pequeas aplicaciones distribuidas. WSTK o Kit de herramientas en Java de servicios Web: Es un potente conjunto de API, bibliotecas y utilidades para construir y acceder a servicios Web. .NET es una especificacin que Microsoft ha escrito e implementado y que cualquiera puede desarrollar siempre y cuando implemente entre otras cosas la mquina virtual CLR. Curiosamente, la gente de Linux han realizado una implementacin al respecto con lo cual se pueden disponer de aplicaciones .NET en Windows y Unix.
328 327
326
- 474 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones a la mquina JVM y al cdigo objeto o bytecode de Java, respectivamente. Por consiguiente, en .NET se pueden programar el cliente y el servidor en cualquier lenguaje siempre y cuando exista un compilador de ese lenguaje para el cdigo intermedio CIL, cuyo intrprete se puede encontrar en cualquier plataforma Windows. El lenguaje estrella de .NET es C# (C sharp o C almohadilla), un lenguaje orientado a objetos y candidato de Microsoft para sustituir al lenguaje de la competencia, Java de Sun. Es importante resaltar que se podran comunicar clientes y servidores independientemente de las plataformas de desarrollo utilizadas (ya sean .NET o no) siempre y cuando dichas plataformas implementen los estndares XML, WSDL, SOAP y UDDI. Si se desea programar un servicio distribuido en la plataforma .NET habra que realizar329 los siguientes pasos: 1. Descargar .NET (contiene todas las libreras XML, WSDL, SOAP y UDDI) del sitio de Microsoft: (http://www.microsoft.com/spanish/msdn/netframework/downloads/default.asp). 2. Definir el interfaz de servicio mediante el lenguaje WSDL y publicarlo como documento WSDL en la pgina Web de un servidor Web de la organizacin. 3. Desarrollar el cdigo del servidor en un determinado lenguaje (p. ej., C#) y compilar con un compilador de ese lenguaje a CIL, obtenindose automticamente el skeleton pertinente. 4. Desarrollar el cdigo del cliente, en un determinado lenguaje (p. ej., C#), a partir de la definicin WSDL llevada a cabo anteriormente en el paso 2 y compilar con un compilador de ese lenguaje a CIL, obtenindose automticamente el stub correspondiente. 5. Finalmente, el programador registra el servicio en la pgina Web de una mquina servidora en donde se ejecute un servidor UDDI. Para ello, el programador debe llamar a los correspondientes mtodos de UDDI mediante SOAP/XML va HTTP.
329
Obviamente, si se dispone de la herramienta de desarrollo comercial de Microsoft, Visual Studio.Net, se simplifican los pasos indicados.
- 475 -
8.6
Modelos orientados a agentes mviles
8.6.1 Introduccin y generalidades

Sistemas Distribuidos y Redes de Computadoras: Aparicin de los Agentes Mviles Programacin Remota: Nuevo paradigma de programacin Facilitan el diseo, implementacin y mantenimiento de los sistemas distribuidos Sistemas de computacin mviles: Delegacin de tareas Reduccin del trfico por la red, mejora de su latencia, asncronos, autnomos
Necesito conocer mi saldo Est bien!
All voy! Vuelvo en cuanto pueda!
Entidad Bancaria
Figura 8.41.- Generalidades de los agentes mviles. Como se coment con anterioridad, la aparicin de los agentes mviles, a travs de la denominada programacin remota en el mundo de las redes, representa un nuevo paradigma de programacin para el desarrollo de aplicaciones en red, y es alternativo a los tpicos modelos cliente-servidor vistos hasta el momento. En determinadas aplicaciones distribuidas representan la solucin ideal para el diseo, implementacin y mantenimiento de las mismas mediante una delegacin de tareas que requieren la visita de diversas plataformas o entornos de ejecucin por la red. Fundamentalmente, este viaje por dichos entornos de ejecucin permite: 1. La reduccin de la carga de trfico por la red en el sentido de que por un lado: Se eliminan los mensajes intercambiados por los pertinentes procesos cliente-servidor que pueden implicar mltiples interacciones por la red; especialmente, si el nmero de clientes es elevado y la aplicacin est desarrollada sobre un protocolo RPC330. Se reducen drsticamente el movimiento y monitorizacin de los datos. Se mueven los clculos hacia los datos y no al revs; asimismo, el cliente no
330
Se recuerda que el protocolo RPC se basa en un modo de operacin asimtrico (semidplex) y sncrono (parada y espera).
- 476 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones tiene que estar bloqueado a la espera de que se produzca un determinado dato. 2. La mejora de la latencia de la red o tiempo de respuesta desde que se realiza una solicitud hasta que se recibe el resultado pedido. Este tiempo es especialmente crtico en redes de gran tamao (Internet) o en sistemas o procesos de fabricacin en tiempo real. 3. La eliminacin de potenciales limitaciones fsicas en la mquina del cliente. Quizs el rasgo ms caracterstico de los agentes mviles sea la capacidad que tienen para operar ascrona y autnomamente del proceso que los cre. En este contexto, un agente mvil dispone de su propio hilo o proceso de ejecucin (asncrono) y es capaz de actuar independientemente sin intervencin directa pudiendo moverse por la red, es decir, migrar, interactuar y regresar bajo su propio control (autnomo). Por todo lo anterior, un agente mvil puede ejecutar sus tareas aun cuando la conexin con la red no est operativa; es decir, si el agente necesita trasladarse o volver y la red no est activa, el agente puede esperar o desactivarse hasta que la conexin se restablezca. Por consiguiente, la conexin se puede cortar y el agente mvil puede seguir trabajando, cosa que no ocurre en los modelos cliente-servidor vistos hasta el momento. Todo ello, hace que los agentes mviles sean particularmente idneos en conexiones frgiles y costosas o con un ancho de banda reducido (p.ej., va mdem). Todas las potenciales ventajas de los agentes mviles hacen que stos representen un rea de investigacin y desarrollo en pleno apogeo y con mltiples variantes.
Inteligencia Artificial
S. Russell and P. Norvig. Artificial Intelligence: A Modern Approach. PrenticeHall, 1995.
Programacin Orientada a Objetos y Concurrente

G. Booch. Object-Oriented Analysis and Design (second edition). Addison-Wesley: Reading, MA, 1994. G. Agha. ACTORS: A Model of Concurrent Computation in Distributed Systems. The MIT Press: Cambridge, MA, 1986. G. Agha, P. Wegner, and A. Yonezawa, editors. Research Directions in Concurrent Object-Oriented Programming. The MIT Press: Cambridge, MA, 1993.
Diseo de Interfaces Hombre-Mquina

P. Maes. Agents that reduce work and information overload. Communications of the ACM, vol. 37(7) pp. 31-40, July 1994. H. Lieberman. Leticia: An agent that assists web browsing. In Proceedings of the Fourteenth International Joint Conference on Artificial Intelligence (IJCAI-95), Montral, Qubec, Canada, August 1995, pp.924-929.
Figura 8.42.- Agentes: Procedencia. - 477 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones El trmino agente no viene de la nada, investigadores de diferentes disciplinas informticas han tratado este trmino contribuyendo a su nacimiento y evolucin. Dichas disciplinas informticas son las siguientes: Inteligencia artificial.- Dota a los agentes de ciertas capacidades de conocimiento, razonamiento, aprendizaje y decisin prximas al modelo humano. Programacin orientada a objetos y concurrente.- Proporciona a los agentes de un estado y comportamiento a travs de un proceso con su propio hilo de ejecucin. Diseo de interfaces hombre-mquina.- Ofrece interfaces inteligentes de usuario mediante agentes de interfaz o asistentes personales, los cuales disponen de autonoma y ciertas capacidades de aprendizaje331.
Origen
Generalizacin del concepto robot
Palabra checa: robota (trabajos forzados o penosos) Karel Kapek:
Novela (1917): Opilek Obra de teatro (1920): Rossum Universal Robots o RUR (trabajadores en una fbrica)
Julien La Mettrie: LHomme Machine (1748) Ciberntica: Norbert Wiener del MIT John McCarthy (1950) y Oliver G. Selfridge del MIT Inteligencia Artificial Distribuida (DAI): Resolucin Distribuida de Problemas (DPS) y Sistemas Multiagente (MAS)
A. H. Bond and L. Gasser, editors. Readings in Distributed Artificial Intelligence. Morgan Kauffmann Publishers: San Mateo, CA, 1988.
Figura 8.43.- Agentes: Historia. La palabra agente deriva de otra, robota (o robot), de origen checo cuyo creador fue el escritor checo Karel Kapec que us dicha palabra en una novela (Opilek) y posteriormente en una obra de teatro332 (Rossum Universal Robots).
331
Aprenden de las acciones del usuario.
En donde un hombre fabricaba mquinas con forma humana para que le sirvieran como esclavos. Finalmente, stos se revelan.
332
- 478 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Aunque durante siglos han existido autmatas de muy diversos tipos, especialmente como mecanismos de relojera y ha habido alguna obra influyente al respecto (Julin La Mettrie: LHomme Machine) no es hasta la segunda guerra mundial y el desarrollo de las computadoras cuando empieza a cobrar importancia todo lo relacionado con los agentes o robots, especialmente de la mano del padre de la ciberntica, Norbert Wiener. Sin embargo, el trmino agente, tal y como se entiende actualmente, procede de los trabajos comenzados en 1950, fundamentalmente, por parte del padre de la inteligencia artificial, John McCarthy, el cual defini un agente como un programa robot viviendo y trabajando en una computadora e interactuando con el exterior en trminos prximos al modelo humano. Quiere decir esto, que la primera disciplina informtica en estudiar el mundo de los agentes, o los sistemas compuestos por mltiples agentes, fue la inteligencia artificial y ms en concreto la inteligencia artifical distribuida (DAI); la cual se divide, a su vez, en dos grandes reas: Resolucin distribuida de problemas (DPS) y sistemas multiagente (MAS). Conviene resaltar que DAI se centra principalmente en la investigacin de agentes estticos333 o fijos en una mquina sin capacidad de moverse por la red. Aunque el trmino agente no es un trmino nuevo, no hay todava una definicin estandarizada y aceptada por todos. A la hora de definir un agente, existe una clara controversia entre los investigadores en funcin de sus caractersticas. Sin embargo, s existe un consenso en el sentido de que es una entidad con capacidad de representacin y con una serie de atributos, caractersticas o propiedades fundamentales que tienen que tener todos los agentes, amn de unos atributos adicionales que aumenten su funcionalidad: Atributos fundamentales: Autonoma: Independencia de actuacin, es decir, sin sufrir la intervencin directa de nadie. Flexibilidad: Reactividad-Adaptabilidad: Perciben, se adaptan al entorno y actan en l. Proactividad: Capacidad de tomar la iniciativa. Comunicabilidad-Sociabilidad: Acceso a recursos y capacidad de interaccin con otras entidades.
333
El concepto de agente esttico se analizar ms adelante.
- 479 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Continuidad Temporal: Proceso en continua ejecucin334. Atributos adicionales: Movilidad (Agentes mviles): Migrar335, interactuar y regresar bajo su propio control. Capacidad de Razonamiento/Aprendizaje: Inteligencia. Seguridad/Confiabilidad: Mecanismos y servicios de seguridad para evitar sorpresas por parte del agente representante y/o de otras entidades. En funcin de lo anterior, cuando se define un agente se establecen dos tipos de visiones: Visin amplia.- Atributos mnimos: Autonoma Flexibilidad: Reactividad-Adaptabilidad, Proactividad Comunicabilidad-Sociabilidad
Continuidad Temporal Visin estricta.- Atributos opcionales aadidos a los mnimos o bsicos. Movilidad Capacidad de Razonamiento-Aprendizaje Seguridad-Confiabilidad Segn se muestra en la siguiente Figura 8.44, la definicin ms completa de un agente sera aqulla que junte los atributos bsicos de la visin amplia con los atributos
334
No es un clculo que tome una entrada y produzca un resultado antes de terminar, sino que est a la espera de estmulos o cambios en el entorno.
Suspender la ejecucin, transportarse a otra plataforma en la red y reanudar la ejecucin en el punto en que se suspendi.
335
- 480 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones opcionales de la visin estricta. En definitiva, esta definicin se correspondera con todos los atributos que en teora debe disponer un agente mvil, inteligente y seguro.
Autnoma Flexibilidad Continuidad

Movilidad
Agente
Inteligencia Seguridad
Capaz de moverse por los nodos de una red
Representante deseo .... De acuerdo
Figura 8.44.- Lo ideal: Un agente mvil, inteligente y seguro. Si la definicin de un agente es algo compleja, su clasificacin tambin lo es ya que la taxonoma de los agentes es muy amplia y variada. Para una mayor comprensin, este libro clasifica los agentes de software en dos grandes tipos y con las siguientes caractersticas: Agentes estticos: Ejecucin limitada al sistema donde se inicia. Interactan con entidades locales: agentes, programas, usuarios. Accesos a recursos remotos va sockets, RPC, RMI, CORBA, etc. Agentes mviles: Capacidad de movimiento: Migracin. Interaccin directa con entidades remotas: Programacin Remota. Transportan un mensaje: Estado (datos) y cdigo (proceso o clase). Por consiguiente, un agente esttico es un proceso que se ejecuta nica y exclusivamente en la mquina donde comienza la ejecucin. Si necesita informacin - 481 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones que no est en el sistema o necesita interactuar con otro agente en una mquina diferente; utiliza, por ejemplo, un mecanismo de comunicacin va sockets, RPC, RMI, CORBA, etc. Por el contrario, un agente mvil es un proceso que no est limitado al sistema donde se inicia la ejecucin sino que tiene la completa libertad para moverse por la red, migrando, interactuando y regresando bajo su propio control. A su vez, la migracin consiste en suspender la ejecucin, transportarse a otra plataforma en la red y reanudar la ejecucin en el punto en donde se suspendi.
Ejecuta acciones Recoge informacin Toma decisiones
agente
agente
agente
INTERNET
agente
agente
agente
Figura 8.45.- Un agente mvil viajando por la red. En concreto, un agente mvil es un proceso situado en una plataforma o entorno de ejecucin para actuar en representacin bsicamente de una persona u organizacin, y llevar a cabo una tarea para la cual ha sido especialmente designado. Asimismo, dispone de un conjunto ms o menos amplio de atributos entre los que destaca la movilidad en el sentido de que no est limitado al sistema donde comienza la ejecucin sino que tiene la completa libertad para viajar, es decir, migrar, interactuar y regresar bajo su propio control. Antes de continuar, conviene distinguir entre cdigo mvil y ejecucin remota de lo que se entiende por agente mvil y migracin. Un cdigo mvil tiene una sola vida, es decir, se transfiere una sola vez antes de su ejecucin, la cual se efecta de forma completa desde su inicio hasta el final. En este contexto, un agente mvil tiene diferentes vidas o resurrecciones en el sentido de que puede moverse por un itinerario de entornos de ejecucin interactuando con otros agentes o recursos de informacin y computacin hasta llevar a cabo el servicio solicitado; momento en el cual, regresa a la mquina de partida. Como ejemplos de cdigo mvil se pueden citar los siguientes:
- 482 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Applet336 (Sun Microsystems).- Es una aplicacin Java compilada previamente y cuyo cdigo objeto (bytecode) se referencia en una pgina HTML dentro de un servidor Web. Posteriormente, dicho cdigo objeto se descarga por la red para su interpretacin (intrprete Java) y ejecucin en un cliente Web. JavaScript (Netscape).- Es una pequea aplicacin o script337 hecha en un lenguaje interpretado (lenguaje JavaScript) basado en comandos y cuyo cdigo fuente338 se referencia en una pgina HTML dentro de un servidor Web. Seguidamente, dicho cdigo fuente se descarga por la red para su interpretacin (intrprete JavaScript) y ejecucin en un cliente Web. Controles ActiveX (Microsoft).- Es una aplicacin hecha en un lenguaje cualquiera que se compila previamente y cuyo cdigo objeto se referencia en una pgina HTML dentro de un servidor Web. Posteriormente, dicho cdigo objeto se descarga por la red para su ejecucin directa (sin intrprete) en un cliente Web. Como se muestra en la siguiente Figura 8.46, los agentes mviles son funcionalmente objetos339 de software que transportan en un mensaje su estado y cdigo para poder interactuar remotamente con otros agentes o recursos. Para que el agente mvil pueda interactuar con otros agentes o recursos afines es necesario la definicin de un protocolo que especifique el formato de los mensajes y las acciones que se han de efectuar. En el mensaje transportado por el agente mvil se incluye un:
No confundir con Servlet (Sun Microsystems), el cual es una aplicacin Java (con cdigo HTML encapsulado) que se ejecuta (ya est instalada) en un servidor Web y que devuelve los resultados en una pgina Web que se transmite automticamente. Asimismo, no confundir Servlet con JSP (Java Server Pages), el cual es una aplicacin HTML (con cdigo Java encapsulado) que se ejecuta (ya est instalada) en un servidor Web. Para los diseadores de pginas Web, JSP es ms sencillo que los Servlets.
337
336
Pequea aplicacin hecha en un lenguaje interpretado basado en comandos. No hay cdigo objeto porque no hay compilacin.
338
Aun cuando el lenguaje est basado en scripts (TCL, Phyton, Perl) se simula el estado y comportamiento del objeto software.
339
- 483 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Estado: Como su nombre indica, contiene el estado del objeto o los valores de los atributos del agente y el estado de la mquina o estado de ejecucin (contador de programa, punteros de pila, registros, ...). Cdigo: Incluye la clase con los mtodos de interaccin permitidos.
Mensaje = Estado (datos) + Cdigo (clase)
Agente Cliente
PC
Internet
Mensaje = Estado (datos) + Cdigo (clase)
Agente Cliente
Servidor
Solici tud Respu esta
Servicio
Figura 8.46.- El mensaje transportado por un agente mvil. Como ya se ha indicado, cuando un agente se mueve, realiza una migracin suspendiendo la ejecucin, transportndose a otra plataforma en la red y reanudando la ejecucin en el punto en que se suspendi. En este contexto, existen dos tipos de migracin que se diferencian por el transporte de ms o menos informacin o datos de estado: Migracin fuerte: Transporta el estado del objeto (valores de los atributos del agente) y estado de la mquina o estado de ejecucin (contador de programa, punteros de pila, registros, ...). Es la foto completa, justo cuando se suspende la ejecucin para su posterior reanudacin en el entorno de otra mquina. Migracin dbil: Transporta slo el estado del objeto (valores de los atributos del agente). Es la foto incompleta que permite slo reiniciar la ejecucin con los valores actuales de los atributos. Por otro lado, es la tpica migracin utilizada por los agentes mviles escritos en Java, debido a que este lenguaje no permite la captura del estado de ejecucin de un hilo de Java. Se resalta que el modelo de seguridad de la arquitectura JVM (Java Virtual Machina) impide que un programa acceda o manipule directamente sus punteros, registros y pilas. Por consiguiente, cuando un agente Java se transporta de una plataforma a otra, no reanuda su ejecucin sino que reinicia sta con los valores actuales de sus atributos. Evidentemente, para que un agente Java reanudara su ejecucin en otra plataforma sera necesario que el programador modificara internamente la mquina JVM realizando las oportunas extensiones o bien simulara el estado de - 484 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones ejecucin codificando ste con una serie de variables del programa y un mtodo de arranque.
Servidor
Cdigo
(C)
Origen
Destino
Agente
Cdigo
(B)
Agente
Cdigo
(A)
Figura 8.47.- La transferencia del cdigo de la clase de un agente. Con respecto al transporte de la otra parte del mensaje de un agente mvil, es decir, el cdigo de la clase, y segn se muestra en la Figura 8.47, se presentan tres posibilidades: A. El cdigo se encuentre disponible en la plataforma de destino ya sea en la memoria cach de clases o en el sistema local de ficheros. Consecuentemente, no es necesario transportar dicho cdigo en el mensaje del agente. B. El cdigo se encuentre disponible slo en la plataforma de origen. Este es el caso ms frecuente y, por tanto, es necesario su transferencia en el mensaje del agente con la lgica penalizacin del trfico de la red. C. El cdigo se encuentre en un servidor de clases. Se procede a recuperarlo bajo demanda desde la plataforma de destino. Llegados a este punto, es importante distinguir ahora entre objetos y agentes mviles. Aunque los agentes son funcionalmente objetos, existen, entre otras, las siguientes diferencias: Un objeto no es un agente mvil ya que un agente mvil es ms que un objeto, es decir, es autnomo, flexible, etc. Un objeto no tiene autonoma sobre su comportamiento a la hora de ejecutar o no un determinado mtodo.
- 485 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Un objeto no es flexible, es decir, no combina un comportamiento reactivo, proactivo y sociable. Desde un agente mvil no se invoca un mtodo sino que se realiza una solicitud de servicio que el agente llevar a cabo o no.
Emisor
Suspender la Ejecucin Ejecuci
Receptor
Reanudar la Ejecucin Ejecuci
Serializar el agente
Deserializar el agente
Codificar los datos
Decodificar los datos
Transferir los datos
Recibir los datos
Red Internet
Figura 8.48.- Transferencia de un agente mvil. En la Figura 8.48 se muestran las distintas acciones que hay que realizar con un agente mvil para que ste pueda migrar desde un entorno de ejecucin a otro. Se recuerda que la migracin de un agente consiste bsicamente en suspender la ejecucin, transportarse a otra plataforma en la red y reanudar la ejecucin en el punto en que se suspendi. As en el lado del emisor (plataforma de origen) se suspende la ejecucin y se serializa340 al agente, es decir, se serializa su estado y cdigo en un determinado formato de serializacin o de transferencia, es decir, en un flujo de octetos (stream) transferible capaz de ser transportado por la red y restaurado en el lado receptor (plataforma de destino). Seguidamente, se efecta el marshalling341, es decir, se toman los datos serializados y se codifican en un formato o sintaxis comn de codificacin, representacin y transferencia. Finalmente, se transmite al agente, por ejemplo, va sockets, RPC, Java RMI, CORBA IIOP, etc. A su vez, en el lado del receptor
340
Se usa el formato de serializacin del lenguaje utilizado para programar los agentes. Si el lenguaje es Java se utilizara la serializacin de objetos Java. Se recuerda que la serializacin y codificacin (marshalling) en Java, es segn el formato o sintaxis de representacin de la mquina JVM.
341
- 486 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones (plataforma de destino) se realiza el proceso contrario o unmarshalling, es decir, se decodifican los datos serializados para luego deserializar los octetos de dichos datos al formato nativo de la nueva mquina; con el objetivo final de poder reiniciar (migracin dbil) o reanudar (migracin fuerte) la pertinente ejecucin. Para finalizar con esta introduccin y descripcin de generalidades sobre agentes mviles, slo indicar que se pueden aplicar los agentes mviles en muchos escenarios, como por ejemplo: Recopilacin de informacin de estado: El agente mvil recoge informacin diseminada por la red. Se establece un itinerario para que un agente mvil viaje secuencialmente por una red de rea local recopilando, por ejemplo, informacin sobre el estado de almacenamiento de los discos duros de las mquinas servidoras de la organizacin. Bsqueda y Filtrado de Informacin: El agente mvil parte de un conocimiento de las preferencias del usuario y elimina la informacin irrelevante. Monitorizacin de Noticias: El agente mvil se enva para que est a la escucha de ciertos tipos de informacin y recoga una determinada informacin diseminada por la red a travs del tiempo Copia o mirroring: El agente mvil realiza una copia inteligente de una informacin que se actualiza a determinadas horas del da o la noche. Diseminacin de la Informacin: El agente mvil lleva a cabo una distribucin interactiva de noticias o publicidad a grupos interesados. Negociacin: Los agentes mviles negociadores efectan una planificacin de reuniones en nombre de sus representados.
- 487 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Comercio Electrnico: El agente mvil localiza productos y precios para, finalmente, llevar a cabo una comparacin, negociacin y compra. Entretenimiento: El agente mvil se programa con una determinada estrategia para su posterior envo a un servidor de juegos. Opcionalmente, se puede establecer todo un itinerario de servidores de juegos. Subastas: El agente mvil se programa con una determinada estrategia para su posterior envo a un servidor de subastas. Opcionalmente, se puede establecer todo un itinerario de servidores de subastas.
8.6.2 Sistemas de agentes (agencias): Introduccin
Sistema Operativo SA 1
Lugar 1
A1
A2
Lugar 2
A1
IC
Figura 8.49.- Un ejemplo de un sistema de agentes en una mquina. Un sistema de agentes342 (SA) o agencia es una plataforma o entorno de ejecucin de agentes que permite, fundamentalmente, la creacin, suspensin, terminacin y
Seguidamente, se va a utilizar toda la terminologa seguida en MASIF: Mobile Agent System Interoperability Facilities (la cual se analizar ms adelante) ya que es la primera especificacin para agentes mviles, la cual fue publicada en 1997 por el grupo OMG para su modelo arquitectnico de referencia OMA/OMG.
342
- 488 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones ejecucin inicial de un agente o retomar343 su ejecucin, posibilitando la comunicacin entre agentes y sus transferencias. Por tanto, un sistema de agentes es responsable de efectuar las siguientes funciones: Coordinar todas las acciones entre agentes. Garantizar la seguridad del sistema interactuando con otras agencias y evitando la llegada de agentes procedentes de agencias maliciosas. Permitir la asociacin con un representado (autoridad) que identifique a una persona u organizacin. Disponer de un tipo344 que, a su vez, describa parte del perfil de un agente. El perfil compleo de un agente queda definido por los tres siguientes parmetros: Tipo del SA, lenguaje y mtodo de serializacin. Disponer de uno o varios lugares (entornos especficos de ejecucin) en funcin de los intereses y objetivos de los agentes). Como muestran la Figura 8.49 y Figura 8.50, en cada lugar se pueden ejecutar uno o ms agentes y, a su vez, en una mquina se pueden alojar simultneamente uno o ms SA. Si un lugar dispone de ms de un agente, cada uno de ellos ofrecer una clase de servicio diferente para ese mismo lugar. As, se podra disponer de un lugar de comercio electrnico con distintos agentes especializados en la localizacin, comparacin y compra de distintos productos. Otro lugar de ocio con uno o ms agentes con distintas estrategias para enviarlos a servidores de juego, etc. Disponer de un servicio de nombres que permita encontrar agentes y lugares locales. En este contexto, cada agente dispone de un identificador global y nico formado por la concatenacin de las siguientes informaciones: Autoridad representada, SA, lugar, un valor o identificador y la direccin IP de la mquina. Disponer de una infraestructura de comunicaciones345 (IC) que ofrezca los pertinentes servicios de transporte entre los SA.
343
Reiniciar (migracin dbil) o reanudar (migracin fuerte) la pertinente ejecucin.
Como ya se analizar ms adelante, existen diferentes tipos o implementaciones de sistemas de agentes mviles: Aglets, Grasshopper, DAgents, Mole, Voyager, Odissey, Concordia,
345
344
Sockets, RPC, Java RMI, CORBA IIOP, etc.
- 489 -
Sistema Operativo
SA 1
SA 2
Lugar 1
Lugar 1
A1
A2
A1
Lugar 2
A1
IC
IC
Figura 8.50.- Un ejemplo de dos SA en una misma mquina.
Sistema Operativo
Sistema Operativo
SA 1
SA 1
SA 2
Lugar 1
A1 A 2
Lugar 2
Lugar 1
Lugar 1
A1
Lugar 2
A1
A1
IC
A1
IC
IC
Red
Figura 8.51.- Ejemplo de interconexin de los SA de dos mquinas. El hecho de que los agentes mviles no actan de forma aislada se puede ver todava de una forma ms clara a travs del concepto de regin (ver siguiente Figura 8.52) que permite a una autoridad estar representada por uno o ms SA. Una regin contiene uno o ms SA con la misma autoridad, pero no necesariamente con el mismo tipo de sistema de agente. Asimismo, una regin es responsable de lleva a cabor las siguientes funciones:
- 490 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Facilitar la gestin de los componentes distribuidos (los SA, lugares, agentes). Mejorar la escalabilidad (mejor distribucin de carga a travs de mltiples SA). Mejorar el control de acceso y la seguridad. Disponer de un servicio de nombres al cual se conectan los servicios de nombres de cada SA. Interconectarse con otras regiones (ver Figura 8.52) a travs de los llamados puntos de acceso a la regin (SA externas), los cuales pueden compartir un mismo servicio de nombres (previo acuerdo entre sus autoridades). Un punto de acceso a la regin es otro SA que mantiene informacin de todos los SA de la regin.
Sistema Operativo SA1

Lugar 1
Sistema Operativo SA1 Lugar 1 SA2 Lugar 1
A1 A2
Lugar 2
A1
A1
A1
Lugar 2
IC
A1
Red
IC
IC
Sistema Operativo Sistema Operativo SA1 Lugar 1 SA2 Lugar 1 SA1

Lugar 1
A1
Lugar 2
A1
A1
Lugar 2
De otra regin
Lugar 2
A1
A1 IC
A1 IC
IC
Punto de Acceso a la Regin

Figura 8.52.- Ejemplo de regin.
- 491 -
Regin 1
Regin 1
SO Sistema Operativo SA 1 SA1 SA2
Lugar 1
Lugar 1
Sistema Operativo
Sistema Operativo
SA1
Lugar 1
SA1
Lugar 1
A1
A1
A1 A2
Lugar 2
A1
Lugar 2
Lugar 2
IC
A1 A2
IC
A1
IC
A1
IC
Sistema Operativo
SA1
Lugar 1
RED RED
RED RED
A1
IC
Regin 2
Figura 8.53.- Ejemplo de interconexin entre dos regiones. En la siguiente Figura 8.54, se describen los pasos ms significativos que debe realizar un agente mvil A para interactuar con otro remoto B.
SA1
agente A
Atributos
SA2
agente A
Atributos
Red
3 4
Servicio de Nombres
2, 3
Cdigo Clase CP
2, 3
Cdigo Clase
CP
5
agente B
Mquina 1
CP: Contador de Programa
Mquina 2
Figura 8.54.- Ejemplo de cmo un agente solicita interactuar con otro. 1. Inicialmente, el agente B, en el SA2, se conecta al propio servicio de nombres de SA2 para registrarse. El agente A podra conocer al agente B por el servicio de nombres de la regin al cual se conectan los servicios de nombres de cada sistema de agentes. 2. Previamente, el agente A interrumpe su ejecucin ante el deseo de interactuar con el agente B. A continuacin, transmite a SA1 una solicitud de permiso - 492 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones para viajar a SA2. Finalmente, SA1 solicita una autorizacin a SA2 para poderle enviar al agente A. En funcin de la identidad, credenciales y privilegios de la regin, SA y autoridad, se emitir o no el pertinente OK! 3. Seguidamente, el agente A migra con la identidad, credenciales y privilegios de la regin, SA y autoridad. Se recuerda que un agente debe disponer de un identificador global y nico formado por la concatenacin de las siguientes informaciones: Autoridad representada, regin (si existe), SA, lugar, un valor o identificador y la direccin IP de la mquina. 4. El agente A retoma346 su ejecucin en SA2 a partir de su informacin de estado. 5. El agente A interacta con el agente B.
8.6.2.1 agentes
Lenguajes de programacin para el desarrollo de sistemas de
En un principio se puede utilizar cualquier lenguaje de programacin aunque no est especficamente diseado para el desarrollo de los agentes mviles y sus plataformas o entornos de ejecucin (los SA). Este tipo de lenguajes obliga al programador a desarrollar al agente mvil desde cero teniendo que incluir aquellas funciones, operaciones y comandos que soporten las caractersticas de la teora de agentes que desee aadir. En este contexto, se destacan los siguientes lenguajes: Lenguajes de propsito general: Java, C, C++, etc. Lenguajes interpretados y procedimentales basados en comandos (scripts): Tcl, Phyton, Perl, etc. Si no se desea utilizar un lenguaje de propsito general o procedimental basado en scripts, se puede utilizar, como alternativa ideal, un lenguaje especialmente diseado para el desarrollo de agentes mviles, es decir, que soporte la programacin orientada a este tipo de agentes. Estos ltimos lenguajes se caracterizan porque son interpretados y orientados a objetos y disponen de todas aquellas funcionalidades y capacidades integradas para dar soporte a las principales caractersticas de los agentes mviles como son la autonoma, migracin, reactividad, proactividad, seguridad, etc. Un ejemplo de esto ltimo, es el lenguaje Telescript similar347 a Java y que fue el primer lenguaje en
346
Reinicia (migracin dbil) o reanuda (migracin fuerte) la pertinente ejecucin.
347
Dispone de su propia mquina virtual Telescript, est basado en un lenguaje orientado a objetos y dispone de un modelo de seguridad.
- 493 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones ser especialmente diseado y utilizado para desarrollar el primer sistema de agentes del mismo nombre. Sin embargo, en la actualidad la mayora de los sistemas de agentes (Aglets, Mole, Odissey, Voyager, Grasshopper, ...) se basan en el lenguaje Java ampliado con nuevas clases348 para soportar caractersticas o atributos de la teora de agentes mviles.
8.6.2.2
Lenguajes para la comunicacin entre agentes mviles
Igual que se ha dicho para los lenguajes de desarrollo de agentes mviles, lo mismo se puede decir para el caso de la comunicacin entre stos en los correspondientes entornos de ejecucin. Teniendo en cuenta que el modelo de comunicacin de los mensajes es por paso de mensajes; en principio, se puede utilizar cualquier lenguaje de programacin aunque no est especficamente diseado ni para el desarrollo ni la comunicacin entre los agentes mviles. Por consiguiente, el programador debe implementar aquellas clases, funciones, procedimientos, comandos, etc., que permita crear, enviar y recibir los datos de los correspondientes mensajes. En este contexto, se destacan los siguientes lenguajes: Lenguajes orientados a objetos: Java ampliado, Telescript, etc. Lenguajes interpretados y procedimentales basados en scripts: Tcl, Phyton, Perl, etc. En este contexto, conviene resear que existen los siguientes tres esquemas para el paso de mensajes entre agentes mviles:
348
No estndares en Java.
- 494 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones 1. Paso sncrono de mensajes (parada y espera):
Emisor Receptor
Figura 8.55.- Paso sncrono de mensajes. El emisor bloquea su ejecucin cada vez que trasmite un mensaje hasta que el receptor responde al mismo. Este esquema de parada y espera es el ms popular y, por tanto, el ms usado. 2. Paso asncrono de mensajes basado en dos envos:
Emisor Receptor
Figura 8.56.- Paso asncrono de mensajes basado en dos envos. Ahora, el emisor no tiene que esperar hasta que el receptor responda y enve la respuesta. Este esquema es ms flexible y especialmente til cuando mltiples agentes interactan con uno. Para su correcta implementacin es necesario mantener en el emisor un identificador del mensaje enviado para no tener que bloquear la ejecucin actual e ir preguntando en determinados momentos si hay una respuesta para el mensaje transmitido.
- 495 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones 3. Paso asncrono de mensajes basado en un envo:

Emisor Receptor
Figura 8.57.- Paso asncrono de mensajes basado en dos envos. Por ser un esquema asncrono, al igual que en el esquema anterior, no se bloquea la actual ejecucin. Ahora, el emisor no retiene el identificador del mensaje y el receptor no tiene que responder. Obviamente, este esquema es muy til cuando el agente que transmite un mensaje no espera la pertinente respuesta. Si no se desea utilizar un lenguaje orientado a objetos o procedimental basado en comandos (scripts), se puede usar, como alternativa ideal, un lenguaje especialmente diseado para la comunicacin entre los agentes mviles. Estos lenguajes se conocen como declarativos o prximos al modelo humano en el sentido de estar basados en sentencias declarativas349. Entre dichos lenguajes se destacan los siguientes: KQML (Kowledge Query Management Language) de DARPA350: Sintaxis normalizada de comunicacin entre agentes de sistemas heterogneos. FIPA351: Sintaxis similar a KQML. Se destaca, que estos dos ltimos lenguajes estn ms pensados para la comunicacin entre agentes estticos tpicos en el contexto de la Inteligencia Artificial que para la propia comunicacin entre agentes mviles.
349
Declaraciones que describen acciones: solicitudes, respuestas, afirmaciones. Defense Advanced Research Projects Agency for the Department of Defense.
350
La Fundacin para los Agentes Fsicos e Inteligentes (The Foundation for Intelligent Physical Agents: http://www.fipa.org) y la Sociedad de Agentes (The Agent Society: http://www.agent.org), son organismos dedicados a la normalizacin de la teora de agentes (estticos) en el contexto de la Inteligencia Artificial.
351
- 496 -
8.6.2.3
Sistemas de agentes (agencias): Clasificacin
Seguidamente, se describen brevemente algunos, de los muchos, SA implementados en la actualidad: TELESCRIPT Diseado por James White (1994) en la empresa General Magic, Incorporated (California): http://www.genmagic.com Primera plataforma comercial (SA) para el desarrollo y ejecucin de agentes mviles. Primer desarrollo de un comercio electrnico basado en agentes mviles. Conceptos utilizados en MASIF (CORBA). Conceptos claves: Lugares y agentes. El cdigo fuente no est disponible. Componentes claves: LENGUAJE TELESCRIPT: Basado en un lenguaje propietario orientado a objetos: Similar a Java en cuanto a que es interpretado (mquina virtual Telescript) y dispone de un modelo de seguridad. Clases para crear y enviar mensajes. Mecanismos de seguridad: autenticacin y control de acceso Motor Telescript: Intrprete del lenguaje Protocolo de transporte Telescript.- Opera en dos niveles: Nivel ms alto: Codificacin y decodificacin de los agentes. Nivel ms bajo: Transporte de los agentes. Migracin fuerte. Sofisticado y relativamente costoso (96 Mbytes de memoria) - 497 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones En julio de 1995, NTT, AT&T y Sony desarrollaron en Japn un servicio basado en Telescript. En Octubre de 1995, France Telecom anunci una licencia de Telescript para su uso en Francia. Actualmente, General Magic ha suspendido el desarrollo de nuevas versiones de Telescript. AGLETS (AGent+appLETS) Diseado por Dany B. Lange (1996) en el laboratorio de investigacin de IBM en Tokyo (IBM Tokyo Research Laboratory). Aglets Software Development Kit (ADSK o Aglets Workbench): http://sourceforge.net/projects/aglets. Muy documentado y con abundantes ejemplos. Libre distribucin. Interfaz de programacin basado en Java (Java Aglet API o J-AAPI). Servidor de aglets (Tahiti). Posiblemente, uno de los SA ms conocidos y utilizados actualmente. No proporciona soporte (clases de agentes reactivos, proactivos, ...) para desarrollar agentes. Proporciona soporte para implementar objetos mviles. Un aglet es un objeto mvil escrito en Java. Migracin dbil. Componentes claves: LENGUAJE JAVA: Mtodo de serializacin de objetos Java (JOS). Proxy u objeto representante. Paso de mensajes: Mtodos especficos de Java.
- 498 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Protocolo de transporte de agentes aglets (ATP).- Ubicado en el nivel de aplicacin para construir un bloque de datos: Nombre del SA, identificador del agente y cadena de octetos con el estado y cdigo procedente del nivel de ejecucin de los aglets. No contempla comunicaciones seguras dejando libertad a las plataformas para utilizar otros protocolos seguros (SSL). TabiCan es un servicio comercial352 de compra-venta de billetes: http://www.tabican.ne.jp. DAgents353 Diseado por Robert Gray (1996) en la Universidad de Darmouth (Dartmouth College, EE UU): http://www.cs.dartmouth.edu/~agent. Uno de los primeros SA. Propuesta alternativa a Telescript. Proporciona un modelo de ciclo de vida ms sofisticado que Aglets. No dispone de mecanismos propios de seguridad. Los servicios de seguridad de autenticacin y confidencialidad se basan en un paquete de seguridad externo PGP (Pretty Good Privacy) de libre distribucin. Componentes claves: Lenguaje Tcl/tk (Tool Command Language/tk Toolkit): Lenguaje interpretado de scripts de alto nivel desarrollado por Sun Microsystems en 1987. Agent TCL admite diferentes tipos de agentes: o Dispone de soporte para otros lenguajes: Java, Scheme, C/C++.
352
Servicio disponible slo en japons. Anteriormente conocido como Agent Tcl.
353
- 499 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Servidor: Toda mquina dispone de un servidor Agent TCL que permite a un agente llamar a una funcin especfica para capturar automticamente el estado completo de un agente (migracin fuerte). DAIS (Domain Adaptative Information System, 1998): Sistema de agentes mviles e inteligentes, financiado por DARPA354 para descubrir y diseminar informacin en redes militares. ARA (Agents for Remote Action) Diseado por Holger Peineen de la Universidad de Kaiserlauten (Alemania) en 1997: http://wwwagss.informatik.uni-kl.de:80/Projekte/Ara/status.html Basado en el lenguaje Tcl/tk (Tool Command Language/tk Toolkit): Lenguaje interpretado de scripts de alto nivel desarrollado por Sun Microsystems en 1987. Asimismo, dispone de otros tipos de intrpretes incluidos dentro del ncleo de Ara: Permite agentes mviles interpretados en C/C++ basado en MACE (Mobile Agent Code Environment), un entorno interpretativo de ejecucin fundamentado en una mquina abstracta. Admite como extensin futura un soporte para Java. Dispone de un modelo de seguridad. Migracin fuerte. MOLE Diseado por Joachim Baumann (agent control), Fritz Hohl (agent security) and Markus Strasser (fault-tolerant agents) en la Universidad de Stuttgart (Alemania): http://mole.informatik.uni-stuttgart.de/ Primera implementacin de un SA basado en el lenguaje Java:
354
Defense Advanced Research Projects Agency for the Department of Defense.
- 500 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Julio de 1996: Release 1.0 del Sistema de Agentes Mviles Mole. Junio de 1997: Release 2.0 Septiembre 1998: Release 3.0 Uno de los primeros SA acadmicos y sencillo en su implementacin. Parecido a Aglets. Hace distincin entre agentes de usuario y del sistema. Entorno grfico (MOLEview) que permite visualizar la interaccin de agentes. Buenas capacidades de intercambio de mensajes entre agentes. Incluye mecanismos de seguridad para proteger a los agentes contra mquinas maliciosas. En el primer desarrollo de Mole se us: RPC y RMI. Migracin dbil y ejecuciones remotas. ODISSEY Diseado por General Magic, Incorporated (California) en 1997: http://www.genmagic.com/ Basado en el lenguaje Java (inicialmente desarrollado con Telescript y luego abandonado por General Magic). Comunicacin con un amplio rango de objetos que trabajan en diferentes plataformas. Interfaz de transporte: Java RMI, DCOM, CORBA IIOP. Entorno Telescript para el desarrollo de agentes Java. Adapta a Java la mayor parte de las prestaciones del lenguaje Telescript (ya abandonado por General Magic). Parecido a Aglets pero mejorando alguna de sus caractersticas. Dispone de un modelo de seguridad. Migracin dbil. - 501 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones VOYAGER Desarrollado por la empresa ObjectSpace, Incorporated (Dallas, Texas) en 1998: http://www.objectspace.com/products/voyager/ Basado en el lenguaje Java. Intenta aglutinar las ventajas de Aglets, Mole y Odissey. Soporta movilidad de objetos y agentes mviles para el desarrollo de aplicaciones distribuidas. Interfaz de transporte: Java RMI, DCOM, CORBA IIOP. Dispone de un modelo de seguridad (incluyendo SSL 3.0) Migracin fuerte. CONCORDIA Desarrollado por Mitsubishi Electric Research Laboratories (Cambridge, Massachusetts) en 1998: http://www.meitca.com Basado en el lenguaje Java. Cumple con las normas especificadas en MASIF por el grupo OMG. Incorpora mecanismos de seguridad. Migracin dbil. TACOMA Proyecto conjunto de investigacin desarrollado desde 1995 entre la Universidad de Tromso (Noruega) y la Universidad de Cornell (EE UU). Soporta agentes escritos en C, Tcl/Tk, Perl, Phyton y cheme y Java. El propio sistema est escrito en C. Basado en Unix (HP-UX, Solaris, BSD Unix y Linux). No incluye mecanismos propios de seguridad. Migracin dbil.
- 502 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones GRASSHOPPER Desarrollado por la empresa IKV++ (Berln, Alemania) en 1998: http://www.ikv.de Basado en el lenguaje Java. Cumple con las normas especificadas en MASIF por el grupo OMG. Lugares, agencias, regiones. Interfaz de transporte: Java RMI, CORBA IIOP, sockets y SSL sockets. Incorpora mecanismos externos de seguridad. Migracin dbil. SUMATRA Desarrollado por la Universidad de Maryland en 1996. Basado en el lenguaje Java. MIGRACIN FUERTE: Es uno de los pocos sistemas basados en JVM que se han modificado para conseguir una migracin transparente de agentes. MOA (Mobile Objects and Agents): Proyecto diseado por Dejan S. Milojicic (1998) del Open Group Research Institute. Basado en Java y parecido al modelo de objetos de Telescript. OBLIQ: Desarrollado en DEC por Luca Cardelli (1995). Se basa en un lenguaje intrprete propietario que soporta un cmputo distribuido orientado a objetos. Ajanta: Desarrollado por la Universidad de Minesota. Se basa en Java. ...
- 503 -
8.6.3 Interoperabilidad entre sistemas de agentes mviles: MASIF

MASIF: Mobile Agent System Interoperability Facilities es la primera especificacin355 para agentes mviles, la cual fue publicada en 1997 por el grupo OMG para su modelo arquitectnico de referencia OMA/OMG. En concreto, es una facilidad comn horizontal accesible va ORB a travs de dos interfaces o componentes: MAFAgentSystem y MAFFinder. Dichos componentes definen operaciones normalizadas con un mismo formato de sintaxis para la gestin y el registro ms la localizacin de agentes mviles, respectivamente. MAFAgentSystem: Define operaciones normalizadas para la gestin bsica de agentes mviles: Crear un agente. Suspender un agente. Terminar un agente. Terminar un SA. Obtener el estado de un agente y gestin del mismo (suspender, reiniciar, terminar, etc.). Obtener informacin del SA (autoridad, agentes y lugares gestionados, etc.). Recepcin de un agente. Peticin de clases. MAFFinder: Define operaciones normalizadas para el registro y localizacin de los SA, lugares y agentes: Buscar un agente. Buscar un SA.
Existen otras especificaciones como la de FIPA (Fundacin para los Agentes Fsicos e Inteligentes o The Foundation for Intelligent Physical Agents: http://www.fipa.org) y la Sociedad de Agentes (The Agent Society: http://www.agent.org). Estos organismos estn dedicados a la normalizacin de la teora de agentes (estticos) en el contexto de la Inteligencia Artificial.
355
- 504 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Buscar un lugar. Inscribir un agente. Inscribir un SA.
Facilidades Comunes
Agente Mvil
MAFAgentSystem
MAFFinder
Stub IDL del Cliente
Interfaz del ORB
Skeleton IDL
Skeleton IDL
POA
Ncleo del ORB

Nombres Ciclo de Vida Seguridad
Negociacin de objetos
Externalizacin
Figura 8.58.- Los agentes mviles en la arquitectura OMA/OMG. La Figura 8.58 muestra cmo se desarrolla un agente mvil en el contexto de la arquitectura de referencia OMA/OMG, o lo que es lo mismo, en el escenario de CORBA. En dicho contexto, un agente mvil se comporta como un objeto CORBA u objeto ORB. Se recuerda que en este escenario, todos los objetos o componentes se comunican mediante interfaces IDL o llamadas internas al API de ORB. Asimismo, conviene recordar que el bus ORB ofrece un API para que el programador pueda llamar a los mtodos de los objetos de la arquitectura OMA/CORBA independientemente del lenguaje empleado. Se resalta, que la facilidad MASIF se public con el objetivo de definir un conjunto de interfaces que permitan la interoperabilidad entre los sistemas de agentes mviles existentes. Al tratarse los agentes mviles como una tecnologa emergente, los distintos SA existentes en el mercado difieren en arquitectura e implementacin, es decir, se consideran sistemas aislados o de carcter propietario carentes de interoperabilidad. Por - 505 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones consiguiente, el objetivo de MASIF es estandarizar algunos aspectos de la teora de agentes mviles para disponer de una base de interoperabilidad comn para dicha tecnologa. Asimismo, conviene destacar que para conseguir la ansiada interoperabilidad entre los SA, stos deben utilizar el mismo lenguaje de desarrollo para sus agentes. Por tanto, el entorno de ejecucin debe estar basado en el mismo lenguaje para poder reanudar o reiniciar la ejecucin de un agente en otra plataforma remota. Por ejemplo, sera milagroso retomar la ejecucin de un agente en Java en una plataforma para agentes en C.
Agencia1 agente1
MASIF
Agentes en el mismo lenguaje (p.ej., Java)
Agencia2 agente1
MASIF
ORB
IIOP
ORB
Red
IIOP
Agencia3 agente1
MASIF
ORB
Agentes en el mismo lenguaje (p.ej., C++)
Agencia4 agente1
MASIF
ORB
Figura 8.59.- Interoperabilidad va MASIF entre sistemas de agentes mviles. Los tipos de interaccin, entre agentes mviles relacionados con aspectos de interoperabilidad, son los siguientes: Creacin remota de un agente: El cliente interacta con el SA de destino para solicitar la creacin de una clase determinada de agente o bien el SA crea el agente de forma proactiva. Para cada agente existe una clase Agente a partir de la cual el SA lo instancia. Esta clase especifica su interfaz. Para crear un agente, un SA crea una instancia de dicha clase dentro del lugar especificado por el cliente o en un lugar por omisin. Pasos que efecta el SA: - 506 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Crear una instancia del agente. Arrancar un hilo de ejecucin. Generar, si es necesario, y asignar un nombre de agente globalmente nico que pueda ser autenticado. Iniciar la ejecucin de la instancia en el hilo de ejecucin.
Contemplar el concepto de regin. Un SA debe cooperar con otros SA de su misma autoridad y contemplar un punto de acceso a la regin que encamine las peticiones de viaje externas hacia los SA internos a dicha regin.
Bsqueda de agentes mviles. Puesto que los agentes migran de SA, sus nombres deben presentar unicidad. Los SA pueden proporcionar un servicio de nombres basado en nombres de agentes.
El cliente se debe autenticar en el SA de destino, estableciendo la autoridad y credenciales que poseer el agente creado. El cliente puede ser un: Programa en un sistema no orientado a agentes. Agente perteneciente a un SA del mismo o diferente tipo que el SA de destino. Transferencia de un agente: El SA de origen crea una solicitud de transferencia con la informacin356 de nombre y direccionamiento que identifica el lugar de destino.
356
Proporcionada por el agente.
- 507 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones Inicio de la transferencia: Identificacin por parte del agente mvil del destino (localizacin del lugar). Solicitud de trasferencia al SA origen utilizando un API interno del SA de destino. Una vez recibida la solicitud de transferencia en el SA de destino: o Se suspende el hilo de ejecucin del agente. Se identifica qu parte del estado del agente ser transferida. Se serializa la instancia de la clase del agente y su estado. Se codifica el agente en estado serializado y en un formato acorde con el protocolo de transporte escogido (p.ej., IIOP). Se autentica el cliente. Se transfiere el agente.
o o
Si el SA de destino acepta la transferencia, el SA de origen enviar el estado del agente, su autoridad, sus credenciales de seguridad y, en caso necesario, su cdigo. Recepcin del agente transferido. El SA de destino determina si puede interpretar el agente en funcin de su perfil, en cuyo caso: o o o Se autentica el cliente. Se decodifica el agente. Se deserializa la clase y el estado del agente. Se instancia el agente.
- 508 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones o o Se restaura su estado. Se contina su ejecucin.
Finalmente, el SA de destino reactivar el agente y continuar su ejecucin.
- 509 -
8.7

Bibliografa
Sistemas Distribuidos: Conceptos y Diseo, G. Coulouris, J. Dollimore, T. Kindberg, 3 edicin, Addison-Wesley, 2001. Distributed Computing Principles and Applications, M. L. Liu, Pearson Addison-Wesley, 2003. Cliente/Servidor Gua de supervivencia, R. Orfali, D. Harkey, J. Edwards, McGRAW-HILL, 1998 (2 edicin). Unix Network Programming, W. R. Stevens, Prentice Hall, 1990. Internetworking with TCP/IP Volumen III: Client-Server Programming and Applications BSD Socket Version, D. E. Comer, D. L. Stevens, Prentice Hall International, Inc., 1993. TCP/IP Tutorial and Tecnical Overview ; M. W. Murhammer, O. Atakan, S. Bretz, L.R. Pugh, K. Suzuki, D. H. Wood, IBM International Tecnical Support Organization, 2001. http://www.redbooks.ibm.com. Redes Globales de Informacin con Internet y TCP/IP, Principios bsicos, protocolos y arquitectura, Douglas E. Comer, 3 Edicin, Prentice Hall, 1996. Internetworking with TCP/IP. Principles, protocols and architectures. Vol. I, Douglas E. Comer, 4 Edicin, Prentice Hall, 2000. "TCP/IP Illustrated Volume 1: The Protocols", R.W. Stevens, Addison-Wesley, 1994. Comunicaciones y Redes de Computadores, W. Stallings, 6 Edicin, Prentice Hall, 1997. Redes de Comunicacin, Conceptos fundamentales y arquitecturas bsicas, Len Garca, A., Widjaja I.; McGraw-Hill, 2002. Redes de Computadores, Un Enfoque Descendente Basado en Internet, J.F. Kurose, K.W. Ross, Segunda Edicin, Addison Wesley, 2004. Inside TCP/IP, K. S. Siyan, 3 Edicin, New Riders, 1997. TCP/IP Arquitectura, protocolos e implementacin con IPv6 y seguridad de IP; Dr. Sydney Feit, Osborne McGraw-Hill, 1998. RFC-2292: Advanced Sockets API for IPv6, W. Stevens, M. Thomas, February 1998. RFC-1831: "RPC: Remote Procedure Call Protocol Specification Version 2", R. Srinivasan, August 1995. RFC-1833: "Binding Protocols for ONC RPC Version 2", R. Srinivasan, August 1995. "Power Programming with RPC", J Bloomer, O'Reilly & Asociates. Inc, 1992. "JINI in a Nutshell, A Desktop Quick Reference", Soaks, H.Wong. O'Reilly, 2000. "JINI Technology Core Plataform Specification", http://www.sun.com/jini/specs/core1_1.pdf "JINI Network Technology: An Executive Overview", http://www.sun.com/jini/whitepapers/ "RMI Documentation", http://java.sun.com/products/jdk/rmi/index.html. "ONC RPC/XDR", http://www.distinct.com/rpc/rpc.htm. "Client/Server Programming with Java and CORBA", Orfali, R. y Harley, D. (2 Edition) John Wiley & Sons, 1998. ISBN: 0-471-24578-X. "Java Distributed Computing", J. Farley. O'Reilly. 1998. "The CORBA Reference Guide, Understanding the Common Object Request Broker Architecture", A. Pope. Addison-Wesley, 1998. - 510 -
Captulo 8. Arquitecturas y Middleware de Comunicaciones "Arquitectura de Objetos Distribuidos CORBA", G Lpez, J Soriano, M Salas, R Siles. Servicio de publicaciones de la UPM, 2000. "Progamacin en Java. Desarrollo Orientado a Objetos de Aplicaciones Cliente/Servidor", G Lpez, J Soriano. Servicio de publicaciones de la UPM, 2001. "CORBA: Document and Specifications" http://www.omg.org/technology/documents.index.htm. "Java Programming with CORBA", Andreas Voguel, Keith Duddy. Wiley Computing Publishing, 1997. "The Common Object Request Broker: Architecture and Specification", Revision 2.3. OMG y X/Open Ltd. Junio 1999. MICO, http://www.mico.org/ ORBit, http://orbit-resource.sourceforge.net/ ORBit CORBA en GNOME, Rodrigo Moya, http://www.es.gnome.org/documentacion/articulos/ORBit/ORBit/t1.html Java y XML, M. Akif, S. Brodhead, A. Cioroianu, J. Hart, E. Jung, D. Writz, Anaya Multimedia, 2001. Desarrollo de soluciones XML, J. Sturm, Mc Graw Hill, 2000. Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI, S. Graham, S. Simeonov, T. Boubez, G. Daniels, D. Davis, Y. Nakamura, R. Neyama, Sams; 1st edition (December 12, 2001). Undestanding Web Services: XML, WSDL, SOAP, and UDDI, Eric Newcomer, Addison Wesley Professional; ; 1st edition (May 13, 2002). Web Services Essentials (O'Reilly XML), E. Cerami, O'Reilly & Associates; 1st edition (February 2002). Simple Object Access Protocol (SOAP) 1.1: http://www.w3.org/TR/SOAP/ Agent technology, N.R., Jennings, M.J., Wooldridge, Springer-Verlag, 1998. The Agent Home Page, http://www.agent.org. Mobile Agents, Cockayne, W. R. and Zyda, M.. Manning. 1997. Is it an Agent or just a program? A Taxonomy for Autonomous Agents Franklin, S., Greasser, A.. Universidad de Memphis. 1996. Mobile Agents: Are they a good idea? Harrison, C.G., Chess, D.M. and Kershenbaum, A.
- 511 -
- 512 -
PREFACIO
El objetivo de este libro es ofrecer una visin conceptual y tcnica de Internet en funcin de su arquitectura de comunicaciones TCP/IP. Es un libro bsico y completo que aborda los principales protocolos y servicios en cada unos de los niveles de comunicaciones de dicha arquitectura; haciendo especial hincapi, entre otros apartados temticos, en los mtodos de transmisin, direccionamiento y encaminamiento que se llevan a cabo en el escenario de TCP/IP. Asimismo, este libro contempla cmo est organizada, actualmente, la red Internet en funcin de sus diferentes centros y registros delegados. Adems, se analiza la problemtica de la transmisin de multimedia en tiempo real; y, finalmente, se proporcionan los conocimientos bsicos para desarrollar aplicaciones TCP/IP en funcin de las principales tecnologas y mecanismos de comunicaciones ms relevantes existentes, hoy en da, para el desarrollo de software en red. Por la experiencia docente de los autores en la materia en cuestin, se resalta que frente a las distintas tendencias existentes a la hora de abordar la explicacin de la arquitectura TCP/IP (enfoques ascendentes y descendentes por la pila de protocolos); este libro inicia la explicacin de dicha arquitectura, comenzando con la descripcin del paisaje de redes existente en Internet y la manera de direccionarse por dicha red de redes. En definitiva, se comienza por el direccionamiento IP del nivel de Internet o red que es en donde est la clave tcnica de todo el fenmeno de Internet y TCP/IP. A partir de este nivel de comunicaciones, que representa el autntico corazn de la arquitectura y la filosofa operativa de Internet, es cuando el resto de los niveles tienen sentido y, por tanto, el momento en que se deben analizar stos. Por la gran cantidad de conceptos reunidos, este libro est pensado, en principio, para cualquier persona relacionada directa o indirectamente con Internet; sin embargo, por la profundidad en su tratamiento, el libro en cuestin est dirigido especialmente a estudiantes de redes y comunicaciones, docentes, desarrolladores de software, curiosos y, tambin, a administradores y profesionales de las comunicaciones; fundamentalmente, si necesitan disear subredes, superredes, y/o convertir su red corporativa en un sistema autnomo de Internet. En este contexto, y entre otros objetivos, se pretende ofrecer una gua de ayuda para la planificacin, configuracin, uso y mantenimiento de una red TCP/IP y los servicios asociados ms relevantes. Se resalta que cada captulo dispone de su propia bibliografa para un acceso ms rpido y cmodo a las referencias concretas de la materia de estudio en cuestin. Dichas referencias se han estructurado, de la manera ms completa posible, en funcin de documentos propios de Internet, libros y direcciones por la red de documentos accesibles gratuitamente. Asimismo, se resalta la gran cantidad de figuras que acompaan a cada captulo, y que recogen, fundamentalmente, descripciones grficas para una mayor comprensin. Tambin estas figuras recogen los resmenes conceptuales ms relevantes y significativos. Se destaca que el nmero total de figuras es de 376 y que son fruto de la experiencia docente de los autores.
-i-
Por ltimo, esperamos que a travs del ndice temtico y de figuras presentado en este libro, se proporcione, al potencial lector, un mayor acercamiento al mundo actual de las comunicaciones; y, por supuesto, se le ofrezca una mayor comprensin del amplio y complejo abanico de funciones, servicios, protocolos y tecnologas asociadas al mundo de Internet y TCP/IP.
- ii -
RESUMEN
En un intento progresivo de asimilacin de conocimientos, el ndice temtico de este libro comienza con una introduccin a las arquitecturas estructuradas de comunicaciones. En concreto, el primer captulo del libro introduce al lector a la actual estratificacin arquitectnica en distintos niveles de comunicaciones. Se analiza cmo se lleva a cabo la comunicacin entre dichos niveles en una misma mquina o en mquinas diferentes, y se finaliza estudiando el estndar OSI como un modelo descriptivo de referencia de otras arquitecturas como es el caso de la arquitectura TCP/IP. El segundo captulo se adentra en el origen, historia, evolucin y organizacin de Internet y su arquitectura de comunicaciones TCP/IP. En este contexto, se analiza qu estructura de centros existe actualmente para acceder a Internet, cmo est estructurado el servicio de nombres simblicos y la disposicin jerrquica de organizaciones que hay al respecto. A continuacin, se describe el modelo de comunicaciones que impone la arquitectura TCP/IP en Internet. As, se asciende paulatinamente por dicha pila de protocolos del nivel ms elemental al ms superior; estudiando inicialmente de una manera global y conceptual los principales servicios, funciones y protocolos TCP/IP. Se prosigue con un anlisis completo del direccionamiento IP, clases de direcciones, tipos de mscaras existentes, y cmo se disean y crean subredes y superredes en una organizacin. Posteriormente, se estudian los protocolos de resolucin de direcciones, los conceptos de nmeros de puerto y sockets, y se finaliza con un anlisis de las principales aplicaciones TCP/IP. El tercer captulo efecta un anlisis del nivel de red o Internet, mostrando en profundidad los protocolos IPv4 e ICMPv4. Seguidamente, se hace lo propio con los protocolos IPv6 e ICMPv6. Asimismo, se describe la problemtica existente y las soluciones ms relevantes en la transicin de IPv4 a IPv6. Este captulo finaliza con otro protocolo ubicado en este mismo nivel de comunicaciones como es el protocolo IGMP de gestin de grupos en Internet, el cual se utiliza dentro del escenario de las transmisiones de multidifusin IP. El cuarto captulo comienza analizando lo que es un sistema autnomo y los diferentes dominios de encaminamiento que pueden existir dentro de l. Seguidamente, se describen los principales algoritmos y protocolos de encaminamiento dinmico para transmisiones de unidifusin. A su vez, el quinto captulo profundiza en el encaminamiento dinmico para envos de multidifusin y, por tanto, en los diferentes algoritmos y protocolos de encaminamiento dinmico existentes en dicho contexto. El sexto captulo se adentra en los protocolos TCP y UDP del nivel de transporte. Por consiguiente, analiza lo que es un transporte fiable y los mecanismos que se implementan para efectuarlo. Asimismo, tambin se explica el porqu de no disponer fiabilidad en este nivel de comunicaciones. A su vez, el sptimo captulo trata la problemtica de las transmisiones de multimedia en tiempo real en Internet y los diferentes protocolos existentes.
- iii -
Finalmente, el octavo captulo se dedica al estudio de los diferentes niveles intermedios de comunicaciones, por encima del nivel de transporte TCP/IP, que existen en la actualidad para el desarrollo de aplicaciones en red. Se analiza desde el modelo ms bsico en funcin de un interfaz de sockets hasta el modelo ms complejo basado en agentes mviles; todo ello, pasando por otros niveles intermedios desde un simple sistema RPC hasta mecanismos tipo Java RMI o CORBA.
- iv -
NDICE
1.
ARQUITECTURAS ESTRUCTURADAS DE COMUNICACIONES ........................................1 1.1 1.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.4 INTRODUCCIN Y GENERALIDADES ............................................................................................1 ESTRATIFICACIN EN NIVELES DE COMUNICACIONES.................................................................3 MODELO DE REFERENCIA OSI ....................................................................................................7 Niveles de comunicaciones ...................................................................................................9 Puntos de acceso al servicio ...............................................................................................13 Servicios .............................................................................................................................14 Protocolos e interfaces .......................................................................................................19 BIBLIOGRAFA ..........................................................................................................................21
2.
MODELO DE COMUNICACIONES EN INTERNET...............................................................23 2.1 HISTORIA .................................................................................................................................23 2.2 ORGANIZACIN DE CENTROS PARA EL ACCESO A INTERNET.....................................................34 2.3 JERARQUA DE CENTROS DE ACCESO A INTERNET ....................................................................37 2.4 EL ACCESO A INTERNET ...........................................................................................................38 2.5 ORGANIZACIN DE CENTROS PARA EL CONTROL Y EVOLUCIN DE INTERNET ..........................43 2.6 LAS ESPECIFICACIONES EN INTERNET: DOCUMENTOS RFC......................................................45 2.7 SISTEMA DE NOMBRES DE DOMINIO..........................................................................................48 2.8 DIRECCIONES NUMRICAS ........................................................................................................51 2.8.1 Direcciones numricas de la clase A ..................................................................................56 2.8.2 Direcciones numricas de la clase B ..................................................................................56 2.8.3 Direcciones numricas de la clase C..................................................................................57 2.8.4 Direcciones numricas de la clase D .................................................................................58 2.8.5 Direcciones numricas de la clase E ..................................................................................60 2.8.6 Direcciones numricas reservadas .....................................................................................60 2.8.7 Direcciones especiales .......................................................................................................63 2.9 CREACIN DE SUBREDES ..........................................................................................................64 2.10 TIPOS DE DIFUSIN ...................................................................................................................80 2.11 MSCARAS DE SUBRED DE LONGITUD VARIABLE .....................................................................83 2.12 TABLAS DE ENCAMINAMIENTO.................................................................................................86 2.13 SUPERREDES Y CIDR (CLASSLESS INTERNET DOMAIN ROUTING) ...........................................98 2.14 AGOTAMIENTO DEL ESPACIO DE DIRECCIONES EN INTERNET .................................................104 2.15 ARQUITECTURA TCP/IP: NIVELES Y UNIDADES DE DATOS ....................................................108 2.16 PROTOCOLOS ARP, RARP, BOOTP Y DHCP .......................................................................115 2.17 NMEROS DE PUERTOS Y SOCKETS .........................................................................................124 2.18 APLICACIONES DE TCP/IP ....................................................................................................128 2.18.1 Envo de correo electrnico: SMTP.............................................................................129 2.18.2 Recogida del correo electrnico: POP3 ......................................................................131 2.18.3 Gestin del correo electrnico: IMAP4 .......................................................................132 2.18.4 Protocolo de acceso remoto: TELNET ........................................................................133 2.18.5 Protocolo de transferencia de ficheros: FTP.............................................................135 2.18.6 Protocolo simple de transferencia de ficheros: TFTP .................................................136 2.18.7 Protocolo de comparticin de ficheros en red: NFS....................................................137 2.18.8 Protocolo de resolucin de direcciones simblicas en numricas: DNS .....................138
-v-
2.18.9
2.18.9.1
Protocolo para el servicio Web: HTTP .......................................................................139

Protocolo de acceso:// Referencia del objeto ......................................................................... 140
2.18.10 Protocolo de gestin de red: SNMP ............................................................................141 2.18.11 PING ............................................................................................................................142 2.18.12 NETSTAT .....................................................................................................................143 2.18.13 IPCONFIG...................................................................................................................144 2.18.14 ARP ..............................................................................................................................145 2.18.15 TRACERT ....................................................................................................................145 2.18.16 ROUTE ........................................................................................................................146 2.18.17 NSLOOKUP .................................................................................................................147 2.19 INTERFACES Y COMPUTADORAS VIRTUALES ...........................................................................149 2.20 ESCENARIOS BSICOS PARA UNA CONFIGURACIN TCP/IP ....................................................152 2.20.1 Conexin con Internet va una tarjeta de red ..............................................................153 2.20.2 Conexin con Internet va mdem a travs de un ISP .................................................159 2.21 BIBLIOGRAFA ........................................................................................................................167 3. NIVEL DE RED DE TCP/IP .......................................................................................................171 3.1 PROTOCOLO IP DE ENCAMINAMIENTO ...................................................................................171 3.1.1 Protocolo IP versin 4 ......................................................................................................173
3.1.1.1 Protocolo ICMP versin 4 de envo de mensajes de control ................................................. 182 Cabeceras de extensin de IPv6 ............................................................................................ 216 Protocolo ICMP versin 6 de envo de mensajes de control ................................................. 222
3.1.2
Protocolo IP versin 6 ......................................................................................................197
3.1.2.1 3.1.2.2
3.1.3 Transicin de IPv4 a IPv6 ................................................................................................228 3.1.4 IP mvil ............................................................................................................................237 3.1.5 Multidifusin IP en Internet: Protocolo IGMP de gestin de grupos de Internet ............244 3.2 BIBLIOGRAFA ........................................................................................................................256 4. ENCAMINAMIENTO DINMICO DE UNIDIFUSIN .........................................................259 4.1 ALGORITMOS Y PROTOCOLOS DE ENCAMINAMIENTO DINMICO ............................................259 4.1.1 Sistemas autnomos..........................................................................................................267 4.1.2 Protocolos especficos en el ambiente Internet ...............................................................269 4.1.3 Protocolo RIP (Routing Information Control) .................................................................274 4.1.4 Protocolo OSPF (Open Shortest Path First) ....................................................................289 4.1.5 Protocolo BGP (Border Gateway Protocol).....................................................................319 4.2 BIBLIOGRAFA ........................................................................................................................335 5. ENCAMINAMIENTO DINMICO DE MULTIDIFUSIN ...................................................337 5.1 EL PROBLEMA DEL ENCAMINAMIENTO DE MULTIDIFUSIN ....................................................337 5.1.1 Un rbol de grupo compartido por todos los orgenes.....................................................338 5.1.2 Un rbol de grupo basado en el origen ............................................................................341 5.2 ALGORITMOS PARA ENVOS DE MULTIDIFUSIN .....................................................................341 5.2.1 Inundacin (Flooding) ......................................................................................................341 5.2.2 rbol de expansin (Spanning Tree) ...............................................................................342 5.2.3 Difusin por el camino inverso (Reverse Path Broadcasting: RPB) ................................343 5.2.4 Difusin por el camino inverso truncado (Truncated- RPB: TRPB) ................................346 5.2.5 Multidifusin por el camino inverso (Reverse Path Multicast: RPM)..............................347 5.2.6 rboles basados en ncleos (Core-Based Trees: CBT) ....................................................349 5.3 PROTOCOLOS DE ENCAMINAMIENTO DE MULTIDIFUSIN........................................................353 5.3.1 Protocolo DVMRP (Distance-Vector Multicast Routing Protocol)..................................354 5.3.2 Protocolo MOSPF (Multicast Extensions to OSPF) ........................................................356
- vi -
5.4 RED TRONCAL DE MULTIDIFUSIN EN INTERNET: MBONE .....................................................365 5.4.1 Algunas aplicaciones para Mbone ...................................................................................370 5.5 BIBLIOGRAFA ...................................................................................................................372 6. NIVEL DE TRANSPORTE DE TCP/IP.....................................................................................373 6.1 6.2 6.3 7. PROTOCOLO TCP (TRANSMISIN CONTROL PROTOCOL) .......................................................373 PROTOCOLO UDP (USER DATAGRAM PROTOCOL) ................................................................399 BIBLIOGRAFA ........................................................................................................................404
APLICACIONES DE MULTIMEDIA EN TIEMPO REAL....................................................405 7.1 7.2 7.3 7.4 7.5 PROTOCOLO DE TRANSPORTE EN TIEMPO REAL: RTP .............................................................407 PROTOCOLO DE CONTROL RTP: RTCP ..................................................................................412 PROTOCOLO DE PRESENTACIN EN TIEMPO REAL: RTSP .......................................................416 LOS PROTOCOLOS DE MULTIMEDIA EN TCP/IP .......................................................................417 BIBLIOGRAFA ........................................................................................................................418
8. ARQUITECTURAS DE SOFTWARE Y NIVELES INTERMEDIOS (MIDDLEWARE) DE COMUNICACIONES PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS ...................419 8.1 8.2 8.3 8.3.1 8.4 8.4.1 8.4.2 8.5 8.6 8.6.1 8.6.2 DESARROLLO DE APLICACIONES EN RED: SISTEMAS DISTRIBUIDOS........................................422 MODELOS DE LLAMADAS A FUNCIONES: INTERFACES DE SOCKETS ........................................428 MODELOS DE LLAMADAS A PROCEDIMIENTOS REMOTOS: SISTEMAS RPC .............................435 Sistema RPC de Sun Microsystems...................................................................................445 MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS .................................................................447 JAVA RMI .........................................................................................................................448 CORBA .............................................................................................................................451 MODELO ORIENTADO A SERVICIOS WEB DISTRIBUIDOS .........................................................468 MODELOS ORIENTADOS A AGENTES MVILES ........................................................................476 Introduccin y generalidades ...........................................................................................476 Sistemas de agentes (agencias): Introduccin ..................................................................488
Lenguajes de programacin para el desarrollo de sistemas de agentes ................................. 493 Lenguajes para la comunicacin entre agentes mviles ........................................................ 494 Sistemas de agentes (agencias): Clasificacin....................................................................... 497
8.6.2.1 8.6.2.2 8.6.2.3
8.6.3 Interoperabilidad entre sistemas de agentes mviles: MASIF .........................................504 8.7 BIBLIOGRAFA ........................................................................................................................510
- vii -
- viii -
FIGURAS
FIGURA 1.1.- COMPARTICIN EN RED DE RECURSOS DE INFORMACIN Y COMPUTACIN. .............................1 FIGURA 1.2.- UNA HIPOTTICA RED INTERNET..............................................................................................2 FIGURA 1.3.- LA ARQUITECTURA ESTRUCTURADA DE COMUNICACIONES TCP/IP.........................................3 FIGURA 1.4.- COMUNICACIN ENTRE LOS DISTINTOS NIVELES DE UN MISMO SISTEMA..................................5 FIGURA 1.5.- COMUNICACIN ENTRE LOS DISTINTOS NIVELES EN SISTEMAS DIFERENTES .............................6 FIGURA 1.6.- INCLUSIN Y ELIMINACIN DE CABECERAS DE INFORMACIN DE CONTROL.............................7 FIGURA 1.7.- UNA HIPOTTICA RED OSI. ......................................................................................................9 FIGURA 1.8.- MODELO OSI DE ISO: FUNCIONES DE LOS NIVELES. ...............................................................9 FIGURA 1.9.- PUNTO DE ACCESO AL SERVICIO (SAP)..................................................................................13 FIGURA 1.10.- SERVICIO CONFIRMADO. ......................................................................................................14 FIGURA 1.11.- SERVICIO NO CONFIRMADO..................................................................................................15 FIGURA 1.12.- SERVICIO DEL NIVEL N ORIENTADO A CONEXIN. ...............................................................17 FIGURA 1.13.- SERVICIO DEL NIVEL N NO ORIENTADO A CONEXIN SIN CONFIRMACIN............................18 FIGURA 1.14.- SERVICIO DEL NIVEL N NO ORIENTADO A CONEXIN CON CONFIRMACIN. .........................19 FIGURA 1.15.- DIFERENCIAS ENTRE PROTOCOLO E INTERFAZ. ....................................................................20 FIGURA 2.1.- LOS PROTOCOLOS EN INTERNET.............................................................................................26 FIGURA 2.2.- FORMACIN DE UNA RED ABSTRACTA O DE COMPUTADORAS. ...............................................32 FIGURA 2.3.- UNA HIPOTTICA RED INTERNET............................................................................................33 FIGURA 2.4.- NMEROS EN INTERNET.........................................................................................................34 FIGURA 2.5.- JERARQUA DE CENTROS DE ACCESO A INTERNET. .................................................................37 FIGURA 2.6.- EL ACCESO A INTERNET. ........................................................................................................39 FIGURA 2.7.- TPICO ACCESO BSICO A INTERNET. .....................................................................................39 FIGURA 2.8.- PORTALES EN INTERNET. .......................................................................................................40 FIGURA 2.9.- ACCESO GRATIS A INTERNET. ................................................................................................41 FIGURA 2.10.- ORGANIZACIN DE CENTROS PARA EL CONTROL Y EVOLUCIN DE INTERNET......................43 FIGURA 2.11.- LA LITERATURA EN INTERNET. ............................................................................................45 FIGURA 2.12.- SISTEMA DE NOMBRES DE DOMINIO: IDENTIFICACIN SIMBLICA. ......................................48 FIGURA 2.13.- FORMATO DE LAS DIRECCIONES NUMRICAS. ......................................................................51 FIGURA 2.14.- UN EJEMPLO DE UNIDIFUSIN IP. .........................................................................................52 FIGURA 2.15.- UN EJEMPLO DE MULTIDIFUSIN IP......................................................................................53 FIGURA 2.16.- UN EJEMPLO DE DIFUSIN IP................................................................................................54 FIGURA 2.17.- CLASES DE DIRECCIONES NUMRICAS..................................................................................55 FIGURA 2.18.- FORMATO DE LAS DIRECCIONES NUMRICAS: CLASES A, B Y C. .........................................55 FIGURA 2.19.- FORMATO DE LAS DIRECCIONES DE LA CLASE A. .................................................................56 FIGURA 2.20.- FORMATO DE LAS DIRECCIONES DE LA CLASE B...................................................................57 FIGURA 2.21.- FORMATO DE LAS DIRECCIONES DE LA CLASE C...................................................................58 FIGURA 2.22.- FORMATO DE LAS DIRECCIONES DE LA CLASE D. .................................................................58 FIGURA 2.23.- FORMATO DE LAS DIRECCIONES DE LA CLASE E...................................................................60 FIGURA 2.24.- DIRECCIONES NUMRICAS RESERVADAS..............................................................................60 FIGURA 2.25.- RANGOS DE DIRECCIONES NUMRICAS: CLASES A, B Y C. ..................................................61 FIGURA 2.26.- NOTACIONES DECIMALES DEL PRIMER OCTETO PARA LAS CLASES A, B Y C. .......................62 FIGURA 2.27.- DIRECCIONES ESPECIALES....................................................................................................63 FIGURA 2.28.- CREACIN DE SUBREDES......................................................................................................65 FIGURA 2.29.- RESTRICCIONES EN LA CREACIN DE SUBREDES. .................................................................67 FIGURA 2.30.- DIRECCIONES RESERVADAS EN LA PARTE LOCAL AL CREAR SUBREDES................................68 FIGURA 2.31.- CONCEPTO DE MSCARA......................................................................................................69 FIGURA 2.32.- MSCARAS DE RED POR OMISIN.........................................................................................71 FIGURA 2.33.- CLCULO DEL OCTETO DE UNA MSCARA. ..........................................................................71
- ix -
FIGURA 2.34.- UN EJEMPLO SEGN LOS DOCUMENTOS RFC- 950 Y 1219. ..................................................72 FIGURA 2.35.- CONTINUACIN DEL EJEMPLO SEGN LOS DOCUMENTOS RFC- 950 Y 1219. .......................73 FIGURA 2.36.- EJEMPLOS DE OBTENCIN DE UNA MSCARA. ......................................................................74 FIGURA 2.37.- OBTENCIN DE LA MSCARA PARA EL ESCENARIO FINAL DEL EJEMPLO...............................75 FIGURA 2.38.- APLICACIN DE LA OPERACIN AND EN EL ESCENARIO DEL EJEMPLO. ...............................75 FIGURA 2.39.- CREACIN DE SUBREDES SIN SEGUIR LOS DOCUMENTOS RFC-950 Y 1219. .........................77 FIGURA 2.40.- OTRO EJEMPLO SEGN LOS DOCUMENTOS RFC-950 Y 1219................................................78 FIGURA 2.41.- OBTENCIN DE LA MSCARA PARA EL ESCENARIO FINAL DEL EJEMPLO...............................79 FIGURA 2.42.- APLICACIN DE LA OPERACIN AND EN EL ESCENARIO DEL EJEMPLO. ...............................80 FIGURA 2.43.- TIPOS DE DIFUSIN...............................................................................................................80 FIGURA 2.44.- UN EJEMPLO DE DIFUSIN DIRIGIDA A TODAS LAS SUBREDES. .............................................82 FIGURA 2.45.- CLASES DE MSCARAS DE SUBRED. .....................................................................................84 FIGURA 2.46.- EJEMPLO DE MSCARAS DE SUBRED DE LONGITUD VARIABLE. ............................................84 FIGURA 2.47.- PASO PRIMERO PARA OBTENER VLSM. ...............................................................................85 FIGURA 2.48.- PASO SEGUNDO PARA OBTENER VLSM. ..............................................................................86 FIGURA 2.49.- EJEMPLO SENCILLO DE UNA TABLA DE ENCAMINAMIENTO...................................................87 FIGURA 2.50.- UNA TABLA DE ENCAMINAMIENTO GENRICA......................................................................88 FIGURA 2.51.- UN EJEMPLO INCORRECTO DE UNA TABLA DE ENCAMINAMIENTO. .......................................89 FIGURA 2.52.- APLICACIN DE LA OPERACIN AND EN EL ESCENARIO DEL EJEMPLO. ...............................90 FIGURA 2.53.- APLICACIN DE LA OPERACIN AND EN EL ESCENARIO DEL EJEMPLO. ...............................90 FIGURA 2.54.- PROCEDIMIENTO DE OBTENCIN DE UNA MSCARA.............................................................91 FIGURA 2.55.- UN EJEMPLO CORRECTO DE TABLA DE ENCAMINAMIENTO. ..................................................91 FIGURA 2.56.- OTRO EJEMPLO CORRECTO DE TABLA DE ENCAMINAMIENTO. ..............................................92 FIGURA 2.57.- UN ESCENARIO PARA LA OBTENCIN DE MSCARAS. ...........................................................92 FIGURA 2.58.- UN PROCEDIMIENTO PARA LA OBTENCIN DE MSCARAS....................................................93 FIGURA 2.59.- CONTINUACIN DEL PROCEDIMIENTO DE OBTENCIN DE MSCARAS. .................................93 FIGURA 2.60.- FINALIZACIN DEL PROCEDIMIENTO DE OBTENCIN DE MSCARAS.....................................94 FIGURA 2.61.- UN EJEMPLO COMPLETO DE UNA TABLA DE ENCAMINAMIENTO. ..........................................94 FIGURA 2.62.- EJEMPLO DEL TPICO ROUTER CENTRALIZADO DE UNA ORGANIZACIN. ..............................96 FIGURA 2.63.- ANIDAMIENTO DE ROUTERS Y SUBREDES. ............................................................................97 FIGURA 2.64.- SOLUCIONES A LOS PROBLEMAS DE DIRECCIONAMIENTO IPV4. ...........................................98 FIGURA 2.65.- EJEMPLO DE FORMATO Y BLOQUE CIDR............................................................................100 FIGURA 2.66.- EJEMPLO DE ASIGNACIN DE REDES CONTIGUAS. ..............................................................102 FIGURA 2.67.- EJEMPLO DE FORMATO CIDR. ...........................................................................................103 FIGURA 2.68.- AGOTAMIENTO DEL ESPACIO DE DIRECCIONES EN INTERNET. ............................................104 FIGURA 2.69.- NIVELES Y UNIDADES DE DATOS DE LA ARQUITECTURA TCP/IP........................................108 FIGURA 2.70.- COMUNICACIN ENTRE NIVELES DE SISTEMAS CONTIGUOS................................................110 FIGURA 2.71.- COMUNICACIN ENTRE NIVELES DE SISTEMAS NO CONTIGUOS. .........................................111 FIGURA 2.72.- COMPARATIVA ARQUITECTNICA......................................................................................112 FIGURA 2.73.- COMUNICACIN ENTRE LOS DIFERENTES NIVELES TCP/IP.................................................112 FIGURA 2.74.- NIVELES INFERIORES DE LA ARQUITECTURA TCP/IP. ........................................................113 FIGURA 2.75.- PROTOCOLO ARP DE RESOLUCIN DE DIRECCIONES..........................................................115 FIGURA 2.76.- PROTOCOLO RARP DE RESOLUCIN DE DIRECCIONES.......................................................116 FIGURA 2.77.- ALTERNATIVAS AL PROTOCOLO RARP..............................................................................117 FIGURA 2.78.- NIVELES SOFTWARE Y HARDWARE EN UNA RED DE ACCESO IEEE 802. .............................122 FIGURA 2.79.- EL PROTOCOLO DEL INTERFAZ DE RED EN LNEAS SERIE EN INTERNET...............................123 FIGURA 2.80.- ESCENARIO DE USO DEL PROTOCOLO DEL INTERFAZ DE RED EN LNEAS SERIE. ..................123 FIGURA 2.81.- NMEROS DE PUERTO. .......................................................................................................125 FIGURA 2.82.- EJEMPLO DE UNA IDENTIFICACIN Y COMUNICACIN DEL CLIENTE Y SERVIDOR. ..............126 FIGURA 2.83.- DOS CONEXIONES VA SOCKET...........................................................................................126
-x-
FIGURA 2.84.- INFORMACIN MS RELEVANTE EN LAS CABECERAS DE INFORMACIN DE CONTROL. .......127 FIGURA 2.85.- PROTOCOLOS MS SIGNIFICATIVOS DE LA ARQUITECTURA TCP/IP. ..................................128 FIGURA 2.86.- EL NIVEL DE APLICACIN DE LA ARQUITECTURA TCP/IP...................................................129 FIGURA 2.87.- ENVO DE CORREO ELECTRNICO VA SMTP. ....................................................................130 FIGURA 2.88.- TRANSMISIN DE DATOS BINARIOS VA MIME. .................................................................131 FIGURA 2.89.- RECOGIDA DEL CORREO ELECTRNICO VA POP3..............................................................131 FIGURA 2.90.- GESTIN DEL CORREO ELECTRNICO VA IMAP4..............................................................133 FIGURA 2.91.- EL PROTOCOLO TELNET DE ACCESO REMOTO. ...................................................................134 FIGURA 2.92.- EL SERVICIO DE TERMINAL REMOTO DEL PROTOCOLO TELNET. .........................................134 FIGURA 2.93.- LOS PROCESOS INTERNOS DEL PROTOCOLO FTP. ...............................................................135 FIGURA 2.94.- EL PROTOCOLO SIMPLE TFTP DE TRANSFERENCIA DE FICHEROS. ......................................136 FIGURA 2.95.- EL PROTOCOLO NFS DE COMPARTICIN DE FICHEROS EN RED...........................................137 FIGURA 2.96.- UN EJEMPLO DE RESOLUCIN DE DIRECCIONES VA DNS...................................................138 FIGURA 2.97.- EL SERVICIO WWW...........................................................................................................140 FIGURA 2.98.- FUNCIONAMIENTO DEL PROTOCOLO SNMP.......................................................................141 FIGURA 2.99.- OPCIONES DEL SERVICIO PING..........................................................................................142 FIGURA 2.100.- OPCIONES DEL SERVICIO NETSTAT................................................................................143 FIGURA 2.101.- OPCIONES DEL SERVICIO IPCONFIG...............................................................................144 FIGURA 2.102.- OPCIONES DEL SERVICIO ARP. ........................................................................................145 FIGURA 2.103.- OPCIONES DEL SERVICIO TRACERT. ..............................................................................146 FIGURA 2.104.- OPCIONES DEL SERVICIO ROUTE. ...................................................................................146 FIGURA 2.105.- OPCIONES DEL SERVICIO NSLOOKUP. ...........................................................................147 FIGURA 2.106.- UN INTERFAZ VIRTUAL CON UNA DIRECCIN PROPIA DE LA RED. .....................................149 FIGURA 2.107.- UN INTERFAZ VIRTUAL CON UNA DIRECCIN PRIVADA CLASE C. .....................................150 FIGURA 2.108.- UNA MISMA RED SOPORTANDO DOS DIRECCIONES IP. ......................................................151 FIGURA 2.109.- UN EJEMPLO DE ESCENARIO BSICO PARA UNA CONFIGURACIN TCP/IP........................153 FIGURA 2.110.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................154 FIGURA 2.111.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................154 FIGURA 2.112.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................155 FIGURA 2.113.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................156 FIGURA 2.114.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................156 FIGURA 2.115.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................157 FIGURA 2.116.- LA CONFIGURACIN TCP/IP DEL EJEMPLO. .....................................................................158 FIGURA 2.117.- OTRO EJEMPLO DE ESCENARIO BSICO PARA UNA CONFIGURACIN TCP/IP....................159 FIGURA 2.118.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................160 FIGURA 2.119.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................160 FIGURA 2.120.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................161 FIGURA 2.121.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................161 FIGURA 2.122.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................162 FIGURA 2.123.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................162 FIGURA 2.124.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................163 FIGURA 2.125.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................163 FIGURA 2.126.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................164 FIGURA 2.127.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................164 FIGURA 2.128.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................165 FIGURA 2.129.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................166 FIGURA 2.130.- UNA CONFIGURACIN TCP/IP TELEFNICA Y VA MDEM. .............................................166 FIGURA 3.1.- EL PROTOCOLO IP Y SUS VECINOS EN LA ARQUITECTURA TCP/IP. ......................................171 FIGURA 3.2.- UN EJEMPLO DE ESCENARIO PARA IP. ..................................................................................171 FIGURA 3.3.- VERSIONES DEL PROTOCOLO IP Y SUS CARACTERSTICAS....................................................172
- xi -
FIGURA 3.4.- CARACTERSTICAS FUNDAMENTALES DEL PROTOCOLO IPV4...............................................173 FIGURA 3.5.- FORMATO DEL DATAGRAMA IPV4. ......................................................................................173 FIGURA 3.6.- FORMATO COMPLETO DEL DATAGRAMA IPV4......................................................................174 FIGURA 3.7.- NUEVA ESPECIFICACIN DEL CAMPO TOS SEGN EL DOCUMENTO RFC-1349. ...................176 FIGURA 3.8.- FORMATO DE LAS OPCIONES DE SERVICIO IP........................................................................178 FIGURA 3.9.- UN EJEMPLO DE FRAGMENTACIN IP...................................................................................180 FIGURA 3.10.- UBICACIN DEL PROTOCOLO ICMP EN LA ARQUITECTURA TCP/IP. .................................182 FIGURA 3.11- CARACTERSTICAS MS SIGNIFICATIVAS DEL PROTOCOLO ICMP. ......................................182 FIGURA 3.12.- EJEMPLO DEL ENVO DE UN MENSAJE ICMP. .....................................................................183 FIGURA 3.13.- ENCAPSULACIN DESDE ICMP. .........................................................................................183 FIGURA 3.14.- FORMATO GENERAL DE UN MENSAJE ICMPV4...................................................................184 FIGURA 3.15.- FORMATO ESPECFICO DE UN MENSAJE ICMPV4................................................................185 FIGURA 3.16.- PRINCIPALES SERVICIOS DEL PROTOCOLO ICMPV4. ..........................................................185 FIGURA 3.17.- FORMATO DE LOS MENSAJES DE DESTINO INALCANZABLE. ................................................187 FIGURA 3.18.- FORMATO DE UN MENSAJE DE FRENADO DEL ORIGEN. .......................................................188 FIGURA 3.19.- FORMATO DE LOS MENSAJES DE TIEMPO EXCEDIDO. ..........................................................189 FIGURA 3.20.- FORMATO DE LOS MENSAJES DE PARMETRO ININTELIGIBLE.............................................189 FIGURA 3.21.- FORMATO DE LOS MENSAJES DE SELLO DE TIEMPO. ...........................................................190 FIGURA 3.22.- FORMATO DE LOS MENSAJES DE MSCARA. .......................................................................191 FIGURA 3.23.- FORMATO DE LOS MENSAJES DE REDIRECCIONAR. .............................................................192 FIGURA 3.24.- FORMATO DE LOS MENSAJES DE ECO..................................................................................193 FIGURA 3.25- APLICACIONES ICMPV4. ....................................................................................................194 FIGURA 3.26.- CARACTERSTICAS GENERALES DEL PROTOCOLO IPV6. .....................................................197 FIGURA 3.27.- SOLICITUD DE PROPUESTAS PARA UN IPNG. .......................................................................199 FIGURA 3.28.- FORMATO DE LOS DATAGRAMAS IPV6...............................................................................204 FIGURA 3.29.- FORMATO DE LA CABECERA FIJA IPV6. ..............................................................................205 FIGURA 3.30.- LOS DOS TIPOS DE TRFICO DEFINIDOS POR EL CAMPO DE PRIORIDAD. ..............................207 FIGURA 3.31.- LOS PREFIJOS DE LAS DIRECCIONES DE IPV6. .....................................................................208 FIGURA 3.32.- DIRECCIONES DE UNIDIFUSIN...........................................................................................210 FIGURA 3.33.- FORMATOS DE DIRECCIONES DE UNIDIFUSIN DE IPV6. .....................................................211 FIGURA 3.34.- PREFIJOS DE LA DIRECCIN BASADA EN EL PROVEEDOR.....................................................212 FIGURA 3.35.- OTRAS DIRECCIONES DE IPV6. ...........................................................................................213 FIGURA 3.36.- FORMATO DE REPRESENTACIN DE LAS DIRECCIONES DE IPV6..........................................214 FIGURA 3.37.- SECUENCIA DE CABECERAS EN UN DATAGRAMA IPV6. ......................................................217 FIGURA 3.38.- FORMATO DE LA CABECERA DE SALTO A SALTO.................................................................217 FIGURA 3.39.- CABECERA DE OPCIONES DE SALTO A SALTO PARA JUMBOGRAMAS. ..................................219 FIGURA 3.40.- CABECERA DE FRAGMENTACIN........................................................................................220 FIGURA 3.41.- FORMATO DE LA CABECERA DE ENCAMINAMIENTO. ..........................................................221 FIGURA 3.42.- CARACTERSTICAS BSICAS DE ICMPV6. ..........................................................................222 FIGURA 3.43.- LOS MENSAJES BSICOS DE ICMPV6. ................................................................................223 FIGURA 3.44.- MENSAJE ICMPV6 DE DESTINO INALCANZABLE................................................................224 FIGURA 3.45.- MENSAJE ICMPV6 DE PAQUETE DEMASIADO GRANDE. .....................................................225 FIGURA 3.46.- MENSAJE ICMPV6 DE TIEMPO EXCEDIDO..........................................................................226 FIGURA 3.47.- MENSAJE ICMPV6 DE PROBLEMA CON LOS PARMETROS. ................................................227 FIGURA 3.48.- MENSAJE ICMPV6 DE SOLICITUD Y RESPUESTA DE ECO. ...................................................227 FIGURA 3.49.- EJEMPLO DE TRADUCCIN DE PROTOCOLOS Y DIRECCIONES DE RED..................................229 FIGURA 3.50.- ARQUITECTURA DE COMUNICACIONES DEL EJEMPLO. ........................................................230 FIGURA 3.51.- PILA DUAL EN UN SISTEMA FINAL CON UN ROUTER MULTIPROTOCOLO. .............................232 FIGURA 3.52.- PILA DUAL EN UN SISTEMA FINAL CON DOS ROUTERS.........................................................233 FIGURA 3.53.-TNEL DE IPV6 SOBRE IPV4. ..............................................................................................234
- xii -
FIGURA 3.54.- ARQUITECTURA DE COMUNICACIONES DEL EJEMPLO. ........................................................235 FIGURA 3.55.- ENCAPSULACIN DE IPV6 SOBRE IPV4. .............................................................................236 FIGURA 3.56.- EJEMPLO DE OTROS POSIBLES TNELES. ............................................................................236 FIGURA 3.57.- MECANISMO BSICO DE ENCAMINAMIENTO DE IP MVIL..................................................238 FIGURA 3.58.- EL REGISTRO CON HA........................................................................................................240 FIGURA 3.59.- ENCAPSULAMIENTO IP SOBRE IP PARA UN TNEL DE IP MVIL. .......................................242 FIGURA 3.60.- UN EJEMPLO DE ENCAMINAMIENTO DE IP MVIL...............................................................243 FIGURA 3.61.- OTRO MECANISMO DE ENCAMINAMIENTO DE IP MVIL. ....................................................243 FIGURA 3.62. MULTIDIFUSIN IP FRENTE A UNIDIFUSIN IP. ...................................................................246 FIGURA 3.63.- MULTIDIFUSIN IP FRENTE A DIFUSIN IP.........................................................................247 FIGURA 3.64.- UBICACIN DEL PROTOCOLO IGMP EN LA ARQUITECTURA TCP/IP. .................................248 FIGURA 3.65.- ENCAPSULACIN DE UN MENSAJE IGMP. ..........................................................................249 FIGURA 3.66.- TRASLACIN (MAPPING) IPV4 CLASE D EN MULTIDIFUSIN IEEE 802.............................250 FIGURA 3.67.- FORMATO DE LA DIRECCIN IPV6 DE MULTIDIFUSIN. ......................................................251 FIGURA 3.68.- FORMATO ACTUAL DE LA DIRECCIN IPV6 DE MULTIDIFUSIN. ........................................252 FIGURA 3.69.- FORMATO DE UN MENSAJE IGMP. .....................................................................................252 FIGURA 3.70.- ENVO DE SOLICITUDES E INFORMES DE PERTENENCIAS A GRUPOS.....................................254 FIGURA 4.1.- EL PROTOCOLO OSPF EN LA ARQUITECTURA TCP/IP..........................................................259 FIGURA 4.2.- UN ESCENARIO BASADO EN EL VECTOR DE DISTANCIA.........................................................263 FIGURA 4.3.- UN ESCENARIO BASADO EN EL ESTADO DEL ENLACE............................................................265 FIGURA 4.4.- UN EJEMPLO DE ESCENARIO CON PROTOCOLOS DE ENCAMINAMIENTO.................................269 FIGURA 4.5.- LOS PROTOCOLOS MS RELEVANTES IGP Y EGP.................................................................271 FIGURA 4.6.- CARACTERSTICAS MS RELEVANTES DEL PROTOCOLO RIP. ...............................................274 FIGURA 4.7.- RESOLUCIN DE BUCLES: SELECCIN DE UN INFINITO PEQUEO. ........................................277 FIGURA 4.8.- MECANISMOS DE RESOLUCIN DE BUCLES...........................................................................278 FIGURA 4.9.- UN EJEMPLO (I) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP........................280 FIGURA 4.10.- UN EJEMPLO (II) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP. ...................281 FIGURA 4.11.- UN EJEMPLO (III) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP...................282 FIGURA 4.12.- UN EJEMPLO (IV) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP...................282 FIGURA 4.13.- UN EJEMPLO (V) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP. ...................282 FIGURA 4.14.- UN EJEMPLO (VI) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP...................283 FIGURA 4.15.- UN EJEMPLO (VII) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP. ................283 FIGURA 4.16.- UN EJEMPLO (VIII) CONCEPTUAL DEL FUNCIONAMIENTO DEL PROTOCOLO RIP. ...............284 FIGURA 4.17.- FORMATO DE LOS MENSAJES RIP V1..................................................................................284 FIGURA 4.18.- FORMATO DE LOS MENSAJES RIP V2..................................................................................287 FIGURA 4.19.- FORMATO DE AUTENTICACIN DE RIP V2. ........................................................................288 FIGURA 4.20.- CARACTERSTICAS MS RELEVANTES DEL PROTOCOLO OSPF. ..........................................289 FIGURA 4.21.- MS CARACTERSTICAS DEL PROTOCOLO OSPF. ...............................................................292 FIGURA 4.22.- UN EJEMPLO DEL MAPA TOPOLGICO DEL PROTOCOLO OSPF. ..........................................293 FIGURA 4.23.- UN EJEMPLO DE UNA RED TRONCAL Y DOS REAS. ............................................................294 FIGURA 4.24.- DEFINICIN DE REA TRONCAL Y CLASES DE ROUTERS OSPF. ..........................................295 FIGURA 4.25.- UN EJEMPLO DE ROUTERS Y REAS EN UN SISTEMA AUTNOMO. .......................................297 FIGURA 4.26.- UN EJEMPLO DE ROUTERS Y REAS EN UN SISTEMA AUTNOMO. .......................................299 FIGURA 4.27.- UN EJEMPLO DE RUTAS INTRAREA, INTERREA E INTERSA. ............................................300 FIGURA 4.28.- UN EJEMPLO DE SA............................................................................................................301 FIGURA 4.29.- EL GRAFO DIRIGIDO CON ARCOS DEL EJEMPLO DEL SA......................................................302 FIGURA 4.30.- RBOL PODADO DESDE R3 Y SU BASE DE DATOS. ..............................................................305 FIGURA 4.31.- CABECERA FIJA DE UN PAQUETE: TIPOS DE PAQUETES.......................................................306 FIGURA 4.32.- FORMATO DEL PAQUETE DE SALUDO OSPF. ......................................................................308 FIGURA 4.33.- FORMATO DEL PAQUETE DE DESCRIPCIN DE LA BASE DE DATOS. ....................................312
- xiii -
FIGURA 4.34.- FORMATO DEL PAQUETE DE SOLICITUD DE ESTADO DEL ENLACE. ......................................315 FIGURA 4.35.- FORMATO DEL PAQUETE DE ACTUALIZACIN DE ESTADO DEL ENLACE. .............................316 FIGURA 4.36.- FORMATO DEL PAQUETE DE CONFIRMACIN DE ESTADO DEL ENLACE. ..............................317 FIGURA 4.37.- UN EJEMPLO DE ESCENARIO PARA EL PROTOCOLO BGP.....................................................319 FIGURA 4.38.- CARACTERSTICAS MS RELEVANTES DEL PROTOCOLO BGP.............................................320 FIGURA 4.39.- UN EJEMPLO ENTRE ROUTERS BGP....................................................................................323 FIGURA 4.40.- LOS MENSAJES DE ACTUALIZACIN EN EL ESCENARIO DEL EJEMPLO. ................................323 FIGURA 4.41.- UN EJEMPLO DE UN ESCENARIO BGP. ................................................................................324 FIGURA 4.42.- PROCEDIMIENTOS FUNCIONALES Y MENSAJES ASOCIADOS BGP. .......................................325 FIGURA 4.43.- FORMATO DE LOS MENSAJES BGP. ....................................................................................327 FIGURA 4.44.- FORMATO DEL MENSAJE BGP DE ABRIR (OPEN).................................................................328 FIGURA 4.45.- FORMATO DEL MENSAJE BGP DE ACTUALIZAR (UPDATE)..................................................329 FIGURA 4.46.- FORMATO DEL MENSAJE BGP DE CONTINUAR (KEEPALIVE). .............................................332 FIGURA 4.47.- FORMATO DEL MENSAJE BGP DE NOTIFICACIN (NOTIFICATION)......................................333 FIGURA 4.48.- PROTOCOLOS PARA EL ENCAMINAMIENTO DINMICO DE IPV6. .........................................334 FIGURA 5.1.- UN EJEMPLO DE UN ESCENARIO DE MULTIDIFUSIN.............................................................337 FIGURA 5.2.- UN NICO RBOL COMPARTIDO CALCULANDO LAS RUTAS MS CORTAS. ............................339 FIGURA 5.3.- UN NICO RBOL COMPARTIDO CALCULANDO LAS RUTAS DE COSTE MNIMO. ....................340 FIGURA 5.4.- UN EJEMPLO DEL ALGORITMO DE INUNDACIN....................................................................342 FIGURA 5.5.- UN EJEMPLO DEL ALGORITMO DEL RBOL DE EXPANSIN. ..................................................343 FIGURA 5.6.- FUNDAMENTO OPERATIVO DE RPB......................................................................................344 FIGURA 5.7.- UN EJEMPLO DEL ALGORITMO RPB. ....................................................................................345 FIGURA 5.8.- UN EJEMPLO DEL ALGORITMO TRPB. ..................................................................................346 FIGURA 5.9.- UN EJEMPLO DEL ALGORITMO RPM.....................................................................................347 FIGURA 5.10.- OTRO EJEMPLO DEL ALGORITMO RPM...............................................................................348 FIGURA 5.11.- UN EJEMPLO DE REGIN CBT. ...........................................................................................350 FIGURA 5.12.- EJEMPLO DE LA PROGRESIN DE UNA SOLICITUD DE CBT DE PERTENENCIA......................351 FIGURA 5.13.- UNA TRANSMISIN DE MULTIDIFUSIN BASADA EN NCLEOS............................................352 FIGURA 5.14.- UN SISTEMA AUTNOMO DE TRES REAS CON ROUTERS MOSPF. .....................................358 FIGURA 5.15.- EJEMPLO DE UN SISTEMA AUTNOMO MOSPF. .................................................................360 FIGURA 5.16.- EJEMPLOS DE MULTIDIFUSIONES INTRREAS. ....................................................................361 FIGURA 5.17.- EJEMPLO DE ENVOS DE TRFICOS DE ORIGEN HACIA EL RFAM. .......................................362 FIGURA 5.18.- EJEMPLOS DE PASO DE AVISOS LSA DE RESMENES DE PERTENENCIA. .............................362 FIGURA 5.19.- EJEMPLO DE UNA MULTIDIFUSIN INTERREA...................................................................363 FIGURA 5.20.- EJEMPLOS DE MULTIDIFUSIONES INTERSA.........................................................................364 FIGURA 5.21.- UN EJEMPLO DE UN POSIBLE ESCENARIO MBONE. .............................................................365 FIGURA 5.22.- UN EJEMPLO DE TNEL ENTRE DOS ROUTERS DE MULTIDIFUSIN. .....................................366 FIGURA 5.23.- CABECERAS IP DE UN DATAGRAMA DE MULTIDIFUSIN ENCAPSULADO. ...........................366 FIGURA 5.24.- UN EJEMPLO MS DETALLADO DE UN ESCENARIO MBONE. ...............................................367 FIGURA 5.25.- LA RED MBONE EN ESPAA: IRIS-IPV6............................................................................370 FIGURA 6.1.- UN EJEMPLO DE ESCENARIO PARA TCP................................................................................373 FIGURA 6.2.- CARACTERSTICAS MS RELEVANTES DEL PROTOCOLO TCP. ..............................................374 FIGURA 6.3.- FORMATO DE UN SEGMENTO TCP........................................................................................377 FIGURA 6.4.- FORMATO DE LA CABECERA DE UN SEGMENTO TCP CON TODOS SUS CAMPOS.....................378 FIGURA 6.5.- INTERCAMBIO DE FLUJOS DE OCTETOS ENTRE APLICACIONES. .............................................381 FIGURA 6.6.- PSEUDOCABECERA TCP.......................................................................................................383 FIGURA 6.7.- FASE DE ESTABLECIMIENTO DE UNA CONEXIN TCP SIN OPCIONES. ...................................385 FIGURA 6.8.- FASE DE ESTABLECIMIENTO DE UNA CONEXIN TCP CON LA OPCIN MSS.........................386 FIGURA 6.9.- UN EJEMPLO DE UNA FASE DE ESTABLECIMIENTO DE UNA CONEXIN TCP..........................387 FIGURA 6.10.- UN EJEMPLO DE UNA FASE DE TRANSFERENCIA DE DATOS TCP SIN ERRORES....................388
- xiv -
FIGURA 6.11.- UN EJEMPLO DE UNA FASE DE TRANSFERENCIA DE DATOS TCP CON ERRORES. .................390 FIGURA 6.12.- FASE DE LIBERACIN DE UNA CONEXIN TCP. ..................................................................392 FIGURA 6.13.- EL TEMPORIZADOR FINAL EN UNA LIBERACIN TCP. ........................................................394 FIGURA 6.14.- UN EJEMPLO DE UNA FASE DE LIBERACIN TCP SIN DATOS...............................................395 FIGURA 6.15.- UN EJEMPLO GENRICO DE UNA FASE DE LIBERACIN TCP CON DATOS. ...........................396 FIGURA 6.16.- UN EJEMPLO CONCRETO DE UNA FASE DE LIBERACIN TCP CON DATOS. ..........................397 FIGURA 6.17.- UN EJEMPLO DE ESCENARIO PARA UDP. ............................................................................399 FIGURA 6.18.- CARATERSTICAS MS RELEVANTES DEL PROTOCOLO UDP...............................................399 FIGURA 6.19.- FORMATO DE UN DATAGRAMA UDP. .................................................................................401 FIGURA 6.20.- FORMATO DE LA CABECERA DE UN DATAGRAMA UDP CON TODOS SUS CAMPOS...............401 FIGURA 6.21.- PSEUDOCABECERA UDP. ...................................................................................................403 FIGURA 7.1.- ESCENARIO DE APLICACIN. ................................................................................................405 FIGURA 7.2.- CARACTERSTICAS DEL PROTOCOLO RTP. ...........................................................................407 FIGURA 7.3.- DOS VISTAS EQUIVALENTES DE LA UBICACIN RTP EN TCP/IP. .........................................408 FIGURA 7.4.- UN EJEMPLO DE UN ENVO DE PAQUETES RTP. ....................................................................410 FIGURA 7.5.- CARACTERSTICAS DEL PROTOCOLO RTCP. ........................................................................412 FIGURA 7.6.- UN EJEMPLO DE UN ENVO DE PAQUETES RTCP...................................................................413 FIGURA 7.7.- UBICACIN DE LOS PROTOCOLOS RTP Y RTCP EN LA ARQUITECTURA TCP/IP. .................413 FIGURA 7.8.- LOS NIVELES MULTIMEDIA TCP/IP. .....................................................................................417 FIGURA 8.1.- ALTERNATIVAS EN EL DESARROLLO DE APLICACIONES EN RED. ..........................................419 FIGURA 8.2.- PROCESOS BSICOS DE INTERACCIN EN RED. .....................................................................422 FIGURA 8.3.- EVOLUCIN EN EL ACCESO A LOS SERVICIOS (I)...................................................................423 FIGURA 8.4.- EVOLUCIN EN EL ACCESO A LOS SERVICIOS (II). ................................................................424 FIGURA 8.5.- UN SERVICIO PROPORCIONADO POR MLTIPLES SERVIDORES. .............................................424 FIGURA 8.6.- TIPOS DE ARQUITECTURAS DE CLIENTE-SERVIDOR...............................................................425 FIGURA 8.7.- NIVELES DE SERVICIO DE SOFTWARE Y HARDWARE. ............................................................426 FIGURA 8.8.- EJEMPLOS DE SISTEMAS DISTRIBUIDOS POR INTERNET.........................................................426 FIGURA 8.9.- INTERFAZ ENTRE EL NIVEL DE TRANSPORTE Y APLICACIN. ................................................428 FIGURA 8.10.- UBICACIN DEL INTERFAZ DE SOCKETS EN LA ARQUITECTURA TCP/IP. ............................429 FIGURA 8.11.- PROGRAMANDO CON EL INTERFAZ DE SOCKETS. ................................................................430 FIGURA 8.12.- LAS FUNCIONES DEL INTERFAZ DE SOCKETS PARA TCP. ....................................................434 FIGURA 8.13.- LAS FUNCIONES DEL INTERFAZ DE SOCKETS PARA UDP. ...................................................434 FIGURA 8.14.- UBICACIN DE UN SISTEMA RPC EN LA ARQUITECTURA TCP/IP.......................................435 FIGURA 8.15.- DESCRIPCIN GRFICA DEL FUNCIONAMIENTO DE UN SISTEMA RPC.................................436 FIGURA 8.16.- MODELO CONCEPTUAL PARA LLAMADAS A PROCEDIMIENTOS CONVENCIONALES. ............437 FIGURA 8.17.- UNA EXTENSIN AL MODELO DE PROCEDIMIENTOS............................................................437 FIGURA 8.18.- MODELO DE PROCEDIMIENTOS EN SISTEMAS DISTRIBUIDOS...............................................438 FIGURA 8.19.- EL SISTEMA RPC DE SUN Y EL MODELO OSI. ....................................................................438 FIGURA 8.20.- PROCESAMIENTO DE UNA LLAMADA A UN PROCEDIMIENTO REMOTO.................................440 FIGURA 8.21.- LA PROGRAMACIN MEDIANTE UN RPC GENRICO. ..........................................................441 FIGURA 8.22.- RPC: PORTMAPPER Y PUERTOS DINMICOS.......................................................................441 FIGURA 8.23.- DIAGRAMA DE INTERACCIN DE RPC................................................................................443 FIGURA 8.24.- MODO DE OPERACIN ASIMTRICO....................................................................................444 FIGURA 8.25.- MODO DE OPERACIN SNCRONO. ......................................................................................444 FIGURA 8.26.- LA PROGRAMACIN MEDIANTE EL SISTEMA RPC DE SUN..................................................446 FIGURA 8.27.- MODELO CLIENTE-SERVIDOR CON OBJETOS DISTRIBUIDOS (I). ..........................................447 FIGURA 8.28.- MODELO CLIENTE-SERVIDOR CON OBJETOS DISTRIBUIDOS (II). .........................................448 FIGURA 8.29.- PROCESAMIENTO DE UNA LLAMADA A UN MTODO REMOTO. ............................................449 FIGURA 8.30.- MECANISMO DE COMUNICACIN ENTRE EL STUB Y SKELETON...........................................450 FIGURA 8.31.- PROTOCOLO IIOP (INTERNET INTER-ORB PROTOCOL). ....................................................454
- xv -
FIGURA 8.32.- INTEROPERABILIDAD CLIENTE-SERVIDOR VA IDL Y ORB. ...............................................455 FIGURA 8.33.- COMPONENTES DEL MODELO DE REFERENCIA OMA..........................................................456 FIGURA 8.34.- COMPONENTES ESPECFICOS DEL MODELO DE REFERENCIA OMA/OMG. ..........................458 FIGURA 8.35.- MODELO OMA/OMG EN NIVELES.....................................................................................460 FIGURA 8.36.- ARQUITECTURA DE CORBA: COMPONENTES BSICOS. ....................................................460 FIGURA 8.37.- DIAGRAMA DE INTERACCIN Y RUTA DE INVOCACIN DE OBJETOS. ..................................463 FIGURA 8.38.- ARQUITECTURA DE CORBA: COMPONENTES....................................................................464 FIGURA 8.39.- ARQUITECTURA DE ESTNDARES PARA LOS SERVICIOS WEB DISTRIBUIDOS. .....................469 FIGURA 8.40.- ESCENARIO DE LOS ESTNDARES PARA SERVICIOS WEB DISTRIBUIDOS. ............................474 FIGURA 8.41.- GENERALIDADES DE LOS AGENTES MVILES. ....................................................................476 FIGURA 8.42.- AGENTES: PROCEDENCIA...................................................................................................477 FIGURA 8.43.- AGENTES: HISTORIA. .........................................................................................................478 FIGURA 8.44.- LO IDEAL: UN AGENTE MVIL, INTELIGENTE Y SEGURO. ...................................................481 FIGURA 8.45.- UN AGENTE MVIL VIAJANDO POR LA RED.........................................................................482 FIGURA 8.46.- EL MENSAJE TRANSPORTADO POR UN AGENTE MVIL........................................................484 FIGURA 8.47.- LA TRANSFERENCIA DEL CDIGO DE LA CLASE DE UN AGENTE. .........................................485 FIGURA 8.48.- TRANSFERENCIA DE UN AGENTE MVIL. ............................................................................486 FIGURA 8.49.- UN EJEMPLO DE UN SISTEMA DE AGENTES EN UNA MQUINA.............................................488 FIGURA 8.50.- UN EJEMPLO DE DOS SA EN UNA MISMA MQUINA. ...........................................................490 FIGURA 8.51.- EJEMPLO DE INTERCONEXIN DE LOS SA DE DOS MQUINAS. ...........................................490 FIGURA 8.52.- EJEMPLO DE REGIN. .........................................................................................................491 FIGURA 8.53.- EJEMPLO DE INTERCONEXIN ENTRE DOS REGIONES..........................................................492 FIGURA 8.54.- EJEMPLO DE CMO UN AGENTE SOLICITA INTERACTUAR CON OTRO. .................................492 FIGURA 8.55.- PASO SNCRONO DE MENSAJES. ..........................................................................................495 FIGURA 8.56.- PASO ASNCRONO DE MENSAJES BASADO EN DOS ENVOS. .................................................495 FIGURA 8.57.- PASO ASNCRONO DE MENSAJES BASADO EN DOS ENVOS. .................................................496 FIGURA 8.58.- LOS AGENTES MVILES EN LA ARQUITECTURA OMA/OMG..............................................505 FIGURA 8.59.- INTEROPERABILIDAD VA MASIF ENTRE SISTEMAS DE AGENTES MVILES. ......................506
- xvi -

INTERNETy TCPIPdiciembre 2003

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

INTERNETy TCPIPdiciembre 2003

Uploaded by

Copyright:

Available Formats

Captulo 1.

Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

... ... ...

... ... ...

Figura 1.2.- Una hipottica red Internet.

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Estratificacin en niveles de comunicaciones

INTERFAZ DE RED HARDWARE

Figura 1.3.- La arquitectura estructurada de comunicaciones TCP/IP.

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Nivel n ... Nivel 1

Nivel n ... Nivel 1

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Nivel n+1 Nivel n Nivel n-1 Nivel n-2 Hardware

Nivel n+1 Nivel n Nivel n-1 Nivel n-2 Hardware

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

DATOS DATOS DATOS DATOS DATOS

Nivel n+1 Nivel n Nivel n-1 Nivel n-2 Hardware

DATOS DATOS DATOS DATOS

Nivel n+1 Nivel n Nivel n-1 Nivel n-2 Hardware

Modelo de referencia OSI

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

... ... ... ... ...

... ... ... ... ...

... ... ...

... ... ...

Figura 1.7.- Una hipottica red OSI.

1.3.1 Niveles de comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

1.3.2 Puntos de acceso al servicio

En un documento para el programador.

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Sistema B PDU N+1

Confirmacin SAP N SAP origen

Identificada previamente en la configuracin local OSI.

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Sistema B PDU N+1

Nivel N+1 Indicacin de Servicio N

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Si existen (no es obligatorio).

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Medio Fsico de Interconexin N N

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Medio Fsico de Interconexin N N

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

el N) (Protocolo del niv

Figura 1.14.- Servicio del nivel N no orientado a conexin con confirmacin.

1.3.4 Protocolos e interfaces

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

PROTOCOLO Interfaz Interfaz

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 1. Arquitecturas Estructuradas de Comunicaciones

Captulo 2. Modelo en Internet

Research and Development.

Captulo 2. Modelo en Internet

Que son la base de la actual Internet.