Sunteți pe pagina 1din 60
Curso de Adaptación al Grado ESCUELA DE INGENIERÍAS INDUSTRIAL E INFORMÁTICA Telecomunicaciones en la Industria

Curso de Adaptación al Grado

ESCUELA DE INGENIERÍAS INDUSTRIAL E INFORMÁTICA

Telecomunicaciones en la Industria

Arquitectura de redes TCP/IP

Contenido

TEMA 1 LA ARQUITECTURA TCP/IP

3

1.1.

ARQUITECTURA TCP/IP

3

1.2

¿QUÉ SON LOS PROTOCOLOS?

5

1.3.

HOSTS, NODOS,

7

1.4.

LOS ESTÁNDARES EN INTERNET

9

1.5.

SERVICIOS ORIENTADOS A CONEXIÓN Y SIN CONEXIÓN

10

1.6.

CONMUTACIÓN DE PAQUETES

12

1.7.

INTRODUCCIÓN A LAS CAPAS TCP/IP

12

1.8.

TOPOLOGÍA DE INTERNET

19

1.9.

LA CAPA DE APLICACIÓN

22

 

Servicios proporcionados por los protocolos de transporte en

Internet

26

1.10.

LA

CAPA DE TRANSPORTE

26

 

Multiplexación y demultiplexación de aplicaciones

27

Protocolos TCP y UDP

29

1.11.

LA CAPA DE RED

32

 

Funciones de la capa de red

32

El protocolo por excelencia: IP

33

Subnetting

46

1.12.

LA CAPA DE ENLACE

48

Servicios proporcionados por la capa de enlace

48

Protocolos de la capa de enlace

50

Protocolos de acceso múltiple y LANs

51

ARP

52

Direcciones Físicas

53

Tema 1 La arquitectura tcp/ip

1.1. Arquitectura TCP/IP

Internet es una red de dispositivos de ámbito mundial que utiliza para comunicarse la pila de protocolos TCP/IP. Por eso este curso está centrado en estos protocolos, porque son los más extendidos con mucha diferencia, los conceptos son los mismos que si se ven en otros protocolos, además tenemos la posibilidad de ver la aplicación práctica de forma más fácil y hay un gran número de herramientas disponibles.

El primer concepto que se debe aclarar es el de “pila de protocolos TCP/IP”, también llamada “capas TCP/IP”, “arquitectura TCP/IP”, etc. Para hacer esta aclaración, debemos pensar en cómo es posible conseguir que dos programas residentes en dos ordenadores separados físicamente por muchos kilómetros puedan llegar a comunicarse y transmitirse datos.

Para conseguir esta comunicación, podemos pensar en todo lo que hace falta para transmitir esos datos a través de la distancia que separa a los ordenadores:

Primero, necesitamos un lenguaje que los dos programas que se van a comunicar entiendan, para poder crear peticiones y que la otra parte sepa qué se está pidiendo.

Como los datos que se transmitirán serán a veces muy grandes, tendrá que haber un mecanismo para poder dividirlo en partes, numerando cada parte para que, cuando llegue a su destino, se pueda recomponer el mensaje original.

Tendrá que haber una forma de identificar para qué programa, de todos los que estén funcionando en el ordenador destino de los datos, es ese mensaje.

Tendrá que haber una forma de identificar el ordenador destino del mensaje, de entre los cientos de millones de ordenadores que hay conectados en Internet a cada momento.

También se necesitará una infraestructura para dirigir esos datos a través de cables y nodos intermedios (routers) desde el origen hasta su destino. Esta infraestructura deberá incluir una forma de elegir los mejores caminos para que el mensaje llegue con más rapidez y fiabilidad.

Se necesitará también una forma de transformar los ceros y unos que componen el mensaje en señales eléctricas para su transmisión por los diferentes medios (por cable telefónico, por fibra óptica, por el aire, etc).

Y se necesitarán muchas otras cosas más de las que nos ocuparemos posteriormente.

Para poder estudiar todas estas funcionalidades necesarias para transmitir un mensaje, lo mejor es aislarlas, de forma que sean independientes, y tratarlas de forma individual. Así, el estudiar cómo debe ser el lenguaje mediante el cual se comunican dos programas en dos ordenadores (la primera funcionalidad que mencionamos) es independiente de las otras funcionalidades, es decir, no tiene nada que ver con la forma en la que los ceros y unos del mensaje se transformará en señales físicas para transmitirlas. De hecho, los aspectos relacionados con el lenguaje con el que se comunicarán los programas es una funcionalidad de mucho más alto nivel que la transformación a señales físicas.

Con todas estas consideraciones, se decidió aislar las funcionalidades y organizarlas en una estructura de niveles o capas, colocando las funcionalidades de más alto nivel arriba y las de más bajo nivel abajo. De esta forma surge la estructura de capas o arquitectura TCP/IP, que puede verse en la figura:

Aplicación

Transporte

Red

Enlace

Física

Fig 1.1 Capas de la arquitectura o modelo TCP/IP

La capa de aplicación recoge las funcionalidades de más alto nivel, es decir, aquellas necesarias para que los programas remotos “se entiendan”, mientras que la física recoge las funcionalidades de más bajo nivel, es decir, la transformación de ceros y unos en señales eléctricas, lumínicas, electromagnéticas, etc. De esta forma, un mensaje se generará en la capa de aplicación, codificado con el mencionado lenguaje que ambos programas conocen. Una vez el mensaje está codificado en este lenguaje, estos datos se pasarán a la capa de transporte para que las funcionalidades descritas en esta capa puedan aplicarse. Los datos seguirán así su recorrido hacia abajo y las funcionalidades de cada capa se irán aplicando hasta llegar a la capa física, donde los datos se convertirán en señales físicas y saldrán al medio físico para ir hacia su destino.

Como puede intuirse, las funcionalidades de la capa de aplicación se implementan en los programas o aplicaciones que se comunican, las capas por debajo se implementan en el sistema operativo de la máquina en la que está el programa. A partir de la capa de enlace, ciertas funcionalidades empiezan a implementarse por medio de hardware en vez de software, hasta que, en la parte más baja de la capa física, todas las funcionalidades son implementadas con hardware (señales físicas).

1.2 ¿Qué son los protocolos?

Para que los ordenadores puedan intercambiar información necesitan una red de comunicaciones. Los programas de los ordenadores que necesitan utilizar la red para comunicarse se denominan aplicaciones de red, como son el correo electrónico, la Web, la mensajería instántanea (Messenger), etc. Estas aplicaciones de red se comunicarán por medio de mensajes especificados en un lenguaje común, como hemos dicho. Algunos ejemplos de mensajes serían:

“Dame la página web www.google.com“La página web solicitada no se encuentra” “El mensaje que me has enviado me ha llegado con errores, envíalo de nuevo”

Por supuesto, los mensajes no consisten en frases de lenguaje natural como en estos ejemplos, sino que consisten en códigos especiales que representan a lo que se quiere transmitir en ellos.

Para que la comunicación sea efectiva tanto los equipos que comunican como los elementos intermedios deben utilizar la misma forma de tratar, enviar, recibir, codificar los mensajes. Todo eso es lo que se define en los protocolos. Por ejemplo, TCP (Transport Control Protocol) es un protocolo que sólo existe en los host 1 y controla los mensajes intercambiados a nivel de capa de transporte transporte. Este protocolo se encarga de que los mensajes lleguen a la aplicación de red destino, de que lleguen en el orden correspondiente, de trocearlos si son grandes y recomponerlos a la llegada, etc. TCP sólo existe en los hosts porque a los nodos intermedios (los routers por los que pasa el mensaje) no les interesa el contenido de estos mensajes. Ejemplos de mensajes especificados en el protocolo TCP serían:

1 Por host se entiende cualquier dispositivo final que conectemos a la red de comunicaciones, por ejemplo un ordenador, una impresora, un móvil, un frigorífico (hay frigoríficos en el mercado que hacen de forma automática la compra a través de Internet según se van terminando los alimentos).

“Me falta un trozo del mensaje ID 455” “Quiero establecer una comunicación con la aplicación 44332 en este ordenador” “El mensaje ID 654 ha llegado con error, retransmitirlo de nuevo”

Como vemos, estos mensajes se intercambian entre el host origen y el host destino, mientras que para los nodos intermedios no tienen relevancia ni necesitan conocerlos.

IP (Internet Protocol) es un protocolo que existe tanto en los host como en los nodos intermedios (routers), y que controla el camino que siguen los mensajes desde el origen hasta el destino. Este protocolo pertenece a la capa de red. Ejemplos de mensajes especificados en el protocolo IP serían:

“La ruta „tal‟ está sobrecargada, no enviar mensajes a través de ella” “Para que este mensaje llegue a su destino debe salir por esta interfaz”

HTTP (Hypertext Transport Protocol) es un ejemplo de protocolo de más alto nivel que TCP, porque HTTP lo que define es el formato de los datos que se intercambian a nivel de capa de aplicación. Ejemplos de mensajes especificados en el protocolo HTTP serían los que vimos al principio precisamente:

“Dame la página www.google.com“La página solicitada no se encuentra” “No tiene permisos para ver esta página”

1.3. Hosts, nodos, enlaces.

Para comunicar los sistemas finales tiene que haber un medio físico que los conecte, p.e. cable coaxial, de cobre, fibra óptica, ondas de radio, etc. Y a este medio físico que conecta dos elementos consecutivos lo llamamos enlace (link). Enlaces diferentes pueden transmitir a velocidades diferentes.

La comunicación entre dos sistemas en Internet no se realiza mediante enlaces dedicados sino que cada unidad de información puede seguir un camino diferente a través de los distintos nodos intermedios, evitando tener que interconectar directamente entre sí todos los hosts. A esta técnica se la llama conmutación de paquetes.

En la siguiente figura puede verse un esquema de funcionamiento de la comunicación entre dos aplicaciones de dos ordenadores a través de Internet:

Aplicación Aplicación Aplicación Nodo intermedio Enlace nodo origen Interfaz de red ó host origen Aplicación
Aplicación
Aplicación
Aplicación
Nodo intermedio
Enlace
nodo origen
Interfaz de red
ó host origen
Aplicación
Aplicación
Aplicación
Aplicación

Nodo destino

ó Host destino

Fig 1.2 Elementos que forman parte de Internet.

Como se ve en la figura, tenemos dos aplicaciones de red que se quieren comunicar a través de Internet. Esas aplicaciones residen en ordenadores que se denominan hosts o nodos (origen y destino). En esos mismos ordenadores se pueden estar ejecutando muchas más aplicaciones, incluso algunas de ellas pueden estar comunicándose también con otras aplicaciones

de red en otros ordenadores. En su camino desde el origen al destino, el mensaje puede circular a través de diversos nodos intermedios (debe tenerse claro que la palabra “nodo” se usa para todos los equipos, sean intermedios, origen o destino, mientras que “host” identifica a los equipos donde residen las aplicaciones que están comunicándose. Los puntos por donde los mensajes abandonan o entran en los nodos se denominan “interfaz de red”, mientras que el medio físico que hay entre dos interfaces se denomina “enlace”. Debe tenerse claro que, a pesar de que en la figura se ha representado el enlace por medio de una línea, no siempre se corresponderá con una conexión de tipo “cable”, sino que ese enlace puede ser el aire (por ejemplo en el caso de una conexión WIFI).

Como puede verse en la figura, cada mensaje puede llegar desde el origen al destino por diferentes caminos. De hecho, dado que un mismo mensaje puede ser dividido en partes, es posible que cada trozo de un mismo mensaje circule por caminos diferentes, llegando incluso en orden diferente al que salieron al origen. De ahí que sea importante un mecanismo para trocear y recomponer el mensaje aunque los trozos lleguen desordenados. Como hemos dicho, de esto se encarga el protocolo TCP, que pertenece a la capa de transporte. Los nodos intermedios (también llamados routers) no necesitan para nada recomponer el mensaje (ya que éste sólo es para que lo lea la aplicación del host destino), por lo que los nodos intermedios no implementan las funcionalidades de la capa de transporte (y tampoco las de la capa de aplicación.

1.4. Los estándares en Internet

Todas las características de construcción y funcionamiento de Internet se definen en los estándares de Internet. Estos estándares son desarrollados por la IETF (Internet Engineering Task Force). Los estándares son recogidos en documentos llamados RFCs (Request For Comments), donde se definen protocolos como TCP, IP, HTTP, etc. Hay más de 2000 RFCs diferentes. Se

pueden consultar en la dirección www.ietf.org. Inicialmente los RFCs eran documentos para intercambiar distintos puntos de vista para solucionar problemas concretos, de ahí su significado de “request for comments”.

Hasta ahora se ha visto lo que es Internet desde el punto de vista del hardware y el software. A continuación veremos un concepto importante: el tipo de servicios que Internet ofrece a las aplicaciones de red. Esto quiere decir que el conjunto de protocolos que hay en la pila TCP/IP puede ofrecer dos tipos principales de servicios, los denominados “orientados a conexión” y los “no orientados a conexión” o “sin conexión”.

1.5. Servicios orientados a conexión y sin conexión

En un servicio orientado a conexión tanto el emisor como el receptor de la información tienen conocimiento de la existencia de esa conexión. Antes de empezar a intercambiar datos, emisor y receptor se ponen en contacto para establecer la conexión, se dice “orientado a conexión” porque en realidad la conexión sólo la conocen el emisor y el receptor pero no es conocida por ningún sistema (nodo) intermedio (routers, etc). Mediante el uso de este tipo de servicio se garantiza, además, que los datos se van a entregar al receptor en el orden correcto y en su totalidad. TCP [descrito en el RFC 793] es el protocolo que ofrece el servicio orientado a conexión en Internet, proporcionando transferencia de datos fiable, posibilidad de tener control de flujo (ponerse de acuerdo emisor y receptor en la velocidad de transmisión de datos) y de congestión (ser capaz de ajustar el flujo de transmisión para no causar congestión en la red).

En cambio, en un servicio no orientado a conexión el emisor envía los datos sin previa comunicación al receptor. Este servicio tiene la ventaja de ser más rápido (menos intercambio de mensajes) y el inconveniente de que no se

sabrá si la información ha llegado o no a su destino. UDP (User Datagram Protocol) [RFC 768] es el protocolo que ofrece el servicio no orientado a conexión en Internet. No existe control de flujo ni de congestión.

El servicio no orientado a conexión se utilizará cuando se prefiera asegurar una cierta velocidad a costa de perder parte de la información, ejemplo de aplicaciones de este tipo son telefonía a través de Internet, video conferencia, aplicaciones multimedia. Por ejemplo, en la transmisión de vídeo, lo importante es que los datos lleguen con la rapidez adecuada para poder seguir las imágenes como si fuese en tiempo real, no importando tanto que se pierda parte de la información. Esta pérdida de información pasará desapercibida o aparecerá como pequeñas interferencias en la imagen (lo mismo ocurrirá con la voz).

Todas aquellas aplicaciones que no pueden permitir pérdida de información usan el servicio orientado a conexión, no nos vale que nos llegue un 95% de un correo electrónico o de una página Web. Una aplicación, cuando va a transmitir un mensaje, tiene la capacidad de elegir si quiere un servicio orientado a conexión o no orientado a conexión. Esta elección, en la práctica, consiste en que se elija el uso del protocolo TCP o del protocolo UDP en la capa de transporte. De hecho, como se verá, en la capa de transporte sólo existen estos dos protocolos y todas las comunicaciones se harán, en cuanto a las funcionalidades implementadas en esta capa, utilizando uno u otro.

El hecho de que un servicio sea orientado o no a conexión solo afecta a los sistemas finales (host origen y host destino), los elementos intermedios son totalmente ignorantes al respecto. Como vimos anteriormente, los elementos intermedios (los nodos intermedios) no implementan la capa de transporte y, por lo tanto, ni siquiera “saben” lo que es el protolo TCP ó UDP.

Hemos hablado del proceso de comunicación entre los hosts, ahora vamos a ver cómo se hacen las cosas en el interior de la red (es decir, a nivel de los nodos intermedios) para llevar la información de un punto a otro

1.6. Conmutación de paquetes

Los protocolos de la capa de aplicación intercambian mensajes. La técnica de conmutación de paquetes consiste en que el emisor divide los mensajes en partes más pequeñas, denominadas genéricamente paquetes. Estos paquetes se transmiten a través de los nodos intermedios hasta llegar a su destino, de forma que cada paquete puede seguir un camino totalmente diferente al que sigue el resto. Los nodos a través de los cuales se transmiten los paquetes se denominan conmutadores de paquetes (packet switches). La conmutación, tal como se trata aquí es un término genérico referido al paso de los paquetes de un nodo a otro. De este modo, los nodos intermedios, o routers, son estos conmutadores de paquetes (packet switches) de los que estamos hablando. (Nota: No debe confundirse el término

“packet switch” con el término “switch” a secas, que es un dispositivo físico diferente que trabaja a nivel de la capa de enlace).

Meciante las técnicas de conmutación de paquetes, los recursos (al hablar de recursos nos referimos a la capacidad del medio físico para transmitir las señales) se utilizan cuando se necesitan, y el ancho de banda total está disponible para cada paquete.

En Internet los paquetes son encaminados de acuerdo con la dirección del host de destino, la conocida “dirección IP”, tal como veremos más adelante. Además, como ya se ha dicho, cada paquete puede ir (en teoría) por un camino diferente al que haya seguido cualquier otro.

1.7. Introducción a las capas TCP/IP

Hasta este momento hemos visto el concepto de capas TCP/IP de forma intuitiva pero no sistemática. En este apartado se presenta una descripción general de cómo se produce la transmisión de datos en este tipo de redes, cubriendo todo el proceso y todas las capas de la pila de protocolos. La siguiente figura muestra las capas TCP/IP que implementa cada uno de los nodos por los que pasará el mensaje (los paquetes). Como se ha dicho, tanto el host origen como el destino implementan las 5 capas de la arquitectura, mientras que los nodos intermedios (los routers) implementan las 3 más bajas (hasta la de red):

Aplicación Aplicación Aplicación Aplicación Transporte Red Enlace Física Red Enlace Red Física Red
Aplicación
Aplicación
Aplicación
Aplicación
Transporte
Red
Enlace
Física
Red
Enlace
Red
Física
Red
Enlace
Enlace
Red
Física
Física
Enlace
Aplicación
Física
Red
Aplicación
Aplicación
Enlace
Física
Aplicación
Aplicación
Transporte
Red
Enlace
Física

Fig. 1.3 Capas del modelo TCP/IP implementadas en cada nodo

Los datos que van a transmitirse se generan, como hemos dicho, en la capa de aplicación. Los datos se generan con el formato adecuado al protocolo establecido para el intercambio de información. Por ejemplo, para transferencia de páginas web entre un servidor web y un navegador, se usa el protocolo HTTP.

Los datos, para llegar a su destino, necesitan usar la red, por lo que se pasan a la capa de transporte (se le pide a la capa de transporte un servicio), donde se les añade información necesaria para el control de la comunicación. Supongamos que la capa de aplicación solicita un servicio orientado a conexión, es decir, quiere, entre otras cosas, que se asegure la llegada de todos los paquetes y en el mismo orden que tenían al principio para recomponer el mensaje. Como sabemos, en la práctica, esto supone utilizar el protocolo TCP a nivel de capa de transporte.

La capa de transporte deberá dividir el mensaje recibido para que se ajuste al tamaño de datos que se usa en esa capa. Como la capa de transporte divide el mensaje en varios trozos y éstos pueden ir por diferentes rutas hacia su destino, será necesario que cada trozo lleve consigo un número de secuencia para que en el destino sea posible recuperar el mensaje original en el orden correcto. Como se puede ver, las capas de transporte del emisor y del receptor son las que tienen conocimiento del significado de ese número de secuencia, mientras que las capas de aplicación tratan con los mensajes completos.

Cuando llegue a su destino, la capa de aplicación del receptor recibe de su capa de transporte el mensaje completo (ya ensamblado) por lo que ésta capa no tiene idea de si alguna vez ese mensaje fue dividido en partes, ni de por qué tipo de redes o a través de cuántos nodos intermedios ha pasado el mensaje. Como se ve, la comunicación se produce entre las capas equivalentes de emisor y receptor, los elementos intermedios no tienen en cuenta ningún tipo de información referente a estas capas.

Una vez que los datos están en la capa de transporte, sólo queda el problema de dirigirlos desde el origen hasta el destino. De esto se encargan la capa inferior, la capa de red.

Para poder dirigir correctamente los datos desde el origen hasta el destino a través de todos los nodos intermedios es necesario:

Que el nodo destino esté identificado de alguna forma.

Que los nodos intermedios sepan dirigir los datos hacia ese nodo destino.

La identificación del nodo destino se realiza mediante el número o dirección IP. El número IP debe ser único para cada nodo conectado a Internet. La información seguirá un camino a través de la red desde su origen hasta el destino. Todos los nodos que toman decisiones sobre el camino que debe seguir la información deben conocer el protocolo de la capa de red. Los nodos encargados del direccionamiento de la información a través de la red, tal como hemos dicho, se llaman routers.

Una vez que se decide el camino a seguir para una unidad de información, es necesario pasar los datos al siguiente elemento dentro del camino elegido. La tarea de transmitir la información entre dos nodos directamente conectados se hace mediante la capa de enlace (la capa de red le pide ese servicio a la de enlace). La capa de red sólo toma la decisión sobre la ruta a seguir (sobre el siguiente elemento que va a recibir los datos) pero no se encarga de la transmisión física de los mismos. Ejemplo de protocolo de la capa de enlace es PPP (Point to Point Protocol), Ethernet, 802.11 (inalámbrico).

Por último, la capa física se encarga de adecuar y transmitir las señales según el medio físico sobre el que se vaya a producir la comunicación. Transforma bit a bit la información a transmitir en señales eléctricas.

La siguiente figura muestra cómo se produce el paso de los datos a transmitir por las capas.

Mensaje a transmitir
Mensaje a transmitir

+5V

Aplicación

Transporte

Red

Enlace

Física

Fig. 1.4. Paso del mensaje por las capas hasta salir a la red.

Cada capa agrega información necesaria para efectuar las funcionalidades que le son propias. La información de cada capa se ha representado por medio de colores. Cada capa sólo es capaz de entender la información correspondiente a su color, de forma que el resto de información no es relevante. Podemos ver la figura también desde abajo hacia arriba, imaginando cómo cada capa “quita” y procesa la información que entiende y cómo luego “pasa” el paquete hacia arriba para que la capa superior siga procesándolo. Al final, la capa de transporte recompone el mensaje original y se lo pasa a la capa de aplicación que es la que, finalmente, procesará el propio mensaje que se intentaba transmitir.

De esta forma, la información va pasando de nodo a nodo. En la siguiente figura podemos ver cómo sería el flujo por las capas de los diferentes dispositivos. Como vemos, los nodos intermedios sólo procesan el mensaje hasta la capa de red, que es donde está la información necesaria para saber por dónde debe seguir el mensaje su camino. La información de las capas superiores (transporte y aplicación) no es relevante en estos nodos intermedios, sólo al final será procesada en su totalidad.

Aplicación Aplicación Aplicación Aplicación Transporte Red Enlace Física Red Enlace Red Física Red
Aplicación
Aplicación
Aplicación
Aplicación
Transporte
Red
Enlace
Física
Red
Enlace
Red
Física
Red
Enlace
Enlace
Red
Física
Física
Enlace
Aplicación
Física
Red
Aplicación
Aplicación
Enlace
Física
Aplicación
Aplicación
Transporte
Red
Enlace
Física

Fig. 1.5. Recorrido de un paquete a través de las capas de los nodos desde su origen hasta su destino.

En resumen, la capa de transporte proporciona una comunicación lógica entre procesos (se encarga de entregar el mensaje completo al proceso o aplicación correspondiente), la capa de red proporciona una comunicación lógica entre hosts (se encarga de que los paquetes lleguen a la interfaz de red del host destino) y la capa de enlace mueve la información de nodo a nodo a través del medio físico que los une (enlace), es decir, se encarga de que el paquete pase de una interfaz de red a la siguiente.

En definitiva, la transmisión de la información a través de la red se realiza por medio de “saltos” de un nodo a otro que están directamente conectados hasta llegar con el último salto, al host de destino.

Si nos fijamos, la gran mayoría del procesamiento de datos en las redes basadas en TCP/IP se realiza en los extremos de la red, de forma que los nodos intermedios son un simple medio de transmisión. Si existe algún error en la transmisión o se pierde algún paquete, sólo será posible detectarlo en los extremos de la comunicación, es decir, en los hosts. Esto no es problema si podemos confiar en que esto va a pasar muy pocas veces, es decir, si

podemos fiarnos de que el medio de transmisión es fiable, cosa que ocurre en el caso de las transmisiones en Internet. En el caso de que el medio de transmisión no fuese fiable y se produjesen errores o pérdidas de paquetes sería mucho más eficiente el detectar esas pérdidas en los nodos intermedios.

Una vez visto el esquema de funcionamiento de Internet, las capas y algunos de los protocolos de la arquitectura TCP/IP, puede surgir la pregunta de cuántos protocolos hay en cada capa, cuales son los más importantes o usados, etc. La siguiente figura recoge algunos de los protocolos que hay en cada capa de la arquitectura TCP/IP.

HTTP DNS POP3 SNMP TFTP SSH SMTP TELNET FTP NFS Aplicación
HTTP
DNS
POP3
SNMP
TFTP
SSH
SMTP
TELNET
FTP
NFS
Aplicación
TCP
TCP
UDP
UDP

Transporte

IP
IP
RIP ICMP ICMP OSPF Red
RIP
ICMP
ICMP
OSPF
Red
Ethernet
Ethernet
802.11
802.11
PPP
PPP

Enlace

Física

Fig. 1.6. Ejemplos de protocolos por capas.

Como puede verse, en la capa de aplicación hay muchos protocolos. De hecho, hay uno (o más de uno) por cada aplicación de red que exista, y habrá que crear nuevos protocolos si se crean nuevas aplicaciones de red. En la figura vemos el protocolo de nivel de aplicación para el servicio Web, que se denomina HTTP (HyperText Transfer Protocol), los protocolos POP (Post Office Protocol) y SMTP (Simple Mail Transfer Protocol) correspondientes al servicio de correo electrónico, el protocolo FTP (File

Transfer Protocol) correspondiente al servicio de transferencia de archivos, el protocolo SNMP (Simple Network Management Protocol) correspondiente al servicio de gestión de red, etc. Cada aplicación que funcione comunicándose en Internet necesita definir un protocolo o conjunto de protocolos a nivel de capa de aplicación, incluyendo los juegos en red como Half Life, Counter Strike, etc.

En la capa de transporte sólo hay dos protocolos: el TCP (Transmission Control Protocol) y el UDP (User Datagram Protocol). El primero ofrece el servicio orientado a conexión del que hemos hablado y el segundo ofrece el servicio no orientado a conexión. TCP es el protocolo más complejo de los dos y el más utilizado para la mayoría de servicios en Internet. De hecho, aparece en el nombre de la arquitectura: TCP/IP.

En la capa de red hay también un protocolo por excelencia: El protocolo IP (Internet Protocol) que, junto con el TCP, dan el nombre a la arquitectura TCP/IP. En esta capa hay también otros protocolos como el ICMP (Internet Control Messaging Protocol) que se utiliza para la transmisión de mensajes de control y error entre nodos, o el RIP (Routing Information Protocol) y el OSPF (Open Shortest Path First) que se utilizan para que los nodos intermedios (routers) intercambien información sobre las mejores rutas para que los paquetes lleguen a su destino.

1.8. Topología de Internet

Hasta ahora hemos visto la conceptualización del funcionamiento de Internet, pero no hemos dicho nada sobre la forma en que se implementa esta red en la práctica, es decir, la topología de Internet. Por lo visto hasta ahora, se podría pensar que Internet está perfectamente estructurada, ya que existe un conjunto de protocolos que permiten a todos los elementos de la red comunicarse y, según las figuras presentadas, hay numerosos caminos que un paquete puede seguir para llegar del origen al destino. Sin

embargo, desde el punto de vista de la topología, Internet parece crecer de una manera caótica, con la aparición de nuevas ramas por todas partes y en todo instante y, además, los paquetes no tienen la libertad de circular por cualquier enlace de forma totalmente libre.

Básicamente, se puede distinguir entre usuarios finales y proveedores de servicios de Internet (ISP). Los ISP son las empresas que proporcionan el acceso a Internet por parte de los usuarios finales.

Los ISP se organizan de forma jerárquica, dependiendo de su importancia (zona geográfica a la que dan servicio). Así puede haber:

ISPs locales.

ISPs regionales.

ISPs nacionales.

ISPs internacionales.

Punto de conexión entre ISP local un ISP local y uno regional ISP regional ISP
Punto de conexión entre
ISP local
un ISP local y uno regional
ISP regional
ISP nacional/internacional
Acuerdo de
tránsito
Punto neutro
(acuerdo de peering )
ISP nacional/internacional
ISP regional
ISP local
Usuario final

Fig. 1.7. Jerarquía de proveedores de servicios de Internet y sistemas finales

Hay ISP que no tienen red propia (infraestructura física), sólo ofrecen servicios, contratando las líneas a otros ISPs mayores. Otros ISP cuentan con una infraestructura de red muy limitada, a nivel local o regional. En un

nivel superior se encuentran los ISP que tienen infraestructuras de red a nivel nacional o internacional.

Con este modelo, para que un proveedor local pueda ofrecer acceso a Internet a un cliente, deberá contratar el uso de las redes de otros ISP que tengan mayor cobertura que él y que, a su vez, pueden tener contratadas redes a proveedores internacionales. Con esta estructura, las relaciones entre ISP son puramente mercantiles y puede darse el caso de que, para que un cliente de un ISP español se comunique con otro cliente de otro ISP también en España, sea necesario que la comunicación se produzca saliendo al extranjero debido a que en España, estos dos ISP no están conectados en ningún punto.

Para evitar este tráfico internacional innecesario, se crean los denominados puntos neutros de intercambio. Un punto neutro es un lugar físico y un equipamiento específico que permite a varios ISP intercambiar la información entre ellos sin que exista contraprestación económica alguna. Los puntos neutros nacionales restringen el tráfico entre proveedores dentro del mismo país, de forma que el intercambio de la información se produce sin salir al extranjero. En España, existe un único punto neutro nacional, se encuentra en Madrid y está gestionado por la asociación Espanix (www.espanix.net). Al punto neutro se conectan los proveedores nacionales interesados siempre que cumplan una serie de normas (por ejemplo, en el caso de Espanix, el proveedor debe contar con un enlace internacional). En el punto neutro existe un dispositivo que conecta un enlace de cada uno de los proveedores, de forma que se puede producir intercambio de tráfico entre cada cualquier par de ellos. Cada proveedor debe llevar un router propio hasta el lugar donde se encuentra el dispositivo y conectarlo a él mediante un enlace. Aparte de los puntos neutros de nivel nacional, existen otros dedicados a mantener el tráfico de manera local. Así, hay también puntos neutros en Cataluña (Catnix), Pais Vasco (Euskonix) y Galicia (Galnix).

Sin embargo, no basta con que los proveedores se conecten al punto neutro para que se pueda producir el intercambio de datos entre ellos, sino que cada par de proveedores que quieran intercambiar datos a través del punto neutro deben alcanzar un acuerdo mediante el cual se reconocen como “iguales”, ya que el intercambio de datos no supone el pago de ninguna cantidad por parte de ninguno de los dos proveedores. A estos acuerdos se les conoce como acuerdos de peering (de pares o iguales), frente a los acuerdos de tránsito, que son los que se surgieron antes de existir los puntos neutros y que suponen el pago de una cantidad y la existencia de una relación cliente-proveedor.

Los acuerdos de peering entre dos proveedores no tienen porqué llevarse a cabo sólo en los puntos neutros, sino que, de forma privada, dos compañías pueden intercambiar tráfico sin prestación económica en un lugar elegido por ambos de forma privada

En Europa hay varios puntos neutros, que están recogidos en:

Cualquiera puede ser un ISP, hay que tener un router con varios modems (para el caso de acceso telefónico o ADSL) y pagar a un proveedor más grande la red de conexión a Internet.

Una vez vistas algunas generalidades sobre Internet, se pasará a tratar más a fondo cada una de las capas del modelo TCP/IP, comenzando por la superior (aplicación) y yendo hacia abajo.

1.9. La capa de Aplicación

Cuando los dos procesos comunicantes están en la misma máquina, se comunican usando comunicación interprocesos. Cuando los procesos están

en distintas máquinas se comunican intercambiando mensajes a través de la red de comunicaciones. Los protocolos de la capa de aplicación definen el formato y el orden de los mensajes intercambiados entre los procesos, así como las acciones tomadas en la transmisión o recepción de cada mensaje.

El protocolo de la capa de aplicación es sólo una parte de la aplicación de red. Por ejemplo, la web es una aplicación de red que consiste en muchos componentes, incluyendo un estándar que define el formato de los documentos (HTML, HiperText Markup Language), los navegadores web (Netscape Navigator, Micorosoft Internet Explorer, Mozilla Firefox, Opera, etc), los servidores web (Apache, Microsoft Internet Information Server, etc) y el protocolo de la capa de aplicación, que en este caso es el HTTP (definido en el RFC 2616). HTTP define cómo se intercambian mensajes entre el navegador y el servidor web (por ejemplo, HTTP define el código para página no encontrada, que es el famoso 404). Por lo tanto, HTTP es sólo una parte de la aplicación web.

Otro ejemplo puede ser la aplicación de correo electrónico de Internet, que incluye muchos componentes como los servidores de correo que albergan los buzones de los usuarios, programas lectores de correo (Outlook, Messenger, Thunderbird, etc) que permite a los usuarios leer y crear los mensajes, un estándar que define la estructura de un mensaje de correo electrónico y unos protocolos de la capa de aplicación que definen cómo los mensajes se pasan entre los servidores y entre los servidores y los lectores y cómo los contenidos de ciertas partes del correo electrónico (por ejemplo, la cabecera del mensaje) tienen que ser interpretados. El principal protocolo de la capa de aplicación para correo electrónico es SMTP (Simple Mail Transfer Protocol, recogido en el RFC 821). Por lo tanto, SMTP es sólo una pequeña parte de correo electrónico.

En concreto, un protocolo de la capa de aplicación define:

El tipo de mensajes intercambiado (solicitud, respuesta).

La sintaxis de los diferentes tipos de mensajes (campos que puede haber en cada mensaje).

La semántica de los campos, es decir, el significado de la información en cada campo.

Las reglas para determinar cuándo y cómo un proceso envía mensajes y responde a mensajes.

Las acciones a tomar ante la recepción de cada tipo de mensaje.

Algunos de estos protocolos están definidos en RFCs y por lo tanto son de dominio público (HTTP, etc), pero muchos otros protocolos de la capa de aplicación son propietarios y no están disponibles para dominio público, por ejemplo, muchos protocolos para telefonía en Internet. Si nosotros programásemos un nuevo servicio para Internet, podríamos crear un protocolo de nivel de aplicación que no estaría incluido en los RFCs, ya que éstos sólo recogen protocolos correspondientes a servicios universalmente conocidos y por lo tanto estandarizados.

Un protocolo de la capa de aplicación típicamente tiene dos partes: una parte cliente y una servidora, cada uno en un sistema final de los que se comunican. El navegador web implementa la parte cliente de HTTP y el servidor web implementa la parte servidora de HTTP.

En muchas aplicaciones, el host implementa tanto la parte servidora como la cliente, por ejemplo, en una sesión TELNET (un servicio para conectarse remotamente a otro equipo), el cliente será el host que inicie la sesión. Otro ejemplo es el FTP (transferencia de archivos).

Los sockets, entre la capa de aplicación y la de transporte

Como hemos visto, los procesos se comunican a través de la red por medio de mensajes. Un socket es el punto por donde los procesos intercambian estos mensajes. Es como la puerta del proceso a la red, es el punto de

comunicación entre la capa de aplicación y la de transporte. El proceso simplemente deja el mensaje en esta puerta y confía en la infraestructura que hay por debajo para que lo transporte a la puerta del proceso destino, es decir, al socket remoto.

Un socket es la interfaz entre la capa de aplicación y la de transporte, también se dice que es la API (Application Programmer’s Interface). El desarrollador de aplicaciones tiene control sobre la parte del socket de la capa de aplicación, pero tiene poco control sobre la parte del socket correspondiente a la capa de transporte (sólo puede elegir el protocolo de la capa de transporte a usar, es decir, TCP ó UDP, y fijar algún parámetro de dicha capa, como el tamaño máximo del buffer o del mensaje). Identificación de los procesos (IP+puerto)

Para que un proceso en un host pueda enviar un mensaje a otro proceso en otro host, el proceso emisor debe identificar de alguna manera al proceso receptor. Para ello debemos especificar dos cosas:

El identificador del host.

El identificador del proceso concreto que se ejecuta dentro de ese host.

En Internet, la dirección del host se identifica mediante el número IP. Es un número binario de 32 bits que identifica el punto donde el host se une a la red (la interfaz de red). Cada ordenador estará identificado, por tanto, por una dirección IP (en realidad un ordenador puede tener varias interfaces y en ese caso tendría varias direcciones IP, pero no es el caso habitual) mientras que cada router tendrá una dirección IP en cada una de las interfaces que tenga.

Una vez que la información ha llegado al sistema (host) final, se debe identificar al proceso, dentro de los que se ejecutan en ese host, que debe recibir la información. En Internet, el proceso dentro del host se identifica

mediante el número de puerto destino. El número de puerto que identifica a un proceso se asigna libremente, por parte del diseñador de la aplicación. Se han estandarizado ciertos números de puerto fijos para las aplicaciones más usadas en Internet, como el servicio Web (protocolo HTTP, puerto 80), correo electrónico (protocolo SMTP, puerto 25), etc. En el RFC 1700 se puede encontrar la lista de los números de puerto asignados a los protocolos más comunes en Internet (a estos puertos se les llama “puertos bien conocidos ó “Well Known Ports).

Todo socket estará identificado por la dirección IP de la interfaz del host y el número de puerto correspondiente.

Servicios proporcionados por los protocolos de transporte en Internet

Como hemos visto, la aplicación usa el socket como punto de salida y entrada a la red. Por debajo del socket está la capa de transporte, que es la encargada del transporte de la información entre los extremos que se comunican. Al desarrollar una aplicación, debe indicarse a la capa de aplicación qué tipo de “servicio de transporte” se requiere. Como ya vimos, la capa de transporte en Internet tiene dos protocolos dedicados a ofrecer dos tipos de servicio de transporte: TCP (servicio orientado a conexión) y UDP (servicio no orientado a conexión).

1.10.La capa de transporte

Los protocolos de la capa de transporte proporcionan comunicación lógica entre procesos de aplicaciones que se ejecutan en diferentes hosts. Las aplicaciones usan los servicios ofrecidos por esta capa para intercambiarse mensajes sin preocuparse de la infraestructura física que haya por debajo.

Es importante distinguir, una vez más, la diferencia entre el cometido de la capa de transporte y la de red. La capa de red proporciona comunicación

lógica entre host, mientras que la de transporte proporciona comunicación lógica entre procesos de los hosts. La capa de red ofrece el servicio de llevar los datos de un host a otro, pero no se encarga de dar los datos al proceso adecuado. La capa de transporte es la que se encarga de saber para cual de todos los procesos que se está ejecutando en ese host van dirigidos esos datos.

Se puede decir que la capa de transporte extiende el servicio de entrega host a host para que sea servicio de entrega proceso a proceso. A este proceso (codificar adecuadamente cual es el proceso destino del mensaje y entregar el mensaje al proceso adecuado cuando llegue a su destino) se le denomina multiplexación y demultiplexación de aplicaciones. Por lo tanto, la multiplexación y demultiplexación de aplicaciones son servicios que ofrecen todos los protocolos de la capa de transporte (es decir, tanto TCP como UDP).

Multiplexación y demultiplexación de aplicaciones

Demultiplexación es la acción de entregar los datos recibidos de la capa IP al proceso correcto de la capa de aplicación. Se realiza en el host destino del mensaje, evidentemente.

Multiplexación es la acción de añadir las cabeceras correspondientes a los datos entregados por la capa de aplicación de forma que en el otro extremo se puedan demultiplexar correctamente. Esta operación se realiza en el host que origina el mensaje.

En Internet, los protocolos UDP y TCP de la capa de transporte efectúan las labores de Multiplexación y demultiplexación mediante dos campos especiales en las cabeceras:

Número de puerto de origen.

Número de puerto destino.

Cada número de puerto es un entero de 16 bits (los valores posibles van, por tanto, de 0 a 65535). Los números de 0 a 1023 están reservados para los números estándar de puerto de los protocolos más usados (well known ports). Toda aplicación que se ejecute en un host y que use los servicios de red debe tener asignado un número de puerto.

El asignar un puerto a la aplicación tiene un problema asociado: en un determinado momento pueden existir en el mismo equipo varios procesos de la misma aplicación ejecutándose, que utilizarían el mismo número de puerto. Por ejemplo, un servidor web puede iniciar un nuevo proceso por cada petición que reciba y el número de puerto asociado será el 80 (el de HTTP) para todos los procesos. Por esta razón, no basta con un único número de puerto para identificar al proceso. Lo que se hace es usar un segundo número de puerto, en este caso en el host origen.

¿Cómo se crea este segundo número de puerto? Lo vemos con un ejemplo.

Como hemos visto, al host que inicia la comunicación se le suele llamar cliente y al que responde a su petición servidor. Supongamos que un cliente pretende iniciar una sesión telnet en un host determinado. El host cliente enviará en el campo “puerto de destino” el número de puerto asignado al protocolo de la aplicación telnet, o sea, el 23. Como puerto de origen, el host cliente usa un número de puerto que no se esté usando en ese momento en el propio host cliente.

Cuando los datos llegan al servidor telnet, éste usa el número de puerto destino (23) para saber que debe pasarle los datos a la aplicación telnet y usa el número de puerto origen (generado en el cliente) para identificar al proceso específico de esa aplicación. Cuando el servidor manda los datos de vuelta al cliente, invierte el orden de los números de puerto, es decir, como puerto de destino usa el que le indicó el cliente (en el campo puerto de

origen) y como puerto de origen usa el 23 (el que venía en el puerto de

destino desde el cliente). Cuando los datos vuelven al cliente, los datos de los dos números de puerto se usan para pasar la información al proceso de

la aplicación correcto.

¿Cuál es el problema que puede presentarse con este modo de funcionamiento? El problema puede producirse cuando dos clientes eligen el mismo número de puerto origen. La forma en la que el servidor soluciona

este caso es usando el número IP del equipo cliente que genera los datos. En definitiva, una comunicación estará totalmente identificada de cualquier otra por medio de los cuatro números que se han visto:

La dirección IP del host destino.

El puerto del host destino.

La dirección IP del host origen.

El puerto del host origen.

Protocolos TCP y UDP

UDP ofrece el servicio más simple a las aplicaciones de la capa de aplicación, simplemente se encarga de la multiplexación y demultiplexación de los datos

y efectúa una suma de comprobación en los datos (no comprueba si se pierden datos).

TCP, además de los servicios ofrecidos por UDP ofrece:

Control de flujo, es decir, la posibilidad de adecuar la velocidad de transmisión de paquetes para no sobrecargar al receptor.

Control de errores, es decir, verificar que los paquetes no llegan con errores.

Control de la congestión. Detectar que el flujo de transmisión no hace colapsar al canal de transmisión.

Control de secuencia. Hacer que los paquetes puedan ser recompuestos en el mismo orden en que salieron del emisor.

Retransmisión de paquetes perdidos.

Es importante tener siempre en cuenta que el servicio confiable de transporte de datos que ofrece TCP puede ser ofrecido también por las capas de enlace, red o aplicación, no estando limitado a la capa de transporte. Esto quiere decir que, si elegimos UDP como protocolo a nivel transporte, siempre podremos implementar algunas de las funcionalidades que faltan a nivel de programación en la aplicación, por ejemplo.

Como ya se vio anteriormente, la elección de TCP ó UDP dependerá del tipo de aplicación de que estemos hablando. Si queremos asegurar la llegada de todos los datos, en el orden en que salieron, la retransmisión de datos perdidos, etc, deberemos utilizar TCP, mientras que si podemos permitir la pérdida de paquetes en beneficio de la velocidad de transmisión, utilizaremos UDP. La siguiente tabla muestra aplicaciones de red típicas, junto con su protocolo de nivel de aplicación y el de nivel de transporte utilizado.

Aplicación

Protocolo capa aplicación

Protocolo capa transporte

Correo electrónico

SMTP

TCP

Terminal remoto

Telnet

TCP

Servicio Web

HTTP

TCP

Transferencia de archivos

FTP

TCP

Servicio de archivos

NFS

típicamente UDP

Streaming de datos multimedia

propietario

típicamente UDP

Telefonía Internet

propietario

típicamente UDP

Gestión de red

SNMP

típicamente UDP

Enrutamiento

RIP

típicamente UDP

Traducción de nombres

DNS

típicamente UDP

SNMP, el protocolo usado para la gestión de red en Internet usa UDP. Esto es debido a que SNMP se usa para solucionar problemas en la red, y cuando hay problemas en la red, es más fácil usar protocolos sencillos como UDP que no la sobrecarguen más. Por otro lado, los datos intercambiados en el servicio de gestión de red son de pequeño tamaño, al igual que los del servicio de enrutamiento y de traducción de nombres; no mereciendo la pena el complicar los paquetes con mucha más información y hacer el servicio más lento.

Por otro lado, TCP no sirve para comunicaciones multicast (las que se establecen entre varios equipos a la vez) ya que TCP lo que hace es establecer una conexión entre dos equipos. Las aplicaciones multicast se implementan usando UDP.

Esta tabla nos sirve también para aclarar de nuevo un concepto importante:

conviene siempre distinguir lo que es la aplicación de red de lo que es el correspondiente protocolo de nivel de aplicación. La primera y segunda columna de esta tabla sirve para ver esta distinción, aunque en la práctica a veces se habla de “servicio ftp” por ejemplo, utilizando el nombre del protocolo como nombre del servicio.

1.11.La capa de red

La capa de red ofrece sus servicios a la capa de transporte. La capa de aplicación le pide el servicio de transmisión de datos a la de transporte. La capa de transporte se encarga como hemos visto de la multiplexación y demultiplexación de datos, chequeo de errores, control de secuencia, flujo, de pérdida de información, etc, pero no se encarga de dirigir los datos desde su origen hasta su destino; para conseguir esto, hace una petición de servicio a la capa de red.

A diferencia que la capa de transporte, los protocolos de la capa de red involucran a todos los nodos de la red, por esta razón, estos protocolos son los más interesantes de toda la pila de protocolos.

Funciones de la capa de red

Las principales funciones que realiza la capa de red se pueden resumir en:

Determinación del camino. Es el procedimiento mediante el cual la capa de red del router crea la información sobre las posibles rutas que un paquete recibido puede tomar para llegar a su destino. En base a esta información, y dada la dirección IP de destino del paquete recibido, el router decide por cual de sus interfaces debe reenviar este paquete. Los algoritmos que calculan los caminos se denominan algoritmos de encaminamiento o routing.

Switching. Es el hecho de hacer que la señal pase del interfaz de entrada del router a la interfaz de salida adecuada.

Internet surgió como consecuencia de la necesidad de conectar computadores, es decir, dispositivos con capacidad de cálculo. Los diseñadores de Internet decidieron aprovechar esta capacidad de cálculo de los sistemas finales y crear un modelo de servicio de red del tipo “best effort”, tan simple como fuese posible, implementando la funcionalidad adicional (ej. transferencia fiable de datos) en capas superiores de los sistemas finales, con algunas interesantes consecuencias: Este modelo de servicio de la red hizo posible que fuese mucho más fácil interconectar redes que usan diferentes tecnologías de la capa de red (Ethernet, Fibra óptica, etc). Este tipo de servicio implementado en la red hace muy fácil la aparición de nuevas aplicaciones de red, ya que sólo habrá que programar los protocolos de las capas superiores de los sistemas finales.

La capa de red contiene una serie de protocolos y elementos dedicados a la funcionalidad de llevar los paquetes desde la interfaz del host origen hasta la del host destino. En concreto, las siguientes funcionalidades se encuentran en la capa de red.

Especificación del formato de los datos en la capa de red: Protocolo IP

Formas de decidir la ruta para un determinado paquete y formato de mensajes que los routers se intercambian para notificarse cuales son los mejores caminos: Protocolos de routing.

Información sobre los posibles caminos y redes a las que puede acceder cada router: la tabla de rutas.

Notificación de sucesos en el proceso de encaminamiento: Protocolo ICMP.

El protocolo por excelencia: IP

Cuando la capa de red recibe un segmento de la de transporte, encapsula el segmento dentro de un datagrama IP, escribe la dirección del host destino y otros campos en este datagrama y le pide a la capa de enlace que lo transporte al primer router en el camino hacia el host destino.

La dirección IP (IPv4)

Se puede decir que la dirección IP identifica de manera única a un host dentro de la red, pero sabemos que en realidad esto no es del todo cierto, lo que identifica la IP es la interfaz, o el punto de unión entre el host y la red. Puede darse el caso de que un host tenga más de una interfaz, pudiendo por lo tanto el mismo host tener más de una dirección IP. En el caso del router, siempre habrá más de una interfaz (al menos habrá dos), ya que la misión del router es transmitír los datagramas que llegan por un enlace hacia otro.

Las direcciones IP son números binarios de 32 bits (4 bytes) (hay por tanto 2^32 posibles valores) agrupados en grupos de 8 bits. Se suele representar por medio de cuatro números enteros de 0 a 255 separados por puntos, que se corresponden con los grupos de 8 dígitos binarios:

11000000

192

10101000

.

168

00000001

.

1

00000001

.

1

Como las direcciones IP de los nodos de Internet deben ser globalmente únicas, no pueden ser asignadas libremente.

La dirección IP de una interfaz está determinada por la “red” a la que se conecta. Este concepto de red hay que verlo desde el punto de vista del direccionamiento IP.

192.168.3.52 193.146.96.29 192.168.3.101 180.23.5.1 192.168.3.17 193.146.96.102 180.23.5.221 180.23.5.24 Fig. 1.7.
192.168.3.52
193.146.96.29
192.168.3.101
180.23.5.1
192.168.3.17
193.146.96.102
180.23.5.221 180.23.5.24
Fig. 1.7. Tres redes IP unidas por un router.

Los interfaces que pertenecen a la misma red, comparten los primeros bits de sus direcciones. En el ejemplo de la figura, comparten los 24 primeros bits (se dice que estos 24 bits representan a la red), identificando los 8 restantes a la interfaz particular.

Para saber cuántos bits de la dirección IP identifican a la red y cuantos a dispositivos dentro de la misma se utiliza el concepto de máscara de red.

La notación /24 indica el número de bits que, empezando por la izquierda, identifican a la red (en este caso se indica que los 24 primeros bits identifican a la red).

La máscara de subred es un número de 32 bits. Cada bit del número de máscara define si su equivalente en cuanto a posición en la IP corresponde con la parte de red y subred o de host. Cuando el bit de la IP es usado para identificar la subred, en la máscara aparecerá el valor 1 y aparecerá 0 en caso contrario.

En el ejemplo anterior, la máscara de subred sería:

11111111 11111111 11111111 00000000

Que se suele expresar al igual que la dirección IP en formato decimal agrupándola en grupos de 8 bits, en este caso:

255.255.255.0

También se puede expresar de esta manera, máscara 24:

193.146.96.102/24

que indica igualmente que los primeros 24 bits empezando por la izquierda de la dirección IP identifican a la red.

La red como tal tendrá una dirección IP “virtual” (no está asignada a ninguna interfaz), formada por los 24 primeros bits y teniendo los restantes bits el valor cero. En el caso de la siguiente figura, la red se identificará por medio de la siguiente dirección IP: 193.146.96.0/24

192.168.3.52 Red 193.146.96.0/24 193.146.96.29 192.168.3.101 180.23.5.1 192.168.3.17 193.146.96.102 180.23.5.221
192.168.3.52
Red 193.146.96.0/24
193.146.96.29
192.168.3.101
180.23.5.1
192.168.3.17
193.146.96.102
180.23.5.221 180.23.5.24
Fig. 1.8. Red 193.146.96.0/24

Es importante tener claro que la red IP está formada por todas las interfaces que comparten la estructura de dirección IP, incluyendo por tanto la interfaz del router correspondiente a esa red, tal como se ve en la figura.

Existe otra dirección IP especial, la dirección de broadcast o de difusión. Se forma dejando los bits que identifican a la red tal cual y poniendo el resto a uno. En el ejemplo sería:

11000001

10010010

1100000

11111111

193.

146.

96.

255

Un mensaje enviado a la dirección de broadcast será procesado por todos los dispositivos conectados a esa red IP.

En este ejemplo con máscara 24, quedan 8 bits para identificar dispositivos dentro de la red, luego el número máximo de dispositivos que admite esta red es de (2^8)-2=254. Se restan dos porque hay dos direcciones reservadas, que acabamos de ver, la que identifica a la red y la de broadcast que no se pueden asignar a ningún dispositivo.

En el ejemplo, la red tiene dos interfaces correspondientes a dos hosts y una interfaz correspondiente al router. Cualquier otra interfaz que perteneciese a esta red, debería tener una dirección de la forma:

193.146.96.xxx

La figura anterior muestra, en realidad, tres redes conectadas mediante un router. En la siguiente figura se muestra cada una de estas redes:

Red 192.168.3.0/24 192.168.3.52 Red 193.146.96.0/24 193.146.96.29 192.168.3.101 180.23.5.1 192.168.3.17
Red 192.168.3.0/24
192.168.3.52
Red 193.146.96.0/24
193.146.96.29
192.168.3.101
180.23.5.1
192.168.3.17
193.146.96.102
180.23.5.221 180.23.5.24
Red 180.23.5.0/24

Fig. 1.8. Las tres redes IP de la figura con sus direcciones de red.

Direcciones públicas y privadas

El gran aumento del número de ordenadores que se conectan a Internet hizo que se tomaran medidas para que no se agotasen las direcciones IP. Para ello se dividió el espacio de direcciones IP en un grupo mayoritario de “direcciones públicas” y otro bastante pequeño de “direcciones privadas”. Las direcciones públicas se usan para identificar de forma única y global a los hosts conectados a Internet. Las direcciones privadas por el contrario no podrán ser usadas para la identificación global y única de un host en Internet, sino que sólo podrán usarse para equipos que no estén conectados de forma directa a Internet.

Los routers de los ISP no reenvían nunca paquetes que tengan esas direcciones privadas. Las direcciones reservadas como privadas son:

Direcciones de 10.0.0.0 a 10.255.255.255

Direcciones de 172.16.0.0 a 172.31.255.255

Direcciones de 192.168.0.0 a 192.168.255.255

Cuando alguno de estos equipos quiere enviar datos a Internet, debe “tomar prestada” un dirección IP pública, para conseguirla existen diferentes tecnologías como proxy, NAT (network address translation), PAT (port address translation).

Como hemos visto, los ISP (Proveedores de servicios de Internet) son las empresas (Telefónica, ONO, Jazztel, BT, etc.) a las que se asignan las direcciones de Internet en primera instancia. Posteriormente, estos ISP asignan bloques de direcciones de las que poseen a las empresas o particulares que contratan sus servicios.

Las direcciones IP están gestionadas al más alto nivel por el ICANN (The Internet Corporation for Assigned Names and Numbers), quien además tiene el trabajo de asignar los nombres de dominio y los números de puertos usados en los protocolos.

En concreto en Europa es el registro regional RIPE (Reseaux IP Europeans) el encargado de la asignación de IPs (http://www.ripe.net/) por delegación del ICANN. Desde este sitio Web podéis acceder a su base de datos y averiguar a quién pertenece una dirección IP concreta.

Dentro de las empresas, una vez que al administrador de la red se le ha

adjudicado un bloque de direcciones éste puede asignar las direcciones a los equipos de dos formas:

Estáticamente. Se asigna de forma manual una dirección IP (junto con la máscara correspondiente) al equipo de modo que éste no la pierde a no ser que se le cambie la configuración.

Dinámicamente. Al arrancar el equipo obtiene su configuración de red de un Servidor DHCP (Dynamic Host Configuration Protocol RFC 2131- ) de forma que, cada vez que se arranque un equipo, se le asigne una dirección IP de forma automática. La dirección IP asignada al equipo será escogida entre las que estén libres en ese

momento. Esta forma de asignar direcciones IP facilita mucho la configuración de redes en las que hay muchos equipos.

El protocolo IP, además de lo visto, también especifica el formato de los datagramas, así como la forma de fragmentarlos y reensamblarlos, pero no entraremos a explicar estos aspectos.

El protocolo de mensajes de control de Internet (ICMP)

El protocolo ICMP es usado por los host y los routers para intercambiar información sobre la capa de red. Lo más frecuente son los informes sobre errores. Por ejemplo, el mensaje “host de destino inalcanzable” es un mensaje ICMP que un router devuelve cuando no puede encontrar el camino hacia el destino especificado. Otras señales importantes en ICMP son “echo request”, que es una petición para que un equipo conteste con un paquete de datos igual al que se le envía o “echo response” que es precisamente la respuesta a un paquete “echo request”. Estas dos señales se utilizan, por ejemplo, en la implementación del comando ping, utilizado para saber si un equipo está encendido y funcionando.

El encaminamiento en Internet.

La capa de red se encarga de encontrar el camino desde el nodo origen hasta el destino. Desde el primer nodo (el host origen) hasta el último, e incluyendo todos los intermedios, se debe hacer una decisión sobre el camino que un paquete debe seguir para dar el siguiente salto. A este proceso se le denomina encaminamiento o routing.

Todos los nodos tienen información sobre la red en la que están y la forma en la que deben enviar los paquetes para alcanzar cualquier otra red. Esta información se almacena en la denominada “tabla de rutas”.

A modo de ejemplo, la siguiente figura contiene la tabla de rutas del equipo A:

Tabla de rutas equipo A Red destino Próximo Número Interfaz de router de saltos salida
Tabla de rutas equipo A
Red destino
Próximo
Número
Interfaz de
router
de saltos
salida
192.168.3.0/24
---
1
192.168.3.52
193.146.96.0/24
192.168.3.1
2
192.168.3.52
192.168.3.52
180.23.5.0/24
192.168.3.1
2
192.168.3.52
A
193.146.96.29
192.168.3.101
180.23.5.1
192.168.3.17
193.146.96.102
180.23.5.221 180.23.5.24

Fig. 1.9. Tabla de rutas en A

La tabla de rutas del equipo A se leería así:

Primera línea: Si un paquete va dirigido a una interfaz de la red 192.168.3.0/24 no debe enviarse a ningún router, la interfaz destino se puede alcanzar en un solo salto, y el paquete debe salir por la interfaz 192.168.3.52 del equipo.

Segunda línea: Si un paquete va dirigido a una interfaz de la red 193.146.96.0/24 éste debe enviarse al router 192.168.3.1, la interfaz destino se puede alcanzar en dos saltos, y el paquete debe salir por la interfaz 192.168.3.52 del equipo.

Tercera línea: Si un paquete va dirigido a una interfaz de la red 180.23.5.0/24 éste debe enviarse al router 192.168.3.1, la interfaz destino se puede alcanzar en dos saltos, y el paquete debe salir por la interfaz 192.168.3.52 del equipo.

Respecto a esta información se pueden hacer varios comentarios. En primer lugar, vemos que la tabla de rutas nos da información de cómo alcanzar las diferentes redes, que aparecen en la primera columna. En la primera fila se habla de cómo alcanzar interfaces de la propia red donde está el equipo A, por lo tanto, no es necesario que el paquete pase por el router, el destino se puede alcanzar directamente. En la segunda línea vemos que, para alcanzar otra red que no sea la propia, el paquete debe salir hacia el router, que es

identificado mediante la IP de la interfaz que el router tiene en la red donde está el equipo A. En cualquiera de los tres casos, el paquete debe abandonar el equipo por la única interfaz que éste tiene, cosa evidente.

La tabla de rutas del host A podría incluso aparecer más simplificada utilizando la denominada “red por defecto”. La tabla sería esta:

Tabla de rutas equipo A Red destino Próximo Número Interfaz de router de saltos salida
Tabla de rutas equipo A
Red destino
Próximo
Número
Interfaz de
router
de saltos
salida
192.168.3.0 ---
1
192.168.3.52
0.0.0.0/0
192.168.3.1 2
192.168.3.52

Fig. 1.9. Formato alternativo para tabla de rutas en A con ruta por defecto.

En este caso, la primera fila tiene e mismo significado que antes, es decir “las interfaces de la propia red se alcanzan directamente sin necesidad de que el paquete vaya a ningún router”. La segunda línea, se leería en este caso “para cualquier otra red de las no especificadas en la tabla, el paquete debe enviarse al router 192.168.3.1, sacándolo por la interfaz 192.168.3.52”

La tabla de rutas también puede expresarse añadiendo una columna específica para la máscara, sin indicarla en formato “/24” como en los ejemplos anteriores. En este caso, la misma tabla de rutas que acabamos de ver quedaría representada así:

Tabla de rutas equipo A Red destino Máscara Próximo Número Interfaz de router de saltos
Tabla de rutas equipo A
Red destino
Máscara
Próximo
Número
Interfaz de
router
de saltos
salida
192.168.3.0
255.255.255.0 ---
1 192.168.3.52
0.0.0.0
0.0.0.0
192.168.3.1 2
192.168.3.52

Fig. 1.10. Formato alternativo de tabla de rutas en A con columna de máscara.

Por último mencionar que, la dirección del router al que hay que enviar todos los paquetes que no van dirigidos a la propia red se denomina “puerta

de enlace” (192.168.3.1 en el ejemplo anterior) y es un dato obligatorio si queremos que el equipo en cuestión pueda comunicarse con otros fuera de la propia red, incluyendo el resto de Internet.

Prestemos ahora atención a la tabla de rutas del router, que se puede ver en la siguiente figura:

Tabla de rutas del router Red destino Próximo Número Interfaz de router de saltos salida
Tabla de rutas del router
Red destino
Próximo
Número
Interfaz de
router
de saltos
salida
192.168.3.0/24
---
1
192.168.3.1
193.146.96.0/24
---
1
193.146.96.1
192.168.3.52
A
180.23.5.0/24
---
1
180.23.5.1
193.146.96.29
192.168.3.101
180.23.5.1
192.168.3.17
193.146.96.102
180.23.5.221 180.23.5.24

Fig. 1.11. Tabla de rutas en el router.

En este caso, vemos que el router alcanza todas las redes directamente, ya que tiene una interfaz en cada una. La tabla de rutas dice por qué interfaz debe salir un paquete que va dirigido a una determinada red de las que hay en la tabla. Se indica simplemente por qué interfaz debe salir un paquete del router para alcanzar cualquier equipo de las redes existentes.

La dirección del host destino (de su interfaz) está almacenada en el datagrama IP. Para decidir el camino se utiliza la tabla de rutas, comparando esta dirección IP del host de destino con las entradas que hay en la tabla. El proceso de razonamiento que se produce para calcular la ruta es el siguiente. Se hace un AND lógico entre esa IP destino y la máscara de red de la tabla de rutas (expresada en binario, claro está). El resultado se compara con el campo “red destino” y, si coincide, esa entrada de la tabla

de rutas es válida para alcanzar el destino y nos indica la interfaz por la que hay que enviar el mensaje y cuál es el próximo salto (si es que existe).

Veamos algunos ejemplos de encaminamiento partiendo de la siguiente figura:

Tabla de rutas equipo A Red destino Máscara Próximo Número Interfaz de router de saltos
Tabla de rutas equipo A
Red destino
Máscara
Próximo
Número
Interfaz de
router
de saltos
salida
Tabla de rutas del router
192.168.3.0
255.255.255.0
---
1
192.168.3.52
Red destino
Máscara
Próximo
Número
Interfaz de
0.0.0.0
0.0.0.0
192.168.3.1 2
192.168.3.52
router
de saltos
salida
192.168.3.0
255.255.255.0
---
1
192.168.3.1
193.146.96.0
255.255.255.0
---
1
193.146.96.1
192.168.3.52
A
180.23.5.0
255.255.255.0
--- 1
180.23.5.1
193.146.96.29
192.168.3.101
180.23.5.1
B
E
192.168.3.17
193.146.96.102
180.23.5.24
180.23.5.221
Tabla de rutas equipo B
Red destino
Máscara
Próximo
Número
Interfaz de
router
de saltos
salida
192.168.3.0
255.255.255.0
--- 1
192.168.3.17
0.0.0.0
0.0.0.0
192.168.3.1 2
192.168.3.17

Fig. 1.12. Tablas de rutas en equipos A y B y router.

Ejemplo1: Host A envía datos a host B. La IP destino es, por tanto 192.168.3.17. En el host A se hace un AND lógico entre la IP destino (192.168.3.17) y la columna máscara o, lo que es lo mismo, nos quedamos con los 24 primeros bits de la dirección. El resultado se compara con la columna red destinode la fila correspondiente y vemos que coincide para la primera entrada de la tabla de rutas (192.168.3.0). Para alcanzar el destino hay que enviar el mensaje, por tanto, a través de la interfaz 192.168.3.52 de A (en este caso es la única que tiene) y no hay próximo salto, esto significa que el destino está en nuestra propia red, no hay que enviarlo a ningún router. Una vez decidido esto, se pediría a la capa de enlace que efectúe ese salto hasta la interfaz con IP 192.168.3.17 y el paquete llegará a su destino en un solo salto.

Ejemplo2: Host A envía datos a host E. Encaminamiento en A: Se hace un AND lógico entre la IP destino

(193.146.96.102) y la columna máscara, al comparar el resultado con la columna red destino de la fila correspondiente vemos que no coincide con la primera entrada (AND lógico de 193.146.96.102 y 255.255.255.0 = 193.146.96.0 ≠ 192.168.3.0) lo que quiere decir que la interfaz destino no está en nuestra propia red. A continuación vemos que el AND lógico sí coincide para la segunda entrada de la tabla de rutas (AND lógico de 193.146.96.102 y 0.0.0.0 = 0.0.0.0). Por lo tanto, hay que enviar el mensaje a través de la interfaz 192.168.3.52 de A hacia el router

192.168.3.1 (próximo salto). Una vez decidido esto, se pedirá a la capa de

enlace que efectúe ese salto desde la interfaz 192.168.3.52 a la

192.168.3.1, con lo que el paquete llegará al router.

Encaminamiento en el router: Una vez que el paquete llega al router, debe

decidirse de nuevo por qué interfaz debe salir para seguir su camino hacia su destino. El paquete que el router recibe entrando por la interfaz

192.168.3.1 es procesado hasta localizar la IP de destino del mismo, que

seguirá siendo la del equipo C (193.146.96.102). Se hace un AND lógico entre esa IP destino (193.146.96.102) y la columna máscara, al comparar el resultado con la columna red destino de la fila correspondiente vemos que coincide para la segunda entrada de la tabla de rutas. Por lo tanto hay que enviar el mensaje a través de la interfaz 193.146.96.1. Además, podemos comprobar que no hay próximo router, es decir, que el router tiene esa interfaz en la propia red donde está el ordenador destino. La capa de red del router entonces hace la petición a la de enlace para que efectúe ese salto y el paquete alcance finalmente su destino

Hemos visto que la tabla de rutas es un elemento fundamental para decidir el camino que tienen que seguir los mensajes en la red, pero ¿cómo se construye la tabla de rutas en un router? La ruta por defecto la tiene que

configurar el administrador de red. El resto se introducen a partir de los protocolos de routing (RIP, OSPF) que se ejecutan en los routers, mediante los cuales los routers intercambian información sobre las redes que alcanzan y cómo las alcanzan.

Subnetting

Existen diversas razones para que una empresa necesite dividir una red grande en varias redes pequeñas:

Por introducir un nuevo tipo de red física.

Por tener que dividir la red local en dos o más por crecer el número de host demasiado. La separación de la red en varias facilita la administración y mejora la velocidad de transmisión de datos.

Por tener que salvar grandes distancias, teniendo la necesidad de dividir la red en dos uniéndolas mediante routers.

Si tenemos una red grande, por ejemplo 150.221.0.0/16, para evitar tener que pedir direcciones adicionales cuando queramos crear nuevas redes, se introdujo el concepto de subnetting. Mediante esta técnica, algunos bits de la parte correspondiente a la identificación del host en el número IP se usan para distinguir la nueva subred.

En este número de red:

150.

10010110 11011101 00000000 00000000

221.

0.

0

La parte correspondiente a la red es: 10010110 11011101 Mientas que la parte correspondiente a equipos es: 00000000 00000000

Esta red podría tener como hosts equipos con los números desde el:

150.221.0.1

10010110

11011101 00000000 00000001

hasta el:

150.221.255.254

10010110 11011101 11111111 11111110

es decir, 65534 hosts.

Mediante la técnica del subnetting, la empresa podría decidir dividir esta red en varias, usando por ejemplo los dos bits más significativos de la parte correspondiente al host para identificar a la subred. De este modo se tendrían cuatro posibles subredes:

150.221.0.0 10010110 11011101 00 000000 00000000

150.221.64.0 10010110 11011101 01 000000 00000000

150.221.128.0 10010110 11011101 10 000000 00000000

150.221.192.0 10010110 11011101 11 000000 00000000

La máscara de subred para cada una de estas nuevas redes sería la siguiente, expresada en los tres formatos conocidos:

11111111

11111111 11000000 00000000

255.

255.

192.

0

/18

Cada router interno de la empresa debe utilizar esta máscara para decidir el camino por el que mandar los paquetes.

Cada una de estas redes tendría 14 bits para identificar al host, por lo que cada subred podría contar ahora con con:

2^14-2 = 16382

En total (entre las cuatro redes), se direccionarían:

4*16382 = 65528 equipos

Los rangos numéricos para los hosts de cada una de las cuatro redes serían:

Red 1: 150.221.0.1 a 150.221.63.254 Red 2: 150.221.64.1 a 150.221.127.254 Red 3: 150.221.128.1 a 150.221.191.254 Red 4: 150.221.192.1 a 150.221.255.254

La decisión de hacer subnetting la toma el administrador de la red de la empresa y la configuración es válida dentro de la empresa solamente.

1.12.La capa de enlace.

La capa de red proporciona un servicio de comunicación entre dos hosts. Esta comunicación comienza en el host origen, atraviesa una serie de routers y termina en el host destino. Decide en cada nodo el camino que tienen que seguir los mensajes (los paquetes) pero no los mueve, es la capa de enlace la encargada de mover el mensaje entre dos nodos consecutivos a través del medio o enlace que los une (cable coaxial, par trenzado de cobre, fibra óptica, aire, etc).

Servicios proporcionados por la capa de enlace

El protocolo de la capa de enlace define el formato de las unidades de datos intercambiados entre los nodos que se encuentran en los extremos de ese enlace, así como las acciones llevadas a cabo por esos nodos cuando envían y reciben estos datos. A las unidades de datos intercambiadas por las capas de enlace se las denomina frames.

Algunos ejemplos de protocolos de la capa de enlace son: Ethernet, Token Ring, FDDI, PPP, 802.11(inalámbrico).

En su camino desde el host origen al destino, un datagrama puede ser transportado en cada enlace por una tecnología y unos protocolos diferentes, que pueden ofrecer un mayor o menor número de servicios.

Los servicios que puede ofrecer la capa de enlace son:

Empaquetado de los datos en frames y acceso al enlace. Un frame es el datagrama de la capa de red con unas cabeceras añadidas. El acceso al medio tiene sentido cuando el enlace es usado por más equipos que los dos que están comunicándose, ya que, en este caso, las señales físicas de dos o más mensajes pueden interactuar y ser dañadas. En el caso de una conexión punto a punto entre dos equipos, el enlace está dedicado a esos dos equipos y el servicio de acceso al medio carece de uso.

Entrega fiable. Este servicio garantiza que el frame se mueve de un nodo a otro del enlace sin errores. Esto se consigue mediante acuses de recibo (ACK) y retransmisiones. Este servicio sólo es útil en enlaces con alto nivel de error, como los enlaces inalámbricos, donde es preferible corregir el error en el enlace en vez de en los extremos, ya que de otro modo se estarían retransmitiendo muchos frames con errores. Sin embargo, los protocolos más populares de la capa de enlace no proporcionan dicho servicio, ya que los enlaces de fibra óptica, cable coaxial y los actuales cables de cobre. Ethernet, por ejemplo, no proporciona este servicio.

Control del flujo. Los nodos en los extremos del enlace tienen una capacidad limitada de almacenamiento de frames. Esto puede ser un problema si un nodo recibe frames a una velocidad mayor que la que puede procesar durante un periodo de tiempo. Los frames se perderían.

Detección de errores.

Corrección de errores.

Servicio half-duplex y full-duplex. En el modo full-duplex, los dos nodos de los extremos del enlace pueden transmitir frames al mismo tiempo. En el modo half dúplex la comunicación puede ser en ambos sentidos, pero no al mismo tiempo.

Los servicios proporcionados por la capa de enlace son conceptualmente similares a los proporcionados por la capa de transporte. La diferencia es que en el caso de la capa de transporte, estos servicios se proporcionan a los procesos de la capa de aplicación en los extremos de la red, mientras que los servicios de la capa de enlace se proporcionan a los nodos directamente conectados por un enlace.

La mayoría de las funciones que realiza la capa de enlace se implementan en el adaptador de red (denominada tarjeta de red en los ordenadores). Un adaptador es una tarjeta que contiene RAM, chips de proceso de señales, una interfaz que comunica con el medio y un bus que comunica la interfaz con el host. A los adaptadores también se los denomina tarjetas de interfaz de red (NIC).

El adaptador es una unidad semiautónoma, en él se implementan todos los servicios de la capa de enlace. Es el adaptador el que decide si se pasan los frames a la capa de red para su procesamiento, de esta forma, se pueden descartar paquetes que directamente se sabe que no hay que procesar, evitando el pasarlo a capas superiores con el consiguiente gasto de tiempo de procesamiento (de la capa de red hacia arriba todo se hace por software ya). No es una unidad totalmente autónoma ya que comparte la alimentación y algunos buses con el host.

Protocolos de la capa de enlace

Detección de errores. Se usan principalmente tres técnicas de detección de errores:

Control de paridad.

Métodos de suma de comprobación.

Control de redundancia cíclica (CRC).

Protocolos de acceso múltiple y LANs

Hay dos tipos de enlace de red:

Enlaces punto a punto.

Enlaces broadcast.

Un enlace punto a punto tiene un solo emisor y un solo receptor. Ejemplos de protocolos de la capa de enlace para enlaces punto a punto son PPP y HDLC.

Un enlace broadcast puede tener múltiples emisores y receptores, todos conectados al mismo canal compartido (canal broadcast). El término broadcast se usa porque cuando un nodo transmite un frame, el canal difunde el frame a todos y cada uno del resto de los nodos. Ethernet es la tecnología para enlace broadcast más ampliamente usada.

El problema en un enlace broadcast es la coordinación del acceso al medio (también llamado problema de acceso al medio), ya que todos los equipos conectados usan el mismo enlace. Más de dos nodos pueden transmitir frames al mismo tiempo. Cuando esto ocurre, los frames pueden colisionar, por lo que las señales de estos frames se distorsionan y ya no pueden ser entendidas por los receptores. Todos los frames envueltos en la colisión se pierden y la capacidad del canal en ese instante se desaprovecha, necesitándose los consiguientes reenvíos de los mismos datos. Por esta razón, cuando varios nodos van a transmitir a un tiempo, es necesario controlar el momento en que cada uno puede o no transmitir, de esto se encargan los protocolos de acceso múltiple.

Los protocolos de acceso múltiple se pueden clasificar como pertenecientes a una de estas tres categorías:

Protocolos de partición del canal.

Protocolos de acceso aleatorio.

Protocolos de toma de turnos.

Dentro de los protocolos de partición del canal, podemos encontrar TDM (Multiplexación por división en el tiempo), FDM (Multiplexación por división en frecuencia) y CDMA (Multiplexación por división de código). Estos protocolos consisten en repartir el ancho de banda del canal asignando un “trozo” a cada comunicación. No es muy eficiente.

El acceso aleatorio consiste en que un nodo, cuando transmite, lo hace con todo el ancho de banda del canal. Cuando hay una colisión, cada nodo implicado en la colisión retransmite el frame después de un periodo de tiempo aleatorio. Hay muchos protocolos de acceso aleatorio, los más conocidos son ALOHA, CSMA (Carrier Sense Múltiple Access, es el usado en Ethernet), etc. CSMA detecta si hay alguien transmitiendo por el canal antes de empezar una transmisión, minimizando (aunque no eliminando completamente) la posibilidad de colisiones. Cuando el protocolo CSMA incorpora la posibilidad de detectar las colisiones se le denomina CSMA/CD (Collision Detection).

Un ejemplo de protocolo de toma de turno es Token Passing Protocol, usado en Token Ring. Aunque fue bastante utilizado en el pasado, actualmente ha desaparecido en la práctica, por lo que no veremos nada sobre el mismo.

ARP

Como se ha dicho en el apartado dedicado a la capa de red, la capa de

la

enlace

enlace una

siguiente. Para hacer esto, cada interfaz tiene, a nivel de

es

la

que

se encarga de mover

el paquete de una interfaz

a

dirección denominada “dirección física”. Mediante esta dirección, cada interfaz de red es capaz de decidir si un determinado paquete es para ella o no. El frame (que es el nombre que recibe el paquete a nivel de la capa de enlace) debe entonces tener un campo dedicado a introducir la dirección física de la interfaz de destino. Cuando una interfaz detecta que la dirección física de destino coincide con la suya sabe que el frame es para ella y que, a continuación, debe “subir” ese frame hacia la capa de red para que siga siendo. En el caso de que la dirección física de destino no coincida con la dirección física de la interfaz en cuestión, el frame es descartado.

Direcciones Físicas

La dirección física no pertenece al nodo, sino al adaptador. A la dirección física también se la denomina dirección LAN (Local Area Network), dirección Ethernet ó MAC (Media Access Control). Estas direcciones se componen de un número de 6 bytes de longitud, dando 2^48 direcciones físicas posibles. Estos 6 bytes son típicamente expresados en notación hexadecimal y agrupados por pares (por ejemplo 00-11-1D-48-DD-09). Una dirección física es permanente. Cuando se fabrica un adaptador, la dirección LAN se graba en la ROM del adaptador. No hay dos adaptadores que tengan la misma dirección física. Para asegurar esto, la dirección física está formada por una parte (24 bits) correspondiente al código del fabricante y otra al número de la tarjeta de entre las de ese fabricante. El control de estos números lo gestiona el IEEE.

Las direcciones físicas tienen una estructura plana, al contrario que las IP (que tenían una parte de dirección de red y otra de host), por lo que un equipo que se lleve de una red a otra no deberá cambiar el adaptador (al contrario que en el caso de las IP, que debe ser cambiada si se cambia de red al equipo).

Cuando se quiere que un frame sea procesado por todos los nodos conectados al enlace debe enviarse con una dirección física especial denominada dirección broadcast, que es FF-FF-FF-FF-FF-FF. Cuando un nodo detecta un paquete con esta dirección física de destino, lo procesa como si fuese dirigido a él, subiéndolo a las capas superiores del protocolo.

El uso de direcciones físicas complica el proceso de transmisión de datos, introduciendo nueva complejidad, ya que el paquete que viaja por la red lleva asociada la dirección IP de destino, pero no la dirección física que corresponde al adaptador de esa dirección IP de destino. Deberá existir, por tanto, un mecanismo para poder averiguar la dirección física de destino a partir de la IP, tal como se describirá en el siguiente apartado. Pero la pregunta que surge inmediatamente es: ¿Por qué no se usa la dirección IP solamente en vez de la física?

Address Resolution Protocol (ARP)

Debido a la existencia de las direcciones IP y física, existe la necesidad de tener un mecanismo de traducción entre ambas. En Internet, este trabajo lo realiza el protocolo ARP. Cada host y router, en su capa de enlace, debe implementar el protocolo ARP. Para las siguientes explicaciones utilizaremos la siguiente figura, donde aparece la dirección IP y la dirección física para cada interfaz de la red de área local:

192.168.3.52 A 192.168.3.101 192.168.3.17 B Fig. 1.13. Direcciones IP y direcciones físicas en una LAN.
192.168.3.52
A
192.168.3.101
192.168.3.17
B
Fig. 1.13. Direcciones IP y direcciones físicas en una LAN.

Si el nodo de arriba (el A) quiere enviar un paquete al nodo de abajo (el B), tal como vimos en el ejemplo de la capa de red, decidirá, consultando la tabla de rutas, que la interfaz de destino (192.168.3.17) está en su propia red y, por lo tanto, la puede alcanzar directamente sin pasar por ningún router intermedio. En ese momento, la capa de red pide a la de enlace ese servicio. La capa de enlace debe entonces transmitir el frame al nodo de abajo (192.168.3.17), para lo cual necesita saber la dirección física de la interfaz del nodo destino. ¿Cómo determina el nodo de arriba la dirección física del nodo de abajo?

El equipo A (192.168.3.52) le pasa al módulo ARP la dirección IP de destino:

(192.168.3.17) y el módulo ARP devuelve la dirección física de la interfaz de este nodo, entonces, se envía el frame con la dirección física de destino correcta añadida al mismo. Este frame es detectado por todas las interfaces que están conectadas al medio compartido, pero sólo la interfaz cuya dirección física coincida con la dirección física de destino procesará el frame. Pero, ¿cómo funciona ARP?, es decir, ¿cómo se produce esa conversión entre dirección IP y dirección física?

El módulo ARP del nodo tiene en RAM una tabla denominada “tabla arp”. Esta tabla contiene el mapeo de direcciones IP a direcciones físicas:

IP address

LAN address

TTL

192.168.3.101

2E-44-CC-13-89-A5

13:45:00

192.168.3.1

AA-1E-55-B5-31-C5

13:52:00

Fig. 1.14. Tabla ARP

Para cada dirección mapeada, la tabla contiene una entrada de tiempo de vida (TTL), que indica cuándo será borrada la entrada de la tabla. La tabla no contiene necesariamente una entrada para cada nodo de la LAN. Algunos nodos pueden haber tenido entradas que hayan caducado, otros puede que nunca hayan sido introducidos, lo que quiere decir que la tabla se crea y cambia dinámicamente.

Supongamos, como en el ejemplo, que el nodo 192.168.4.57 quiere enviar un datagrama a otro nodo de la LAN. Si en la tabla ARP de este nodo origen existe una entrada para el nodo destino, se coge el valor correspondiente a esa dirección física y se introduce en el frame y se envía. Si no existe la entrada para el nodo destino, el nodo construye un paquete especial ARP que incluye la IP y la dirección física del nodo emisor, así como la IP del nodo destino. Este paquete se envía con la dirección física de destino de broadcast (FF-FF-FF-FF-FF-FF), de forma que todos los nodos lo procesen. Cuando un nodo recibe este frame, compara su IP con la IP destino que viene en el frame, no realizando ninguna acción si estos dos valores no coinciden; de esta forma, sólo el nodo que tenga la IP que viene en el frame contestará al emisor con un frame ARP con un formato parecido en el que incluye su propia dirección física. De este modo, el nodo emisor ya conoce la dirección física del nodo destino y puede enviar los datos. Además, el nodo emisor introduce en la tabla ARP el dato que ha conseguido de forma que si hay envíos al mismo destino ya no tendrá que realizar todo el proceso de nuevo. La tabla siguiente sería la resultante de haber resuelto mediante ARP la dirección física del equipo B:

IP address

LAN address

TTL

192.168.3.101

2E-44-CC-13-89-A5

13:45:00

192.168.3.1

AA-1E-55-B5-31-C5

13:52:00

192.168.3.17

CC-DD-11-50-7A-32

14:00:25

Fig. 1.15. Tabla ARP con nueva entrada aprendida.

Hay un par de cosas interesantes a destacar:

El mensaje de consulta de ARP se envía en un frame broadcast, mientras que el de respuesta es un frame unicast (va dirigido al emisor).

El protocolo ARP funciona de forma automática, no necesitando ser configurado por el administrador.

En este ejemplo, se ha enviado un datagrama a otro equipo de la misma LAN donde está el emisor. El datagrama llevaba una dirección IP de destino. El nodo emisor detectó que esa IP correspondía a un equipo que se encontraba en su misma red (consultando la tabla de rutas) y que por lo tanto podía ser alcanzado directamente a través del medio compartido, sin enviar el datagrama a ningún router intermedio. Por lo tanto, al poder alcanzar el equipo destino directamente, el nodo emisor debe usar la dirección física del nodo destino y enviar el paquete, para esto usaba ARP.

Ahora, supongamos que queremos enviar un datagrama a un nodo fuera de la LAN. Utilizaremos la siguiente imagen para discutir el proceso:

193.146.96.2 193.146.96.3 1E-44-5F-D1-22-70 AA-BB-C2-48 -3E-11 216.239.35.100 Internet 2A-5C-6F-77-15-CC
193.146.96.2
193.146.96.3
1E-44-5F-D1-22-70
AA-BB-C2-48 -3E-11
216.239.35.100
Internet
2A-5C-6F-77-15-CC
192.168.3.52
A
192.168.3.101
192.168.3.17

Fig. 1.16. Ruta de un mensaje desde una LAN hasta www.google.com

Por ejemplo, supongamos que desde el equipo A (192.168.3.52) se ejecuta un comando ping a www.google.com (216.239.35.100). Veamos el proceso completo de esta comunicación.

El equipo emisor, consultando su tabla de rutas, detecta, comparando la dirección IP de destino con las de la tabla, que este destino no está en su propia red, por lo que debe mandar el datagrama al router de salida (a su “puerta de enlace”). En la tabla de rutas, averigua la dirección IP de la interfaz del router de salida: 192.168.3.1. Por lo tanto, el equipo emisor debe enviar el datagrama a 192.168.3.1. Esta interfaz sí pertenece a la LAN donde está el equipo A, por lo que el equipo puede enviar el frame de forma directa, de lo que se encarga la capa de enlace de A. Para hacer esto, necesita averiguar la dirección física para el interfaz 192.168.3.1. Se resuelve entonces la dirección física mediante ARP y se envía el frame a la dirección física AA-1E-55-B5-31-C5. Es importante tener claro que dentro del frame, el datagrama sigue llevando la dirección IP del destino (la de www.google.com, 216.239.35.100) y que la dirección 192.168.3.1 sólo la usa el equipo emisor para preguntar la dirección física la interfaz de red del router de salida de la LAN.

Una vez que el frame llega a la interfaz 192.168.3.1 del router, éste extrae

el datagrama, pasándolo a la capa IP, aquí es donde el router utiliza su tabla de rutas para detectar cual es el siguiente router en el camino. Para hacer esto, utiliza la dirección IP de destino que va en el datagrama (216.239.35.100). Una vez consultada la tabla de rutas, el router tiene dos informaciones:

La dirección IP de la interfaz del siguiente router al que debe mandar el datagrama. En el ejemplo será 193.146.96.3.

La interfaz del propio router por donde debe mandar este datagrama para alcanzar la interfaz encontrada en el punto anterior. En el ejemplo esta interfaz será 193.146.96.2.

Entonces, el router pasa el datagrama a la capa de enlace de la interfaz encontrada (193.146.96.3). Esta interfaz está directamente conectada a la interfaz correspondiente al siquiente router en el camino. Esta interfaz resuelve mediante ARP la dirección física de la interfaz destino, empaqueta el datagrama en un frame con esta dirección física (AA-BB-C2-48-3E-11) y lo envía. De nuevo, internamente, el datagrama sigue llevando la IP de destino final (216.239.35.100).

Este proceso se repite en todos los routers intermedios hasta que el datagrama llega al último router. El último router tendrá una de sus interfaces conectada directamente al mismo medio que el equipo final (216.239.35.100). Cuando el datagrama llega a este router, al consultar la tabla de rutas, se llega a la conclusión de que el destino se puede alcanzar directamente a través de la LAN a la que está conectada una interfaz del router. Se le pasa el datagrama a esa interfaz (216.239.35.1) y es esa interfaz la que, por medio de ARP resuelve la dirección IP de destino (216.239.35.100) a la correspondiente dirección física (2A-5C-6F-77-15-CC) y envía el frame al equipo final.

El paquete ha llevado siempre la misma dirección IP destino, que ha sido utilizada por los protocolos de la capa de red para decidir el siguiente salto que debe dar ese paquete. Para dar esos saltos, las capas de enlace de cada interfaz por donde el paquete ha ido saliendo, ha tenido que ir resolviendo la dirección IP de la siguiente interfaz a la correspondiente dirección física. Es muy importante tener claro este funcionamiento.