redes 2-5

REDES 2-5

II.4 - Redes TCP/IP

II.4.1 - Arquitectura TCP/IP

La arquitectura TCP/IP es distinta a la arquitectura OSI. Básicamente se diferencian los siguientes niveles:

Modelo TCP/IP
FIGURA II.55 Niveles TCP/IP frente a OSI.
Se denomina subredes a las tecnologías específicas sobre las que se sustenta la interred. (Ethernet...) El servicio que se da a niveles superiores es, por tanto, dependiente de subred.

El nivel de interred suele estar implementado por el protocolo IP. Es, por decisión de diseño, no fiable y no orientado a conexión. Su finalidad esencial es ocultar la heterogeneidad de subredes ofreciendo un servicio independiente de ellas.

En cuanto al nivel de transporte su función es dar un servicio fiable y orientado a conexión. Podemos fijarnos en dos protolos que lo implementan:

TCP: Cumple perfectamente con los requisitos de fiabilidad y de ser orientado a conexión. Su principal inconveniente es su tremenda complejidad.

UDP: A pesar de ser más sencillo que TCP e ir un poco más allá que IP, no es fiable.

Por último, en el nivel de aplicación encontramos aplicaciones tales como FTP, TELNET o WWW.

En cuanto a la nomenclatura en TCP/IP podemos hacer algunos comentarios:

Los sistemas finales se llaman Host.
Se denominan datagramas IP a las PDUs de nivel de interred.
Se denominan segmentos a las PDUs de nivel de transporte.

II.4.2 - Nivel de interred: IP

II.4.2.1 - Servicio

IP ofrece una comunicación extremo a extremo independiente de las redes por las que se pase. Es no orientado a conexión y no fiable, es decir, pueden producirse pérdidas, duplicaciones y desórdenes. Todos estos errores han de ser vigilados y corregidos a nivel superior.

II.4.2.2 - Interredes IP
IP está definido en un documento público denominado RFC 791 ( Request For Comments, son documentos con la misma función que las normas OSI).

El uso de IP hace necesario implantar niveles intermedios entre el propio IP y las subredes sobre las que descansa. Recordemos que IP es único mientras que subredes hay muchas. Por tanto, si sale al mercado una red nueva deberá salir a su vez un nuevo nivel intermedio (SNCDP). De esta forma, instalar una nueva tecnología no obliga al usuario a cambiar los niveles que estén de IP hacia arriba. Estos niveles intermedios que actúan como traductores se denominan protocolos de convergencia.

Veamos dos ejemplos de interredes con IP:

IP sobre Ethernet.

El proceso que se sigue es el siguiente:

Se genera el datagrama IP con su correspondiente cabecera.
Se construye la trama ethernet introduciendo el datagrama IP completo en el campo de datos y rellenando la cabecera como corresponda según el contenido de la dirección destino que vaya en el datagrama IP. (Posteriormente veremos cómo se da este paso)

Gráficamente:

**FIGURA II.56** *IP sobre Ethernet.*

Este caso se simplifica mucho por el hecho de que tanto Ethernet como IP son no orientados a conexión. Por esto, las directivas Data.Request y Data. Indication se traducen rápidamente a sus equivalentes en Ethernet.

IP sobre X.25

El proceso para generar una trama es similar al del caso anterior:

**FIGURA II.57** *IP sobre X.25.*

El cambio más importante viene obligado por ser X.25 orientado a conexión. Supongamos la siguiente situación:

**FIGURA II.58** *IP sobre X.25.*

El proceso para realizar una transmisión desde el equipo conectado a X.25 hasta el conectado al router es el siguiente:

Antes de mandar nada, X.25 exige abrir un circuito virtual con el router (Esto se sabrá a partir de lo indicado en la cabecera IP).
Una vez enviado un datagrama el circuito queda establecido para otros envíos.
Transcurrido un tiempo sin envíos el circuito se libera.

Gráficamente:

**FIGURA II.59** *Transmisión en IP sobre X.25.*

Si es el sistema conectado al router mediante una red Ethernet el que quiere empezar a enviar:

Envía el datagrama IP sobre una trama Ethernet sin preocuparse de nada más.
El router de forma transparente al usuario es quien se encarga de establecer la conexión.

II.4.2.3 - Funciones IP

IP especifíca:

cómo almacenar y reenviar datagramas.(En X.25 no se definía la labor de los equipos, aquí sí).
el plan de numeración.
segmentación y reensamblado: no todas las subredes tienen la misma longitud máxima de paquetes. IP segmenta y reensambla. Esto provoca que IP necesite una mínima información acerca de la subred sobre la que está implementado.
no hay corrección de errores ni control de congestión.

II.4.2.4 - Direcciones IP

En primer lugar hay que señalar que deben ser independientes de la subred. Su longitud es de 32 bits lo que teóricamente permite la utilización de 4.000 millones de direcciones diferentes. Sin embargo, como veremos más adelante, se pierden muchas por la forma de asignar esas direcciones.

Los 32 bits se dividen en dos campos:

FIGURA II.60 Direcciones IP.
El campo subred nombra la subred a la que está conectado el sistema, mientras que el campo sistema identifica el equipo dentro de la subred. Para dar flexibilidad la asignación hay cinco tipos básicos de direcciones en función de la longitud de los campos:

Clase A:

**FIGURA II.61** *Direcciones IP. Tipo A.*

El primer bit, el más significativo, va a cero indicando dirección de tipo A. Esta clase de direcciones permite tener muchos sistemas conectados en una única subred siendo idónea para grandes redes con muchos equipos. No interesa, sin embargo, para pequeñas redes locales con pocos equipos, pues se desperdiciarían multitud de direcciones.

Clase B:

**FIGURA II.62** *Direcciones IP. Tipo B.*

El primer bit ha de ir a ´1´ y el segundo a ´0´.

Clase C:

**FIGURA II.63** *Direcciones IP. Tipo C.*

Los tres bits más significativos deben ser ´110´. Esta clase de direcciones está pensada para subredes pequeñas con pocos equipos.(Hasta 255 direcciones diferentes para una subred)

Clase D: Esta clase está pensada para direcciones de multicast o multidestino. Con una dirección de este tipo se envía un mismo datagrama a un grupo de equipos previamente definidos. De esta forma, nos ahorramos tener que generar un datagrama para cada destinatario con cada dirección unicast o individual si el contenido del datagrama es el mismo para todos. No debemos confundir, sin embargo, multicast con broadcast. Con broadcast un datagrama se enviaría a todos los usuarios y no a un grupo de ellos.

Las direcciones multicast han de comenzar con los bits ´1110´.

Clase E: La clase E está reservada para posibles usos futuros.

Es muy importante saber que una dirección IP no identifica un sistema sino una conexión de un sistema a una subred. Por tanto, un sistema conectado a dos subredes, por ejemplo un router, tendrá dos direcciones.

Evidentemente, una dirección de 32 bits es algo inmanejable para las personas.(Imagínese un teléfono de 32 dígitos) Como primera solución a este problema se utiliza la denominada notación punto. Consiste en traducir, por separado, cada octeto a decimal. Algunos ejemplos son:

Clase A: 10.1.2.3
Clase B: 138.4.3.59
Clase C: 192.16.192.1

Algunos valores especiales son:

Loopback: A uno mismo. Un ejemplo: 127.0.0.0
Subred: Da nombre a toda una subred, pero es un convenio que utilizamos las personas no es una dirección válida. Para enviar un datagrama a todos los sistemas de una subred se emplea la dirección de broadcast que se explica a continuación. Un ejemplo: 138.4.0.0
Broadcast: Un ejemplo: 138.4.255.255. Un mensaje enviado a esta dirección llegaría a todos los sistemas conectados a la subred 138.4.0.0

Pero aún así no es tan cómodo como cabría esperar. Para resolver definitivamente este problema se hace uso de los nombres IP. Consiste en asignar a los sistemas nombres con significado comprensible para el usuario (normalmente, en función de su localización). La traducción se realiza de forma interna y transparente mediante, por ejemplo, la aplicación DNS.(DNS es una aplicación que traduce nombres IP en direcciones IP utilizando una base de datos distribuida)

La asignación se realiza partiendo de un dominio o raíz y añadiendo los subdominios necesarios. Se definieron dos tipos de dominios raíz:

Asignados geográficamente:

.es: España.
.uk: United Kingdom
.it: Italia
...

Asignados por el tipo de organización:

.edu: educación.
.mil: militar.
.org: organismos internacionales.
.com: company.
...

Un ejemplo puede ser:

**FIGURA II.64** *Nombre IP.*

II.4.2.5 - Formato de un datagrama IP

El formato general de un datagrama IP es:

FIGURA II.65 Datagrama IP.
Estudiamos sus campos uno a uno:

Versión: Los protocolos evolucionan y cambian con el tiempo. Por esto, es conveniente saber con qué versión se ha generado un datagrama.
Longitud: Es la longitud de la cabecera medida en palabras de 32 bits. Puesto que este campo tiene 4 bits la longitud máxima de la cabecera es de 64 octetos.
Servicio: Lo rellena quien envía el datagrama. Su utilidad actual es muy escasa, pero irá aumentando en la medida en que se empleen diferentes tipos de tráfico. Su formato es:

**FIGURA II.66** *Campo servicio.*

donde:

PRIO: Se utiliza en casos de congestión.
D: Dar prioridad al retardo.
T: Dar prioridad al throughput.
R: Dar prioridad a la fiabilidad.
C: Dar prioridad al coste.

La norma especifíca que sólo se puede poner a ´1´ uno de los campos D, T, R y C. Con esto, el usuario decide a qué quiere dar prioridad para su mensaje.

Longitud total: Es la longitud total del mensaje en octetos incluída la cabecera. Por ser un campo de 16 bits permite una longitud de hasta 65535 octetos.
Campos de segmentación y reensamblado: Supongamos la siguiente situación:

**FIGURA II.67** *Segmentación y reensamblado.*

Analicemos detenidamente lo que ocurre cuando Host1 envía un datagrama con1400 octetos de datos a Host2. Se genera el datagrama:

**FIGURA II.68** *Segmentación y reensamblado.*

El datagrama se envía y llega hasta el router1. Este advierte que ha de reenviar el datagrama de 1420 octetos por una red en la que el tamaño máximo es de 620 octetos. Por tanto, antes de reenviar, procede a segmentar generando tres datagramas del original que respeten la longitud máxima:

**FIGURA II.69** *Segmentación y reensamblado.*

Los campos de la cabecera que se utilizan son:

Identificador: numero de secuencia. Es el mismo para todos los datagramas generados al segmentar e igual al del datagrama original.
Offset: posición de los datos del datagrama segmentado en el original. (Se cuenta por octetos)
Flags: Son los siguientes:

**FIGURA II.70** *Flags.*

El único que nos va a interesar es MF. Éste se pone a ´0´ si el datagrama es el último fragmento de una segmentación. En caso contrario estará a ´1´

En nuestro ejemplo el router rellena estos campos con los siguientes valores:

**FIGURA II.71** *Segmentación y reensamblado.*

Estos tres datagramas son enviados hasta el Host2 donde se reensambla el datagrama original. ¿Por qué no se reensambla en el router2? Para responder esta pregunta basta con recordar que IP es no orientado a conexión y por ello al Host2 podría llegarse por dos routers diferentes.

Por el hecho de que IP es, además, no fiable al llegar el primer fragmento se disparará un TIMER. Si transcurrido un tiempo no han llegado todos los fragmentos se descartan los que sí lo hayan hecho.

TTL: o Time To Life. Límita el tiempo que un datagrama puede pasar en la red. TTL se decrementa en una unidad cada vez que pasa por un router si todo va bien, o en una unidad por segundo en el router si hay congestión. Al llegar a cero el datagrama es descartado.

Protocolo: Especifica qué protocolo está por encima de IP: TCP, UDP o ICMP que se explicará posteriormente.

Checksum: Es el resultado de aplicar un código de protección de errores a la cabecera con los bits del campo checksum puestos a cero. Normalmente, se suman todos los bits de la cabecera, se complementa la suma a uno y se pone el resultado en checksum. Este campo se modifica en cada router por decrementarse el campo TTL.

Opciones: En este campo se especifican algunas opciones de las que se puede hacer uso. Por ejemplo, una de ellas es la denominada registro de ruta. Si se emplea esta opción todos los routers por los que pase el datagrama copiarían en su campo de opciones su dirección. (Como máximo este campo puede tener 40 octetos, es decir, 10 direcciones.)

II.4.3 - ICMP (Internet Control Messages Protocol)

II.4.3.1 - Introducción

Son un tipo de mensajes que envían los routers, encapsulados en datagramas IP, al originador de algún mensaje conflictivo (porque haya problemas para encaminar un datagrama, congestión en la red, etc.).
Básicamente tiene dos funciones:

Informar sobre errores.
Diagnosticar y obtener información

El esquema general que se sigue a la hora de empaquetar es el siguiente:

**FIGURA II.72** *Esquema general para encapsular mensajes ICMP.*

II.4.3.2 - Tipos de mensajes ICMP

Errores:

El formato común para todos los mensajes de error es el siguiente:

**FIGURA II.73** *Formato general para los mensajes de error.*

Los diferentes tipos de mensajes de error que estudiaremos son los siguientes:

Destination Unreachable (tipo=3): Se envía cuando se descarta un mensaje. El campo de código (code) refina la causa del descarte:

'0' (Network Unreachable): la red dentro de la cual está el destino, se encuentra inalcanzable.
'1' (Host Unreachable): el host destino está inalcanzable.
'2' (Protocol Unreachable): el host destino está bien, pero el campo de protocolo del datagrama no coincide con ninguno de los protocolos del host..

En la parte opcional, se incluye la cabecera IP y los primeros 64 bits (que probablemente tengan la cabecera del nivel de transporte...) del datagrama que se descartó.

Source Quench (tipo=4): Utiliza el mismo formato aunque el código es siempre 0.

Avisa de descarte por congestión.

Time exceeded for datagram (tipo=11): Avisa de un descarte por exceso de tiempo en el sistema.

Usa el mismo formato, con dos códigos posibles:

'0': descarte por TTL=0.
'1': timeout reensamblando (no han llegado todos los trozos al destino en el tiempo esperado).

Diagnóstico:

Los mensajes de diagnóstico que estudiaremos son los de echo request y reply, que responden ambos al mismo formato (los tipos son 8 y 0 respectivamente):

**FIGURA II.74** *Formato de los mensajes de Echo Request y Reply.*

Se utilizan para saber si el destino es accesible (utilidades ping y traceroute por ejemplo).
La idea es que al mandar un Request, se obliga al destino a responder con un Reply. También podemos usar el campo de datos para pruebas más complicadas.

Utilidades:

Ping: Una vez que el destino devuelve el mismo mensaje que se le envió, el origen comprueba el campo de datos recibido con el transmitido y si coinciden es que el destino es perfectamente alcanzable (la opción '-s' dice el tiempo que tarda en ir y volver el datagrama, si bien no escapaz de desglosarlo y decir qué parte corresponde a la ida o a la vuelta).
Traceroute: Nos dice la ruta seguida por los datagramas en una conexión (se observa por otra parte que no es una información demasiado fiable, pues un datagrama por definición no tiene por qué seguir un camino determinado).

Para hacer esto, envía echos con TTL a 1. Esto ocasiona que el primer router envíe un ICMP de descarte por TTL=0, pero además incluirá su dirección IP. Luego se envía otro con TTL=1,2.... hasta que se reciba un reply señal de que el mensaje llegó al destino.

Así, voy recibiendo progresivamente los mensajes de error de todos los routers atravesados a la vez que sus direcciones IP.

NOTA:

Aunque aparentemente estos mensajes de ICMP ofrecen la fiabilidad que antes decíamos que le faltaba a IP, no es así. Si un mensaje ICMP se pierde, no se vuelve a enviar otro mensaje de error. Luego pese a que ofrece más robustez, no podemos asegurar la fiabilidad.

II.4.4 - Encaminamiento IP

Los dos casos que analizaremos se esquematizan en el siguiente dibujo:

FIGURA II.75 Transmisión directa e indirecta.

II.4.4.1 - Transmisión directa

FIGURA II.76 Transmisión directa.
El primer host conoce tanto IP1 como IP2 y las incluye en la cabecera IP del datagrama que envía.
Sin embargo, para encapsular a nivel 2 necesito conocer ET2 (pues ET1 es él mismo y se conoce......). Esto se consigue con un traductor de direcciones, que me dé ET2 desde la IP2 conocida. Concretamente y como veremos luego, el encargado es el protocolo ARP.

II.4.4.2 - Transmisión indirecta

El host origen (que ha puesto como destino IP3) sabe qué equipos hay en su subred y sus direcciones IP (incluido el router).
Por consiguiente sabe que IP3 no pertenece a su subred, por lo que se lo manda al router (con dirección IP3 de destino, pero encapsulado en una trama Ethernet con destino ET2 que obtendré por ARP).
En el router se consultan unas tablas de encaminamiento, que dicen a partir de una dirección IP destino, a qué dirección IP de su subred (recordemos que el router está en varias subredes) hay que enviar.
Esa dirección IP' hará lo mismo, etc., hasta llegar al destino.

**FIGURA II.77** *Tabla de encaminamiento del router 2.*

II.4.4.3 - Tablas de encaminamiento

**FIGURA II.78** *Tablas de encaminamiento.*

El orden de consulta es de lo más específico a lo menos específico (de otra forma podría ir siempre a la dirección por defecto, etc.).

Ejemplo:

**FIGURA II.79** *Ejemplo tabla de encaminamiento.*

Las subredes a las que un nodo está conectado, en general no suelen estar en la tabla, pero para hacer más completo el ejemplo hemos supuesto que no están configuradas.

II.4.4.4 - Resolución de direcciones

Problema:: Dada una dirección IP, obtener la dirección de la subred correspondiente: dir_sub= f (dir_IP).
Soluciones:: Tablas estáticas (una en cada host):; Asociación directa:; Asociación dinámica (protocolos de resolución):

II.4.4.5 Subnetting

**FIGURA II.84** *Ejemplo de subnetting.*

Introducción:
Solución:: La solución es precisamente el subnetting, gracias al cual puedo compartir un prefijo de red entre distintas subredes.
Ejemplo de tabla:
Máscaras:: Me dice cuánto de la dirección que aparece en la tabla es significativo para encaminar (1: significativo 0: no).; La máscara que se usa en la escuela es la siguiente:; Ejemplo:
NOTAS: El resto de la red no tiene por qué enterarse de que yo utilizo subnetting; Actualmente se tiende al Supernetting o CIDR (Classless Interdomain Routing), que sería la interpolación del concepto al resto de Internet.

Hosted by www.Geocities.ws