Tamaño de Datagrama, MTU y fragmentación - materia

Teleprocesos y Redes 2
Esquema de Comunicaciones
DIRECCIONES INTERNET
Tipos primarios de direcciones IP:
Para las direcciones los diseñadores de TCP/IP eligen un sistema en el que cada host en la red tiene
asignada una dirección, que es un número entero de 32 bits, llamada dirección IP. Dicha dirección se
utilizará en todas las comunicaciones con dicho host.
Conceptualmente cada dirección es del par {RedID, HostID}, donde RedID identifica una red y HostID
un host dentro de la red.
En la práctica, cada dirección IP debe tener una de las primeras tres formas mostradas a
continuación:
Debido a que las direcciones IP codifican tanto una red y un host en dicha red, no especifican una
computadora individual, sino una conexión a la red. Por lo tanto, un router que conecta cierto número
de redes tiene cierto número de direcciones IP distintas, una para cada conexión de red
Direcciones de red y de difusión
{00…0.00…0}
{RedID.00…0}
{RedID.11…1}
(0.0.0.0) Se refiere al host local. Suele utilizarse en casos en los que el Host se
quiere comunicar a la red, pero aún no sabe su dirección IP. Normalmente las
respuestas ya tendrán la dirección de red especificada, permitiendo que el host
tome nota de ella.
Hace referencia a la red en sí misma y se denomina dirección de red.
Difusión Dirigida: Se utiliza como dirección de difusión y se refiere a todos los host
de esta red. Se denomina dirección de broadcast. Esto permite que un sistema
remoto envíe un solo paquete que será difundido en la red especificada. Posee
como desventaja que se debe conocer el RedID.
1/70
Teleprocesos y Redes 2
{11…1.11…1}
{127.00…0}
Clase
A
B
C
D
E
Difusión limitada. Proporciona una dirección de difusión para la red local. Suele
utilizarse en procedimientos de arranque antes de que el Host conozca su dirección
IP o la dirección de la red.
Loopback o Dirección de Bucle Local: Esta dirección es reservada. Se utiliza para
pruebas y para la comunicación de los procesos internos en la máquina local.
Cuando algún programa utiliza esta dirección como destino, el protocolo regresa los
datos sin generar tráfico en la red.
Rango
1.0.0.0 – 126.0.0.0
128.0.0.0 – 191.255.0.0
192.0.0.0 – 223.155.155.0
224.0.0.0 – 239.255.255.255
240.0.0.0 – 255.255.255.255
N° de Redes
126
16.384
2.097.152
N° de Host
16.777.214
65.534
254
Mascara de Red
255.0.0.0
255.255.0.0
255.255.255.0
Broadcast
x.255.255.255
x.x.255.255
x.x.x.255
ARP (PROTOVOLO DE ASOCIACIÓN DE DIRECCIONES)
ARP permite que un host encuentre la dirección física de otro host dentro de la misma red física con
sólo proporcionar la dirección IP del objetivo.
La idea es que cuando el host A quiere determinar la dirección física asociada a una dirección IP,
transmite por difusión un paquete especial que pide al host que posee esa dirección IP, que responda
con su dirección física.
Memoria Intermedia para asociación de direcciones: Podría parecer extraño que A transmita por
difusión para averiguar la dirección física de B en lugar sólo transmitir por difusión el paquete que
quiere enviar. La razón más importante de esto es que la difusión es demasiado cara para utilizarse
cada vez que una máquina necesita transferir un paquete a otra, debido a que requiere que cada
máquina en la red procese dicho paquete. Para reducir los costos de comunicación, las
computadoras que utilizan ARP, mantienen una memoria intermedia de las asociaciones de dirección
IP con dirección física recientemente adquiridas, para que no tengan que utilizar ARP varias veces.
Siempre que una computadora recibe una respuesta ARP, esta guarda la dirección IP del transmisor,
así como la dirección física correspondiente, en su memoria intermedia para utilizarla en búsquedas
posteriores.
Refinamiento ARP: Una mejora de ARP es que el transmisor incluya, en cada difusión ARP, su IP y
dirección física; los receptores actualizan su información en memoria intermedia antes de procesar el
paquete ARP.
Podría darse el caso en el que la máquina A ya posea una asignación de la maquina B, pero el
hardware de B es reemplazado por algún motivo, haciendo que la dirección de B cambie, pero la
asignación en la memoria temporal de A no, produciendo que A no pueda entregar paquetes a B.
Esto se soluciona haciendo que ARP maneje de forma temporal la tabla de asignaciones, con lo cual
remueve los registros después de un período de tiempo. La marca de tiempo de un registro se
reinicia cada vez que se recibe una difusión ARP que lo contenga.
Proxy ARP: Permite a un router responder peticiones ARP procedentes de una de las redes a la que
está conectado, realizadas a un host que está conectado a otra red. Esto produce que el host emisor
de la petición ARP crea que la dirección física del router es la del host destino. El router se dice que
está actuando como un proxy-agent para el host destino, contestando los paquetes dirigidos a él
desde otros hosts. El Proxy ARP también se denomina promiscuous ARP o ARP hack, debido al otro
uso que se le da: conectar dos redes físicas mediante un router proxy-agent, haciendo “invisible” una
a la otra. Esto permite que ambas redes puedan usar el mismo valor de subred.
2/70
Teleprocesos y Redes 2
Formato de Mensaje ARP
TIPO DE HARDWARE
TIPO DE PROTOCOLO
HLEN
PLEN
OPERACION
SENDER HA
SENDER IP
TARGET HA
TARGET IP
TIPO DE HARDWARE: El tipo de interfaz de hardware para el que el transmisor busca respuesta.
TIPO DE PROTOCOLO: Tipo de protocolo de alto nivel (Por ejemplo IP).
HLEN y PLEN: Permiten que ARP se utilice con redes arbitrarias ya que estas especifican la longitud de
direcciones físicas y la longitud de las direcciones de protocolo de alto nivel.
OPERACIÓN: (1) Solicitud ARP, (2) Respuesta ARP, (3) Solicitud RARP, (4) Respuesta RARP.
SENDER HA: Dirección física del transmisor.
SENDER IP: Dirección IP del transmisor.
TARGET HA: Dirección física del objetivo.
TARGET IP: Dirección IP del objetivo.
Cuando el transmisor realiza una solicitud, proporciona la dirección IP del objetivo (ARP) o la
dirección física (RARP). Antes que la máquina objetivo responda, completa las direcciones faltantes e
intercambia objetivo y transmisor, y cambia la operación de respuesta.
RARP (ARP Inverso)
Una máquina utiliza este protocolo a fin de obtener su dirección IP desde un servidor. RARP es una
adaptación de ARP y utiliza el mismo formato de mensaje.
Al igual que ARP, un mensaje RARP se envía de una máquina a otra, encapsulado en la porción de
datos de una trama de red.
El que envía trasmite por difusión una solicitud RARP especificando su dirección física en el campo
TARGET HA. Todas las máquinas en la red reciben la solicitud, pero sólo las autorizadas para
proporcionar el servicio RARP (servidores RARP) la procesarán y enviarán respuesta.
Servidores RARP Primarios y Secundarios: Bajo circunstancias normales, sólo el servidor primario
responde a una solicitud RARP. Todos los servidores secundarios reciben la solicitud, pero
únicamente registran su tiempo de llegada. Si el servidor primario no está disponible, la máquina
original cronometra el tiempo de respuesta y, si esta no aparece, transmitirá de nuevo la solicitud
por difusión. Cuando un servidor no primario recibe una segunda copia de una solicitud RARP, poco
tiempo después de la primera, éste responde.
Para intentar evitar que todos los servidores secundarios respondan a la vez. Cada servidor
secundario que recibe una solicitud computa un retraso aleatorio y, luego, envía la respuesta.
3/70
Teleprocesos y Redes 2
PROTOCOLO IP
IP realiza la función de ruteo seleccionando la ruta por la que los datos serán enviados.
Se define al servicio como un sistema de entrega de paquetes no orientado a la conexión y con el
mejor esfuerzo. El servicio se conoce como no confiable porque la entrega no esta garantizada. Los
paquetes se pueden perder, duplicar, retrasar o entregar sin orden, pero el servicio no detectara ni
informara al respecto. Se conoce como no orientado a la conexión dado que cada paquete es tratado
de manera independiente. Se dice que trabaja con el mejor esfuerzo dado que se hace un serio
intento por entregar los paquetes (no se descartan porque sí). La no confiabilidad aparece sólo
cuando los recursos están agotados o la red subyacente falla.
Formato del Datagrama IP:
Cabecera, que contiene la información de control del protocolo. A su vez se divide en dos partes, una
fija de 20 octetos (160 bits) existente en todos los datagramas IP y una variable múltiplo de 32 bits
que en los casos más habituales no aparece
Datos, contiene la información transportada por el protocolo IP, habitualmente contendrá
información del nivel de transporte.
El significado de los campos que aparecen en la cabecera del datagrama son:
VERS: Indica la versión del protocolo
LONG: Indica la longitud de la cabecera, medida en palabras de 32 bits.
SERVICIO (TOS): Indica el tipo de servicio solicitado. Indica una serie de parámetros sobre la calidad
de servicio deseada durante el tránsito por una red. Puede representar Prioridad, Retraso,
Performance o Confiabilidad.
LONGITUD TOTAL: Señala la longitud total de todo el datagrama (cabecera y datos) en bytes.
IDENTIFICADOR: Es un identificador único del datagrama, y se utiliza en caso de segmentación para
distinguir los fragmentos de un datagrama.
FLAGS: Se utilizan para labores de fragmentación. Uno de sus bits indica si el datagrama es Divisible o
no, mientras que otro bit indica si es un último fragmento o un fragmento intermedio. La indicación
de que un paquete es indivisible debe ser tenida en cuenta bajo cualquier circunstancia. Si el paquete
necesitara ser fragmentado, no se enviará.
OFFSET: Se utiliza para identificar la posición de un fragmento cuando existe segmentación.
TTL (Time To Live): Indica la validez de un datagrama. El origen indica un valor inicial. Cada vez que
atraviesa un router, este decrementa el valor. Al llegar a 0 la red elimina el datagrama y se envía un
mensaje de error a la fuente.
4/70
Teleprocesos y Redes 2
PROTOCOLO: Especifica que protocolo de alto nivel se utilizó para crear el mensaje que se esta
transportando en el área DATA del datagrama (ej: TCP, UDP, ICMP; etc).
CHECKSUM: Se trata de un código de redundancia de la cabecera utilizado para determinar si se han
producido errores de transmisión o no. El método de cálculo consiste en sumar el complemento a 1
de cada palabra de 16 bits de la cabecera y hacer el complemento a 1 del valor resultante.
DIR. IP ORIGEN: Es la dirección origen del datagrama, identifica al origen de la comunicación.
DIR. IP DESTINO: Es la dirección destino del datagrama, identifica al destino de la comunicación.
OPCIONES: Para utilizar opciones adicionales del protocolo IP. Es de tamaño variable. Las opciones
actualmente definidas:
- Final de Lista de Opciones: Se usa al final de la lista de opciones, si ésta no coincide con el
final de la cabecera IP.
- Ninguna Operación (NOP): Se puede usar para forzar la alineación de las opciones en
palabras de 32 bits.
- Seguridad: Especifica niveles de seguridad que van desde "No Clasificado" hasta "Máximo
Secreto".
- Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR): Esta opción provee el
mecanismo para que el originador de un datagrama pueda indicar el itinerario que ha de
seguir a través de la red y para registrar el camino seguido. Los Datos de Opción consisten en
un puntero y una lista de direcciones IP que se han de alcanzar ("procesar"): El puntero
indica la posición de la siguiente dirección de la ruta, dentro de la Opción; así, su valor
mínimo es de 4. Cuando un nodo de Internet procesa la dirección de la lista apuntada por el
puntero (es decir, se alcanza esa dirección) incrementa el puntero en 4, y redirige el paquete
a la siguiente dirección. Si el puntero llega a ser mayor que el Tamaño de Opción significa que
la información de ruta se ha procesado y registrado completamente y se redirigirá el paquete
a su dirección de destino. Si se alcanza la dirección de destino antes de haber procesado la
lista de direcciones completa (el puntero es menor que el Tamaño de Opción) la siguiente
dirección de la lista reemplaza a la dirección de destino del paquete y es a su vez
reemplazada por la dirección del nodo que está procesando el datagrama ("Ruta
Registrada"), incrementando, además, el puntero en 4. Utilizando este método de sustituir la
dirección especificada en origen por la Ruta Registrada se asegura que el tamaño de la
Opción (y de la cabecera IP) no varía durante su recorrido por la red.
- Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR): Exactamente igual que LSSR,
excepto en el tratamiento que los nodos harán de este datagrama. Al ser la ruta especificada
"estricta", un nodo debe reenviar el paquete directamente a la siguiente dirección, es decir,
no podrá redireccionarlo por otra red.
- Registro de Ruta: Mediante el uso de esta Opción se puede registrar el itinerario de un
datagrama. Los Datos de Opción consisten en un puntero (un octeto) y un espacio relleno de
ceros que contendrá la Ruta Registrada para el paquete. Cuando un nodo recibe un paquete
en el que está presente esta opción, escribirá su dirección IP en la posición indicada por el
puntero, siempre que ésta sea menor que el Tamaño de Opción, e incrementará el puntero
en 4.
RELLENO (Padding): Utilizado para alinear el campo de opciones a 32 bits.
Tamaño de Datagrama, MTU y fragmentación
MTU: (Maximum Trasfer Unit) Unidad de transferencia máxima.
5/70
Teleprocesos y Redes 2
TCP/IP selecciona el tamaño de datagrama más conveniente desde el principio y establece una forma
de dividir datagramas en fragmentos más pequeños cuando necesita viajar a través de una red que
tiene un MTU menor. Las piezas del datagrama dividido se conocen como fragmentos y al proceso de
división se conoce como fragmentación.
Una vez que un datagrama es fragmentado, los fragmentos viajan como datagramas separados hacia
su destino final donde serán reensamblados. Esto produce que el datagrama, en su trayecto hacia su
destino, una vez que sale de la red de MTU menor desaproveche el uso de otras redes con MTU
mayor. Otro inconveniente es que si un fragmento se pierde, el datagrama no podrá reensamblarse.
Reensamblado de Fragmentos: El host de destino iniciará un temporizador cuando recibe un
fragmento inicial. Si el temporizador termina antes que lleguen todos los fragmentos, el host los
descartará sin procesar el datagrama. Así la probabilidad de perder un datagrama se incrementa con
la fragmentación.
Control de fragmentación
Los campos de INDENTIFICADOR, FLAGS y OFFSET, en el encabezado del datagrama, controlan la
fragmentación y el reensamblado de los datagramas. Recordemos que el campo IDENTIFICADOR
contiene un entero único que identifica al datagrama. Para un segmento, el campo OFFSET especifica
el desplazamiento en el datagrama original de los datos que se están acarreando en el fragmento,
medido en unidades de 8 bytes, comenzando con un desplazamiento igual a cero.
Si el FLAG de no fragmentar esta puesto a 1 especifica que el datagrama no debe fragmentarse. Cada
vez que un router necesita fragmentar un datagrama que tiene activado este FLAG, el router
descarta el datagrama y devolverá un mensaje de error a la fuente.
El FLAG de more fragments especifica si el fragmento contiene datos intermedios del datagrama
original o se trata de la parte final del mismo.
ENCABEZADO DEL
DATAGRAMA
Datos1
600 bytes
ENCABEZADO DEL
FRAGMENTO 1
Datos1
IDENTIFICACION1 = IDENTIFICACIONORIG
OFFSET1 = OFFSETORIG
MORE1 = 1
ENCABEZADO DEL
FRAGMENTO 2
Datos2
IDENTIFICACION2 = IDENTIFICACIONORIG
OFFSET2 = OFFSETORIG + (600 / 8)
MORE2 = 1
ENCABEZADO DEL
FRAGMENTO 3
Datos3
Datos2
600 bytes
Datos3
200 bytes
IDENTIFICACION3 = IDENTIFICACIONORIG
OFFSET3 = OFFSET2 + (600 / 8)
MORE3 = MOREORIG
RUTEO DE DATAGRAMAS IP
En un sistema de conmutación de paquetes, el ruteo es el proceso de selección de un camino sobre
el que se mandarán paquetes, y el ruoter es la computadora que hace la selección.
Entrega Directa: Es la transmisión de un datagrama desde una máquina hasta otra a través de una
sola red física. Para hacer esto, el transmisor encapsula el datagrama en una trama física, transforma
la dirección IP en una dirección física y utiliza la red para entregar el datagrama.
Entrega Indirecta: Ocurre cuando el destino no esta en una red conectada directamente, lo que
obliga al transmisor a pasar el datagrama a un router para su entrega.
Una vez que la trama llega a un router, se extrae el datagrama encapsulado, e IP selecciona el
siguiente router a lo largo del camino hacia el destino. Se vuelve a colocar el datagrama en una trama
y se envía a través de la siguiente red física hacia el segundo router, y así sucesivamente, hasta que
se puede entregar en forma directa.
6/70
Teleprocesos y Redes 2
Ruteo Controlado por Tablas: El algoritmo de ruteo IP emplea una tabla de ruteo en cada máquina
que almacena información sobre posibles destinos y sobre cómo alcanzarlos. Debido a que tanto los
ruters como los hosts rutean datagramas, ambos tienen tablas de ruteo IP. Siempre que el software
de ruteo IP en un host necesita transmitir un datagrama, consulta la tabla de ruteo para decidir a
donde enviarlo.
Las tablas de ruteo sólo necesitan conocer prefijos de red y no direcciones IP completas, dado que
contener información de cada posible dirección de destino sería imposible de manejar y de mantener
actualizada.
Ruteo con Salto al Siguiente: Utilizar la porción de red de una dirección de destino en vez de toda la
dirección, hace que el ruteo sea eficiente y mantiene reducidas las tablas de ruteo. Por lo general,
una tabla de ruteo contiene pares {N, R}, donde N es la dirección IP de una red de destino y R la
dirección IP del “siguiente” router en el camino hacia la red N. Por lo tanto, la tabla de ruteo en el
router R sólo especifica un paso a lo largo del camino de R a su red de destino, el router no conoce el
camino completo hacia el destino.
Es importante entender que cada registro en una tabla de ruteo apunta hacia un router que se puede
alcanzar a través de una sola red. Todos los routers listados en la tabla de ruteo de la maquina M
deben residir en las redes con las que M se conecta de manera directa.
El ejemplo (a) muestra un ejemplo de internet con 4 redes y 3 routers, y (b) muestra la tabla de ruteo en R.
Rutas por Omisión: Una técnica usada para ocultar información y mantener reducido el tamaño de
las tablas de ruteo, es asociar muchos registros a un router por omisión. La idea es hacer que IP
busque primero en la tabla de ruteo para encontrar la red de destino. Si no aparece una ruta en la
tabla, las rutinas de ruteo envían el datagrama a un router por omisión.
Rutas por host Específico: IP permite que se especifiquen rutas por host como caso especial.
Algoritmo de Ruteo IP
RutaDatagrama (Datagrama, Taba de Ruteo)
Extraer la IP de destino, D, del datagrama y computar el prefijo de red, N;
Si N corresponde a cualquier dirección de red directamente conectada
Entregar el datagrama al destino D sobre dicha red (Esto comprende la
transformación de D en una dirección física, encapsulando el datagrama y
enviando el datagrama.)
De otra forma,
7/70
Teleprocesos y Redes 2
si la tabla contiene una ruta con host específico para D,
enviar el datagrama al salto siguiente especificado en la tabla.
de otra forma,
si la tabla contiene una ruta para la red N,
enviar el datagrama al salto siguiente especificando en la tabla;
de otra forma,
si la tabla contiene una ruta asignada por omisión,
enviar el datagrama al ruoter asignado por omisión especificado en la
tabla;
de otra forma,
declarar un error de ruteo;
Ruteo IP: Es importante entender que, a excepción de la disminución del TTL y de volver a calcular el
CHECKSUM, el ruteo IP no altera el datagrama original. En particular, las direcciones de origen y
destino del datagrama permanecen sin alteración. Cuando IP ejecuta el algoritmo de ruteo,
selecciona una nueva dirección IP, que es la dirección IP de la máquina a la que a continuación se
tendrá que enviar el datagrama. La nueva dirección es parecida a la dirección de un router. Sin
embargo, si el datagrama se puede entregar directamente, la nueva dirección será la misma que la
del último destino.
Dijimos que la dirección IP seleccionada por el algoritmo de ruteo IP se conoce como la dirección de
salto al siguiente, pues indica a donde enviará el datagrama (aunque no necesariamente sea el
destino del datagrama). ¿Dónde almacena IP la dirección de salto al siguiente? No en el datagrama.
De hecho, IP no almacena la dirección de salto al siguiente. Después de ejecutar el algoritmo de
ruteo, IP utiliza ARP para transformar la dirección de salto al siguiente en una dirección física y luego
pasa el datagrama y la dirección física de salto al siguiente al software de la interfaz de red,
responsable de la red física sobre la que el datagrama se debe enviar. El software de interfaz de red,
pone el datagrama en la porción de datos de la trama y lo envía.
Manejo de los datagramas entrantes: Cuando un datagrama IP llega a un host, el software de
interfaz de red lo entrega a IP para su procesamiento, si la dirección de destino del datagrama
corresponde a la dirección IP del host, IP acepta el datagrama y lo pasa al software de protocolo de
nivel superior.
ICMP – Protocolo de Mensajes de Control Internet
Para permitir que los routers en una red soporten errores, se agregó a los protocolos TCP/IP un
mecanismo de mensajes de propósito especial. El mecanismo es conocido como Protocolo de
Mensajes de Control Internet (ICMP).
Al igual que el resto del tráfico, los mensajes ICMP viajan a través de la red en la porción de datos de
los datagramas IP. Sin embargo, el destino final de un mensaje ICMP no es un programa de
aplicación, sino el software de IP de dicha máquina.
Cuando un datagrama causa un error, el ICMP sólo puede reportar la condición de error a la fuente
original del datagrama; la fuente debe relacionar el error con un programa de aplicación individual o
debe tomar alguna acción para corregir el problema.
Entrega de mensajes ICMP: Hay una excepción en los procedimientos de manejo de errores si un
datagrama que lleva un mensaje de ICMP causa un error. Esta excepción fue diseñada para evitar el
problema de tener mensajes de error sobre mensajes de error.
Formato de los Mensajes ICMP
Aunque cada mensaje ICMP tiene su propio formato, todos comienzan con los mismos tres campos:
TIPO
CODIGO
CHECKSUM
8/70
Teleprocesos y Redes 2
CODIGO: Proporciona información adicional sobre el tipo de mensaje.
TIPO: Define el significado del mensaje así como su formato. Los tipos incluyen.
- 0- Respuesta de Eco.
- 3- Destino inaccesible.
- 4- Disminución de origen.
- 5- Redireccionar (cambiar una ruta)
- 8- Solicitud de Eco.
- 11- Tiempo excedido para un datagrama.
- 12- Problema de parámetros para un datagrama
- 13- Solicitud de TimeStamp.
- 14- Respuesta de TimeStamp.
- 15- Solicitud de Información (obsoleto).
- 16- Respuesta de Información (obsoleto).
- 17- Solicitud de mascara de dirección.
- 18- Respuesta de mascara de dirección.
1) Prueba de accesibilidad y estado de un destino (Ping)
Una de las herramientas más utilizadas incluye los mensajes ICMP de echo request (solicitud de eco)
y echo reply (respuesta de eco). En muchos sistemas se conoce como el comando ping.
El formato de los mensajes de solicitud de eco y de respuesta:
TIPO
CODIGO
CHECKSUM
IDENTIFICADOR
NRO. SECUENCIA
DATOS OPCIONALES
...
DATOS OPCIONALES: Campo de longitud variable que contiene los datos que se regresarán al
transmisor.
IDENTIFICADOR: y NUMERO DE SECUENCIA: Los utiliza el transmisor para responder a las solicitudes.
2) Reporte de destinos no accedidos
Cuando un router no puede direccionar o entregar un datagrama IP, envía un mensaje de destino no
accesible a la fuente original, utilizando el formato:
TIPO
CODIGO
CHECKSUM
NO UTILIZADO (DEBE SER CERO)
ENCABEZADO DEL DATAGRAMA + PRIMEROS
64 BITS DEL DATAGRAMA
...
CODIGO: Contiene un número entero que describe con más detalle el problema. Los valores posibles
son:
- 0- Red inaccesible.
- 1- Host inaccesible
- 2- Protocolo inaccesible.
- 3- puerto inaccesible.
9/70
Teleprocesos y Redes 2
-
4- Se necesita fragmentación y configuración DF.
5- Falla en ruta origen.
6- Red de destino desconocida.
7- Anfitrión de destino desconocido.
8- Anfitrión de origen aislado.
9- Comunicación con la red de destino administrativamente prohibida.
10- Comunicación con el host de destino administrativamente prohibida.
11- Red inaccesible por el tipo de servicio.
12- Host inaccesible por el tipo de servicio.
Los errores de red no accesible por lo general implican fallas en el ruteo. Debido a que los mensajes
de error ICMP contienen un prefijo del datagrama que causo el problema, la fuente sabrá
exactamente qué dirección no es accesible.
3) Control de Congestionamiento y de flujo de datagramas
Los routers se pueden saturar con el tráfico, condición conocida como congestionamiento. Es
importante entender que el congestionamiento puede surgir por dos razones. Primero, una
computadora de alta velocidad puede ser capaz de generar tráfico de forma más rápida de lo que
una red lo puede transferir. Segundo, si muchas computadoras necesitan enviar datagramas al
mismo tiempo por el router.
Una máquina utiliza mensajes ICMP de este tipo para reportar el congestionamiento a la fuente
original. Un mensaje de disminución de tasa a la fuente es una solicitud para que la fuente reduzca la
velocidad de transmisión de datagramas. Por lo general, los routers congestionados envían un
mensaje de disminución de tasa al origen por cada datagrama que descartan. Otros, intentan evitar
los congestionamientos al enviar solicitudes de disminución cuando sus colas de espera crecen, pero
antes de que se saturen.
TIPO
CODIGO
CHECKSUM
NO UTILIZADO (DEBE SER CERO)
ENCABEZADO DEL DATAGRAMA + PRIMEROS
64 BITS DEL DATAGRAMA
...
4) Solicitudes de Cambio de Ruta
Cuando un router detecta un host que utiliza una ruta no optima, le envía al host un mensaje ICMP,
llamado de redireccionar solicitándole que cambie sus rutas. El router también redirecciona el
datagrama original a destino.
TIPO
CODIGO
CHECKSUM
DIRECCION DEL ROUTER
ENCABEZADO DEL DATAGRAMA + PRIMEROS
64 BITS DEL DATAGRAMA
...
DIRECCION DEL ROUTER: Contiene la dirección de un router que el host utilizará para alcanzar el
destino mencionado en la cabecera del datagrama.
10/70
Teleprocesos y Redes 2
5) Detección de rutas circulares o muy largas
Un router disminuye siempre el contador de tiempo de vida que posee el datagrama y lo descarta
cuando el conteo llega a cero. Siempre que un router descarta un datagrama ya sea porque su
conteo de saltos llega a cero o porque ocurre una terminación de tiempo mientras espera
fragmentos de un datagrama; envía un mensaje ICMP de tiempo excedido a la fuente del datagrama,
utilizando el formato siguiente:
TIPO
CODIGO
CHECKSUM
NO UTILIZADO (DEBE SER CERO)
ENCABEZADO DEL DATAGRAMA + PRIMEROS
64 BITS DEL DATAGRAMA
...
En estos casos el valor de CODIGO puede ser alguno de los siguientes:
- 0- Conteo de tiempo de vida excedido.
- 1- Tiempo para reensamblado de fragmentos excedido.
6) Sincronización de relojes y estimación de tiempos del transito
Una máquina solicitante envía un mensaje ICMP de solicitud de TimeStamp a otra, solicitándole que
informe su valor actual del reloj.
TIPO
CODIGO
IDENTIFICADOR
CHECKSUM
NRO. SECUENCIA
ORIGINAR TIMESTAMP
RECIBIR TIMESTAMP
TRANSMITIR TIMESTAMP
IDENTIFICADOR y NUMERO DE SECUENCIA: Los utiliza la fuente para asociar las solicitudes con las
respuestas.
ORIGINAR TIMESTAMP: Es llenado por la fuente original justo antes de transmitir el paquete.
RECIBIR TIMESTAMP: Se llena inmediatamente al recibir la solicitud.
TRANSMITIR TIMESTAMP: Se llena justo antes de transmitir la respuesta.
7) Obtención de Mascara de Red
Para conocer la máscara de sub red utilizada por la red local, una máquina puede enviar un mensaje
de solicitud de mascara de subred a un router. El mensaje puede ser enviado a un router
determinado, si se conoce su dirección, o por difusión.
TIPO
CODIGO
IDENTIFICADOR
CHECKSUM
NRO. SECUENCIA
MASCARA DE RED
IDENTIFICADOR y NUMERO DE SECUENCIA: Los utiliza la fuente para asociar las solicitudes con las
respuestas.
MASCARA DE RED: Una respuesta contiene la máscara de red.
11/70
Teleprocesos y Redes 2
DIRECCIONAMIENTO DE SUBRED Y SUPERRED
El esquema de direccionamiento IP presenta una debilidad, y es debido al crecimiento no previsto
por los diseñadores.
Al pensar en cómo se podría minimizar el número de direcciones de red asignadas sin destruir el
esquema original de direccionamiento, se pensó en que muchas redes físicas deben compartir el
mismo prefijo de red. Una forma de hacer esto es mediante direccionamiento de subredes.
Direccionamiento de SubRed
Una manera de entender esto es imaginarse que una localidad tiene asignada una sola dirección IP,
pero tiene dos o más redes físicas. Sólo los routers locales saben que existen muchas redes físicas y
como rutear el tráfico entre ellas; los routers en otros sistemas rutean todo el tráfico como si sólo
hubiera una única red.
Para lograr esto, cambia ligeramente la interpretación de direccionamiento IP. En vez de dividir la
dirección IP en Red y Host, la dirección se divide en una porción de red, y una porción local. La
interpretación de la porción de red permanece igual que en las redes que no utilizan
direccionamiento de subredes. La interpretación de la porción local identifica una red física y un host
en dicha localidad.
Flexibilidad en la asignación de direcciones de subred: Para permitir una máxima flexibilidad al
particionar las direcciones de subred, el estándar TCP/IP de subred permite que la interpretación se
escoja de forma independiente para cada red física, una vez que se selecciona una partición de
subred, todas las máquinas la deben utilizar.
Implantaciones de Subredes con Máscaras
La forma de implementar subredes es mediante mascaras. Una máscara es un número de 32 bits, y
se guarda en cada equipo que la necesite. Se debe escoger una máscara de subred para cada red. Los
bits en 1 en la máscara identifican la parte de la dirección de red y los bits en 0 como parte del
identificador de host.
RedID = IP AND MASK.
HostID = IP AND not MASK
12/70
Teleprocesos y Redes 2
El algoritmo de ruteo de subred.
Al igual que el algoritmo estándar de ruteo IP, el algoritmo de ruteo en subredes basa sus decisiones
en una tabla de ruteo. Recuerde que en el algoritmo estándar, las rutas por anfitrión y las rutas
asignadas por omisión son casos especiales que se deben verificar de manera explícita; para los
demás casos se lleva a cabo la búsqueda en tablas. Una tabla convencional de ruteo contiene
registros de la siguiente forma:
(dirección de red, dirección de salto siguiente)
Donde el campo de red especifica la dirección IP de la red de destino, N, y el campo salto siguiente
especifica la dirección de un router al que se deben enviar los datagramas destinados a N. El
algoritmo estándar de ruteo compara la porción de red de una dirección destino con el campo de
dirección de red de cada registro en la tabla de ruteo, hasta que encuentra una correspondencia.
Debido a que el campo de dirección de salto siguiente está reservado sólo para especificar una
máquina que se puede accesar a través de una red conectada de manera directa, solamente es
necesaria una búsqueda en tabla.
El algoritmo estándar sabe que una dirección esta divida en una porción de red y una porción local,
ya que los primeros tres bits codifican el tipo y formato de la dirección. Con las subredes, no es
posible decidir que bits corresponden a la red ni cuales corresponden al anfitrión sólo con la
dirección. En cambio el algoritmo modificado que se utiliza con las subredes guarda información
adicional en la tabla de ruteo. Cada registro dentro de la tabla contiene un campo adicional que
especifica la máscara de subred utilizada con la red:
(mascara de subred, dirección de red, dirección de salto siguiente)
Mantenimiento de las máscaras de subred
Las máscaras de Subred se propagan por de una solicitud de máscara de subred ICMP al router de la
red. La solicitud se puede transmitir por difusión si el host no conoce la dirección específica de un
router.
Con respecto a la asignación de máscaras de subred, cada localidad tiene la libertad de escoger una
cualquiera para sus redes. Cuando hacen asignaciones, los administradores intentan balancear los
tamaños de las redes, los números de redes físicas, el crecimiento esperado y el mantenimiento. La
dificultad surge porque las máscaras no uniformes proporcionan una flexibilidad máxima, pero
posibilitan hacer asignaciones que llevan a rutas ambiguas. O peor aún, permiten que las
asignaciones válidas se vuelvan no válidas si se agregan más hosts a las redes. Por lo general, para
identificar una red, una localidad selecciona bits contiguos de la porción local de una dirección y
utiliza la misma división para todas las redes físicas.
Direccionamiento de SuperRed
En el direccionamiento de SuperRedes, en contraposición con el de subredes, permite la utilización
de muchas direcciones IP para una sola organización.
Este tipo de direccionamiento crea un nuevo problema: la información que los routers almacenan e
intercambian aumenta drásticamente. Esto se debe a que una tabla de ruteo en vez de tener un
registro por cada organización, contiene muchos por cada una.
Este problema se resuelve con una técnica conocida como “Ruteo sin tipo de Inter-Dominio”. Esta
técnica colapsa un grupo de direcciones contiguas en un solo registro representado por dos datos: la
dirección más baja del grupo y una máscara de 32 bits. En particular, la máscara opera como una
máscara estándar de subred al determinar el fin del prefijo.
Los routers y los hosts que utilizan el direccionamiento de superred necesitan software de ruteo no
convencional que entienda los rangos de direcciones.
13/70
Teleprocesos y Redes 2
UDP – PROTOCOLO DE DATAGRAMA DE USUARIO
En la capa de protocolo IP, una dirección de destino identifica un host; no se hace ninguna otra
distinción con respecto a qué usuario o qué programa de aplicación recibirá el datagrama. Para esto
cada máquina contiene un grupo de puntos abstractos de destino, llamados puertos de protocolo.
Cada puerto de protocolo se identifica por medio de un número entero positivo.
En general, los puertos tienen memoria intermedia, para que los datos que llegan antes de que un
proceso esté listo para aceptarlos no se pierdan.
Para comunicarse con un puerto externo, un transmisor necesita saber tanto la dirección IP de la
máquina de destino como el número de puerto de protocolo del destino dentro de la máquina. Cada
mensaje debe llevar el número de puerto de protocolo del destino de la máquina a la que se envía,
así como el número de puerto de origen de la máquina fuente a la que se deben direccionar las
respuestas.
El UDP proporciona puertos de protocolo para distinguir entre muchos programas que se ejecutan en
la misma máquina. UDP utiliza el protocolo IP subyacente para transportar un mensaje de una
máquina a otra y proporciona la misma semántica de entrega de datagramas, sin conexión y no
confiable que IP. No emplea acuses de recibo para asegurarse de que lleguen mensajes, no ordena
los mensajes entrantes, ni proporciona retroalimentación para controlar la velocidad a la que fluye la
información entre las máquinas. Por lo tanto, los mensajes UDP se pueden perder, duplicar o llegar
sin orden.
Formato del mensaje: Consiste de dos partes: un encabezado y un área de datos.
PUERTO UDP ORIGEN
PUERTO UDP DESTINO
LONG. MSJ. UDP
CHECKSUM
DATOS
...
PUERTO ORIGEN Y PUERTO DESTINO: Contiene los números de puerto. PUERTO DE ORIGEN es
opcional. Cuando se utiliza, especifica la parte a la que se deben enviar las respuestas, de lo
contrario, puede tener el valor cero.
LONGITUD: contiene un conteo de los bytes en el datagrama UDP, incluye el encabezado y los datos.
CHECKSUM: Es opcional y un valor de cero significa que la suma no se computo. Es aconsejable
utilizarlo, dado que IP solo calcula el CHECKSUM del encabezado y no de los datos, con lo cual esta es
la única manera de garantizar que los datos lleguen intactos.
Para calcular el CHECKSUM, UDP añade un pseudo-encabezado al datagrama UDP y calcula el
CHECKSUM sobre todo el conjunto. El pseudo-encabezado no se transmite con el datagrama UDP, ni
se incluyen en su longitud. El propósito de utilizar un pseudo-encabezado es verificar que el
datagrama UDP llegó a su destino correcto.
En el destino final, el software de UDP revisa la suma de verificación utilizando la dirección IP de
destino, obtenida del encabezado del datagrama IP que transportó el mensaje UDP. Si la suma
concuerda, se confirma que llego al destino correcto, así como al puerto de protocolo deseado
dentro del host.
El pseudo-encabezado:
DIRECCION IP DE ORIGEN
DIRECCION IP DE DESTINO
CERO
PROTO
LONGITUD UDP
14/70
Teleprocesos y Redes 2
DIRECCION IP DE ORIGEN y DIRECCION IP DE DESTINO: contienen las direcciones IP que se utilizan
cuando se envíe el mensaje UDP.
PROTO: Contiene el código del tipo de protocolo IP (17 para UDP).
LONGITUD UDP: contiene la longitud del datagrama UDP (sin incluir el pseudo-encabezado). Para
revisar la suma de verificación, el receptor debe extraer estos campos del encabezado IP,
ensamblarlos en el formato de pseudo-encabezado y recuperar la suma.
Número de Puertos UDP reservados y disponibles
Existen dos enfoques para la asignación de puertos. El primero se vale de una autoridad central.
Todos se ponen de acuerdo en permitir que una autoridad central asigne los números de puerto
conforme se necesitan y publique la lista de todas las asignaciones, las cuales se conocen como
asignaciones bien conocidas de puertos.
El segundo enfoque emplea la transformación dinámica. En este enfoque, los puertos no se conocen
de manera global. En vez de eso, siempre que un programa necesita un puerto, el software de red le
asigna uno. Para conocer la asignación actual de puerto en otra computadora, es necesario enviar
una solicitud para averiguar qué puerto está utilizando determinada aplicación. La máquina objetivo
responde al proporcionar el número de puerto correcto a utilizar. Los diseñadores de TCP/IP
adoptaron un enfoque hibrido.
TCP – SERVICIO DE TRANSFERENCIA DE FLUJO CONFIABLE
Características del Servicio de Entrega Confiable
La interfaz entre los programas de aplicación y el servicio TCP/IP de entrega confiable, se puede
caracterizar por cinco funciones:
-
-
-
-
Orientación de flujo: El servicio de entrega de flujo en la máquina de destino pasa al
receptor exactamente la misma secuencia de bytes que le pasa el transmisor en la máquina
origen.
Conexión de circuito virtual: la transferencia de flujo es análoga a realizar una llamada
telefónica. Conceptualmente, una aplicación realiza una “llamada” que la otra debe aceptar.
Una vez que se establece, los módulos de protocolo informan a los programas de aplicación
que se estableció una conexión y que la transferencia puede comenzar. Si la comunicación no
se logra por algún motivo, ambas máquinas detectarán la falla y la reportarán a los
programas apropiados de aplicación.
Transferencia con memoria intermedia: Cuando se transfieren datos, cada aplicación utiliza
piezas del tamaño que encuentre adecuado, que pueden ser tan pequeñas como un byte.
Para hacer eficiente la transferencia y minimizar el tráfico de red, las implantaciones por lo
general recolectan datos suficientes de un flujo para llenar un datagrama razonablemente
largo antes de transmitirlo a través de una red. De forma similar, si el programa de aplicación
genera bloques de datos muy largos, el software de protocolo puede dividir cada bloque en
partes mas pequeñas para su transmisión. Para aplicaciones en las que los datos se deben
entregar aunque no se llene una memoria intermedia, el servicio de flujo proporciona un
mecanismo de empuje (push) que las aplicaciones utilizan para forzar una transferencia.
Flujo no estructurado.
Conexión Full Duplex.
15/70
Teleprocesos y Redes 2
Proporcionando Confiabilidad
El servicio de entrega confiable garantiza la entrega de los datos enviados de una máquina a otra sin
pérdida o duplicación. Para lograr esto se utiliza una técnica fundamental conocida como acuse de
recibo positivo con retransmisión. La técnica requiere que el receptor se comunique con el origen y le
envíe un mensaje de acuse de recibo (ACK) conforme recibe los datos. El transmisor guarda un
registro de cada paquete que envía y espera un acuse de recibo antes de enviar el siguiente paquete.
El transmisor también inicia un temporizador cuando envía un paquete y lo retransmite si dicho
temporizador expira antes de que llegue un acuse de recibo.
El problema final de confiabilidad surge cuando un sistema subyacente de entrega de paquetes los
duplica. La solución de la duplicación requiere acciones cuidadosas ya que tanto los paquetes como
los acuses de recibo se pueden duplicar. Por lo general los protocolos confiables detectan los
paquetes duplicados al asignar a cada uno un número de secuencia y al obligar al receptor a recordar
que números de secuencia recibidos. Para evitar la confusión causada por acuses de recibo
retrasados o duplicados, los protocolos de acuses de recibo positivos envían los números de
secuencia dentro de los acuses, para que el receptor pueda asociar correctamente los acuses de
recibo con los paquetes.
Ventanas deslizantes: Esta técnica es una forma más compleja de acuse de recibo positivo y
retransmisión que el método anterior. Los protocolos de ventana deslizante utilizan el ancho de
banda de red de mejor forma, ya que permite que el transmisor envíe varios paquetes sin esperar un
acuse de recibo.
Por ejemplo un protocolo de ventana deslizante con un tamaño de ventana de 8, se permite al
transmisor enviar 8 paquetes antes de recibir un acuse de recibo.
16/70
Teleprocesos y Redes 2
Una vez que el transmisor recibe un acuse de recibo para el primer paquete dentro de la ventana,
“mueve” la misma y envía el siguiente paquete. La ventana continua moviéndose en tanto se reciban
acuses de recibo.
Con un tamaño de ventana de 1, un protocolo de ventana deslizante sería idéntico a un protocolo de
acuse de recibo positivo. Al aumentar el tamaño de la ventana, es posible eliminar completamente el
tiempo ocioso de la red.
Conceptualmente, un protocolo de ventana deslizante siempre recuerda que paquetes tienen acuse
de recibo y mantiene un temporizador separado para cada paquete sin acuse de recibo. Si se pierde
un paquete, el temporizador concluye y el transmisor reenvía el paquete. Cuando el transmisor
desliza su ventana, mueve hacia atrás todos los paquetes con acuse. En el extremo receptor, el
software de protocolo mantiene una ventana análoga, que acepta y acusa como recibidos los
paquetes conforme llegan. Por tanto, la ventana divide la secuencia de paquetes en tres partes: los
paquetes a la izquierda de la ventana se transmitieron, recibieron y acusaron exitosamente; los
paquetes a la derecha de la ventana no se han transmitido; y los paquetes que quedan dentro de la
ventana están en proceso de transmisión.
Puertos, conexiones y puntos extremos: TCP utiliza la conexión, no el puerto de protocolo, como su
abstracción fundamental; las conexiones se identifican por medio de un par de puntos extremos.
Una conexión consiste en un circuito virtual entre dos programas de aplicación. TCP define que un
punto extremo es un par (hostId, puerto), en donde hostId es la IP de un host y puerto es un puerto
TCP del host.
Puede darse el caso que dos conexiones utilicen el mismo puerto en una máquina determinada, pero
no hay ambigüedad. Debido a que el TCP asocia los mensajes entrantes con una conexión en vez de
hacerlo con un puerto de protocolo, utiliza ambos puntos extremos para identificar una conexión
apropiada.
Desde el punto de vista de un programador, la abstracción de comunicación es importante. Significa
que un programador puede diseñar un programa que proporcione servicio concurrente a varias
conexiones al mismo tiempo, sin necesitar números únicos de puerto local para cada una.
Aperturas pasivas y activas: Al ser TCP un protocolo orientado a la conexión, requiere que ambos
puntos estén de acuerdo en participar. Para hacerlo, el programa de aplicación en un extremo realiza
una función de apertura pasiva al contactar su sistema operativo e indicar que aceptará una
conexión entrante. En ese momento, el sistema operativo asigna un número de puerto TCP a su
extremo de la conexión. El programa de aplicación en el otro extremo debe contactar a su sistema
operativo mediante una solicitud de apertura activa para establecer la conexión.
Segmentos, flujos y números de secuencia: TCP visualiza el flujo como una secuencia de bytes que
divide en segmentos para su transmisión. TCP también utiliza un mecanismo especializado de
ventana deslizante para solucionar dos problemas importantes: la transmisión eficiente y el control
de flujo. El mecanismo de ventana de TCP hace posible enviar varios segmentos antes de que llegue
un acuse de recibo. También soluciona en problema de control de flujo de extremo a extremo, al
permitir que el receptor restrinja la transmisión hasta que tenga espacio suficiente en memoria
interna para incorporar más datos.
El mecanismo TCP de ventana deslizante opera a nivel de byte, no a nivel de segmento ni de paquete.
Los bytes del flujo de datos se numeran de manera secuencial, y el transmisor guarda tres punteros
asociados con cada conexión. Los punteros definen una ventana deslizante. El primer puntero marca
el extremo izquierdo de la ventana deslizante, separa los bytes que ya se enviaron. Un segundo
puntero marca el extremo derecho de la ventana deslizante y define el byte más alto de la secuencia
que se puede enviar antes de recibir más acuses de recibo. El tercer puntero señala la frontera
dentro de la ventana que separa los bytes que ya se enviaron de los que aún no se envían.
17/70
Teleprocesos y Redes 2
Dado que las conexiones TCP son del tipo full duplex, se llevan a cabo dos transferencias al mismo
tiempo en cada conexión, una en cada dirección. Por lo tanto el software TCP en cada extremo
mantiene dos ventanas por cada conexión, una se desliza a lo largo del flujo de datos que se envía,
mientras que la otra se desliza a lo largo de los que se reciben.
Tamaño Variable de Ventana y Control de Flujo
El protocolo TCP permite que el tamaño de la ventana varíe. Cada acuse de recibo, que informa
cuántos bytes se recibieron, contiene un aviso de ventana, que especifica cuántos bytes de datos
adicionales está preparado para aceptar el receptor. En respuesta a un aumento en el aviso de
ventana, el transmisor aumenta el tamaño de su ventana deslizante y procede al envío de bytes de
los que todavía no se tiene acuse de recibo. En respuesta a una disminución en el aviso de ventana,
el transmisor disminuye el tamaño de su ventana y deja de enviar los bytes que se encuentran más
allá de la frontera. De hecho, los anuncios más pequeños acompañan a los acuses de recibo, así que
el tamaño de la ventana cambia en el momento que se mueve hacia delante.
La ventaja de utilizar una ventana de tamaño variable es que ésta proporciona control de flujo así
como una transferencia confiable. Si la memoria intermedia del receptor se llena, no puede aceptar
más paquetes, así que envía un anuncio de ventana más pequeño. En caso extremo, el receptor
anuncia un tamaño de ventana igual a cero para detener toda la transmisión. Después, cuando hay
memoria intermedia disponible, el receptor anuncia un tamaño de ventana distinto a cero para
activar el flujo de datos.
Formato del Segmento TCP
La unidad de transferencia entre el software TCP de dos máquinas se conocen como segmentos. Los
segmentos se intercambian para establecer conexiones, transferir datos, enviar acuses de recibo,
anunciar los tamaños de ventanas y para cerrar conexiones.
PUERTO ORIGEN
PUERTO DESTINO
NUMERO DE SECUENCIA
NUMERO DE ACUSE DE RECIBO
HLEN
RES.
CODE
VENTANA
CHECKSUM
PUNT. DE URGENCIA
OPCIONES (SI LAS HAY)
RELLENO
DATOS
…
Cada segmento de divide en dos partes: encabezado y datos.
PUERTO FUENTE Y PUERTO DESTINO: Contiene los números de puerto TCP que identifican a los
programas de aplicación en los extremos de la conexión.
NUMERO DE SECUENCIA: Identifica la posición de los datos del segmento en el flujo de datos del
transmisor.
NUMERO DE ACUSE DE RECIBO: Identifica el número de bytes que la fuente espera recibir después.
HLEN: Contiene un número entero que especifica la longitud del encabezado del segmento, medida
en múltiplos de 32 bits. Es necesario porque el campo OPCIONES puede variar su tamaño.
CODE BITS: Determina el propósito y contenido del segmento. Los seis bits de izquierda a derecha
representan lo siguiente.
18/70
Teleprocesos y Redes 2
-
URG: El campo de puntero de urgente es válido.
ACK: El campo de acuse de recibo es válido.
PSH: Solicita una operación push.
RST: Iniciación de la conexión.
SYN: Sincronizar números de secuencia.
FIN: El emisor ha llegado a su fin de flujo de bytes.
VENTANA: Especifica el tamaño de su memoria intermedia. De esta manera TCP informa cuántos
datos está dispuesto a aceptar cada vez que envía un segmento.
PUNTERO DE URGENCIA: Cuando está activado el bit URG, éste campo especifica la posición dentro
del segmento en la que terminan los datos urgentes.
OPCIONES: TCP utiliza este campo para negociar con el software TCP del otro extremo de la
conexión; una de las opciones permite que TCP especifique el tamaño máximo de segmento (MSS)
que está dispuesto a recibir.
CHECKSUM: Se utiliza para verificar la integridad del encabezado y los datos del segmento TCP. Para
computar esta suma de verificación, TCP coloca un pseudo-encabezado en el segmento y recalcula la
suma de 16 bits sobre todo el resultado. TCP no cuenta el pseudo-encabezado en la longitud del
segmento, ni tampoco lo transmite. TCP utiliza aritmética de de 16 bits y toma el complemento a 1
de la suma. El propósito de utilizar un pseudo-encabezado es el permitir que el receptor verifique
que el segmento llego a su destino correcto.
Pseudo-Encabezado:
DIRECCION IP DE LA FUENTE
DIRECCION IP DEL DESTINO
CERO
PROTOCOLO
LONGITUD TCP
PROTOCOLO: es el valor que utilizara el sistema subyacente de entrega en su campo tipo de
protocolo. En el caso de TCP el valor es 6.
LONGITUD TCP: especifica la longitud total del segmento TCP, incluyendo el encabezado TCP.
Datos Fuera de Banda: Para incorporar señalización fuera de banda, TCP permite que el transmisor
especifique los datos como urgentes, dando a entender que se debe notificar su llegada al programa
receptor tan pronto como sea posible, sin importar la posición en el flujo. Esto, se logra mediante el
bit de URG y el campo PUNTERO DE URGENCIA del segmento.
Opciones de Tamaño máximo de Segmento: No todos los segmentos que se envían a través de una
conexión serán del mismo tamaño. Sin embargo, ambos extremos necesitan acordar el tamaño
máximo de los fragmentos que transferirán. TCP por lo general computará un tamaño máximo de
segmento de tal forma que los datagramas IP resultantes correspondan con la MTU de la red. Es
claro que si el tamaño del segmento es chico, la utilización de la red permanece baja, esto se debe al
elevado overhead producido por el agregado de los encabezados de TCP e IP. Por otro lado, si los
tamaños de segmento son muy grandes, es posible que IP deba fragmentarlos.
Acuses de Recibo y Retransmisión
Como TCP envía los datos en segmentos de longitud variable, y debido a que los segmentos
retransmitidos pueden incluir más datos de los originales, los acuses de recibo no pueden asociarse
fácilmente con los datagramas o segmentos. De hecho, se remiten a una posición en el flujo,
utilizando los números de secuencia de flujo. El receptor recolecta bytes de datos de los segmentos
entrantes y reconstruye una copia exacta del flujo que se envía. Como los segmentos viajan en
19/70
Teleprocesos y Redes 2
datagramas IP, se pueden perder o llegar en desorden; el receptor utiliza los números de secuencia
para reordenar los segmentos.
Un acuse de recibo TCP especifica el número de secuencia del siguiente byte que el receptor espera
recibir. A este esquema de acuses de recibo se lo llama acumulativo porque reporta cuánto se ha
acumulado del flujo. Una ventaja de este esquema es que son fáciles de generar y no son ambiguos.
Una desventaja es que el emisor no obtiene información sobre todas las transmisiones exitosas, sino
únicamente sobre una sola porción. Para entender el porqué es una desventaja, piense en una
ventana con 5000 bytes comenzando en la posición 101 en el flujo, y suponga que el transmisor
envió todos los datos transmitiendo 5 segmentos. Supongamos también que llegan todos menos el
primero. Conforme fue llegando cada segmento, el receptor envió un acuse de recibo, pero todos
ellos especificaban el byte 101, que es el byte continuo siguiente más alto que espera recibir. No hay
forma que el receptor indique al transmisor que llego la mayor parte de los datos para la ventana
actual.
Timeout y Retransmisión
Cada vez que se envía un segmento, TCP arranca un temporizador y espera un acuse de recibo. Si se
produce un timeout antes de recibir el acuse de recibo correspondiente, TCP asume que el segmento
se perdió o corrompió y lo retransmite.
TCP utiliza un algoritmo adaptable de retransmisión para manejar retrasos variables. TCP monitorea
el desempeño de cada conexión y deduce valores razonables para el timeout. Para esto, TCP registra
la hora que se envía cada segmento y la hora en que se recibe el acuse de recibo de los datos en el
segmento. A partir de estos dos valores, TCP computa el tiempo transcurrido, conocido como
muestra de tiempo de viaje redondo (muestra de RTT). TCP almacena el RTT como promedio y a
medida que va recibiendo nuevas muestras de RTT, los utiliza para cambiar lentamente dicho
promedio.
RTT = (α * old_RTT) + ((1-α) * new_muestra_RTT)
Elegir α cercano a 1, hace que el promedio sea inalterable ante cambios mínimos. Elegir un valor de α
cercano a 0 hace que el promedio responda con rapidez a los cambios.
Timeout = β * RTT
Por una parte, para detectar con rapidez la pérdida de paquetes, el valor de timeout debe acercarse
al actual RTT. La pronta detección de pérdida de paquetes hace que TCP no espere un tiempo
innecesariamente largo para retransmitir. Por otra parte si β=1, hace que ante cualquier retraso
pequeño, TCP retransmita innecesariamente, lo cual desperdiciará ancho de banda de la red.
Medición precisa de muestra de RTT
Ambigüedad de acuse de recibo: En el caso que TCP retransmita un segmento debido a un timeout,
el receptor no tiene forma de saber si un acuse de recibo corresponde al segmento original o al
retransmitido.
El problema aquí radica sobre cual empezará a contar el tiempo (la original o la última). Veremos que
ninguna de las dos funciona. En el caso de asociar los acuses de recibo con la transmisión original,
puede causar que el RTT aumente sin medida en los casos en los que la red pierda datagramas.
Asociar el acuse de recibo con la retransmisión más reciente tampoco funciona, dado que se podría
asociar la retransmisión con un acuse de recibo anterior y producir un RTT más pequeño de lo que
debería y causando más retransmisiones.
20/70
Teleprocesos y Redes 2
Algoritmo de Karn
Para resolver el problema anterior, TCP no debe actualizar la estimación de RTT para los segmentos
retransmitidos. Esto se conoce como algoritmo de Karn, y evita el problema de los acuses de recibos
ambiguos (usa acuses relacionados con segmentos transmitidos sólo una vez).
Una implementación simple del algoritmo de Karn también puede llevar a fallas. Considere lo que
sucede si TCP envía un segmento después de un aumento en el retraso. TCP computa un timeout
mediante la estimación existente de RTT. El timeout será demasiado pequeño para el nuevo retardo
y forzará la retransmisión. Si TCP ignora los acuses de recibo para los segmentos retransmitidos,
nunca actualizará la estimación y el ciclo continuará.
Para resolver dicha falla, el algoritmo de Karn necesita que el transmisor combine las técnicas de
timeout de transmisión con la estrategia de timer backoff (anulación del temporizador). Si se termina
el tiempo y se provoca una retransmisión, TCP aumenta el valor de tiemout.
new_timeout =  * timeout
Respuesta al congestionamiento
El congestionamiento es una condición de retraso severo causada por una sobrecarga de datagramas
en uno o más routers. Esto se produce cuando el número de datagramas entrantes en un router
congestionado crece hasta alcanzar su capacidad máxima y comienza a descartar datagramas.
La mayoría de los protocolos de transporte utilizan el timeout y la retransmisión, lo cual termina
produciendo un aumento en el retraso al retransmitir datagramas, lo que empeora el
congestionamiento.
Para evitar congestionamiento, TCP recomienda la utilización de dos técnicas: arranque lento y
disminución multiplicativa. Dijimos que para cada conexión, TCP debe recordar el tamaño de la
ventana del receptor. Para controlar el congestionamiento, TCP mantiene un segundo límite, límite
de ventana de congestionamiento.
En una conexión no congestionada, la ventana de congestionamiento es del mismo tamaño que la
ventana del receptor. La reducción de la ventana de congestionamiento reduce el tráfico que TCP
inyecta a la conexión.
Prevención del congestionamiento por Disminución Multiplicativa: Cuando se pierda un segmento,
reducir a la mitad la ventana de congestionamiento (hasta un mínimo de 1). Si la pérdida continúa
TCP continúa duplicando el timeout antes de retransmitir.
Recuperación de Arranque Lento (Aditiva): Siempre que se arranque el tráfico en una nueva conexión
o se aumente el tráfico después de un período de congestionamiento, activar la ventana de
congestionamiento con el tamaño de un solo segmento y aumentarla un segmento cada vez que
llegue un acuse de recibo.
El termino arranque lento puede no estar bien aplicado porque bajo condiciones ideales, el arranque
no es muy lento. TCP inicia la ventana de congestionamiento en 1, envía un segmento y espera.
Cuando llega el acuse de recibo, aumenta la ventana de congestionamiento a 2, envía dos segmentos
y espera. Cuando llegan los dos acuses de recibo, cada uno aumenta la ventana de
congestionamiento en 1, por lo que TCP puede enviar 4 segmentos. Los acuses por estos 4
segmentos incrementarán a 8 la ventana de congestionamiento. Cuando ocurren cuatro viajes
redondos, el TCP puede enviar 16 segmentos, que a veces es lo suficiente para llegar al límite de la
ventana del receptor.
Para evitar el aumento demasiado rápido del tamaño de la ventana y no causar congestionamiento
adicional, TCP agrega una restricción más. Una vez que la ventana de congestionamiento llega a la
mitad de su tamaño original, TCP entra en una fase de prevención de congestionamiento y hace más
lenta la velocidad de incremento. Durante esta fase, aumenta el tamaño de la ventana por 1
solamente si, para todos los segmentos en la ventana, se tienen acuses de recibo.
21/70
Teleprocesos y Redes 2
Establecimiento de una conexión TCP
Para establecer una conexión, TCP utiliza un saludo (handshake) de tres etapas.
Números de Secuencia Inicial
El saludo de tres etapas realiza dos funciones importantes. Garantiza que ambos lados estén listos
para transferir datos (y que tengan conocimiento de que ambos están listos) y permite, a ambas
partes, acordar un número de secuencia inicial. Los números de secuencia son enviados y
reconocidos durante el saludo. Cada máquina debe seleccionar un número un número de secuencia
inicial en forma aleatoria que se utilizará para identificar bytes en el flujo que se esta enviando.
Para entender cómo las máquinas pueden acordar un número de secuencia para dos flujos después
de sólo tres mensajes, recordemos que cada segmento contiene un campo de número de secuencia y
un capo de acuse de recibo. La máquina A, que inicia un saludo, transfiere un número de secuencia
inicial, x, en el campo de secuencia del primer segmento SYN como parte del saludo de tres etapas.
La máquina B, recibe el SYN, registra el número de secuencia y responde enviando su número de
secuencia inicial en el campo de secuencia así como un reconocimiento que especifica el byte x+1
esperado por B (piggybacking). En el mensaje final, A envía un “acuse de recibo” de la recepción del
mensaje de B de los bytes a través de y. En todos los casos, los acuses de recibo siguen la convención
de utilizar el número del próximo byte esperado.
Terminación de una conexión TCP
TCP utiliza una modificación del saludo de tres etapas para cerrar conexiones. Recordemos que las
conexiones TCP son full duplex que contienen dos transferencias de flujos independientes. Cuando
un programa de aplicación informa a TCP que ya no tiene más datos para enviar, cerrará la conexión
en una dirección.
Una vez que la conexión se ha cerrado en una dirección dada, TCP rechaza más datos en esta
dirección. Mientras tanto, los datos pueden continuar fluyendo en la dirección opuesta hasta que el
emisor se cierra. Por supuesto, los acuses de recibo continúan fluyendo hacia el emisor incluso
después de que la conexión se ha cerrado. Cuando ambas direcciones se han cerrado, TCP en cada
punto extremo borra sus registros de la conexión.
22/70
Teleprocesos y Redes 2
Reset de una conexión TCP
TCP proporciona una capacidad de reiniciación (reset) para desconexiones anormales. Para resetear
una conexión, un lado inicia la interrupción enviando un segmento con el bit RST activado en el
campo CODIGO. El otro lado responde a un segmento de reset de forma inmediatamente
interrumpiendo la conexión. TCP también informa al programa de aplicación que se ha presentado
un reset. Un reset es una interrupción instantánea, lo cual significa que la transferencia en ambas
direcciones se interrumpe de manera inmediata y se liberan recursos como los búfers.
Forzando la entrega de datos
Para forzar la entrega TCP proporciona la operación de push, que un programa de aplicación puede
utilizar para forzar la entrega de bytes en el flujo de transmisión sin esperar a que se les almacene en
memoria intermedia. También solicita que se active el bit PSH del campo CODIGO, así los datos se
entregarán sin retraso al programa de aplicación en el receptor.
Números reservados para puertos TCP
TCP cambia la asignación dinámica de puertos mediante un conjunto de asignación de puertos bien
conocidos para programas llamados con frecuencia, pero la salida de la mayor parte de los números
de puerto disponibles para el sistema operativo se asigna conforme los programas lo necesitan.
Síndrome de ventana tonta y paquetes pequeños
Las primeras implementaciones de TCP presentaron un problema conocido como síndrome de
ventana tonta en el cual cada acuse de recibo anunciaba una pequeña cantidad de espacio disponible
y cada segmento transportaba una pequeña cantidad de datos.
Por ejemplo, consideremos lo que sucedería si la aplicación de un receptor elige leer los datos de
entrada un byte a la vez. Cuando una conexión se establece por primera vez, el receptor TCP asigna
un búfer de K bytes y utiliza el campo VENTANA, en los segmentos de acuse de recibo, para anunciar
el tamaño disponible del búfer al emisor. Si la aplicación del emisor genera datos rápidamente, el
emisor TCP transmitirá segmentos con datos para toda la ventana. Finalmente, el emisor recibirá un
acuse de recibo que especifica que la ventana está llena y que no queda espacio adicional en el búfer
del receptor.
Cuando la aplicación de recepción lee un byte de datos desde la memoria intermedia llena, queda
disponible un espacio de un byte. Hemos dicho que cuando un espacio queda disponible en el búfer,
el TCP genera un acuse de recibo que utiliza el campo VENTANA, en la máquina de recepción, para
informar al emisor. En el ejemplo, el receptor anunciará una ventana de un byte. Cuando tenga
23/70
Teleprocesos y Redes 2
conocimiento del espacio disponible, el emisor TCP responderá con la transmisión de un segmento
que contenga un byte de datos.
Prevención del síndrome de ventana tonta
Prevención del lado del receptor: En general un receptor mantiene un registro interno de la ventana
disponible en el momento, pero retarda los anuncios para incrementar el tamaño de la ventana del
emisor hasta que la ventana pueda avanzar una cantidad significativa. La definición de “significativa”
depende del tamaño de la memoria intermedia del receptor y del tamaño del segmento máximo. TCP
lo define como el mínimo de la mitad de la memoria intermedia del receptor o el número de bytes de
datos en un segmento de tamaño máximo.
Prevención de la ventana tonta del lado del emisor: Así, para lograr este objetivo, un emisor TCP
debe permitir a la aplicación del emisor hacer múltiples llamadas a write y debe reunir los datos
transferidos con cada llamada antes de transmitirlos a un solo segmento largo. Es decir que un
emisor TCP debe retardar el envío de un segmento hasta que pueda acumular una cantidad
razonable de datos. Esta técnica se conoce con el nombre de clumping (agrupamiento). La cuestión
es la siguiente, ¿Qué tanto debe esperar TCP antes de transmitir datos? La técnica que un emisor TCP
utiliza para evitar el envío de paquetes pequeños es flexible –el retraso depende del desempeño
actual de la red. La prevención de la ventana tonta en el lado del emisor se conoce como self clocking
pues no se calculan retardos. Por lo contrario, el TCP utiliza la llegada de un acuse de recibo para
disparar la transmisión de paquetes adicionales. Si una aplicación genera datos un byte por vez, TCP
enviará el primer byte inmediatamente. Sin embargo, hasta que llegue el ACK, TCP acumulará bytes
adicionales en su memoria intermedia. Así, si la aplicación es razonablemente rápida, comparada con
la red, los segmentos sucesivos contendrán muchos bytes. Si la aplicación es lenta en comparación
con la red, se enviarán segmentos pequeños sin retardos largos. Esta técnica es conocida como
algoritmo de Nagle.
RUTEO – NUCLEOS PARES Y ALGORITMOS
Orígenes de las Tablas de Ruteo
Cada router está conectado a dos o más redes físicas y envía datagramas IP entre éstas, acepta
datagramas que llegan por medio de una interfaz de red y los rutea hacia otra interfaz. Excepto para
los destinos conectados directamente a la red. Un datagrama viaja de un router a otro hasta
encontrar un router que se encuentre conectado directamente a la misma red en la que se ubica su
destino final. El ruteo IP utiliza una tabla para tomar decisiones de ruteo. Cada elemento de
información en la tabla de ruteo especifica la porción de red de una dirección de destino y establece
la dirección de la siguiente máquina a lo largo de una ruta utilizada para alcanzar la red.
En general el establecimiento de rutas comprende procesos de iniciación y actualización. Cada router
debe establecer un conjunto inicial de rutas cuando es iniciado y debe actualizar las tablas cuando las
rutas cambian. En algunos sistemas el router lee una tabla de ruteo inicial desde un almacenamiento
secundario en el proceso de iniciación, haciéndola residente en la memoria principal. En otros casos,
se comienza con una tabla vacía que debe llenarse ejecutando comandos explícitos. Otros comienzan
por deducir un conjunto inicial de rutas del conjunto de direcciones para la red local a la que la
máquina esta conectada, y se pone en contacto con las máquinas vecinas para solicitar rutas
adicionales.
24/70
Teleprocesos y Redes 2
Ruteo con información parcial
La diferencia principal entre los routers y los hosts, es que los hosts saben muy poco acerca de la
estructura de la red a la que están conectadas. De hecho, muchos hosts tienen sólo dos rutas en su
tabla de ruteo: una para la red local y otra por omisión hacia un router cercano.
Un host puede rutear datagramas exitosamente aun cuando sólo cuente con información de ruteo
parcial ya que puede basarse en un router.
Router de núcleo
El sistema de núcleo estaba diseñado para proporcionar rutas autorizadas consistentes y confiables
para todos los destinos posibles.
Debido a que coda router de núcleo conoce todas las rutas hacia todos los destinos posibles, no es
necesaria una ruta por omisión. Si la dirección de destino del datagama no aparece en la tabla de
ruteo de un router de núcleo, el router generará un mensaje de destino inalcanzable, ICMP, y
eliminará el datagrama. En esencia, el diseño de núcleo evita la ineficiencia al eliminar las rutas por
omisión.
Una arquitectura de ruteo de núcleo requiere de un conjunto centralizado de servidores de ruteo
como depósito de información acerca de todos los destinos posibles en una red. Este sistema trabaja
mejor en redes que cuentan con una sola columna vertebral de red administrada centralmente. La
expansión de la topología hacia múltiples columnas vertebrales de redes hace el ruteo mas complejo;
el método de la división de la arquitectura de núcleo, en la que todos los routers utilizan rutas por
omisión, introduce la posibilidad de que se desarrollen ciclos cerrados de ruteo.
Ruteo por Vector-Distancia (Bellman-Ford)
El router establece una lista de todas las rutas conocidas en una tabla. Cuando arranca, un router
inicia esta tabla de ruteo para que contenga una entrada de información por cada red conectada
directamente. Cada introducción en la red identifica una red de destino y establece una distancia
hacia la red, por lo general medida en saltos.
Periódicamente, cada router envía una copia de su tabla de ruteo a cualquier otro router que pueda
alcanzar de manera directa. Cuando llega un reporte al router K desde el router J, K examina el
conjunto de destinos reportados y la distancia de cada uno. Si J conoce una ruta más corta para
alcanzar un destino o si J reporta un destino que K no tiene en su tabla, o bien si K rutea actualmente
hacia un destino a través de J y la distancia de J hacia el destino ha cambiado, K actualiza esta
información en su tabla.
Observe que si J reporta una distancia N, el lado actualizado en K tendrá la distancia N+1 (la distancia
para alcanzar el destino desde J, más la distancia de alcanzar J). Por supuesto, la tabla de ruteo
completa contiene una tercera columna que especifica la ruta. La entrada inicial de datos se marca
con el valor entrega inmediata. Cuando el router K añade o actualiza una entrada de datos en
respuesta al mensaje de J, asigna a J como la ruta para tal dato.
25/70
Teleprocesos y Redes 2
El algoritmo vector-distancia crea un problema de convergencia lenta o conteo al infinito, problema
en el cual aparecerán inconsistencias, debido a que los mensajes de actualización de ruteo se
difunden lentamente a través de la red. Seleccionando un infinito pequeño se ayuda a limitar la
convergencia, pero no se elimina.
Como se muestra en (a), el router R1 tiene una conexión directa a la red 1, con lo cual tiene una ruta
de distancia 1 en su tabla. El router R2 ha aprendido la ruta desde R1 y anuncia la ruta con distancia 2.
Finalmente R3 aprende la ruta de R2 y la anuncia con distancia 3.
Ahora R1 pierde conexión con la red 1. R1 actualiza su tabla de ruteo especificando una distancia a la
red 1 como infinito (16 en RIP). Supongamos ahora que R2 logra anunciar sus rutas justo después de
que la conexión de R1 fallara. Si esto sucede, R1 recibirá los mensajes de R2 y seguirá el algoritmo
usual: éste notará que R2 ha anunciado una ruta hacia la red 1 a un costo más bajo, calculando ahora
que se encuentra a 3 pasos para alcanzar la red 1 e instalará una nueva ruta a través de R2. En el
siguiente ciclo de intercambio de ruteo, R1 difundirá sus tablas. Cuando R2 aprenda que las rutas de
R1 hacia la red 1 tiene una longitud igual a 3, ésta calculará una nueva longitud para tal ruta,
haciéndola igual a 4. En el siguiente ciclo, R1 recibe el incremento desde R2 e incrementa la distancia
a 5. Este proceso continuará contando hasta el infinito.
Solución al problema de la convergencia lenta
Otra forma de pensar el problema de la convergencia lenta es en términos de flujo de información. Si
un router anuncia una ruta corta hacia alguna red, todos los routers receptores responderán
rápidamente instalando la ruta. Si un router deja de anunciar una ruta, el protocolo deberá depender
de un mecanismo de límite de tiempo antes de considerar la ruta como inaccesible.
Técnica de actualización de horizonte dividido: Cuando se utiliza está técnica, un router registra la
interfaz por la que ha recibido una ruta particular y no difunde esta información acerca de la ruta de
regreso sobre la misma interfaz.
Poison Reverse: Una vez que la conexión desaparece, el router anuncia la conexión conservando la
entrada de información por varios períodos de actualización e incluye un costo infinito en la difusión.
Para hacer esta técnica más efectiva, se debe combinar con las triggered updates. Las
actualizaciones activadas obligan a un router a que envíe una difusión inmediatamente que recibe
malas noticias, en lugar de esperar el próximo período de difusión. Al enviar una actualización
inmediatamente, un router minimiza el tiempo en el que es vulnerable por recibir las buenas
noticias.
RUTEO – SISTENAS AUTONOMOS
Sistemas Autónomos
Para propósitos de ruteo a un grupo de redes y routers controlados por una sola autoridad
administrativa se lo conoce sistemas autónomos. Los routers dentro de un sistema autónomo son
libres de seleccionar sus propios mecanismos de exploración, propagación, validación y verificar la
consistencia de las rutas.
Dado que las redes y los routers se encuentran bajo una sola unidad administrativa, esta autoridad
puede garantizar que las rutas internas se mantengan consistentes y viables; más aún, la autoridad
26/70
Teleprocesos y Redes 2
administrativa puede seleccionar a una de sus máquinas para servir como la máquina que aparecerá
ante el mundo exterior como el acceso hacia la red.
Vecinos Exteriores: se los llama así a los routers que intercambian información de ruteo y que
pertenecen a dos sistemas autónomos diferentes.
Vecinos Interiores: se los llama así a los routers que intercambian información de ruteo y que
pertenecen al mismo sistema autónomo.
OSPF – RUTEO EN UN SISTEMA AUTONOMO
Rutas Interiores dinámicas y Estáticas
En redes pequeñas que cambian lentamente, los administradores pueden establecer y modificar las
rutas a mano. El administrador tiene una tabla de redes y actualiza la tabla si una red nueva se añade
o se elimina del sistema autónomo.
La desventaja de un sistema manual es obvia; los sistemas manuales no se pueden adaptar al
crecimiento o a los cambios rápidos, para lo cual son necesarios métodos automatizados. Estos
métodos pueden también ayudar a mejorar la confiabilidad y la respuesta a las fallas en pequeñas
redes que tienen rutas alternativas.
Para automatizar información sobre la accesibilidad de una red, los routers interiores normalmente
se comunican con otros, intercambian información de accesibilidad o información de ruteo, a partir
de la cual la accesibilidad se puede deducir. Una vez que la información de accesibilidad para un
sistema autónomo completo se ha ensamblado, uno de los routers en el sistema puede anunciarlo a
otros sistemas autónomos utilizando EGP.
Un solo router puede utilizar simultáneamente 2 protocolos de ruteo diferentes, uno para la
comunicación al exterior del sistema autónomo y otro para la comunicación al interior del sistema
autónomo.
Protocolo SPF
La principal alternativa a los algoritmos de vector-distancia es una clase de algoritmos conocidos
como enlace estado, Shortest Path First (SPF). Estos algoritmos requieren que cada router
participante tenga información de la topología completa.
En lugar de enviar un mensaje que contenga una lista de destinos, un router que participa en un
algoritmo SPF desempeña dos tareas. En primer lugar, prueba activamente el estado de todos los
routers vecinos. En segundo lugar difunde periódicamente la información del estado del enlace hacia
otros routers.
Para informar a los otros routers, cada router difunde periódicamente un mensaje que lista el estado
de cada uno de estos enlaces. Estos mensajes no especifican rutas, sólo si es posible la comunicación
entre pares de routers.
Cada vez que llega un mensaje de estado de enlace, un router utiliza la información para actualizar su
mapa de la red. Cada vez que cambia el estado de un enlace, el router computa de nuevo las rutas
aplicando el algoritmo de Dijkstra de la ruta más corta al grafo resultante.
Una de las ventajas es que cada router computa trayectorias independientes, utilizando la misma
información de estado original. Como los routers realizan el cálculo de rutas de manera local, la
convergencia está garantizada. Por último, dado que los mensajes de estado de enlace sólo
transportan información sobre conexiones directas desde un solo router, su tamaño no depende del
número de redes en la red. De esta forma los algoritmos SPF se extienden mejor que los algoritmos
de vector-distancia.
27/70
Teleprocesos y Redes 2
Protocolo OSPF
OSPF incluye un ruteo por tipo de servicio. Los administradores pueden instalar múltiples rutas hacia
un destino dado, uno por cada tipo de servicio (por ejemplo, retardo bajo, rendimiento alto). Cuando
se rutea un datagrama, un router que corre OSPF utiliza la dirección de destino y el IP para
seleccionar una ruta. El OSPF está entre los primeros protocolos TCP/IP que ofrecen un ruteo por tipo
de servicio.
OSPF proporciona balance de carga. Si un administrador especifica múltiples rutas hacia un destino
dado con el mismo costo, OSPF distribuye el trafico entre todas las rutas de la misma manera.
Protocolos como RIP calculan una sola ruta para cada destino.
OSPF permite que una localidad divida sus redes y routers en subconjuntos llamados áreas. Cada
área es autónoma; el conocimiento de la topología de un área se mantiene oculto para las otras
áreas.
El protocolo OSPF especifica que todos los intercambios entre routers deben ser autenticados.
OSPF soporta rutas específicas para hosts y sub redes así como rutas específicas de red.
Permite a los routers intercambiar información de ruteo aprendida desde otras localidades
(externas). Básicamente uno o más routers con conexiones hacia otras localidades reciben
información sobre éstas y la incluyen cuando envían mensajes de actualización. El formato de
mensaje distingue entre información adquirida de fuentes externas e información adquirida de
routers en el interior de la localidad, para evitar ambigüedad acerca de la fuente o de la confiabilidad
de las rutas.
Formato del Mensaje OSPF:
VERSION
LONG. DEL MENSAJE
TIPO
DIR IP DEL ROUTER FUENTE
AREA ID
CHECKSUM
TIPO DE AUTENTICACION
AUTENTICACION
AUTENTICACION
VERSION: Especifica la versión del protocolo.
TIPO: Identifica el tipo de mensaje según lo siguiente
-
1: Hello (Se utiliza para pruebas de accesibilidad).
2: Descripción de base de datos (topología)
3: Solicitud de estado de enlace.
4: Actualización de estado de enlace.
5: Acuse de recibo de estado de enlace.
DIRECCION IP ROUTER FUENTE: Tiene la dirección de emisor.
AREA ID: Tiene el número de identificación de 32 bits para el área.
TIPO DE AUTENTICACIÓN: Dado que cada mensaje puede incluir la autenticación, este campo
especifica qué esquema de autenticación se está utilizando (actualmente, 0 significa que no se está
empleando ninguna autenticación y 1 que se está usando una simple clave de acceso)
28/70
Teleprocesos y Redes 2
1) Formato del mensaje Hello de OSPF
OSPF envía periódicamente mensajes Hello en cada enlace para establecer y probar la accesibilidad
del vecino.
ENCABEZADO OSPF CON TIPO = 1
MASCARA DE RED
HELLO INTER
DEAD TIMER
GWAY PRIO
DIR IP DEL ROUTER FUENTE
AREA ID
CHECKSUM
TIPO DE AUTENTICACION
AUTENTICACION
AUTENTICACION
MASCARA DE RED: Contiene la máscara de red sobre la cual se esta enviando el mensaje.
DEAD TIMER: Contiene el tiempo en segundos después del cual se considera sin actividad a un vecino
que no responde.
HELLO INTER: Es el período normal en segundos, entre mensajes Hello.
GWAY PRIO: Es un entero que señala la prioridad del router y se utiliza en la selección de un router
designado de respaldo
ROUTER DESIGNADO y ROUTER DE RESPALDO: Contiene las direcciones IP que proporcionan la visión
del emisor del router designado y del router de respaldo para la red sobre la que está enviando el
mensaje.
DIRECCION IP DE VECINOn: Contiene las direcciones IP de todos los vecinos de los que el emisor ha
recibido recientemente mensajes Hello.
2) Formato del mensaje de Descripción de la Base de Datos del OSPF
Los routers intercambian mensajes de descripción de la base de datos para iniciar su base de datos
de la topología de red. En el intercambio, un router sirve como maestro, mientras que otro es
esclavo. El esclavo envía acuses de recibo de cada mensaje de descripción de base de datos con una
respuesta. Dado que la base de datos puede ser extensa, puede dividirse en varios mensajes
utilizando los bits I y M.
ENCABEZADO OSPF CON TIPO = 2
DEBE SER CERO
I
M
S
NUMERO DE SECUENCIA DE BASE DE DATOS
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
NUMERO DE SECUENCIA DE ENLACE
CHECKSUM
LINK AGE
…
29/70
Teleprocesos y Redes 2
I: Se setea a 1 en el mensaje inicial.
M: Se setea a 1 si hay mensajes adicionales.
S: Indica si el mensaje fue enviado por un maestro (valor 1) o por un esclavo (valor 0).
NUMERO DE SECUENCIA DE BASE DE DATOS: Numera los mensajes secuencialmente, así el receptor
puede saber si uno está equivocado. El mensaje inicial contiene un número aleatorio y los mensajes
siguientes contienen enteros en secuencia que comienzan con R.
TIPO DE ENLACE: describe un enlace según la siguiente tabla:
- 1: Enlace de router.
- 2: Enlace de red.
- 3: Resumen de enlace (red IP)
- 4: Resumen de enlace (enlace para router de frontera)
- 5: Enlace externo (enlace hacia otras localidades)
ENLACE ID: Contiene la identificación para el enlace (puede ser la dirección IP de un router o una red,
dependiendo del tipo de enlace).
ADVERTISING ROUTER: Especifica la dirección del router que anuncia este enlace.
NUMERO DE SECUENCIA DE ENLACE: proporciona otra garantía de que la información del enlace no
se ha alterado.
LINK AGE: Contiene el tiempo en segundos desde que el enlace fue establecido (ayuda a ordenar los
mensajes)
Los campos resaltados, describen un enlace en la topología de red y se repiten por cada enlace.
3) Formato del mensaje de Solicitud de Estado de Enlace de OSPF
Luego de intercambiar mensajes de descripción de bases de datos con un vecino, un router puede
descubrir que algunas partes de su base de datos están fuera de fecha. Para solicitar que el vecino
proporcione información actualizada, el router envía un mensaje de solicitud de estado de enlace. El
mensaje lista enlaces específicos y el vecino responde con la información más actualizada que tiene
en relación a estos enlaces.
ENCABEZADO OSPF CON TIPO = 3
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
…
4) Formato del mensaje de Actualización de Estado de Enlace OSPF
Los routers difunden el estado de enlace como un mensaje de actualización de estado de enlace.
Cada actualización consiste en una lista de anuncios con la siguiente forma:
ENCABEZADO OSPF CON TIPO = 4
NUMEROS DE ANUNCIOS DE ESTADO DE ENLACE
ANUNCIO DE ESTADO DE ENLACE1
…
ANUNCIO DE ESTADO DE ENLACESn
30/70
Teleprocesos y Redes 2
Cada anuncio de estado de enlace tiene un formato de encabezado como el siguiente:
LINK AGE
TIPO DE ENLACE
ID DE ENLACE
ADVERTISING ROUTER
NUMERO DE SECUENCIA DE ENLACE
CHECKSUM
LINK AGE
El valor utilizado en cada campo es el mismo que en el mensaje de descripción de base de datos.
A continuación del encabezado de estado de enlace, se incluye uno de cuatro posibles formatos para
describir el enlace desde un router hacia un área dada, el enlace desde un router hacia una red
específica, el enlace desde un router hacia una red física que comprende una sola subred de una red
IP o un enlace desde un router hacia una red en otra localidad. En todos los casos el campo TIPO DE
ENLACE en el encabezado de estado de enlace especifica cuál de los formatos de ha utilizado. Así, un
router que recibe un mensaje de actualización de estado de enlace sabe exactamente cuál de los
destinos se ubica dentro de la localidad y cuales son externos.
Ruteo con información parcial
Los hosts pueden rutear con información parcial porque dependen de los routers. Está claro que
todos los routers tienen información completa. La mayor parte de los sistemas autónomos tienen un
solo router que forma un puente al conectar el sistema autónomo con otros sistemas autónomos.
Los routers dentro del sistema autónomo tienen conocimiento sobre los destinos dentro de este
sistema autónomo, pero éstos rutearán el tráfico restante hacia el puente.
Los routers núcleo tienen un conjunto completo de rutas hacia todos los destinos posibles; éstos no
utilizan el ruteo por omisión. Los routers no-nucleo usualmente no tienen un conjunto completo de
rutas; éstos dependen de una ruta por omisión para manejar direcciones de redes que no entienden.
Utilizar rutas por omisión para la mayor parte de los routers no-nucleo tiene dos consecuencias.
Primero, significa que los errores de ruteo locales podrían no detectarse. Por ejemplo, si una
máquina en un sistema autónomo rutea incorrectamente un paquete hacia un sistema autónomo
externo en lugar de hacerlo hacia un router local, el sistema externo lo ruteará de regreso
(posiblemente enviando un mensaje de redireccionamiento ICMP hacia la fuente original). En
segundo lugar, por el lado positivo, tener rutas por omisión significa que el mensaje de actualización
de ruteo será mucho más pequeño que las actualizaciones de ruteo utilizadas en un sistema núcleo.
PROTOCOLOS DE ROUTING EXTERNO: BGP (BORDER GATEWAY PROTOCOL)
Introducción
Los protocolos de ruteo externo son los que se utilizan para interconectar Sistemas Autónomos. En
los protocolos de ruteo interno la prioridad era buscar rutas optimas atendiendo únicamente al
criterio de minimizar la “distancia” medida en términos de la métrica elegida para la red.
La selección de rutas entre sistemas autónomos plantea un problema diferente, ya que la cuestión
no se reduce a la selección de la ruta optima sino que se debe atender a criterios externos de tipo
político, económico, administrativo, etc.
Hasta 1990 se utilizaba como protocolo de ruteo externo en la Internet el denominado EGP (Exterior
Gateway Protocol). Este protocolo no fue capaz de soportar el crecimiento de la Red y entonces se
desarrollo un nuevo protocolo de ruteo externo denominado BGP.
31/70
Teleprocesos y Redes 2
BGP es un protocolo de transporte fiable. Esto elimina la necesidad de llevar a cabo la fragmentación
de actualización explícita, la retransmisión, el reconocimiento, y secuenciación.
Funciones de BGP
BGP se diseño para permitir el intercambio de información de encaminamiento entre routers en
sistemas autónomos diferentes. El protocolo opera en términos de mensajes, que se envían
utilizando TCP. El repertorio de mensajes es el siguiente:
1.- OPEN
2.- UPDATE
3.- KEEPALIVE
4.- NOTIFICACION
BGP supone tres procedimientos funcionales:
-
Adquisición de vecino.
Detección de vecino alcanzable.
Detección de red alcanzable.
Dos routers se considera que son vecinos si están en la misma subred. Si los dos routers están en
sistemas autónomos diferentes, podrían desear intercambiar información de encaminamiento. Para
esto es necesario realizar primero el proceso de adquisición de vecino. Se requiere un mecanismo
formal de encaminamiento ya que alguno de los dos vecinos podría no querer participar. Existirán
situaciones en las que un vecino no desee intercambiar información esto se puede deber a múltiples
factores como por ejemplo que este sobresaturado y entonces no quiere ser responsable del tráfico
que llega desde fuera del sistema.
En el protocolo de adquisición de vecino, un dispositivo envía un mensaje de petición al otro, el cual
puede aceptar o rechazar el ofrecimiento. El protocolo no indica como puede saber un router la
dirección o incluso la existencia de otro router. Estas cuestiones se tratan en el momento de
establecer la configuración del sistema o por una intervención activa del gestor de la red.
Para llevar a cabo la adquisición de vecino, un router envía al otro un mensaje OPEN. Este mensaje
identifica al AS al que pertenece el emisor y suministra la dirección IP del router. Si el otro router
acepta la relación, envía un mensaje de KEEPALIVE.
Una vez establecida la relación de vecino, se utiliza el procedimiento de detección e vecino
alcanzable para mantener la relación. Este procedimiento consiste en enviarse entre los dos vecinos
periódicamente mensajes de KEEPALIVE para asegurarse de que la relación sigue establecida.
El último procedimiento especificado por BGP es la detección de red alcanzable. Cada router
mantiene una base de datos con las redes que puede alcanzar y la ruta preferida para llegar hasta
esa red. Siempre que se realiza un cambio en esa base de datos, el dispositivo de almacenamiento
envía un mensaje de UPDATE por difusión a todos los router que implementan BGP.
Formato de Mensajes BGP
Los mensajes BGP tienen una cabecera común que contiene los siguientes tres campos:
-
MARKER: reservado para autentificación. El emisor puede insertar un valor en este campo
para permitir al receptor comprobar la veracidad del emisor.
LONGITUD: longitud del mensaje en bytes.
TIPO: tipo de mensaje: OPEN, UPDATE, NOTIFICATION, KEEPALIVE.
32/70
Teleprocesos y Redes 2
1) Mensaje OPEN.
Para adquirir un vecino, un router abre primero una conexión TCP con el dispositivo vecino y después
envía un mensaje OPEN. Este mensaje identifica al AS al que pertenece el emisor y suministra la
dirección IP del router.
En la siguiente figura se muestra el formato del mensaje OPEN:
Campo
Long (bytes)
MARKER
16
LONGITUD
2
TIPO
1
VERSION
1
AS
2
TIEMPO DE PERMANENCIA
2
IDENTIFICADOR DE BGP
4
LONGITUD OPCIONES
1
OPCIONES
Variable
VERSION: indica la versión del protocolo del mensaje. La versión actual es 4.
AS: identifica al sistema autónomo del emisor del mensaje.
TIEMPO DE PERMANENCIA: indica el tiempo de que propone el emisor como Hold Time.
IDENTIFICADOR DE BGP: identifica al BGP emisor.
2) Mensaje KEEPALIVE
El mensaje KEEPALIVE consta solo de la cabecera. Cada router envía regularmente estos mensajes
para evitar que expire el temporizador.
En la siguiente figura se muestra el formato del mensaje KEEPALIVE:
Campo
Long (bytes)
MARKER
16
LONGITUD
2
TIPO
1
3) Mensaje UPDATE
El mensaje UPDATE facilita dos tipos de información:
- Información sobre una ruta particular a través del conjunto de redes. Esa información se
puede incorporar a la base de datos de cada router que la recibe.
- Una lista de rutas previamente anunciadas por este router que van a ser eliminadas.
En la siguiente figura se muestra el formato del mensaje UPDATE:
Campo
MARKER
LONGITUD
TIPO
LONGITUD RUTAS NO FACTIBLES
Long (bytes)
16
2
1
2
33/70
Teleprocesos y Redes 2
RUTAS RETIRADAS
LONGITUD TOTAL ATRIBUTOS DE CAMINO
ATRIBUTOS DE CAMINO
INFORMACION DE ACCESIBILIDAD DE LA CAPA DE RED
Variable
2
Variable
Variable
Un mensaje UPDATE puede contener uno o ambos tipos de información. Consideremos primero el
tipo de información 1. La información sobre una ruta particular a través de la red implica tres
campos, campo INFORMACION DE ACCESIBILIDAD DE LA CAPA DE RED (NLRI), LONGITUD TOTAL
ATRIBUTOS DE CAMINO, y el campo ATRIBUTOS DE CAMINO. El campo NLRI contiene una lista de
identificadores de redes que se pueden alcanzar por esta ruta. Cada red se identifica por su dirección
IP, que es en realidad una parte de la dirección IP completa.
El campo atributos de camino contiene una lista de atributos que se aplican a esta ruta particular. Los
atributos definidos son los siguientes:
-
-
Origen: indica si la información fue generada por un protocolo de router interior o exterior.
Camino_AS: una lista de los AS que son atravesados por la ruta.
Siguiente_salto: dirección IP del router frontera que se debe usar como siguiente salto para
alcanzar los destinos indicados en el NLRI.
Multi_exit_disc: se usa para comunicar alguna información sobre rutas internas a un AS.
Local_pref: usado por un router para informar a otros router dentro del mismo AS de su
grado de preferencia por una ruta particular. No tiene significado alguno para routers en
otros AS.
Agregado_atomico, Agente_union: estos dos campos implementan el concepto de unión de
rutas. En esencia, un conjunto de redes y su espacio de direcciones correspondiente se
pueden organizar jerárquicamente, o como un árbol. En este caso las direcciones de las redes
se estructuran en dos o más partes. Todas las redes de un subarbol comparten una dirección
internet parcial común. Usando esta dirección parcial común, la cantidad de información que
se debe comunicar en NLRI se pude reducir significativamente.
El atributo Camino_AS sirve realmente para dos objetivos. Ya que indica los AS que debe atravesar un
datagrama si sigue esta ruta. La información de camino_AS habilita a un router a que implemente un
criterio de ruteo. Esto es, un router puede construir un camino para pasar por un determinado AS.
4) Mensaje NOTIFICATION
Se envían cuando se detecta algún tipo de error. Se puede informar de los siguientes tipos de
errores:
-
-
-
Error en la cabecera del mensaje: incluye errores de sintaxis y autentificación.
Error en mensaje OPEN: incluye errores de sintaxis y opciones no reconocidas en un mensaje
OPEN. Este mensaje también se puede utilizar para indicar que el tiempo de mantenimiento
en el mensaje OPEN es inaceptable.
Error en el mensaje UPDATE: incluye errores de sintaxis y validación en un mensaje UPDATE.
Tiempo de mantenimiento expirado: si el router que envía no recibe mensajes sucesivos de
KEEPALIVE y/o UPDATE y/o NOTIFICATION durante el tiempo de mantenimiento, entonces se
comunica este error y se cierra la conexión.
Error en la máquina de estados finitos: incluye cualquier error de procedimiento.
Cese: utilizado por un router para cerrar una conexión con otro router en ausencia de
cualquier otro error.
34/70
Teleprocesos y Redes 2
En la siguiente figura se muestra el formato del mensaje NOTIFICATION:
Campo
MARKER
LONGITUD
TIPO
CODIGO ERROR
SUBCODIGO DE ERROR
DATOS
Long (bytes)
16
2
1
1
1
Variable
El subcódigo de error nos da mas información sobre el error.
35/70
Teleprocesos y Redes 2
IGMP – MULTIDIFUSION INTERNET
Difusión por hardware
La entrega por difusión significa que la red entrega una copia de un paquete para cada destino. En
Ethernet, esto puede completarse con la transmisión de un solo paquete. En redes compuestas por
conmutadores con conexiones punto a punto, el software tiene que implantar la difusión enviando
copias de los paquetes a través de conexiones individuales hasta que todas las computadoras han
recibido una copia.
En el caso de la mayor parte del hardware, el usuario especifica la entrega por difusión enviando el
paquete hacia una dirección de destino especial y reservada, llamada dirección de difusión. La
principal desventaja, es que toda difusión consume recursos en todas las máquinas.
Multidifusión por hardware
Algunas tecnologías de hardware soportan una segunda forma de entrega multipunto, llamada
multidifusión. A diferencia de la difusión, la multidifusión permite que cada máquina elija si quiere
participar en ella. Cuando un grupo de máquinas quiere comunicarse selecciona una dirección de
multidifusión en particular para utilizarla durante la comunicación. Luego de configurar el hardware
de interfaz de red, para conocer la dirección de multidifusión seleccionada, todas las máquinas en el
grupo recibirán una copia de cada paquete enviado hacia tal dirección de multidifusión.
Multidifusión IP
La multidifusión IP permite la transmisión de un datagrama IP a un conjunto de hosts que forman un
solo grupo de multidifusión. La multidifusión IP emplea el mismo concepto de entrega con el mejor
esfuerzo que en otras entregas IP, esto significa que los datagramas de multidifusión pueden
perderse, borrarse, duplicarse o entregarse sin orden.
La pertenencia a un grupo de multidifusión IP es un proceso dinámico. Un anfitrión puede unirse o
abandonar un grupo en cualquier momento. Además, un host puede ser miembro de un número
indeterminado de grupos de multidifusión. Cada grupo de multidifusión tiene una dirección de
multidifusión única de clase D.
La multidifusión IP puede utilizarse en una sola red física o a través de una red de redes. En éste
ultimo caso, routers de multidifusión especiales enviarán los datagramas de multidifusión.
Direcciones de Multidifusión IP
La multidifusión IP usa direcciones Clase D. Los primeros 4 bits contienen 1110 e identifican la
dirección como una multidifusión. Los 28 bits restantes especifican un grupo de multidifusión
particular. No hay estructura en el grupo de bits. En particular, el campo de grupo, no contiene una
dirección de red como en las direcciones clase A, B y C.
224.0.0.0 a 239.255.255.255
La dirección 224.0.0.0 esta reservada; no se puede asignar a ningún grupo. Además, la dirección
224.0.0.1 está asignada permanentemente al grupo de todos los hosts, el cual incluye todos los hosts
y routers que participan en la multidifusión IP. En general, esta dirección se utiliza para alcanzar
todas las máquinas que participan en la multidifusión IP en una red local; no hay direcciones que
hagan referencia a todos los hosts en todas las redes.
Las direcciones de multidifusión solo pueden emplearse como direcciones de destino.
36/70
Teleprocesos y Redes 2
Transformación de Multidifusión IP en Multidifusión Ethernet
Para transformar una dirección de multidifusión IP en su correspondiente dirección de multidifusión
Ethernet, colocar los 23 bits de orden menor de la dirección de multidifusión IP dentro de los 23 bits
de orden inferior de la dirección (hardware) de multidifusión Ethernet especial 01.00.5E.00.00.0016.
Puede verse que la transformación no es única. La consecuencia de este diseño es que algunos
datagramas de multidifusión puede recibirse en un host, aunque no estén destinados a tal host.
Extensión de IP para manejar la Multidifusión
Un host participa en una multidifusión IP en uno de tres niveles.
0: El host no puede ni enviar ni recibir multidifusión IP.
1: El host puede enviar pero no recibir multidifusión IP.
2: El host puede enviar y recibir multidifusión IP.
El software IP debe permitir a un programa de aplicación especificar una dirección de multidifusión
como una dirección IP de destino y el software de interfaz de red debe ser capaz de transformar una
dirección de multidifusión en la correspondiente dirección de multidifusión de hardware (o utilizar la
difusión si el hardware no soporta la multidifusión).
Ampliar el software del host para recibir datagramas de multidifusión es más complejo. El software IP
en el host debe tener una interfaz que permita a un programa de aplicación declarar si desea unirse
o abandonar un grupo de multidifusión en particular. Si diversos programas de aplicación se unen al
mismo grupo, IP debe recordar cada uno de ellos para transferir una copia de los datagramas que
llegan destinados para este grupo. Si todos los programas de aplicación abandonan un grupo, el host
debe recordar que no quedan participantes en el grupo. Además, el host tiene que correr un
protocolo que informe a los routers de multidifusión local del estado de los miembros de un grupo.
La complejidad radica en: los hosts se unen a un grupo de multidifusión IP específicos en redes
específicas. Esto es, un host con diversas conexiones de red puede unirse a un grupo de multidifusión
en una red y no en otra.
IGMP – Protocolo de Gestión de Grupos en Internet
Para participar en la multidifusión dentro de una red local, un host debe tener el software que le
permita enviar y recibir datagramas de multidifusión. Para participar en una multidifusión que cubra
varias redes, el host debe informar a los routers de multidifusión local. El router local se pone en
contacto con otros routers de multidifusión, pasando información hacia los miembros y
estableciendo rutas.
Antes de que un router de multidifusión pueda difundir información a los miembros, debe
determinar si uno o más hosts de la red local han decidido unirse a un grupo de multidifusión, para
esto deben utilizar el protocolo IGMP (Internet Group Management Protocolo) para comunicar
información a los miembros del grupo.
IGMP utiliza datagramas IP para transportar mensajes y proporciona un servicio utilizado por IP.
IGMP tiene dos fases. Fase 1: Cuando un host se une a un nuevo grupo envía un mensaje IGMP para
la dirección de multidifusión “todos los hosts”, declarando su membresía. Los routers de
multidifusión local reciben el mensaje y establecen el ruteo necesario para difundir la información de
membresía del grupo hacia otros routers de multidifusión a través de la red. Fase 2: Debido a que la
membresía es dinámica, los routers de multidifusión local muestrean de manera periódica a los hosts
en la red local para determinar qué hosts se mantienen como miembros de qué grupos. Si en un
grupo no se reportan miembros después de varios muestreos, el router asume que no hay hosts en la
red que se mantengan en el grupo y deja de anunciar miembros del grupo a otros routers de
multidifusión.
37/70
Teleprocesos y Redes 2
Implementación IGMP
IGMP esta diseñado para evitar congestionamientos en la red local. En primer lugar, toda la
comunicación entre hosts y routers de multidifusión utilizan multidifusión IP. Esto es, cuando los
mensajes IGMP están encapsulados en un datagrama IP para su transmisión, la dirección de IP de
destino es la dirección de multidifusión de todos los hosts. Así, los datagramas que transportan
mensajes IGMP son transmitidos mediante hardware de multidifusión si éste esta disponible. Como
resultado, en las redes en las que el hardware soporta la multidifusión, los anfitriones que no
participan en la multidifusión IP nunca reciben mensajes IGMP. En segundo lugar, un router de
multidifusión no enviará mensajes de solicitud individuales para cada grupo de multidifusión, sino un
mensaje de muestreo para solicitar información relacionada con la membresía en todos los grupos.
La cantidad de muestreos está restringida, a lo sumo, una solicitud por minuto. En tercer lugar, los
hosts que son miembros de varios grupos no envían respuestas múltiples al mismo tiempo. Por el
contrario, luego de que un host recibe un mensaje de solicitud IGMP, el host separa sus respuestas
por un lapso aleatorio no mayor a 10 segundos. En cuarto lugar, los hosts escuchan las respuestas de
otros hosts y suprimen cualquiera de estas respuestas que sea innecesaria. Esto es porque los
routers de multidifusión sólo necesitan saber si al menos un host en la red sigue siendo miembro del
grupo. Luego de que un router envia un mensaje de muestreo, todos los hosts asignan un retardo
aleatorio para la respuesta. Cuando el host con el retardo más pequeño envía una respuesta
(mediante multidifusión), otros hosts participantes reciben una copia. Cada host asume que el router
también recibió una copia de la respuesta y cancelan sus respuestas. Así, en la práctica, sólo un host
de cada grupo responde a un mensaje de solicitud del router.
Transiciones del estado de la Membresía de Grupo: El IGMP debe recordar el estado de cada grupo
de multidifusión al que el host pertenece. Cada vez que un programa de aplicación en el host se une
a un nuevo grupo, el software IGMP asignará un espacio y lo llenará con información acerca del
grupo. Dentro de dicha información, el IGMP establecerá un contador de referencia de grupo, el cual
se inicia en 1. Si aplicaciones adicionales se unen al grupo, el IGMP incrementará el contador de
referencia. Conforme los programas de aplicación abandonan el grupo, IGMP decrementa el
contador. El host deja el grupo de multidifusión cuando el contador llega a cero.
Formato del mensaje IGMP
VER
TYPE
SIN USO
CHECKSUM
DIRECCION DE GRUPO (CERO EN SOLICITUD)
VER: Versión del Protocolo.
TYPE: Identifica al mensaje como una solicitud enviada por un router de multidifusión (tipo 1) o como
una respuesta enviada por un host (tipo 2).
CHECKSUM: Contiene la suma de verificación. Se calcula de la misma forma que en IP.
DIRECCION DEL GRUPO: Los hosts utilizan este campo para reportar su membresía en un grupo de
multidifusión en particular (en una solicitud, este campo contiene ceros y no tiene ningún
significado).
Asignación de Direcciones de Multidifusión: El estándar no especifica exactamente cómo son
asignados los grupos de máquinas a las direcciones de multidifusión, pero una posibilidad es que se
forme aleatoriamente hasta descubrir una que no esté en uso. También es posible asignarla
manualmente.
38/70
Teleprocesos y Redes 2
Difusión de Información de ruteo: Aun cuando la multidifusión descrita es un estándar para TCP/IP,
no existe un estándar para la difusión de información de ruteo entre routers de multidifusión. Sin
embargo existe un protocolo experimental llamado Protocolo de Ruteo de Multidifusión Vector
Distancia, DVMRP. Los routers de multidifusión utilizan DVMRP para transferir información de
membresía entre ellos. Se valen de la información para establecer rutas y, así, entregar la copia de un
datagrama de multidifusión a todos los miembros del grupo.
Tunneling
Uno de los mayores problemas con la multidifusión se debe a que no todos los routers pueden enviar
datagramas de multidifusión. Mediante tunneling un routrer puede enviar datagramas de
multidifusión a través de routers intermedios que no manejen multidifusión.
De hecho, el tunneling consiste en un acuerdo entre dos routers. Cada router escucha en su red local
si existen datagramas enviados hacia el grupo de multidifusión para los que el túnel está configurado.
Cuando un datagrama de multidifusión llega y la dirección de destino corresponde a la del túnel, se
envía el datagrama al otro router empleando una dirección de unidifusión IP convencional. Cuando
se recibe un datagrama de unidifusión a través del túnel, se extrae el datagrama de multidifusión y
entonces utiliza el hardware de multidifusión para entregar el datagrama a las computadoras de la
red local.
Para lograr esto, el datagrama de multidifusión, incluyendo el encabezado, viaja dentro de un
datagrama de unidifusión convencional. El router receptor extrae y procesa el datagrama como si
llegara en una interfaz local.
BOOTP y DHCP – Arranque y Autoconfiguración
La Necesidad de una Alternativa a RARP
RARP tiene 3 inconvenientes:
-
Dado que RARP opera en un nivel bajo, su uso requiere de un acceso directo hacia el
hardware de red.
-
Aun cuando RARP necesita un intercambio de paquetes entre una máquina cliente y una
computadora que responda las solicitudes, la réplica contiene sólo una pequeña parte de la
información (la dirección IP del cliente). Esto trae problemas en redes Ethernet dado que se
impone un tamaño mínimo de paquete, ya que la información adicional puede enviarse en la
respuesta sin costo adicional (piggybacking).
-
Como RARP emplea una dirección de hardware de computadora para identificar una
máquina, no puede utilizarse en redes con una asignación dinámica de direcciones de
hardware.
BOOTP (BOOT-strap Protocol)
Dado que BOOTP utiliza UDP e IP, debe implementarse como un programa de aplicación. Como ARP,
BOOTP opera dentro de un paradigma cliente-servidor y requiere solo de un intercambio de
paquetes. No obstante BOOTP especifica muchos aspectos necesarios para el arranque además de la
dirección IP.
Utilización de IP para Determinar una Dirección IP
BOOTP se vale del UDP para transportar mensajes y los mensajes UDP están encapsulados en
datagramas IP para su entrega.
39/70
Teleprocesos y Redes 2
Para poder enviar un datagrama IP antes de que la computadora conozca su dirección IP, un
programa de aplicación puede utilizar la dirección IP de difusión límite (255.255.255.255) para
obligar al IP a difundir un datagrama en la red local, antes de que el IP haya descubierto la dirección
IP de la red local o la dirección IP de la máquina.
Política de Retransmisión BOOTP
BOOTP confiere toda la responsabilidad de la confiabilidad de la comunicación al cliente. Sabemos
que como UDP utiliza IP para la entrega, los mensajes pueden retrasarse, perderse, entregarse en
desorden, etc. Además, como IP no proporciona Checksum sobre los datos, por lo tanto, para
protegerse contra las alteraciones de datos, BOOTP requiere que UDP utilice Checksum. También
especifica que las solicitudes y las réplicas deben enviarse con el bit de NO FRAGMENT activado a fin
de que los clientes tengan una memoria pequeña para reensamblar los datagramas. BOOTP también
esta construido para permitir réplicas múltiples, las acepta y procesa primero.
Para manejar datagramas perdidos utiliza la técnica convencional de Time Out y Retransmisión. Por
supuesto, después de una falla generalizada, todas las máquinas de la red deben arrancar de nuevo
de manera simultánea, posiblemente sobrecargando el servidor BOOTP de solicitudes. Para evitar
esto implementa un retardo aleatorio de entre 0 y 4 segundos y va duplicando el temporizador
después de cada retransmisión hasta un máximo de 60 segundos.
OP: Especifica si el mensaje es una solicitud (valor 1) o una replica (valor 2).
HTYPE y HLEN: Al igual que en ARP, estos campos especifican el tipo de hardware de red y la longitud
de la dirección de hardware.
HOPS: El cliente inicializa este campo en 0. Si un servidor recibe la solicitud y por algún motivo decide
reenviarla hacia otro servidor, éste incrementara el valor de este campo.
TRANSACTION ID: contiene un entero que la máquina sin disco utiliza para cotejar las respuestas con
las solicitudes.
SECONDS: reporta el número de segundos desde que el cliente comenzó el arranque.
CLIENT IP ADDRESS: Un cliente que conozca su dirección IP la colocará en este campo; otros clientes
utilizarán cero en este campo. Si la dirección IP del cliente es cero en la solicitud, un servidor
devolverá la IP del cliente en el campo YOUR IP ADDRESS.
SERVER IP ADDRESS y SERVER HOST NAME: Si un cliente conoce el nombre o la dirección de un
servidor específico desde el que espera información, llena estos campos. Si estos campos no son
40/70
Teleprocesos y Redes 2
iguales a cero, sólo el servidor con el nombre-dirección que concuerde responderá la solicitud. Si los
campos están puestos en cero, responderá cualquier servidor que reciba la solicitud.
BOOT FILE NAME: Contiene un valor genérico, que BOOTP consultará en su base de datos, y
especifica que sistema operativo se desea correr.
VENDOR SPECIFIC AREA: contiene información opcional del vendedor para su transferencia del
servidor al cliente, de información utilizada solo en sus computadoras. Los primeros 4 bytes del
campo se llaman MAGIC COOKY y define el formato de los campos siguientes. A continuación de este
campo, sigue una lista de términos, en la que cada aspecto contiene un byte TIPO, un byte
LONGITUD opcional y varios bytes VALOR. Según el MAGIC COOKY 99.130.83.99 el formato es el
siguiente:
Procedimiento de Arranque de Dos Pasos
No proporciona una imagen de memoria a los clientes, solo proporciona al cliente información
necesaria para obtener una imagen. El cliente entonces utiliza un segundo protocolo para obtener la
imagen de memoria. Ej: TFTP. Aunque el procedimiento de dos pasos parase innecesario, permite
una clara separación de configuración y almacenamiento.
La necesidad de una configuración dinámica
BOOTP fue diseñado para un ambiente relativamente estático en el que cada host tiene una
conexión de red permanente. Un administrador crea un archivo de configuración que especifica un
conjunto de parámetros BOOTP para cada host. El archivo no cambia con frecuencia pues la
configuración por lo general se mantiene estable.
Con la llegada de redes inalámbricas y computadoras portátiles, se ha vuelto posible transportar
computadoras de una localidad a otra. BOOTP no se adapta fácilmente, dado que no incluye una
forma para asignar dinámicamente valores a máquinas individuales.
DHCP (Dynamic Host Configuration Protocol)
Para manejar la asignación de direcciones de manera automática, se creó un nuevo protocolo
conocido como DHCP, el cual extiende BOOTP de dos formas:
Permite que una computadora adquiera toda la información que necesita en un solo
mensaje.
- Permite que una computadora posea una dirección IP en forma rápida y dinámica.
Para utilizar el mecanismo de asignación de direcciones dinámico DHCP, un administrador debe
configurar un servidor DHCP suministrando un conjunto de direcciones IP. Cada vez que una
computadora nueva se conecta a la red, la computadora contacta al servidor y solicita una dirección.
El servidor selecciona una de las direcciones especificadas por el administrador y las asigna a la
computadora.
-
DHCP permite tres tipos de asignación de direcciones; un administrador selecciona cómo responderá
el DHCP a cada red o a cada host.
-
Configuración Manual: mediante el cual un administrador puede configurar una dirección
específica para un host específico.
41/70
Teleprocesos y Redes 2
Configuración Automática: de esta forma el administrador permite a un servidor DHCP
asignar una dirección permanente cuando una computadora se conecta por primera vez a la
red.
- Configuración Dinámica Completa: en la cual el servidor “presta” una dirección para un host
por un tiempo limitado.
El DHCP utiliza la identidad del cliente para decidir cómo proceder. Cuando un cliente conecta un
servidor DHCP, envía un identificador, por lo general, la dirección de hardware del cliente. El servidor
utiliza el identificador del cliente y la red a la que el cliente se ha conectado para determinar cómo
asignar el cliente y la dirección IP. Así, el administrador tiene un control completo sobre la forma en
que se asignan las direcciones. Un servidor puede configurarse para asignar direcciones a
computadoras específicas de manera estática (como BOOTP), mientras permite a otras
computadoras obtener dinámicamente direcciones de manera permanente o temporal.
-
Asignación Dinámica de Direcciones IP
DHCP permite a un host obtener todos los parámetros necesarios para la comunicación, sin la
intervención manual, también permite la auto configuración. Esta se encuentra sujeta, por supuesto,
a restricciones administrativas.
A diferencia de la asignación de direcciones estática, que asigna permanentemente cada dirección IP
a host específico, la asignación de direcciones dinámicas es temporal. El servidor DHCP especifica el
período de arrendamiento cuando asigna la dirección. Durante ese período el servidor no arrendará
la misma dirección a ningún otro cliente. Al final del período de arrendamiento, el cliente debe
renovar el arrendamiento o dejar de usar la dirección.
Para adaptarse a todos los ambientes, DHCP no especifica un período de arrendamiento fijo y
constante. De hecho, el protocolo permite que un cliente solicite un período de arrendamiento
específico y permite a un servidor informar al cliente que el período de arrendamiento está
garantizado. En el caso extremo, el DHCP reserva un valor infinito para permitir un arrendamiento
por un período de tiempo indeterminadamente largo, como si fueran direcciones permanentes.
Obtención de Direcciones Múltiples
Un host multi-homed está conectado a más de una red, cuando arranca, puede necesitar información
de configuración para cada una de sus interfaces. Un mensaje DHCP suele proporcionar información
acerca de una interfaz. Una computadora con varias interfaces debe manejar cada interfaz por
separado.
BOOTP y DHCP utilizan la noción de Relay Agent (Agente Retrasmisión) para permitir que una
computadora contacte un servidor en una red no local. Un agente de retransmisión retransmite los
mensajes DHCP y BOOTP que se difunden en una de las interfaces físicas a las que está conectado.
Formato de los mensajes DHCP
DHCP se vale del formato de mensaje BOOTP, pero modifica el contenido y el significado de algunos
campos. Casi todos los campos en un mensaje DHCP son idénticos a los de un mensaje BOOTP. De
hecho, los dos protocolos son compatibles; un servidor DHCP puede ser programado para responder
solicitudes BOOTP. Sin embargo DHCP cambia el significado de dos campos:
FLAGS: (Sin uso en BOOTP), de los 16 bits del campo sólo el bit de orden superior tiene asignado un
significado. El cliente activa este flag para solicitar que el servidor responda por medio de difusión en
lugar de la unidifusión de hardware. Esto se debe a que el datagrama IP que lleva la respuesta tiene
en su dirección de destino en su cabecera dirección IP fijada por el servidor DHCP, y la dirección MAC
a la dirección hardware del cliente DHCP. Si un host no puede recibir un datagrama IP en unicast
hasta saber su propia dirección IP, el bit de broadcast se debe poner a 1 para indicar al servidor que
el mensaje DHCPREPLY se debe enviar como un broadcast en IP y MAC. De otro modo, este bit debe
ponerse a cero.
42/70
Teleprocesos y Redes 2
OPTION: Este campo tiene el mismo formato que la VENDOR SPECIFIC AREA, asimismo DHCP acepta
todos los temas de vendedores específicos definidos para BOOTP. Los primeros cuatro bytes del
campo de opciones del mensaje DHCP contienen el magic cookie (99.130.83.99). El resto del campo
de opciones consiste en parámetros marcados llamados opciones.
El siguiente es el formato de una opción de tipo de mensaje del DHCP utilizado para especificar el
mensaje DHCP que se está enviando.
La siguiente tabla muestra los posibles valores para el tercer byte y sus significados:
1
Tipo de mensaje DHCP
correspondiente
DHCPDISCOVER
2
DHCPOFFER
3
DHCPREQUEST
4
DHCPDECLINE
5
DHCPACK
6
DHCPNAK
7
DHCPRELEASE
Valor
Función
Difusión del cliente para localizar los servidores disponibles.
Servidor al cliente en respuesta a DHCPDISCOVER con los parámetros de la
configuración.
Mensaje del cliente a los servidores. El cliente selecciona la configuración de
los paquetes recibidos de DHCPOFFER.
Lo envía el cliente al servidor cuando detecta un problema con los parámetros
en el mensaje DHCPACK y reinicia el proceso de configuración.
El servidor confirma el pedido y lo publica masivamente en la subred.
El servidor envía al cliente un mensaje indicando que el contrato ha terminado
o que la dirección IP asignada no es válida.
Cliente al servidor que abandona la dirección de red y que cancela el arriendo
restante.
Opción Overload: Cuando esta presente esta opción, indica al receptor que debe ignorar el
significado de los capos SERVER HOST NAME y BOOT FILE NAME y que debe considerar las opciones
que están en lugar de los campos.
Estados de Adquisición de Direcciones
Cuando un cliente arranca por primera vez, entra en estado INITIALIZE. Para comenzar a adquirir una
dirección IP, el cliente primero contacta a todos los servidores DHCP en la red local. Para hacerlo, el
cliente difunde un mensaje DHCPDISCOVER y cambia al estado con el nombre SELECT. Todos los
servidores DHCP de la red local reciben el mensaje y los servidores que hayan sido programados para
responder a un cliente en particular enviarán un mensaje DHCPOFFER.
Mientras permanece en estado SELECT, el cliente reúne respuestas DHCPOFFER. Cada oferta
contiene información de configuración para el cliente junto con la dirección IP que el servidor ofrece
para arrendar al cliente. El cliente debe seleccionar una de las respuestas y negociar con el servidor
43/70
Teleprocesos y Redes 2
un arrendamiento. Para ello, el cliente envía al servidor un mensaje DHCPREQUEST y entra al estado
REQUEST. El servidor envía un DHCPACK para enviar un acuse de recibo y comenzar el
arrendamiento. Esto hace que el cliente cambie al estado BOUND, en el cual el cliente procede a
utilizar la dirección.
Un cliente en estado BOUND, puede terminar un arrendamiento en forma temprana, con lo cual
envía un mensaje DHCPRELEASE al servidor.
Cuando un cliente entra al estado BOUND, éste instala tres temporizadores que controlan la
renovación de arrendamiento, la reasignación y la expiración. Un servidor DHCP puede especificar
valores explícitos para los temporizadores; si no asigna valores el cliente utilizará valores por
omisión. El valor por omisión para el primer temporizador es la mitad del tiempo que tarda el
arrendamiento. Cuando el primer temporizador expira, el cliente debe lograr la renovación de su
arrendamiento. Para solicitar una renovación, el cliente envía un mensaje DHCPREQUEST hacia el
servidor de donde obtuvo el arrendamiento. El cliente entonces cambia al estado RENEW en espera
de una respuesta. Como en la negociación inicial de arrendamiento, un cliente puede solicitar un
período para la extensión. Un servidor puede responder a una solicitud de renovación de dos formas:
puede pedirle al cliente que deje de usar la dirección o aprobar que la continúe utilizando. Si se
aprueba esto último, el servidor envía un DHCPHACK, el cual hace que le cliente regrese al estado
BOUND y continúe utilizando la dirección. Si un servidor desaprueba que se continúe utilizando la
dirección, el servidor enviará un DHCPNACK, el cual hace que el cliente deje de utilizar la dirección
inmediatamente y regrese al estado INITIALIZE.
Si el cliente no llegase a recibir una respuesta al mensaje que envió, el servidor se considera inactivo
o inaccesible. Para manejar esta situación, se utiliza el segundo temporizador. Este temporizador
expira luego que se cumple el 87,5% del período de arrendamiento y hace que el cliente pase a
estado REBIND. Cuando pasa a este estado comienza a difundir nuevamente un mensaje
DHCPREQUEST hacia cualquier servidor local. Cualquier servidor configurado puede responder de
manera positiva (para extender el arrendamiento) o negativamente (para evitar que siga usando su
IP). Si recibe una respuesta positiva, el cliente vuelve al estado BOUND y reinicializa los
temporizadores. Si recibe una respuesta negativa, debe cambiar a estado INITIALIZE, deja de usar su
dirección IP y debe adquirir una nueva IP antes de seguir utilizando IP.
En el caso de que el cliente no reciba una respuesta de ningún servidor, el arrendamiento expirará. El
cliente debe dejar de utilizar su dirección IP, y regresar al estado INITIALIZE y comenzar la adquisición
de una dirección IP nueva.
44/70
Teleprocesos y Redes 2
DNS – Domain Name System
Espacio de Nombres Plano
Cada nombre consistía en una secuencia de caracteres sin ninguna estructura adicional. En el
esquema original, una localidad central (NIC) administraba el espacio de nombres y determinaba si
un nombre nuevo era apropiado.
Ventajas: Los nombres eran convenientes y cortos.
Desventajas: El espacio de nombres no podía generalizarse para grandes conjuntos de máquinas por
razones técnicas y administrativas.
-
Como los nombres se construyen desde un solo conjunto de identificadores, la posibilidad de
conflicto se incrementa.
Dado que la autoridad es centralizada, la sobrecarga de trabajo administrativo se incrementa.
Como los nombres cambian con frecuencia, es elevado el costo de mantener copias correctas
de las listas correctas en cada localidad.
Al estar la base de datos de nombres centralizada, el tráfico de red sobre la misma se
incrementaría.
Nombres Jerárquicos
Consiste en la descentralización del mecanismo de asignación de nombres, mediante el cual se
delega la autoridad de partes del espacio de los nombres y se reparte la responsabilidad de la
traducción de nombres y direcciones.
Características principales
-
De propósito general: Se puede usar para resolver nombres a cualquier serie de
identificadores.
Eficiente: La mayoría de los problemas no requieren de mucho tráfico.
Distribuido: Información distribuida y Administraciones independientes.
Delegar la autoridad para los nombres
El espacio de nombres es particionado en el nivel superior y delega la autoridad a cada división. La
sintaxis de asignación jerárquica de nombres casi siempre refleja la delegación jerárquica de la
autoridad utilizada para asignarlos:
local.localidad
donde localidad es el nombre de la localidad autorizada por la unidad central, local es la parte del
nombre controlado por la localidad. Se utiliza el punto como delimitador de separación.
Autoridad para los subconjuntos de nombres
En un espacio jerárquico de nombres, la autoridad puede ser subdividida en cada nivel. La idea es
conservar subdividido el espacio de nombres hasta que cada subdivisión sea lo suficientemente
pequeña como para que se pueda manejar.
En una red TCP/IP, la jerarquía de nombres se asigna de acuerdo con la estructura de la organización
que obtiene autoridad para dividir el espacio de nombres y no necesariamente de acuerdo con la
estructura de las interconexiones de red física. Aunque en muchas localidades la jerarquía
organizacional corresponde a la estructura de las interconexiones físicas de la red.
45/70
Teleprocesos y Redes 2
Nombres de dominio TCP/IP de Internet
El mecanismo que implementa una jerarquía de nombres de máquina para las redes TCP/IP se
conoce como Domain Name System (DNS). El DNS tiene dos aspectos conceptuales diferentes. El
primero es abstracto. Especifica la sintaxis del nombre y las reglas para declarar la autoridad respecto
a los nombres. El segundo es concreto: Especifica la implementación de un sistema distribuido que
transforma eficientemente los nombres en direcciones.
caece.edu.ar
En el ejemplo, el dominio de nivel inferior es caece.edu.ar, el segundo nivel del dominio es edu.ar, y
el nivel superior es ar. Los nombres de dominio están escritos con la etiqueta local primero y el
dominio superior al último.
Nombres de dominio oficiales y no oficiales de Internet
El estándar de nombres especifica un espacio de nombre jerárquico abstracto con valores arbitrarios
para las etiquetas. Como el sistema de dominio dicta sólo la forma de los nombres y no sus valores,
es posible seleccionar etiquetas arbitrarias para todas las partes de su jerarquía.
Sin embargo, la mayoría de los usuarios de tecnología de dominio sigue la jerarquía de etiquetas
utilizadas por el sistema de dominio oficial de Internet. Hay dos razones para ello:
-
El esquema de Internet es completo y flexible.
La mayor parte de las localidades respeta el esquema Internet porque de esta manera puede
conectar sus instalaciones TCP/IP a la red global sin cambiar nombres.
El nombre de nivel superior permite dos jerarquías de nombres completamente diferentes:
-
Esquema Geográfico (GTLD - Global Top Level Domain): Divide el universo de máquinas por
país. Por ejemplo: ar, uy, es…
Esquema Institucional/Organizacional (CCTLD - Country Code Top Level Domain): permite a
las organizaciones que se agrupen según la función de su organización. Por ejemplo: com,
edu, mil, gov…
Asociación de nombres de dominio en direcciones
Características principales
-
Distribuido: esto significa que un conjunto de servidores, que opera en varias localidades de
manera conjunta, resuelve el problema de la asociación de nombres en direcciones.
Eficiente: la mayor parte de los nombres se puede asociar localmente, sólo unos pocos
requieren tráfico de red de redes.
De propósito general: porque no se encuentra restringido a nombres de máquina.
Confiable: dado que una sola falla de una máquina prevendrá al sistema para que opere
correctamente.
Componentes del DNS
-
-
Servidor DNS (Servidores de Dominio): Sistema independiente y cooperativo. Un servidor
DNS es un programa servidor que ofrece la asociación nombre-dirección, asociando los
nombres de dominio en direcciones IP.
Clientes DNS (Resolver): Utiliza uno o más servidores de nombre cuando traduce un nombre.
Zonas de Autoridad: Áreas de nombres de dominio que abarcan al menos un dominio.
46/70
Teleprocesos y Redes 2
La forma más fácil de entender cómo trabaja un servidor de dominio es imaginándolo como una
estructura de árbol que corresponde a la jerarquía, como se muestra en la figura siguiente. La raíz del
árbol es un servidor que reconoce el dominio de nivel superior y sabe qué servidor resuelve cada
dominio. Teniendo un nombre por resolver, la raíz puede resolver el servidor correcto para este
nombre. En el siguiente nivel, el conjunto de servidores de nombre proporciona respuestas para un
dominio de nivel superior. Un servidor en este nivel sabe qué servidor puede resolver cada uno de
los subdominios bajo su dominio. En el tercer nivel del árbol, el servidor de nombres proporciona
respuestas para el subdominio. El árbol conceptual continúa con un servidor en cada nivel para el
que se ha definido un subdominio.
Los enlaces en el árbol conceptual no indican conexiones de red física. De hecho, muestran qué otros
servidores conoce y contacta un servidor dado. El servidor por sí mismo puede localizarse en una
localidad cualquiera dentro de la red de redes. De esta manera, el árbol de servidores es una
abstracción que emplea una red de redes para comunicarse.
En la práctica, la relación entre una jerarquía de nombres y el árbol de nombres no resulta tan
sencilla como el modelo. Las organizaciones a menudo reúnen información de todos los subdominios
desde un solo servidor.
Resolución de nombres de dominio
El software cliente forma una solicitud de nombres de dominio que contiene el nombre a resolver,
una declaración sobre la clase del nombre, el tipo de respuesta deseada y un código que especifica si
el servidor de nombres debe traducir el nombre completamente. Se envía la solicitud a un servidor
de nombre para su resolución.
Cuando un servidor de nombres de dominio recibe una solicitud, verifica si el nombre señala un
subdominio sobre el cual tenga autoridad. Si así es, traduce el nombre a una dirección de acuerdo
con su base de datos y anexa una respuesta a la solicitud, antes de enviarla de regreso al cliente. Si el
servidor de nombre no puede resolver el nombre, verifica qué tipo de interacción especifico el
cliente, y en base a eso realiza lo siguiente:
-
-
Resolución Recursiva: El servidor contactará a otro servidor, y en el momento de recibir la
respuesta de éste último, copia el mensaje al solicitante, ocultando las respuestas
intermedias.
Resolución Iterativa: En servidor responderá con la dirección del próximo server de dominio
que el cliente deberá contactar, para consultarle por el nombre.
47/70
Teleprocesos y Redes 2
Los clientes deben conocer al menos un Servidor de Dominio local (Normalmente provisto por
DHCP). Cada Servidor de Dominio debe conocer por lo menos a un Servidor de nivel superior y a
todos los servidores de los dominios jerárquicos inferiores.
Desempeño del cache
La búsqueda de nombres puede representar una pesada carga para una red de redes. Así, para
mejorar el desempeño global de un sistema de servidor de nombres, es necesario reducir los costos
de búsqueda para nombres no locales.
Los servidores de nombre utilizan una memoria intermedia de nombres (name caching) para
optimizar los costos de búsqueda. Cada servidor mantiene una memoria intermedia:
-
Los nombres y sus direcciones utilizados más recientemente.
Un registro de dónde fue obtenida la información para la asociación de nombres.
Un TTL para mantener la memoria intermedia con información correcta, suprimiendo las
entradas que excedan un tiempo especificado.
Cuando un cliente interroga a un servidor a fin de resolver el problema de un nombre, el servidor
verifica primero si tiene autoridad para el nombre. Si no es así, el servidor verifica su memoria
intermedia para ver si el problema del nombre se resolvió recientemente. Los servidores reportan la
información almacenada en memoria intermedia a los clientes, pero la marcan como que no tiene
autoridad y entrega el nombre del servidor y su dirección desde la cual obtiene la asignación. De esta
manera, los clientes reciben respuestas rápidamente, pero la información podría no estar
actualizada. Si la eficiencia es importante, el cliente elegirá aceptar la respuesta sin autoridad y
continuar. Si la seguridad es importante, el cliente seleccionará contactar a la autoridad y verificar
que la asignación entre el nombre y la dirección siga siendo válida.
48/70
Teleprocesos y Redes 2
TELNET – Acceso Remoto
Protocolo TELNET
Se utiliza para servicio de terminal remota. TELNET permite al usuario de una localidad interactuar
con un sistema de tiempo compartido como si el teclado y el monitor del usuario estuvieran
conectados a la máquina remota.
TELNET permite a un usuario acceder a una computadora a través de internet. TELNET transfiere las
pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota como si
hubiesen sido hechos en un teclado unido a la máquina remota. TELNET también transporta la salida
de la máquina remota de regreso a la pantalla del usuario. El servicio se llama transparente porque
da la impresión de que el teclado y el monitor del usuario están conectados de manera directa a la
máquina remota.
TELNET ofrece tres servicios básicos:
- Terminal Virtual de Red (network virtul terminal - NVT): Proporciona una interfaz estándar
para los sistemas remotos. Los programas clientes no tienen que comprender los detalles de
todos los sistemas remotos, se construyen para utilizarse con ésta interfaz estándar.
- Negociación de Opciones: Telnet incluye un mecanismo que permite al cliente y al servidor
negociar opciones, permitiendo a cualquiera de los dos extremos negociar las opciones.
Asimismo proporciona un conjunto de opciones estándar.
- Simétrico: TELNET trata a ambos lados de la conexión de manera simétrica. En particular,
TELNET no fuerza la entrada de cliente para que ésta provenga de un teclado, ni al cliente
para que muestre su salida en la pantalla. De esta manera TELNET permite que cualquier
programa se convierta en cliente.
Como se muestra en la figura, cuando un usuario invoca a TELNET, un programa de aplicación en la
máquina del usuario se convierte en el cliente. El cliente establece una conexión TCP con el servidor
por medio de la cual se comunicarán. Una vez establecida la conexión, el cliente acepta los pulsos de
teclado del usuario y los manda al servidor, al tiempo que acepta caracteres de manera concurrente
que el servidor regresa y despliega en la pantalla del usuario. El servidor debe aceptar una conexión
TCP del cliente y después transmitir los datos entre la conexión TCP y el sistema operativo local.
El servidor debe manejar diversas conexiones concurrentes. Normalmente, un proceso de servidor
maestro espera nuevas conexiones y crea nuevos esclavos para manejar cada conexión.
Utilizamos el término pseudo terminal para describir el punto de entrada del sistema operativo que
permite que un programa, que se está corriendo como el servidor TELNET, transfiera caracteres al
sistema operativo como si vinieran de un teclado.
Al ser TELNET un programa de nivel de aplicación tiene sus ventajas y desventajas:
49/70
Teleprocesos y Redes 2
Ventaja: hace la modificación y el control del servidor más fácil que si el código estuviera embebido
en el sistema operativo.
Desventaja: su ineficiencia. Esto se debe a que cada pulso del teclado viaja a través de la red hacia el
servidor. Después de llegar a su máquina destino, la salida (si es que el eco de caracteres remotos
esta activado) viaja de regreso al cliente.
Adaptarse a la heterogeneidad
Para hacer que TELNET interopere entre tantos sistemas operativos como sea posible, debe
adaptarse a las distintas computadoras y sistemas operativos existentes.
Para adaptar la heterogeneidad, TELNET define cómo deben mandarse las secuencias de datos y
comandos a través de Internet. La definición se conoce como NVT (teminal virtual de red). El
software cliente traduce las pulsaciones de teclado y las secuencias de comandos que vienen de la
terminal del usuario a formato NVT y las envía al servidor. El software del servidor traduce los datos y
comandos que acaban de llegar de formato NVT al formato que el sistema requiera. Para devolver los
datos, el servidor traduce a NVT y el cliente los traduce al formato de la máquina local.
Transferencia de Comandos que Controlan el Extremo Remoto
Para transferir las funciones de control a través de la conexión TCP, TELNET las codifica mediante la
secuencia de escape. Una secuencia de escape se vale de un byte reservado para indicar que a
continuación sigue un byte de código de control. En TELNET, el byte reservado que inicia una
secuencia de escape se conoce como el byte Interpret As Command (IAC). A continuación se listan
los comandos posibles:
-
Comando
Significado
-
IAC
DON’T
DO
WON’T
WILL
SB
GA
EL
EC
AYT
AO
IP
BRK
DMARK
-
-
NOP
SE
EOR
SYNCH
-
Se interpreta al siguiente byte como comando.
Negación de petición para ejecutar una operación especificada.
Aprobación para permitir una opción especificada.
Rechazo de ejecución de una operación especificada.
Autorización de realizar una operación especificada.
Inicio de subnegociación de opción.
Señal de Go Ahead. Continuar
Señal de Erase Line. Borra toda la línea actual.
Señal de Erase Character. Borra carácter previo.
Señal de Are You There. Estás ahí. Prueba si el servidor responde.
Señal de Abort Output. Salida Abortada. Se descarta cualquier salida de búfer.
Señal de Interrupt Process Interrupción de proceso. Termina de ejecutarse el programa.
Señal de Breack. Tecla de pausa o señal de atención.
La porción de datos de un SYNCH (siempre acompañada de una notificación de urgente
del TCP)
Sin operación.
Fin de operación de subnegociación.
Fin de registro.
(Synchronize) Sincroniza. Elimina los datos hasta que el puntero de datos urgente, pero no
interpreta comandos.
50/70
Teleprocesos y Redes 2
Forzar al servidor a leer una función de control
El envío de funciones de control junto con datos normales no siempre es suficiente para garantizar
los resultados deseados.
TELNET no puede confiarse del flujo de datos convencional por sí sola para transportar secuencias de
control entre el cliente y el servidor. Pues una aplicación que se conduce mal necesita estar
controlada ya que se podría bloquear de manera inadvertida el flujo de datos.
Para resolver el problema, TELNET utiliza una señal fuera de banda. El TCP implementó señalización
fura de banda con el mecanismo de dato urgente. Dondequiera que se coloque una función de
control en una corriente de datos, TELNET también mandará un comando SYNCH. TELNET después
anexará un byte reservado, llamado marca de datos y hará que TCP emita una señal hacia el servidor
enviando un segmento con el conjunto de bits de URGEN DATA. Los segmentos que llevan los datos
urgentes evitan el control de flujo y llegan de inmediato al servidor. En respuesta a una señal de
urgente, el servidor lee y descarta todos los datos hasta que encuentra la marca de datos. El servidor
regresa a su procesamiento normal cuando encuentra esta marca.
Opciones de TELNET
En TELNET, las opciones son negociables, lo que hace posible reconfigurar su conexión para el cliente
y el servidor.
El rango de opciones es amplio: algunos extienden las capacidades de manera significativa mientras
que otros tratan con los detalles menores. Una de las opciones controla si TELNET opera en modo
half-duplex o full-duplex. Otra de las opciones permite que el servidor, en una máquina remota,
determine el tipo de terminal de usuario. El tipo de terminal es importante para las secuencias de
posicionamiento del cursor.
Negociación de opciones de TELNET
Como en algunas opciones tiene sentido para el server iniciar una operación en particular, el
protocolo está diseñado para permitir o dejar de hacer una petición. De este modo, se dice que el
protocolo es simétrico con respecto al procesamiento de opciones. El extremo de recepción puede
responder a una petición con una aceptación positiva o un rechazo. La petición es WILL X, que
significa “estarías de acuerdo en dejarme usar la opción X”; y la respuesta podría ser DO X o DON’T X,
que significa “estoy de acuerdo en dejarte usar la opción X” o “no estoy de acuerdo en dejarte usar la
opción X”. La simetría surge porque DO X pide que la parte receptora comience a utilizar la opción X,
y WILL X o WON’T X significa “comenzaré a utilizar la opción X” o “no comenzaré a utilizar la opción
X”.
TELNET utiliza un mecanismo de negociación de opciones simétrica para permitir a los clientes y a los
servidores reconfigurar los parámetros que controlan su interacción. Como el software TELNET
comprende un protocolo NVT básico, los clientes y los servidores pueden interoperar aun cuando
uno comprenda las opciones y el otro no.
FTP - PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS
Los objetivos del FTP son:
1) Promocionar el uso compartido de ficheros.
2) Animar al uso indirecto o implícito (a través de programas) de servidores remotos.
3) Hacer transparente al usuario las variaciones entre la forma de almacenar ficheros en diferentes
ordenadores.
4) Transferir datos fiable y eficientemente. El FTP, aunque puede ser utilizado directamente por un
usuario en un terminal, está diseñado principalmente para ser usado por programas.
51/70
Teleprocesos y Redes 2
TERMINOLOGIA
Conexión de datos: Una conexión bidireccional sobre la que se transfieren los datos (parte de un
fichero, un fichero entero o un cierto número de ficheros). La conexión se puede establecer entre un
server-DTP y un user-DTP o entre dos server-DTP's.
DTP (Data Transfer Process): Establece y maneja la conexión de datos. Puede ser activo o pasivo.
PI (Protocol Interpreter): El Intérprete del Protocolo. La parte del usuario y del servidor del protocolo
tienen distintos papeles que se implementan como un user-PI y un server-PI.
Server-DTP (server Data Transfer Process): En su estado normal de "activo", establece una conexión
de datos con el puerto de datos que está a la espera. Prepara los parámetros para transferir y
almacenar y transfiere los datos cuando así se requiere a través de su PI. El DTP se puede poner en
estado "pasivo" para esperar una conexión, en lugar de iniciarla.
Server-PI (server Protocol Interpreter): "Escucha" en el puerto determinado hasta que recibe una
conexión de un user-PI y establece una conexión de comunicaciones para control. Recibe órdenes
FTP estándar desde el user-PI, envía respuestas y controla el server-DTP.
User-DTP (user Data Transfer Process): Espera a recibir una conexión en el puerto de datos desde el
proceso server-FTP. Si dos servidores están transfiriendo datos entre ellos, el user-DTP permanece
inactivo.
User-PI (user Protocol Interpreter): El intérprete de protocolo de usuario inicia la conexión de control
desde su puerto U hasta el proceso server-FTP, envía órdenes FTP y controla el user-DTP si es
necesario para la transferencia de ficheros.
EL MODELO FTP
El siguiente modelo representa un diagrama de un servicio FTP.
Figura 1: Modelo para el uso del FTP.
NOTAS: a. La conexión de datos es bidireccional. b. La conexión de datos no tiene por qué existir todo el tiempo.
En el modelo descrito en la Figura 1, el user-PI, inicia la conexión de control, la cual se usará para el
intercambio de órdenes y respuestas, esta conexión sigue el Protocolo Telnet.
Las órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de
transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de
ficheros (almacenar, recuperar, añadir, borrar, etc.).
52/70
Teleprocesos y Redes 2
En otra situación, un usuario puede querer transferir ficheros entre dos ordenadores que no son
locales. El usuario prepara las conexiones de control con los dos servidores y da las órdenes
necesarias para crear una conexión de datos entre ellos. De esta forma, la información de control se
envía al user-PI pero los datos se transfieren entre los procesos de transferencia de datos de los
servidores.
Figura 2
El protocolo requiere que las conexiones de control permanezcan abiertas mientras se transfieren
datos. Es responsabilidad del usuario solicitar el cierre de las conexiones de control una vez termine
de usar el servicio, mientras que el servidor es el encargado de cerrarlas. El servidor puede
interrumpir la transferencia de datos si las conexiones de control se cierran sin previa solicitud.
3. FUNCIONES DE TRANSFERENCIA DE DATOS
Los ficheros sólo se transmiten por la conexión de datos. La conexión de control se usa para enviar
órdenes, que describen la función a realizar, y las repuestas a estas órdenes.
Representación de Datos y Almacenamiento
A menudo es necesario realizar ciertas transformaciones en los datos porque la representación de los
datos almacenados varía de un ordenador a otro.
Tipos de Datos: El usuario especifica las representaciones de datos que se manejarán en el FTP.
- Tipo ASCII: Este es el tipo por omisión. Su principal propósito es transferir ficheros de texto.
- Tipo EBCDIC: El propósito de este tipo es la transferencia eficaz entre ordenadores que usan
EBCDIC como su representación de carácter interna.
- Tipo IMAGEN: El tipo imagen está indicado para el almacenamiento y obtención de ficheros y
la transferencia de datos binarios.
- Tipo LOCAL
Control de Formato: Los tipos ASCII y EBCDIC llevan un segundo parámetro (opcional); este es para
indicar qué tipo de control de formato vertical. Los tipos son:
- NO PARA IMPRIMIR [NON PRINT]: Este es el formato por omisión.
- CONTROLES DE FORMATO TELNET: El fichero contiene controles de formato vertical
ASCII/EBCDIC que el proceso para imprimir interpretará apropiadamente.
- CONTROL DE CARRO (ASA): El fichero contiene caracteres de control de formato vertical ASA
(FORTRAN).
53/70
Teleprocesos y Redes 2
Estructura de Datos
Se definen tres estructuras de fichero en el FTP:
- Estructura de fichero: donde no hay una estructura interna y el fichero se considera como
una secuencia continua de bytes de datos.
- Estructura de registro: donde el fichero está compuesto de registros secuenciales.
- Estructura de página: donde el fichero está compuesto de páginas indizadas independientes.
CONEXIONES
Modos de conexión del cliente FTP
FTP admite dos modos de conexión del cliente. Estos modos se denominan Activo (o Estándar, o
PORT, debido a que el cliente envía comandos tipo PORT al servidor por el canal de control al
establecer la conexión) y Pasivo (o PASV, porque en este caso envía comandos tipo PASV). Tanto en
el modo Activo como en el modo Pasivo, el cliente establece una conexión con el servidor mediante
el puerto 21, que establece el canal de control.
Modo Activo
En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado
del cliente el canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente
manda un comando PORT al servidor por el canal de control indicándole ese número de puerto, de
manera que el servidor pueda abrirle una conexión de datos por donde se transferirán los archivos y
los listados, en el puerto especificado.
Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a
aceptar cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello
implica si se tiene el equipo conectado a una red insegura como Internet. De hecho, los cortafuegos
que se instalen en el equipo para evitar ataques seguramente rechazarán esas conexiones aleatorias.
Para solucionar esto se desarrolló el modo Pasivo.
Modo Pasivo
Cuando el cliente envía un comando PASV sobre el canal de control, el servidor FTP abre un puerto
efímero (cualquiera entre el 1024 y el 5000) e informa de ello al cliente FTP para que, de esta
manera, sea el cliente quien conecte con ese puerto del servidor y así no sea necesario aceptar
conexiones aleatorias inseguras para realizar la transferencia de datos.
54/70
Teleprocesos y Redes 2
Antes de cada nueva transferencia, tanto en el modo Activo como en el Pasivo, el cliente debe enviar
otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el
servidor recibirá esa conexión de datos en un nuevo puerto aleatorio (si está en modo pasivo) o por
el puerto 20 (si está en modo activo).
3.4. MODOS DE TRANSMISION
Se definen los siguientes modos de transmisión en el FTP:
- Modo Flujo: Los datos se transmiten como un flujo de bytes. No hay ninguna restricción en el
tipo de representación usado.
- Modo Bloque: El fichero se transmite como una serie de bloques de datos precedidos por
uno o más bytes de cabecera. Los bytes de la cabecera contienen un campo contador y un
código descriptor. El campo contador indica la longitud total del bloque de datos en bytes,
indicando así el inicio del siguiente bloque de datos (no hay bits de relleno). El código
descriptor define: último bloque del fichero.
- Modo Comprimido: Hay tres clases de información a enviar: datos normales, enviados en una
cadena de bytes; datos comprimidos, formados por repeticiones o relleno.
3.5. RECUPERACION DE ERRORES Y REINICIO
No hay nada que detecte bits perdidos o alterados en las transmisiones de datos; esto lo maneja el
TCP. Sin embargo, se proporciona un medio para recomenzar transferencia para proteger a los
usuarios de fallos graves en el sistema.
Sólo está definido el procedimiento de reinicio para los modos de transferencia de bloque y
comprimido. Requiere que el que envía datos inserte un código marcador especial en el flujo de
datos con información que indique por dónde vamos. El receptor de los datos, si implementa el
procedimiento de reinicio, debería guardar la correspondiente posición de este marcador en el
sistema receptor y devolver esta información al usuario.
En el caso de un fallo del sistema, el usuario puede reiniciar la transferencia de datos identificando el
último marcador recibido con el procedimiento de recomenzar del FTP.
55/70
Teleprocesos y Redes 2
ORDENES FTP
Ordenes de Control de Acceso
- USER: Recibe el nombre de usuario que lo identifica en el sistema. Es requerido para acceder
al sistema de archivos del servidor.
- PASS: Especifica el password del usuario. Este comando siempre es precedido por USER.
- ACCT: Un string Telnet con el nombre de la cuenta constituye el argumento de este
comando.
- CWD: Permite al usuario cambiar de directorio de trabajo sin alterar su estadía en el sistema.
- CDUP: Caso particular del anterior. Sirve para cambiar al directorio raíz desde cualquier
ubicación.
- SMNT: Sirve para montar un sistema de archivos distinto sin alterar la estadía del usuario.
- REIN: Reinicializa el sistema para el ingreso de un nuevo usuario.
- QUIT: Permite cerrar la sesión de un cliente o usuario.
Ordenes de Parámetros de Transferencia
- PORT: Especifica el puerto de la conexión de datos.
- PASV: Comando que hace una petición al DTP de servidor para que “escuche” en un puerto
(no el por defecto) para la conexión de datos.
- TYPE: Especifica el tipo de representación de los datos (ASCII, EBCDIC, Image, Local).
- STRU: Especifica la estructura de archivo (File, Record structure, Page structure)
- MODE: Especifica el modo de transmisión de los datos (Stream, Bloque o Comprimida).
Ordenes de Servicio FTP
- RETR: Comando que da la orden al DTP de servidor para que transfiera una copia del archivo
al DTP de usuario.
- STOR: Da la orden para que el DTP de servidor acepte el archivo transferido hacia el lado
servidor y lo guarde.
- STOU: Caso particular del comando anterior donde el archivo queda en un directorio con
nombre único.
- APPE: Ordena al DTP de servidor aceptar un archivo y si este existiese, adjunta la información
a dicho archivo antiguo.
- ALLO: Este comando permite reservar un espacio en disco duro en el servidor para un posible
archivo.
- REST: Reinicia la transferencia de un archivo indicando el marcador del servidor.
- RNFR: Este comando especifica el nombre antiguo de un directorio que será renombrado.
- RNTO: Especifica el nombre nuevo de un directorio que será renombrado.
- ABOR: Aborta el comando ingresado previamente.
- DELE: Elimina el archivo especificado en el lado del servidor.
- RMD: Remueve un directorio completo.
- MKD: Crea un directorio nuevo.
- PWD: Este comando hace que el nombre del directorio de trabajo sea retornado en una
respuesta.
- LIST: Comando que provoca el envió de una lista de archivos desde el servidor al DTP.
- NLST: Envía una lista de directorios desde el servidor hacia el usuario.
- SITE: Comando que sirve para que el servidor provea servicios más específicos.
- SIST: Comando que sirve para identificar el sistema operativo del servidor.
56/70
Teleprocesos y Redes 2
-
STAT: Causa el envió de una respuesta de status de las operaciones en desarrollo.
HELP: Entrega información acerca de cualquiera de los comandos y su sintaxis.
NOV: Sirve para recibir una respuesta de OK del servidor. No altera otros parámetros.
RESPUESTAS FTP
Las respuestas a órdenes del FTP están pensadas para asegurar la sincronización entre peticiones y
acciones en el proceso de transferencia de ficheros y para garantizar que el proceso de usuario
siempre conoce el estado del servidor. Cada orden debe generar por lo menos una respuesta.
Una respuesta FTP consiste en un número de tres cifras seguidas de texto.
Hay cinco valores para el primer dígito del código de respuesta:
-
1XX: El comando fue aceptado pero se debe esperar una segunda respuesta para ingresar
nuevo comando.
2XX: El comando fue aceptado y la acción se llevó a cabo con éxito. Se puede ingresar uno
nuevo.
3XX: El comando fue aceptado pero se necesita el ingreso de otro comando especificando
información requerida.
4XX: El comando fue rechazado y la acción requerida no se efectuó, pero el error es temporal
y la acción podría ser solicitada de nuevo.
5XX: Comando no aceptado y acción no efectuada.
57/70
Teleprocesos y Redes 2
TFTP – Trivial File Tranfer Protocol
Este protocolo se diseño para aplicaciones que no necesitan interacciones complejas entre cliente y
servidor. Restringe las operaciones a transferencia de archivos sencillas y no proporciona
autenticación.
El TFTP corre bajo UDP y utiliza time-out y retransmisión para asegurar que los datos lleguen. El lado
que envía transmite un bloque y espera un acuse de recibo para cada bloque antes de enviar el
siguiente. El receptor envía un acuse de recibo por cada bloque cuando le llega.
Las reglas del TFTP son sencillas. El primer paquete enviado requiere de una transferencia de archivo
y establece la interacción entre cliente y servidor, especifica el nombre del archivo y si se lee o
escribe. Los bloques de archivos están numerados secuencialmente comenzando en 1, el cual figura
en el encabezado del bloque que se transporta. A su vez cada acuse de recibo contiene el número del
bloque al que corresponde. Un bloque de menos de 512 bytes señala el final del archivo. Es posible
enviar mensajes de error. Normalmente los mensajes de error terminan con la transferencia.
La figura anterior muestra el formato de cinco tipos de paquetes TFTP. El paquete inicial debe utilizar
códigos de operación 1 o 2, según se trate de una petición de lectura o escritura.
Una vez enviado el paquete inicial, el servidor utiliza la dirección IP y el número de puerto de
protocolo UDP del cliente para identificar las operaciones subsiguientes. De este modo, ni los
mensajes de datos ni los mensajes de ACK necesitan especificar el nombre del archivo.
La retransmisión de TFTP es simétrica. Cada lado implementa time-out y retransmisión. Si el emisor
llega a un time-out, vuelve a retransmitir el último bloque de datos. Si el receptor llega a un time-out
vuelve a transmitir el último acuse de recibo. Tener a ambas partes participando en la transmisión
ayuda a asegurar que no falle la transferencia después de que se haya perdido un paquete.
Este tipo de retransmisión simétrica puede conducir a retransmisiones excesivas. Este problema se
conoce como Falla del Aprendiz de Brujo, y surge cuando un acuse de recibo para un paquete k se
demora pero no se pierde. El emisor vuelve a transmitir el paquete de datos para el cual el receptor
emite un acuse de recibo. Ambos acuses de recibo llegan en algún momento y cada uno dispara una
transmisión del paquete k+1. El receptor emite un acuse de recibo para ambas copias del paquete
k+1, y los dos acuses de recibo causan que el emisor transmita el paquete de datos k+2.
58/70
Teleprocesos y Redes 2
SMTP - Protocolo Simple de Transmisión de Correo
Este protocolo es el estándar de Internet para el intercambio de correo electrónico. SMTP utiliza los
servicios de TCP. Para que dos sistemas intercambien correo mediante el protocolo SMTP, no es
necesario que exista una conexión interactiva, ya que este protocolo usa métodos de
almacenamiento y reenvío de mensajes.
Modo de Comunicación SMTP
Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP, el emisor
(servidor que inicia la sesión SMTP) establece una conexión con el receptor (servidor que recibe
petición de establecer sesión SMTP). Esta conexión es unidireccional, es decir, el emisor puede enviar
correo al receptor, pero durante esa conexión, el receptor no puede enviar correo al emisor. Si el
receptor tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión establecida y
establecer otra en sentido contrario, cambiando los papeles de emisor y receptor. Una vez
establecida la conexión, el emisor envía comandos y mensajes. Los mensajes pueden tener como
destino el receptor o un intermediario para llegar a un destino más lejano. El receptor puede enviar
al emisor respuestas y códigos de estado. Los comandos son cadenas de caracteres que se pueden
entender fácilmente y las respuestas son códigos numéricos seguidos de una explicación del código.
Por lo señalado, SMTP (RFC 821) está basado en entrega "end-to-end". Esto es diferente del principio
guardar y enviar común en muchos sistemas de mensajería electrónica, donde el mensaje puede
pasar a través de un numero de maquinas intermediarias su camino al destino final.
Existen aplicaciones que permiten intercambiar correo entre SMTP y el sistema de correo localmente
usado. Estas aplicaciones son llamadas "Gateways" de correo o "Bridges" de correo. Enviar correo a
través de un "Gateway" puede alterar la entrega "end-to-end". El protocolo SMTP solo puede
garantizar la entrega al "Gateway" y no al destino final que está localizado más allá de la red TCP/IP.
Cuando el "Gateway" es usado, la transmisión SMTP "end-to-end" se realiza en varias partes, de
"host" a "Gateway", "Gateway" a "host" o "Gateway" a "Gateway". El comportamiento más allá del
"Gateway" no está especificado por SMTP. En la Fig. 2-1 se observa la comunicación a través de los
"Gateways".
SMTP se basa en el modelo de comunicación que se muestra en la Fig. 2-2.
59/70
Teleprocesos y Redes 2
En este modelo de comunicación en primera instancia un usuario establece la petición de enviar un
mensaje a través de correo electrónico, luego el Emisor SMTP establece una conexión de dos hilos
con el Receptor SMTP. El Receptor SMTP puede ser la destinación última o un intermediario, como es
el caso del "Gateway". El Emisor SMTP genera comandos que son contestados por el Receptor SMTP.
Comandos SMTP
HELO: Se utiliza para identificar el Remitente-SMTP al Receptor SMTP.
EHLO: HELO Extendido (RFC 2821).
MAIL: Este comando se utiliza para iniciar una transacción de correo en la cual el correo se entrega a
uno o más buzones de correo.
DATA: Agrega líneas de datos al buffer de datos del correo.
SEND: Se usa para iniciar una transacción de mail en el cual el mail es entregado a una o más
terminales.
SOML (SEND OR MAIL): Inicializa una transacción de mail en el cual el mail es entregado a una o más
terminales o buzones de correo.
SAML (SEND AND MAIL): Inicializa una transacción de mail en el cual el mail es entregado a una o
más terminales y buzones de correo.
RSET (RESET): Aborta la transacción de mail actual.
VRFY (VERIFY): Solicita al receptor confirmar el argumento que identifica a un usuario.
EXPN (EXPAND): Solicita al receptor confirmar el argumento que identifica una lista de correo, y si es
así, regresar a la composición de dicha lista.
HELP: El receptor envía información de ayuda al remitente.
NOOP: Este comando no afecta ningún parámetro ingresado previamente.
QUIT: El receptor debe enviar una respuesta de OK, y a continuación, cerrar el canal de transmisión.
TURN: Este comando especifica que el receptor SMTP y el remitente SMTP intercambien roles.
Flujo de Transferencia de los Mensajes de Correo Electrónico
Aunque los comandos y respuestas son estrictamente definidos por el protocolo, el intercambio de
ellos entre emisor y receptor resultar fácil de comprender. El ejemplo de trasferencia se detalla a
continuación:
60/70
Teleprocesos y Redes 2
· El Emisor SMTP establece una conexión TCP con el destino SMTP y luego espera que el servidor
envíe un 220 Servicio de lectura de mensaje o un 421 Servicio de mensaje no habilitado, esto último,
cuando la destinación está temporalmente inhabilitada para procesar el mensaje.
· HELO es enviado para que el receptor identifique si el Emisor SMTP está enviando su nombre de
dominio. El Emisor SMTP puede usarlo para verificar si contactó la destinación SMTP correcta. Si el
Emisor SMTP soporta Extensión de Servicios ("Service Extensions") SMTP, puede sustituir por un
comando EHELO el comando HELO. El Receptor SMTP que no soporta Extensión de Servicios,
responde con una sintaxis de error 500, que es un comando de mensaje no reconocido. El Emisor
SMTP debe entonces reintentar con HELO, o si el emisor no puede transmitir el mensaje sin uno o
más de los comandos que son propios de Extensión de Servicios, éste debe enviar un mensaje QUIT.
· Si el Receptor SMTP soporta Extensión de Servicios, responde con un mensaje multilínea 250 OK,
que incluye una lista de extensión de servicios que soporta.
· El Emisor SMTP, luego de recibir este comando 250 OK, inicializa la transferencia del mensaje
enviando el comando MAIL al Receptor SMTP. Este comando contiene el "reverse-path"
(habitualmente se utiliza para el envío del nombre de dominio del emisor) que puede ser usado para
reportar errores. Esta "reverse-path" puede contener más que solamente el nombre de dominio de
usuario (del emisor), en adición, éste puede contener una lista de "host" de la ruta. Ejemplo de esto
es cuando se pasa por un "Bridge" o cuando se provee explícitamente información de la ruta en la
dirección de destino. Si el Receptor SMTP acepta responde con un 250 OK.
· El segundo paso del intercambio de mensajes a través de correo electrónico, consiste en proveer al
servidor SMTP la destinación para el mensaje. Se realiza enviando uno o más comandos RCPT TO:
forward-path. Cada uno de estos envíos es contestado por parte del Receptor SMTP con un 250 OK,
si la destinación es conocida por el servidor, o un 550 NO, si tal usuario no es conocido.
· Cuando todos los comandos RCPT son enviados, el Emisor SMTP emite un comando DATA para
notificar al Receptor SMTP que el contenido del mensaje será el siguiente envío. El Receptor SMTP
responde con 354 Start mail input, end with CRLF CRLF. Esta secuencia final es la que el Emisor SMTP
utiliza cuando termina el envío de datos del mensaje a transferir.
· El cliente ahora envía las líneas de datos, una a una, finalizando con la secuencia CRLF.CRLF,
secuencia que el Receptor SMTP responde con un 250 OK o un mensaje de error si es que algo ha
fallado.
· Luego se tienen algunas opciones:
- El Emisor SMTP no tiene más mensajes que enviar, por lo que se finaliza la conexión con un
comando QUIT, a lo cual el Receptor SMTP responde con 221 Service closing transmission channel.
- Si el Emisor SMTP no tiene más mensaje es que enviar, pero quiere recibir mensajes del otro
extremo. Este envía el comando TURN. Los dos extremos de la comunicación SMTP ahora cambian
roles de Emisor/Receptor y el nuevo Emisor SMTP (Anterior Receptor SMTP) puede enviar mensajes
partiendo del paso 3 del esquema mostrado en la Fig. 2-3.
- Si el Emisor SMTP tiene otro mensaje para enviar retorna al paso 3 y envía un comando MAIL.
61/70
Teleprocesos y Redes 2
PROTOCOLO MIME - Extensión de Correo de Internet Multipropósito
SMTP tradicional es adecuado para la transmisión de mensajes de texto en inglés, pero es
inadecuado para texto en otro idioma o para datos no textuales. Uno de los métodos para superar
estas limitaciones es el protocolo MIME. Este protocolo, especifica un mecanismo para codificar
texto y datos binarios en 7-bit ASCII.
MIME y Extensión de servicios SMTP son cercanos y complementarios más que estándares
excluyentes. Desde el estándar MIME, se permiten mensajes para ser declarados como consistentes
de datos de 8-bit más que de datos de 7-bit, debido a que los mensajes no pueden ser transmitidos
por agentes SMTP que estrictamente se ajusten a RFC 821(especifica ASCII de 7-bit).
Cuando un cliente SMTP intenta enviar datos de 8 bits a un servidor que no soporta esa extensión, el
cliente SMTP debe codificar el contenido del mensaje a una representación de 7 bits o retornara un
error permanente del servidor. MIME redefine el formato de mensajes para permitir cuerpos de
mensajes textuales y no textuales con un conjunto de caracteres diferentes a EE.UU.-ASCII de 7 bits.
El protocolo MIME surge por la incapacidad que tiene SMTP para representar todos los datos que se
desean transmitir a través de correo electrónico. Desde un principio SMTP define el formato normal
de mensajes textuales en Internet (define sintaxis de cuerpo y cabecera). Su éxito ha sido tal que se
utiliza más allá de los límites de Internet. Cuando el formato se ha usado en forma más extensa, se ha
observado un aumento de las limitaciones para la comunidad de usuarios, dado que no se considera
mensajes multimediales que incluyan audio o imágenes. Incluso, en el caso de texto, cuyos idiomas
requieren el uso de un conjunto de caracteres más rico. Dada estas limitaciones, se necesitan las
características técnicas adicionales que proporciona MIME. Una de las limitaciones notables de SMTP
es que limita la longitud del mensaje de correo electrónicos a líneas relativamente cortas (Ej. 1000
caracteres o menos). Esto obliga a los usuarios a convertir cualquier dato no textual a la
representación de caracteres de bytes de 7-bits EE.UU.-ASCII antes de invocar un UA (Agente del
Usuario, un programa con el que los usuarios humanos envían y reciben correo).
Mensajes Multiparte: Un mensaje MIME multiparte contiene una frontera en el encabezado; esta
frontera, que no puede aparecer en ninguna de las partes, es ubicada entre cada una de ellas, y al
inicio y al final del cuerpo del mensaje. Cada parte consiste de su propio encabezado de contenido y
un cuerpo. El contenido multiparte puede estar anidado.
Subtipos de Multiparte
El estándar MIME define varios subtipos para mensajes multiparte, estos especifican la naturaleza de
la parte del mensaje y su relación con otras partes. El subtipo es especificado en el encabezado para
todo el mensaje. Lo que sigue es una lista de los subtipos más comúnmente usados:
Mixed: es usado para enviar mensajes o archivos con diferentes encabezados ya sea en línea o como
adjuntos. Si se envían imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de
correo electrónico las mostrarán como parte del mensaje. De otra manera serán ofrecidos como
adjuntos.
Digest: es una forma simple de enviar múltiples mensajes de texto.
Alternative: indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada
una en formatos diferentes denotados por su encabezado. Los formatos son ordenados atendiendo a
cuan fieles son al original, con el menos fiel al inicio. Los sistemas pueden escoger la "mejor"
representación que ellos son capaces de procesar; en general esta será la última parte que el sistema
entiende, a menos que otros factores puedan afectar este comportamiento.
Parallel: es similar a Mixed, pero con una representación en paralelo.
62/70
Teleprocesos y Redes 2
POP - Protocolo de Oficina de Correos
El protocolo SMTP, aparece cuando la red Internet no estaba en auge. El protocolo SMTP surgió
cuando los usuarios tenían cuentas en computadores que estaban continuamente conectados a
Internet, de tal forma que cuando un usuario quería leer su correo, entraba en una sesión de
terminal y solicitaba al servidor el mensaje que tenía almacenado para él. Esta situación ha cambiado
considerablemente, hoy en día, los usuarios se conectan al servidor de correo por un período de
tiempo muy breve, el suficiente para solicitar el envío del correo mediante un programa cliente. Por
tanto, el servidor de correo electrónico debe mantener almacenado el correo en sus casillas y
enviarlo a los clientes cuando se conecten y lo soliciten. Este es el objetivo para el cual se creó el
protocolo POP.
En la actualidad, se utiliza el protocolo SMTP para el envío de correo y para la recepción de correo se
utiliza el protocolo POP, el cual, ya está en su tercera versión desde su aparición (POP3).
Modelo de Comunicación POP
El modelo de comunicaciones POP se basa en el concepto de buzón, que posee un espacio para
almacenar los mensajes de correo hasta que se solicite la descarga de estos mensajes.
El cliente POP se conecta con el servidor a través del puerto TCP, 110. Para conectarse al servidor, es
necesario una cuenta de identificación en dicha máquina (lo que le permite tener un espacio
reservado para sus correos). A continuación es necesario verificar que es dueño de la cuenta a través
de una clave. Una vez conectado al sistema, el cliente POP puede dialogar con el servidor para saber,
entre otras cosas, si existen mensajes en la casilla, cuántos mensajes son o para solicitar la descarga
de alguno de ellos.
Para poder ofrecer estas funciones, el modelo de comunicación POP se basa en estados. Estos son
estado de autorización, estado de transacción y estado de actualización. Después de establecer la
conexión, el servidor POP se encuentra en un estado de autorización, esperando que el cliente le
envíe el nombre y clave de la cuenta de usuario. Cuando se verifica que son correctos, el servidor
pasa a un estado de transacción. Antes de pasar a este estado, el servidor POP bloquea el buzón para
impedir que los usuarios modifiquen o borren el correo antes de pasar al estado siguiente. En este
estado de transacción el servidor atiende las peticiones del cliente. Después de enviar al servidor el
comando QUIT el servidor pasa al estado de actualización. En este estado el servidor elimina los
mensajes que están con la marca de borrado y finaliza la conexión.
Comandos POP
El diálogo desde el cliente al servidor, se basa en el envío de comandos, a los que el servidor
responde con código y cambiando, cuando corresponda, de un estado a otro.
Lo que el protocolo busca es conocer si los comandos funcionan, por tanto, sólo se establecen dos
códigos de respuesta, uno para cuando el comando funciona correctamente y otro para cuando no
es así. Los códigos de respuesta que el servidor POP envía, van seguidos de una frase que explica el
código. El Código de respuesta es el siguiente:
+OK: El comando funcionó correctamente
+ERR: El comando falló
Los comandos POP se pueden agrupar según el estado en el que se encuentre el servidor:
Comandos del Estado de Autorización
Al conectarse a un servidor POP, éste entra en un estado de autorización. El cliente de correo debe
enviar el nombre de la cuenta y la clave para poder continuar. Si son correctos, la casilla
correspondiente a esa cuenta pasa a un estado de bloqueo exclusivo, para impedir que los mensajes
63/70
Teleprocesos y Redes 2
sean modificados o borrados antes de llegar al estado de actualización del servidor POP. Si no se
consigue pasar la casilla al estado de bloqueo exclusivo, se produce un fallo y no se puede pasar al
estado de transacción.
USER: le proporciona el nombre de la cuenta de usuario.
PASS: señala la clave de la cuenta de usuario indicada por el comando USER.
QUIT: se puede usar cuando el servidor está en estado de autorización y en estado de transacción. Si
se usa cuando está en estado de autorización, la sesión finaliza y se interrumpe la conexión. Si se usa
cuando está en estado de transacción, se cierra la sesión y el servidor pasa a estado de actualización.
Comandos del Estado de Transacción
DELE: marca como eliminado un mensaje, se elimina realmente cuando se pasa al estado de
actualización.
LIST: recupera información acerca del tamaño que ocupa un mensaje determinado o todos los
mensajes.
NOOP: comando de no operación. Cuando se envía, el servidor responde con un OK. Se utiliza para
mantener activa la sesión.
RETR: (Recuperar) permite recuperar un mensaje determinado del servidor.
RSET: (Reiniciar) anula la marca de borrado de todos los mensajes en la casilla.
STAT: (Estado) permite obtener un resumen del contenido de la casilla.
Comandos del Estado de Actualización
En este estado no hay comandos. A este estado se llega desde el estado de transacción cuando se
envía al servidor el comando QUIT. En este estado de actualización se eliminan los mensajes que han
sido marcados en el estado anterior. A continuación se le quita el bloqueo exclusivo a la casilla para
que pueda actualizarse con nuevo correo. Por último, el servidor termina la conexión.
Comandos POP Opcionales
APOP: (entrar en el sistema con contraseña encriptada) es una alternativa a los comandos USER y
PASS.
TOP: permite al cliente de correo recuperar la parte del encabezado del mensaje y un número de
líneas del cuerpo o núcleo del mensaje. Este comando se suele utilizar cuando se desea conocer los
mensajes sin leerlos.
UIDL: (lista de identificadores únicos) permite obtener del servidor una identificación (ID) de mensaje
única y persistente para uno o todos los mensajes de la casilla.
NAT – Network Address Translation y PAT – Port Address Translation
El uso de redes de computadoras en las empresas ha crecido y continúa creciendo drásticamente.
Además, el rápido agotamiento de las direcciones IP públicas hace que adquirirlas sea costoso, razón
por la cual las redes privadas utilizan un direccionamiento basado en direcciones IP reservadas que
son inválidas para su uso fuera de la red interna.
NAT – Network Address Translation
NAT es un método mediante el que las direcciones IP son mapeadas desde un dominio de
direcciones a otro, proporcionando encaminamiento transparente a las máquinas finales.
Características:
-
Asignación transparente de direcciones.
Encaminamiento transparente mediante la traducción de direcciones (aquí el
encaminamiento se refiere al reenvío de paquetes, no al intercambio de información de
encaminamiento).
- Traducción de la carga útil de los paquetes de error ICMP
La traducción de la dirección de red, se aplica en redes que fueron implementadas con direcciones IP
privadas y necesitan tener un acceso a Internet, se debe solicitar a un proveedor un rango de
64/70
Teleprocesos y Redes 2
direcciones válidas para poder asociar dichas direcciones válidas con los hosts que tengan
direcciones inválidas y necesiten salida a Internet.
Operación básica:
Para que una red privada tenga acceso a Internet, el acceso debe ser por medio de un dispositivo
ubicado en la frontera de las dos redes que tenga configurado NAT para la traducción de direcciones,
en estos casos lo más conveniente es poner a un router para que los paquetes sean enviados hacia
él. Existen dos tipos de asignación de direcciones:
-
Asignación estática de direcciones, en este caso, existe un mapeo uno a uno de direcciones
para las máquinas entre una dirección privada de red y una dirección externa de red durante
el tiempo en funcionamiento del NAT. La asignación estática de direcciones asegura que NAT
no tiene que administrar la gestión de direcciones con los flujos de sesión.
SRC: 192.168.0.2:1108
DST: 207.28.194.84:80
SRC: 206.245.160.2:1108
DST: 207.28.194.84:80
A
Cliente
192.168.0.2
B
Web Server
207.29.194.84
Router NAT
192.168.0.1
Privada
206.245.160.1
Publica
Internet
SRC: 192.168.0.3:1101
DST: 207.28.194.84:21
Cliente
192.168.0.3
SRC: 206.245.160.2:1101
DST: 202.197.101.111:21
FTP Server
205.197.101.111
Tabla NAT Estatico
Interno
Externo
192.168.0.x
206.245.160.x
Figura 1: NAT estático: cuando el host 192.168.0.2 envía un paquete al servidor
207.28.194.84 tiene en la cabecera de sus paquetes los datos mostrados en “A”, al
pasar estos paquetes por el router NAT, los datos son modificados y llegan al
servidor con los datos mostrados en “B”. Las relaciones de direcciones de la tabla
del router son puestas estáticamente
-
Asignación dinámica de direcciones, en este caso, las direcciones externas son asignadas a las
máquinas de la red privada de manera dinámica, basándose en los requisitos de uso y el flujo
de sesión que el NAT determine heurísticamente. Cuando la última de las sesiones que use
una dirección asociada termine, NAT liberará la asociación para que la dirección global pueda
ser reciclada para su posterior uso.
65/70
Teleprocesos y Redes 2
SRC: 192.168.0.2:1108
DST: 207.28.194.84:80
SRC: 206.245.160.2:1108
DST: 207.28.194.84:80
A
Cliente
192.168.0.2
B
Web Server
207.29.194.84
Router NAT
192.168.0.1
Privada
206.245.160.1
Publica
Internet
SRC: 192.168.0.3:1101
DST: 207.28.194.84:21
Cliente
192.168.0.3
SRC: 206.245.160.2:1101
DST: 202.197.101.111:21
FTP Server
205.197.101.111
Tabla NAT Dinamico
Interno
Externo
192.168.0.2
206.245.160.5
192.168.0.3
206.245.160.6
NAT Pool: 206.245.160.5 - 10
Figura 2: NAT dinámico: en este caso sucede lo mismo que en el anterior con las
cabeceras de los paquetes que salen de “A”, en este caso la tabla muestra una
lista con las direcciones válidas disponibles para ser usadas, estas direcciones son
asignadas dinámicamente a los hosts.
NAT tradicional:
En un NAT tradicional, las sesiones son unidireccionales, salientes de la red privada. Las sesiones en
la dirección opuesta pueden ser permitidas en una base excepcional usando mapeos de dirección
estáticos para hosts preseleccionados. Existen dos variantes del NAT Tradicional: NAT Básico y PAT
(Port Address Translation).
NAT Básico:
Una zona con un conjunto de direcciones de red privadas puede ser habilitada para comunicarse con
una red externa mapeando dinámicamente el conjunto de direcciones privadas a un conjunto de
direcciones de red válidas globalmente, cada dirección tiene garantizada una dirección global para
ser mapeada a ella. De lo contrario, los nodos habilitados para tener acceso simultáneo a la red
externa son limitados por el número de direcciones en el conjunto global.
Direcciones locales individuales pueden ser estáticamente mapeadas a direcciones globales
específicas para asegurarse acceso garantizado hacia fuera o para permitir acceso al host local desde
hosts externos mediante una dirección pública fija. Sesiones múltiples simultáneas pueden ser
iniciadas desde un nodo local, usando el mismo mapeo de dirección.
PAT – Port Address Translation
Digamos, una organización tiene una red IP privada y una conexión WAN a un proveedor de servicio.
El router de zona de la red privada es asignado a una dirección válida globalmente en la conexión
WAN y los demás nodos en la organización usan direcciones IP que tienen sólo significado local. En
este caso, a los nodos en la red privada se les puede permitir acceder simultáneamente a la red
externa, usando la única dirección IP registrada con la ayuda de PAT. PAT permitiría mapeos del tipo
(direcciones IP local, número de puerto local) a tipos del tipo (dirección IP registrada, número de
puerto asignado).
Este modelo es adecuado para muchos grupos de redes pequeñas para acceder a redes externas
usando una sola dirección IP asignada del proveedor de servicio. Este modelo debe ser extendido
para permitir acceso entrante mapeando estáticamente un nodo local por cada puerto de servicio TU
de la dirección IP registrada.
66/70
Teleprocesos y Redes 2
SRC: 192.168.0.2:1108
DST: 207.28.194.84:80
SRC: 206.245.160.2:61001
DST: 207.28.194.84:80
A
Cliente
192.168.0.2
B
Web Server
207.29.194.84
Router PAT
192.168.0.1
Privada
206.245.160.1
Publica
Internet
SRC: 192.168.0.3:1101
DST: 207.28.194.84:21
Cliente
192.168.0.3
SRC: 206.245.160.2:61002
DST: 202.197.101.111:21
FTP Server
205.197.101.111
Tabla PAT
Interno
Externo
192.168.0.2:1108
61001
192.168.0.3:1108
61002
Figura 4: PAT: ejemplo de funcionamiento de PAT, se usa una sola dirección IP
válida y se conectan diferentes hosts de la red interna hacia Internet por
diferentes puertos.
Fases de Traducción:
- Asociando la dirección, con NAT Básico, una dirección privada se la asocia a una dirección
externa cuando la primera sesión saliente es iniciada desde el host privado. Después de esto,
todas las otras sesiones salientes originadas desde la misma dirección privada usarán la
misma dirección unida por la traducción de paquete.
En el caso de PAT, donde muchas direcciones privadas son mapeadas a un sola dirección
globalmente única, la asociación sería entre <dirección privada y puerto privado> a
<dirección global y puerto asignado>. Como con NAT Básico, esta unión es determinada
cuando la primera sesión saliente es iniciada.
- Búsqueda y traducción de dirección, Después de que una unión de dirección o dirección y
puerto en el caso de PAT se establece, se puede mantener un estado para cada una de las
conexiones. Los paquetes pertenecientes a la misma sesión estarán sujetos a la búsqueda de
sesión para propósitos de traducción.
- Desasociando la dirección, Cuando la última sesión basada en una dirección o dirección y
puerto es terminada, ésta sesión finaliza.
Manipulación de Cabeceras
En el modelo NAT Básico, el encabezado IP de todos los paquetes debe ser modificado. Esta
modificación incluye la dirección IP (dirección IP origen para paquetes salientes y dirección IP destino
para paquetes entrantes) y la suma de control IP.
Para las sesiones TCP y UDP, las modificaciones deben incluir actualización de la suma de control en
los encabezados TCP/UDP. Esto es porque la suma de control de TCP/UDP también cubre un
pseudoencabezado que contiene las direcciones IP origen y destino. Como una excepción, los
encabezados UDP con suma de control 0 no deben ser modificados. Como para los paquetes de
petición ICMP, no son requeridos cambios adicionales en el encabezado ICMP como la suma de
control en el encabezado ICMP que no incluye las direcciones IP.
En el modelo PAT, las modificaciones al encabezado IP son similares a las del modelo NAT Básico.
Para las sesiones TCP/UDP, las modificaciones deben ser extendidas para incluir la traducción del
puerto (puerto origen para paquetes salientes y puerto destino para paquetes entrantes) en el
encabezado TCP/UDP. El encabezado ICMP en los paquetes de petición ICMP deben también ser
67/70
Teleprocesos y Redes 2
modificados para reemplazar el ID de petición y la suma de control del encabezado ICMP. La suma de
control del encabezado ICMP debe ser corregida para contar la traducción del ID de petición.
Estas son algunas de las modificaciones efectuadas:
- Ajuste de la suma de control, las modificaciones de NAT son por paquete y puede ser un
cómputo muy intensivo, ello involucra una o más modificaciones a la suma de control,
inclusive para traducciones de un sólo campo.
- Modificaciones al paquete de error ICMP, los cambios al mensaje de error ICMP incluirán
cambios a los encabezados IP e ICMP en la capa saliente como bien cambios a los
encabezados de los paquetes embebidos en la carga útil del mensaje ICMP-error. El método
para NAT debe ser transparente para el host-final, la dirección IP del encabezado IP
embebido en la carga útil del mensaje ICMP-error debe ser modificado, el campo de suma de
control del encabezado IP embebido debe ser modificado, y finalmente, la suma de control
del encabezado ICMP debe también ser modificada para reflejar los cambios a la carga útil.
- Manipulando la opción IP, un datagrama IP con una de las opciones IP de Registrar Ruta,
Encaminamiento de Origen Fijo o Encaminamiento de Origen No Estricto involucraría registro
o uso de direcciones IP de routers intermedios. Un router NAT intermedio puede elegir no
soportar estas opciones o dejar las direcciones sin traducir mientras que si procesa las
opciones. El resultado de dejar las direcciones sin traducir sería que direcciones privadas a lo
largo del encaminamiento origen son expuestas de extremo a extremo. Esto no debe poner
en peligro la ruta atravesada por el paquete, de hecho, como cada router se supone que mira
sólo al próximo salto.
En general, NAT no debería trabajar con ninguna aplicación que envíe direcciones IP o puertos como
datos. Por ejemplo, cuando dos programas usan FTP mantienen una conexión TCP entre ellos. Como
parte del protocolo, un programa obtiene un número de puerto en la máquina local, y envía los datos
por la conexión TCP al otro programa. Si la conexión entre los programas pasa por medio de un
router configurado con PAT, el puerto podría ser cambiado y reemplazado por el puerto que PAT le
asigne. Así, si NAT falla al cambiar el número de puerto, el protocolo podría fallar. Las
implementaciones de NAT fueron creadas para reconocer puertos conocidos como el de FTP y hacer
los cambios necesarios en el flujo de datos. Pero existen aplicaciones que no pueden ser usadas con
NAT.
Conclusiones
Gracias a la invención de NAT, se detuvo el agotamiento de las direcciones IP válidas, porque permite
que varios hosts dentro de una red privada, tengan acceso a Internet con sólo usar unas pocas
direcciones IP válidas. Esta es una gran ventaja porque le dio un respiro a IPv4 para que no colapse
rápido y dio tiempo para la creación de una nueva versión de IP (IPv6) que soluciones el problema de
agotamiento de direcciones.
Aunque un router que utiliza NAT no es un firewall, provee de cierta seguridad, porque los hosts
externos a la red no conocen las direcciones verdaderas de los hosts que se encuentran dentro de la
red privada, haciendo que sea difícil poder realizar un ataque desde hosts externos.
Una desventaja de PAT es cuando se debe traducir paquetes fragmentados TCP/UDP, sólo el primer
fragmento contiene el encabezado TCP/UDP que sería necesario para asociar el paquete a una sesión
para la traducción. Los fragmentos siguientes no contienen información del puerto, simplemente
llevan el mismo identificador de fragmentación especificado en el primer fragmento. El problema se
presenta cuando dos hosts de la red privada originan paquetes TCP/UDP fragmentados al mismo
host destino, si por coincidencia usaron el mismo identificador de fragmentación, cuando el host
destino recibe los datagramas de ambas fuentes (que no tienen relación entre si) con el mismo
identificador de fragmentación y desde la misma dirección de host asignada, es incapaz de
determinar a cuál de las dos sesiones pertenece cada datagrama y las dos sesiones se corrompen.
68/70
Teleprocesos y Redes 2
RUTEO COMPLETO
Normalmente A generará segmentos TCP de tal forma que el datagrama IP resultante coincida con el
MTU, con lo que no suele haber fragmentación en el origen.
La capa IP llena los campos IP DE DESTINO y PROTOCOLO provisto por TCP. Luego completa el campo
IP DE ORIGEN, inicializa el campo TTL, asigna el número de identificación del datagrama, si no hay
fragmentación inicializa el OFFSET en cero, el MORE FLAG en cero. Finalmente, luego de completar el
resto de los campos calcula el CHECKSUM.
Con la IP DE DESTINO, IP busca en su tabla de ruteo para saber si es una entrega directa o no:
-
En el caso de ser entrega directa, la IP DE ENTREGA será la IP DE DESTINO.
-
En el caso de no ser entrega directa, la IP DE ENTREGA será la IP del GATEWAY por default.
Mediante ARP traduce la IP DE ENTREGA en una dirección de física y luego le pasa dicha dirección y el
datagrama a la capa NAL.
La capa NAL lo encapsule en una trama y lo envía.
El host o router que reconoce su dirección física lee la trama completa de la red, toma el datagrama y
se lo entrega a la capa IP.
-
-
-
IP toma el datagrama y le calcula el CHECKSUM, y lo compara con el campo CHECKSUM del
datagrama. Si son distintos, IP descarta el datagrama y envía un mensaje ICMP (TIPO = 12,
Problema de parámetros para un datagrama) a quien originó el datagrama.
IP decrementa y el TTL del datagrama. Si éste llegó a cero, IP descarta el datagrama y envía
un mensaje ICMP (TIPO = 11, Tiempo excedido para un datagrama) a quien originó el
datagrama.
La capa IP del router toma la IP DE DESTINO del datagrama, y realiza el algoritmo de ruteo.
Para ello busca en su tabla de ruteo si existe una entrada para la red a la que corresponde la
IP.
Si existe una entrada en la tabla de ruteo, y ésta indica que es entrega inmediata, el
algoritmo de ruteo devolverá la misma IP DE DESTINO y por qué interfaz deberá ser enviado
el datagrama.
69/70
Teleprocesos y Redes 2
-
-
-
-
-
Si existe una entrada en la tabla de ruteo, y ésta indica la dirección de un router, el algoritmo
de ruteo devolverá la misma IP del router y por qué interfaz deberá ser enviado el
datagrama.
Si no existe entrada en la tabla de ruteo y existe un router por default, el algoritmo de ruteo
devolverá la IP del router por default como salto al siguiente y por qué interfaz deberá ser
enviado el datagrama.
Si no existe entrada en la tabla de ruteo y tampoco existe un router por default, el router
descarta el datagrama y envía un mensaje ICMP (TIPO = 3, Destino inaccesible) a quien
originó el datagrama.
Una vez que IP sabe por qué interfaz va a enviar el datagrama, chequea si el datagrama
puede ser enviado en una sola trama de esa red o si debe fragmentarlo.
Si no es necesario fragmentar, IP actualiza el TTL y recalcula el CHECKSUM del datagrama; y al
igual que antes utiliza ARP para traducir la dirección de entrega en una dirección física.
Luego IP entrega la dirección física y el datagrama a la capa NAL. La que se encargará de
enviar el datagrama en una trama a dicha dirección física.
Si es necesario fragmentar, y el datagrama tiene el flag de NO FRAGMENTAR = 1, el router
descarta el datagrama y envía un mensaje ICMP (TIPO = 12, Problema de parámetros para un
datagrama) a quien originó el datagrama.
Si es necesario fragmentar, y el datagrama tiene el flag de NO FRAGMENTAR = 0,
70/70