t25 El Modelo de Referencia de Interconexión de Sistemas Abiertos

T25 - EL MODELO DE REFERENCIA DE INTERCONEXIÓN DE SISTEMAS ABIERTOS (OSI) DE ISO. PROTOCOLOS TCP/IP.

1.

EL MODELO DE REFERENCIA DE INTERCONEXIÓN DE SISTEMAS ABIERTOS (OSI) DE ISO ................ 3 1.1. INTRODUCCIÓN........................................................................................................................................................ 3 1.2. MODELO DE REFERENCIA OSI. CONCEPTOS GENERALES ............................................................................. 3 1.2.1. CONEXIONES...................................................................................................................................................... 7 1.2.1.1. ESTABLECIMIENTO DE CONEXIONES........................................................................................................ 7 1.2.1.2. LIBERACIÓN DE CONEXIONES.................................................................................................................... 8 1.2.1.3. MULTIPLEXACIÓN Y DIVISIÓN.................................................................................................................... 8 1.2.2. TRANSMISIÓN DE DATOS ................................................................................................................................. 9 1.3. CAPAS DEL MODELO OSI........................................................................................................................................ 9 1.3.1. CAPA FÍSICA (NIVEL 1) ................................................................................................................................... 11 1.3.2. CAPA DE ENLACE DE DATOS (NIVEL 2)....................................................................................................... 12 1.3.3. CAPA DE RED (NIVEL 3) ................................................................................................................................. 12 1.3.4. LA CAPA DE TRANSPORTE (NIVEL 4) ........................................................................................................... 13 1.3.5. LA CAPA DE SESIÓN (NIVEL 5) ...................................................................................................................... 14 1.3.6. LA CAPA DE PRESENTACIÓN (NIVEL 6) ....................................................................................................... 15 1.3.7. LA CAPA DE APLICACIÓN (NIVEL 7)............................................................................................................. 16 1.4. CRÍTICAS DEL MODELO........................................................................................................................................ 18

2.

PROTOCOLOS TCP/IP.................................................................................................................................................. 18 2.1. INTRODUCCIÓN...................................................................................................................................................... 18 2.2. CAPAS DEL MODELO TCP/IP ................................................................................................................................ 19 2.3. PROTOCOLOS DEL NIVEL DE RED...................................................................................................................... 20 2.3.1. PROTOCOLO IP................................................................................................................................................ 20 2.3.1.1. DATAGRAMA IP............................................................................................................................................ 20 2.3.1.2. DIRECCIONES IP.......................................................................................................................................... 22 2.3.1.3. ENRUTAMIENTO .......................................................................................................................................... 25 2.3.2. PROTOCOLOS DE CONTROL ......................................................................................................................... 26 2.3.2.1. ICMP. PROTOCOLO DE CONTROL DE MENSAJES DE INTERNET ........................................................ 26 2.3.2.2. ARP. PROTOCOLO DE RESOLUCIÓN DE DIRECCIONES ....................................................................... 28 2.3.2.3. RARP. PROTOCOLO DE RESOLUCIÓN DE DIRECCIONES INVERSO. .................................................. 29 2.3.2.4. BOOTP ........................................................................................................................................................... 29 2.3.2.5. IGMP. PROTOCOLO DE ADMINISTRACIÓN DE GRUPOS DE INTERNET............................................. 29 2.3.3. PROTOCOLOS DE ENRUTAMIENTO.............................................................................................................. 30 2.3.3.1. OSPF. PROTOCOLO DE ENRUTAMIENTO DE PASARELA INTERIOR ................................................... 30 2.3.3.2. BGP. PROTOCOLO DE ENRUTAMIENTO DE PASARELA EXTERIOR .................................................... 31 2.3.4. IPv6 .................................................................................................................................................................... 32 2.3.4.1. LA CABECERA DE IPv6................................................................................................................................ 33 2.4. PROTOCOLOS DEL NIVEL DE TRANSPORTE .................................................................................................... 34 2.4.1. PROTOCOLO TCP ............................................................................................................................................ 34 2.4.1.1. SEGMENTO TCP ........................................................................................................................................... 35 2.4.1.2. CONEXIONES TCP ....................................................................................................................................... 36 2.4.1.3. DETECCIÓN DE ERRORES.......................................................................................................................... 37 2.4.1.4. CONTROL DE FLUJO................................................................................................................................... 37 2.4.1.5. CONTROL DE CONGESTIÓN ...................................................................................................................... 38 2.4.2. PROTOCOLO UDP ........................................................................................................................................... 38 2.4.2.1. DATAGRAMA UDP ....................................................................................................................................... 39 2.5. PROTOCOLOS DEL NIVEL DE APLICACIÓN...................................................................................................... 39 2.5.1. PROTOCOLOS QUE UTILIZAN UDP .............................................................................................................. 39 2.5.1.1. SNMP. PROTOCOLO DE GESTIÓN DE RED.............................................................................................. 39 2.5.1.2. DNS. SERVICIO DE NOMBRES DE DOMINIO ........................................................................................... 40

T25 Página 1 de 49

2.5.2. PROTOCOLOS QUE UTILIZAN TCP ............................................................................................................... 40 2.5.2.1. SMTP. PROTOCOLO DE TRANSFERENCIA DE MENSAJES..................................................................... 40 2.5.2.2. TELNET. PROTOCOLO DE CONEXIÓN REMOTA..................................................................................... 41 2.5.2.3. FTP. PROTOCOLO DE TRANSFERENCIA DE FICHEROS........................................................................ 41 2.5.2.4. HTTP. PROTOCOLO DE TRANSPORTE DE HIPERTEXTO....................................................................... 41 2.6. PROBLEMAS DEL MODELO TCP/IP ..................................................................................................................... 42 3.

CONCLUSIÓN ................................................................................................................................................................. 42

4.

BIBLIOGRAFÍA .............................................................................................................................................................. 43

5.

ESQUEMA – RESUMEN ................................................................................................................................................ 44

TEMARIO-TICC-mar04 Actualizado en marzo de 2004

T25 Página 2 de 49

1. EL MODELO DE REFERENCIA DE INTERCONEXIÓN DE SISTEMAS ABIERTOS (OSI) DE ISO 1.1.

INTRODUCCIÓN

Inicialmente, los computadores eran elementos aislados que contenían sus propios archivos y precisaban sus propios periféricos. La independencia era tal que, si se necesitaba imprimir un documento alojado en una máquina que no disponía de impresora, era necesario copiar el archivo en un disquete y llevarlo hasta un equipo con impresora e imprimirlo desde allí. Para evitar esto, la solución era instalar una impresora en el computador inicial, con la consiguiente duplicidad de recursos y dispositivos. Con una planta informática así, la configuración y gestión de todos los ordenadores y de los periféricos a ellos asociados se convertía en una tarea tediosa, llegando a ser poco práctica cuando el número de computadores fue creciendo en las distintas empresas. De esta forma, surgió la necesidad de conectar los diferentes ordenadores entre sí e implantar métodos de comunicación y transferencia de datos entre ellos. Nace el concepto de “redes de ordenadores” y “trabajo en red”. A mediados de los 70 diversos fabricantes desarrollaron sus propios sistemas de redes locales. Sin embargo, la comunicación entre ordenadores pertenecientes a redes distintas era imposible, debido a que los sistemas de comunicación de cada red eran propietarios. Es decir, estaban desarrollados con hardware y software propios y usaban protocolos y arquitecturas diferentes a los de otras redes. Entonces las empresas se dieron cuenta de que era necesario abandonar los sistemas propietarios y definir una arquitectura de red con un modelo común que permitiera interconectar varias redes sin problemas. En 1977, la Organización Internacional de Normas (ISO, International Standard Organization), integrada por industrias representativas del sector, creó un subcomité para desarrollar estándares de comunicación de datos que permitieran la interoperabilidad entre productos de diferentes fabricantes. Tras varias investigaciones acerca de los modelos de red, elaboraron el modelo de referencia OSI (Open Systems Interconnection), en 1984.

1.2.

MODELO DE REFERENCIA OSI. CONCEPTOS GENERALES

El modelo de referencia para la Interconexión de Sistemas Abiertos se caracteriza porque: □

Se ocupa de la conexión de sistemas abiertos, es decir, sistemas que están abiertos a la comunicación con otros sistemas.

□

Consta de siete capas. Por capa se entiende una entidad (o varias) que realiza por sí misma una función específica. Las entidades del mismo nivel se denominan entidades pares.

□

Representa el primer paso hacia la estandarización internacional de los protocolos que se usan en las diversas capas.

□

No es una arquitectura de red en sí, ya que no especifica los servicios y protocolos exactos que se han de usar en cada capa, sino que sólo dice lo que debe hacer cada capa.

En el modelo OSI existen tres conceptos fundamentales: □

Servicio.- Capacidad de comportamiento de una capa. Cada capa presta algunos servicios a las entidades que se encuentran sobre ella, que acceden a los mismos a través de los puntos de acceso al servicio (SAP), intercambiando primitivas de servicio.

□

Interfaz.- Dice a los procesos de la capa superior cómo acceder a ella, especificando cuáles son los parámetros y qué resultados esperar. La interfaz entre dos capas en una máquina no tiene porque ser igual a la correspondiente en otra máquina.


T25 Página 3 de 49

□

Protocolo.- Conjunto de reglas que determinan el comportamiento de comunicación horizontal entre entidades pares. Se pueden cambiar los protocolos de una capa sin afectar a las demás.

Las entidades pares residentes en el nivel N+1 se comunican entre sí a través del nivel N, mediante el uso de primitivas de servicio. Sin embargo, existe una comunicación lógica horizontal entre entidades pares. Las reglas que regulan esta comunicación vienen reflejadas en el protocolo de pares. Por lo tanto, en la especificación de cada capa existen dos documentos: □

Especificación del servicio, que informa sobre las primitivas existentes. En la descripción de las primitivas se dice cuántos parámetros puede o debe haber y qué información contienen, pero no se dice cómo ni con qué formato han de ser “pasados”. Esto es asunto local y definir esto equivale a definir la Interfaz. Existen cuatro tipos de primitivas. à

De petición (REQUEST). Empleada para invocar un servicio y pasarle los parámetros necesarios para su ejecución.

à

De indicación (INDICATION). Usada para indicar que un procedimiento ha sido invocado por el usuario par del servicio en la conexión y pasar los parámetros asociados o para indicar al usuario del servicio el inicio de una acción por parte del proveedor.

à

De respuesta (RESPONSE). Empleada por el usuario del servicio para reconocer o completar algún procedimiento previamente iniciado por una indicación del proveedor.

à

De confirmación (CONFIRM). Usada por el proveedor del servicio para reconocer o completar algún procedimiento previamente iniciado por una petición del usuario. USUARIO DEL SERVICIO

PROVEEDOR DEL SERVICIO

USUARIO DEL SERVICIO

REQUEST INDICATION

CONFIRM

□

RESPONSE

Especificación del protocolo, que describe las PDUs (Protocol Data Units) y las reglas que determinan su intercambio entre unidades pares. Existen dos clases de PDUs. à

De datos, que contiene los datos del usuario final (en el caso de la capa de aplicación) o la PDU del nivel inmediatamente superior.

à

De control, que sirven para gobernar el comportamiento completo del protocolo en sus funciones de establecimiento y ruptura de la conexión, control de flujo, control de errores, etc. No contienen información alguna proveniente del nivel N+1.

Con la siguiente figura se ilustra la nomenclatura utilizada por ISO en la “torre” que envía la información. PDU (N) -> Unidad de Datos de Protocolo de nivel N. Contiene información de control de protocolo y, posiblemente, datos de usuario. Debe estar puntual y perfectamente definida (sintaxis y semántica) ICI (N) -> Información de Control de Interfaz de nivel N. Es transferida entre una entidad N+1 y una entidad N para coordinar el funcionamiento local conjunto. Su sintaxis y semántica son un asunto local cuando actúa como información complementaria en la transferencia de una PDU.

T25 Página 4 de 49

IDU (N) -> Unidad de Datos de Interfaz de nivel N. Es transferida a través del punto de acceso al servicio N. Contiene la ICI más la totalidad (o parte) de la información de la PDU (N+1). La estructura de las informaciones en la IDU es asunto local. SDU (N) -> Unidad de Datos del Servicio de nivel N. Representa la información entregada por el nivel inmediatamente superior. PCI (N) -> Información de Control del Protocolo de nivel N. Información generada por la entidad N para coordinar el funcionamiento conjunto con otra u otras entidades N con las que está intercambiando información “horizontal”. UD (N) -> Datos de Usuario. Datos transferidos entre entidades N en nombre de las entidades N+1. PDU (N+1) ICI (N)

IDU (N) ICI (N)

PDU (N+1)

ICI (N)

SDU (N) PCI (N) Protocolo N PDU (N)

ICI (N-1)

Entidad N

iDU (N-1)

ICI (N-1)

SDU (N-1)

En la “torre” que recibe la información, la relación existente entre las unidades de datos residentes en las entidades de nivel N-1, N y N+1 es similar a la representada más arriba, sólo que en lugar de añadidos se producen sustracciones y las flechas son ascendentes, como muestra la figura siguiente.

T25 Página 5 de 49

PDU (N+1) ICI (N)

IDU (N)

ICI (N)

SDU (N) PCI (N) Protocolo N PDU (N)

ICI (N-1)

Entidad N

IDU (N-1)

ICI (N-1)

SDU (N-1)

Los datos de usuario contenidos en la PDU (N) de datos corresponden exactamente a la PDU (N+1). Para el nivel N son una ristra de bits, cuya semántica desconoce. La PDU (N) de datos se forma con los UD (N) y con la PCI (N), que los “envuelve” antes de entregarlos al nivel inferior. Cuando las unidades de datos de los niveles limítrofes no tienen tamaños compatibles, se recurre a alguna de las siguientes funciones: □

Segmentación de la SDU. Cuando la SDU es demasiado grande, se reparte en más de una PDU. La función simétrica en el extremo receptor es el reensamblado, que consiste en identificar varias PDUs con una sola SDU. La PCI incluye, en este caso, información adicional para posibilitar el reensamblado.

□

Bloqueo de la SDU. Cuando el tamaño de la SDU es más pequeño que el de la PDU, puede ser conveniente o necesario agrupar varias SDUs en una sola PDU. El bloqueo es el caso contrario que la segmentación de la SDU. La función inversa del bloqueo es el desbloqueo, que consiste en descomponer una PDU en varias SDUs. El caso de segmentación se da con más frecuencia que el de bloqueo.

□

Segmentación de la PDU. Si la PDU es muy grande, puede ser necesario repartirla en más de una IDU del nivel inferior. Por eso, en la definición de IDU se dice que contiene la ICI más la totalidad (o parte) de la PDU. También en este caso deben existir informaciones adicionales que posibiliten el reensamblado en el extremo receptor.

□

Concatenación de PDU. Si el tamaño de la SDU del nivel inferior, es decir, de la IDU del nivel inferior, es mayor que el de la PDU, puede convenir agrupar varias PDUs sobre una sola SDU. La función inversa a

T25 Página 6 de 49

ésta, que se realiza en el extremo receptor, es la separación. La concatenación-separación es el caso contrario de la segmentación-reensamblado de la PDU, siendo éste último más frecuente que el primero.

1.2.1. CONEXIONES El modelo de referencia OSI es orientado a la conexión. Esto significa que, en todos los niveles, es necesario que se establezca previamente una conexión para que pueda existir intercambio de datos. Sin embargo, existen protocolos que no requieren esta condición, son los no orientados a la conexión (connectionless). En las comunicaciones orientadas a la conexión se pierde tiempo y procesamiento en establecer y liberar la conexión entre dos nodos, pero se garantiza que el nodo remoto está escuchando. Por el contrario, en las comunicaciones no orientadas a la conexión se ahorra tiempo y procesamiento, pero a costa de no saber si el otro extremo está o no escuchando. SERVICIO N

NIVEL N+1

NIVEL N

ENTIDAD

SAP N

PROTOCOLO N

N

NIVEL N-1

ENTIDAD

N

CONEXIÓN N-1

A nivel N-1 se establece una asociación, una conexión N-1, para que dos entidades de nivel N puedan comunicarse. La conexión N-1 es un servicio ofrecido por el nivel N-1, a través de la cual circulan unidades de información del nivel N. El Punto de Acceso al Servicio (SAP) del nivel N identifica la dirección del nivel N a la que se conectan las entidades de nivel N+1. La relación entre direcciones de dos niveles consecutivos puede ser 1 a 1, N a 1 ( no confundir con la multiplexación, que se explica más abajo) o 1 a N, como se muestra en la figura siguiente.

DIRECCIONES N (N SAPs) NIVEL N

DIRECCIONES N-1 (N-1 SAPs) 1A1

NA1

1AN

1.2.1.1. ESTABLECIMIENTO DE CONEXIONES Para que dos entidades N establezcan una conexión, es necesario:


T25 Página 7 de 49

□

Disponer de una conexión N-1 por debajo. En los niveles bajos, es necesario establecer previamente la conexión N-1 antes de intentar establecer la conexión N, descendiendo hasta que se encuentra una disponible a nivel físico (el nivel más bajo). Sin embargo, en los niveles altos, se aprovecha la circunstacia de establecimiento de la conexión N para establecer, al mismo tiempo, la conexión N+1.

□

Estar ambas entidades conformes con el establecimiento.

Una vez establecida la conexión, es como si la entidad dispusiese de un “tubo” a través del cual pudiese enviar datos a su entidad de comunicación correspondiente.

1.2.1.2. LIBERACIÓN DE CONEXIONES La liberación de una conexión N es iniciada, normalmente, por una de las entidades N+1 que la está usando. Sin embargo, esta ruptura puede ser también iniciada por una de las entidades N que la soportan. Al contrario que ocurre en el establecimiento, la liberación de una conexión N-1 no implica la liberación de la conexión N. Esto es así para permitir que, si la conexión N-1 se ha roto por dificultades de la comunicación, pueda intentarse reestablecerla o sustituirla por otra. La liberación de una conexión puede ser: □

Abrupta. Se libera de inmediato y los datos pendientes de envío se pierden.

□

Suave o diferida. Antes de romper la conexión, se espera a no tener datos pendientes.

1.2.1.3. MULTIPLEXACIÓN Y DIVISIÓN La multiplexación es la función que permite utilizar una sola conexión N-1 para soportar varias conexiones de nivel N. Todos los “tubos” de conexión N viajan por dentro del “tubo” de conexión N-1. Varias comunicaciones entre entidades pares de nivel N se realizan apoyándose en una sola conexión de nivel N-1. Es decir, las distintas entidades usan un solo punto de acceso al servicio N-1. La función inversa realizada en el receptor se denomina demultiplexación. No debe confundirse el concepto de multiplexación con el de concatenación, ya explicado. N SAPs CONEXIONES N

CONEXIÓN N-1

La división es la función que permite la utilización de más de una conexión N-1 por una sola conexión de nivel N. Con ello, el flujo de datos que soporta puede ser mayor. El flujo de datos del “tubo” correspondiente a la conexión N se reparte entre todos los “tubos” de conexiones N-1. En el extremo receptor, la función inversa se denomina recombinación y debe ser capaz de recuperar el orden en el que las PDUs fueron generadas por el extremo emisor. No debe confundirse el concepto de división con el de segmentación, ya explicado. N SAP

CONEXIÓN N

CONEXIONES N-1


T25 Página 8 de 49

1.2.2. TRANSMISIÓN DE DATOS Una capa de una máquina no puede transferir los datos de forma directa a su capa par de otra máquina, sino que necesita los servicios de todas las capas que se encuentran por debajo de ella en la jerarquía de capas, pasándose la información hacia abajo hasta llegar al nivel físico, donde se transmiten a la máquina receptora. Cada capa utiliza el encapsulamiento para colocar la PDU de la capa superior en su campo de datos y agregar cualquier encabezado e información final que la capa necesite para realizar su función. De esta forma, a medida que los datos se desplazan hacia abajo a través de las capas del modelo OSI, el tamaño del mensaje va creciendo. A nivel 3, la PDU se llama paquete e incluye las direcciones lógicas origen y destino. A nivel 2, la trama incluye las direcciones físicas. Y, finalmente, la capa física codifica los datos de la trama de enlace de datos en un patrón de unos y ceros para su transmisión a través del medio. En la máquina receptora se realiza el proceso inverso, retirando los distintos encabezados, uno por uno, conforme el mensaje se propaga hacia arriba por las capas. La figura siguiente trata de ilustrar este proceso.

1.3.

CAPAS DEL MODELO OSI

Como se ha dicho en el punto anterior, el modelo de referencia OSI se dividió en siete niveles o capas, para poder simplificar la implementación de la arquitectura necesaria. Los principios que se aplicaron para llegar a las siete capas son los siguientes:

TEMARIO-TICC-mar04

T25 Página 9 de 49

□

Se debe crear una nueva capa siempre que se precise un grado diferente de abstracción.

□

A cada capa se le asigna una función bien definida o un conjunto de funciones relacionadas entre sí, tratando de resolver cada capa un problema distinto.

□

La funcionalidad de cada capa se debe elegir teniendo en cuenta la posibilidad de definir protocolos normalizados a nivel internacional.

□

La frontera de las capas será tal que se minimice el flujo de información a través de la interfaz entre ambas.

□

El número de capas debe ser lo suficientemente grande para no reunir en un mimo nivel funcionalidades distintas y suficientemente pequeño para que la arquitectura resultante sea manejable.

Cada una de las capas del modelo OSI ilustra una función de red particular. Las características generales de las capas son las siguientes: □

Las capas poseen una estructura jerárquica.

□

Cada capa desempeña funciones bien definidas.

□

A cada nivel se le asigna un nombre que trata de describir las funciones que realiza.

□

Los cambios en una capa son transparentes al resto de niveles.

□

Los servicios proporcionados por cada nivel son utilizados por el nivel superior.

□

Existe una comunicación virtual entre dos mismas capas, de manera horizontal.

□

Existe una comunicación vertical entre una capa de nivel N y las capas de nivel N-1 y N+1

□

La comunicación física se lleva a cabo entre las capas de nivel 1.

Las siete capas del modelo de referencia son: □

Aplicación.

□

Presentación.

□

Sesión.

□

Transporte.

□

Red.

□

Enlace.

□

Física.

Las tres capas inferiores, física, enlace y red, engloban lo que se conoce como bloque de transmisión y tratan los protocolos asociados con la red de conmutación de paquetes utilizada para la conexión. El nivel 4 enmascara a los niveles superiores los detalles de trabajo de los niveles inferiores, dependientes de la red, y junto con ellos forma lo que se conoce como bloque de transporte. Este bloque es común para todas las aplicaciones y se encarga del transporte fiable de los datos sin intervenir en el significado de los mismos. Los niveles de aplicación, presentación y sesión son los usuarios del bloque de transporte, están relacionados con aspectos de las aplicaciones de usuario y aíslan la comunicación de las características específicas del sistema informático.


T25 Página 10 de 49

1.3.1. CAPA FÍSICA (NIVEL 1) La capa física está relacionada con la transmisión de bits por un canal de comunicación, de forma que sólo reconoce bits individuales, sin estructura alguna. Es decir, la PDU de nivel físico se corresponde con un bit o, dicho de otro modo, cada bit se considera una unidad de datos. Las consideraciones de diseño tienen que ver con las interfaces mecánica, eléctrica y de procedimiento, así como con el medio de transmisión que está bajo la capa física, asegurando que cuando un lado envíe un bit 1, se reciba en el otro extremo como bit 1, no como bit 0. La capa física proporciona sus servicios a la capa de enlace de datos. Sus principales funciones son: □

Definición de características materiales (componentes y conectores mecánicos) y eléctricas (niveles de tensión, tipo de señal) que se van a utilizar en la transmisión de los datos por el medio físico.

□

Definición de las características funcionales de la interfaz en cuanto a establecimiento, mantenimiento y liberación del enlace físico.

□

Definición de reglas de procedimiento, es decir, la secuencia de eventos para transmitir.

□

Transmisión de flujos de bits a través del medio.


□

Manejo de voltajes y pulsos eléctricos para representar 1’s o 0’s.

□

Especificación de cables, polos en un enchufe, componentes de interfaz con el medio, etc.

□

Especificación del medio físico de transmisión (coaxial, fibra óptica, par trenzado, etc.)

□

Garantía de conexión física, pero no fiabilidad de la misma. Es decir, no se realiza ningún control de errores en este nivel. Eso corresponde al nivel superior.

1.3.2. CAPA DE ENLACE DE DATOS (NIVEL 2) Puesto que la capa física sólo acepta y transmite una corriente de bits sin preocuparse por su significado o estructura, corresponde al nivel de enlace tomar el medio de transmisión en bruto y transformarlo en una línea que parezca libre de errores a los ojos de la capa de red. La capa de enlace de datos puede ofrecer a la capa de red varias clases de servicio con diferentes calidades. Algunas de las funciones más importantes de la capa de enlace son: □

Establecimiento de medios necesarios para la comunicación fiable y eficiente entre dos máquinas en red.

□

Estructuración de los datos en un formato predefinido, denominado trama, que suele ser de unos cientos de bytes, añadiendo una secuencia especial de bits al principio y al final de la misma.

□

Sincronización en el envío de tramas.

□

Detección y control de errores provenientes del medio físico mediante el uso de bits de paridad, CRC (Códigos Cíclicos Redundantes) y envío de acuses de recibo por parte del receptor que debe procesar el emisor.

□

Utilización de número de secuencia en las tramas para evitar pérdidas y duplicidades.

□

Utilización de la técnica de “piggybacking”, envío de acuses de recibo dentro de tramas de datos.

□

Resolución de los problemas provocados por las tramas dañadas, perdidas o duplicadas.

□

Control de la congestión de la red.

□

Mecanismos de regulación de tráfico o control de flujo, para evitar que un transmisor veloz sature de datos a un receptor lento.

□

Control del acceso al canal compartido en las redes de difusión.

1.3.3. CAPA DE RED (NIVEL 3) La capa de red es una capa compleja que ofrece sus servicios a la capa de transporte. Responsable de la conmutación y enrutamiento de la información, sus funciones se pueden resumir de la siguiente forma: □

Conocimiento de la topología de la red, es decir, de la forma en que están interconectados los nodos, con objeto de determinar la mejor ruta para la comunicación entre máquinas que pueden estar ubicadas en redes geográficamente distintas.

□

División de los mensajes de la capa de transporte en unidades más complejas, llamadas paquetes (NPDUs), y asignación de direcciones lógicas a los mismos.

□

Ensamblado de paquetes en el host destino.

□

Establecimiento, mantenimiento y liberación de las conexiones de red entre sistemas.

□

Determinación del encaminamiento de los paquetes de la fuente al destino a través de dispositivos intermedios (routers). à

Las rutas se pueden basar en tablas estáticas.


à

Las rutas se pueden determinar al inicio de cada conversación.

à

Las rutas pueden ser dinámicas, determinándose con cada paquete en función de la carga de la red.

□

Envío de paquetes de nodo a nodo usando un circuito virtual (orientado a la conexión) o datagramas (no orientado a la conexión).

□

Control de la congestión.

□

Control de flujo.

□

Control de errores.

□

Reencaminamiento de paquetes en caso de caída de un enlace.

□

Con frecuencia, funciones de contabilidad, para determinar cuántos paquetes, caracteres o bits envía cada cliente y producir información de facturación.

Esta capa sólo es necesaria en las redes de conmutación o redes interconectadas. En redes punto a punto o de difusión existe un canal directo entre los dos equipos, por lo que el nivel 2 proporciona directamente conexión fiable entre los dos equipos.

1.3.4. LA CAPA DE TRANSPORTE (NIVEL 4) Se trata de una verdadera capa extremo a extremo, del origen al destino. La comunicación en los niveles inferiores es entre máquinas adyacentes. La capa de transporte proporciona sus servicios a la capa de sesión, efectuando la transferencia de datos transparente entre dos entidades de sesión. El nivel 4 tiene la interfaz más sencilla de todo el modelo OSI, es el que tiene menos primitivas. No tiene primitivas de confirmación, pues se considera a todos los efectos que es un nivel fiable. Su función más importante es la aceptación de datos de la capa de sesión, división en unidades más pequeñas, si es preciso, denominadas segmentos, y envío de esta información a la capa de red, asegurando que todos los pedazos lleguen correctamente al otro extremo de forma eficiente, donde son reensamblados. Otras funcionalidades son: □

Establecimiento, mantenimiento y terminación adecuados de los circuitos virtuales (conexiones que se establecen dentro de una red). Cuando se inicia la conexión se determina una ruta de la fuente al destino, ruta que es usada para todo el tráfico de datos posterior.

□

Determinación, en el momento del establecimiento de la sesión, del tipo de clase de servicio de transporte que se proporcionará a la capa de sesión: à

Canal punto a punto libre de errores, que entrega los mensajes o bytes en el orden en que se envían.

à

Mensajes aislados sin garantía respecto al orden de entrega.

à

Difusión de mensajes a múltiples destinos.

□

Control de flujo, que desempeña un papel clave en esta capa. El control de flujo entre nodos es distinto del control de flujo entre enrutadores, que tiene lugar en la capa de red. Los datos pueden ser normales o urgentes. Estos últimos se saltan los mecanismos de control de flujo.

□

Detección y recuperación de errores de transporte.

□

Control de la congestión.

□

Numeración de los segmentos para prevenir pérdidas y doble procesamiento de transmisiones.

□

Garantía de recepción de todos los datos y en el orden adecuado, sin pérdidas ni duplicados.

□

Asignación de una dirección única de transporte a cada usuario.


□

Aislamiento a las capas superiores de los cambios inevitables de la tecnología del hardware.

□

Contabilidad a través de la red.

Lo normal es que la capa de nivel 4 cree una conexión de red distinta para cada conexión de transporte que requiera la capa de sesión. Sin embargo, es posible crear múltiples conexiones de red, dividiendo los datos entre ellas para aumentar el volumen, si se requiere un volumen de transmisión alto. De igual forma, si resulta costoso mantener una conexión de red, el nivel 4 puede multiplexar varias conexiones de transporte en la misma conexión de red para reducir el coste. En la cabecera que añade este nivel se envía la información que identifica a qué conexión pertenece cada mensaje. En cualquier caso, la capa de transporte debe hacer esto de forma transparente a la capa de sesión.

1.3.5. LA CAPA DE SESIÓN (NIVEL 5) Esta capa proporciona sus servicios a la capa de presentación, facilitando el medio necesario para que las entidades de presentación de dos máquinas diferentes organicen y sincronicen su diálogo y procedan al intercambio de datos, mediante el establecimiento de sesiones. Por tanto, la función principal de la capa de sesión es el establecimiento, administración y finalización ordenada de sesiones entre dos máquinas. Una sesión permite el transporte ordinario de datos, como efectuar un login a un sistema remoto o transferir un archivo entre dos nodos, pero también proporciona servicios mejorados, útiles en algunas aplicaciones, como los que se detallan a continuación. □

Manejo del control del diálogo (quién habla, cuándo, cuánto tiempo, half duplex o full duplex). Las sesiones pueden permitir que el tráfico vaya en una única dirección, comunicaciones bidireccionales alternadas (half duplex), o en ambas direcciones al mismo tiempo, comunicaciones bidireccionales simultáneas (full duplex). En las comunicaciones half duplex, la capa de sesión ayuda a llevar el control de los turnos, mediante el manejo de fichas, también llamadas testigos o token. Sólo el lado que posea la ficha puede efectuar la operación.

□

Sincronización del diálogo, mediante la inserción de puntos de verificación en la corriente de datos (APDU), de modo que si se produce una interrupción sólo es necesario repetir la transferencia de los datos después del último punto de verificación. La decisión de dónde colocar los puntos de sincronización es competencia directa del nivel de aplicación. Los puntos de sincronización pueden ser de dos tipos. à

Mayor. Necesita confirmación del otro extremo para seguir con la transferencia del siguiente bloque.

à

Menor. Se intercalan entre dos puntos de sincronización mayores. No necesitan confirmación. Al confirmarse un punto de sincronización mayor, se dan por confirmados los puntos menores intermedios.

El bloque entre el primero y el último punto de sincronización mayor se llama actividad. Cuando se establece una conexión de sesión, automáticamente se abre una actividad, para poder trabajar. Sólo un tipo de datos concreto puede enviarse fuera de una actividad, los datos de capacidades (CD), que son datos de control. Las actividades se dividen en unidades de diálogo, que es el contenido entre dos puntos de sincronización mayor consecutivos. En la siguiente figura pueden verse gráficamente estos conceptos.

Sesión Actividad

CD

CD


Sesión Actividad

Actividad

CD

CD

Sesión

Actividad

CD

CD

Sesión

Sesión

Actividad

CD

CD

En esta capa la referencia a los dispositivos es por nombre y no por dirección. Además, es aquí donde se definen las API’s (Application Program Interface). El protocolo del nivel de sesión es orientado a la aplicación, ya que sus funcionalidades se adaptan a las necesidades de la aplicación. Las unidades de datos del nivel de sesión, SPDUs, que regulan el diálogo, fluyen horizontalmente a través del nivel 5, pero son puestas en circulación por iniciativa de los correspondientes procesos de aplicación que residen a nivel 7. Es decir, la capa de sesión no en un nivel autónomo que tenga capacidad para tomar decisiones sobre quién habla y quién escucha. Estas decisiones se reservan para las entidades de la capa de aplicación. El nivel 5 sólo proporciona los mecanismos para que las entidades de aplicación puedan regular el diálogo entre sí. En el párrafo anterior se habla como si la capa de aplicación residiera directamente encima de la de sesión. Esto no es así. Como se indica al principio del apartado 3, la capa de sesión ofrece sus servicios a la capa de presentación. Lo que ocurre es que el protocolo de nivel 6 no es un protocolo “normal”. De hecho, la mayor parte de las primitivas que comunican la capa de presentación con el nivel 7 son traslación exacta de las correspondientes primitivas entre el nivel 6 y la capa de sesión.

1.3.6. LA CAPA DE PRESENTACIÓN (NIVEL 6) A diferencia de las capas inferiores, las explicadas hasta ahora, que se ocupan sólo del movimiento fiable de bits de un lado a otro, la capa de presentación se encarga de la sintaxis y la semántica de la información que se transmite. Además, aísla a dichas capas inferiores del formato de los datos de las aplicaciones específicas. Las estructuras de datos a intercambiar se deben definir de forma abstracta, mediante la codificación de estos datos de una manera estándar acordada, haciendo posible así la comunicación entre computadoras con representaciones locales diferentes. La capa de presentación maneja estas estructuras de datos abstractas y las convierte de la representación de la computadora a la representación estándar de la red y viceversa. Además de esta funcionalidad, la capa de presentación ofrece a la capa de aplicación los servicios de: □

Garantía de que la información que envía la capa de aplicación de un sistema pueda ser entendida y utilizada por la capa de aplicación de otro sistema.

□

Acuerdo y negociación de la sintaxis de transferencia en la fase de establecimiento de la conexión. La sintaxis elegida puede ser cambiada durante el tiempo que dure la conexión.

□

à

Definición del código a utilizar para representar una cadena de caracteres (ASCII, EBCDIC, etc.)

à

Interpretación de formatos de números...

Compresión de los datos, si es necesario.


□

Aplicación de procesos criptográficos, si así se requiere. Es el nivel clave para el sistema de seguridad del modelo OSI.

□

Formateo de la información para su visualización o impresión.

1.3.7. LA CAPA DE APLICACIÓN (NIVEL 7) Es la capa del modelo OSI más cercana al usuario. Difiere de las demás capas en que no proporciona servicios a ninguna otra capa OSI, sino a aplicaciones que se encuentran fuera del modelo. Todas las capas anteriores sirven de mera infraestructura de telecomunicaciones, es decir, mantienen en buen estado el camino para que fluyan los datos. Es la capa de aplicación la que hace posible que una red se pueda usar, a pesar de estar abstraída de todas las restantes funciones necesarias para el establecimiento de la comunicación. Las aplicaciones más importantes que hacen uso de esta capa, para que los procesos de las aplicaciones accedan al entorno OSI son, entre otras: □

Correo electrónico. Primera aplicación que se normalizó en OSI.

□

Terminal virtual de red abstracta, que diferentes editores y programas puedan manejar.

□

Transferencia de archivos.

□

Carga remota de trabajos.

□

Servicios de directorio.

□

Login remoto (rlogin, telnet).

□

Acceso a bases de datos.

□

Sistemas operativos de red.

□

Aplicaciones Cliente/Servidor...

Por supuesto, en el nivel 7 también hay cabida para aplicaciones “particulares” diseñadas por y para un núcleo reducido de usuarios, pero carecen de demasiado interés. Las PDUs de la capa de aplicación, APDUs, son de formato muy flexible y variable. Entre dos APDUs pueden encontrarse diferencias sustanciales en cuanto a su tamaño, número de campos presentes, etc, que dependen de las necesidades de cada momento. A cada una de las partes de una aplicación que se encarga de una tarea específica se denomina Elemento de Servicio de Aplicación (ASE). El conjunto de todos los ASEs que forman una aplicación concreta y la relación entre ellos forman el contexto de aplicación. Hay ASEs válidos para varias aplicaciones: □

ACSE (Association Control Service Element). Establecimiento, manejo y liberación ordenada o abrupta de conexiones. Lo utilizan todas las aplicaciones.

□

RTSE (ReliableTransfer Service Element). Garantiza fiabilidad en la transferencia de datos, solucionando los problemas que se hayan producido de nivel 4 hacia arriba. Se encarga de manejar todas las funciones de nivel 5. Lo utilizan algunas aplicaciones, no todas.

□

ROSE (Remote Operation Service Element). Facilita el trabajo de petición de operaciones remotas y devolución de los resultados.

Las aplicaciones se componen de una mezcla de elementos específicos y comunes. Las siguientes figuras ilustran las relaciones entre ASEs comunes.


Resto aplicaciones Para aplicaciones que no manejan RTSE ni ROSE. Tienen que gestionar por sí mismas los puntos de sincronización, los token, etc.

ACSE

N Presentación Resto aplicaciones

El RTSE es el que se encarga de las actividades, los puntos de sincronización, etc. En este caso, la aplicación no maneja directamente el nivel 5, sino que lo hace a través de RTSE.

RTSE

ACSE

N Presentación

Resto aplicaciones

ROSE Para las aplicaciones que hacen uso de los tres ASEs comunes. RTSE

ACSE

N Presentación Resto aplicaciones En este caso, ROSE trabaja directamente sobre el nivel 5. ROSE

ACSE

N Presentación



1.4.

CRÍTICAS DEL MODELO

La verdadera razón de que el modelo OSI tenga siete capas es que, en el momento en que se diseñó, IBM tenía un protocolo patentado de siete capas, llamado SNA (System Network Architecture, Arquitectura de Red de Sistemas) y, en esa época, IBM dominaba la industria de la computación. Por otro lado, el proceso de estandarización fue demasiado largo. Cuando todavía se trabajaba en la definición de OSI, ya existían implementaciones completas y gratuitas de TCP/IP y aplicaciones como e-mail, telnet, ftp, etc. Algunos de los problemas o fallos que se han detectado en el modelo de referencia OSI son:

2. 2.1.

□

Aunque el modelo OSI, junto con sus definiciones y protocolos de servicios, es muy completo; hay que reconocer que los estándares son difíciles de implementar e ineficientes en su operación. Las implementaciones iniciales fueron enormes, inmanejables y lentas.

□

OSI se desarrolló antes de que se inventaran los protocolos. Así que los diseñadores no supieron bien qué funcionalidad poner en cada capa.

□

La capa de sesión tiene poco uso en la mayor parte de las aplicaciones.

□

La capa de presentación está prácticamente vacía.

□

Por el contrario, las capas de red y enlace de datos están muy llenas, hasta tal punto que han llegado a dividirse en múltiples subcapas, cada una con funciones distintas.

□

Algunas funciones, como el direccionamiento, el control de flujo y el control de errores, reaparecen una y otra vez en cada capa.

□

Omisión de la administración de la red en el modelo.

□

Aunque en el presente documento se ha ubicado en la capa de presentación la función de cifrado y seguridad de los datos, inicialmente se dejó fuera del modelo por falta de acuerdo sobre en qué capa colocarlo.

□

En la capa de red se ofrece servicio orientado a la conexión y no orientado a la conexión. Sin embargo, en la capa de transporte, donde el servicio es visible a los usuarios, sólo se ofrece comunicación orientada a la conexión.

□

El modelo está dominado por una mentalidad de comunicaciones. Las computadoras son diferentes de los teléfonos. Muchas de las decisiones tomadas son inapropiadas para la forma de trabajar de las computadoras y el software. El modelo de un sistema controlado por interrupciones no se ajusta conceptualmente con las ideas modernas de la programación estructurada.

PROTOCOLOS TCP/IP INTRODUCCIÓN

El nacimiento del modelo TCP/IP se remonta a la red ARPANET. Ésta era una red de investigación controlada por el Departamento de Defensa de EE.UU. Poco a poco fueron conectándose instituciones y universidades, mediante el uso de líneas telefónicas alquiladas. La necesidad de buscar una arquitectura de referencia nueva surgió cuando empezaron a añadirse redes de satélite y radio y hubo problemas a la hora de interactuar con los protocolos existentes. Uno de los principales objetivos de esta nueva arquitectura fue la capacidad de conexión de múltiples redes entre sí. Esta arquitectura desembocó en lo que hoy conocemos como modelo de referencia TCP/IP. TCP/IP tiene una mayor aplicación que el modelo OSI, ya que se desarrolló antes y las empresas implantaron TCP/IP mientras esperaban el protocolo OSI. Además, como todas las especificaciones asociadas a los protocolos TCP/IP son de dominio público, y por lo tanto no hay que pagar nada para usarlos, han sido utilizados extensivamente por autoridades comerciales y públicas para crear entornos de redes abiertos.


La carta de presentación del modelo TCP/IP dice en su favor que: □

Agrupa bancos de redes, creando una red mayor llamada Internet.

□

Es independiente del hardware del nodo, del sistema operativo y de la tecnología del medio y del enlace de datos.

□

Ofrece capacidad de encaminamiento adaptativo, transparente al usuario.

□

Es el software de red más disponible universalmente.

Las diferencias más notables entre ambos modelos de referencia, OSI y TCP/IP, se enumeran a continuación: □

Mientras que en OSI la distinción entre los conceptos de servicio, interfaz y protocolo es clara, en TCP/IP no existía esta distinción inicialmente. Posteriormente, se ha intentado ajustar esto para acercarse más a OSI.

□

OSI se desarrolló antes de que se inventaran los protocolos, mientras que TCP/IP fue, en realidad, una descripción de los protocolos existentes.

□

Una diferencia clara es que OSI cuenta con siete capas bien definidas y TCP/IP sólo tiene 4.

□

El modelo OSI considera los dos tipos de comunicación, orientada y no orientada a la conexión, en la capa de red. Sin embargo, en la capa de transporte, donde el servicio es visible al usuario, ofrece únicamente comunicación orientada a la conexión. Por otro lado, el modelo TCP/IP en la capa de red sólo tiene el modo sin conexión pero considera ambos modos en la capa de transporte, ofreciendo posibilidad de elección a los usuarios.

2.2.

CAPAS DEL MODELO TCP/IP

La arquitectura del modelo TCP/IP consta de 4 capas: □

□

□

Aplicación. Proporciona comunicación entre procesos o aplicaciones en ordenadores distintos. Contiene todos los protocolos de alto nivel. A continuación se enumeran los más importantes: à

TELNET Æ Permite que un usuario, desde una máquina, entre en otra máquina distante y trabaje en ella.

à

FTP Æ Protocolo de transferencia de archivos que permite el movimiento de datos entre máquinas de forma eficiente.

à

SMTP Æ Correo electrónico.

à

NNTP Æ Protocolo de transferencia de artículos de noticias.

à

HTTP Æ Protocolo de recuperación de páginas de Internet.

Transporte. Al igual que la capa de transporte de OSI, permite que se pueda establecer una comunicación entre las entidades pares de los nodos origen y destino. Proporciona, por tanto, transferencia de datos extremo a extremo, asegurando que los datos llegan en el mismo orden que han sido enviados y sin errores. Esta capa también puede incluir mecanismos de seguridad. Se puede resumir la funcionalidad de la capa de transporte como calidad de servicio. En este nivel se definen dos protocolos importantes, que se explican en detalle más adelante. à

TCP Æ Protocolo orientado a la conexión que proporciona entrega fiable de mensajes entre máquinas. Realiza control de flujo para que un emisor rápido no pueda saturar a un receptor lento.

à

UDP Æ Protocolo sin conexión y no fiable. Se utiliza en aplicaciones donde la entrega rápida es más importante que la entrega precisa, como transmisión de voz y vídeo, y en aplicaciones de consulta de petición y respuesta, del tipo cliente-servidor.

Interred. Esta capa es el eje de la arquitectura y permite que los nodos inyecten paquetes en cualquier red y los hagan viajar de forma independiente a su destino, sin importar si está en la misma red, o si hay


otras redes entre ellas. Su misión principal, por tanto, es el enrutamiento de los paquetes, pero sin garantía de que lleguen al extremo final ni de que lo hagan en el mismo orden en que se enviaron. Si se desea una entrega ordenada, las capas superiores deben reordenar los paquetes. En este nivel se define un formato de paquete y el protocolo IP, que se detallan en el capítulo siguiente. □

2.3.

Capa del nodo a la red. El modelo TCP/IP no dice mucho de lo que sucede bajo la capa de interred, existe un gran vacío. Esta abstracción de la topología de red pone en relieve la capacidad de la capa de interred de soportar cualquier tipo de red por debajo. Lo que está claro es que debe permitir que un nodo se conecte a la red para que pueda enviar por ella paquetes IP. El protocolo que regula esta conexión puede variar de un nodo a otro.

PROTOCOLOS DEL NIVEL DE RED

El modelo de referencia TCP/IP consta principalmente de tres protocolos: IP, UDP y TCP. El protocolo básico es IP y permite enviar mensajes entre dos equipos. En los apartados siguientes se describen más en detalle estos y otros protocolos del modelo.

2.3.1. PROTOCOLO IP IP proporciona un servicio de distribución de paquetes caracterizado por: □

Transmisión de datos en datagramas (paquetes IP).

□

No es orientado a la conexión, por lo que los paquetes son tratados de forma independiente y cada uno puede seguir una trayectoria diferente en su viaje hacia el host destino.

□

No es fiable, por lo que no garantiza la entrega de los paquetes, ni la entrega en secuencia, ni la entrega única. Esto es responsabilidad del protocolo TCP de la capa superior.

□

No implementa control de errores ni control de congestión.

□

Puede fragmentar los paquetes si es necesario.

□

Direcciona los paquetes empleando direcciones lógicas IP de 32 bits. (IPv4)

□

Verifica la integridad del paquete en sí, no de los datos que contiene.

2.3.1.1. DATAGRAMA IP Los datos proporcionados por la capa de transporte son divididos en datagramas y transmitidos a través de la capa de red. A lo largo del camino pueden ser fragmentados en unidades más pequeñas para atravesar una red o subred cuya MTU (Unidad de Transferencia Máxima) sea más pequeña que el paquete. En la máquina destino, estas unidades son reensambladas para volver a tener el datagrama original que es entregado a la capa de transporte. Un datagrama IP está formado por un cuerpo y una cabecera. El cuerpo se corresponde con el segmento TCP/UDP de la capa de transporte. La cabecera tiene una parte fija de 20 bytes y una parte opcional de longitud variable. En la siguiente figura puede verse la estructura de dicha cabecera. Además, se acompaña con la descripción de cada campo.



32 bits

Versión

IHL

Tipo de servicio D F

Identificación TTL (tiempo de vida)

Longitud total

Protocolo

M F

Desplazamiento del fragmento

Suma de comprobación de la cabecera

Dirección de origen Dirección de destino

Opciones (de 0 a 40 bytes)

□

Versión (4 bits). Indica la versión del protocolo al que pertenece el datagrama. El propósito de este campo es permitir la evolución del protocolo y que durante la transición entre las versiones se pueda ejecutar en unas máquinas la versión vieja y en otras la versión nueva. Actualmente hay dos versiones: la 4 (Ipv4) y la 6 (Ipv6).

□

IHL (Internet Header Length) (4 bits). Indica la longitud de la cabecera en palabras de 32 bits, ya que ésta no tiene una longitud constante. Si no hay opciones, este valor es mínimo e igual a 5. El valor máximo es 15 (4 bits a “1”, “1111”=15 en decimal). Como cada palabra equivale a 4 bytes, el tamaño máximo de la cabecera es de 60 bytes y, por tanto, de 40 bytes el campo de opciones.

□

Tipo de servicio (8 bits). La subred ofrece distintos grados de confiabilidad y seguridad. Con este campo el host puede indicarle a la subred el tipo de servicio que quiere, combinando fiabilidad y seguridad. Este campo contiene, a su vez, de izquierda a derecha: à

Campo de precedencia (3 bits) Æ Indica la prioridad, de 0 (normal) a 7 (paquete de control de red).

à

Tres bits indicadores Æ D (Delay=retardo), T (Throughput=rendimiento) y R (Reliability=fiabilidad), que permiten especificar qué interesa más.

à

Dos bits no usados.

□

Longitud total (16 bits). Longitud total en octetos del datagrama, incluyendo cabecera y datos. La longitud teórica máxima es 65535 bytes (64 Kbytes) pero en la práctica los datagramas son de unos 1500 bytes. Este tamaño máximo será insuficiente en las redes futuras de alta velocidad. Internet no limita los datagramas a un tamaño específico pero sugiere que redes y enrutadores estén preparados para manejar datagramas a partir de 576 octetos.

□

Identificación (16 bits). Cuando se transmite un datagrama a través de Internet puede ser necesario fragmentarlo en unidades más pequeñas a lo largo del camino. Este campo permite al host destino determinar a qué datagrama pertenece un fragmento recién llegado, ya que todos los fragmentos de un mismo datagrama contienen el mismo valor de identificación.

□

1 bit sin uso actualmente.

□

Bit DF (Don’t Fragment). Puesto a “1”, indica a los enrutadores que no pueden fragmentar el datagrama porque el destino no va a poder unir las piezas de nuevo. Si es demasiado grande y no se puede enviar, se descarta y se envía al origen un mensaje de error.

□

Bit MF (More Fragment). Este bit está a “1” en todos los fragmentos de un datagrama excepto en el último. De esta forma, se sabe cuándo han llegado todos los fragmentos.



□

Desplazamiento del fragmento (13 bits). Indica en qué posición del datagrama original, medido en unidades de 8 octetos (64 bits), se encuentra el fragmento actual. Todos los fragmentos, menos el último del datagrama, deben tener una longitud múltiplo de 8 bytes. Puede haber 8192 fragmentos como máximo por datagrama.

□

TTL o tiempo de vida (8 bits). Contador que sirve para limitar la vida de un paquete. Teóricamente, cuenta el tiempo en segundos, permitiendo una vida máxima de 255 segundos (“11111111”=255 en decimal). Debe disminuirse en cada salto. En la práctica, simplemente cuenta saltos. Cuando el contador llega a 0 el paquete se descarta y se envía al host origen un paquete de aviso. Este campo evita que los paquetes estén dando vueltas eternamente por la red.

□

Protocolo (8 bits). Indica la entidad de la capa de transporte a la que debe entregarse el datagrama una vez que la capa de red del host destino lo ensambla por completo.

□

Suma de comprobación de la cabecera (16 bits). Verifica sólo la cabecera y es útil para la detección de errores generados por palabras de memoria en mal estado en un enrutador.

□

Dirección de origen y dirección de destino (32 bits, cada una). Indican la dirección IP origen y la dirección IP destino.

□

Opciones (de 0 a 40 bytes). Las opciones son de longitud variable. Empiezan con un código de 1 byte, que identifica la opción. A continuación, sólo para algunas opciones, 1 byte que indica la longitud de la opción. Finalmente, uno o más bytes de datos. El campo de opciones se rellena para obtener palabras completas o, lo que es lo mismo, múltiplos de 4 bytes. Las opciones las eligen las aplicaciones de origen aunque es bastante raro usarlas. Actualmente hay 5 opciones definidas: à

Seguridad Æ Permite añadir una etiqueta para indicar lo secreta que es la información que contiene el datagrama. En la práctica, los enrutadores ignoran esta opción.

à

Enrutamiento estricto desde el origen Æ Indica la trayectoria completa a seguir como secuencia de direcciones IP. Esta opción es usada por los administradores para hacer mediciones de tiempo.

à

Enrutamiento libre desde el origen Æ Se indica una lista de enrutadores por los que tiene que pasar el paquete, en el orden especificado, pero puede pasar a través de otros enrutadores en el camino. Es de utilidad cuando las consideraciones políticas o económicas dictan pasar o evitar ciertos países.

à

Registrar ruta Æ Indica a los enrutadores por los que pasa el datagrama que agreguen su dirección IP de 32 bits en el campo de opciones para conocer la ruta que ha seguido el datagrama.

à

Marca de tiempo Æ Como la opción anterior, pero además el enrutador también tiene que registrar una marca de tiempo de 32 bits, expresada en milisegundos, de acuerdo a cada reloj local. Ambas opciones se utilizan principalmente para la búsqueda de fallos en los algoritmos de enrutamiento.

2.3.1.2. DIRECCIONES IP Cada nodo de la red tiene una dirección IP única, formada por el número de red y el número de host. Para evitar que dos nodos tengan la misma dirección IP existe un organismo de asignación de direcciones, el NIC (Network Information Center). Estas direcciones son de 32 bits de longitud y generalmente se escriben en notación decimal con puntos. Se usan en los campos de dirección de origen y dirección de destino de los paquetes IP. Las direcciones se agrupan en clases. El formato de cada una puede verse gráficamente en la siguiente figura.

TEMARIO-TICC-mar04


32 bits 8 bits 0 Red (1 - 126) 10

Red (1º byte 128 - 191)

110

Clase A

Host

Red (1º byte 192 - 223)

Host

Clase B Host

Clase C

1110

Dirección multitransmisión (1º byte 224 - 239)

Clase D

11110

Reservado para uso futuro (1º byte 240 - 247)

Clase E

□

Clase A. Tiene 8 bits para referenciar la identificación de la red, pero el primer bit es siempre 0. Por tanto, sólo permite direccionar 27 = 128 redes. A este número hay que restarle 2, puesto que las direcciones 0.0.0.0 y 127.0.0.0 están reservadas, quedando un total de 126 redes. La dirección de red 0.0.0.0 se denomina encaminamiento por defecto y 127.0.0.0 es la dirección de loopback, como se explica más abajo. Por otro lado, esta clase puede direccionar 224 – 2 = 16.777.214 nodos, puesto que las direcciones X.0.0.0 y X.255.255.255 son las direcciones de red y difusión respectivamente. Una dirección con todos los bits de la parte de host a 0 se refiere a la red y con todos los bits de nodo a 1 se denomina dirección de difusión y se utiliza para referirse a todos los host de la red especificada.

□

Clase B. Tiene dos octetos para identificar la red, pero los dos primeros bits están fijados a 10, con lo que existen 214 =16.384 posibilidades. El número de host posibles es 216 – 2 = 65.534.

□

Clase C. Sabiendo que los tres primeros bits son fijos (110), el número de redes posibles es 221 = 2.097.152. Por otro lado, el número de nodos posibles es 28 – 2 = 254.

□

Clase D. El rango de direcciones de esta clase se utiliza para dirigir un datagrama a múltiples hosts.

□

Clase E. Este rango se reserva para uso futuro.

El siguiente ejemplo permite clarificar la diferencia entre una dirección de red, una dirección de difusión y una dirección asignable: Se tiene la dirección 115.40.110.15. Para determinar a qué clase pertenece nos fijamos en el primer byte. Como es un 115, está contenido en el rango 1-126 por lo que se trata de una dirección de clase A. Esto quiere decir que el primer octeto identifica la red. Como se ha explicado antes, poniendo todos los bits a 0 en la parte de host, se tiene la dirección de la red. Así pues, 115.0.0.0 es una dirección de red de clase A. También se ha comentado que poniendo a 1 todos los bits del host se tiene la dirección de difusión para la red indicada, que será la 115.255.255.255. Quitando la dirección de red y la de difusión, el resto del rango son direcciones asignables. En este ejemplo, se pueden asignar 224 – 2 = 16.777.214 direcciones de host, de la 115.0.0.1 a la 115.255.255.254. Existen algunas direcciones especiales: □

Cuando se arranca un host, éste utiliza la dirección IP 0.0.0.0 inicialmente.

□

El formato de dirección para referirse a una red se hace completando la parte local de la dirección con ceros. Ejemplo: 5.0.0.0 es una dirección de red de clase A.

□

Las direcciones IP con número de red igual a 0 se refieren a la red actual. Ejemplo: 0.193.130.11 es un host en su propia red, de clase A.

□

Para difusión en una subred local, se usa la dirección 255.255.255.255. No es reenviada por los encaminadores.



□

Para difundir un mensaje a todos los nodos de una red distante, la dirección IP a utilizar tiene un número de red y sólo unos en el campo de host. Ejemplo: 131.18.255.255 para difusión a todos los ordenadores de la red de clase B 131.18.0.0.

□

Las direcciones con formato 127.xx.yy.zz se utilizan para pruebas de realimentación. La dirección 127.0.0.1 se utiliza como dirección interna, también llamada “loopback”.

Subredes Todos los ordenadores de una red deben tener el mismo número de red. Esta característica puede llegar a ser un problema a medida que crecen las redes. La solución a este problema es la división de una red en varias partes o subredes. Desde el punto de vista del mundo exterior las subredes no son visibles, sino que se ve la red como un todo. Por esta razón, no es necesario ponerse en contacto con el NIC para la asignación de una subred nueva. Al incluir el concepto de subred, la parte de la dirección IP que identifica la red no cambia, mientras que la parte de host ahora se divide en subred y nodo dentro de ésta. Por ejemplo, se supongamos una organización que tiene asignada la red de tipo B 145.25.0.0 pero quiere tener sus máquinas repartidas en redes de área local o LAN’s diferentes. La forma de conseguir esto es mediante la creación de subredes dentro de la red existente. El número de bits asignados a la parte de subred y a la parte de host puede variar en función de las necesidades de la organización. En este ejemplo, suponemos que de los 16 bits correspondientes inicialmente a la parte de host de la red de clase B, 6 van a identificar la subred y 10 el nodo. De esta forma, se tiene una red de clase B con posibilidad de albergar hasta 26 – 2 = 62 subredes (el 0 y el 1 se reservan), con 210 – 2 = 1022 hosts cada una. Máscaras de red y subred La herramienta que permite obtener la dirección de red de una dirección IP dada es la máscara de red. Es una especie de dirección IP especial que, en binario, tiene todos los bits que definen la red puestos a 1 y los bits correspondientes al host puestos a 0. Así, las máscaras de red de los diferentes tipos de redes principales son: □

Red de clase A: Máscara de red = 255.0.0.0

□

Red de clase B: Máscara de red = 255.255.0.0

□

Red de clase C: Máscara de red = 255.255.255.0

La máscara de red posee la propiedad de que cuando se combina, mediante una operación AND lógica, con la dirección IP de un host se obtiene la dirección propia de la red en la que se encuentra el mismo. En las redes donde hay definidas subredes se aplica el concepto de máscara de subred. Siguiendo con el ejemplo anterior, la máscara de subred que debe aplicarse es 255.255.252.0. Es decir, si se recibe un mensaje con la dirección 145.25.25.25 se sabe que va destinado al host 281 de la subred 6. A continuación se clarifica esta afirmación mediante notación binaria: la dirección recibida es 10001100.00011001.00011001.00011001. Como el primer byte es un 145 (está en el rango 128-191) se sabe que es de clase B y, por tanto, la máscara de red es 255.255.0.0. Dirección recibida Máscara de red Máscara de subred

10001100.00011001.00011001.00011001 11111111.11111111.00000000.00000000 11111111.11111111.11111100.00000000 < ---------red---------- >< -----host---->

Red Subred Host

10001100.00011001 = 145.25 000110 = 6 0100011001 = 281


IP móvil La mayor parte de las direcciones IP se asignan a host estacionarios, es decir, que nunca se mueven. Sin embargo, hoy en día, millones de personas tienen ordenadores portátiles que se mueven de un punto a otro de la red. A continuación se explica el proceso de asignación de direcciones IP a host móviles: □

Por un lado, todos los hosts tienen una dirección base permanente.

□

Por otro lado, en todas las áreas de la red existe un agente de base, que lleva el registro de todos los usuarios móviles cuya base está en el área, pero que actualmente están visitando otra área, y uno o más agentes foráneos, que llevan el registro de todos los usuarios que visitan el área.

□

Cuando un host se conecta en un área nueva debe registrarse con el agente foráneo de ese lugar, dando su dirección base, su dirección actual de capa de enlace de datos y cierta información de seguridad.

□

El agente foráneo se pone en contacto con el agente de base del host móvil para informarle de que uno de sus host está en el área de dicho agente foráneo. Éste le envía al agente de base la información de seguridad proporcionada por el host móvil y su propia dirección IP.

□

El agente de base examina la información de seguridad.

□

Cuando el agente foráneo recibe el reconocimiento del agente de base, hace una entrada en sus tablas e informa al host móvil que ahora está registrado.

Los paquetes enviados al host móvil son interceptados por el agente de base. Éste lo encapsula en un paquete exterior y lo envía al agente foráneo que controla al host móvil. Este mecanismo se llama proceso de túnel. El agente foráneo recibe el paquete encapsulado, extrae el paquete original de y se lo envía al host móvil. Además, el agente de base informa al emisor del paquete original para que en el futuro envíe los paquetes al host móvil a través del agente foráneo. Cuando el host móvil abandona un área debería comunicarlo para borrar el registro pero muchas veces no lo hace. Para evitar los problemas que esto conlleva, el registro es válido sólo por un intervalo de tiempo fijo, transcurrido el cuál el agente foráneo limpia sus tablas. El registro puede renovarse periódicamente antes de que se agote el tiempo de validez. CIDR. Enrutamiento interdominios sin clases Se está agotando el espacio de direcciones IP de 32 bits. En teoría existen cerca de dos mil millones de direcciones pero la práctica de organizar el espacio de direcciones por clases desperdicia millones de ellas. Para la mayoría de las organizaciones una red clase A, con 16 millones de direcciones, es demasiado grande y una red clase C es demasiado pequeña. Una red clase B es la adecuada pero hay estudios que demuestran que más de la mitad de todas las redes clase B tienen menos de 50 hosts. Por tanto, una red clase C habría sido suficiente. Sin embargo, si se usaran medio millón de redes clase C, se necesitarían tablas de enrutamiento con miles de entradas en los routers, complicando con una tasa mayor que la lineal los algoritmos relacionados con el mantenimiento de dichas tablas. El enrutamiento interdominios sin clases CIDR (Classless InterDomain Routing) supone un respiro ante este problema. Se basa en el reparto de las redes clase C no asignadas aún en bloques de tamaño variable. De esta forma si una instalación necesita 2000 direcciones se asignan 8 redes clase C contiguas en vez de una dirección clase B completa.

2.3.1.3. ENRUTAMIENTO Para enrutar los paquetes de una red a otra se utilizan unos dispositivos denominados enrutadores o routers. Son los encargados de determinar el camino concreto que seguirá cada paquete en su viaje desde el host origen al host destino.


Cada enrutador posee en su interior una tabla de encaminamiento para alcanzar redes distantes y otra para alcanzar redes locales. En la primera se almacenan direcciones IP de redes y subredes distintas de la actual, así como la máscara e interfaz de salida asociada a cada una de ellas. Y en la segunda tabla las direcciones de los hosts de la subred actual, junto con la dirección de la tarjeta de red de dicho host. De esta forma, cada enrutador sólo tiene que llevar el registro de otras redes/subredes y de los host locales. Las tablas de direccionamiento deben estar ordenadas de las direcciones más específicas hasta la más general y recorrerse en este orden. Las tablas de enrutamiento pueden ser fijas y contener rutas alternativas que serán utilizadas cuando algún dispositivo de encaminamiento no esté disponible. También pueden ser dinámicas de forma que el router puede ir modificándolas de acuerdo con el estado de la red y de los enrutadores que se comunican con él. Este es el motivo por el que los paquetes pertenecientes a una misma comunicación pueden seguir caminos diferentes. Los hosts también poseen tablas de encaminamiento. De hecho, cuando un host desea enviar datos a otro lo primero que hace es comprobar si el host destino aparece en sus tablas de enrutamiento. En caso afirmativo los datagramas le son enviados directamente mediante su dirección física (la dirección de su tarjeta de red). En caso contrario envía un mensaje de petición ARP (este concepto se explica más adelante), que será respondido por el host destino enviando su dirección física. A partir de aquí se procede como en el caso afirmativo. En ambos casos el proceso recibe el nombre de entrega directa. Si ningún host de la red/subred responde al mensaje de petición los datagramas son enviados al router para que éste se encargue de su direccionamiento. En este caso se habla de entrega indirecta. Cuando un paquete IP llega a un enrutador, se extrae la dirección del host destino y se comprueba, pasándole las diferentes máscaras almacenadas en la tabla de enrutamiento, si pertenece a alguna de las redes que dicho router une. En caso afirmativo, el enrutador se comporta como un host más y sigue el proceso de entrega directa explicado en el párrafo anterior. Si el host destino no pertenece a ninguna de las redes que conecta el router, se reenvía al siguiente enrutador por la interfaz dada en la tabla de enrutamiento. De esta forma, el paquete va saltando de uno a otro router, hasta llegar a uno que sí esté conectado a la red destino. De todo esto se desprende que, si sólo se tuvieran que enviar datos entre hosts de la misma red, no sería necesario el uso del protocolo IP ya que con el direccionamiento físico mediante los números de las tarjetas de red se podría trabajar sin problemas. Sin embargo, cuando se deben mandar datos a hosts de otra red el protocolo IP es necesario porque el conjunto de números de tarjeta de red conforma un sistema de direccionamiento plano. Es decir, dichos números son asignados secuencialmente por el fabricante de la tarjeta, no dando información alguna de la localización del host que la tiene instalada.

2.3.2. PROTOCOLOS DE CONTROL Además de IP que, como hemos visto, se usa para la transferencia de datos, en la capa de red se usan varios protocolos de control, como ICMP, ARP, RARP y BOOPT.

2.3.2.1. ICMP. PROTOCOLO DE CONTROL DE MENSAJES DE INTERNET Cuando ocurre algún suceso, ICMP (Internet Control Message Protocol) es el protocolo encargado de informar del mismo. No toma ninguna decisión al respecto, esto es tarea de las capas superiores. Los mensajes de ICMP se encapsulan dentro del campo de datos de los paquetes IP. El mensaje ICMP tiene tres campos fijos y a continuación el cuerpo del mensaje que varía en función del tipo de mensaje. Los campos obligatorios son: □

Tipo (8 bits). Se utiliza para distinguir los tipos de mensajes ICMP, descritos más abajo, y determinar su formato.

□

Código (8 bits). En algunos mensajes ICMP se utiliza este campo para distinguir distintos subtipos dentro de un tipo de mensaje, es decir, para ofrecer una descripción concreta del error que se ha producido.

□

Checksum (16 bits). Código de protección contra errores de transmisión.



Existen diversos tipos de mensajes ICMP. Por un lado, están los mensajes informativos. Todos ellos contienen, además de los 3 campos fijos, un identificador de 16 bits y un número de secuencia, también de 16 bits. Los mensajes informativos más importantes son los siguientes: □

Solicitud de eco (Tipo 8). Permite detectar si un destino concreto es alcanzable y está vivo. Cuando se envía un mensaje de este tipo se espera que el destino, si existe, devuelva un mensaje de Respuesta de eco. Lleva un campo de Datos opcional con un número de bytes variables que fija el host peticionario.

□

Respuesta de eco (Tipo 0). Mensaje que se devuelve cuando se recibe un mensaje de Solicitud de eco al emisor de dicho mensaje. Si el mensaje de solicitud lleva campo de datos, éste se copia en el mensaje de respuesta, tal como llega. Este mecanismo permite ver si paquetes de distintos tamaños llegan o no a un destino.

□

Solicitud de marca de tiempo (Tipo 13). Misma funcionalidad que el mensaje Solicitud de eco pero indica al receptor que debe añadir información adicional de tiempos en el mensaje de respuesta.

□

Respuesta de marca de tiempo (Tipo 14). Parecido al mensaje de Respuesta de eco pero además almacena el tiempo de llegada del mensaje de Solicitud de marca de tiempo y el tiempo de partida del mensaje de respuesta. Los mensajes de solicitud y respuesta de marca de tiempo permiten estimar el retardo extremo a extremo y sincronizar los relojes de los hosts.

□

Solicitud de máscara de dirección (Tipo 17). Lo utiliza un host cuando se reinicia en una red y no conoce cuántos bits se han asignado a la máscara de subred.

□

Respuesta de máscara de dirección (Tipo 18). Ante un mensaje del tipo anterior, normalmente es un router el que contesta con un datagrama con los bits de red y subred puestos a 1 y los de host a 0.

El resto son mensajes de error. Todos ellos contienen, además de los 3 campos fijos, el encabezado y los 8 primeros bytes del datagrama que ocasionó el error. Los mensajes de error más importantes son los siguientes: □

□

Destino inalcanzable (Tipo 3). Este tipo de mensaje se utiliza ante varias situaciones. El campo de código describe el error concreto que se ha producido. à

Código=0 Æ Se usa cuando no se puede encontrar la red del destino del mensaje.

à

Código=1 Æ Cuando el propio host o aplicación destino está inalcanzable.

à

Código=2 Æ Cuando el campo de protocolo del datagrama no coincide con ninguno de los protocolos del host destino.

à

Código=3 Æ No se puede llegar al puerto destino o la aplicación destino no está libre.

à

Código=4 Æ Cuando una red no puede transportar un paquete IP demasiado grande para ella pero lleva el bit DF activado, indicando que no se permite fragmentación.

à

Código=5 Æ La ruta de origen no es correcta.

à

Código=6 Æ No se conoce la red destino.

à

Código=7 Æ No se conoce el host destino.

à

Código=8 Æ El host origen está aislado.

à

Código=9 Æ La comunicación con la red destino está prohibida por razones administrativas.

à

Código=10 Æ La comunicación con el host destino está prohibida por razones administrativas.

à

Código=11 Æ No se puede llegar a la red destino debido al Tipo de servicio.

à

Código=12 Æ No se puede llegar al host destino debido al Tipo de servicio.

Tiempo excedido (Tipo 11). Cuando existe una alta congestión en la red o los paquetes están vagando por la red en bucle, llega un momento en que el contador de tiempo de vida del paquete llega a 0. Cuando esto ocurre se envía un mensaje de Tiempo excedido al origen del datagrama descartado, con el campo de Código puesto a 0. Esto puede ser síntoma de que el temporizador tiene un valor demasiado pequeño. Otra situación en la que se envía este mensaje es cuando finaliza el tiempo de espera de los


trozos de un datagrama fragmentado sin que se hayan recibido todos. En este caso, el valor del campo Código es 1. □

Problema de parámetro (Tipo 12). Indica que algún campo de la cabecera tiene un valor ilegal, que el tamaño del datagrama es incorrecto o que falta algún campo obligatorio, debido a un fallo del software de IP en el host emisor o en alguno de los enrutadores por los que ha pasado el mensaje. Este mensaje incluye un campo Indicador de 8 bits que apunta al campo del encabezado IP que generó el problema.

□

Supresión de origen (Tipo 4). Cuando un host envía muchos paquetes se le envía un mensaje de este tipo con la intención de que deje de enviar tantos. Actualmente no se usa mucho este tipo de mensaje ICMP porque incrementan la posibilidad de congestión en la red.

□

Redireccionamiento (Tipo 5). Cuando un enrutador detecta que un paquete puede estar mal encaminado envía un mensaje de este tipo al host emisor del paquete para avisarle del posible error y para que modifique sus tablas de enrutamiento, si procede.

2.3.2.2. ARP. PROTOCOLO DE RESOLUCIÓN DE DIRECCIONES El hardware de la capa de enlace de datos no entiende las direcciones IP, es necesario que sean traducidas a direcciones físicas. Una posible solución es tener un archivo de configuración en algún lugar del sistema que proyecte las direcciones IP en direcciones físicas. Sin embargo, en organizaciones con miles de hosts, el mantenimiento y gestión de estos archivos conllevaría mucho tiempo y sería muy susceptible de errores. Una solución más sencilla la ofrece el protocolo de resolución de direcciones, ARP (Address Resolution Protocol). Cuando un host quiere enviar un paquete a otro, del cual conoce su dirección IP pero no su dirección física, envía un paquete ARP a la red con la dirección IP que se quiere resolver. La difusión llegará a cada host de la red, que revisará su propia dirección IP, y sólo aquel que coincida responderá con su dirección física. El host origen pone en su caché el resultado de esta operación por si necesita establecer contacto con el mismo host posteriormente. Esta solución admite distintas optimizaciones. Cuando un nodo envía un mensaje a otro, para lo que ha utilizado previamente el protocolo ARP para obtener la dirección física del host destino, lo más normal es que el host destino devuelva una respuesta. Por tanto, el destino debe utilizar el protocolo ARP para determinar la dirección física del transmisor. Esto podría evitarse si el host origen incluye en su primer paquete ARP la proyección de su dirección IP a dirección física. En este caso, todos los host de la red que reciben este paquete incluyen dicha proyección en sus cachés de ARP. Otra mejora sería que todos los hosts difundan su proyección al arrancar mediante un paquete de ARP. No debe haber respuesta, pero todos los hosts de la red crean una entrada en su caché de ARP con la proyección recibida. Si se recibe respuesta es porque dos host de la red tienen la misma dirección IP. En este caso, el host que se está conectando debe informar de ello al administrador del sistema y no arrancar. A continuación se muestra el formato de la trama de ARP. T.HW

PROTO

L.HW

L.IP

OPERACION D.O.HW D.O.IP D.D.HW D.D.IP

□

T.HW (Tipo de hardware). Especifica la tecnología de red. Ejemplo: Ethernet -> T.HW=1

□

PROTO (Tipo de protocolo). Especifica el tipo de protocolo de nivel de red para el que se están resolviendo las direcciones físicas.

□

L.HW (Longitud hardware). Especifica la longitud de la dirección física que se va a resolver.

□

L.IP (Longitud IP). Especifica la longitud de la dirección del protocolo de nivel 3 que hay que traducir.

□

OPERACION à

1 = Solicitud ARP


à

2 = Respuesta ARP

à

3 = Solicitud RARP

à

4 = Respuesta RARP

□

D.O.HW (Dirección origen HW). Especifica la dirección física del emisor de la trama ARP.

□

D.O.IP (Dirección origen IP). Especifica la dirección de nivel 3 del emisor de la trama ARP.

□

D.D.HW (Dirección destino HW). Especifica la dirección física del destino de la trama ARP. Si se trata de una operación de solicitud, será una dirección de difusión.

□

D.D.IP (Dirección destino IP). Especifica la dirección de nivel 3 del destino de la trama ARP.

2.3.2.3. RARP. PROTOCOLO DE RESOLUCIÓN DE DIRECCIONES INVERSO. A veces se produce el caso inverso al anterior. Es decir, se necesita conocer la dirección IP dada una dirección física. Esto ocurre, por ejemplo, cuando se inicia una máquina sin disco que normalmente recibe la imagen binaria de su sistema operativo de un servidor de archivos remoto pero desconoce su dirección de IP. El protocolo de resolución de direcciones inverso RARP (Reverse Address Resolution Protocol) permite que un host recién iniciado difunda su dirección física para preguntar si alguien en la red conoce la dirección IP asociada a ella. Cuando el servidor RARP recibe esta solicitud busca la dirección física en sus archivos de configuración y le envía la dirección de IP correspondiente. Es preferible usar RARP a integrar la dirección IP en la imagen de memoria. La razón es que, si se hiciera esto último, cada máquina necesitaría su propia imagen de memoria. De esta forma se puede usar la misma imagen para todas las máquinas. El problema de RARP es que usa una dirección de difusión limitada, con todos los bits a 1, que no es reenviada por los enrutadores. Por esta razón es necesario que haya un servidor RARP en cada red. El formato de la trama RARP es como el explicado para ARP.

2.3.2.4. BOOTP Para solucionar el problema de RARP planteado en el apartado anterior se ha inventado un protocolo alterno de arranque llamado BOOTP. A diferencia de RARP, BOOTP utiliza mensajes UDP que se reenvían a través de los enrutadores. Este protocolo también proporciona información adicional a una estación de trabajo sin disco, incluida la dirección IP del servidor de archivos que contiene la imagen de memoria, la dirección IP del enrutador predeterminado y la máscara de subred a usar.

2.3.2.5. IGMP. PROTOCOLO DE ADMINISTRACIÓN DE GRUPOS DE INTERNET La comunicación IP normal es entre un transmisor y un receptor. En algunas aplicaciones, sin embargo, es útil poder transmitir a una cantidad grande de receptores de forma simultánea. Por ejemplo, las actualizaciones de réplicas, las bases de datos distribuidas, etc. IP maneja la multitransmisión usando direcciones clase D (direcciones multicast) que identifican cada una a un grupo de hosts (estos host mantienen su dirección IP individual de forma que responden a ambas direcciones). Cuando se envía un paquete a una dirección clase D se intenta entregar a todos los miembros de grupo, pero no se dan garantías (protocolo best-effort). La multitransmisión se lleva a cabo mediante enrutadores especiales. Aproximadamente cada minuto todos los enrutadores multitransmisión envían una multitransmisión de hardware a los host de su red local, solicitándoles



que indiquen las direcciones clase D o los grupos en los que están interesados. Cada host responde con dicha información. Estos paquetes de solicitud y respuesta usan el protocolo IGMP (Internet Group Management Protocol). La trama IGMP tiene los siguientes campos: 0 VERS

4 8 TYPE

16 SIN USO CHECKSUM DIRECCIÓN DE GRUPO DE MULTIENVÍO

31

2.3.3. PROTOCOLOS DE ENRUTAMIENTO

2.3.3.1. OSPF. PROTOCOLO DE ENRUTAMIENTO DE PASARELA INTERIOR OSPF (Open Shortest Path First) se estandarizó en 1990 desbancando al protocolo de vector de distancia RIP, que sólo funcionaba bien en sistemas pequeños. Los requisitos que se pretendían cubrir cuando se diseño OSPF eran: □

El algoritmo no podía ser propiedad de una compañía sino que tenía que publicarse como literatura abierta.

□

El nuevo protocolo tenía que reconocer distintas métricas de distancia, incluidas distancia física y retardo.

□

Tenía que ser un algoritmo dinámico que se adaptara a los cambio de topología de forma rápida y automática.

□

El nuevo protocolo tenía que reconocer el enrutamiento basado en el tipo de servicio, diferenciando entre el tráfico de tiempo real y el resto.

□

El protocolo tenía que efectuar equilibrio de cargas, dividiéndola entre varias líneas.

□

Reconocimiento de sistemas jerárquicos de modo que ningún enrutador tuviera que conocer la topología completa.

□

Se requería un mínimo de seguridad para evitar el envío de información de enrutamiento falsa a los enrutadores.

En OSPF se pueden encontrar distintos tipos de topologías: □

Punto a punto. Este tipo de topologías son las más simples, ya que en ellas sólo intervienen dos enrutadores conectados de forma directa formando un único enlace.

□

Redes multiacceso con difusión. Los enrutadores tienen en común una red que permite tráfico de multicast, es decir, dirigido a varios routers.

□

Redes multiacceso sin difusión. La red que une a los distintos enrutadores no permite tráfico de multicast. Es necesario emular esta característica mediante la replicación de mensajes.

Los host, normalmente, no desempeñan ningún papel en OSPF. OSPF funciona mapeando el conjunto de redes, enrutadores y líneas en un grafo dirigido, en el que a cada arco se le asigna un coste, y calculando la trayectoria más corta desde cada dispositivo de enrutamiento a todos los demás en base a los pesos de los arcos. OSPF maneja áreas numeradas, donde un área es una generalización de una subred. La topología y detalles de un área no son visibles desde fuera de la misma. El área 0 es el área de backbone. Todas las áreas se conectan al backbone. Cada enrutador conectado a dos o más áreas forma parte del backbone. Dentro de un área todos los routers tienen la misma base de datos y ejecutan el mismo algoritmo de trayectoria más corta a todos los


demás enrutadores del área, incluido el que está conectado al backbone. Un router conectado a dos áreas necesita las bases de datos de ambas áreas y debe ejecutar para cada una por separado el algoritmo de trayectoria más corta. OSPF maneja el enrutamiento en función del tipo de servicio teniendo varios grafos etiquetados con los costes según la métrica utilizada. Para uno la métrica es el retardo, para otro es el rendimiento y, para otro, la fiabilidad. Esto triplica el cálculo necesario pero permite rutas separadas para optimizar el retardo, el rendimiento y la fiabilidad. La siguiente tabla muestra los tipos de mensaje OSPF: Tipo de mensaje Hola Actualización de estado de enlace Reconocimiento de estado de enlace Descripción de la base de datos Solicitud de estado de enlace

Descripción Sirve para descubrir quiénes son los vecinos Proporciona los costes del transmisor a sus vecinos Reconocimiento de la actualización de estado de enlace Anuncia las actualizaciones que tiene el transmisor Solicita información del compañero

2.3.3.2. BGP. PROTOCOLO DE ENRUTAMIENTO DE PASARELA EXTERIOR Todo lo que tiene que hacer un protocolo de pasarela interior, como OSPF, es mover paquetes con la mayor eficiencia posible del origen al destino sin necesidad de preocuparse por la política. Sin embargo, los protocolos de pasarela exterior en general, y en particular el BGP (Border Gateway Protocol), se han diseñado para permitir muchos tipos de políticas de enrutamiento. Las políticas típicas comprenden consideraciones políticas, valga la redundancia, de seguridad o económicas. Se configuran manualmente en cada enrutador BGP y no son parte del protocolo mismo. Un ejemplo de restricción de enrutamiento es que el tráfico que comience o termine en una organización no debe transitar por redes de la competencia. BGP tiene especial interés en el tráfico de tránsito. Las redes se agrupan en tres categorías: □

Redes de punta. Sólo tienen una conexión al grafo BGP. No se pueden usar para el tráfico en tránsito porque no hay nadie al otro lado.

□

Redes multiconectadas. Pueden utilizarse para el tráfico de tránsito excepto que si se niegan ha hacerlo.

□

Redes de tránsito. Están dispuestas a manejar los paquetes de terceros, posiblemente con algunas restricciones. Un ejemplo de este tipo son los backbones.

Dos enrutadores BGP se consideran conectados si comparten una red común. Los pares de routers BGP se comunican entre ellos estableciendo conexiones TCP, proporcionando comunicación fiable y ocultando todos los detalles de la red por la que pasa. BGP es fundamentalmente un protocolo de vector de distancia, en el que cada dispositivo de encaminamiento mantiene el coste a cada destino y, además, la trayectoria seguida. Del mismo modo, en lugar de dar periódicamente a cada vecino sus costes estimados a todos los destinos posibles, cada enrutador BGP le dice a sus vecinos la trayectoria exacta que está usando. La esencia de BGP es el intercambio de información de enrutamiento entre dispositivos de encaminamiento. Esta información actualizada se va propagando a través de un conjunto de redes. BGP involucra tres procedimientos funcionales: □

Adquisición de vecino. Dos routers son vecinos si están conectados a la misma subred y están de acuerdo en que quieren intercambiar información de enrutamiento entre ellos.

□

Detección de vecino alcanzable. Permite mantener la relación de vecino.



□

Detección de red alcanzable. Cada enrutador mantiene una base de datos con todas las redes que puede alcanzar y la mejor ruta para alcanzarla.

Todos los mensajes BGP tienen una cabecera de 19 bytes formada por tres campos: □

Marcador. Permite al receptor verificar la identidad del emisor.

□

Longitud. Indica el tamaño del mensaje en bytes.

□

Tipo. Indica el tipo del mensaje. Hay 4 tipos: Open, Update, Notification y Keepalive.

Alguno de estos mensajes puede tener campos adicionales, además de la cabecera.

2.3.4. IPv6 A lo largo del capítulo 3 se han puesto de manifiesto algunas de las limitaciones de IP (IPv4). En 1990 se empezó a trabajar en una nueva versión de IP que fuera más flexible y superase los problemas de IPv4. Las principales metas que se perseguían eran: □

Manejar miles de millones de host, aún con asignación de espacio de direcciones ineficiente.

□

Reducir el tamaño de las tablas de enrutamiento.

□

Simplificar el protocolo para permitir a los enrutadores el procesamiento más rápido de los paquetes.

□

Proporcionar mayor seguridad.

□

Prestar más atención al tipo de servicio, especialmente a los datos en tiempo real.

□

Mejorar la multitransmisión.

□

Posibilitar que un host sea móvil sin cambiar su dirección.

□

Permitir que el protocolo evolucione.

□

Permitir que distintas versiones del protocolo puedan coexistir.

Así surge la nueva versión de IP, IPv6 (también llamado IPng=Internet Protocol Next Generation). Dos de las características más significativas de IPv6 son: □

Direcciones de 16 bytes de longitud, frente a las direcciones de 4 bytes de IPv4.

□

Simplificación de la cabecera. Campos que en IPv4 eran obligatorios en IPv6 son opcionales. Esto permite a los enrutadores procesar los paquetes con mayor rapidez y, por tanto, mejorar el rendimiento.

En IPv6 las direcciones identifican a una interfaz o conjunto de interfaces, no a un nodo. Para identificar a un host como perteneciente a una red dada se ha sustituido el método de las máscaras de red por el de los Identificadores: [prefijo de abonado][Identificador de subred][Identificador de interfaz], de n bits, (80-n) bits y 48 bits, respectivamente. El Identificador de interfaz se construye mediante el número de la tarjeta de red del host (dirección física), con lo que se unen la dirección física y la lógica. Las redes que implementan IPv6 son más fáciles de administrar, tienen menos problemas de tráfico y cargan menos a los enrutadores. También cambian los protocolos encargados de gestionar el sistema, perdiendo importancia algunos de ellos, como el ARP, y apareciendo otros nuevos encargados de la comunicación y el paso de referencias entre los diferentes routers.


2.3.4.1. LA CABECERA DE IPv6 La cabecera consta de los siguientes campos: □

Versión. Para IPv6 su valor es siempre 6.

□

Prioridad. Permite distinguir entre paquetes a los que se les puede controlar el flujo y a los que no. Para transmisiones capaces de reducir su velocidad en caso de congestionamiento se utilizan los valores de 0 a 7. Los valores de 8 a 15 son para el tráfico en tiempo real cuya tasa de envío es constante, aún cuando se estén perdiendo paquetes. Dentro de cada grupo, los paquetes de número más alto son más importantes que los paquetes de número más bajo.

□

Etiqueta de flujo. Este campo está pensado para permitir a un origen y un destino establecer una pseudoconexión con propiedades y requisitos particulares.

□

Longitud de carga útil. Indica cuántos bytes siguen a la cabecera de 40 bytes.

□

Siguiente cabecera. La razón por la que pudo reducirse la cabecera es que puede haber cabeceras adicionales de extensión, que son opcionales y proporcionan información extra codificada de una forma eficiente. Este campo indica cuál de las seis cabeceras de extensión sigue a ésta. Si es la última cabecera de IP este campo indica el protocolo de transporte al que se entregará el paquete en el destino. Las cabeceras de extensión deben aparecer tras la cabecera fija en el siguiente orden de preferencia. Cabecera de extensión Opciones salto por salto Enrutamiento Fragmentación Verificación de autenticidad Carga útil cifrada de seguridad Opciones de destino

Descripción Información diversa para los enrutadores Ruta total o parcial a seguir Manejo de fragmentos de datagrama Comprobación de la identidad del transmisor Información sobre el contenido cifrado Información adicional para el destino

□

Límite de saltos. Se usa para evitar que los paquetes vivan eternamente. Es el equivalente al TTL de IPv4.

□

Dirección de origen y dirección de destino. Direcciones de 16 bytes de longitud fija. Además de manejar direcciones punto a punto y multitransmisión (multicast), IPv6 también maneja un nuevo tipo de direccionamiento, la transmisión a cualquiera (anycast). Consiste en entregar el paquete a un solo destino de entre un grupo dado, generalmente al más cercano. Las direcciones se escriben como ocho grupos de cuatro dígitos hexadecimales, separados los grupos por dos puntos.



32 bits

Versión

Prioridad

Etiqueta de flujo

Longitud de carga útil

Siguiente cabecera

Límite de saltos

Dirección de origen (16 bytes)

Dirección de destino (16 bytes)

Comparando con IPv4, lo que se ha dejado fuera de la cabecera de IPv6 es: □

IHL, porque la cabecera de IPv6 tiene una longitud fija.

□

Protocolo, porque el campo de Siguiente cabecera se utiliza también para este propósito.

□

Todos los campos relacionados con la fragmentación, porque IPv6 afronta la fragmentación de forma diferente. Todos los host y enrutadores deben reconocer paquetes de 576 bytes, lo que hace que sea menos probable que haya que fragmentarlos. Cuando un host envía un paquete de IPv6 demasiado grande, en vez de fragmentarlo, el enrutador que no es capaz de reenviarlo envía hacia atrás un mensaje de error que indica al host que divida todos los paquetes futuros a ese destino. Es más eficiente hacer que el host envíe paquetes del tamaño correcto que hacer que los enrutadores los fragmenten por el camino.

□

Checksum, porque su cálculo reduce en gran medida el rendimiento.

2.4.

PROTOCOLOS DEL NIVEL DE TRANSPORTE

2.4.1. PROTOCOLO TCP TCP (Transmisión Control Protocol) se diseñó específicamente para enviar una secuencia de bytes fiable a través de una interred no fiable. Sus características principales son: □

Es un protocolo orientado a la conexión. TCP establece una conexión entre un socket de la máquina transmisora y un socket de la máquina receptora. Un socket es un punto terminal al que se le asigna un número de socket formado por la dirección IP del host y un número de 16 bits local a ese host, llamado puerto. Puerto es el nombre que se le asigna a los Puntos de acceso al servicio de nivel 4 (TSAP). Una vez establecida la conexión se pueden transferir datos entre origen y destino. 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 existe un único circuito de comunicación entre ambos hosts.

□

Es un protocolo fiable.

□

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



□

Es un protocolo con transferencia de memoria intermedia. Con objeto de minimizar el tráfico de red y conseguir una transferencia eficiente, se van almacenando los datos del flujo de transmisión hasta completar un paquete lo suficientemente largo como para ser enviado. En el destino, se almacenan los datos recibidos hasta completar una secuencia completa y correcta para pasarla al proceso de aplicación destino. Los datos se almacenan en memorias intermedias denominadas buffers.

□

Usa conexiones dúplex integral, es decir, el tráfico puede ir en ambos sentidos al mismo tiempo. TCP no reconoce la multitransmisión ni la difusión.

2.4.1.1. SEGMENTO TCP Cada segmento comienza con una cabecera de formato fijo de 20 bytes. Ésta puede ir seguida de opciones de cabecera. Tras las opciones, si las hay, se encuentran los datos. También puede haber segmentos sin datos usados normalmente para acuses de recibo y mensajes de control. El formato de la cabecera TCP es el siguiente: 32 bits

Puerto de origen

Puerto de destino Número de secuencia

Longitud de cabecera TCP

U R G

A C K

Número de reconocimiento P R S F S S Y I H T N N

Suma de comprobación

Tamaño de la ventana

Apuntador urgente

Opciones (0 o más palabras de 32 bits)

Datos (opcional)

□

Puerto de origen y puerto de destino (16 bits cada uno). Identifican los puntos terminales locales de la conexión. Cada host puede decidir la forma de asignar sus propios puertos, comenzando por el 256. Al finalizar la conexión el número de puerto queda libre para ser utilizado en una futura conexión. El rango de puertos abarca desde 0 a 65535. De 0 a 1023 ya están asignados, algunos aparecen en la siguiente tabla. Puerto 20 21 23 25 80 110 119

□

Aplicación DATOS FTP TELNET SMTP HTTP POP3 NNTP

Descripción Transferencia de datos Transferencia de archivos Conexión remota Transferencia de correo Transferencia de hipertexto Recuperación de correo de PC Acceso a noticias de la red

Número de secuencia (32 bits). Indica el primer byte de datos que hay en el segmento.


□

Número de acuse de recibo (32 bits). Especifica el siguiente byte esperado, no el último byte recibido correctamente. Para que este campo se tenga en cuenta el bit ACK debe estar activado (“1”).

□

Longitud de cabecera TCP. Cantidad de palabras de 32 bits contenidas en la cabecera TCP. Es necesaria, ya que el campo de opciones es de longitud variable. El tamaño de la cabecera completa puede oscilar entre 5 y 60 bytes.

□

6 bits que no se usan. Su valor es “0” y están reservados para usos futuros.

□

6 banderas o indicadores de 1 bit con funciones de control. à

URG Æ A “1” indica que el segmento contiene datos urgentes. El Apuntador urgente (16 bits) indica el siguiente byte del campo de Datos que sigue a los datos urgentes, es decir, indica cuál es el último byte de datos que es urgente. Al recibirse los datos urgentes en el destino se interrumpe la aplicación receptora para que pueda leer el flujo de datos hasta encontrar los datos urgentes.

à

ACK Æ A “1” indica que el Número de acuse de recibo es válido. Si ACK=0 se ignora el campo de Número de acuse de recibo. Hay que tener en cuenta que un mismo segmento puede transportar datos en un sentido y confirmaciones en el sentido opuesto de la comunicación.

à

PSH Æ Indica datos empujados. Se activa para solicitar al receptor que entregue los datos a la aplicación a su llegada y no los almacene en el buffer hasta la recepción de un buffer completo.

à

RST Æ Sirve para reestablecer una conexión y para rechazar un segmento no válido o un intento de abrir una conexión.

à

SYN Æ Campo para la sincronización de los números de secuencia, que se utiliza al establecer la conexión. SYN indica el primer número de secuencia con el que se va a empezar a transmitir. Puede ser distinto de 0.

à

FIN Æ Se utiliza para liberar conexiones.

□

Tamaño de la ventana (16 bits). Indica la cantidad de bytes que pueden enviarse a partir del último byte del que se ha recibido acuse de recibo. El receptor pone el valor de la ventana a 0 cuando no puede recibir más datos.

□

Suma de comprobación (16 bits). Suma de comprobación de la cabecera, los datos y una pseudocabecera conceptual.

□

Opciones. Permite agregar características extra no cubiertas en la cabecera normal. La más importante es la que permite que cada host especifique la carga útil TCP máxima que está dispuesto a aceptar.

□

Para completar el tamaño del segmento TCP hasta que sea múltiplo de 32 bits se usan bits de relleno.

2.4.1.2. CONEXIONES TCP Para establecer una conexión uno de los lados espera pasivamente una conexión entrante y el otro ejecuta una primitiva de conexión, especificando la dirección y el puerto IP con el que se desea conectar, el tamaño máximo de segmento TCP que está dispuesto a aceptar y, opcionalmente, algunos datos de usuario. Esta primitiva genera un segmento TCP con el bit SYN encendido y el bit ACK apagado. Al llegar el segmento al destino la entidad TCP revisa si hay algún proceso escuchando en el puerto indicado en el campo de puerto de destino. Si no lo hay, envía una contestación con el bit RST encendido para rechazar la conexión. En caso contrario, el proceso recibe el segmento TCP entrante y puede aceptar o rechazar la conexión. Si la acepta, se envía de vuelta un segmento de acuse de recibo. Cuando se cae un host, por seguridad, no puede reiniciarse durante el tiempo máximo de paquete (120 seg.) para asegurar que no haya paquetes de conexiones previas vagando por Internet. Para liberar una conexión, cualquiera de las partes puede enviar un segmento TCP con el bit FIN activado, indicando que no tiene más datos que transmitir. Al reconocerse el FIN, ese sentido se apaga. Sin embargo, el flujo de datos en el otro sentido puede continuar. Cuando ambos sentidos se han apagado se libera la conexión.


En algunas implementaciones de TCP existe un temporizador de seguir con vida (keepalive timer). Cuando una conexión ha estado ociosa durante demasiado tiempo este contador puede agotarse. Si esto ocurre, un lado de la conexión comprueba si el otro aún está ahí. Si no se recibe respuesta se termina la conexión.

2.4.1.3. DETECCIÓN DE ERRORES Las técnicas más efectivas y usadas son las siguientes: □

Detección de errores. Consiste en añadir uno o más bits de información a cada segmento de forma que indiquen claramente si se ha alterado alguno de los bits del mismo en el camino del emisor al receptor. Ejemplos. à

Paridad Æ Se añade un bit de paridad al bloque de datos para que el número de bits de valor 1 sea par en todo el bloque. El receptor sólo tiene que comprobar que el número de bits 1 del bloque recibido es par para darlo por válido.

à

Checksum Æ Se obtiene un valor calculado a partir de la información del segmento completo, incluyendo dicho valor en la cabecera. En el otro extremo, el receptor vuelve a calcular este valor, comprobando que es el mismo que el suministrado en la cabecera. Si no hay coincidencia es incorrecto.

à

Comprobación de Redundancia Cíclica (CRC) Æ Partiendo de un bloque de n bits a transmitir, el emisor le suma los k bits necesarios para que n+k sea divisible por algún número conocido tanto por el emisor como por el receptor.

□

Confirmaciones positivas. El receptor devuelve un acuse de recibo positivo por cada uno de los segmentos recibidos correctamente. Se usa para detectar y solicitar el reenvío de segmentos perdidos. Esta es la técnica que se utiliza en el sistema de parada y espera (ver siguiente apartado).

□

Expiración de intervalos de tiempo. El emisor inicia un contador de tiempo tras haber enviado un segmento (el temporizador de retransmisión). Si este contador se agota sin que se reciba un ACK positivo el emisor vuelve a transmitir el mismo segmento. Como el anterior, se utiliza para detectar y solicitar el reenvío de segmentos perdidos.

□

Confirmación negativa y transmisión. El receptor sólo confirma los segmentos recibidos erróneamente para que el emisor los vuelva a enviar. Por tanto, se utiliza para solicitar el reenvío de segmentos dañados.

2.4.1.4. CONTROL DE FLUJO El control de flujo más simple es el que se lleva a cabo mediante el sistema de parada y espera. El transmisor guarda un registro de cada segmento que envía, esperando un ACK antes de enviar el siguiente. También arranca un temporizador cuando envía el segmento. Si el temporizador expira antes de recibir el acuse de recibo, retransmite el segmento y reinicia el temporizador. Este mecanismo es el más barato y el más usado cuando se transmiten tramas muy grandes pero es ineficiente ya que está el canal de transmisión desaprovechado la mayor parte del tiempo. El control de flujo mediante ventana deslizante permite que el transmisor envíe varios segmentos sin esperar los ACK correspondientes. En este sistema el emisor y el receptor se ponen de acuerdo en el número de segmentos sin procesar que puede guardar éste último, dependiendo del tamaño de sus buffers. También se ponen de acuerdo en el número de bits a utilizar para numerar cada segmento. Cuando la ventana tiene un tamaño cero el emisor no puede enviar más segmentos, salvo en dos casos excepcionales: cuando se trata de datos urgentes y cuando el emisor envía un segmento de 1 byte para provocar que el receptor genere un nuevo acuse de recibo con un nuevo tamaño de ventana, evitando así un bloqueo indefinido de la conexión. Este sistema es mucho más eficiente que el de parada y espera ya que puede haber más de un segmento a la vez en las líneas de transmisión. Una variedad mejorada del sistema de ventana deslizante es el sistema de control de flujo con adelante-atrás-N, en el que cuando la estación destino encuentra un segmento erróneo devuelve un ACK negativo, rechazando


todos los que le lleguen hasta que no reciba otra vez el segmento incorrecto en buenas condiciones. El emisor, al recibir el ACK negativo, sabe que tiene que volver a transmitir ese segmento y todos los siguientes. Por último, existe otro sistema denominado sistema de control con rechazo selectivo, que se basa en que los únicos segmentos que se vuelven a retransmitir son aquellos rechazados por el receptor o aquellos cuyo temporizador expira sin confirmación. Este método es más eficiente que los anteriores pero precisa que el receptor disponga de un buffer intermedio de gran capacidad (y por lo tanto caro) en el que guardar todos los segmentos recibidos tras el rechazo de uno dado hasta recibir de nuevo el segmento rechazado de forma correcta. Además, debe ser capaz de colocarlo en su lugar de secuencia correcto. Por su parte, el emisor debe tener la capacidad de reenviar segmentos fuera de orden. Estos motivos hacen que este método, a pesar de ser el más efectivo, sea el menos utilizado.

2.4.1.5. CONTROL DE CONGESTIÓN Cuando la carga ofrecida a la red es mayor que la que puede gestionar se produce congestión. Todos los algoritmos TCP suponen que las terminaciones de temporización son causadas por congestiones y las revisan en busca de problemas. Cada transmisor mantiene dos ventanas diferentes: □

Ventana negociada con el receptor al establecerse la conexión, cuyo tamaño está basado en el tamaño del buffer de memoria del destino. Esto permite que el transmisor no envíe más datos de los que el receptor puede almacenar evitando así que le sature.

□

Ventana de congestión, determinada por el tamaño de los datos que se pueden enviar sin que se produzca timeout.

El transmisor sólo puede mandar un número de segmentos limitado por el tamaño de la ventana más pequeña. Al establecerse una conexión, el transmisor asigna a la ventana de congestión el tamaño de segmento máximo usado por la conexión. Cada envío reconocido con éxito duplica la ventana de congestión. Este algoritmo se llama arranque lento y permite que el tamaño de la ventana de congestión crezca exponencialmente hasta que se produzca una terminación de temporización (timeout) o se alcance el tamaño de la ventana receptora. Este crecimiento exponencial puede producir saturación. Para evitarlo, se introduce otro parámetro, denominado umbral, que toma como valor inicial 64 KBytes. Cuando se produce el timeout se cambia el valor del umbral a la mitad del tamaño de la ventana de congestión, se establece el valor de la ventana al del tamaño de un segmento máximo y se inicializa otra vez el proceso de arranque lento. Ahora, cuando el tamaño de la ventana llega al del umbral ésta crece sólamente en saltos de un segmento máximo, es decir, con un progreso lineal hasta que se produzca una nueva terminación de temporización.

2.4.2. PROTOCOLO UDP El UDP (User Data Protocol) ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto, encapsulados sin tener que establecer una conexión. Es una alternativa al TCP y se usa cuando una entrega rápida es más importante que una entrega garantizada, o cuando la información a enviar cabe en un único datagrama. Sus características son: □

UDP no admite numeración de los datagramas y tampoco utiliza mensajes de confirmación de entrega. Esto hace que la garantía de que un paquete llegue a su destino sea mucho menor que si se usa TCP. También origina que los datagramas puedan llegar duplicados y/o desordenados a su destino. Por estos motivos, el control de envío de datagramas debe ser implementado por las aplicaciones que usan UDP.

□

Es un protocolo del tipo best-effort (mejor esfuerzo) porque hace lo que puede para transmitir los datagramas hacia el destino, pero no puede garantizar que éste los reciba.


□

UDP no utiliza mecanismos de control de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicación destino, se descarta.

Algunos ejemplos de situaciones en las que es más conveniente un servicio no orientado a conexión, en los que es más útil un protocolo del tipo UDP, son: □

Aplicaciones en tiempo real como audio o video, donde no se puede tolerar el retardo producido por los ACK.

□

Consultas a servidores que requieren el envío de uno o dos mensajes únicamente, como es el caso del DNS.

□

Cuando se quiere transmitir información en modo multicast (a varios destinos) o en modo broadcast (a todos los destinos), ya que no tiene sentido esperar la confirmación de todos los destinos para continuar.

2.4.2.1. DATAGRAMA UDP El datagrama UDP consiste en una cabecera de 8 bytes seguida de los datos. La cabecera presenta el siguiente aspecto. 32 bits

Puerto de origen

Puerto de destino

Longitud UDP

Suma de comprobación UDP

□

Puerto de origen y puerto de destino (16 bits cada uno). Al igual que en TCP, sirven para identificar los puntos terminales de las máquinas de origen y destino.

□

Longitud UDP (16 bits). Indica la longitud del datagrama UDP en bytes, incluyendo la cabecera de 8 bytes y los datos.

□

Suma de comprobación UDP (16 bits). Esta suma es opcional. Si no se calcula, su valor es 0.

2.5.

PROTOCOLOS DEL NIVEL DE APLICACIÓN

2.5.1. PROTOCOLOS QUE UTILIZAN UDP Entre los protocolos superiores que usan UDP se incluyen TFTP (Trivial File Transfer Protocol), SNMP (Simple Network Management Protocol), DNS (Domain Name Server), NTP (Network Time Protocol) y NFS (Network File System). Algunos de ellos de describen a continuación.

2.5.1.1. SNMP. PROTOCOLO DE GESTIÓN DE RED Los protocolos de gestión de red dividen el problema de la administración en dos partes: □

La primera parte está relacionada con la comunicación de la información. Especifica cómo se comunica el software de administrador con el SW de sistema administrativo. El componente SW del sistema administrativo que posibilita esta comunicación se llama agente.

□

La segunda parte está relacionada con los datos que se están administrando. El estándar especifica los datos que un host o un router deben conservar y las operaciones permitidas en cada uno.


es SNMP (Simple Network Management Protocol) es un protocolo cliente/servidor que se usa para configurar y monitorizar remotamente los equipos de una red. Estos elementos gestionables han de tener dirección IP para que la estación de gestión pueda comunicarse con ellos, más concretamente, con los agentes de gestión que tienen dentro los elementos gestionables, mediante la aplicación de gestión. El agente de gestión tiene acceso a la Base de Datos de Información de Gestión (MIB, Management Information Base) que representa todo lo que el elemento gestionable es capaz de ofrecer a la estación de gestión.

2.5.1.2. DNS. SERVICIO DE NOMBRES DE DOMINIO Para evitar que los usuarios tengan que recordar direcciones IP cualquier servicio en Internet puede invocarse utilizando un nombre propio y único llamado “nombre de dominio”. El servicio de nombres de dominio (DNS, Domain Name Server) se utiliza para relacionar dichos nombres de dominio de los hosts con sus direcciones IP. La asignación de direcciones sigue una estructura jerárquica. Para hacer más sencillo el acceso a los sistemas cada ordenador puede tener asignados uno o varios nombres de dominio DNS. Estos son identificadores descriptivos que permiten hacer referencia al equipo y equivalen a su dirección IP. Los nombres DNS también se asignan de forma jerárquica, añadiendo a la derecha del nombre del ordenador una serie de identificadores, que corresponden con la organización o empresa a la que pertenece el host. Ejemplo:

...

dominio

es

uc3m

subdominios

it

host

No hay límite en el número de subdominios. La forma de identificar a un host es: nombre_host.subdominio...subdominio.dominio Æ host.it.uc3m.es Cuando en un comando de aplicación se indica un nombre de máquina, el sistema siempre convierte ese nombre a una dirección IP antes de establecer la conexión. Desde la máquina que necesita saber la dirección IP se envía un paquete UDP a un servidor DNS, que busca el nombre y devuelve la dirección IP. Con la dirección IP el programa puede entonces establecer una conexión TCP con el destino o enviarle datagramas UDP.

2.5.2. PROTOCOLOS QUE UTILIZAN TCP Se incluyen en este apartado algunos de los protocolos de aplicación que hacen uso de TCP.

2.5.2.1. SMTP. PROTOCOLO DE TRANSFERENCIA DE MENSAJES SMTP (Simple Mail Transfer Protocol) es el protocolo dedicado a la transmisión de mensajes electrónicos sobre una conexión TCP. Se implementó sobre una sencilla sesión del terminal virtual de red (NVT, Network Virtual Terminal) de Telnet.



El protocolo especifica el formato de los mensajes, definiendo la estructura de la información acerca del remitente, el destinatario, datos adicionales y naturalmente el cuerpo de los mensajes. Este protocolo no especifica cómo los mensajes deben ser editados. Es necesario tener un editor local o una aplicación nativa de correo electrónico. Una vez el mensaje es creado, el SMTP lo acepta y usa el protocolo TCP para enviarlo a un módulo SMTP de otra máquina. El TCP es el encargado de intercomunicar los módulos SMTP de las máquinas implicadas. Existen extensiones de SMTP, ESMTP, definidas en un conjunto más reciente de normas, que permiten transportar cualquier tipo de información (imágenes, vídeos, sonidos codificados, hojas de cálculo, etc).

2.5.2.2. TELNET. PROTOCOLO DE CONEXIÓN REMOTA Este protocolo permite a los usuarios conectarse a ordenadores remotos y utilizarlos desde el sistema local mediante la emulación de terminal sobre una conexión TCP. Interconecta el cliente local de una máquina con el servidor con el que se comunica. Los caracteres que se teclean en un cliente local son enviados por la red y procesados en el ordenador remoto. El resultado de su ejecución se muestra en la pantalla del ordenador local. Este protocolo fue uno de los primeros que se definió y ha sido diseñado para trabajar con terminales en modo texto. Se implementa en dos módulos. □

El módulo cliente, que es un programa que ofrece un entorno no gráfico, es decir, modo carácter y es el encargado de entenderse con el programa servidor.

□

El módulo servidor, que permanece escuchando en el puerto adecuado, por defecto el puerto 23 de TCP, a la espera de peticiones por parte de los clientes.

2.5.2.3. FTP. PROTOCOLO DE TRANSFERENCIA DE FICHEROS Permite la transferencia de ficheros de texto o binarios desde un ordenador a otro sobre una conexión TCP. FTP (File Transfer Protocol) implementa un sistema estricto de restricciones basadas en propiedades y permisos sobre los ficheros. Hay un control de acceso de los usuarios y, cuando un usuario quiere realizar la transferencia de un fichero, el FTP establece una conexión TCP para el intercambio de mensajes de control. De esta manera se puede enviar el nombre de usuario, la password, los nombres de los ficheros y las acciones que se quieren realizar. Una vez se ha aceptado la transferencia del fichero, una segunda conexión TCP se establece para la transferencia de datos. El fichero se transfiere sobre la conexión de datos sin la utilización de ninguna cabecera o información de control en la capa de aplicación. Cuando se completa la transferencia, la conexión de control es usada para señalizar que la transferencia se ha completado y para aceptar nuevos comandos de transferencia.

2.5.2.4. HTTP. PROTOCOLO DE TRANSPORTE DE HIPERTEXTO HTTP (Hyper Text Transport Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP. Este protocolo fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información multimedia como el World Wide Web. Se utiliza para transmitir páginas de hipertexto y está soportado sobre los servicios de conexión TCP/IP. Un proceso servidor espera las solicitudes de conexión de los clientes Web y, una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.


2.6.

PROBLEMAS DEL MODELO TCP/IP

Aunque el modelo TCP/IP ha sido, en general, más aceptado que el modelo OSI, también tiene sus problemas:

3.

□

Como se ha dicho al comienzo del tema, el modelo TCP/IP no distingue con claridad los conceptos de servicio, interfaz y protocolo.

□

No es una buena guía para diseñar redes nuevas, ya que tampoco distingue de forma clara entre especificaciones e implementación.

□

No es un modelo general, por lo que no resulta adecuado para describir cualquier pila de protocolos distinta de TCP/IP.

□

La capa por debajo de interred, que denominamos capa de nodo a red, más que una capa es una interfaz entre la red y las capas de enlace de datos. Se echa de menos, por tanto, la existencia de la capa física y la de enlace de datos, que todo modelo bien diseñado debería incluir.

□

Como la distribución de las implementaciones era gratuita, TCP/IP se ha utilizado ampliamente, dificultando mucho su reemplazo.

CONCLUSIÓN

El modelo de referencia OSI estandariza la interconexión entre sistemas. Se divide en 7 capas y se apoya en tres conceptos fundamentales: servicio, interfaz y protocolo. El servicio dice lo que hace una capa. Cada capa presta algunos servicios a la capa superior, que accede a los mismos a través de los puntos de acceso al servicio (SAP), intercambiando primitivas de servicio; y utiliza los servicios ofrecidos por la capa inferior. La interfaz indica cómo acceder de una capa a otra, permitiendo que se comuniquen verticalmente. Finalmente, el protocolo regula la comunicación horizontal entre entidades pares, entendiendo por éstas los sistemas funcionales en capas del mismo nivel jerárquico. Las unidades que se intercambian las entidades en la comunicación horizontal se llaman PDUs y pueden ser de datos o de control. Por otro lado, las primitivas permiten a una entidad utilizar los servicios de la capa que tiene por debajo. Las hay de cuatro tipos, petición, indicación, respuesta y confirmación. El modelo OSI no es una arquitectura de red en sí, ya que no especifica los servicios y protocolos exactos que se han de usar en cada capa, sino que sólo dice lo que debe hacer cada capa. Las tres capas inferiores, física, enlace y red, tratan los protocolos asociados con la red de conmutación de paquetes utilizada para la conexión. El nivel 4 enmascara a los niveles superiores los detalles de trabajo de los niveles inferiores, dependientes de la red, y se encarga del transporte fiable de los datos sin intervenir en el significado de los mismos. Los niveles de aplicación, presentación y sesión son los usuarios del bloque de transporte, están relacionados con aspectos de las aplicaciones de usuario y aíslan la comunicación de las características específicas del sistema informático. OSI es un modelo orientado a la conexión y es necesario que exista una conexión previa para que pueda tener lugar el intercambio de datos. Para establecer una conexión N es necesario que exista una conexión N-1 por debajo. Por el contrario, la liberación de una conexión N-1 no implica la liberación de la conexión N. Para aprovechar los recursos de la forma más eficiente posible, a menudo se produce multiplexación, utilización de una sola conexión N-1 para soportar varias conexiones de nivel N, o división, utilización de más de una conexión N-1 por una sola conexión de nivel N. Una capa de una máquina no puede transferir los datos de forma directa a su capa par de otra máquina, sino que necesita los servicios de todas las capas que se encuentran por debajo de ella en la jerarquía de capas, pasando la información hacia abajo hasta llegar al nivel físico, donde son transmitidos realmente a la máquina receptora, y realizando en ésta el proceso inverso. Cuando las unidades de datos de los niveles limítrofes no tienen tamaños compatibles, se recurre a la segmentación, reparto de una unidad de datos en dos o más unidades del nivel inferior, o al bloqueo (concatenación), agrupación de varias unidades de datos en una sola unidad del nivel inferior.


El modelo TCP/IP es anterior a OSI. Es más práctico que éste y su arquitectura consta sólo de cuatro capas: aplicación, transporte, interred y la capa bajo el nivel de red, de la que no se dice mucho en este modelo. En la capa de red el protocolo más importante es IP, que transmite los datos en datagramas. No es orientado a la conexión por lo que los paquetes son tratados de forma independiente y cada uno puede seguir una trayectoria diferente en su viaje hacia el host destino. No es fiable, por lo que no garantiza la entrega de los paquetes, ni la entrega en secuencia, ni la entrega única. No implementa control de errores ni control de congestión. Puede fragmentar los paquetes si es necesario. Y, por último, direcciona los paquetes empleando direcciones lógicas IP de 32 bits (IPv4). Con sólo 32 bits se está agotando el espacio de direcciones. Para solucionar éste y otros problemas se ha desarrollado IPv6, que maneja direcciones de 16 bytes de longitud. Además del protocolo IP, a nivel 3 hay protocolos de control y enrutamiento que cooperan con el protocolo IP. Entre los protocolos de control: ICMP gestiona los errores ocurridos en la red, ARP y RARP traducen direcciones IP a direcciones físicas y viceversa e IGMP interviene en la multitransmisión. Como protocolos de enrutamiento: OSPF tiene la misión principal de mover paquetes con la mayor eficiencia posible del origen al destino y BGP se centra en el intercambio de información de enrutamiento entre routers. A nivel de transporte coexisten dos protocolos importantes: TPC y UDP. El primero es un protocolo orientado a la conexión y fiable. Utiliza conexiones dúplex integral, es decir, el tráfico puede ir en ambos sentidos al mismo tiempo, y punto a punto. No reconoce la multitransmisión ni la difusión. Realiza detección de errores, control de flujo y control de la congestión. Por otro lado, UDP ofrece un mecanismo de envío de datagramas sin tener que establecer una conexión. Se utiliza en aplicaciones donde la entrega rápida es más importante que la entrega precisa. En la capa de aplicación residen los protocolos de alto nivel. Algunos utilizan UDP como protocolo de transporte (SNMP, DNS, etc) y otros usan TCP (TELNET, FTP, HTTP, SMTP, etc).

4.

BIBLIOGRAFÍA □

Tanenbaum, A.: Redes de computadoras.

□

Fundamentos de Telemática. Universidad Politécnica de Madrid.

□

Curso on-line “Tecnologías IP”. FYCSA


5.

ESQUEMA – RESUMEN

EL MODELO OSI El modelo de referencia OSI (Open System Interconnection) surge como solución al problema de interconexión de máquinas de diferentes redes, basadas en sistemas propietarios. OSI, como su propio nombre indica, se ocupa de la conexión de sistemas abiertos con otros sistemas. No es una arquitectura de red en sí, ya que no especifica los servicios y protocolos exactos que se han de usar en cada una de las siete capas de las que consta, sino que sólo dice lo que debe hacer cada una. En el entorno de OSI se manejan tres conceptos fundamentales, que son: □

Servicio.- Dice lo que hace cada capa. Cada capa utiliza los servicios ofrecidos por la capa inferior y ofrece sus propios servicios a la capa que tiene por encima, a través de los puntos de acceso al servicio (SAP), intercambiando primitivas de servicio.

□

Interfaz.- Dice a los procesos de la capa superior cómo acceder a ella.

□

Protocolo.- Conjunto de reglas que determinan el comportamiento de comunicación horizontal entre entidades pares, entendiendo por éstas los sistemas funcionales en capas del mismo nivel jerárquico.

Las entidades de un nivel N mantienen una comunicación vertical con las entidades de los niveles N+1 y N-1, intercambiando primitivas de servicio. Existen cuatro tipos de primitivas. □

De petición (REQUEST). Empleada para invocar un servicio y pasarle los parámetros necesarios para su ejecución.

□

De indicación (INDICATION). Usada para indicar que un procedimiento ha sido invocado por el usuario par del servicio en la conexión y pasar los parámetros asociados o para indicar al usuario del servicio el inicio de una acción por parte del proveedor.

□

De respuesta (RESPONSE). Empleada por el usuario del servicio para reconocer o completar algún procedimiento previamente iniciado por una indicación del proveedor.

□

De confirmación (CONFIRM). Usada por el proveedor del servicio para reconocer o completar algún procedimiento previamente iniciado por una petición del usuario.

De igual forma, las entidades pares mantienen una comunicación lógica horizontal, regulada por el protocolo de pares, intercambiando Unidades de Datos de Protocolo (PDUs). Las PDUs pueden ser de dos tipos: □

De datos, que contiene, entre otras informaciones, el mensaje de usuario o parte de él.

□

De control, que sirven para gobernar el comportamiento completo del protocolo en sus funciones de establecimiento y ruptura de la conexión, control de flujo, control de errores, etc. No contienen información alguna proveniente del nivel superior.

Los datos de usuario contenidos en la PDU (N) de datos corresponden exactamente a la PDU (N+1). Para el nivel N son una ristra de bits, cuya semántica desconoce. La PDU (N) de datos se forma con los UD (N) y con la PCI (N), que los “envuelve” antes de entregarlos al nivel inferior. Cuando las unidades de datos de los niveles limítrofes no tienen tamaños compatibles, se recurre a alguna de las siguientes funciones: □

Segmentación de la SDU. Una SDU se reparte en más de una PDU. La función simétrica en el extremo receptor es el reensamblado, que consiste en identificar varias PDUs con una sola SDU.


□

Bloqueo de la SDU. Permite agrupar varias SDUs en una sola PDU. La función inversa del bloqueo es el desbloqueo, que consiste en descomponer una PDU en varias SDUs. El caso de segmentación se da con más frecuencia que el de bloqueo.

□

Segmentación de la PDU. Reparto de una PDU grande en más de una IDU del nivel inferior. En el extremo receptor se realiza el reensamblado.

□

Concatenación de PDU. Agrupación de varias PDUs sobre una sola SDU. La función inversa a ésta, que se realiza en el extremo receptor, es la separación. La concatenación-separación es el caso contrario de la segmentación-reensamblado de la PDU, siendo éste último más frecuente que el primero.

El modelo de referencia OSI es orientado a la conexión. Por eso, hay que establecer previamente una conexión para que pueda existir intercambio de datos. En el establecimiento, se requiere que ambas entidades estén conformes. Para establecer una conexión N es necesario que exista una conexión N-1 por debajo. Por el contrario, la liberación de una conexión N-1 no implica la liberación de la conexión N. La liberación de una conexión de nivel N puede iniciarse por una entidad del mismo nivel o del nivel superior y puede ser de dos tipos: □

Abrupta. Se libera de inmediato y los datos pendientes de envío se pierden.

□

Suave o diferida. Antes de romper la conexión, se espera a no tener datos pendientes.

Para aprovechar los recursos de la forma más eficiente, a menudo se produce alguna de estas situaciones: □

Multiplexación, que es la función que permite utilizar una sola conexión N-1 para soportar varias conexiones de nivel N. La función inversa realizada en el receptor se denomina demultiplexación. No debe confundirse el concepto de multiplexación con el de concatenación.

□

División, que es la función que permite la utilización de más de una conexión N-1 por una sola conexión de nivel N. La función inversa se denomina recombinación. No debe confundirse el concepto de división con el de segmentación.

Una capa de una máquina no puede transferir los datos de forma directa a su capa par de otra máquina, sino que necesita los servicios de todas las capas por debajo de ella, pasándose la información hacia abajo hasta llegar al nivel físico, donde son transmitidos realmente a la máquina receptora. Cada capa utiliza el encapsulamiento para colocar la PDU de la capa superior en su campo de datos y agregar la información adicional que la capa necesite para realizar su función. De esta forma, a medida que los datos se desplazan hacia abajo a través de las capas del modelo OSI, el tamaño del mensaje va creciendo. En la máquina receptora se realiza el proceso inverso, retirando los distintos encabezados, uno por uno, conforme el mensaje se propaga hacia arriba por las capas. OSI consta de 7 capas. Las tres capas inferiores, física, enlace y red, engloban lo que se conoce como bloque de transmisión y tratan los protocolos asociados con la red de conmutación de paquetes utilizada para la conexión. El nivel 4 enmascara a los niveles superiores los detalles de trabajo de los niveles inferiores, dependientes de la red, y junto con ellos forma lo que se conoce como bloque de transporte. Este bloque es común para todas las aplicaciones y se encarga del transporte fiable de los datos sin intervenir en el significado de los mismos. Los niveles de aplicación, presentación y sesión son los usuarios del bloque de transporte, están relacionados con las aplicaciones de usuario y aíslan la comunicación de las características específicas del sistema informático. Algo más en detalle, cada capa: □

Física. Relacionada con la transmisión de bits por un canal de comunicación, de forma que sólo reconoce bits individuales, sin estructura alguna. Las consideraciones de diseño tienen que ver con las interfaces mecánica, eléctrica y de procedimiento, y con el medio de transmisión que está bajo la capa física.

□

Enlace de datos. Toma el medio de transmisión en bruto y lo transforma en una línea que parezca libre de errores a los ojos de la capa de red. Estructura los datos en tramas, añadiendo una secuencia especial de bits al principio y al final de la misma.

□

Red. Capa compleja, responsable de la conmutación y enrutamiento de la información. La unidades de datos de este nivel se llaman paquetes, a los que se les asignan direcciones lógicas.


□

Transporte. Se trata de una verdadera capa extremo a extremo, del origen al destino. La comunicación en los niveles inferiores es entre máquinas adyacentes. Su función más importante es la aceptación de datos de la capa de sesión, división en unidades más pequeñas, si es preciso, denominadas segmentos, y envío de esta información a la capa de red, asegurando que todos los pedazos lleguen correctamente al otro extremo de forma eficiente, donde son reensamblados. El control de flujo es clave en esta capa.

□

Sesión. La función principal de la capa de sesión es el establecimiento, administración y finalización ordenada de sesiones entre dos máquinas. Ofrece manejo del control del diálogo (quién habla, cuándo, cuánto tiempo, half duplex o full duplex). En las comunicaciones half duplex, la capa de sesión ayuda a llevar el control de los turnos, mediante el manejo de testigos o token. También ofrece sincronización del diálogo, mediante la inserción de puntos de verificación en la corriente de datos. La capa de sesión no es un nivel autónomo que tenga capacidad para tomar decisiones sobre quién habla y quién escucha. Estas decisiones se reservan para las entidades de la capa de aplicación. El nivel 5 sólo proporciona los mecanismos para que las entidades de aplicación puedan regular el diálogo entre sí.

□

Presentación. Se encarga de la sintaxis y la semántica de la información que se transmite, aislando a dichas capas inferiores del formato de los datos de las aplicaciones específicas.

□

Aplicación. Es la capa más cercana al usuario. Difiere de las demás en que no proporciona servicios a ninguna otra capa OSI, sino a aplicaciones que se encuentran fuera del modelo. A cada una de las partes de una aplicación que se encarga de una tarea específica se denomina Elemento de Servicio de Aplicación (ASE). El conjunto de todos los ASEs que forman una aplicación concreta y la relación entre ellos forman el contexto de aplicación. Hay ASEs comunes, válidos para varias aplicaciones: à

ACSE (Association Control Service Element). Establecimiento, manejo y liberación ordenada o abrupta de conexiones.

à

RTSE (Reliable Transfer Service Element). Garantiza fiabilidad en la transferencia de datos, solucionando los problemas producidos de nivel 4 hacia arriba. Maneja las funciones de nivel 5.

à

ROSE (Remote Operation Service Element). Facilita el trabajo de petición de operaciones remotas y devolución de los resultados.

El modelo de referencia OSI ha recibido abundantes críticas, algunas de las cuales se detallan a continuación: □

OSI es muy completo, pero los estándares son difíciles de implementar e ineficientes en su operación.

□

La capa de sesión tiene poco uso en la mayor parte de las aplicaciones.

□

La capa de presentación está prácticamente vacía.

□

Por el contrario, las capas de red y enlace de datos están muy llenas, hasta tal punto que han llegado a dividirse en múltiples subcapas, cada una con funciones distintas.

□

Algunas funciones, como el direccionamiento, el control de flujo y el control de errores, reaparecen una y otra vez en cada capa.

EL MODELO TCP/IP El nacimiento del modelo TCP/IP se remonta a la red ARPANET. Permite agrupar distintas redes y conectar host entre sí, independientemente del hardware del nodo y de la tecnología del medio físico. Las diferencias más notables con el modelo de referencia OSI son: □

Mientras que en OSI la distinción entre los conceptos de servicio, interfaz y protocolo es clara, en TCP/IP no existía esta distinción inicialmente.

□

Distinto número de capas. OSI tiene 7 y TCP/IP sólo 4.

Las cuatro capas de la arquitectura TCP/IP son:



□

Aplicación. Proporciona comunicación entre procesos o aplicaciones en ordenadores distintos.

□

Transporte. Proporciona transferencia de datos extremo a extremo, asegurando que los datos llegan en el mismo orden en que han sido enviados y sin errores. En este nivel se definen dos protocolos importantes, TCP, orientado a la conexión, y UDP, sin conexión.

□

Interred. Su misión principal es el enrutamiento de los paquetes, pero sin garantía de que lleguen al extremo final ni de que lleguen en el mismo orden en que se enviaron. El protocolo más importante de este nivel y del modelo en general es IP.

□

Capa del nodo a la red. El modelo TCP/IP no dice mucho de lo que sucede bajo la capa de interred. Esta abstracción de la topología de red pone en relieve la capacidad de la capa de interred de soportar cualquier tipo de red por debajo.

En cada capa se definen una serie de protocolos para permitir la comunicación entre entidades pares en máquinas diferentes. En el nivel de red domina el protocolo IP, que maneja unidades de datos llamadas datagramas. Estos están formados por un cuerpo donde se encapsula la unidad de datos del nivel de transporte y una cabecera de hasta 60 bytes de longitud. Este protocolo tiene las siguientes características: □

No es orientado a la conexión, por lo que los paquetes son tratados de forma independiente y cada uno puede seguir una trayectoria diferente en su viaje hacia el host destino.

□

No es fiable, por lo que no garantiza la entrega de los paquetes, ni la entrega en secuencia, ni la entrega única. Esto es responsabilidad del protocolo TCP de la capa superior.

□

No implementa control de errores ni control de congestión.

□

Puede fragmentar los paquetes, si es necesario.

Cada nodo tiene una dirección IPv4 única, formada por el número de red y el número de host. Si una máquina está conectada a varias redes, tiene direcciones IP diferentes en cada red. Estas direcciones se agrupan en clases como se resume en la figura siguiente: 32 bits 8 bits 0 Red (1 - 126) 10

Red (1º byte 128 - 191)

110

Clase A

Host

Red (1º byte 192 - 223)

Host

Clase B Host

Clase C

1110

Dirección multitransmisión (1º byte 224 - 239)

Clase D

11110

Reservado para uso futuro (1º byte 240 - 247)

Clase E

El principal problema de IPv4 es que se está agotando el espacio de direcciones. Para solucionar éste y otros problemas, se ha desarrollado IPv6, que maneja direcciones de 16 bytes de longitud. Para enrutar los datagramas se utilizan enrutadores o routers, que poseen en su interior tablas de encaminamiento. Estas tablas pueden ser fijas o dinámicas, de forma que el router puede ir modificándolas de acuerdo con el estado de la red y de los enrutadores que se comunican con él. Además del protocolo IP, a nivel de red se usan varios protocolos de control y enrutamiento:


□

ICMP (Internet Control Message Protocol). Básicamente, se encarga de informar de los errores ocurridos en la red, como destino inalcanzable, finalización de temporizadores, problemas en los campos de la cabecera y problemas de enrutamiento.

□

ARP (Address Resolution Protocol). Traduce direcciones IP a direcciones físicas.

□

RARP (Reverse Address Resolution Protocol). Traduce direcciones físicas a direcciones IP dentro de una red local.

□

IGMP (Internet Group Management Protocol). Permite solicitar y obtener la información necesaria para actualizar las tablas de los enrutadores multitransmisión.

□

OSPF (Open Shortest Path First). Protocolo de enrutamiento de pasarela interior cuya misión principal es mover paquetes con la mayor eficiencia posible del origen al destino.

□

BGP (Border Gateway Protocol). Protocolo de enrutamiento de pasarela exterior que se centra en el intercambio de información de enrutamiento entre routers para contemplar distintas políticas.

A nivel de transporte existen dos protocolos importantes: □

□

TCP (Transmisión Control Protocol). Las unidades de datos que gestiona se llaman segmentos. Cada segmento comienza con una cabecera de formato fijo de 20 bytes que puede ir seguida de opciones de cabecera, tras las cuales se encuentran los datos. También puede haber segmentos sin datos, usados normalmente para acuses de recibo y mensajes de control. Sus características más relevantes son: à

Es un protocolo orientado a la conexión. Para obtener el servicio TCP debe establecerse una conexión entre origen y destino. Una vez establecida la conexión se pueden transferir datos. 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 existe un único circuito de comunicación entre ambos hosts.

à

Es un protocolo fiable.

à

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, que permite minimizar el tráfico de red y conseguir una transferencia eficiente.

à

Usa conexiones dúplex integral, es decir, el tráfico puede ir en ambos sentidos al mismo tiempo. TCP no reconoce la multitransmisión ni la difusión.

à

Detección de errores. Se emplean distintas técnicas, bits de paridad, checksum, comprobación de redundancia cíclica, confirmaciones positivas y negativas y expiración de temporizadores.

à

Control de flujo. Hay distintos mecanismos, como parada y espera y rechazo selectivo, pero el más usado es el de ventana deslizante.

à

Control de congestión mediante el empleo de dos ventanas distintas, una asociada a la capacidad de la red y otra a la capacidad del receptor.

UDP (User Data Protocol). Ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto encapsulados sin tener que establecer una conexión. Se utiliza en aplicaciones donde la entrega rápida es más importante que la entrega precisa, como transmisión de voz y vídeo, y en aplicaciones de consulta de petición y respuesta del tipo cliente-servidor. La unidad de datos se llama datagrama UDP y consiste en una cabecera de 8 bytes seguida de los datos. Sus características son: à

No admite numeración de los datagramas y tampoco utiliza mensajes de confirmación de entrega.

à

Es un protocolo del tipo best-effort (mejor esfuerzo) porque hace lo que puede para transmitir los datagramas hacia el destino pero no puede garantizar que éste los reciba.

à

No utiliza mecanismos de control de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicación destino, se descarta.


Por último, en el nivel de aplicación existen diversos protocolos. Algunos se encapsulan sobre UDP: □

SNMP (Simple Network Management Protocol). Protocolo de gestión cliente/servidor que se usa para configurar y monitorizar remotamente los equipos de la red.

□

DNS (Domain Name Server). El servicio de nombres de dominio se utiliza para relacionar dichos nombres de dominio de los hosts con sus direcciones IP.

Otros van encima de TCP: □

SMTP (Simple Mail Transfer Protocol). Protocolo dedicado a la transmisión de mensajes electrónicos sobre una conexión TCP.

□

TELNET (Remote Login). Este protocolo permite a los usuarios conectarse a ordenadores remotos y utilizarlos desde el sistema local mediante la emulación de terminal sobre una conexión TCP.

□

FTP (File Transfer Protocol). Permite la transferencia de ficheros de texto o binarios desde un ordenador a otro sobre una conexión TCP.

□

HTTP (Hyper Text Transport Protocol). Es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP.



t25 El Modelo de Referencia de Interconexión de Sistemas Abiertos

Recommend Documents