|
 |
 | |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Departamento de Ingeniería en Sistemas de Información | |||||||||||||||||||||||||||||||||||||||||||||||||||||
TCP/IPArquitecturaLa arquitectura TCP/IP
es distinta a la arquitectura OSI. Básicamente se diferencian los siguientes
niveles: 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 protocolos 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 (Hostales en la última versión traducida del Tanembaum). Se denominan datagramas
IP a las PDU´s de nivel de interred. Se denominan segmentos a
las PDU´s de nivel de transporte. Nivel
de interred: IP.
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. 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. 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:
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: IP sobre X.25.
El cambio más
importante viene obligado por ser X.25 orientado a conexión. Supongamos la
siguiente situación:
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: 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. Funciones IP.
IP específica: 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. 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: 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:
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:
Direcciones IP. Tipo B.
El primer BIT ha de ir a
´1´ y el segundo a ´0´. Clase C:
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. 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 .ar: Argentina Asignados por el tipo de
organización: .edu: educación. .mil: militar. .org: organismos
internacionales. .com: company. 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 dos subredes, por ejemplo un
router, tendrá dos direcciones. Formato de un datagrama IP.
El formato general de un datagrama IP es: 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: 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 específica 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 incluida 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: 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: 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: 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: 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´ 1.
En nuestro ejemplo el router rellena estos campos con los siguientes
valores: 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.Limita 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.) ICMP (Internet Control Messages Protocol).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: Esquema general para
encapsular mensajes ICMP.
Errores:
El formato común
para todos los mensajes de error es el siguiente: Formato general para los
mensajes de error.
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): Formato de los mensajes
de Echo Request y Reply.
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 escapa de desglosarlo y decir qué parte
corresponde a la ida o a la vuelta). Trace Route:
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. Encaminamiento IP.
Los dos casos que analizaremos se esquematizan en el siguiente dibujo:
Transmisión indirecta.
El host origen (que ha
puesto como destino IP3) sabe qué gente 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. Tabla de encaminamiento
del router 2.
Tablas de encaminamiento.
Tablas de
encaminamiento.
Ejemplo tabla de
encaminamiento.
Resolución de direcciones.
Problema: Dada una dirección IP,
obtener la dirección de la subred correspondiente: dirsub= f (dirIP).
Soluciones: Tablas estáticas
(una en cada host): Tablas estáticas.
Si la red tiene muchos
sistemas, la operación se hace muy tediosa. Si cambio un PC, agrego otro nuevo, se estropea alguno, etc., tengo que cambiar todas las tablas. Asociación directa: Problemas: La dirección IP es de
32 bits mientras que la de subred puede ser por ejemplo de 48. No es recomendable
mezclar direcciones de varios niveles, pues si por ejemplo variase mi dirección
física IP, abría que variar la de red y decírselo a todo el mundo. Pese a que la idea
parece buena, a nosotros no nos vale (sin embargo, hay ciertos protocolos que si
lo usan). Asociación dinámica
(protocolos de resolución): ARP (Address Routing Protocol): Sólo es
posible aplicarlo si en la red hay broadcast. ARP.
Para ello construye un
paquete en el que se escribe lo que sabemos y lo que queremos saber y se manda a
FF:FF:FF:FF:FF:FF (dirección broadcast). Así llega a todos. Sin
embargo sólo responde el que reconozca su dirección IP en el target (el resto
lo que hace el apuntar IPA/ETA en su tabla ARP, aunque ya lo tuviera antes). Mensaje de B.
Por último, A guarda
ETB en su memoria. Las tablas no se mantienen perpetuamente porque si por
ejemplo B se estropease, A seguiría mandando sin saber que ya no hay nadie. Lo
que se hace es borrar la entrada pasado un tiempo. Notas: Con el comando 'arp
-a' podemos ver las tablas de nuestro host. Se observa además que si hago
un ping, aparecen nuevas entradas. Este método mantiene
independientes las direcciones IP de direcciones de subred. Se utiliza en FDDI, Token ring/bus,
Ethernet, ATM, ... (todas las que
tienen broadcast). RARP (Reverse Address Routing Protocol): Se usa para esquemas como el de la figura: Escenario RARP.
Problema: El PC no sabe nada de
direcciones. Sabe su dirección
Ethernet que tendrá en su ROM, pero no la dirección IP. Lo que hace es construir
El servidor que sí
tiene una tabla RARP le devuelve Ventajas: Podemos variar la
configuración de una manera muy versátil. Evitamos problemas de
virus. El PC puede
autoconfigurarse. Permite una mejor
administración del sistema. OTROS: DHCP (Dinamic Host
Configuration Protocol). PPP (Point to Point
Protocol) o SLIP (Serial Line IP) que permiten tratar el caso de un
enlace por línea serie, son muy utilizados por los usuarios de un PC doméstico
con acceso a Internet mediante modem y línea telefónica. Subnetting.
Ejemplo de subnetting.
En un esquema como el
presentado, la mayoría del tráfico se generará en local. Para direccionar
pediremos una clase B (138.4.0.0) que da para 64K direcciones, pues una clase C
sólo me da para 255 máquinas que no son muchas. Si asigno ese prefijo a
un segmento, ¿cómo asigno los otros? Convendría además que
el resto de Internet viese mi red con el mismo prefijo (pues podría asignar múltiples
direcciones C, una por segmento, pero además de derrochar direcciones, desde
fuera se vería nuestra red casi como una tela de araña...) Solución: La solución es
precisamente el subnetting, gracias al cual puedo compartir un prefijo de red
entre distintas subredes. Subnetting.
Así puedo asignar un número de subred a cada subred y uno de sistema a
cada sistema y el resto de internet me sigue viendo como 138.4. Ejemplo de tabla: Tabla con subnetting.
Me dice cuánto de la
dirección que aparece en la tabla es significativo para encaminar (1:
significativo 0: no).
255.255.255.0 => si los tres primeros bytes coinciden con los de mi dirección,
uso esta entrada para encaminar ( 138.4.2.1 se encamina con la 1ª entrada). Ejemplo de máscara:
Ejemplo: Con la máscara anterior
y una dirección genérica IP 138.4.0.0, vamos analizar las distintas
direcciones de subredes y sistemas que obtendremos:
La primera subred será
la que tenga por dirección base la misma 138.4.0.0. La segunda subred tendrá
por dirección 138.4.0.64. Detalle para la segunda
subred:
En ella los sistemas irán desde 138.4.0.65 hasta 138.4.0.126 y usaremos 138.4.0.127 para broadcast. Y así sucesivamente hasta acabar la asignación NOTAS El resto de la red no tiene por qué enterarse de que yo utilizo subnetting Actualmente se tiende al Supernetting o CIRD (Classless Interdomain Routing), que sería la interpolación del concepto al resto de Internet. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
