ESTUDIO DE CAPAS DE PROTOCOLOS USADOS EN INTERNET

INGIENERÍA

DE PROTOCOLOS

1.- INTRODUCCION

Antes de comenzar con el estudio con los protocolos que intervienen en las capturas realizadas en prácticas debemos, para ser rigurosos, hacer un escueto resumen del modelo de referencia OSI, para poder ubicar a que nivel trabaja cada protocolo.

2.- MODELO DE REFERENCIA OSI

En 1984, la Organización Internacional de Estandarización (ISO) desarrolló un modelo llamado OSI (Open Systems Interconection, Interconexión de sistemas abiertos). El cual es usado para describir el uso de datos entre la conexión física de la red y la aplicación del usuario final. Este modelo es el mejor conocido y el más usado para describir los entornos de red.

Como se muestra en la figura, las capas OSI están numeradas de abajo hacia arriba. Las funciones más básicas, como el poner los bits de datos en el cable de la red están en la parte de abajo, mientras las funciones que atienden los detalles de las aplicaciones del usuario están arriba.

En el modelo OSI el propósito de cada capa es proveer los servicios para la siguiente capa superior, resguardando la capa de los detalles de como los servicios son implementados realmente. Las capas son abstraídas de tal manera que cada capa cree que se está comunicando con la capa asociada en la otra computadora, cuando realmente cada capa se comunica sólo con las capas adyacentes de la misma computadora.

Con esta ultima figura se puede apreciar que a excepción de la capa más baja del modelo OSI, ninguna capa puede pasar información directamente a su contraparte en la otra computadora. La información que envía una computadora debe de pasar por todas las capas inferiores, la información entonces se mueve a través del cable de red hacia la computadora que recibe y hacia arriba a través de las capas de esta misma computadora hasta que llega al mismo nivel de la capa que envió la información. Por ejemplo, si la capa de red envía información desde la computadora A, esta información se mueve hacia abajo a través de las capas de Enlace y Física del lado que envía, pasa por el cable de red, y sube por las capas de Física y Enlace del lado del receptor hasta llegar a la capa de red de la computadora B.

La interacción entre las diferentes capas adyacentes se llama interfaz. La interfaz define que servicios la capa inferior ofrece a su capa superior y como se accede servicios. Además, cada capa en una computadora actúa como si estuviera comunicándose directamente con la misma capa de la otra computadora. La serie de las reglas que se usan para la comunicación entre las capas se llama protocolo.

2.1.- CAPA FÍSICA

Se encarga de la transmisión de bits a lo largo de un canal de comunicación. Debe asegurarse en esta capa que si se envía un bit por el canal, se debe recibir el mismo bit en el destino. Es aquí donde se debe decidir con cuántos voltios se representará un bit con valor 1 ó 0, cuánto dura un bit, la forma de establecer la conexión inicial y cómo interrumpirla. Se consideran los aspectos mecánicos, eléctricos y del medio de transmisión física. En esta capa se ubican los repetidores, amplificadores, estrellas pasivas, multiplexores, concentradores, modems, codecs, CSUs, DSUs, transceivers, transductores, cables, conectores, NICs, etc. En esta capa se utilizan los siguientes dispositivos: Cables, tarjetas y repetidores (hub). Se utilizan los protocolos RS-232, X.2 1.

En nuestro caso la capa física sobre la que va encapsulado el protocolo IP es Ehernet y a continuación desglosamos brevemente el formato de una de sus tramas:

Datos: el área de datos contiene de 56 bytes a 1500 bytes, por lo que el tamaño de una trama en Ethernet es variable: no menor a 64 bytes ni mayor a 1518 bytes.

• Preámbulo: para permitir a nodos receptores sincronizarse (1's y 0's alternados).

• CRC (Cyclic Redundancy Check:) sirve para detectar errores en la transmisión.

• Tipo de Trama: utilizado para saber el tipo de información que transporta la trama o el protocolo de nivel superior a utilizar, no necesariamente TCP/IP.

2.2.- CAPA DE ENLACE

La tarea primordial de esta capa es la de corrección de errores. Hace que el emisor trocee la entrada de datos en tramas, las transmita en forma secuencial y procese las tramas de asentimiento devueltas por el receptor. Es esta capa la que debe reconocer los límites de las tramas. Si la trama es modificada por una ráfaga de ruido, el software de la capa de enlace de la máquina emisora debe hacer una retransmisión de la trama. Es también en esta capa donde se debe evitar que un transmisor muy rápido sature con datos a un receptor lento. En esta capa se ubican los bridges y switches. Protocolos utilizados: HDLC y LLC.

2.3.- CAPA DE RED

Se ocupa del control de la operación de la subred. Debe determinar cómo encaminar los paquetes del origen al destino, pudiendo tomar distintas soluciones. El control de la congestión es también problema de este nivel, así como la responsabilidad para resolver problemas de interconexión de redes heterogéneas (con protocolos diferentes, etc.). En esta capa se ubican a los ruteadores y switches. Protocolos utilizados: IP, IPX.

2.4.- CAPA DE TRANSPORTE

Su función principal consiste en aceptar los datos de la capa de sesión, dividirlos en unidades más pequeñas, pasarlos a la capa de red y asegurar que todos ellos lleguen correctamente al otro extremo de la manera más eficiente. La capa de transporte se necesita para hacer el trabajo de multiplexión transparente al nivel de sesión. A diferencia de las capas anteriores, esta capa es de tipo origen-destino; es decir, un programa en la máquina origen lleva una conversación con un programa parecido que se encuentra en la máquina destino, utilizando las cabeceras de los mensajes y los mensajes de control. En esta capa se ubican los gateways y el software. Protocolos utilizados: UDP, TCP, SPX.

2.5.- CAPA DE SESIÓN

Esta capa permite que los usuarios de diferentes máquinas puedan establecer sesiones entre ellos. Una sesión podría permitir al usuario acceder a un sistema de tiempo compartido a distancia, o transferir un archivo entre dos máquinas. En este nivel se gestional el control del diálogo. Además esta capa se encarga de la administración del testigo y la sincronización entre el origen y destino de los datos. En esta capa se ubican los gateways y el software.

Servicios de esta capa :

• controlar el díalogo: las sesiones permiten que el tráfico se realice en ambas direcciones o en una sola en un momento dado, cuando se realiza en un solo sentido, esta capa ayudará en el seguimiento de quien tiene el turno.

• administración de testigo: esto es para que en algunos protocolos los dos extremos no quieran transmitir al mismo tiempo, de esta forma sólo lo hace el que posee el testigo (token).

• sincronización: esta capa proporciona la inserción de puntos de verificación para el control de flujo. Esto es pues, si dos computadoras desean transmitir un archivo que lleva dos horas, y al cabo de una hora se interrumpen las conexiones de red, la transmisión se debe desarrollar nuevamente desde el principio, con el servicio que brinda esta capa sólo se transmite lo posterior al punto de verificación.

2.6.- CAPA DE PRESENTACIÓN

Se ocupa de los aspectos de sintaxis y semántica de la información que se transmite y no del movimiento fiable de bits de un lugar a otro. Es tarea de este nivel la codificación de de datos conforme a lo acordado previamente. Para posibilitar la comunicación de ordenadores con diferentes representaciones de datos. También se puede dar aquí la comprensión de datos. En esta capa se ubican los gateways y el software. Protocolos utilizados: VT100.

Básicamente realiza conversiones de datos

• Uso de codigo estándar en la red

• Transforma representaciones computador-red-computador

2.7.- CAPA DE APLICACIÓN

Es en este nivel donde se puede definir un terminal virtual de red abstracto, con el que los editores y otros programas pueden ser escritos para trabajar con él. Así, esta capa proporciona acceso al entorno OSI para los usuarios y también proporciona servicios de información distribuida. En esta capa se ubican los gateways y el software. Protocolos utilizados: X.400

3.- PROTOCOLOS QUE INTERVIENEN

3.1.- PROTOCOLO ETHERNET

3.1.1.- Introducción

En 1973, Robert Metcalfe escribió una tesis para obtener el grado de PhD en el MIT (Instituto Tecnológico de Massachusets - USA), en la que describió la investigación que realizó acerca de las LAN. Posteriormente se trasladó a la compañía Xerox, donde formó un equipo de trabajo, junto con David Bogge y algunos otros colegas, para desarrollar la red Ethernet, basada en las ideas contenidas en su tesis.

Varias compañías la adoptaron con rapidez y posteriormente Intel fabricó un controlador para ella en un solo chip. No pasó mucho tiempo antes de que Ethernet se convirtiera en casi una norma para todas las LAN.

La Ethernet desarrollada por Xerox tuvo tanto éxito, que las compañías Xerox, DEC (Digital Equipment Corporation) e Intel propusieron a la IEEE (Institute of Electrical and Electronics Engineers: Instituto de Ingenieros Eléctricos y Electrónicos), una norma para la Ethernet de 10 Mbps. Esta norma fué la base para la hoy conocida IEEE 802.3, que aunque difiere un poco de su especificación inicial, conserva muchas características originales.

Este sistema se llamó Ethernet, en honor del éter luminífero, a través del cual se pensó alguna vez que se propagaban las ondas electromagnéticas. (Cuando el físico británico del siglo XIX, James Clerk Maxwell, descubrió que la radiación electromagnética podía describirse por medio de una ecuación de onda, los científicos supusieron que el espacio debía estar lleno de algún medio etéreo por el cual se pudiese propagar dicha radiación. Y fué solo después de llevarse a cabo el famoso experimento de Michelson-Morley en 1887, cuando los físicos descubrieron que la radiación electromagnética podía propagarse en el vacío).

Topología de la red:

Existen dos opciones para implementar una red Ethernet.

La primera consiste en conectar todas los computadoras sobre el cable de la red directamente. Esta opción se conoce como topología tipo bus.

La segunda consiste en utilizar un dispositivo llamado hub o concentrador, en el cual se conecta cada uno de los cables de red de las computadoras. Esta topología se conoce como hub.

Transmisión de información en la red:

Para garantizar que las computadoras conectadas en la red puedan comunicarse sin problemas, deben cumplir una serie de normas que se conocen generalmente con el nombre de protocolo. La red Ethernet utiliza un protocolo llamado CSMA/CD (Carrier Sense Multiple Access / Carrier Detect), que quiere decir: Acceso múltiple por detección de portadora con detección de colisión. A continuación haremos una breve descripción de su funcionamiento.

Como todas las computadoras están conectadas sobre el mismo bus, se dice que el cable opera en acceso múltiple. Esto significa que cuando una computadora quiere mandar información hacia otra computadora, debe colocar en el cable todo el paquete de información a ser transmitido. Dicho paquete incluye los datos sobre qué usuario los envía y qué usuario los recibe, además de la información en sí.

Formato de la información:

Los paquetes de información (también conocidos como tramas) que envía cada computadora por la red deben tener un formato específico y cumplir unas normas establecidas, para que sean comprendidas por todos los usuarios de la red. Esas normas cobijan aspectos como la longitud de los paquetes, polaridad o voltaje de los bits, códigos para detección de errores, etc. 

3.1.2.- Servicio

Ethernet está diseñado para cubrir la tierra de nadie entre la redes de ordenador de oficina, especializadas y de baja velocidad y grandes distancias  transportando datos a alta velocidad para distancias muy limitadas. Ethernet suele utilizarse para referirse a todas las LANs tipo "carrier sense multiple access/collision detection (CSMA/CD)" que suelen cumplir con las especificaciones Ethernet, incluyendo IEEE 802.3. Ethernet está bien adaptada a las aplicaciones en que el soporte de comunicaciones local a menudo tiene que procesar un elevado tráfico con puntas elevadas de intercambio de datos.

Las diferencias entre LANs Ethernet y IEEE 802.3 son sutiles. Ethernet proporciona servicios correspondientes a las capas 1 y 2 del modelo de referencia OSI, mientras que IEEE 802.3 especifica la capa física (Capa 1) y la parte de acceso-canal de la capa de enlace (Capa 2), pero no define un protocolo de control de enlace lógico. Así como el resto de funciones de las capas 1 y 2, tanto Ethernet como IEEE 802.3 están implementadas en hardware, en general a través de una tarjeta de interface en un ordenador o a través de una placa principal en el propio ordenador.

3.1.3.- Suposiciones

Capa de aplicación (HTTP, SMTP, FTP, TELNET...)

Capa de transporte (UDP, TCP)

Capa de red (IP)

Capa de acceso a la red (Ethernet, Token Ring...)

Capa física (cable coaxial, par trenzado...)

La capa de acceso a la red determina la manera en que las estaciones (ordenadores) envían y reciben la información a través del soporte físico proporcionado por la capa anterior. Es decir, una vez que tenemos un cable, ¿cómo se transmite la información por ese cable? ¿Cuándo puede una estación transmitir? ¿Tiene que esperar algún turno o transmite sin más? ¿Cómo sabe una estación que un mensaje es para ella? Pues bien, son todas estas cuestiones las que resuelve esta capa.

El nivel más bajo es la capa física. Aquí nos referimos al medio físico por el cual se transmite la información. Generalmente será un cable aunque no se descarta cualquier otro medio de transmisión como ondas o enlaces vía satélite.

Capa de aplicación (HTTP, SMTP, FTP, TELNET...)

Capa de transporte (UDP, TCP)

Capa de red (IP)

Capa de acceso a la red (Ethernet, Token Ring...)

Capa física (cable coaxial, par trenzado...)

Resumen de las características físicas de Ethernet

Características	Ethernet
Velocidad de los datos (Mbps)	10
Método de señalización	Banda de base
Longitud máxima del segmento (m)	500
Soporte	Coaxial de 50-ohmios (grueso)
Topología	Bus

3.1.4.- Vocabulario y formato:

El paquete de Ethernet empieza por un patrón alternativo de unos y ceros denominado preámbulo. El preámbulo indica a las estaciones receptoras que llega un paquete.

El byte que precede a la dirección de destino tanto en un paquete Ethernet es un delimitador inicio-de-paquete, "start-of-frame" (SOF). Este byte finaliza con dos bits uno consecutivos y sirven para sincronizar las partes recibidas del paquete de todas las estaciones de la LAN.

Inmediatamente después del preámbulo se encuentran los campos destino y dirección de origen. Las direcciones tienen una longitud de 6 bytes. Estas están especificadas en el hardware de las tarjetas de interface Ethernet. Los tres primeros bytes los especifica el vendedor de la tarjeta Ethernet, como por ejemplo EPSON. La dirección destino siempre es una dirección única (nodo único), mientras que la dirección destino puede ser única o múltiple (grupo), o de difusión (todos los nodos).

En los paquetes Ethernet, el campo de 2 bytes que sigue a la dirección origen es un campo de tipo. Este campo especifica el protocolo de la capa superior que recibirá los datos después que se haya completado el proceso Ethernet.

A continuación del campo tipo se encuentran los datos reales contenidos en el paquete. Después de completarse el procesamiento de la capa de enlace y la capa física, estos datos se envían eventualmente a un protocolo de capa superior. En el caso Ethernet, el protocolo de capa superior viene identificado en el campo tipo. Si los datos del paquete son insuficientes para llenar el paquete a su tamaño mínimo de 64 bytes, se añaden bytes de relleno para garantizar un paquete con un tamaño mínimo de 64 bytes.

Después del campo de los datos se encuentra el campo FCS de 4 bytes que contiene un valor de comprobación de redundancia cíclica (CRC). El CRC se crea en el dispositivo emisor y lo recalcula el dispositivo receptor para comprobar si el paquete en tránsito ha sufrido daños.

3.1.5.- Reglas de procedimiento

Ethernet está basado en una técnica MAC (Media Access Control) muy sencilla denominada: Carrier Sense Multiple Access with Collision Detection. (CSMA/CD).

Una estación que quiera poner una trama en el cable debe monitorizar previamente el medio de transmisión. Si el medio no está en uso, la estación transmite la trama. La cabecera de la trama contiene la dirección física de la estación de destino, de tal modo que todas las estaciones detectan la presencia de la trama pero tan solo la acepta su destinataria. Si dos o más estaciones transmiten simultáneamente se produce una 'colisión' por lo que las estaciones deben aguardar un tiempo aleatorio antes de reintentar la transmisión.

El protocolo requiere alguna regla más para operar correctamente:

• Existe un tiempo mínimo en el que las estaciones deben guardar silencio entre las transmisiones para permitir que la estación receptora pueda procesar una trama antes de recibir la siguiente. Este tiempo es de 9'6 microsegundos. Un transceptor averiado puede producir errores de alineamiento.

• Las tramas deben ser lo suficientemente largas como para permitir que al producirse una colisión todas las estaciones la detecten. La longitud mínima requerida para una trama Ethernet es de 64 octetos. Las tramas menores de este tamaño (usualmente producidas por la detección de una colisión) se denominan: runts.

• También existe una longitud máxima para las tramas: 1518 octetos. Como resultado del comportamiento anómalo de un transceptor , pueden generarse tramas de mayor tamaño: jabbers.

3.1.5.1.- Sincronismo y temporización

Las comunicaciones en las redes Ethernet están sincronizadas mediante el uso de ranuras o slots. Un slot es el tiempo mínimo que necesita una trama para alcanzar todas las estaciones de la red, siendo este tiempo igual a: 51'2 µs ó 512 bits. -recordemos que Ethernet funciona a 10 Mbits/seg.- Los adaptadores de red al detectar una colisión envían a la red una señal denominada: jam, (secuencia repetitiva de bits aleatorios) y esperan un número de slots al azar antes de retransmitir la trama. Un registro de reintentos, integrado en el propio adaptador, se incrementa para cada nueva retransmisión. Si el adaptador alcanza la cifra de 16 reintentos sin éxito, se abandona la comunicación, reportándolo a las capas superiores, al entender que el medio de transmisión ha sufrido alguna alteración que lo hace inutilizable o que el número de colisiones es tan alto que el nodo ha perdido la oportunidad de poder comunicar. De este modo de operación se desprenden algunas conclusiones:

• El rendimiento de una red Ethernet se degrada sustancialmente con un tráfico superior al 30%.

• El hecho de no respetar las recomendaciones en cuanto a las longitudes máximas y mínimas del cableado implica errores de temporización que se traducen directamente en colisiones.

• El número de colisiones se ve a su vez incrementado al rebasar el número máximo de nodos que se pueden conectar simultáneamente a la red.

3.1.6.- Evolución de Ethernet

Al tratarse de una tecnología relativamente antigua (20 años), la Ethernet se ha visto en los últimos tiempos ante el difícil compromiso de evolucionar.

Las siguientes técnicas muestran esta evolución:

• Full Duplex Ethernet

• 100BASET y Anylan

• Ethernet Síncrono

• Gigabit Ethernet

3.2.- PROTOCOLO IP

3.2.1.- Introducción

El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de un proyecto dirigido por el ingeniero norteamericano Robert Kahn y patrocinado por la Agencia de Programas Avanzados de Investigación (ARPA, siglas en inglés) del Departamento Estadounidense de Defensa. Internet comenzó siendo una red informática de ARPA (llamada ARPAnet) que conectaba redes de ordenadores de varias universidades y laboratorios en investigación en Estados Unidos. World Wibe Web se desarrolló en 1989 por el informático británico Timothy Berners-Lee para el Consejo Europeo de Investigación Nuclear (CERN, siglas en francés).

3.2.2.- Servicio

Los retos de encaminamiento son:

• Proporcionar una manera unívoca de identificar los orígenes y destinos de tráfico (direcciones IP).

• Necesidad de una solución apta para grandes redes.

• La solución además debe manejar el problema de la interconexión de redes heterogéneas(internetworking), de muy distinto soporte físico y/o de organizaciones independientes.

Los programas sobre el nivel IP deben ver simpliemente la red como una entidad que comunica dos puntos identificados por su dirección IP.

Los criterios de diseño que se determinaron fueron:

• Protocolo sin conexión: Los datagramas con mismo origen y destino son tratados de forma totalmente independiente por los encaminadote, y pueden seguir distintos caminos a su destino.

• Protoclo no confiable, y de entrega best-effort.

• El protocolo debe ocultar toda la problemática de la interconexión de redes a las capas superiores, que tienen una visión de una red virtual que les resuelve el problema de enviar y recibir datagramas.

3.2.3.- Suposiciones

Capa de aplicación (HTTP, SMTP, FTP, TELNET...)

Capa de transporte (UDP, TCP)

Capa de red (IP)

Capa de acceso a la red (Ethernet, Token Ring...)

Capa física (cable coaxial, par trenzado...)

Aunque sabemos que nuestro datagrama IP debe atravesar multitud de redes heterogéneas para llegar a su destino (www.upct.es) suponemos que va encapsulado sobre el protocolo Ethernet II.

El siguiente diagrama ilustra el lugar del protocolo internet en la jerarquía de protocolos:

+------+ +-----+ +-----+ +-----+

|Telnet| | FTP | | TFTP| ... | ... |

+------+ +-----+ +-----+ +-----+

| | | |

+-----+ +-----+ +-----+

| TCP | | UDP | ... | ... |

+-----+ +-----+ +-----+

| | |

+--------------------------+----+

| Protocolo Internet & ICMP |

+--------------------------+----+

|

+---------------------------+

| Protocolo de la Red Local |

+---------------------------+

Relación entre Protocolos

El protocolo Internet interactúa por un lado con los protocolos host-a-host de alto nivel y por otro con el protocolo de la red local.

3.2.4.- Vocabulario

Opciones IP: Existen hasta 40 bytes extra en la cabecera del Datagrama IP que pueden llevar una o más opciones. Su uso es bastante raro.

• Uso de Ruta Estricta (Camino Obligatorio)

• Ruta de Origen Desconectada (Nodos Obligatorios)

• Crear registro de Ruta

• Marcas de Tiempo

• Seguridad Básica del Departamento de Defensa

• Seguridad Extendida del Departamento de Defensa.

3.2.4.1.- Definiciones de Opciones Específicas

Fin de la lista de opciones

+--------+

|00000000|

+--------+

Tipo=0

Esta opción indica el final de la lista de opciones. Esta puede no coincidir con el final de la cabecera internet ségún expresa la longitud de cabecera internet. Se usa al final de todas las opciones, no al final de cada opción, y sólo es necesario usarla si, caso de no hacerlo, el final de las opciones no coincidiera con el final de la cabecera internet.

Puede ser copiado, introducido o borrado en la fragmentación, o por cualquier otra razón.

Sin Operación

+--------+

|00000001|

+--------+

Tipo=1

Esta opción puede usarse entre opciones para, por ejemplo, ajustar el comienzo de una opción siguiente a una posición múltiplo de 32 bits.

Puede ser copiado, introducido o borrado en la fragmentación, o por cualquier otra razón.

Seguridad

Esta opción proporciona a los hosts una forma de enviar parámetros de seguridad, compartimentación, manejo de restricciones y TCC (grupo de usuarios cerrado). El formato de esta opción es el siguiente:

+--------+--------+---//---+---//---+---//---+---//---+

|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |

+--------+--------+---//---+---//---+---//---+---//---+

Tipo=130 Longitud=11

Seguridad (campo S): 16 bits

Especifica uno de entre 16 niveles de seguridad (ocho de los cuales están reservados para uso futuro)

00000000 00000000 - 14 - - No Clasificado

11110001 00110101 - Confidencial

01111000 10011010 - EFTO

10111100 01001101 - MMMM

01011110 00100110 - PROG

10101111 00010011 - Restringido

11010111 10001000 - Secreto

01101011 11000101 - Alto Secreto

00110101 11100010 - (Reservado para uso futuro)

10011010 11110001 - (Reservado para uso futuro)

01001101 01111000 - (Reservado para uso futuro)

00100100 10111101 - (Reservado para uso futuro)

00010011 01011110 - (Reservado para uso futuro)

10001001 10101111 - (Reservado para uso futuro)

11000100 11010110 - (Reservado para uso futuro)

11100010 01101011 - (Reservado para uso futuro)

Compartimentos (Campo C): 16 bits

Cuando la información no está compartimentada se usa un valor de todo ceros. Otros valores para el campo Compartimentos pueden obtenerse de la Agencia de Inteligencia de Defensa.

Manejo de Restricciones (campo H): 16 bits

Los valores para los marcadores de control y liberación son digrafos alfanuméricos y están definidos en el Manual DIAM 65-19 "Marcadores de Seguridad Estándar", de la Agencia de Inteligencia de Defensa.

Código de Control de Transmisión (Campo TCC): 24 bits

Proporciona un mecanismo para segregar el tráfico y definir comunidades de interés controladas entre diversos suscriptores. Los valores TCC son trigrafos, se pueden encontrar en "HQ DCA Code 530". Debe copiarse al fragmentar. Esta opción aparece como máximo una vez en un datagrama.

Ruta de Origen No Estricta y Registrar Ruta

+--------+--------+--------+---------//--------+

|10000011| long. | puntero| datos de ruta |

+--------+--------+--------+---------//--------+

Tipo=131

La opción de Encaminamiento de Origen No Estricto y Registrar Ruta ("loose source and record route (LSRR)") proporciona un mecanismo mediante el cual el origen de un datagrama internet puede suministrar información de encaminamiento que será usada por las pasarelas para transmitir el datagrama a su destino, y para almacenar la información de la ruta.

La opción comienza con el código de tipo de opción. El segundo octeto es la longitud de la opción que incluye al código de tipo de opción, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta. El tercer octeto es el puntero a los datos de ruta que indica el octeto en el cual comienza la siguiente dirección de origen a procesar. El puntero es relativo a esta opción, y el valor legal más pequeño para el puntero es 4.

Los datos de ruta se componen de una serie de direcciones internet. Cada dirección internet son 32 bits o 4 octetos. Si el puntero es mayor que la longitud, la ruta de origen está vacía (y la ruta registrada llena) y el encaminamiento debe basarse en el campo de la dirección de destino.

Si se ha alcanzado la dirección indicada en el campo dirección de destino y el puntero no es mayor que la longitud, la siguiente dirección en la ruta de origen sustituye a la dirección del campo de dirección de destino, y la dirección de ruta registrada sustituye a la dirección de origen recién usada, y se suma cuatro al puntero.

La dirección de ruta registrada es la propia dirección internet que tiene el módulo internet en el entorno en el cual el datagrama está siendo reenviado.

Este procedimiento de sustituir la ruta de origen con la ruta registrada (si bien está en orden inverso del necesario para ser usada como ruta de origen) significa que la opción (y la cabecera IP en su totalidad) sigue teniendo una longitud constante a medida que el datagrama progresa a través de internet.

Esta opción es una ruta de origen no estricta porque la pasarela o IP del host puede utilizar cualquier ruta con cualquier número de pasarelas intermedias para alcanzar la siguiente dirección en la ruta.

Debe copiarse al fragmentar. Aparece como máximo una vez en un datagrama.

Ruta de Origen Estricta y Registrar Ruta

+--------+--------+--------+---------//--------+

|10001001| long. | puntero| datos de ruta |

+--------+--------+--------+---------//--------+

Tipo=137

La opción de Ruta de Origen Estricta y Registrar Ruta (strict source and record route (SSRR)) proporciona al origen de un datagrama internet un medio de suministrar información de encaminamiento a ser usada por las pasarelas al reenviar el datagrama al destino y para registrar la información de la ruta.

La opción comienza con el código de tipo de opción. El segundo octeto es la longitud de la opción que incluye al código de tipo de opción, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta. El tercer octeto es el puntero a los datos de ruta que indica el octeto en el cual comienza la siguiente dirección de origen a procesar. El puntero es relativo a esta opción, y su menor valor legal es 4.

Los datos de ruta se componen de una serie de direcciones internet. Cada dirección internet son 32 bits o 4 octetos. Si el puntero es mayor que la longitud, la ruta de origen está vacía (y la ruta registrada llena) y el encaminamiento debe basarse en el campo de la dirección de destino.

Si se ha alcanzado la dirección indicada en el campo de dirección de destino y el puntero no es mayor que la longitud, la siguiente dirección en la ruta de origen sustituye a la dirección del campo de dirección de destino, y la dirección de ruta registrada sustituye a la dirección de origen recién usada, y se suma cuatro al puntero.

La dirección de ruta registrada es la propia dirección internet del módulo internet tal y como es en el entorno en el cual el datagrama está siendo reexpedido.

Este procedimiento de sustituir la ruta de origen con la ruta registrada (si bien está en orden inverso del necesario para ser usada como ruta de origen) significa que la opción (y la cabecera IP en su totalidad) sigue teniendo una longitud constante a medida que el datagrama progresa a través de internet.

Esta opción es una ruta de origen estricta porque la pasarela o el IP del host deben enviar el datagrama directamente a la siguiente dirección en la ruta de origen sólamente a través de la red conectada directamente indicada en la siguiente dirección, para alcanzar la siguiente pasarela o host especificado en la ruta.

Debe copiarse al fragmentar. Aparece como máximo una vez en un datagrama.

Registrar Ruta

+--------+--------+--------+---------//--------+

|00000111| long. | puntero| datos de ruta |

+--------+--------+--------+---------//--------+

Tipo=7

La opción de Registrar Ruta proporciona un mecanismo para registrar la ruta de un datagrama internet.

La opción comienza con el código de tipo de opción. El segundo octeto es la longitud de la opción que incluye al código de tipo de opción, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta. El tercer octeto es el puntero a los datos de ruta que indica el octeto en el cual comienza la siguiente área para almacenar una dirección de ruta. El puntero es relativo a esta opción, y su menor valor legal es 4.

Una ruta registrada se compone de una serie de direcciones internet. Cada dirección internet son 32 bits o 4 octetos. Si el puntero es mayor que la longitud, el area de datos de la ruta registrada esta llena. El host de origen debe construir esta opción con una área de datos de ruta con suficiente espacio para contener todas las direcciones esperadas. El tamaño de la opción no cambia al agregar direcciones. El contenido inicial del área de datos de ruta debe ser cero.

Cuando un módulo internet encamina un datagrama, comprueba si la opción Registrar ruta está presente. Si lo está, inserta su propia dirección internet, tal y como se la conoce en el entorno en el cual el datagrama está siendo transmitido, en la ruta registrada, comenzando en el octeto indicado por el puntero, e incrementa el puntero en cuatro. Si el área de datos de ruta ya está llena (el puntero sobrepasa a longitud) el datagrama es transmitido sin insertar la dirección en la ruta registrada. Si hay algo de espacio pero no el suficiente para insertar una dirección completa, el datagrama original es considerado erróneo y descartado. En ambos casos se puede enviar un mensaje de problema de parámetros ICMP al host de origen [3]. No se copia al fragmentar, va sólo en el primer fragmento. Aparece como máximo una vez en un datagrama.

Identificador de Flujo

+--------+--------+--------+--------+

|10001000|00000010| ID de Flujo |

+--------+--------+--------+--------+

Tipo=136 Longitud=4

Esta opción proporciona una forma de transportar el identificador de flujo SATNET de 16 bits a través de redes que no soportan el concepto de flujo.

Debe copiarse al fragmentar. Aparece como máximo una vez en un datagrama.

Marca de tiempo Internet

+--------+--------+--------+--------+

|01000100| long. | puntero|oflw|flg|

+--------+--------+--------+--------+

| dirección internet |

+--------+--------+--------+--------+

| Marca de tiempo |

+--------+--------+--------+--------+

| . |

.

.

Tipo = 68

La Longitud de opción es el número de octetos en la opción contando los octetos de tipo, longitud, puntero y desbordamiento/indicadores (oflw/flg, overflow/flags) (máxima longitud: 40)

El puntero es el número de octetos desde el principio de esta opción hasta el final de las marcas de tiempo mas uno (es decir, apunta al octeto de comienzo del espacio para la siguiente marca de tiempo). El valor legal mínimo es 5. El área de marca de tiempo está llena cuando el puntero es mayor que la longitud.

El Desbordamiento (oflw) (4 bits) es el número de módulos IP que no han podido registrar marcas de tiempo debido a falta de espacio.

Los valores de los Indicadores (4 bits) son

0 -- Sólo marcas de tiempo, almacenadas en palabras de 32 bits consecutivas

1 -- cada marca de tiempo es precedida con la dirección internet de la entidad registradora

3 -- Los campos de dirección internet están preespecificados.

Un módulo IP registra su marca de tiempo sólo si su dirección concuerda con la siguiente dirección internet especificada.

La Marca de Tiempo es una marca temporal de 32 bits, justificada a la derecha, en milisegundos desde la medianoche UT. Si el tiempo no está disponible en milisegundos o no puede darse con respecto a la medianoche UT, entonces se puede insertar cualquier tiempo como marca de tiempo, siempre que el bit de mayor orden sea puesto a uno para indicar el uso de un valor no estándar.

El host de origen debe construir está opción con un área de datos para la marca de tiempo lo sufucientemente grande para que quepa toda la información de marcas temporales esperada. El tamaño de la opción no cambia al añadir marcas de tiempo. El contenido inicial del área de datos de marcas de tiempo debe ser cero o pares dirección Internet/cero.

Si el área de datos de marca de tiempo ya está llena (el puntero sobrepasa a la longitud) el datagrama es transmitido sin insertar marca de tiempo, pero el contador de desbordamiento es incrementado en uno.

Si hay algo de espacio pero no el suficiente para insertar una marca de tiempo completa, o el contador de desbordamiento el mismo se desborda, el datagrama original es considerado erróneo y descartado. En ambos casos se puede enviar un mensaje de problema de parámetros ICMP al host de origen [3].La opción de marca de tiempo no se copia al fragmentar. Es transportada sólo en el primer fragmento. Aparece como máximo una vez en un datagrama.

Valor de Relleno: variable

El Valor de Relleno se usa para asegurar que la cabecera Internet ocupa un múltiplo de 32 bits. El valor de relleno es cero.

3.2.5.- Formato:

El esquema de envío de IP es similar al que se emplea en la capa Acceso a red. En esta ultima se envían Tramas formadas por un Encabezado y los Datos. En el Encabezado se incluye la dirección física del origen y del destino.

En el caso de IP se envían Datagramas, estos también incluyen un Encabezado y Datos, pero las direcciones empleadas son Direcciones IP.

Encabezado

Datos

Los datagramas IP están formados por Palabras de 32 bits. Cada datagrama tiene un mínimo (y tamaño más frecuente) de cinco palabras y un máximo de quince.

Ver	Hlen	TOS	Longitud Total
Identificación			Flags	Desp. De Fragmento
TTL		Protocolo	Checksum
Dirección IP de la Fuente
Dirección IP del Destino
Opciones IP (Opcional)					Relleno
DATOS

 

• Ver: Versión de IP que se emplea para construir el Datagrama. Se requiere para que quien lo reciba lo interprete correctamente. La actual versión IP es la 4.

• Hlen: Tamaño de la cabecera en palabras.

• TOS: Tipo de servicio. La gran mayoría de los Host y Routers ignoran este campo. Su estructura es:

Prioridad

D

T

R

Sin Uso

La prioridad (0 = Normal, 7 = Control de red) permite implementar algoritmos de control de congestión más eficientes. Los tipos D, T y R solicitan un tipo de transporte dado: D = Procesamiento con retardos cortos, T = Alto Desempeño y R = Alta confiabilidad. Nótese que estos bits son solo "sugerencias", no es obligatorio para la red cumplirlo.

• Longitud Total: Mide en bytes la longitud de doto el Datagrama. Permite calcular el tamaño del campo de datos: Datos = Longitud Total - 4 * Hlen.

• Identificación: Numero de 16 bits que identifica al Datagrama, que permite implementar números de secuencias y que permite reconocer los diferentes fragmentos de un mismo Datagrama, pues todos ellos comparten este numero.

• Banderas(Flags): Un campo de tres bits donde el primero está reservado. El segundo, llamado bit de No - Fragmentación significa: 0 = Puede fragmentarse el Datagrama o 1 = No puede fragmentarse el Datagrama. El tercer bit es llamado Más - Fragmentos y significa: 0 = Unico fragmento o Ultimo fragmento, 1 = aun hay más fragmentos. Cuando hay un 0 en más - fragmentos, debe evaluarse el campo desp. De Fragmento: si este es cero, el Datagrama no esta fragmentado, si es diferente de cero, el Datagrama es un ultimo fragmento.

• Desp. De Fragmento: A un trozo de datos se le llama Bloque de Fragmento. Este campo indica el tamaño del desplazamiento en bloques de fragmento con respecto al Datagrama original, empezando por el cero.

• TTL: Tiempo de Vida del Datagrama, especifica el numero de segundos que se permite al Datagrama circular por la red antes de ser descartado.

• Protocolo: Especifica que protocolo de alto nivel se empleó para construir el mensaje transportado en el campo datos de Datagrama IP. Algunos valores posibles son: 1 = ICMP, 6 = TCP, 17 = UDP, 88 = IGRP (Protocolo de Enrutamiento de Pasarela Interior de CISCO).

• Checksum: Es un campo de 16 bits que se calcula haciendo el complemento a uno de cada palabra de 16 bits del encabezado, sumándolas y haciendo su complemento a uno. Esta suma hay que recalcularla en cada nodo intermedio debido a cambios en el TTL o por fragmentación.

• Dirección IP de la Fuente: 32 bits. Dirección IP de la máquina que originó el datagrama.

• Dirección IP del Destino: 32 bits. Dirección IP de la máquina destino.

• Opciones IP: Existen hasta 40 bytes extra en la cabecera del Datagrama IP que pueden llevar una o más opciones. Su uso es bastante raro.

• Uso de Ruta Estricta (Camino Obligatorio)

• Ruta de Origen Desconectada (Nodos Obligatorios)

• Crear registro de Ruta

• Marcas de Tiempo

• Seguridad Básica del Departamento de Defensa

• Seguridad Extendida del Departamento de Defensa

3.2.6.- Reglas de procedimiento:

En primer lugar, el tamaño de un Datagrama debe ser tal que permita la encapsulación, esto es, enviar un Datagrama completo en una trama física. El problema está en que el Datagrama debe transitar por diferentes redes físicas, con diferentes tecnologías y diferentes capacidades de transferencia. A la capacidad máxima de transferencia de datos de una red física se le llama MTU (el MTU de ethernet es 1500 bytes por trama, la de FDDI es 4497 bytes por trama). Cuando un Datagrama pasa de una red a otra con un MTU menor a su tamaño es necesaria la fragmentación. A las diferentes partes de un Datagrama se les llama fragmento. Al proceso de reconstrucción del Datagrama a partir de sus fragmentos se le llama Reensamblado de fragmentos.

El control de la fragmentación de un Datagrama IP se realiza con los campos de la segunda palabra de su cabecera:

• Identificación: Numero de 16 bits que identifica al Datagrama, que permite implementar números de secuencias y que permite reconocer los diferentes fragmentos de un mismo Datagrama, pues todos ellos comparten este numero.

• Banderas: Un campo de tres bits donde el primero está reservado. El segundo, llamado bit de No - Fragmentación significa: 0 = Puede fragmentarse el Datagrama o 1 = No puede fragmentarse el Datagrama. El tercer bit es llamado Más - Fragmentos y significa: 0 = Unico fragmento o Ultimo fragmento, 1 = aun hay más fragmentos. Cuando hay un 0 en más - fragmentos, debe evaluarse el campo desp. De Fragmento: si este es cero, el Datagrama no esta fragmentado, si es diferente de cero, el Datagrama es un ultimo fragmento.

• Desp. De Fragmento: A un trozo de datos se le llama Bloque de Fragmento. Este campo indica el tamaño del desplazamiento en bloques de fragmento con respecto al Datagrama original, empezando por el cero.

El reensamblado de todos los fragmentos los realiza el receptor. Cuando llega un datagrama con el campo FLAGS activado (fragmento), se lanza un temporizador que espera a recibir el resto de fragmentos del datagrama (con el mismo campo IDENTIFICACION) y se reconstruye el datagrama atendiendo al campo FRAGMENT OFFSET y LENGTH. Si se vence y aun no llegan TODOS, entonces se descartan los que ya han llegado y se solicita el reenvío del Datagrama completo.

3.2.7.- Nueva versión IPv6:

La nueva versión del protocolo IP recibe el nombre de IPv6, aunque es también conocido comúnmente como IPng (Internet Protocol Next Generation). El número de versión de este protocolo es el 6 (que es utilizada en forma mínima) frente a la antigua versión utilizada en forma mayoritaria. Los cambios que se introducen en esta nueva versión son muchos y de gran importancia, aunque la transición desde la versión antigua no debería ser problemática gracias a las características de compatibilidad que se han incluido en el protocolo. IPng se ha diseñado para solucionar todos los problemas que surgen con la versión anterior, y además ofrecer soporte a las nuevas redes de alto rendimiento (como ATM, Gigabit Ethernet, etc.)

Una de las características más llamativas es el nuevo sistema de direcciones, en el cual se pasa de los 32 a los 128 bit, eliminando todas las restricciones del sistema actual. Otro de los aspectos mejorados es la seguridad, que en la versión anterior constituía uno de los mayores problemas. Además, el nuevo formato de la cabecera se ha organizado de una manera más efectiva, permitiendo que las opciones se sitúen en extensiones separadas de la cabecera principal.

3.3.- PROTOCOLO ICMP

3.3.1.- Introducción

ICMP (Internet Control Message Protocol) (RFC 792) permite el intercambio de mensajes de control y de supervisión entre dos ordenadores. Toda anomalía detectada por el protocolo IP provoca el intercambio de mensajes ICMP entre los nodos de la red. Este protocolo forma parte de la capa internet y usa la facilidad de enviar paquetes IP para enviar mensajes.

3.3.2.- Servicio

ICMP es un protocolo de control que utilizan los dispositivos de encaminamiento para notificar las diferentes incidencias que pueden haber en una red IP. Está definido en el RFC 792. Proporciona información de realimentación sobre los problemas que ocurren y por ejemplo se utiliza cuando:

• Un datagrama no puede alcanzar su destino.

• El dispositivo de encaminamiento no tiene la capacidad de almacenar temporalmente el datagrama para poderlo reenviar.

• El dispositivo de encaminamiento indica a un ordenador que envíe el tráfico por una ruta mas corta (redireccionamiento de rutas).Cada mensaje ICMP se encapsula en un paquete IP y luego es enviado de la forma habitual. Como los mensajes ICMP se transmiten en mensajes IP, no se puede garantizar que llegue a su destino.

3.3.3.- Suposiciones

ICMP utiliza el soporte básico de IP como si se tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integrante de IP, y debe ser implementado por todo módulo IP. Aunque muchos de sus servicios también están disponibles a otros niveles, deben utilizarse con precaución. El hecho de que las capas superiores puedan utilizar el ICMP es una de las razones por las que IP envía hacia arriba la cabecera IP original de los datagramas que se reciben. La comunicación con el resto de los procesos se realiza única y exclusivamente a través del intercambio de mensajes.

3.3.4.- Vocabulario

La primera versión del ICMP [RFC792] define una serie de mensajes de control que incluyen:

MENSAJE	DESCRIPCIÓN
Destino inalcanzable (Destination Unreachable)	Un datagrama no puede llegar a su host, utilidad o aplicación de destino
Plazo superado (Time Exceeded)	El tiempo de vida ha expirado en un encaminador o el plazo de reensamblado ha expirado en un host de destino
Problema de los parámetros (Parameter Problem)	Existe un parámetro erróneo en la cabecera de IP
Acallado de origen (Source Problem)	Un encaminador o un destino está congestionado. Se recomienda que los sistemas no envíen mensajes de acallado
Redirigir (Redirect)	Un host ha enviado un datagrama al encaminador local equivocado

3.3.5.- Formato

Recuerde que los mensajes de ICMP se transmiten en la parte de datos de un datagrama de IP. Cada mensaje de ICMP empieza con los mismos tres campos: un campo de Tipo, un campo de Código que a veces ofrece descripción concreta del error y un campo Suma de control. El formato del resto del mensaje viene determinado por el tipo. Los mensajes de error de ICMP incluyen la cabecera de IP y los 8 primeros octetos del datagrama que ocasionó el error. Esta información se puede utilizar para resolver el problema, ya que incluye datos como el destino previsto y protocolo destino de la capa 4. Al mensaje de ICMP se le aplica la suma de control de ICMP, empezando desde el campo Tipo. Los tipos de mensaje son:

3.3.5.1.- Mensaje destino inalcanzable.

La entrega de un datagrama puede fallar en muchos momentos. Debido a un enlace roto, a un encaminador físicamente incapaz de llegar a una subred de destino o para ejecutar el siguiente salto de encaminamiento. El destino puede estar fuera de servicio por labores de mantenimiento. Todos sabemos que en esta tiempo podemos encontrar dispositivos inteligentes que corten el paso a host de la red por administración segura de sus redes, pues entonces tambien estariamos con un mensaje de control de este tipo. El tipo de ICMP es el 3 y en el campo codigo pueden haber distintos valores que expondremos ahora mismo:

Tipo = 3 "Código" Suma de control

No usado

Cabecera de Internet + 8 octetos de los datos del datagrama original

Código	Significado
0	No se puede llegar a la red.
1	No se puede llegar al host.
2	El destino no dispone del protocolo solicitado.
3	No se puede llegar al puerto. Puede que la aplicación de destino no esté libre.
4	Se necesita realizar fragmentación, pero se ha establecido la bandera "No fragmentar".
5	La ruta de origen no es correcta.
6	No se conoce la red de destino.
7	No se conoce el host de destino.
8	El host origen está aislado.
9	La comunicación con la red de destino está prohibida por razones administrativas.
10	La comunicación con el host de destino está prohibida por razones administrativas.
11	No se puede llegar a la red debido al Tipo de servicio.
12	No se puede llegar al host debido al Tipo de servicio.

3.3.5.2.- Tiempo de vida

Un datagrama puede expirar porque su tiempo de vida ha llegado a cero mientras se encontraba en tránsito. Otra razón es cuando el plazo de reensamblado del host expira antes de que lleguen todos los fragmentos. En cualquier caso, se envía un mensaje de ICMP de Plazo expirado al origen del datagrama. El formato del mensaje es el siguiente:

Tipo = 11 "Código" Suma de control

No usado

Cabecera de Internet + 8 octetos de los datos del datagrama original

Los valores de los códigos indican la naturaleza del plazo, y se pueden ver en la siguiente tabla:

Código	Significado
0	Se ha excedido el tiempo de vida
1	Ha expirado el plazo de reensamblado

3.3.5.3.- Problema de parámetros IP

El mensaje de ICMP Problemas de parámetros se usa para informar de otros problemas que no se cubre con ningún otro mensaje de error. Por ejemplo, puede existir información inconsistente en un campo de opciones que que sea imposible procesar el datagrama correctamente, por lo que hay que descartarlo. Lo más habitual en cuanto a problemas de parámetros se debe a errores de implementación en el sistema que escribió los parámetros en la cabecera de IP. En el formato del mensaje que estamos explicando, aparece un nuevo campo, "Apuntador", te dice en que octeto a detectado el fallo. El formato del mensaje es:

Tipo = 12 "Código" Suma de control

Apuntador No usado

Cabecera de Internet + 8 octetos de los datos del datagrama original

Código	Significado
0	El valor del campo apuntador indica el octeto donde se detectó el error.
1	Falta una opción obligatoria, se indica en la comunidad militar para indicar que falta una opción de seguridad.
2	Tamaño incorrecto

3.3.5.4.- Acallamiento de origen

Este mensaje no es muy efectivo, ya que ¿Cuándo, y quién, debería enviar un mensaje de acallamiento de origen?. Cuando un encaminador se ve colapsado puede que el datagrama que descarte no sea del origen que lo esta colapsando, por eso se esta intentando encontrar algo más efectivo que un Acallamiento de origen. El formato del mensaje es el siguiente:

Tipo = 4 "Código" Suma de control

No usado

Cabecera de Internet + 8 octetos de los datos del datagrama original



3.3.5.5.- Mensaje redirección

Puede que haya mas de un encaminador conectado a la LAN. Si el host local envía un datagrama al encaminador equivocado, el encaminador reenviará el datagrama y un mensaje Redirección (Redirect) al host origen, como se muestra en la Figura 7.8. El jost debería enviar el tráfico siguiente al encaminador con la ruta más corta. Los mensajes Redirección se pueden usar para reducir el trabajo manual de administración. Se puede configurar un encaminador con un único encaminador por defecto y que aprenda dinámicamente sobre las rutas que van por otros encaminadores. Algunos protocolos de encaminamiento pueden elegir el camino de entrea según el campo Tipo de servicio (TOS). Los codigos 2 y son consejos que reflejan estas consideraciones. El formato de los mensajes Redirección es:

Tipo = 5 "Código" Suma de control

Dirección del encaminador a usar

Cabecera de Internet + 8 octetos de los datos del datagrama original

Y la tabla con los codigos y su significado es:

Código	Significado
0	Redirigir los datagramas debido a la red.
1	Redirigir los datagramas debido al host.
2	Redirigir los datagramas debido al Tipo de servicio (TOS) y a la red.
3	Redirigir los datagramas debido al Tipo de servicio (TOS) y al host.

3.3.5.6.- Mensajes de petición de ICMP

No todos los mensajes ICMP son señales de error. Algunos se usan para obtener información útil de la red. ¿está vivo el host?¿Está ejecutando el host Y? ... Concretamente, entre los mensajes de petición de ICMP están:

• Mensajes de petición y respuesta de ECO (ECHO) que pueden intercambiar con los host y con los encaminadotes.

• Mensajes de petición y respuesta de la Máscara de dirección que permite a un sistema descubrir la máscara de dirección que debería asignar a una interfaz.

• Mensajes de petición y respuesta de Marca de tiempo que lee el reloj de un sistema dado.

El objetivo es que la respuesta dé una idea de cuanto tiempo le lleva al sistema procesar un datagrama.

3.3.5.6.1.- Petición y respuesta de ECO

La petición de ECO y la respuesta de ECO se usan para comprobar si un sistema está activo. Se usa Tipo = 8 para la petición y Tipo = 0 para la respuesta. El número de octetos del campo de datos es variable y se selecciona en el origen. El destino debe enviar de vuelta el mismo mensaje recibido. El campo "Indentificador" se usa para hacer coincidir la respuesta con la petición original. Se puede enviar una secuencia de ocho mensajes para comprobar si la red está tirando mensajes y estimar el tiempo medio de ida y vuelta. Para ello, se deja fijo el identificador y el número de secuencia se incrementa con cada mensaje, empezando en cero. Formato de ECO:

Tipo = 8 o 0 "Código" Suma de control

Identificador Número de secuencia

DATOS

3.3.5.6.2.- Máscara de dirección.

Recuerde que una organización puede decidir dividir sus campos de direcciones locales en parte de subred y parte de host. Cuando se arranca un sistema puede que no esté configurado para conocer cuantos bits se le han asignado al campo de dirección de subred. Para obtenerlo, el sistema puede difundir una petición de Máscara de Dirección. La respuesta debería enviarla un servidor autorizado de Máscaras de Dirección. Normalmente, se supone que el servidor sea un encaminador, pero a veces puede usarse un host. La respuesta pondrá a uno los campos de red y subred del camo de Máscara de dirección en cuanto esté activo de nuevo. Se hace así en beneficio de los sitemas que hayan arrancado mientras no estaba disponible el servidor.

El tipo 17 es para la petición y el Tipo 18 para la respuesta. Generalmente se pueden ignorar los campos de número de secuencia. En la actualidad el metodo preferido para determinar la Máscara de Dirección es utilizando un protocolo de arranque como el Protocolo Dinámico de Configuración de host, o BOOTP. Estos procesos son más eficientes ya que disponen de un amplio conjunto de parámetros de configuración. También son, a menudo, más precisos. Por ejemplo, una estación Unix puede estar desconfigurada y responder erróneamente a los mensajes de petición de Mascara de Dirección. El resultado es que su sistema recibirá varias respuestas y algunas de ellas serán erróneas.

Tipo = 17 o 18 "Código" Suma de control

Identificador Número de secuencia

Máscara de Dirección



3.3.5.6.3.- Marca de tiempo y su respuesta.

Los mensajes de Marca de Tiempo indican la hora de un sistema y su objetivo es ofrecer una apreciación de lo que tarda el sistema remoto en el proceso del búfer y del procesamiento de un datagrama. Tenga en cuenta estos campos:

Marca de Tiempo Original	La marca de tiempo en que el origen tocó por última vez el mensaje.
Marca de Tiempo de recepción	La marca de tiempo en que el destino lo tocó por primera vez.
Marca de tiempo de transmisión	La marca de tiempo en que el destino lo tocó por última vez.

Si es posible, el tiempo devuelto debería medirse en milisegundos después de medianoche, en Tiempo Universal, anteriormente Tiempo medio de Greenwich. La mayor parte de las implementaciones actuales devuelven la misma marca de tiempo en los campos Marca de tiempo de recepción y Marca de tiempo de transmisión. Este protocolo podría ser un método sencillo para sincronizar los relojes con otros. Por supuesto que la sincronización sería un poco absurda debido a los posibles retardos de la red. Existe un protocolo mejor, el Protocolo de Tiempo de Red definido para la sincronización de la hora en internet. Se usa el Tipo 13 para la petición de Marca de Tiempo y el tipo 14 para la respuesta de Marca de Tiempo.

Tipo = 13 o 14 "Código" Suma de control

Identificador Número de secuencia

Marca de tiempo de generación

Marca de tiempo de recepción

Marca de tiempo de transmisión

3.3.6.- Reglas de procedimiento:

Cuando sea apropiado se intenta hacer llegar los mensajes ICMP al proceso adecuado. Ello se realiza en cooperación con la capa IP, que es la que conoce a qué proceso hay que informar sobre los eventos ocurridos a los datagramas de un protocolo determinado. En el caso de que el protocolo sea desconocido, los mensajes ICMP simplemente se ignoran.

Como ya se ha comentado con anterioridad, los servicios de la capa ICMP están orientados, fundamentalmente, a la capa IP. Ningún otro nivel debería hacer uso de ellos sin un conocimiento profundo de su funcionamiento y de las estructuras de datos implicadas (en especial, la cabecera IP).

3.3.6.1.- Obligación de enviar mensajes ICMP

El protocolo ICMP especifica que los mensajes de ICMP deberían o podrían enviarse en todos los lugares. No requiere que todos los errores tengan que generar un mensaje de ICMP. Tiene sentido, la prioridad de un encaminador en una red es reenviar datagramas. Y un host receptor congestionado debería prestar más atención a la entrega de datagramas a sus aplicaciones que a la notificación remota de errores. No es un gran problema si algunos datagramas se descartan y no se indica.

3.3.6.2.- Mensajes entrantes ICMP


¿Qué ocurre cuando un HOST recibe un mensaje de ICMP?. El comando ping de windows nos dice exactamente lo que nos manda el protocolo ICMP.

C:\WINDOWS>ping 10.10.10.1

Haciendo ping a 10.10.10.1 con 32 bytes de datos:

Host de destino inaccesible.

Host de destino inaccesible.

Host de destino inaccesible.

Host de destino inaccesible.

Como la dirección IP es inaccesible, recibimos un mensaje ICMP que nos indica este error.


3.3.6.3.- Cuando no enviar mensajes ICMP


Se puede esperar que los mensajes de ICMP se envíen cuando una red tiene problemas. Es importante asegurar que el tráfico de ICMP no inunda la red, empeorando la situación. Hay que imponer algunos límites obvios al protocolo. ICMP debe informar de los problemas causados por:

• El encaminamiento o el envío de mensajes de ICMP.

• La difusión o multienvío de datagramas.

• Fragmentos de datagrama distintos del primero.

• Mensajes cuya dirección de origen no identifique a un host único, como por ejemplo las direcciones de IP como 127.0.0.1 o 0.0.0.0.

3.3.6.4.- Tratamiento de los mensajes de error de ICMP entrantes

¿Qué se hace cuando llega un mensaje de error de ICMP a un host de origen? Cada fabricante implementa su software de red de forma variada y existen muchos modos de actuar con un mensaje de ICMP. Las guías que se dan para los distintos tipos de mensajes son:

Destino inalcanzable	Entregar el mensaje de ICMP a la capa de transporte. La acción depende de si la razón es permanente o transitoria
Redirect	El host debe actualizar la tabla de encaminamiento
Acallamiento de origen	Entregar el mensaje a la capa de transporte o a un módulo de procesamiento de ICMP
Plazo superado	Entregar el mensaje a la capa de transporte
Problema de parámetros	Entregar el mensaje a la capa de transporte; opcionalmente notificar al usuario

A veces, se pueden tratar las condiciones de error mediante la cooperación entre el sistema operativo, el software de comunicaciones y la aplicación que realiza la comunicación.

3.3.6.5.- Obtención de la MTU de una ruta

Cuando se realiza una operación que transmite gran cantidad de información entre dos host, como una transferencia de archivos, el tamaño de datagrama puede tener un gran impacto en el rendimiento del sistema. Las cabeceras IP y de TCP aportan una sobrecarga de al menos 40 bytes.

• Si se envían los datos en datagramas de 80 bytes, la sobrecarga es del 50 por ciento

• Si se envían los datos en datagramas de 400 bytes, la sobrecarga es del 10 por ciento

• Si se envían los datos en datagramas de 4000 bytes, la sobrecarga es de un 1 por ciento

Para minimizar la sobrecarga, se desearía enviar los mayores datagramas posibles. Pero hay que recordar que existe cierto límite en el tamaño del datagrama en un medio dado, la Unidad máxima de transmisión (MTU). Si los datagramas son demasiado grandes, se fragmentarán, y la fragmentación reduce el rendimiento del sistema. Durante muchos años, los host evitaban la fragmentación fijando la "MTU efectiva de envío" en 576 bytes para el tráfico a cualquier lugar que no fuese local. A menudo, distorsionaba innecesariamente el rendimiento.
Sabiendo esto, sería muy util predecir el mayor datagrama que se puede enviar por una ruta especifica para que no baje el rendimiento en el sistema. Existe un mecanismo, el de Obtención de la MTU de una ruta (Path MTU discovery) que permite determinar este tamaño. Su modo de funcionamiento es el siguiente:

• Se fija 1 la bandera "No fragmentar" de las cabeceras de IP.

• Se empieza con un tamaño de MTU de la ruta como el de la MTU de la interfaz local.

• Si el datagrama es demasiado grande para que lo reenvíe algún encaminador, le devolverá un mensaje de ICMP de Destino inalcanzable con el código =4.

• El host reduce el tamaño del datagrama y lo intenta de nuevo.

Entonces, sabiendo esto, se deduce que si el software es lo bastante actualizado, el mensaje Destino Inalcanzable tendra un campo que contendra el MTU con el que se deberia transmitir. Como la ruta pueden cambiar dinámicamente, la bandera "No fragmentar" se puede mantener durante toda la comunicación. Los encaminadores enviarán correcciones si se necesita.

Si en el caso de que el software del encaminador sea antiguo, el encaminador no indicara el tamaño de la MTU del siguiente salto. Un host puede hacer un supuesto razonable eligiendo el siguiente nivel inferior de la lista de tamaños estándar de MTU.

El procedimiento de cambio de tamaño continúa hasta que se encuentra un valor con el que se alcanza el destino. Por supuesto, si ocurre un cambio en la ruta existe la posibilidad de cambiar a una MTU mayor.

Un sistema que haya tenido que elegir una MTU pequeña puede intentar, periódicamente, enviar una de mayor tamaño para comprobar si se puede conseguir alguna mejora.

Tipo = 3 "Código" Suma de control

No usado MTU del siguiente salto

Cabecera de Internet + 8 octetos de los datos del datagrama original

3.3.6.6.- Ping www.upct.es

El comando ping, que existe en casi todos los sistemas operativos con TCP/IP está programado usando los mensajes de petición y respuesta de ECO. En el diálogo que sigue, en primer lugar se comprueba si el host www.upct.es está activo. A continuación se envía una secuencia de 4 mensajes, cada uno con 32 bytes de datos. En la parte derecha se muestra el tiempo de ida y vuelta.




3.4.- PROTOCOLO TCP

3.4.1.- Introducción

En 1973, la Agencia de Proyectos de Investigación Avanzada para la Defensa (DARPA), de los Estados Unidos, inició un programa para la investigación de tecnologías que permitieran la transmisión de paquetes de información entre redes de diferentes tipos y características. El proyecto tenía por objetivo la interconexión de redes, por lo que se le denominó "Internetting", y a la familia de redes de computadoras que surgió de esta investigación se le denominó "Internet". Los protocolos desarrollados se denominaron el Conjunto de Protocolos TCP/IP, que surgieron de dos conjuntos previamente desarrollados; los Protocolos de Control de Transmisión (Transmition Control Protocol) e Internet (Internet Protocol).

En la actualidad, las funciones propias de una red de computadoras pueden ser divididas en las siete capas propuestas por ISO para su modelo de sistemas abiertos (OSI). Sin embargo la implantación real de una arquitectura puede diferir de este modelo. Las arquitecturas basadas en TCP/IP proponen cuatro capas en las que las funciones de las capas de Sesión y Presentación son responsabilidad de la capa de Aplicación y las capas de Liga de Datos y Física son vistas como la capa de Interface a la Red. Por tal motivo para TCP/IP sólo existen las capas Interface de Red, la de Intercomunicación en Red, la de Transporte y la de Aplicación. Como puede verse TCP/IP presupone independencia del medio físico de comunicación, sin embargo existen estándares bien definidos a los nivel de Liga de Datos y Físico que proveen mecanismos de acceso a los diferentes medios y que en el modelo TCP/IP deben considerarse la capa de Interface de Red; siendo los más usuales el proyecto IEEE802, Ethernet, Token Ring y FDDI.

3.4.2.- Servicio

TCP ofrece maneras flexibles y de alta calidad para crear comunicaciones de red confiables, sin problemas de flujo y con un nivel de error bajo. Este protocolo trabaja al nivel de la capa de transporte por ello debe transportar y regular el flujo de información para garantizar la conectividad de extremo a extremo entre aplicaciones de host que se están comunicando en red de manera confiable, eficiente y precisa, utilizando para ello los servicios de la Capa de Red. La funcionalidad del protocolo TCP al igual que la de la capa de transporte se resume en calidad de servicio.

Para ello, TCP en el host fuente parte el flujo de bits en mensajes discretos y los envía, mientras que TCP en el host destino los recibe y los monta de nuevo para crear el flujo original, manejando el control de flujo de la transmisión.

3.4.3.- Suposiciones

Capa de aplicación (HTTP, SMTP, FTP, TELNET...)

Capa de transporte (UDP, TCP)

Capa de red (IP)

Capa de acceso a la red (Ethernet, Token Ring...)

Capa física (cable coaxial, par trenzado...)

La fiabilidad en la comunicación es requisito para numerosas aplicaciones. Las causas de pérdidas de datagramas IP son normalmente:

• Fallo en el hardware de red

• Routers congestionados que descarta datagramas

• Routers mal configurados que encaminan erróneamente.

Existe la necesidad de proporcionar a aplicaciones, fiabilidad sobre el protocolo IP (no confiable)

TCP utiliza el soporte básico de IP, ya no se preocupa de la ruta que siguen los mensajes hasta llegar a su destino. Sencillamente, considera que la comunicación extremo a extremo está establecida y la utiliza. Además añade la noción de puertos, como veremos más adelante.

3.4.4.- Vocabulario

TCP mantiene un diálogo entre el origen y el destino mientras fragmenta y empaqueta la información de la capa de aplicación en unidades de tamaño adecuado, denominadas segmentos, debiendo ocuparse de los datos independientemente del hardware y del software que tenga la red con la que se esté trabajando. Sus principales características son:

• Es un protocolo orientado a la conexión, lo que significa que se establece una conexión entre el emisor y el receptor antes de que se transfieran los datos entre ambos. Los segmentos de la Capa de Transporte viajan de un lado a otro entre dos hosts para comprobar que la conexión exista lógicamente para un determinado período, lo que se conoce como conmutación de paquetes. Al circuito lógico por el que viajan los paquetes se le denomina circuito virtual, porque aunque cada paquete enviado desde el host origen puede viajar por un camino o ruta diferente hasta llegar al host destino por medio del protocolo IP, TCP consigue que parezca que sólo existe un único circuito de comunicación entre ambos host. Con ello, el servicio controla el flujo entre los host que se están comunicando, entregando al receptor exactamente la misma secuencia de bytes que le ha pasado el tresmisor en el host origen.

• Es un protocolo fiable, implementando mecanismos para conseguir que la información enviada por el emisor llegue de forma correcta al receptor. De esta forma, las aplicaciones que envían datos no tienen porqué preocuparse de la integridad de los mismos, dando por hecho que los datos recibidos son correctos. TCP aporta la fiabilidad de que carece el protocolo inferior IP. Para ello, cada paquete se trata de forma independiente, asignándole el emisor un número identificador único, lo que permite un posterior control de los paquetes enviados y recibidos.

• Es un protocolo de flujo no estructurado, con posibilidad de enviar información de control junto a datos.

• Es un protocolo con transferencia de memoria intermedia, sistema mediante el cual, y con objeto de hacer eficiente la transferencia y minimizar el tráfico de red, se van almacenando datos suficientes del flujo de transmisión hasta completar un paquete lo suficientemente largo como para ser enviado. En el lado receptor ocurre un proceso similar, almacenándose los datos recibidos hasta completar una secuencia completa y correcta de ellos, momento en el que son pasados al proceso de aplicación de destino. De esta forma, la transferencia a través de la red puede ser sumamente eficiente. Estos datos se almacenan en una memorias intermedias, denominadas buffers.

• Usa conexiones full-duplex, en las que se permite la transferencia de datos concurrente en ambas direcciones, sin ninguna interacción aparente desde el punto de vista de las aplicaciones emisora y destinataria. Este sistema presenta la ventaja de que el software de protocolo puede enviar datagramas de información de control de flujo al origen, a la vez que lleva datos en dirección opuesta, con lo que se reduce el tráfico de red.

• Usa conexiones punto a punto, en las cada conexión tiene exactamente dos puntos terminales. TCP no reconoce ni la multitransmisión ni la difusión.

3.4.5.- Formato






Tal vez te pueda interesar:

• Access 97
• Adaptadores Token Ring
• Administracion de distribuciones linux
• Algoritmos de ordenación
• Ampliación del {WWW}


Descargar

0	10	20	30
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Puerto TCP origen			Puerto TCP destino
Número de secuencia
Número de acuse de recibo
HLEN	Reservado	Indicadores	Ventana
Checksum TCP			Marcador urgente
Opciones				Relleno

Enviado por:	El remitente no desea revelar su nombre
Idioma:	castellano
País:	España