TEMA 1: INTRODUCCIÓN A REDES DE ORDENADORES

1.1.- INTRODUCCIÓN

En tan solo unos años las redes de ordenadores han pasado de ser algo esotérico solo conocido y utilizado por

unos pocos a ocupar un primer plano en cualquier medio informativo de carácter general. Quizá el protagonismo

que actualmente se da a términos como 'Internet', 'autopistas de la información' o 'aldea global' sea más fruto de

las modas que de una realidad objetiva, pero no cabe duda que dichos términos (o al menos las ideas a las que

representan) tendrán un interés creciente en los años venideros y permanecerán con nosotros durante bastante

tiempo.

Podemos hacer un cierto paralelismo entre la explosión de la Telemática en la década de los noventa y el auge de

la Informática personal en los ochenta; sin embargo a pesar de su importancia la aparición del PC no parece

comparable a la revolución que protagonizará la Telemática; la razón estriba en que, a pesar de todo, el PC

aislado es hasta cierto punto un producto minoritario, mientras que el sistema multimedia de los noventa

conectado a las redes se convertirá en una fuente de información y entretenimiento de interés para el público en

general. Existen ya en el mercado algunos modelos de lo que se conoce como 'set-top boxes' desarrollados por

empresas como Philips, Sony o Nokia, que son aparatos que se conectan a la red de datos y al televisor

doméstico. En estos equipos resulta esencial la facilidad de manejo.

Los precios de la informática vienen sufriendo desde hace bastantes años una disminución exponencial. El precio

del espacio en disco (pesetas/MB) se reduce a la mitad aproximadamente cada 4.5 años, el de la potencia de

procesador (pesetas/MIP) cada 2.3 años, y el de la memoria RAM (pesetas/MB) cada 1.8 años. Como

comparación el precio de la transmisión de datos (medido en pesetas/Mbps/Km) se reduce a la mitad cada 1.5

años aproximadamente, es decir, esta teniendo una disminución aun mayor que las tecnologías informáticas. Las

investigaciones y desarrollos en curso en materia de transmisión de datos hacen prever que dicha tendencia se

mantendrá en el futuro.

Además de los factores tecnológicos en los precios de los servicios telemáticos influyen aspectos legales que en

ocasiones alteran la situación de manera importante. Por ejemplo en España, como en otros países de Europa, la

decisión de liberalizar las telecomunicaciones en 1998 está produciendo un abaratamiento de los precios gracias a

la libre competencia, que de forma transitoria hará aun mayor la reducción que cabría esperar de los factores

puramente tecnológicos.

1.1.1.- Objetivo del curso

El curso pretende dar una formación básica en los aspectos técnicos de la comunicación de ordenadores.

El alumno deberá ser capaz al finalizar el curso de diseñar adecuadamente una red informática para una empresa,

atendiendo a criterios de coste, prestaciones y necesidades. También debería poder comprender la descripción

técnica o documentación de un producto de comunicaciones, así como artículos de la literatura especializada.

En toda área de conocimiento técnica existe una profusión de siglas para referirse a términos, conceptos o incluso

a frases concretas. La telemática es especialmente rica en este sentido, y el conocimiento del significado de tales

abreviaturas es necesario para la comprensión de la literatura técnica. Siempre que un término o concepto

disponga de una abreviatura habitual lo indicaremos junto con su significado (casi siempre en inglés) la primera

vez que aparezca. El conocimiento del significado de las siglas es como su 'etimología', y forma parte de la

'cultura general' que todo ingeniero informático debería tener.

1.1.2.- Que no es objetivo del curso

Actualmente existen, sobre todo en entornos universitarios, multitud de 'gurus' de la Internet que son capaces de

encontrar casi cualquier cosa en la red, conocen todos los servicios existentes y están al tanto de la última

aplicación o programa aparecido. Conviene destacar que no es el objeto de este curso crear tales gurus, por tres

razones:

El profesor no está capacitado para ello,

Dicha información no sería susceptible de incluirse en una asignatura del curriculum académico ya que para

cuando el estudiante iniciara su andadura profesional dicha información práctica sería ya obsoleta, y

No es este el tipo de formación que se espera de un Ingeniero Informático

En cierto modo podríamos decir, siguiendo la típica analogía de las 'autopistas de la información', que dichos

'gurus' de la Internet son muy buenos conductores, pero lo que aquí pretendemos no es obtener el carnet de

conducir sino aprender a diseñar carreteras y vehículos para que el tráfico sea lo más fluido (y seguro) posible.

Que duda cabe no obstante que nunca le vendrá mal a un ingeniero saber conducir bien, y en este sentido

estimulamos al alumno a realizar tantas 'prácticas de conducción' como le sea posible tanto durante sus estudios

como después en su futura actividad profesional.

Tampoco es objeto de este curso introducir al alumno en los aspectos legales, comerciales o políticos del mundo

de las telecomunicaciones, que son motivo de noticia casi diaria en los medios de comunicación, tanto a nivel

nacional como europeo.

1.1.3.- Telecomunicaciones y Telemática

Empezaremos por diferenciar estos dos términos fundamentales.

Entendemos por telecomunicaciones el conjunto de medios técnicos que permiten la comunicación a distancia.

Normalmente se trata de transmitir información sonora (voz, música) o visual (imágenes estáticas o en

movimiento) por ondas electromagnéticas a través de diversos medios (aire, vacío, cable de cobre, fibra óptica,

etc.). La información se puede transmitir de forma analógica, digital o mixta, pero en cualquier caso las

conversiones, si las hay, siempre se realizan de forma transparente al usuario, el cual maneja la información de

forma analógica exclusivamente.

El término telemática (fusión de telecomunicaciones e informática) trata del uso de las telecomunicaciones para

enriquecer las posibilidades de la informática (y no al revés), es decir, del uso de medios de comunicación a

distancia para conectar equipos informáticos (ordenadores con ordenadores u ordenadores con periféricos). La

información puede transmitirse de forma analógica, digital o mixta, pero esto es transparente al usuario, que

maneja la información de forma digital únicamente.

Todos los sistemas habituales de telecomunicaciones transmiten la información por medio de ondas

electromagnéticas a través de diversos medios: aire, vacío, cable de cobre fibra óptica, etc.

A modo de ejercicio diga en cuales de las siguientes situaciones se utilizan las telecomunicaciones y en cuales la

telemática:

Dos usuarios mantienen una conversación a través de dos teléfonos conectados a la RDSI (Red Digital de

Servicios Integrados).

Otros dos usuarios hablan, pero utilizan dos PCs (con tarjeta de sonido); los PCs están conectados a la Internet

mediante líneas analógicas y módems de 28.8 Kbps.

Un usuario envía a otro por mensajero un disquete que contiene un fichero.

Un usuario envía un telegrama utilizando el código Morse.

Un usuario envía un documento desde un ordenador, conectado mediante un módem y un programa emulador de

facsímil; en el destino el documento es recibido por otro ordenador conectado de la misma forma.

Dos usuarios mantienen una videoconferencia mediante PCs conectados por RDSI en los que se ha instalado el

hardware y software adecuado.

1.1.4.- Redes de ordenadores y sistemas distribuidos

La expresión redes de ordenadores (o simplemente redes) se utiliza cuando, por medio de la telemática, se realiza

la comunicación entre dos o más ordenadores. Queda excluida aquí la comunicación entre un ordenador y un

periférico (terminal, impresora, etc.) independientemente de la distancia a la que dicha comunicación se produzca

o el tipo de medios utilizados para ella. Dicho de otro modo, en redes de ordenadores se considera únicamente la

comunicación entre elementos que pueden hablar de igual a igual ('peer to peer' en inglés), sin tomar en

consideración la comunicación asimétrica maestro-esclavo.

Un caso particular de las redes de ordenadores son los sistemas distribuidos, en los que se intenta conectar varios

ordenadores mediante una red y crear un entorno de utilización tal que el usuario no perciba la existencia de

múltiples sistemas, sino que los maneje como un único sistema virtual de forma transparente; para esto se utilizan

normalmente protocolos o aplicaciones específicos. Evidentemente si el medio de comunicación es de baja

velocidad el usuario percibirá un retraso cuando acceda a un nodo remoto, por lo que generalmente los sistemas

distribuidos sólo se implementan en redes de alta velocidad (redes locales por ejemplo). Un ejemplo de protocolo

de sistemas distribuidos podría ser el NFS (Network File System) que permite acceso a ficheros remotos de

forma transparente.

1.2.- ALGUNOS USOS DE LAS REDES DE ORDENADORES

Podemos diferenciar claramente dos tipos de usos o usuarios de las redes de ordenadores: el profesional, que se

da normalmente en la empresa, y el particular, que generalmente tiene lugar en la residencia habitual de los

usuarios.

1.2.1.- Uso de las redes en empresas

Prácticamente cualquier empresa que tenga varios ordenadores hoy en día tiene una red local que los

interconecta. Si la empresa dispone de varias sedes u oficinas dispersas dispondrá típicamente de una red local

(LAN, Local Area Network) en cada una de ellas y de un medio de interconexión de dichas redes locales a través

de enlaces telefónicos (también llamados accesos WAN, Wide Area Network). La red o redes permiten acceder a

información importante y actualizada de manera rápida, por ejemplo una base de datos que contenga toda la

información comercial de la compañía (productos, stocks, precios, plazos de entrega, etc.). A menudo estas bases

de datos necesitan estar en uno o unos pocos ordenadores de la red, ya que la existencia de múltiples copias

complica las actualizaciones.

Antiguamente las aplicaciones se diseñaban para que los usuarios accedieran desde terminales 'tontos' al

ordenador central en el que se mantenía la base de datos y en el cual se procesaba la transacción en su totalidad,

pero la aparición de redes de ordenadores donde el terminal se ha convertido en un PC ha llevado a un nuevo

modelo de desarrollo de las aplicaciones llamado cliente-servidor, consistente en descargar en el PC (cliente) una

parte del proceso de la transacción (por ejemplo toda la labor de validación de los datos introducidos), y dejar

para el ordenador central (servidor) únicamente la parte que no es posible hacer en el cliente, como por ejemplo

la inclusión del nuevo registro en la base de datos. El modelo cliente-servidor reduce así de forma considerable la

potencia necesaria en el ordenador central, y permite aprovechar el PC que el usuario tiene en su mesa (y que

muy probablemente tendría de todas formas). Además así la aplicación se integra de forma mas amigable en el

ordenador del usuario final (mediante el uso de ventanas, interfaces gráficas, ratón, etc.). Así el uso del modelo

cliente-servidor, y por tanto de las redes de ordenadores puede llegar a suponer en la práctica un ahorro en los

gastos informáticos de la empresa, además de una mayor productividad de sus empleados.

Por otro lado, la existencia de redes de ordenadores permite a la empresa tener duplicado su servidor de base de

datos, o cualquier otra información vital, de forma que en caso de fallo de software, hardware, o destrucción

física del servidor la información no se vea afectada al poder los clientes seguir funcionando con el servidor de

reserva. Esto se traduce en una elevada fiabilidad del sistema, aspecto imprescindible en algunas empresas (por

ejemplo bancos, hospitales, cadenas de montaje de fábricas, etc.). Por supuesto para que el sistema en su conjunto

sea altamente fiable es preciso duplicar no solo el servidor de base de datos, sino la propia red (elementos de

conmutación, conexión, cables, etc.) de forma que no haya ningún elemento importante susceptible de fallo cuya

funcionalidad no este duplicada.

La red en las empresas permite compartir recursos, tales como periféricos de elevado costo (impresoras láser,

scanners, plotters, filmadoras, etc.), o programas (siempre y cuando la licencia que se posee permita su uso en

red) con el consiguiente ahorro de espacio en disco y sencillez de actualización.

Otra utilidad importante de la red en las empresas es como medio de comunicación entre sus empleados; el correo

electrónico es el servicio básico, pero otros mas avanzados se están implantando, tales como la videoconferencia

o las aplicaciones que permiten compartir un documento entre varios usuarios trabajando desde ordenadores

distintos. Este tipo de aplicaciones se conoce como CSCW (Computer Supported Cooperative Work) y también

como 'groupware'.

Hasta aquí hemos discutido aplicaciones orientadas fundamentalmente al uso de la red dentro de la propia

empresa (lo que en tiempos recientes se suele denominar la 'Intranet'). Dicha red puede conectarse al exterior,

bien directamente o a través de un cortafuego o 'firewall', es decir, una pasarela intermedia que permita controlar

el acceso (entrante y/o saliente) para evitar problemas de seguridad. Cuando la red de la empresa se conecta al

exterior (normalmente a la Internet) aparecen una serie de nuevas aplicaciones que le dan aun mayor utilidad,

entre las que cabe destacar las siguientes:

Las actividades de marketing; por ejemplo se puede poner el catálogo de productos de la empresa en la red para

su consulta por los clientes, con información detallada de características, precio, referencias, etc.; también es

posible tramitar pedidos recibidos a través de la red.

Actividades de soporte en línea; se puede responder a preguntas de los usuarios a través de la red, tanto por

correo electrónico como por listas de distribución o grupos de news. En el caso de empresas de software es

frecuente ofrecer a través de la red nuevas versiones de programas, sistemas operativos, parches para la

resolución de problemas, etc.

Las herramientas de comunicación antes mencionadas (correo electrónico, videoconferencia, CSCW, etc.)

adquieren una relevancia mucho mayor cuando su uso no se limita al interior de la empresa.

Algunas empresas encuentran en Internet una manera económica de interconectar sus oficinas remotas, evitando

así la contratación de líneas propias de larga distancia.

El empleado puede acceder a una enorme cantidad de información externa a su empresa útil para su trabajo, por

ejemplo información de suministradores, competidores, clientes, foros de discusión sobre temas relacionados con

su trabajo (especialmente de carácter técnico), etc. Curiosamente esta ventaja conlleva un problema, que es la

imposibilidad de evitar que el empleado utilice la conexión al exterior para acceder a información no relacionada

con su trabajo (por ejemplo sobre su hobby favorito), perdiendo en ello a veces una parte importante de su

jornada laboral. Es prácticamente imposible impedir por medios técnicos que esto suceda, aunque se pueden

adoptar algunas medidas protectoras. Este problema ha hecho a algunas empresas cuestionarse la conveniencia de

dar acceso Internet a sus empleados.

1.2.2.- Uso de las redes por particulares

El uso de las redes de ordenadores por parte de particulares tiene tres objetivos fundamentales:

· Acceso a información

· Comunicación

· Entretenimiento

El acceso a información actualmente se centra en el acceso a Internet y en particular a servidores Web. En torno a

esto han aparecido multitud de servicios derivados del uso de la telemática para diversos fines, tales como

teletrabajo, telecompra, teleenseñanza, telemedicina, etc.

La comunicación tiene lugar tanto a nivel individual (correo electrónico) como en grupos (listas de distribución,

grupos de news, etc.). Esto incluye no solo información textual, sino también multimedia: sonido, imagen y vídeo.

Además de estas aplicaciones asíncronas, en las que los participantes no han de coincidir en el tiempo, existen

otras (llamadas isócronas) en las que si han de coincidir, como las que permiten utilizar el ordenador como un

teléfono, para hablar con un usuario remoto a través de la Internet; esto supone un ahorro importante en algunos

casos ya que se puede hacer una llamada a un lugar remoto pagando tarifa local (lo cual ha motivado serias

críticas y discusiones con las compañías telefónicas, especialmente en Estados Unidos). También está el servicio

de videoconferencia, aunque esta poco extendido a nivel particular debido a su escasa difusión y a sus

requerimientos de capacidad, difíciles de satisfacer con un módem telefónico.

El uso con fines de entretenimiento será la gran aplicación de las redes de ordenadores en el futuro, pero

actualmente el reto tecnológico es tan grande que para abordarlo es preciso disponer de potentes y costosos

equipos, con lo que la rentabilidad es cuando menos dudosa. Se han hecho ya algunas experiencias de vídeo bajo

demanda en Estados Unidos, pero las necesidades de red y de servidores para un número elevado de usuarios son

tan grandes que los servicios comerciales que actualmente se ofrecen se basan generalmente en el vídeo casi bajo

demanda (NVOD, Near Vídeo On Demand) donde cada transmisión es vista por un conjunto de usuarios

simultáneamente.

1.2.3.- Aspectos sociales

La Internet es noticia casi diaria en los medios de comunicación, y no siempre en sentido positivo. Algunos

ejemplos de temas polémicos son los siguientes:

Distribución de pornografía. En muchos países es ilegal distribuir pornografía a menores, por lo que la

disponibilidad de estos materiales en la red limita a veces el acceso a la Internet en colegios. También es polémica

la distribución de pornografía infantil a adultos, que algunos consideran inaceptable en cualquier caso.

Distribución de información 'peligrosa': por ejemplo se han dado casos de personas que han aprendido a sintetizar

drogas a partir de información obtenida en la Internet; análogamente sería posible distribuir información detallada

sobre como fabricar explosivos, o incluso una bomba atómica.

Distribución de publicidad no deseada. Es tremendamente fácil recopilar una enorme lista de direcciones de

correo electrónico para distribuir a muy bajo costo cualquier propaganda de tipo comercial, político, religioso,

etc. a nivel mundial. Alguna gente recomienda en estos casos utilizar la técnica del 'ladrillo a portes pagados', es

decir, devolver al remitente un mensaje con unos cuantos Megabytes de información inútil. Esta acción tomada

por un número elevado de usuarios inutiliza el buzón y el servidor desde el que se distribuye la propaganda.

Discrepancias legales. Es posible que una información distribuida por la red desde un país sea ilegal en otro; por

ejemplo, ETA ha puesto un servidor Web en Suiza con información que en España se considera apología del

terrorismo. También es posible comprar al extranjero bienes de consumo sin pagar los impuestos

correspondientes a nuestro país.

Acceso a la Internet desde el trabajo para fines personales. Este tema, que ya hemos comentado, ha llevado a

algunas empresas a 'censurar' lo que sus empleados pueden consultar por la red.

Derecho a la privacidad. La única forma de obtener privacidad en la red es encriptando la información; sin

embargo, algunos países (Estados Unidos y Francia, por ejemplo) tienen regulaciones muy severas en ese sentido,

al punto de prohibir a los ciudadanos encriptar, salvo si el encriptado es lo bastante 'suave' como para poder

descifrarlo en caso necesario. Dicho de otro modo: el Estado siempre debe poder descifrar un mensaje si lo

considera necesario.

Anónimos: las redes de ordenadores permiten enviar mensajes anónimos. Si bien esto tiene sus ventajas, se

plantean problemas legales cuando se utiliza un anónimo por ejemplo para acusar a una persona.

1.3.- TIPOS DE REDES

De acuerdo con su tecnología de transmisión las redes se clasifican en:

· Redes broadcast (que significa radiodifusión en inglés)

· Redes punto a punto

Según su escala también se suelen clasificar en:

· Redes de área local (LAN, Local Area Network)

· Redes de área extensa (WAN, Wide Area Network)

En esta última clasificación también se distingue a veces una categoría intermedia, la formada por las redes de

área metropolitana (MAN, Metropolitan Area Network).

La combinación de estos dos criterios nos permite crear una matriz con cuatro categorías posibles; en la práctica

existen redes en cada una de estas cuatro categorías, si bien la mayoría encajan en dos de ellas:

LAN WAN

Broadcast La mayoría de las LANs (Ethernet, FDDI, Token Ring, etc.) Redes de transmisión vía

satélite

Punto a punto HIPPI, Fibre Channel La mayoría de las WANs (todas las basadas en enlaces telefónicos,

X.25, Frame Relay, RDSI, ATM, etc.)

1.3.1.- Redes broadcast

En las redes broadcast el medio de transmisión es compartido por todos los ordenadores interconectados.

Normalmente cada paquete transmitido es para un único destinatario, cuya dirección aparece en el paquete, pero

para saberlo cada máquina de la red ha de recibir o 'escuchar' cada paquete, analizar la dirección de destino y

averiguar si va o no dirigido a ella; las normas de buena educación 'telemática' establecen que un ordenador debe

descartar sin mas análisis todo paquete que no vaya dirigido a él; sin embargo, algunos programas llamados

'sniffers' se dedican a 'cotillear' todo lo que pasa por el cable, independientemente de quien sea su destinatario;

con un sniffer es muy fácil capturar cualquier cosa, por ejemplo los caracteres que viajan por la red en un proceso

de conexión averiguando así de manera rápida el userid y la password de un usuario cualquiera (por ejemplo

'root'). La única protección efectiva en las redes broadcast es el encriptado de la información.

A veces en una red broadcast lo que se quiere es precisamente enviar un paquete a todas las máquinas

conectadas. Esto se llama un envío broadcast. Asimismo es posible enviar un paquete dirigido a un subconjunto

de todas las máquinas de la red (subconjunto que ha de estar definido previamente); esto se conoce como envío

multicast (y el subconjunto se denomina grupo multicast). En algunos contextos cuando se habla de broadcast o

multicast el caso normal, en el que el paquete va dirigido a una máquina concreta, se conoce como envío unicast.

Como ejemplos de redes broadcast podemos citar prácticamente todas las tecnologías de red local: Ethernet (en

sus diversos tipos), Token Ring, FDDI, etc. También son redes broadcast las basadas en transmisión vía satélite.

En una red broadcast la capacidad o velocidad de transmisión indica la capacidad agregada de todas las máquinas

conectadas a la red; por ejemplo, la red conocida como Ethernet tiene una velocidad de 10 Mbps, lo cual significa

que la cantidad máxima de tráfico agregado de todos los equipos conectados no puede superar este valor.

Conviene mencionar en este punto que en telemática siempre que se especifican velocidades o capacidades de

transmisión los prefijos Kilo, Mega, etc., se utilizan con su significado métrico (103, 106, etc.), no con el

significado informático (210, 220, etc.); así 1 Mbps significa 1.000.000 bits/s, no 1.048.576 bits/s; análogamente

1 Kbps corresponde a 1.000 bits/s (no 1.024 bits/s). Sin embargo cuando no se trate de velocidades el significado

seguirá siendo el habitual, así por ejemplo si decimos que un determinado protocolo utiliza un tamaño máximo de

paquete de 64 Kbytes, o que hemos transmitido un fichero de 1 MByte, querremos decir que el paquete puede

contener hasta 65.536 Bytes, o que el fichero contiene 1.048.576 Bytes. Normalmente las velocidades o

capacidades de transmisión se miden en bits/segundo, mientras que en los demás casos se cuenta en Bytes.

1.3.2.- Redes punto a punto

Las redes punto a punto se construyen por medio de conexiones entre pares de ordenadores, también llamadas

líneas, enlaces, circuitos o canales (en inglés los términos equivalentes son 'lines', 'links', 'circuits', 'channels' o

'trunks'). Una vez un paquete es depositado en la línea el destino es conocido de forma unívoca y no es preciso en

principio que lleve la dirección de destino.

Los enlaces que constituyen una red punto a punto pueden ser de tres tipos de acuerdo con el sentido de la

transmisión:

Simplex: la transmisión sólo puede efectuarse en un sentido

Semi-dúplex o 'half-duplex': la transmisión puede hacerse en ambos sentidos, pero no simultáneamente

Dúplex o 'full-duplex': la transmisión puede efectuarse en ambos sentidos a la vez.

En los enlaces semi-dúplex y dúplex la velocidad de conexión es generalmente la misma en ambos sentidos, en

cuyo caso se dice que el enlace es simétrico; en caso contrario se dice que es asimétrico.

La gran mayoría de los enlaces en líneas punto a punto son dúplex simétricos. Así, cuando se habla de un enlace

de 64 Kbps sin especificar mas se quiere decir 64 Kbps en cada sentido, por lo que la capacidad total del enlace es

de 128 Kbps.

Al unir múltiples máquinas con líneas punto a punto es posible llegar a formar redes de topologías complejas en

las que no sea trivial averiguar cual es la ruta óptima a seguir para ir de un punto a otro, ya que puede haber

múltiples caminos posibles con distinto número de ordenadores intermedios, con enlaces de diversas velocidades

y distintos grados de ocupación. Como contraste, en una red broadcast el camino a seguir de una máquina a otra

es único , no existen ordenadores intermedios y el grado de ocupación es el mismo para todas ellas.

Cada uno de los ordenadores que participa en una red de enlaces punto a punto es un nodo de la red. Si el nodo

tiene un único enlace se dice que es un nodo terminal o 'end node', de lo contrario se dice que es un nodo

intermedio, de encaminamiento o 'routing node'. Cada nodo intermedio ha de tomar una serie de decisiones

respecto a por donde debe dirigir los paquetes que reciba, por lo que también se les llama nodos de conmutación

de paquetes, nodos de conmutación, conmutadores o encaminadores (los términos equivalentes en inglés son

respectivamente packet switching nodes, switching nodes, switches y routers). Dependiendo del tipo de red que

se trate nosotros utilizaremos las denominaciones router o conmutador.

Cualquier ordenador (por ejemplo una estación de trabajo UNIX, o incluso un PC con MS/DOS), puede actuar

como un router en una red si dispone del programa apropiado; sin embargo, se prefiere normalmente utilizar para

este fin ordenadores dedicados, con sistemas operativos en tiempo real y software específico, dejando los

ordenadores de propósito general para las aplicaciones del usuario; esto da normalmente mayor rendimiento y

fiabilidad. Tradicionalmente al ordenador de propósito general que se conecta a la red como nodo terminal

mediante un router se le denomina host, palabra inglesa que significa anfitrión (aunque esta denominación no se

utiliza nunca en este contexto). El conjunto de líneas de comunicación y routers que interconectan a los hosts

forman lo que se conoce como la subred de comunicaciones, o simplemente subred. Obsérvese que los hosts o

nodos terminales no forman parte de la subred. Si hacemos la analogía con la red telefónica diríamos que la

subred es el conjunto de cables y centralitas telefónicas, incluido el aplique de la pared donde conectamos el

teléfono, pero no formaría parte de la subred nuestro teléfono, que enchufamos al aplique.

Para llegar de un nodo a otro en una red se ha de atravesar uno o varios enlaces; el número de enlaces se

denomina en inglés 'hops', que significa saltos, y depende de la trayectoria seguida y de la topología de la red.

Cuando dos nodos no vecinos (es decir a mas de un 'hop' de distancia) desean intercambiar información lo han de

hacer a través de uno o varios nodos intermedios. Cuando un paquete se envía de un nodo al siguiente

normalmente el paquete es transmitido en su totalidad y almacenado; solo entonces el nodo receptor intenta

enviar el paquete al siguiente nodo de la red. Esto es lo que se conoce como una red de almacenamiento - reenvío

('store-and-forward') o red de conmutación de paquetes ('packet - switched'). Esta forma de proceder permite una

elevada fiabilidad incluso en entornos hostiles donde el número de errores puede ser elevado.

Dado que en una red punto a punto cada enlace puede tener una velocidad distinta, no podemos caracterizar la

red con un único dato de forma tan sencilla como en una red broadcast; sería preciso adjuntar un esquema de la

topología indicando el tipo de cada enlace (simplex, semi-dúplex o dúplex) y su velocidad (en cada sentido si

fuera asimétrico).

1.3.3.- Redes de área local

Las redes de área local tienen generalmente las siguientes características:

· Tecnología broadcast: medio compartido

· Cableado específico, instalado normalmente a propósito

· Velocidad de 1 a 100 Mbps

· Extensión máxima de unos 3 KM (FDDI llega a 200 Km)

Las LANs mas conocidas y extendidas son la Ethernet a 10 Mbps, la IEEE 802.5 o Token Ring a 4 y 16 Mbps, y

la FDDI a 100 Mbps. Estos tres tipos de LAN han permanecido prácticamente sin cambios desde finales de los

ochenta, por lo que a menudo se les referencia en la literatura como 'LANs tradicionales ('legacy LANs' en inglés)

para distinguirlas de otras mas modernas aparecidas en los 90, tales como la Fast Ethernet (100 Mbps).

A menudo las LANs requieren un tipo de cableado específico (de cobre o de fibra); esto no suele ser un problema

ya que al instalarse en una fábrica, campus o similar, se tiene un control completo sobre el entorno y las

condiciones de instalación.

El alcance limitado de las LANs permite saber el tiempo máximo que un paquete tardará en llegar de un extremo

a otro de la red, lo cual permite aplicar diseños que de otro modo no serían posibles, y simplifica la gestión de la

red.

Como consecuencia del alcance limitado y del control en su cableado, las redes locales suelen tener un retardo

muy bajo en las transmisiones (decenas de microsegundos) y una tasa de errores muy baja.

La topología básica de las redes locales suele ser de bus (p. ej. Ethernet) o de anillo (Token Ring o FDDI). Sin

embargo, pueden hacerse topologías mas complejas utilizando elementos adicionales, tales como repetidores,

puentes, conmutadores, etc., como veremos más adelante.

En épocas recientes se ha popularizado una técnica para aumentar el rendimiento de las redes locales, que

consiste en dividir una LAN en varias mas pequeñas, con lo que el ancho de banda disponible para cada uno es

mayor; las diversas LANs así formadas se interconectan en un equipo especial denominado conmutador LAN (o

LAN switch); en casos extremos se puede llegar a dedicar una red por equipo, disponiendo así de todo el ancho

de banda para él.

En años recientes se ha empezado a utilizar una tecnología de redes telefónicas, y por tanto típicamente de redes

WAN, para la construcción de redes locales; esta tecnología, denominada ATM (Asynchronous Transfer Mode),

dará mucho que hablar en el futuro.

1.3.4.- Redes MAN

En principio se considera que una MAN abarca una distancia de unas pocas decenas de kilómetros, que es lo que

normalmente se entiende como área metropolitana. Existe solamente una red característica de las MANs, la

conocida como IEEE 802.6 o DQDB (Distributed Queue Dual Bus), que puede funcionar a diversas velocidades

entre 34 y 155 Mbps con una distancia máxima de unos 160 Km. En realidad la distinción de MANs en base a la

distancia es un tanto arbitraria, ya que FDDI puede llegar a 200 Km pero raramente se la clasifica como MAN, al

no ser un servicio ofrecido por las compañías telefónicas, cosa que sí ocurre con DQDB en algunos países.

La tecnología DQDB ha tenido escasa difusión. Su mayor mérito ha sido servir como predecesora de ATM en

algunos aspectos. En el futuro es de esperar que la red DQDB caiga en desuso o desaparezca ya que su espacio

ha sido ocupado por completo por las redes basadas en ATM.

Un caso de redes especialmente difíciles de clasificar son las formadas por empresas de televisión por cable.

Desde el punto de vista técnico estas redes se podrían considerar tipo LAN, y como tal las estudiaremos; sin

embargo el hecho de que sean gestionadas por empresas especializadas y ofrecidas como un servicio contratable

por los usuarios les da unas características de WAN desde el punto de vista legal. Estas circunstancias unidas a su

alcance máximo (entre 160 y 200 Km) hacen que las podamos considerar en cierto modo como redes MAN.

El término MAN suele utilizarse también en ocasiones para denominar una interconexión de LANs ubicadas en

diferentes recintos geográficos (por ejemplo diferentes campus) cuando se dan las siguientes circunstancias:

La interconexión hace uso de enlaces telefónicos de alta o muy alta velocidad (comparable a la de las propias

LANs interconectadas).

La interconexión se efectúa de forma transparente al usuario, que aprecia el conjunto como una única LAN por lo

que se refiere a servicios, protocolos y velocidades de transmisión.

Existe una gestión unificada de toda la red

1.3.5.- Redes WAN

Las redes de amplio alcance se utilizan cuando no es factible tender redes locales, bien porque la distancia no lo

permite por el costo de la infraestructura o simplemente porque es preciso atravesar terrenos públicos en los que

no es posible tender infraestructura propia. En todos estos casos lo normal es utilizar para la transmisión de los

datos los servicios de una empresa portadora. Hasta hace poco este tipo de servicios eran ofrecidos en régimen de

monopolio por las compañías telefónicas en la mayoría de los países de Europa. Afortunadamente esto esta

cambiando rápidamente siendo posible por ejemplo en España contratar hoy en día servicios portadores de datos

con Retevisión, o en breve con diversas compañías de televisión por cable, si bien en muchos casos la mayor

penetración de Telefónica hace que haya un monopolio de facto.

En la literatura especializada es frecuente referirse a las compañías telefónicas europeas genéricamente con la

denominación PTT, abreviatura de Post, Telegraph and Telephone. Esto se debe a que en muchos países de

Europa la empresa que se encargaba tradicionalmente de las transmisiones telefónicas era la misma que ofrecía el

servicio de correos y telégrafos, todo esto en régimen de monopolio. Con la liberalización del servicio de

telefonía y la aparición de diversas compañías competidoras la denominación PTT se esta sustituyendo por la de

operador (que quiere decir que opera la red); la costumbre hace que en muchos casos se siga aun utilizando el

término PTT.

Las redes WAN se implementan casi siempre haciendo uso de enlaces telefónicos que han sido diseñados

principalmente para transmitir la voz humana, ya que este es el principal negocio de las compañías telefónicas.

Normalmente la infraestructura esta fuera del control del usuario, estando supeditado el servicio disponible a la

zona geográfica de que se trate. Conseguir capacidad en redes WAN suele ser caro, por lo que generalmente se

solicita el mínimo imprescindible.

Hasta tiempos recientes las conexiones WAN se caracterizaban por su lentitud, costo y tasa de errores

relativamente elevada. Con la paulatina introducción de fibras ópticas y líneas digitales en las infraestructuras de

las compañías portadoras las líneas WAN han reducido apreciablemente su tasa de errores; también se han

mejorado las capacidades y reducido los costos. A pesar del inconveniente que en ocasiones pueda suponer el uso

de líneas telefónicas tienen la gran virtud de llegar prácticamente a todas partes, que no es poco.

Con la excepción de los enlaces vía satélite, que utilizan transmisión broadcast, las redes WAN se implementan

casi siempre con enlaces punto a punto, por lo que prácticamente todo lo que hemos dicho en el apartado de

redes punto a punto es aplicable a las redes WAN.

1.3.6.- Redes Inalámbricas y movilidad.

En los últimos años ha habido un auge considerable de los sistemas de telefonía inalámbrica. Algunos usuarios

requieren facilidades para conectar por radioenlaces sus ordenadores personales desde cualquier lugar o mientras

se encuentran viajando en tren, autobús, etc. El sistema de telefonía inalámbrica digital GSM (Global System for

Mobile communications), muy extendido en Europa, utiliza un canal digital para transmitir la voz, por lo que es

posible conectar un ordenador portátil mediante un teléfono GSM, sin necesidad de módem. En algunos países ya

se han hecho experimentos de conexiones inalámbricas a 64 Kbps utilizando una versión modificada del GSM.

La conexión de ordenadores con total movilidad es importante en aplicaciones tales como flotas de taxis,

camiones, autobuses, servicios de emergencia, fines militares, etc. En estos casos se emplean, además de los ya

familiares ordenadores portátiles conocidos como 'laptops', otros aún más pequeños que se conocen como

'palmtop', asistente digital personal o PDA (Personal Digital Assistant), y que son algo intermedio entre un

ordenador portátil y una agenda electrónica.

Las redes inalámbricas también tienen utilidad en algunos casos donde no se requiere movilidad, como en las

LANs inalámbricas. Por ejemplo, una empresa que desea establecer una nueva oficina y por rapidez,

provisionalidad de la ubicación o simples razones estéticas no desea cablear el edificio puede utilizar una LAN

inalámbrica, consistente en una serie de equipos transmisores-receptores. Las LAN inalámbricas son generalmente

mas lentas que las normales (1-2 Mbps) y tienen una mayor tasa de errores, pero para muchas aplicaciones

pueden ser adecuadas.

La movilidad es importante también en casos en que no hay involucradas conexiones inalámbricas. Por ejemplo

un representante que desee conectar con su oficina desde su ordenador portátil cuando se encuentra de viaje

puede optar por llamar a su oficina directamente, pagando posiblemente una costosa llamada de larga distancia, o

bien puede llamar al punto de presencia (POP, Point Of Presence) mas próximo de algún proveedor de servicios

de comunicación, y a través de este acceder a su oficina por una infraestructura compartida que le resulte mas

barata (por ejemplo la Internet); en este último caso se dan una serie de problemas de solución no trivial en

cuanto a la seguridad y el correcto encaminamiento del tráfico.

1.3.7.- Internetworking

Si bien las clasificaciones de redes antes estudiadas tienen interés como medio de sistematizar su estudio, es obvio

que en la realidad casi nunca se da uno de esos tipos en estado puro. Por ejemplo, una LAN (que normalmente

será una red de tipo broadcast) casi siempre dispondrá de un router que la interconecte a una WAN (que

generalmente consistirá en un conjunto de enlaces punto a punto). Esta interconexión de tecnologías diferentes se

conoce como 'internetworking' (que podríamos intentar traducir como 'interredes'). El router que interconecta

redes diferentes está físicamente conectado a todas las redes que se desean interconectar.

Además de la combinación de medios físicos diversos es posible encontrarse con necesidades de internetworking

en un mismo medio físico; este es el caso cuando coexisten protocolos de comunicación diferentes; por ejemplo,

en una misma red ethernet puede haber unos ordenadores utilizando el protocolo TCP/IP y otros utilizando

DECNET (protocolo típico de la marca de ordenadores Digital). Al ser protocolos diferentes son completamente

independientes y no se pueden hablar entre sí, por lo que un usuario de un ordenador TCP/IP no podría por

ejemplo enviar un mensaje de correo electrónico a uno de un ordenador DECNET. Sin embargo, es posible

instalar en un ordenador ambos protocolos, y un programa de conversión de correo electrónico, de forma que los

usuarios de ambas redes puedan intercambiar mensajes. A la máquina que interconecta el correo electrónico de

los dos protocolos se la denomina pasarela ('gateway' en inglés). Generalmente las pasarelas han de

implementarse a nivel de aplicación; así disponer en nuestro ejemplo de una pasarela para el correo electrónico no

significa que podamos transferir ficheros entre máquinas TCP/IP y DECNET, ya que para esto haría falta una

pasarela del servicio de transferencia de ficheros. Una misma máquina puede actuar como pasarela para varios

servicios. Haciendo una analogía podemos decir que los protocolos son como idiomas y las pasarelas equivalen a

servicios de traducción que permiten entenderse a personas que hablan diferentes lenguas.

Cuando una red esta formada por la interconexión de varias redes se le denomina internet. A principios de los

setenta se creó en los Estados Unidos una internet mediante la unión de varias redes que utilizando medios de

transmisión diversos empleaban un conjunto común de protocolos en el nivel de red y superiores, denominados

TCP/IP. Con el tiempo la denominación Internet (con I mayúscula) terminó convirtiéndose en el nombre propio

de dicha red, muy conocida en nuestros días.

1.4.- ARQUITECTURA DE REDES

En los inicios de la informática el diseño de un ordenador resultaba en sí mismo una tarea tan compleja que no se

tomaba en consideración la compatibilidad con otros modelos de ordenadores; la preocupación fundamental era

que el diseño fuera correcto y eficiente. Como consecuencia de esto era preciso crear para cada nuevo modelo de

ordenador un nuevo sistema operativo y conjunto de compiladores. Los programas escritos en lenguaje máquina

o en ensamblador (que entooces eran la mayoría) tenían que ser prácticamente reescritos para cada nuevo modelo

de ordenador.

En 1964 IBM anunció un nuevo ordenador denominado Sistema/360. Se trataba en realidad de una familia

formada por varios modelos que compartían una arquitectura común (era la primera vez que se utilizaba este

término referido a ordenadores). La arquitectura establecía unas especificaciones comunes que hacían

compatibles a todos los modelos de la familia (conjunto de instrucciones, forma de representar los datos, etc.),

pudiendo así ejecutar los mismos programas, utilizar el mismo sistema operativo, compiladores, etc. en toda la

familia, que comprendía una gama de ordenadores de potencias y precios diversos. El nombre 360 se eligió en

base a la década en que se creó (los 60) y a la idea de que era una arquitectura polivalente, que pretendía servir

para aplicaciones de todo tipo (360º, o sea que puede ir en todas direcciones). La arquitectura 360 ha ido

evolucionando hasta desembocar en nuestros días en la arquitectura ESA/390, utilizada en los grandes

ordenadores IBM (mainframes) actuales, que son aún la base de las aplicaciones críticas en grandes empresas

(bancos, líneas aéreas, etc.). Todos los fabricantes de ordenadores actuales utilizan una o varias arquitecturas

como base para el diseño de sus equipos.

Las primeras redes de ordenadoresstuvieron unos inicios muy similares a los primeros ordenadores: Las redes y

los protocolos se diseñaban pensando en el hardware a utilizar en cada momento, sin tener en cuenta la evolución

previsible, ni por supuesto la interconexión y compatibilidad con equipos de otros fabricantes (seguramente

muchos creían que bastante trabajo suponía conseguir que las cosas funcionaran como para perder el tiempo con

florituras¡). A medida que la tecnología avanzaba y se mejoraba la red se vivieron experiencias parecidas a las de

los primeros ordenadores: los programas de comunicaciones, que habían costado enormes esfuerzos de

desarrollo, tenían que ser reescritos para utilizarlos con el nuevo hardware, y debido a la poca modularidad

prácticamente nada del código era aprovechable.

El problema se resolvió de forma análoga a lo que se había hecho con los ordenadores. Cada fabricante elaboró

su propia arquitectura de red, que permitía independizar las funciones y el software del hardware concreto

utilizado. De esta forma cuando se quería cambiar algún componente sólo la función o el módulo afectado tenía

que ser sustituido. La primera arquitectura de redes fue anunciada por IBM en 1974, justo diez años después de

anunciar la arquitectura S/360, y se denominó SNA (Systems Network Architecture). La arquitectura SNA se

basa en la definición de siete niveles o capas, cada una de las cuales ofrece una serie de servicios a la siguiente, la

cual se apoya en esta para implementar los suyos, y así sucesivamente. Cada capa puede implementarse en

hardware, software o una combinación de ambos. El módulo (hardware y/o software) que implementa una capa

en un determinado elemento de la red debe poder sustituirse sin afectar al resto de la misma, siempre y cuando el

protocolo utilizado se mantenga inalterado. Dicho en otras palabras, SNA es una arquitectura altamente modular

y estructurada. No vamos a entrar en mas detalles sobre la arquitectura SNA, ya que cae fuera de los objetivos

del presente curso, pero sí diremos que el modelo de capas que utiliza ha sido la base de todas las arquitecturas de

redes actualmente en uso, incluidas las basadas en el modelo OSI (Open Systems Interconnection) y el TCP/IP

(Transmission Control Protocol/Internet Protocol) que veremos en detalle más adelante.

Las ideas básicas del modelo de capas son las siguientes:

La capa n ofrece una serie de servicios a la capa n+1.

La capa n solo 've' los servicios que le ofrece la capa n-1.

La capa n en un determinado sistema solo se comunica con su homóloga en el sistema remoto (comunicación de

igual a igual o 'peer-to-peer'). Esa 'conversación' se efectúa de acuerdo con una serie de reglas conocidas como

protocolo de la capa n.

La comunicación entre dos capas adyacentes en un mismo sistema se realiza de acuerdo con una interfaz. La

interfaz es una forma concreta de implementar un servicio y no forma parte de la arquitectura de la red.

La arquitectura de una red queda perfectamente especificada cuando se describen las capas que la componen, su

funcionalidad, los servicios que implementan y los protocolos que utilizan para hablar con sus 'iguales'. El

conjunto de protocolos que utiliza una determinada arquitectura en todas sus capas se denomina pila de

protocolos ('protocol stack' en inglés); así es frecuente oír hablar de la pila de protocolos OSI, SNA, TCP/IP o

DECNET, por ejemplo.

Para mejor comprender como funciona el modelo de arquitectura de redes basado en capas hagamos una

analogía. Supongamos que un ejecutivo de la empresa A desea enviar de forma urgente un importante informe a

un colega suyo en la empresa B. Para esto hablará con aquél notificándole el envío y a continuación pasará a su

secretaria el informe con las instrucciones correspondientes. La secretaria llamará a la secretaria de B para

averiguar la dirección exacta, pondrá el informe en un sobre y llamará a un servicio de mensajería, que enviará a

un motorista para que recoja el paquete y lo lleve al aeropuerto. Cuando el paquete llega al aeropuerto de destino

es recogido allí por otro motorista que lo lleva a la oficina de la empresa B y lo entrega a la secretaria; ésta se

ocupará de los trámites administrativos (pagar al mensajero, abrir el paquete, comprobar su contenido, acusar

recibo a la secretaria de A, etc.) y lo pasará después a su jefe, el cual una vez estudio el informe llamará al

ejecutivo de A.

Obsérvese que en el proceso anterior existen diferentes niveles claramente diferenciados: los ejecutivos, las

secretarias, los motoristas, y por último la empresa de líneas aéreas que se ocupa del transporte físico de la

mercancía. En todos los niveles (menos probablemente el más bajo) hay dos entidades, la transmisora (A) y la

receptora (B). Si todo ocurre según lo previsto cada entidad sólo hablará con su correspondiente en el otro lado,

y con sus entidades vecinas, es decir, el jefe de A sólo habla con el jefe de B y con su secretaria, la secretaria

habla con su jefe, con el motorista y con la otra secretaria para confirmar el envío, etc. En ningún caso se

contempla que la secretaria de A hale con el ejecutivo de B. Si por ejemplo la secretaria de A es sustituida por

enfermedad por otra persona los procedimientos seguirán funcionando, siempre y cuando la secretaria suplente

desarrolle la misma función. Las variaciones de carácter interno sólo han de ser conocidas por las entidades

contiguas, por ejemplo, el motorista de B podría ser reemplazado por una furgoneta de reparto, y este hecho solo

ha de ser conocido por la secretaria de B y por la persona que entrega los paquetes en el aeropuerto. Esto es lo

que denominamos una interfaz. Obsérvese que el modelo de capas simplifica considerablemente la tarea de cada

una de las entidades, que sólo tiene que preocuparse de una pequeña parte de todo el mecanismo. En esencia se

trata de aplicar a la resolución de problemas la vieja fórmula de divide y vencerás.

Cuando un sistema desea enviar un mensaje a un sistema remoto normalmente la información se genera en el nivel

más alto; conforme va descendiendo se producen diversas transformaciones, por ejemplo adición de cabeceras, de

colas, de información de control, la fragmentación en paquetes mas pequeños si es muy grande (o mas raramente

la fusión con otros si es demasiado pequeño), etc. Todas estas operaciones se invierten en el sistema remoto en

las capas correspondientes, llegando en cada caso a la capa correspondiente en el destino un mensaje igual al

original.

1.4.1.- Decisiones en el diseño de arquitecturas de redes.

Cuando se diseña una arquitectura de red hay una serie de aspectos y decisiones fundamentales que condicionan

todo el proceso. Entre estos cabe mencionar los siguientes:

Direccionamiento: cada capa debe poder identificar los mensajes que envía y recibe. En ocasiones un mismo

ordenador puede tener varias instancias de una misma capa, por lo que la sola identificación del ordenador puede

no ser suficiente.

Normalmente cualquier protocolo admite comunicación en ambos sentidos (dúplex); pero no siempre se permite

que esta ocurra de forma simultánea (full-dúplex). también se debe determinar si se definirán prioridades, y cuáles

serán éstas.

En cualquier comunicación es preciso establecer un control de errores, ya que los canales de comunicación no son

totalmente fiables. Es preciso decidir que código de detección y/o corrección de errores se va a utilizar, y en que

capa o capas se va a llevar a cabo. Generalmente a medida que los medios de transmisión mejoran y las tasas de

errores disminuyen la detección/corrección se va suprimiendo de las capas inferiores y dejando al cuidado de las

más altas, ya que es un proceso costoso que puede llegar a ralentizar apreciablemente la transmisión.

En algunos casos se debe tener en cuenta la posibilidad de que los paquetes lleguen a su destino en orden

diferente al de envío.

Debe contemplarse la posibilidad de que el receptor no sea capaz de 'digerir' la información enviada por el

transmisor. Para esto es conveniente disponer de algún mecanismo de control de flujo y notificación para indicar

la congestión.

Normalmente los equipos funcionan de forma óptima cuando el tamaño de los mensajes que se envían esta dentro

de un cierto rango. Para evitar los problemas que puede producir el envío de mensajes muy grandes o muy

pequeños se suelen contemplar mecanismos de fragmentación y reagrupamiento. Es importante que estos

mecanismos estén claramente especificados para evitar la destrucción del mensaje en tránsito.

1.4.2.- Interfaces y servicios

Debido a su importancia vamos a estudiar con mas detalle que es un servicio. Empezaremos con algunas

definiciones.

Llamaremos entidad a los elementos activos en cada capa. Una entidad puede ser un proceso, un componente

hardware, o una combinación de ambos. Un ordenador puede tener una o varias entidades en cada capa (por

ejemplo un ordenador con dos tarjetas de conexión a LAN).

Llamaremos entidades iguales o entidades pares ('peer entities' en inglés) a dos entidades homólogas, es decir

entidades diferentes de la misma capa (generalmente estarán en diferentes máquinas, pero podrían estar en la

misma).

Las entidades de la capa n implementan los servicios que utiliza la capa n+1. En este caso la capa n actúa como el

proveedor del servicio y la capa n+1 es el usuario del servicio. El uso que la capa n haga de los servicios de la

capa n-1 es algo que no afecta ni incumbe a la capa n+1.

Los servicios están disponibles en los SAPs (Service Access Points). Los SAPs de la capa n son los puntos donde

la capa n+1 puede acceder a los seevicios ofertados. Cada SAP de cada entidad de la capa n tiene una dirección

que le identifica de forma única en toda la red.

Denominamos interfaz al conjunto de reglas que gobiernan el intercambio de información entre capas. En una

comunicación la entidad de la capa n+1 intercambia una IDU (Interface Data Unit) con la entidad de la capa n a

través del SAP (ver fig. 1-12 del Tanenbaum). La IDU esta formada por una SDU (Service Data Unit) e

información de control. La SDU es la información que se transmite a la entidad equivalente (peer) en el lado

contrario, y de allí a la capa n+1 a través de su SAP. La información de control es necesaria como su nombre

indica para que la capa n haga correctamente su trabajo, pero no es parte de los datos mismos. En la

especificación de una arquitectura solo es necesario describir la estructura de la SDU, pero no la de la IDU; ésta

se describe en la interfaz, que puede ser distinta para cada implementación.

Para transferir la SDU (Service Data Unit) la entidad de la capa n puede tener que fragmentarla en varias PDUs

(Protocol Data Units). Cada PDU llevará una cabecera que permitirá a la entidad de la capa n en el otro lado

ensamblar de nuevo la SDU correctamente.

1.4.3.- Servicios orientados y no orientados a conexión

En una arquitectura de redes cada capa utiliza los servicios de la capa inmediatamente inferior para comunicar

con la correspondiente del otro extremo. En función de como se establezca esa comunicación suelen distinguirse

dos tipos de servicios: orientados a conexión y no orientados a conexión.

En el servicio orientado a conexión, también llamado CONS (Connection Oriented Network Service), primero se

establece el canal de comunicación, después se transmiten los datos, y por último se termina la conexión. Dicha

'conexión' se denomina circuito virtual (VC, virtual circuit). Una vez establecido el VC el camino físico que van a

seguir los datos está determinado; los paquetes deben ir todos por él desde el origen al destino, y llegar en el

mismo orden con el que han salido. Dado que el VC establece de forma clara el destino, los paquetes no necesitan

contener su dirección. Generalmente se distinguen dos tipos de circuitos virtuales: conmutados, también llamados

SVCs (Switched Virtual Circuits), y permanentes, conocidos también como PVCs (Permanent Virtual Circuits).

Los SVCs se establecen y terminan a petición del usuario, normalmente cuando hay paquetes que se quieren

transmitir. Los PVCs están establecidos todo el tiempo que la red está operativa (o al menos eso es lo que se

pretende). Al hablar de circuitos utilizaremos las denominaciones 'establecer' y 'terminar' en vez de abrir y cerrar,

ya que estos términos tienen un significado completamente opuesto según se trate de ingenieros informáticos o

electrónicos (para un ingeniero electrónico un circuito esta abierto cuando esta interrumpido, es decir cuando no

puede viajar por el ninguna señal).

En el servicio no orientado a conexión, llamado también CLNS (ConnectionLess Network Service) la

comunicación se establece de manera menos formal. Cuando una entidad tiene información que transmitir

sencillamente la envía en forma de paquetes, confiando que estos llegaran a su destino mas pronto o mas tarde.

No se establece previamente un VC ni otro tipo de canal de comunicación extremo a extremo; los paquetes

pueden ir por caminos físicos diversos, y deben incluir cada uno la dirección de destino. Los paquetes pueden ser

almacenados por nodos intermedios de la red, y reenviados mas tarde. Aunque lo normal es que lleguen en el

mismo orden con que han salido, esto no esta garantizado como ocurría en el servicio orientado a conexión

debido al almacenamiento en nodos intermedios y a la diversidad de caminos físicos posibles. A los paquetes

enviados en un servicio no orientado a conexión se les denomina datagramas, ya que cada paquete viaja hacia su

destino de forma completamente independiente de los demás como si fuera un telegrama..

Generalmente se suelen explicar los modelos orientado y no orientado a conexión con dos analogías: el sistema

telefónico y el sistema postal. El sistema telefónico es un ejemplo de servicio orientado a conexión, mientras que

el sistema postal es un servicio no orientado a conexión. La analogía es bastante exacta salvo por el hecho de que

en redes telemáticas la diferencia en el tiempo de entrega del mensaje entre servicios CONS y CLNS no es tan

grande como la anterior comparación podría hacer pensar.

En cualquiera de los dos tipos de servicio antes mencionados es posible que se produzca pérdida de información;

también puede ocurrir que el tiempo de envío del paquete, también llamado retardo o latencia ('delay' y 'latency'

respectivamente en inglés) sea demasiado grande o fluctúe dentro de un amplio rango debido a la carga o

congestión en la red (el término inglés usado para denominar dicha fluctuación es jitter, que literalmente significa

mieditis, temblar de miedo). En algunos casos se requiere una entrega fiable, es decir que se garantice la entrega

de los paquetes, o un retardo y/o jitter garantizados, o sea no superiores a un determinado valor. Por ejemplo si

transferimos un fichero, normalmente dividiéndolo en múltiples paquetes, necesitaremos un servicio fiable en la

entrega, pero podemos tolerar un retardo o jitter mas o menos grande; por el contrario la voz, o el vídeo (imagen

en movimiento) toleran un pequeño porcentaje de pérdidas, pero requieren un retardo y un jitter reducidos y

constantes. Cuando al establecer una comunicación se solicita un nivel mínimo para alguno de éstos parámetros

se dice que se requiere una calidad de servicio (llamada QoS, Quality of Service). La calidad de servicio estipula

unos mínimos que la red ha de satisfacer para efectuar la conexión, por ejemplo 'transmisión fiable con un retardo

no superior a 100 ms'; es posible que la red no sea capaz de satisfacer la calidad solicitada, en cuyo caso podría

hacer una propuesta alternativa, a modo de regateo (por ejemplo, 'no puedo asegurar 100 ms de retardo, lo

mínimo es 250ms, ¿estás conforme?') Una vez pactadas las condiciones de la conexión éstas actúan a modo de

contrato que obliga a la red a dar la calidad de servicio prometida al usuario. No todos los protocolos o redes

ofrecen la posibilidad de negociar calidades de servicio; en estos casos el protocolo simplemente aprovecha los

medios disponibles lo mejor que puede, intentando evitar las congestiones y situaciones críticas en lo posible, y

repartir los recursos entre los usuarios de manera mas o menos equilibrada; esta estrategia se denomina del 'mejor

esfuerzo' (o también 'best effort'). Como ejemplos de redes con QoS podemos citar ATM, como ejemplos de

redes 'best effort' podemos mencionar TCP/IP (la Internet) y Ethernet.

1.4.4.- Primitivas de servicio

Recordemos que, en el modelo de capas, cada capa ofrece sus servicios a la siguiente. El servicio se define por un

conjunto de operaciones u órdenes que la capa superior puede mandar a la capa inferior. Dicho conjunto de

operaciones se denomina primitivas.

Vamos a analizar en detalle las primitivas que participan en el establecimiento y terminación de una conexión

entre la capa n de dos sistemas llamados A y B. La entidad A.n (es decir, la capa n del sistema A) inicia la

conexión emitiendo la primitiva CONNECT.request, que provoca la transferencia de una IDU (Interface Data

Unit) a través del SAP (Service Access Point) a la entidad A.n-1; ésta extrae la información de control y la

interpreta creando la SDU (Service data Unit), que convierte en una o varias PDUs (Protocol Data Units); las

PDUs son transferidas a B.n-1, que regenera a partir de ello la SDU, luego la información de control

correspondiente y con ambos la IDU; una vez dispone de la IDU la transmite a B.n a través del SAP mediante la

primitiva CONNECT.indication, que le indica a B.n que alguna entidad desea establecer conexión con ella. La

entidad B.n emite entonces la primitiva CONNECT.response para indicar si acepta o rechaza la conexión (las

primitivas pueden llevar parámetros y sería aquí donde se indicaría esto). La respuesta se traduce en un paquete

que B.n-1 envía a A.n-1, el cual informa a A.n de la situación mediante la primitiva CONNECT.confirm.

Obsérvese que el mismo evento origina diferentes primitivas en cada lado. Una CONNECT.request produce una

CONNECT.indication en el lado contrario, y la CONNECT.response se convierte en CONNECT.confirm. Existe

una cierta simetría entre las primitivas, ya que a una CONNECT.request siempre le corresponderá una

CONNECT.indication en el lado opuesto (salvo que falle la comunicación).

En este ejemplo hemos hecho un servicio confirmado, es decir, hemos verificado que la conexión se establecía,

para lo cual ha tenido que enviarse un paquete en cada sentido. Se podría haber hecho una conexión no

confirmada, para lo cual sencillamente se habría emitido la CONNECT.request y la CONNECT.indication.

Una vez establecida la conexión lo normal sería transferir datos, y finalmente terminar la conexión. Un ejemplo

del conjunto de primitivas que se emitirían a lo largo de una conexión podría ser el siguiente:

En A En B

CONNECT.request

CONNECT.indication

CONNECT.response

CONNECT.confirm

DATA.request

DATA.indication

DATA.request

DATA.indication

DISCONNECT.request

DISCONNECT.indication

Aquí hemos introducido cuatro nuevas primitivas para poder transferir datos y terminar la conexión. Obsérvese

que como antes una primitiva request va seguida siempre de una indication en el lado contrario. En este ejemplo

hemos supuesto que se intercambiaban únicamente dos paquetes de datos.

Como ya hemos dicho las primitivas pueden llevar parámetros, y de hecho casi siempre los llevan. Por ejemplo

una CONNECT.request llevará la máquina con la que se desea conectar, una CONNECT.indication dirá la

máquina que quiere conectar con nosotros, etc. La descripción detallada de estos argumentos, su significado, etc.,

no es parte de la especificación de las primitivas (y por tanto del servicio) sino del protocolo. El protocolo puede

modificarse sin necesidad de cambiar las primitivas. Por ejemplo, un protocolo puede establecer que el servicio de

establecimiento de conexión sea confirmado y otro que no lo sea, y ambos pueden utilizar el mismo conjunto de

primitivas antes descrito.

Una vez mas diremos que la interfaz no forma parte del protocolo. Por ejemplo imaginemos en el caso anterior

que las entidades A.n y A.n-1 acuerdan que la SDU estará codificada en EBCDIC, mientras que B.n y B.n-1

acuerdan utilizar ASCII. Si el protocolo de la capa n-1 establece que la PDU estará en ASCII, entonces A.n-1

sabe que deberá realizar la conversión de códigos cada vez que construya una PDU a partir de una SDU, o

viceversa.

1.5.- MODELOS DE REFERENCIA

Hasta aquí hemos hablado del modelo de capas en un sentido genérico. Vamos a hablar ahora con cierto detalle

de las dos arquitecturas de redes mas importantes en la actualidad, correspondientes a los protocolos OSI (Open

Systems Interconnection) y TCP/IP (Transmission Control Protocol/Internet Protocol). Conviene destacar que la

arquitectura es una entidad abstracta, mas general que los protocolos o las implementaciones concretas en que

luego se materializan éstos. Típicamente para cada capa de una arquitectura existirán uno o varios protocolos, y

para cada protocolo habrá múltiples implementaciones. Las implementaciones cambian continuamente; los

protocolos ocasionalmente se modifican o aparecen otros nuevos que coexisten con los anteriores o los dejan

anticuados; sin embargo una vez definida una arquitectura ésta permanece esencialmente intacta y muy raramente

se modifica.

1.5.1.- El modelo de referencia OSI

Después de la especificación de SNA por parte de IBM cada fabricante importante definió su propia arquitectura

de redes; así la evolución de los productos de comunicaciones estaba garantizada, pero no se había resuelto el

problema de la interoperabilidad entre diferentes fabricantes. Debido a la posición de hegemonía que IBM

disfrutaba en los años 70 y principios de los ochenta la compatibilidad con IBM era un requisito necesario, por lo

que la mayoría de los fabricantes tenían implementaciones de los protocolos SNA para sus productos, o estas

estaban disponibles a través de terceros. Así, la forma mas sencilla de interconectar dos equipos cualesquiera era

conseguir que ambos hablaran SNA.

En 1977 la ISO (International Organization for Standardization) consideró que esta situación no era la mas

conveniente, por lo que entre 1977 y 1983 definió la arquitectura de redes OSI con el fin de promover la creación

de una serie de estándares que especificaran un conjunto de protocolos independientes de cualquier fabricante. Se

pretendía con ello no favorecer a ninguno a la hora de desarrollar implementaciones de los protocolos

correspondientes, cosa que inevitablemente habría ocurrido si se hubiera adoptado alguna de las arquitecturas

existentes, como la SNA de IBM o la DNA (Digital Network Architecture) de Digital. Se esperaba llegar a

convertir los protocolos OSI en el auténtico Esperanto de las redes telemáticas. Por diversas razones que

veremos luego el éxito de los protocolos OSI en la práctica ha sido mucho menor de lo inicialmente previsto

(cosa que por cierto también le ha ocurrido al Esperanto, aparentemente).

Seguramente la aportación más importante de la iniciativa OSI ha sido precisamente su arquitectura. Ésta ha

servido como marco de referencia para describir multitud de redes correspondientes a diversas arquitecturas, ya

que la arquitectura OSI es bien conocida en entornos de redes, y su generalidad y no dependencia de ningún

fabricante en particular le hacen especialmente adecuada para estos fines. Por este motivo generalmente a la

arquitectura OSI se la denomina Modelo de Referencia OSI, o también OSIRM (OSI Reference Model). Por

extensión hoy en día se utiliza a menudo el término modelo de referencia para referirse a una arquitectura de red;

así oímos hablar del Modelo de Referencia TCP/IP, el Modelo de Referencia ATM, etc.

El modelo OSI define siete capas, curiosamente como en la arquitectura SNA si bien la funcionalidad es diferente.

Las capas son las siguientes:

1? Física

2? Enlace

3? Red

4? Transporte

5? Sesión

6? Presentación

7? Aplicación

La ISO ha especificado protocolos para todas las capas, aunque algunos son poco utilizados. En función del tipo

de necesidades del usuario no siempre se utilizan todas ellas.

Pasaremos a describir brevemente las funciones desarrolladas por cada una de las capas.

1.5.1.1-La Capa Física

Esta capa transmite los bits entre dos entidades (nodos) directamente conectadas. Puede tratarse de un enlace

punto a punto o de una conexión multipunto (una red broadcast, por ejemplo Ethernet). La comunicación puede

ser dúplex, semi-dúplex o simplex. Si la información se transmite por señales eléctricas se especifican los voltajes

permitidos y su significado (1 ó 0) y análogamente para el caso de fibra óptica. Se especifican las características

mecánicas del conector, la señalización básica, etc.

Como ejemplos de la capa física podemos mencionar las norma EIA RS-232-C, utilizada por las puertas COM de

los ordenadores personales, la EIA-RS-449, CCITT X.21/X.21bis, CCITT V.35. Las normas de redes locales

incluyen en sus especificaciones la capa física (IEEE 802.3 o Ethernet, IEEE 802.5 o Token Ring, ISO 9314 o

FDDI, etc.)

Muchas de las normas que existen en la capa física se refieren a la interfaz utilizada para conectar un ordenador

con un módem o dispositivo equivalente, que a través de una línea telefónica conecta con otro módem y

ordenador en el extremo opuesto. Este es el caso por ejemplo de las normas EIA RS-232-C, EIA-RS-449,

CCITT X.21/X.21bis y CCITT V.35 antes mencionadas. En estos el conector del ordenador y el módem son de

diferente 'sexo' (macho o hembra). En este contexto se suele utilizar la denominación DTE (Data Terminal

Equipment) para referirse al ordenador y DCE (Data Circuit-Terminating Equipment) para referirse al módem. El

'módem' en ocasiones no es más que un adaptador, ya que por ejemplo la norma X.21 se utiliza para líneas

digitales. En sentido general al equipo que actúa como adaptador entre el ordenador y el medio de transmisión se

le denomina CSU/DSU (Channel Service Unit/ Data Service Unit).

1.5.1.2.- La capa de enlace (data link)

La principal función de la capa de enlace es ofrecer un servicio de comunicación fiable a partir de los servicios

que recibe de la capa física, también entre dos entidades contiguas de la red. Esto supone que se realice detección

y posiblemente corrección de errores. A diferencia de la capa física, que transmitía los bits de manera continua, la

capa de enlace transmite los bits en grupos denominados tramas (frames en inglés) cuyo tamaño es típicamente de

unos pocos cientos a unos pocos miles de bytes. Si el paquete recibido de la capa superior es mayor que el

tamaño máximo de trama la capa física debe encargarse de fragmentarlo, enviarlo y recomponerlo en el lado

opuesto. En caso de que una trama no haya sido transmitida correctamente se deberá enviar de nuevo; también

debe haber mecanismos para reconocer cuando una trama se recibe duplicada. Generalmente se utiliza algún

mecanismo de control de flujo, para evitar que un transmisor rápido pueda 'abrumar' a un receptor lento.

Las redes broadcast utilizan funciones especiales de la capa de enlace para controlar el acceso al medio de

transmisión, ya que éste es compartido por todos los nodos de la red. Esto añade una complejidad a la capa de

enlace que no está presente en las redes basadas en líneas punto a punto, razón por la cual en las redes broadcast

la capa de enlace se subdivide en dos subcapas: la inferior, denominada subcapa MAC (Media Access Control) se

ocupa de resolver el problema de acceso al medio, y la superior, subcapa LLC (Logical Link Control) cumple una

función equivalente a la capa de enlace en las líneas punto a punto.

Ejemplos de protocolos de la capa de enlace incluyen ISO 7776, la capa de enlace de CCITT X.25, RDSI,

LAP-D, ISO HDLC. Como ejemplos de protocolos de la subcapa MAC podemos citar los de IEEE 802.3

(Ethernet), IEEE 802.5 (Token Ring), ISO 9314 (FDDI). El protocolo de subcapa LLC de todas las redes

broadcast es el IEEE 802.2.

1.5.1.3.- La capa de red

La capa de red se ocupa del control de la subred. Esta es la capa que tiene 'conciencia' de la topología de la red, y

se ocupa de decidir por que ruta va a ser enviada la información; la decisión de la ruta a seguir puede hacerse de

forma estática, o de forma dinámica en base a información obtenida de otros nodos sobre el estado de la red.

De forma análoga a la capa de enlace la capa de red maneja los bits en grupos discretos que aquí reciben el

nombre de paquetes; motivo por el cual a veces se la llama la capa de paquete. Los paquetes tienen tamaños

variables, pudiendo llegar a ser muy elevados, sobre todo en protocolos recientes, para poder aprovechar

eficientemente la elevada velocidad de los nuevos medios de transmisión (fibra óptica, ATM, etc.). Por ejemplo

en TCP/IP el tamaño máximo de paquete es de 64 KBytes, pero en el nuevo estándar, llamado IPv6, el tamaño

máximo puede llegar a ser de 4 GBytes (4.294.967.296 Bytes).

Entre las funciones de la capa de red cabe destacar, aparte de la ya mencionada de elegir la ruta a seguir, el

control del tráfico para evitar situaciones de congestión o 'atascos'. En el caso de ofrecer servicios con QoS el

nivel de red debe ocuparse de reservar los recursos necesarios para poder ofrecer el servicio prometido con

garantías. También debe ser capaz de efectuar labores de contabilidad del tráfico en caso necesario (por ejemplo

si el servicio se factura en base a la cantidad de datos transmitidos).

En la capa de red es donde con mas intensidad se observa la distinción entre servicios orientados y no orientados

a conexión (CONS vs CLNS). En el curso veremos en detalle las redes ATM, que en el nivel de red dan un

servicio de tipo CONS, y las redes TCP/IP, que en el nivel de red dan un servicio de tipo CLNS.

La capa de red es la mas importante en redes de conmutación de paquetes (tales como X.25 o TCP/IP). Algunos

ejemplos de protocolos utilizados en la capa de red son los protocolos de nivel de paquete y nivel de pasarela

CCITT X.25 y X.75, el IP (Internet Protocol), CCITT/ITU-T Q.931, Q.933, Q.2931, y el OSI CLNP

(ConnectionLess Network Protocol).

En las redes de tipo broadcast el nivel de red es casi inexistente, ya que desde un punto de vista topológico

podemos considerar que en una red broadcast los nodos estan interconectados todos con todos, por lo que no se

toman decisiones de encaminamiento. Sin embargo veremos que la unión de redes broadcast mediante puentes

suscita en algunos casos la necesidad de efectuar tareas propias del nivel de red en el nivel de enlace.

1.5.1.4.- La capa de transporte

La capa de transporte es la primera que se ocupa de comunicar directamente nodos terminales, utilizando la

subred como un medio e transporte transparente gracias a los servicios obtenidos de la capa de red. Por esta

razón se la ha llamado históricamente la capa host-host. También se suele decir que es la primera capa extremo a

extremo.

La principal función de la capa de transporte es fragmentar de forma adecuada los datos recibidos de la capa

superior (sesión) para transferirlos a la capa de red, y asegurar que los fragmentos llegan y son recompuestos

correctamente en su destino.

En condiciones normales la capa de transporte solicita a la capa de red una conexión diferente por cada solicitud

recibida de la capa de sesión, pero puede haber razones de costo que aconsejen multiplexar diferentes conexiones

en la capa de sesión sobre una sola conexión en la capa de red o, inversamente, razones de rendimiento pueden

requerir que una conexión solicitada por la capa de sesión sea atendida por varias conexiones en la capa de red;

en ambos casos la capa de transporte se ocupará de hacer la multiplexación mas adecuada de forma transparente a

la capa de sesión.

La capa de transporte establece el tipo de servicio que recibe la capa de sesión, y en último extremo los usuarios.

Éste podría ser por ejemplo un servicio libre de errores que entrega los mensajes en el mismo orden en que se

envían; también podría ser un servicio de datagramas, es decir, mensajes independientes sin garantía en cuanto al

orden de entrega ni confirmación de la misma, o un servicio broadcast o multicast en que los paquetes se

distribuyen a múltiples destinos simultáneamente.

El control de flujo, que ha aparecido en capas anteriores, es necesario también en la capa de transporte para

asegurar que un host rápido no satura a uno lento. La capa de transporte realiza también su propio control de

errores, que resulta ahora esencial pues algunos protocolos modernos como Frame Relay o ATM han reducido o

suprimido totalmente el control de errores de las capas inferiores, ya que con las mejoras en la tecnología de

transmisión de datos éstos son menos frecuentes y se considera mas adecuado realizar esta tarea en el nivel de

transporte.

Salvo el caso de transmisiones multicast o broadcast el nivel de transporte se ocupa siempre de una comunicación

entre dos entidades, lo cual le asemeja en cierto sentido al nivel de enlace. Por esto existen grandes similitudes

entre ambas capas en cuestiones tales como el control de errores o control de flujo.

Ejemplos de protocolos de transporte incluyen el CCITT X.224, también llamado protocolo de transporte OSI

TP4 (Transport Protocol 4). En Internet existen dos protocolos de transporte: TCP y UDP.

1.5.1.5.- La capa de sesión

La capa de sesión es la primera que es accesible al usuario, y es su interfaz más básica con la red. Por ejemplo,

mediante los servicios de la capa de sesión un usuario podría establecer una conexión como terminal remoto de

otro ordenador. En un sistema multiusuario la capa de sesión se ocupa de ofrecer un SAP a cada usuario para

acceder al nivel de transporte.

1.5.1.6.- La capa de presentación

Hasta aquí nos hemos preocupado únicamente de intercambiar bits (o bytes) entre dos usuarios ubicados en dos

ordenadores diferentes. Lo hemos hecho de manera fiable y entregando los datos a la sesión, es decir al usuario,

pero sin tomar en cuenta el significado de los bits transportados. La capa de presentación se ocupa de realizar las

conversiones necesarias para asegurar que dichos bits se presentan al usuario de la forma esperada. Por ejemplo,

si se envía información alfanumérica de un ordenador ASCII a uno EBCDIC será preciso efectuar una

conversión, o de lo contrario los datos no serán interpretados correctamente. Lo mismo podríamos decir de la

transferencia de datos enteros, flotantes, etc. cuando la representación de los datos difiere en los ordenadores

utilizados.

1.5.1.7.- La capa de aplicación

La capa de aplicación comprende los servicios que el usuario final está acostumbrado a utilizar en una red

telemática, por lo que a menudo los protocolos de la capa de aplicación se denominan servicios. Dado que se

crean continuamente nuevos servicios, existen muchos protocolos para la capa de aplicación, uno o mas por cada

tipo de servicio.

Ejemplos de protocolos estándar de la capa de aplicación son el CCITT X.400, X.420, X.500, FTAM. SMTP,

FTP, HTTP, etc.

1.5.2.- Transmisión de datos en el modelo OSI

La transmisión de datos en el modelo OSI se realiza de forma análoga a lo ya descrito para el modelo de capas.

La capa de aplicación recibe los datos del usuario y les añade una cabecera (que denominamos cabecera de

aplicación), constituyendo así la PDU (Protocol Data Unit) de la capa de aplicación. La cabecera contiene

información de control propia del protocolo en cuestión. La PDU es transferida a la capa de aplicación en el nodo

de destino, la cual recibe la PDU y elimina la cabecera entregando los datos al usuario. En realidad la PDU no es

entregada directamente a la capa de aplicación en el nodo de destino, sino que es transferida a la capa de

presentación en el nodo local a través de la interfaz; esto es una cuestión secundaria para la capa de aplicación,

que ve a la capa de presentación como el instrumento que le permite hablar con su homóloga en el otro lado.

A su vez la capa de presentación recibe la PDU de la capa de aplicación y le añade una cabecera propia, (cabecera

de presentación) creando la PDU de la capa de presentación Esta PDU es transferida a la capa de presentación

en el nodo remoto usando a la capa de sesión como instrumento para la comunicación, de manera análoga a lo ya

descrito para la capa de aplicación.

En el caso mas general cada capa añade una cabecera propia a los datos recibidos de la capa superior, y construye

así su PDU. La capa homóloga del nodo de destino se ocupará de extraer dicha cabecera, interpretarla, y entregar

la PDU correspondiente a la capa superior. En algunos casos la cabecera puede no existir. En el caso particular de

la capa de enlace además de la cabecera añade una cola al construir la PDU (trama) que entrega a la capa física.

Volviendo por un momento a nuestra analogía de los dos ejecutivos que intercambian un documento, vemos que

a medida que vamos descendiendo capas en el envío (jefe, secretaria, motorista, líneas aéreas) el documento va

recibiendo nuevos envoltorios que contienen a los anteriores. A la llegada el paquete es procesado de forma

simétrica, es decir se le va quitando en cada capa el envoltorio correspondiente antes de pasarlo a la siguiente.

1.5.3.- El modelo de referencia TCP/IP

En 1969 la agencia ARPA (Advanced Research Projects Agency) del Departamento de Defensa (DoD,

Department of Defense) de los Estados Unidos inició un proyecto de interconexión de ordenadores mediante

redes telefónicas. Al ser un proyecto desarrollado por militares en plena guerra fría un principio básico de diseño

era que la red debía poder resistir la destrucción de parte de su infraestructura (por ejemplo a causa de un ataque

nuclear), de forma que dos nodos cualesquiera pudieran seguir comunicados siempre que hubiera alguna ruta que

los uniera. Esto se consiguió en 1972 creando una red de conmutación de paquetes denominada ARPAnet, la

primera de este tipo que operó en el mundo. La conmutación de paquetes unida al uso de topologías malladas

mediante múltiples líneas punto a punto dio como resultado una red altamente fiable y robusta.

La ARPAnet fue creciendo paulatinamente, y pronto se hicieron experimentos utilizando otros medios de

transmisión de datos, en particular enlaces por radio y vía satélite; los protocolos existentes tuvieron problemas

para interoperar con estas redes, por lo que se diseñó un nuevo conjunto o pila de protocolos, y con ellos una

arquitectura. Este nuevo conjunto se denominó TCP/IP (Transmission Control Protocol/Internet Protocol)

nombre que provenía de los dos protocolos mas importantes que componían la pila; la nueva arquitectura se

llamó sencillamente modelo TCP/IP, los nuevos protocolos fueron especificados por vez primera por Cerf y Kahn

en un artículo publicado en 1974. A la nueva red, que se creó como consecuencia de la fusión de ARPAnet con

las redes basadas en otras tecnologías de transmisión, se la denominó Internet.

La aproximación adoptada por los diseñadores del TCP/IP fue mucho más pragmática que la de los autores del

modelo OSI. Mientras que en el caso de OSI se emplearon varios años en definir con sumo cuidado una

arquitectura de capas donde la función y servicios de cada una estaban perfectamente definidas, y solo después se

planteó desarrollar los protocolos para cada una de ellas, en el caso de TCP/IP la oppración fue a la inversa;

primero se especificaron los protocolos, y luego se definió el modelo como una simple descripción de los

protocolos ya existentes. Por este motivo el modelo TCP/IP es mucho más simple que el OSI. También por este

motivo el modelo OSI se utiliza a menudo para describir otras arquitecturas, como por ejemplo la TCP/IP,

mientras que el modelo TCP/IP nunca suele emplearse para describir otras arquitecturas que no sean la suya

propia.

En el modelo TCP/IP se pueden distinguir cuatro capas:

1? La capa host-red

2? La capa internet

3? La capa de transporte

4? La capa de aplicación

Pasemos a describirlas brevemente.

1.5.3.1.- La capa host-red

Esta capa engloba realmente las funciones de la capa física y la capa de enlace del modelo OSI. El modelo

TCP/IP no dice gran cosa respecto a ella, salvo que debe ser capaz de conectar el host a la red por medio de

algún protocolo que permita enviar paquetes IP. Podríamos decir que para el modelo TCP/IP esta capa se

comporta como una 'caja negra'. Cuando surge una nueva tecnología de red (por ejemplo ATM) una de las

primeras cosas que aparece es un estándar que especifica de que forma se pueden enviar sobre ella paquetes IP; a

partir de ahí la capa internet ya puede utilizar esa tecnología de manera transparente.

1.5.3.2.- La capa internet

Esta capa es el 'corazón' de la red. Su papel equivale al desempeñado por la capa de red en el modelo OSI, es

decir, se ocupa de encaminar los paquetes de la forma mas conveniente para que lleguen a su destino, y de evitar

que se produzcan situaciones de congestión en los nodos intermedios. Debido a los requisitos de robustez

impuestos en el diseño, la capa internet da únicamente un servicio de conmutación de paquetes no orientado a

conexión. Los paquetes pueden llegar desordenados a su destino, en cuyo caso es responsabilidad de las capas

superiores en el nodo receptor la reordenación para que sean presentados al usuario de forma adecuada.

A diferencia de lo que ocurre en el modelo OSI, donde los protocolos para nada intervienen en la descripción del

modelo, la capa internet define aquí un formato de paquete y un protocolo, llamado IP (Internet Protocol), que se

considera el protocolo 'oficial' de la arquitectura.

1.5.3.3.- La capa de transporte

Esta capa recibe el mismo nombre y desarrolla la misma función que la cuarta capa del modelo OSI, consistente

en permitir la comunicación extremo a extremo (host a host) en la red. Aquí se definen dos protocolos: el TCP

(Transmission Control Protocol) ofrece un servicio CONS fiable, con lo que los paquetes (aquí llamados

mensajes) llegan ordenados y sin errores. TCP se ocupa también del control de flujo extremo a extremo, para

evitar que por ejemplo un host rápido sature a un receptor mas lento. Ejemplos de protocolos de aplicación que

utilizan TCP son el SMTP (Simple Mail Transfer Program, correo electrónico) y el FTP (File Transfer Program).

El otro protocolo de transporte es UDP (User Datagram Protocol) que da un servicio CLNS, no fiable. UDP no

realiza control de errores ni de flujo. Una aplicación típica donde se utiliza UDP es la transmisión de voz y vídeo

en tiempo real; aquí el retardo que introduciría el control de errores produciría mas daño que beneficio: es

preferible perder algún paquete que retransmitirlo fuera de tiempo. Otro ejemplo de aplicación que utiliza UDP es

el NFS (Network File System); aquí el control de errores y de flujo se realiza en la capa de aplicación.

1.5.3.4.- La capa de aplicación

Esta capa desarrolla las funciones de las capas de sesión, presentación y aplicación del modelo OSI. La

experiencia ha demostrado que las capas de sesión y presentación son de poca utilidad, debido a su escaso

contenido, por lo que la aproximación adoptada por el modelo TCP/IP parece mas acertada.

La capa de aplicación contiene todos los protocolos de alto nivel que se utilizan para ofrecer servicios a los

usuarios. Entre estos podemos mencionar tanto los 'tradicionales', que existen desde que se creó el TCP/IP:

terminal virtual (TelNet), transferencia de ficheros (FTP), correo electrónico (SMTP) y servidor de nombres

(DNS), como los mas recientes, como el servicio de news (NNTP), el Web (HTTP), el Gopher, etc.

1.5.4.- Comparación de los modelos OSI y TCP/IP

Como ya hemos comentado, la génesis del modelo OSI y TCP/IP fue muy diferente. En el caso de OSI primero

fue el modelo y después los protocolos, mientras que en TCP/IP el orden fue inverso. Como consecuencia de esto

el modelo OSI es mas elegante y esta menos condicionado por ningún protocolo en particular, y se utiliza

profusamente como modelo de referencia para explicar todo tipo de redes. El modelo OSI hace una distinción

muy clara entre servicios, interfaces y protocolos, conceptos que a menudo se confunden en el modelo TCP/IP.

Podríamos decir que la arquitectura (o el modelo) OSI es mas modular y académico que el TCP/IP.

Pero este mayor nivel de abstracción también tiene sus inconvenientes. Los diseñadores del modelo OSI no tenían

experiencia práctica aplicando su modelo para desarrollar protocolos y olvidaron algunas funcionalidades

importantes. Por ejemplo, las redes broadcast no fueron previstas inicialmente en la capa de enlace, por lo que se

tuvo que insertar a la fuerza la subcapa MAC para incluirlas. Otro problema era que no se había previsto la

interconexión de redes diferentes, cosa que fue como ya hemos visto el alma mater del modelo TCP/IP.

El modelo OSI tiene siete capas, mientras que el modelo TCP/IP sólo tiene cuatro. Aunque es desafortunada la

fusión de la capa física y la de enlace en una oscura capa host-red, la fusión de las capas de sesión, presentación y

aplicación en una sola en el modelo TCP/IP es claramente mas lógica que la del modelo OSI.

Otra diferencia fundamental estriba en los servicios orientados a conexión (CONS) o no orientados a conexión

(CLNS). El modelo OSI soporta ambos modos en la capa de red, pero sólo el modo CONS en la capa de

transporte, que es la que percibe el usuario. El modelo TCP/IP en cambio soporta solo CLNS en la capa de red,

pero ambos en la de transporte. Quizá un sutil detalle pueda explicar esta diferencia: el servicio CONS a nivel de

red hace mucho mas sencillo facturar por tiempo de conexión, cosa a la que están muy acostumbradas las

compañías telefónicas, que son las que han participado activamente en los comités técnicos de ISO que diseñaron

el modelo OSI.

En la práctica los protocolos basados en las normas estándar OSI definidas por la ISO nunca llegaron a tener gran

relevancia a nivel mundial, a pesar de que la mayoría de los grandes fabricantes de ordenadores y compañías

telefónicas impulsaron su utilización ofreciendo productos y servicios basados en ellos. Las razones principales

que motivaron este fenómeno las podemos resumir en los siguientes puntos:

Momento inadecuado: Para cuando estaban disponibles productos comerciales basados en protocolos OSI

(finales de los ochenta) ya estaban ampliamente difundidos los productos basados en los protocolos TCP/IP; esto

era especialmente cierto en entornos académicos (universidades y centros de investigación), que aunque

económicamente no eran los mejor dotados sí tenían las mayores redes a nivel mundial.

Tecnología inapropiada: como ya hemos comentado la elección del modelo de siete capas para el protocolo OSI

era algo forzada. Una de las razones que llevaron a elegir este número de capas era que coincidía con el del

modelo SNA de IBM, que dominaba el mercado de la informática por aquel entonces; los autores del modelo OSI

creían que aproximándose a SNA tenían mayores posibilidades de éxito. La complejidad de la arquitectura OSI

(análogamente a la SNA) es considerable, y en muchos aspectos difícil de traducir en programas.

Implementaciones inadecuadas: en parte como consecuencia de su complejidad, los productos comerciales que

aparecían basados en los protocolos OSI eran muy caros y poco fiables. Esto creó un círculo vicioso, ya que al

ser caros los usuarios no los compraban, y al no usarse en condiciones reales los nuevos productos no se

depuraban; además, las empresas fabricantes tenían que mantener un alto precio del software OSI para compensar

los elevados costos de desarrollo y mantenimiento. Como contraste una de las primeras implementaciones de

TCP/IP formaba parte del UNIX de Berkeley, era muy buena y además se distribuía gratuitamente. No es extraño

pues que rápidamente se asociara OSI con baja calidad, complejidad y costos elevados.

Mala política: el desarrollo de OSI era patrocinado principalmente por la ISO, las PTTs europeas, la Comunidad

Europea y los gobiernos de sus países miembros; las decisiones eran fruto de multitud de reuniones de los

diversos comités y grupos de trabajo, y en ocasiones se tomaban en consideración no sólo aspectos técnicos sino

también políticos, buscando el compromiso entre sus miembros. Por el contrario el desarrollo de TCP/IP seguía

un curso mucho más improvisado e informal, cualquier persona podía (y puede) proponer un nuevo protocolo

para su estandarización independientemente de su nacionalidad, prestigio o situación laboral. Haciendo una

simplificación podríamos decir que OSI funcionaba como una 'democracia parlamentaria' (similar a un gobierno

moderno), mientras que TCP/IP era más similar a una ONG, o a un movimiento alternativo; esto se reflejaba

incluso en la indumentaria utilizada por uno y otro colectivo. No es de extrañar que en entornos académicos (de

nuevo recordemos los más avanzados en redes globales) se viera con mucha más simpatía el mecanismo de

estandarización del TCP/IP que el de OSI.

Aunque por la exposición anterior pueda parecer lo contrario, también existen aspectos negativos en los

protocolos TCP/IP. Por un lado no se distinguen claramente los conceptos de servicio, interfaz y protocolo. En

segundo lugar, el 'modelo' TCP/IP fue diseñado con posterioridad al protocolo, intentando imitar la labor de

síntesis que se había hecho en el modelo OSI ( podríamos decir que es como si se hubieran cortado los patrones

después de cosido el traje). En tercero esta la 'caja negra' que hemos llamado capa host-red y que en el modelo

TCP/IP es mas bien una interfaz que una capa, ya que lo único que se especifica de ella es que ha de ser capaz de

transmitir paquetes IP. Como consecuencia de esto el modelo TCP/IP no distingue entre la capa física y la de

enlace, ya que ambas entran en la 'capa' host-red.

Por otro lado, aun cuando los protocolos IP y TCP fueron diseñados concienzudamente y bien implementados,

algunos protocolos, especialmente del nivel de aplicación, fueron el resultado de una improvisación para resolver

un problema concreto; como las implementaciones se distribuían después de forma gratuita se extendían con

rapidez por lo que resultaban difíciles de sustituir; un ejemplo de esto lo tenemos en el protocolo TelNet que se

utiliza ampliamente a pesar de no tener soporte para interfaz gráfica, ratón, etc.

Durante la década de los ochenta en Europa las redes académicas de la mayoría de los países (incluido España)

utilizaban protocolos OSI por imposición de los respectivos gobiernos y de la Comunidad Europea; a la vista de

los problemas ya mencionados de los productos OSI, y la extensión y buen resultado de los protocolos TCP/IP,

se empezaron a ofrecer en 1991 servicios basados en TCP/IP, lo cual provocó su inmediata difusión por toda

Europa y el estancamiento y casi desaparición de los servicios basados en protocolos OSI.

Probablemente el único protocolo OSI que sobrevivirá la batalla contra TCP/IP será el X.500, protocolo a de

aplicación que implementa los servicios de directorio. Estos estaban cubiertos en TCP/IP por un servicio

denominado Whois de funcionalidad mucho mas pobre. Probablemente es el hecho de no haber una alternativa en

TCP/IP lo que ha salvado a X.500, que actualmente funciona sobre TCP/IP..

Consecuentemente con los puntos fuertes y débiles de cada modelo y protocolo, en el curso nos basaremos en

una versión modificada del modelo OSI, del cual hemos suprimido la capa de sesión y la de presentación. Sin

embargo utilizaremos este modelo para describir fundamentalmente protocolos TCP/IP, si bien también

hablaremos de otros mas modernos y que en muchos casos se utilizan como medio de transporte para TCP/IP. En

la figura siguiente hacemos un resumen del modelo y los principales protocolos que veremos en cada capa.

Capa Protocolo

Aplicación TCP/IP (DNS, SNMP, SNMP, NNTP, HTTP)

Transporte TCP/IP (TCP, UDP) ATM (AAL1, AAL2, AAL3/4, AAL5)

Red TCP/IP (IP, ICMP, ARP, RARP, OSPF, BGP, IPv6), ATM (Q2931)

Enlace ISO( HDLC), TCP/IP (SLIP, PPP), ATM, LANs

Física N-ISDN, B-ISDN (ATM), GSM, SONET/SDH, LANs

Cable coaxial, cable UTP, fibra óptica, microondas, radioenlaces, satélite

Tabla 1.1: Ejemplos de protocolos en cada uno de los niveles del modelo de red OSI-TCP/IP

1.6.- EJEMPLOS DE SERVICIOS DE COMUNICACIÓN

Dado que cualquier usuario puede solicitar un acceso a las redes que operan las compañías telefónicas, a éstas se

las denomina redes públicas de datos (PDN, Public Data Networks). Cuando se desea interconectar ordenadores

o redes locales ubicadas a cierta distancia es preciso normalmente utilizar los servicios de alguna de esas redes

públicas. Dichos servicios pueden clasificarse de acuerdo con el tipo de conexión que ofrecen, permanente o

temporal, y con el tipo de circuito, real o virtual. Esquemáticamente sería:

Tipo de circuito Tipo de conexión

Permanente Temporal

Real Líneas dedicadas Redes de conmutación de circuitos

(RTB, RDSI, GSM)

Virtual Redes de conmutación con PVCs (X.25, Frame Relay, ATM) Redes de conmutación con SVCs (X.25,

Frame Relay, ATM)

Tabla 1.2: Clasificación de los tipos de servicio de transmisión de datos por líneas telefónicas según el tipo de

circuito y conexión.

En la práctica suele utilizarse en cada caso el servicio mas conveniente por sus prestaciones y precio, por lo que

las redes suelen mezclar varios de los servicios que hemos mencionado. Vamos a dar una pequeña descripción de

cada uno de ellos.

1.6.1.- Líneas dedicadas

La solución mas simple para una red es el circuito real permanente, constituido por lo que se conoce como líneas

dedicadas o líneas alquiladas (leased lines); está formado por un enlace punto a punto abierto de forma

permanente entre los ordenadores o routers que se desean unir. Una línea dedicada es únicamente un medio de

transmisión de datos a nivel físico, todos los protocolos de niveles superiores han de ser suministrados por el

usuario.

La red ARPAnet que hemos visto anteriormente se constituyó mediante líneas dedicadas. La Internet incorpora

actualmente todos los servicios que hemos mencionado.

Normalmente no es posible contratar una línea dedicada de una velocidad arbitraria, existen unas velocidades

prefijadas que son las que suelen ofrecer las compañías telefónicas y que tienen su origen en la propia naturaleza

del sistema telefónico, como veremos más adelante. Por ejemplo Telefónica de España ofrece líneas dedicadas de

las siguientes velocidades: 9.6, 64, 128, 192, 256, 512 y 2.048 Kbps. El precio de una línea dedicada es una cuota

fija mensual que depende de la velocidad y de la distancia entre los dos puntos que se unen.

En las líneas dedicadas la capacidad contratada está reservada de forma permanente en todo el trayecto. Su costo

es elevado y por tanto su instalación generalmente sólo se justifica cuando el uso es elevado (al menos tres o

cuatro horas al día). Por este motivo las líneas dedicadas no suelen utilizarse en casos en que se necesita una

conexión de forma esporádica, por ejemplo una oficina que requiere conectarse unos minutos al final del día para

transferir unos ficheros, o un usuario doméstico que se conecta a Internet en los ratos de ocio.

Para mostrar el elevado consumo de recursos que representan las líneas dedicadas pondremos un ejemplo:

supongamos que la empresa X con sede central en Valencia ha abierto treinta sucursales en distintos puntos de

España, y necesita que los ordenadores de las sucursales comuniquen con la sede central todos los días durante

treinta minutos cada uno para transferir 2 MBytes de información. Para esto la empresa solicita 30 líneas

dedicadas de 64 Kbps a la compañía telefónica, y constituye una red con topología de estrella. Aunque cada línea

se utiliza únicamente el 2% del tiempo con una eficiencia del 14% el ancho de banda está reservado en su

totalidad de forma permanente. Además, se requieren treinta interfaces físicos en el servidor, lo cual lo encarece y

complica bastante.

1.6.2.- Conmutación de circuitos

La conmutación de circuitos supone una utilización mas óptima de los recursos que las líneas dedicadas, ya que la

conexión extremo a extremo sólo se establece durante el tiempo necesario. Para la transmisión de datos mediante

conmutación de circuitos se utiliza la misma red que para la transmisión de la voz, mediante módems o

adaptadores apropiados. Genéricamente se la denomina Red Telefónica Conmutada (RTC) o PSTN (Public

Switched Telephone Network) y comprende en realidad tres redes diferentes:

La Red de Telefonía Básica (RTB) también llamada POTS (Plain Old Telephone Service); Está formada por las

líneas analógicas tradicionales y por tanto requiere el uso de módems; la máxima velocidad que puede obtenerse

en este tipo de enlaces es de 33.6 Kbps (recientemente han aparecido en el mercado módems capaces de

comunicar a 56 Kbps por líneas analógicas si se dan ciertas condiciones).

La Red Digital de Servicios Integrados (RDSI) también llamada ISDN (Integrated Services Digital Network).

Está formada por enlaces digitales hasta el bucle de abonado, por lo que el circuito se constituye de forma digital

extremo a extremo. La velocidad por circuito es de 64 Kbps, pudiendo con relativa facilidad agregarse varios

circuitos (llamados canales) en una misma comunicación para obtener mayor ancho de banda.

La Red GSM (Global System for Mobile communications). Se trata de conexiones digitales, como en el caso de

la RDSI, pero por radioenlaces. La capacidad máxima de un circuito GSM cuando se transmiten datos es de 9.6

Kbps.

La RDSI apareció en España hacia 1994, y la red GSM hacia 1995. Dado que hasta fechas recientes el único

sistema de RTC era la RTB a menudo se utilizan ambos términos indistintamente para indicar la red telefónica

analógica. Para evitar confusiones conviene usar sólo el término RTB al referirse a la red telefónica analógica, y

reservar el término RTC para referirnos al conjunto de todas las redes conmutadas existentes, ahora o en el

futuro.

En el caso de la RTC los equipos se conecta a la red pública y en principio cualquier equipo puede comunicar con

cualquier otro, siempre que conozca su dirección (número de teléfono). Podemos ver la RTC como una gran

nube a la que se conectan multitud de usuarios. Una vez establecido un circuito en RTC la función que éste

desempeña para los protocolos de nivel superior es equivalente a la de una línea dedicada.

Telefónica de España dispone de los tres tipos de RTC (RTB, RDSI y GSM), con tarificación por tiempo de

conexión. En el caso de RTB y RDSI se aplica una tarificación con cuatro ámbitos: metropolitano, provincial,

nacional e internacional (éste último depende del país). En el caso de la red GSM (conocida como MoviStar) hay

sólo dos ámbitos: nacional e internacional. Existe otra red GSM operada por la empresa Airtel.

Es posible la interconexión entre ordenadores de redes diferentes (RDSI, RTB o GSM); en cuyo caso la

velocidad de transmisión será igual a la mas lenta de las conexiones implicadas; en algunos casos puede ser

necesario disponer de equipos o contratar servicios especiales.

Siguiendo con nuestro ejemplo anterior de la empresa X, en vez de líneas dedicadas se podría haber utilizado la

red telefónica conmutada (por ejemplo la RDSI). En este caso el costo de cada conexión es normalmente menor,

ya que sólo se paga por el tiempo que se esta utilizando. Además, la sede central podría contratar menos de

treinta enlaces si se planifica un horario escalonado de conexión de las sucursales, o si simplemente se considera

que la probabilidad de que todas llamen a la vez es muy reducida. Esto se conoce como sobresuscripción

(oversubscription) o sobrereserva ('overbooking) y es algo muy normal en redes cuando el número de usuarios es

razonablemente elevado y se puede jugar con el factor estadístico. Por ejemplo, supongamos que inicialmente la

sede central contrata diez accesos y observa que solo durante el 0,1% del tiempo están todos utilizados; entonces

se puede afirmar que el servicio tiene una disponibilidad del 99,9%, es decir, el 99,9% del tiempo hay líneas libres

para recibir llamadas de las sucursales; a la vista de esto la empresa puede decidir si aumenta o reduce el número

de accesos, según la disponibilidad que se quiera tener y el costo de cada acceso (aquí además del costo de la

compañía telefónica se deberá tener en cuenta el de las interfaces , módems y equipo auxiliar).

1.6.3.- Conmutación de paquetes

Con la conmutación de circuitos hemos avanzado en el aprovechamiento de la infraestructura. Sin embargo nos

encontramos aún con tres inconvenientes:

En ocasiones no podremos establecer la conexión por no haber circuitos libres, salvo que contratemos un número

de circuitos igual al máximo número posible de conexiones simultáneas, lo cual sería muy costoso.

Que un circuito se esté utilizando no garantiza que se esté aprovechando el ancho de banda que tiene asignado; en

nuestro ejemplo cada sucursal está conectada 30 minutos para enviar 2 MBytes de información, que cual supone

un aprovechamiento del 14% suponiendo que se trata de conexiones de 64 Kbps.

El servidor ha de tener una conexión física por cada circuito, aun cuando la ocupación media sea reducida.

Para evitar estos inconvenientes se crearon redes en las que el usuario puede mantener una única conexión física a

la red, y sobre ella varios circuitos virtuales con equipos remotos. De esta forma podemos dotar a nuestro

ordenador central de treinta circuitos virtuales, con lo que las sucursales siempre van a encontrar un circuito libre

sobre el cual establecer la conexión. Al mantener un solo enlace físico el costo de las interfaces, módems, etc., es

fijo e independiente del número de circuitos virtuales utilizados. Lógicamente al tener el ordenador central que

atender a todas las conexiones por el mismo enlace físico sería conveniente (aunque no necesario) incrementar la

velocidad de este; en nuestro ejemplo con conexiones el 2% del tiempo y con un tráfico medio del 14%; para las

30 oficinas agregadas nos daría una ocupación media del 8,4% (0.02x0.14x30) suponiendo un reparto

homogéneo (cosa poco probable); como previsiblemente muchas oficinas querrán conectar mas o menos a la

misma hora sería conveniente ampliar el enlace del servidor a 128 o 256 Kbps para evitar congestión en horas

punta.

Para poder definir circuitos virtuales es preciso disponer de equipos inteligentes en la red que puedan hacer la

distribución de los paquetes en función de su destino. Por esto a las redes que permiten crear circuitos virtuales se

las denomina redes de conmutación de paquetes, y en cierto sentido podemos considerarlas como la evolución

lógica de las redes de conmutación de circuitos. En realidad existen dos tipos de redes de conmutación de

paquetes, según ofrezcan servicios orientados a conexión o no orientados a conexión (envío de datagramas). La

primera red de conmutación de paquetes que existió fue como ya hemos visto ARPAnet, pero como no era

orientada a conexión no se adaptaba bien a un servicio de compañía telefónica. Para facilitar la facturación las

redes públicas de conmutación de paquetes suelen ofrecer servicios orientados a conexión en el nivel de red.

Actualmente hay tres tipos de redes públicas de conmutación de paquetes: X.25, Frame Relay y ATM, y todos

ofrecen servicios orientados a conexión. Las tres representan implementaciones bastante completas de los tres

primeros niveles del Modelo de Referencia OSI, y tienen muchos puntos en común, según veremos a

continuación.

La subred de una red de conmutación de paquetes se constituye mediante conmutadores unidos entre sí por líneas

dedicadas. La distribución de los conmutadores y la forma como éstos se unen entre sí (es decir la topología de la

red) es algo que decide el proveedor del servicio y que fija la carga máxima que la red podrá soportar en lo que se

refiere a tráfico entre conmutadores; la topología fija también la fiabilidad de la red, es decir cuan resistente será a

fallos de los enlaces (por ejemplo una red muy mallada será muy resistente). Cuando un usuario desea conectar un

equipo a la red el acceso se hace normalmente mediante una línea dedicada entre el equipo a conectar y el

conmutador mas próximo del proveedor de servicio (normalmente la Compañía Telefónica). La velocidad de la

conexión entre el equipo y el conmutador establece de entrada un máximo a las prestaciones que ese usuario

podrá obtener de la red. Puede haber además otras limitaciones impuestas por la capacidad de la red, por

saturación o porque se hayan impuesto limitaciones de acuerdo con lo contratado por el usuario con el proveedor

del servicio.

Aunque estamos considerando el caso en que la red de conmutación de paquetes la gestiona una compañía

Telefónica (con lo que tenemos una red pública de conmutación de paquetes), también es posible que una

organización o conjunto de organizaciones (por ejemplo una gran empresa, una administración o un conjunto de

universidades) establezcan una red privada basada en X.25, Frame Relay o ATM. En este caso normalmente la

gestión de la red se asigna a algún grupo especializado (por ejemplo el departamento de comunicaciones en el

caso de la empresa) que se ocupa de diseñar topología, solicitar los enlaces correspondientes, instalar los

conmutadores, etc. Si se desea que la red privada esté interconectada con la red pública es preciso prever que al

menos uno de los conmutadores de la red privada esté conectado con la red pública. Desde el punto de vista

técnico ambas redes son equivalentes en su funcionamiento, salvo que normalmente en una red privada o no se

tarifica la utilización, por lo que el control no es tan crítico.

En X.25, Frame Relay y ATM existe el concepto de circuito virtual (VC), que puede ser de dos tipos: conmutado

o SVC (Switched Virtual Circuit) y permanente o PVC (Permanent Virtual Circuit). El conmutado se establece y

termina a petición del usuario, mientras que el permanente tiene que ser definido por el proveedor del servicio,

mediante configuración en los conmutadores a los que se conectan los equipos implicados, normalmente mediante

modificación contractual con el cliente. En cierto modo es como si los PVCs fueran 'líneas dedicadas virtuales'

mientras que los SVCs son como conexiones RTC 'virtuales'.

1.6.3.1.- X.25

X.25 fue el primer protocolo estándar de red de datos pública. Se definió por primera vez en 1976 por la CCITT

(Comité Consultatif International Télégraphique and Téléphonique). Aunque el protocolo ha sido revisado

múltiples veces (la última en 1993) ya se ha quedado algo anticuado y no es en la actualidad un servicio

interesante, salvo en algunos casos, debido a su baja eficiencia y velocidad; normalmente no supera los 64 Kbps,

aunque se pueden contratar conexiones de hasta 2.048 Kbps. A pesar de estas desventajas conviene conocer los

aspectos básicos de X.25 pues aun existe una gran cantidad de usuarios de este tipo de redes. Además, en el

protocolo X.25 se definieron por primera vez muchos de los conceptos en que se basa frame relay y ATM, que

podemos considerar en cierto sentido como sus descendientes. El conjunto de estándares que definen X.25 ha

sido adoptado como parte del modelo OSI para los tres primeros niveles.

A nivel físico se definen en X.25 dos interfaces, la X.21 cuando se usa señalización digital (cosa poco habitual) y

la X.21bis (un subconjunto de la EIA-232D/V.24) cuando es analógica.

A nivel de enlace se utiliza un protocolo llamado LAP-B (Link Access Procedure-Balanced) que es una versión

modificada del estándar ISO HDLC (High-level Data Link Control), que veremos en detalle al estudiar la capa de

enlace.

El protocolo utilizado a nivel de red se conoce como X.25 PLP (Packet Layer Protocol). En este nivel se realizan

todas las funciones de control de flujo, confirmación y direccionamiento. Cada NSAP (Network Services Access

Point) en una red X.25 viene representado por una interfaz de un conmutador X.25, y tiene una dirección única.

Las direcciones son numéricas y típicamente pueden tener entre nueve y quince dígitos. Las redes X.25 públicas

de muchos países están interconectadas, como ocurre con las redes telefónicas. Para facilitar su direccionamiento

la CCITT ha establecido un sistema jerárquico análogo al sistema telefónico en la recomendación X.121; así es

posible por ejemplo llamar desde Iberpac (la red X.25 pública española) a una dirección de Transpac (la red

pública X.25 francesa), sin más que añadir el prefijo correspondiente a dicha red en la dirección de destino.

X.25 es un servicio fiable orientado a conexión; los paquetes llegan en el mismo orden con que han salido. Una

vez establecido un circuito entre dos NSAPs la información se transfiere en paquetes que pueden ser de hasta 128

bytes (aunque en muchas redes se permiten tamaños de hasta 4 KB). En la red los paquetes son transferidos de

cada conmutador al siguiente (almacenamiento y reenvío), y solo borrados cuando se recibe la notificación de

recepción. Un mismo NSAP puede tener establecidos varios VCs (PVCs y/o SVCs) hacia el mismo o diferentes

destinos.

Los ordenadores que se conectan a un conmutador X.25 necesitan tener la capacidad suficiente para procesar los

complejos protocolos X.25. Cuando se definió el estándar X.25 los ordenadores personales eran caros y poco

potentes; muchos usuarios que tenían necesidad de conectarse a redes X.25 no disponían de un ordenador

adecuado. Para estos casos se diseñó un equipo capaz de conectar un terminal asíncrono, que trabaja en modo

carácter (es decir, un paquete por carácter) a una red X.25. A dicho equipo se le denominó PAD (Packet

Assembler Disassembler) ya que se ocupaba de ensamblar y desensamblar los paquetes X.25 que recibía. A través

de un PAD un usuario de un PC, o incluso de un terminal 'tonto', podía conectarse a un host en una red X.25 y

trabajar como un terminal remoto de aquel. La CCITT publicó tres documentos para especificar todo lo

relacionado con el funcionamiento de un PAD: el X.3 describe las funciones propias del PAD, el X.28 define el

protocolo de comunicación entre el PAD y el terminal asíncrono, y el X.29 define el protocolo entre el PAD y la

red X.25. El uso conjunto de estos tres protocolos permite iniciar una sesión interactiva desde un terminal

conectado a un PAD con un ordenador remoto, por lo que se le conoce como el logon remoto XXX. Cuando un

usuario en un ordenador conectado a X.25 desea establecer una conexión como terminal remoto de otro

ordenador a través de una red X.25 lo hace mediante un programa en su ordenador que emula el comportamiento

de un PAD (PAD Emulation). El logon remoto XXX ofrece en redes X.25 un servicio equivalente al de Telnet en

TCP/IP. Para el caso de usuarios que no dispongan de un PAD propio muchas compañías telefónicas ponen a su

disposición un servicio de acceso a PADs por RTC (normalmente RTB). Este servicio se denomina normalmente

X.28, por ser este estándar el que define el protocolo de comunicaciones entre el terminal de usuario y el PAD.

El rendimiento que se obtiene de un VC X.25 depende de muchos factores: velocidad de los accesos físicos

implicados, número de VC simultáneos, tráfico en cada uno de ellos, carga de la red, infraestructura, etc.

En España Telefónica inició un servicio de red pública de conmutación de paquetes en 1971 con la red RSAN,

basada en unos protocolos propios, no estándar. Esta red hoy desaparecida fue la segunda red de conmutación de

paquetes del mundo (después de ARPAnet que empezó en 1969), y la primera establecida por un operador de

telefonía. En 1984 Telefónica inició la red Iberpac, que ya obedecía a los estándares X.25. A través de Iberpac es

posible acceder a mas de 200 redes similares en todo el mundo. Las velocidades de acceso a Iberpac pueden ser

de 2,4 a 2.048 Kbps. Es posible contratar PVCs, aunque lo normal es utilizar SVCs. La tarificación se hace por

tres conceptos: en primer lugar una cuota fija mensual según la velocidad de la línea de acceso, en segundo por el

tiempo que dura cada llamada (o lo que es lo mismo, el tiempo que esta establecido cada SVC), y en tercer lugar

por el número de paquetes transferidos por llamada. Para los dos últimos conceptos existen tres ámbitos de

tarificación: nacional, europeo e internacional (en X.25 cuesta lo mismo transferir datos entre dos oficinas vecinas

que entre Valencia y La Coruña). Telefónica dispone también de un servicio de acceso X.28 a su red Iberpac,

conocido como Datex28.

Los protocolos X.25 se diseñaron pensando en los medios de transmisión de los años setenta, líneas de baja

velocidad con tasa de errores elevada. El objetivo era aprovechar lo mejor posible las lentas líneas de transmisión

existentes, aun a costa de hacer un protocolo de proceso pesado. Por si esto fuera poco, las redes X.25 casi

siempre se utilizan para encapsular tráfico correspondiente a otros protocolos, por ejemplo TCP/IP, SNA o

DECNET (podríamos decir que los paquetes de estos protocolos viajan 'disfrazados' en paquetes X.25); cuando

se encapsula un protocolo como TCP/IP en X.25 se realizan de forma redundante las tareas de la capa de red, con

lo que el resultado es aún mas ineficiente. Para resolver este tipo de problemas a partir de 1990 se empezaron a

crear redes basadas en frame relay.

1.6.3.2.- Frame Relay

Frame Relay (que significa retransmisión de tramas) nació a partir de los trabajos de estandarización del servicio

RDSI, como un intento de crear una versión 'light' de X.25, que permitiera aprovechar las ventajas de poder

definir circuitos virtuales pero sin la baja eficiencia que tenían los protocolos excesivamente 'desconfiados' de

X.25. Mientras que en X.25 la capa de enlace y la capa de red eran sumamente complejas en frame relay ambas se

intentaron reducir a su mínima expresión, dejando en manos de los equipos finales toda la labor de acuse de

recibo, retransmisión de tramas erróneas y control de flujo; de esta forma frame relay se convertía en el

complemento perfecto a otros protocolos, tales como TCP/IP. En muchos casos se considera que frame relay no

es un protocolo a nivel de red sino a nivel de enlace (de ahí su nombre), y aun visto como nivel de enlace resulta

bastante ligero.

El servicio que suministra frame relay consiste básicamente en identificar el principio y final de cada trama, y

detectar errores de transmisión. Si se recibe una trama errónea simplemente se descarta, confiando en que el

protocolo de nivel superior de los equipos finales averigüe por sí mismo que se ha perdido una trama y decida si

quiere recuperarla, y como. A diferencia de X.25, frame relay no tiene control de flujo ni genera acuse de recibo

de los paquetes (estas tareas también se dejan a los niveles superiores en los equipos finales). El tamaño máximo

de los paquetes varía según las implementaciones entre 1 KB y 8 KB. La velocidad de acceso a la red típicamente

esta entre 64 y 2.048 Kbps, aunque ya se baraja la estandarización de velocidades del orden de 34 Mbps.

Una novedad importante de Frame Relay estriba en que se define un ancho de banda 'asegurado' para cada

circuito virtual mediante un parámetro conocido como CIR (Committed Information Rate). Un segundo

parámetro, conocido como EIR (Excess Information Rate) define el margen de tolerancia que se dará al usuario,

es decir, cuanto se le va a dejar 'pasarse' del CIR contratado. Por ejemplo, supongamos que un ordenador se

conecta a una red frame relay mediante una línea de acceso al conmutador de 1.984 Kbps, y tiene dos circuitos

establecidos con otros dos ordenadores, cada uno de ellos con un CIR de 256 Kbps y un EIR de 256 Kbps; en

este caso cada circuito tendrá asegurado un ancho de banda de 256 Kbps como mínimo, y si la red no está

saturada podrá llegar a 512 Kbps; si un circuito intenta utilizar mas de 512 Kbps el conmutador frame relay

empezará a descartar tramas. Obsérvese que en este caso la línea de acceso nunca llegaría a saturarse, ya que

como mucho podrían enviarse 512 Kbps por cada circuito. La especificación del CIR para un circuito virtual se

hace de forma independiente para cada sentido de la transmisión, y puede hacerse asimétrica, es decir dar un valor

distinto del CIR para cada sentido.

Cuando un usuario hace uso del EIR (es decir, genera un tráfico superior al CIR contratado en un circuito virtual)

el conmutador frame relay pone a 1 en las tramas excedentes un bit especial denominado DE (Discard Elegibility).

Si se produce congestión en algún punto de la red el conmutador en apuros descartará en primera instancia las

tramas con el bit DE marcado, intentando resolver así el problema. Este mecanismo permite a un usuario

aprovechar la capacidad sobrante en la red en horas valle sin perjudicar la calidad de servicio a otros usuarios en

horas punta, ya que entonces se verá limitado a su CIR. En realidad el CIR tampoco está garantizado, ya que si la

congestión no se resuelve descartando las tramas DE el conmutador empezará a descartar tramas normales (no

marcadas como DE) que pertenecen a usuarios que no han superado su CIR. Afortunadamente las redes frame

relay se suelen dimensionar de forma que el CIR de cada usuario esté prácticamente garantizado en cada

momento. En cierto modo podemos imaginar el bit DE como un sistema de 'reserva de asiento' en un billete de

tren (el bit a 0 significaría en este caso tener hecha reserva).

Una red Frame Relay podría utilizarse en vez de líneas dedicadas para interconectar conmutadores X.25; a la

inversa sería mucho más difícil ya que al ser X.25 una red mas lenta los retardos introducidos serían apreciados

por los usuarios de Frame Relay.

En ocasiones se utilizan redes Frame Relay para transmitir voz digitalizada; esto no es posible con X.25 debido a

la lentitud del protocolo, que introduciría unos retardos excesivos; el envío de voz por una red tiene unos

requerimientos especialmente severos en cuanto a retardos para que la transmisión se efectúe correctamente.

La red pública Frame Relay de Telefónica se denomina Red Uno, y esta operativa desde 1992. Aunque Telefónica

anunció la disponibilidad de SVCs en Frame Relay para 1997, parece que estos aun no estan disponibles y el

único servicio contratable es el de PVCs. La tarificación se realiza por dos conceptos: el primero es una cuota fija

mensual en función de la velocidad de acceso a la red; el segundo es una cuota fija al mes por cada circuito según

el valor de CIR que se tenga contratado; en ambos casos la tarifa depende de la distancia. El EIR no se especifica

en el contrato, y por tanto no se paga, pero tampoco se compromete su valor por parte de Telefónica;

habitualmente Telefónica pone un EIR que es 256 Kbps superior al CIR contratado. La velocidad del acceso

físico puede tener valores comprendidos entre 64 y 1.984 Kbps. El CIR puede ser de 0 a 1.984 Kbps. Al no

existir circuitos conmutados la Red Uno no es una red abierta como lo son Iberpac o la RTC. Es posible la

conexión internacional con muchas otras redes frame relay gracias a acuerdos suscritos con diversos operadores.

1.6.3.3.- ATM y B-ISDN

Casi todos los servicios de comunicación que hemos visto hasta ahora fueron diseñados para la transmisión de

voz o datos, pero no ambos. La RTB y la red GSM, pensadas para la voz, pueden transmitir datos, pero sólo a

muy bajas velocidades. Las líneas dedicadas y redes Frame Relay, pensadas para datos, pueden transmitir voz si

se utilizan los equipos apropiados y se respetan ciertas restricciones.

El único servicio de los que hemos visto hasta ahora que se diseñó pensando en voz y datos es la RDSI (de ahí el

nombre de Servicios Integrados). Pero la RDSI tiene dos inconvenientes importantes:

Al ser una red de conmutación de circuitos reales la reserva del ancho de banda se realiza durante todo el tiempo

que esta establecida la comunicación, independientemente de que se estén transfiriendo datos o no (o en el caso

de transmitir voz independientemente de que se este hablando o se este callado).

El estándar RDSI se empezó a definir en 1984. En aquel entonces las líneas dedicadas eran de 9.6 Kbps en el

mejor de los casos y hablar de enlaces a 64 Kbps parecía algo realmente avanzado; sin embargo el proceso de

estandarización tardó mas de lo previsto (cosa que ocurre a menudo) y cuando aparecieron los primeros servicios

RDSI diez años más tarde la red 'avanzada' resultaba interesante sólo en entornos domésticos y de pequeñas

oficinas; se había quedado corta para nuevas aplicaciones.

Hasta aquí sólo hemos hablado de la transmisión de voz o datos, pero las redes de comunicaciones permiten

transmitir también otros tipos de información como imágenes en movimiento (videoconferencia o vídeo), que

tienen unos requerimientos distintos. De una forma muy concisa resumimos en la siguiente tabla las características

esenciales de cada tipo de tráfico:

Tipo de información Capacidad Pérdida tolerable Retardo Jittter

Datos Variable Muy baja Alto Alto

Audio en tiempo real, monólogo Baja (64 Kbps) Baja Bajo Muy bajo

Audio en tiempo real, diálogo Baja (64 Kbps) Baja Muy bajo Muy bajo

Vídeo en tiempo real Alta (2 Mbps) Media Bajo Bajo

Tabla 1.3.- Necesidades de los diversos tipos de tráfico

Cuando una red está preparada para transmitir tanto audio y vídeo como datos informáticos decimos que es una

red multimedia. Generalmente el tráfico multimedia tiene unas necesidades muy variables de ancho de banda, se

dice que es un tráfico a ráfagas ('bursty traffic').

Cuando se tiene tráfico a rr'e1fagas resulta especialmente útil disponer de una red de conmutación de paquetes

con circuitos virtuales, ya que así unos usuarios pueden aprovechar en un determinado instante el ancho de banda

sobrante de otros. Sin embargo las redes de este tipo que hemos visto hasta ahora (X.25 y frame relay) no son

apropiadas para tráfico multimedia porque el retardo y el jitter son impredecibles cuando la red esta cargada, y en

general son demasiado lentas (especialmente X.25).

Las compañías telefónicas vienen trabajando desde hace bastante tiempo en el diseño de una red adecuada al

tráfico multimedia que permita aprovechar las ventajas de la conmutación de paquetes, para así utilizar de forma

mas eficiente las infraestructuras y ofrecer servicios nuevos, tales como la videoconferencia o el vídeo bajo

demanda. La tecnología que permite todo esto se denomina ATM (Asynchronous Transfer Mode) y sus orígenes

se remontan nada menos que a 1968, cuando se concibió en los laboratorios Bell el primer sistema de transmisión

de celdas.. En esencia lo que se intenta con esta nueva tecnología es integrar todos los servicios en una única red

digital, lo mismo que pretendía la RDSI (aunque como hemos visto llegó demasiado tarde). Por este motivo

ATM también se denomina a veces RDSI de banda ancha o RDSI-BA (B-ISDN, Broadband-ISDN); por

contraste a la 'antigua' RDSI se la denomina en ocasiones RDSI de banda estrecha o RDSI-BE (N-ISDN,

Narrowband-ISDN). Podríamos decir que la RDSI de banda ancha es lo más parecido a las 'autopistas de la

información'.

En 1986 la CCITT definió el concepto de RDSI-BA y eligió ATM como la tecnología sobre la que se basarían los

futuros estándares. En aquel entonces ATM era una tecnología que interesaba exclusivamente a las compañías

telefónicas. Gradualmente los fabricantes de ordenadores se fueron percatando de las posibilidades y futuro de

dicha tecnología; para acelerar el proceso de estandarización se creó en 1991 el ATM forum, en el que

participaban compañías telefónicas y fabricantes de ordenadores. A partir de ese momento se ha producido un

avance impresionante en las normas y equipos ATM, especialmente en lo que se refiere a redes de datos. El

primer conmutador ATM comercial apareció en 1991.

En cierto sentido ATM puede verse como una evolución de frame relay. La principal diferencia es que los

paquetes ATM tienen una longitud fija de 53 bytes (5 de cabecera y 48 de datos) frente al tamaño variable y

mucho mayor de las tramas frame relay. Debido a su tamaño pequeño y constante los paquetes ATM se

denominan celdas, y por esto en ocasiones a ATM se le denomina cell relay (retransmisión de celdas). Manejar

celdas de un tamaño tan reducido tiene la ventaja de que permite responder con mucha rapidez a tráfico de alta

prioridad que pueda llegar inesperadamente mientras se están transmitiendo otro menos urgente, algo muy

importante en tráfico multimedia. El hecho de que todas las celdas sean del mismo tamaño simplifica el proceso

en los nodos intermedios, cuestión esencial cuando se quiere que dicho proceso sea lo más rápido posible. En el

lado negativo está el hecho de que la eficiencia de una conexión ATM nunca puede superar el 90% (48/53)

debido a la información de cabecera que viaja en cada celda.

Al igual que en X.25 o frame relay, una red ATM se constituye mediante conmutadores ATM normalmente

interconectados por líneas dedicadas, y equipos de usuario conectados a los conmutadores. Mientras que en X.25

o frame relay se utilizan velocidades de 64 Kbps a 2 Mbps, en ATM las velocidades pueden llegar a 155,52,

622,08 o incluso superiores. La elección de precisamente estos valores se debe a que son los que se utilizan en el

nuevo sistema de transmisión sobre fibra óptica en redes WAN denominado SONET/SDH (Synchronous Optical

NETwork/Synchronous Digital Hierarchy), que es el que están utilizando las compañías telefónicas actualmente

en las infraestructuras. ATM también puede utilizarse a velocidades inferiores, 34 Mbps e incluso 2 Mbps.

Dos equipos conectados a una red ATM pueden establecer entre si un circuito virtual, permanente o conmutado,

y transmitir por él información digital de cualquier tipo. ATM da al usuario muchas mas facilidades que X.25 o

frame relay para controlar las características de su circuito virtual: se puede fijar un ancho de banda máximo

permitido, un margen de tolerancia sobre dicho máximo, un ancho de banda mínimo garantizado, un ancho de

banda asimétrico, un perfil horario de forma que el ancho de banda fluctúe con la hora del día de una forma

preestablecida, etc. Además es posible definir prioridades y distintos tipos de tráfico, de forma que se prefiera

fiabilidad o rapidez, tráfico constante o a ráfagas, etc.

El modelo de referencia ATM

ATM tiene su propio modelo de referencia, constituido por tres capas denominadas capa física, capa ATM y capa

de adaptación ATM, o capa AAL (ATM Adaptation Layer).

La capa física está formada por dos subcapas: la PMD (Physical Media Dependent) y la TC (Transmission

Convergence). La subcapa PMD describe la interfaz física con el medio de transmisión, y equivale a la capa física

del modelo OSI. La subcapa TC se ocupa de 'deshacer' las celdas en bits para pasarlos a la subcapa PMD en el

envío, y de recibir los bits de la subcapa PMD para reconstruir las celdas en la recepción. Si consideramos la celda

como equivalente a la trama en el modelo OSI esta subcapa haría la función de la capa de enlace. Por este motivo

nosotros estudiaremos la subcapa TC en la capa de enlace.

La capa ATM trata de la estructura de las celdas y su transporte. También realiza las tareas de señalización, es

decir establece y termina los circuitos virtuales, y realiza el control de congestión. Sus funciones son una mezcla

de la capa de enlace y la capa de red en el modelo OSI.

La capa de adaptación ATM (capa AAL) se divide también en dos subcapas; la inferior se denomina subcapa

SAR (Segmentation And Reassembly) se ocupa de fragmentar el paquete que recibe desde arriba (normalmente

mayor de 48 bytes) en celdas para su envío, y de reensamblarlo en la recepción cuando se lo pasa la capa ATM.

La subcapa CS (Convergence Sublayer) se ocupa de suministrar distintos tipos de servicio adecuados al tipo de

tráfico (vídeo, audio, datos. etc.). La capa AAL corresponde en sus funciones a la capa de transporte del modelo

OSI.

Obsérvese que en el modelo de referencia ATM no se habla de aplicaciones. En realidad el modelo contempla la

existencia de capas por encima de la capa AAL, pero no se especifican sus funciones ni características. El modelo

deja total libertad a los implementadores sobre como diseñar las aplicaciones que funcionen sobre ATM.

Actualmente el principal uso de ATM es como medio de transporte para otros protocolos; hay muy pocas

aplicaciones que hayan sido diseñadas para funcionar de manera nativa, es decir, directamente sobre la capa AAL.

Futuro de ATM

Probablemente ATM es el acrónimo que está mas de moda en el mundo de las telecomuncaciones actualmente.

Prácticamente cualquier revista del área incluye uno o varios artículos sobre algún aspecto de ATM o tema

relacionado. En los últimos años ha habido bastante debate sobre si ATM se consolidaría o no como la tecnología

de red del futuro, cosa que hoy en día ya pocos ponen en duda. Una de las razones que ha hecho prosperar a

ATM es que las compañías telefónicas han visto en esta red su oportunidad para competir con los servicios que

ofrecen las compañías de televisión por cable.

Aunque seguirán durante mucho tiempo ofreciéndose todos los tipos de servicios que hemos visto anteriormente,

es muy probable que en unos años la infraestructura básica de las compañías telefónicas esté formada por

conmutadores ATM unidos mediante enlaces SONET/SDH; y todos los demás servicios utilicen esta red como

medio de transporte (de forma análoga a como X.25 puede utilizar frame relay). Por ejemplo Telefónica está

evolucionando hacia una red ATM para la interconexión de sus grandes centros como infraestructura básica sobre

la que discurrirá el tráfico de todas las otras redes.

Existen aun muy pocas experiencias de servicios públicos ATM; una de las mayores se ha puesto en marcha en

Finlandia, país que se encuentra a la cabeza de Europa en muchos aspectos de telecomunicaciones. En España

Telefónica inició en 1996 dos servicios de red ATM denominados servicio Gigacom y Servicio Cinco

(Comunicaciones Integrales Corporativas). Estos servicios están orientados a clientes con grandes necesidades de

transmisión de datos mutimedia; solo se permite la constitución de PVCs; las velocidades de acceso van de 512

Kbps a 155 Mbps. Este servicio puede ser una alternativa interesante a las líneas dedicadas de alta velocidad, ya

que además de su precio más interesante permiten contratar servicios de acuerdo a horarios preestablecidos, por

ejemplo un periódico que necesita transmitir todos los días un circuito de 4 Mbps entre sus dos oficinas

principales de 1 a 2 de la mañana para transmitir la edición del día siguiente.

Curiosamente uno de los campos donde ATM ha encontrado más éxito es como base para constituir redes locales

de alta velocidad. Existen hoy en día equipos en el mercado que permiten interconectar redes locales tradicionales

(Ethernet, Token Ring, FDDI) a través de conmutadores ATM, pudiendo conectar directamente a ATM a 155

Mbps los servidores mas importantes; de esta forma se consiguen prestaciones y funcionalidades mejores que las

de cualquier red local actual. Esta por ver si las redes locales de alta velocidad del futuro se basarán en ATM,

pero no hay duda de que esta tecnología WAN tiene un papel que jugar también en la LAN.

1.7.- EJEMPLOS DE REDES

Las redes que hay en el mundo difieren en cuanto a sus medios físicos de transmisión, protocolos, tipos de

máquinas que conectan, forma como se crearon, modo de administración, etc. A fin de ilustrar esta diversidad

antes de entrar a estudiar en detalle cada una de las capas antes descritas hemos seleccionado unos ejemplos

representativos que describiremos a continuación.

1.7.1.- Novell NetWare

Este es el sistema de red de PC mas popular en el mundo. Es una red diseñada para ser utilizada en una empresa

(típicamente en una red local Ethernet o Token ring) donde cada usuario dispone de un PC que actúa como

cliente y uno o varios PCs (normalmente más potentes) actúan como servidores. De esta forma los usuarios

comparten ficheros, aplicaciones, etc., de forma transparente como si estuvieran en su propio PC.

La pila de protocolos propietarios en que se basa NetWare es una versión modificada del XNS (Xerox Network

System). Tiene un cierto parecido con TCP/IP:

Capa

Aplicación SAP Servidor de ficheros ...

Transporte NCP SPX

Red IPX

Enlace Ethernet Token ring ARCnet

Física Ethernet Token ring ARCnet

Tabla 1.4.- Protocolo utilizado en cada capa por Novell NetWare

El protocolo de red, llamado IPX, es un protocolo no fiable no orientado a conexión que se parece bastante a IP.

El protocolo de transporte, NCP (Network Core Protocol) es realmente la pieza clave de NetWare. Existe otro

protocolo de transporte mas sencillo, denominado SPX, y también es posible utilizar TCP. En el nivel de

aplicación existen diversos protocolos, y cada uno elige el protocolo de transporte que mejor se acopla a sus

necesidades, por ejemplo el sistema de ficheros usa NCP y Lotus Notes (una aplicación de comunicación y

trabajo en grupo) usa SPX.

Un paquete IPX contiene los siguientes campos:

Campo Bytes Propósito

Checksum 2 Control de errores de transmisión; raramente se utiliza pues el nivel de enlace ya hace

comprobación

Longitud de paquete 2 Indica la longitud del paquete

Control de transporte 1 Cuenta cuantas redes ha atravesado el paquete; cuando supera un máximo

éste es descartado. De esta forma se evita el riesgo de que se produzcan bucles.

Tipo de paquete 1 Sirve para marcar varios paquetes de control

Dirección de destino 12 Formada por 12 bytes que se estructuran en tres partes: red (4 bytes),

ordenador (6 bytes) y socket local (2 bytes)

Dirección de origen 12 12 bytes en formato 4-6-2, como en la dirección de destino

Datos Variable El tamaño máximo de este campo viene fijado por el tamaño máximo de paquete soportado en

la red que se utiliza en el nivel de enlace

Tabla 1.5.- Estructura de un paquete IPX

Con NetWare podemos construir una red única o varias interconectadas, según asignemos direcciones en las que

coincidan o no los cuatro primeros bytes de todas las máquinas. En caso de tener mas de una red deberá haber

algún dispositivo (router) que interconecte las diversas redes.

Los servidores anuncian su presencia enviando cada cierto tiempo (aproximadamente un minuto) paquetes en los

que indica su dirección y los servicios que ofrece; estos paquetes se envían utilizando el protocolo SAP (Service

Advertising Protocol). Otras máquinas, llamadas agentes, se dedican a recoger esta información para saber que

servidores están disponibles, y dónde. Cuando un cliente arranca su software de NetWare envía un paquete

broadcast preguntando cual es su servidor mas próximo. El agente local ve esta petición y responde indicándole

que servidor debe utilizar. El servidor utilizado puede estar en la misma red que el cliente, o en otra accesible a

través de un router.

1.7.2.- ARPANET, NSFNET y La Internet

Como ya hemos comentado ARPANET tuvo sus orígenes en un proyecto del Departamento de Defensa de los

Estados Unidos que se desarrolló en la segunda mitad de la década de los sesenta, y que pretendía crear una red

de ordenadores resistente a ataques militares. Para esto se optó por crear una red de conmutación de paquetes

formada por ordenadores especializados denominados IMPs (Interface Message Processors) que se

interconectaban por líneas telefónicas punto a punto de 56 Kbps. Para aumentar la fiabilidad de la red se diseñó

una topología mallada en la que cada IMP estaba conectado al menos a otros dos. Los IMPs eran los routers de

la ARPANET. Como detalle curioso diremos que eran miniordenadores Honeywell con 24 KBytes de memoria

RAM especialmente modificados para desarrollar esta tarea; un router pequeño de hoy en día tiene típicamente de

2 a 4 MBytes de memoria RAM.

Dado que en aquellas fechas aun no existían redes locales, cada IMP se conectaba en forma local a un solo

ordenador (host) ubicado en la misma habitación; era este ordenador, que daba servicio a un número

razonablemente elevado de usuarios, el que permitía a éstos utilizar la red a través de sus aplicaciones. En la

ARPANET la subred estaba formada por los IMPs y las líneas punto a punto que los unían.

La ARPANET empezó a funcionar en diciembre de 1969 con cuatro nodos. En septiembre de 1972 tenía 34

nodos repartidos por todo Estados Unidos.

Paulatinamente se fueron ampliando las posibilidades de los IMP, permitiendo conexiones de varios hosts en cada

IMP, de hosts remotos, o incluso de simples terminales. También se hicieron pruebas con medios de transmisión

distintos de las líneas telefónicas, tales como transmisiones por radio o vía satélite. En estas pruebas se puso de

manifiesto que los protocolos existentes no eran aptos para interconectar redes con diferentes tecnologías, por lo

que con este fin se diseñaron unos nuevos, que son los que conocemos como TCP/IP, y que fueron los oficiales

en ARPANET desde principios de 1983. Para fomentar su uso ARPA adjudicó diversos contratos a la

Universidad de California en Berkeley y a BBN (empresa encargada de gestionar la ARPANET) para que

integraran los nuevos protocolos en el UNIX de Berkeley. El momento fue muy propicio y muchas universidades

de Estados Unidos se conectaron a la nueva red. El principal problema que tenía la ARPANET era que sólo las

universidades o centros de investigación que tuvieran contratos con el DoD podían conectarse a ella, y muchas no

los tenían.

En vista del éxito que tenía ARPANET la NSF (National Science Foundation) diseñó en 1984 una red paralela

que permitiría a las universidades conectarse sin las restricciones que imponía ARPANET. Para esto se empezó

de una forma muy similar a la ARPANET, interconectando seis superodenadores que la NSF tenía repartidos por

Estados Unidos mediante microordenadores adaptados para actuar como routers; el superordenador iba

conectado al router y éste a una o dos líneas. En la NSFNET también se utilizaban los protocolos TCP/IP. La

Universidad Carnegie-Mellon, que estaba conectada a NSFNET y ARPANET, hacía de 'puente' entre ambas

redes para permitir el intercambio de paquetes.

El crecimiento de la NSFNET fue espectacular. Multitud de universidades, centros de investigación, museos y

bibliotecas se conectaron a ella. En poco tiempo las líneas iniciales de 56 Kbps que constituían la espina dorsal o

backbone de la red tuvieron que ser aumentadas a 448 Kbps, y después a 1.5 Mbps. A medida que la red se

popularizaba las empresas comerciales querían entrar en ella, pero esto no era posible con una red financiada por

fondos públicos. En 1990 IBM, MCI y MERIT, impulsados por la NSF, crearon una empresa sin ánimo de lucro

denominada ANS (Advanced Networks and Services) que se ocupó de sustituir a NSFNET y crear ANSNET,

aumentando la capacidad del backbone a 45 Mbps. También en 1990 desapareció por completo ARPANET, que

había ido disminuyendo en importancia a medida que NSFNET y otras redes fueron ocupando su terreno. En

1995 ANSNET fue vendido a America Online; en ese momento existían ya numerosas compañías que operaban

redes IP comerciales en los Estados Unidos.

Después de que en 1984 se interconectaran ARPANET y NSFNET también lo hicieron muchas redes regionales y

de otros países, aprovechando la ventaja que suponía tener un protocolo común. Así se constituyó poco a poco

una superred o interred que desde el punto de vista del usuario era una única red. De manera coloquial los

usuarios empezaron a llamar a esta superred la internet, hasta el punto de que este llegó a ser su nombre propio;

no existe una fecha concreta en la que podamos fijar el origen de La Internet. Sin duda ARPANET y NSFNET

han sido sus dos principales impulsores.

En Europa (y en España) el desarrollo de La Internet estuvo frenado durante la década de los ochenta por

razones políticas, ya que los gobiernos y la Comunidad Europea, que financiaban las redes de investigación,

fomentaban el uso de protocolos OSI e impedían el uso de TCP/IP (la excepción eran los países nórdicos, que sí

estaban integrados en La Internet). La comunicación de los investigadores europeos con sus colegas americanos

sólo podía efectuarse a través de pasarelas, generalmente limitadas al correo electrónico en modo texto. En 1991

la actitud de los gobiernos y las redes europeas de investigación empezó a cambiar, se permitió la coexistencia de

los protocolos TCP/IP con los OSI, y la interconexión a La Internet; de forma inmediata se produjo una

explosión en el número de usuarios de la Internet en Europa, que superó incluso a la ocurrida en Estados Unidos

unos años antes.

Actualmente la Internet crece sin parar, a un ritmo que aproximadamente duplica su tamaño cada año. Es de

esperar que en unos años este ritmo disminuya. El crecimiento tan elevado, unido a la privatización de la

infraestructura básica, ha traído como consecuencia indeseable la saturación de la red en muchas áreas. En

octubre de 1996 se puso en marcha una iniciativa, liderada por 34 universidades de Estados Unidos, denominada

Internet II. El objetivo de Internet II es rescatar el espíritu original de la NSFNET, es decir, crear un entorno de

red específicamente orientado al ámbito académico e investigador que permita garantizar al usuario una calidad

de servicio tal que permita experimentar con nuevos servicios que requieran una elevada velocidad de

transmisión. Aunque nace como una iniciativa de los Estados Unidos, no sería raro que en un breve plazo se unan

a ella instituciones europeas.

El mecanismo informal que solía predominar en los viejos tiempos de La Internet ya no es factible hoy en día dada

la gran cantidad de usuarios e intereses comerciales en juego. Por esto se creó en 1992 una asociación

denominada Internet Society (ISOC) que se ocupa de coordinar, promover y organizar el futuro desarrollo de La

Internet, incluida la aceptación de nuevos estándares dentro del conjunto de protocolos.

1.7.3.- La red nacional de I+D, RedIRIS

Como en muchos otros países, en España el desarrollo de las redes de ordenadores se produjo inicialmente por la

necesidad de comunicación de las universidades y centros de investigación. Las primeras conexiones se llevaron a

cabo en 1984 cuando tres universidades en Madrid y Barcelona se conectaron a la red EARN (European

Academic and Research Network) que, patrocinada en sus inicios por IBM, utilizaba unos protocolos de este

fabricante llamados NJE (Network Job Entry) anteriores incluso a SNA. Un año más tarde otros centros

establecieron otra red basada en ordenadores VAX/VMS de Digital Equipment Corporation (DEC) que utilizaba

protocolos DECNET. Ambas redes disponían de enlaces internacionales, pero no estaban interconectadas entre sí

a nivel nacional, por lo que la comunicación entre ellas sólo podía establecerse a través de una pasarela en otro

país, y sólo para correo electrónico. Las velocidades de interconexión típicas eran de 2.4 a 9.6 Kbps.

En 1988 el PNID (Plan Nacional de Investigación y Desarrollo), órgano dependiente de la CICYT (Comisión

Interministerial de Ciencia y Tecnología), en un intento por armonizar estas iniciativas y para extender el uso de

las redes a toda la comunidad universitaria española, inició el Programa IRIS (mas tarde RedIRIS), delegando su

gestión en Fundesco. Siguiendo directrices entonces normales en todas las redes de investigación europeas, el

Programa IRIS fomentaba el uso de protocolos OSI, lo cual supuso que en la práctica el avance de la red se viera

limitado por la falta de software adecuado para muchas plataformas, quedando el correo electrónico

prácticamente como el único servicio disponible. Para la transmisión de los datos se utilizaba el servicio Iberpac

de Telefónica, con velocidades de acceso de 2.4 a 9.6 Kbps. En Madrid, Barcelona y Sevilla se instalaron

conmutadores X.25 que se interconectaron mediante líneas dedicadas de 64 Kbps.

TEMA 2: LA CAPA FÍSICA

2.1.- INTRODUCCIÓN

La primera capa dentro de cualquier modelo de red está formada por el medio físico de transmisión y sus

interfaces ópticas o eléctricas. Independientemente de cual sea el conjunto de protocolos a utilizar es

imprescindible que haya compatibilidad entre los equipos. Por ejemplo, al solicitar a la compañía telefónica una

línea dedicada deberemos indicar el tipo de interfaz que tienen nuestros equipos e intentar que la línea dedicada se

nos suministre con ese mismo tipo de interfaz; si esto no es posible tendremos que proveernos de los conversores

apropiados; en algunas ocasiones la conversión se hace con un cable únicamente, en otras mediante un adaptador

pasivo (no alimentado), y en otras será preciso un equipo con alimentación eléctrica; la casuística en este campo

es tan variada que no podemos entrar en detalles concretos a este respecto, pues nos llevaría demasiado tiempo.

En el caso de una LAN suele haber también diferentes tipos de medios de transmisión, de conectores e interfaces;

conviene estar familiarizado con los que vayamos a utilizar para adoptar en cada caso la solución más adecuada.

2.1.1.- TRANSMISIÓN DE DATOS: BASES TEÓRICAS

Módems y códecs

Cuando se envían datos por un canal de transmisión analógico (por ejemplo una línea telefónica de RTB) es

preciso modular la señal en origen y demodularla en el destino; el aparato que realiza esta función se llama

módem. Inversamente, cuando enviamos una señal analógica por un canal de transmisión digital tenemos que

codificarla en origen y decodificarla en destino, para lo cual se utiliza un aparato denominado códec; por ejemplo

un teléfono RDSI es un códec, ya que convierte una señal analógica (la voz humana) en digital, y viceversa; un

sistema de videoconferencia es un códec puesto que convierte una señal analógica (la imagen en movimiento

captada por la cámara) en una señal digital (la transmitida por RDSI u otro medio); también hay un códec en

cualquier sistema de grabación digital de sonido (CD, Minidisc, dcc, DAT). Es frecuente referirse a los códecs

como conversores analógico-digital o conversores A/D, aunque en telecomunicaciones suele preferirse la

denominación códec.

Para desempeñar su labor un códec debe muestrear periódicamente la onda a digitalizar, y convertir su amplitud

en una magnitud numérica. Por ejemplo los sistemas de grabación digital del sonido en CD muestrean la señal de

cada canal de audio 44 100 veces por segundo (44,1 KHz) y generan para cada muestra un número entero de 16

bits que representa la amplitud de la onda. En la decodificación se realiza el proceso inverso.

Teorema de Nyquist

Cualquier medio o canal de transmisión tiene un ancho de banda limitado. A continuación damos algunos

ejemplos:

Medio de transmisión Ancho de banda en KHz

Línea telefónica 3

Emisión de radio de onda media (AM) 4,5

Emisión de radio de FM 75

Emisión de televisión PAL 8 000

Red local Ethernet 10 000

Emisión de televisión de alta definición 30 000

Tabla 2.1: Ancho de banda de algunos medios de transmisión habituales.

Los bits se transmiten por un canal realizando modificaciones en la onda portadora; por ejemplo en una línea

telefónica podemos utilizar una frecuencia de 1 KHz para representar el 0 y una de 2 KHz para el 1; esto se

conoce como modulación de frecuencia; si sincronizamos dos equipos para que transmitan un cambio de

frecuencia de la portadora cada 3,333 milisegundos podremos transmitir datos a 300 bps, (si dos bits

consecutivos son iguales en realidad no hay tal cambio). Si en vez de dos frecuencias utilizamos cuatro, por

ejemplo 0,5, 1, 1,5 y 2 KHz, podremos transmitir con la misma sincronización 600 bps, ya que enviamos dos bits

cada vez al disponer de cuatro estados o niveles posibles; análogamente si utilizamos ocho estados podremos

transmitir 900 bps (tres bits por vez), y así sucesivamente; ganamos en velocidad, pero a cambio tenemos que ser

mas precisos en la frecuencia ya que el número de valores permitidos es mayor. Al número de cambios de estado

o sincronizaciones por segundo que tienen lugar en una comunicación entre dos equipos se le denomina baudios;

así en nuestro ejemplo anterior todas las transmisiones se hacían a 300 baudios, aunque el numero de bits que se

transmitía por segundo era diferente en cada caso. Además de la frecuencia es posible modular la amplitud y la

fase de la onda portadora; en la práctica los módems modernos modulan una compleja combinación de las tres

magnitudes para extraer el máximo provecho posible de las líneas telefónicas, es decir el máximo número de bps a

un número de baudios dado.

A pesar de todo el ingenio utilizado, los canales de transmisión tienen un límite. Ya en 1924 Nyquist observó la

existencia de un límite fundamental en las transmisiones digitales sobre canales analógicos, que se conoce como

teorema de Nyquist, y que establece que el número máximo de baudios que puede transmitirse por un canal no

puede ser superior al doble de su ancho de banda. Así en el caso de la transmisión de datos por una línea

telefónica, con un ancho de banda de 3 KHz, el máximo número de baudios que puede transmitirse es de 6.000.

Podemos comprender intuitivamente el teorema de Nyquist si imaginamos cual sería la frecuencia que tendría una

señal digital que transmitiera 6.000 baudios; supongamos por sencillez que 1 baudio = 1 bps, o sea que

manejamos únicamente dos estados, y que utilizamos una corriente de 1 voltio para indicar un bit a 1 y de -1

voltio para indicar un bit a 0; la frecuencia máxima se produciría cuando transmitieramos la secuencia 010101…

(ya que entonces la alternancia entre cresta y valle sería máxima). Obtendríamos entonces una onda cuadrada de 3

KHz de frecuencia (ya que cada dos bits forman una oscilación completa). Habríamos llegado a la misma

conclusión aplicando el teorema de Nyquist.

El teorema de Nyquist no fija un número máximo de bits por baudio, ya que esto depende del número de estados

que se utilicen. En nuestro ejemplo anterior si en vez de dos valores de voltaje utilizamos cuatro (-2, -1, 1 y 2

voltios) el número de baudios y de hertzios se mantiene constante mientras que se duplica el número de bits por

segundo. Podemos expresar el teorema de Nyquist también en forma de ecuación relacionándolo con la velocidad

máxima de transmisión, así si H es el ancho de banda y V el número de niveles o estados posibles, entonces la

velocidad máxima de transmisión C viene dada por:

C = 2 H log2 V

Por ejemplo, un canal telefónico (H=3 KHz) con tres bits por baudio (ocho estados, V=8) la máxima velocidad

de transmisión posible es 18 Kbps.

Debido a la relación directa que el teorema de Nyquist postula entre ancho de banda y velocidad de transmisión,

es frecuente en telemática considerar ambas expresiones como sinónimos; así decimos por ejemplo que la

transmisión de grandes ficheros necesita un elevado ancho de banda queriendo decir que requiere una elevada

velocidad de transmisión.

=========================== Revisón =======================

Podemos calcular también la eficiencia de un canal de comunicación, E, que es la relación entre la velocidad de

transmisión y el ancho de banda:

E = C/H

Así en nuestro ejemplo anterior la eficiencia era de 6 bits/Hz.

Combinando las dos fórmulas anteriores podemos expresar de otra forma el Teorema de Nyquist:

E = 2 log2 V

O dicho de otro modo, el número de baudios no puede ser mayor que el doble del ancho de banda.

El teorema de Nyquist es bidireccional, es decir, también se aplica al caso de transmisión de una señal analógica

por un canal digital. Por ejemplo, para que un teléfono RDSI (códec) pueda capturar la señal de audio sin mermar

la calidad respecto a una línea analógica el teorema de Nyquist establece que la frecuencia de muestreo deberá ser

como mínimo de 6,8 KHz (recordemos que la frecuencia máxima es de 3,4 KHz). En la práctica los teléfonos

digitales muestrean a 8 KHz para disponer de un cierto margen de seguridad. Los sistemas de grabación digital de

alta fidelidad, que muestrean a 44,1 KHz, son capaces de capturar sonidos de hasta 22 KHz lo cual excede la

capacidad del oído humano (en la práctica suelen filtrarse todas las frecuencias superiores a 20 KHz) . Cuando el

teorema de Nyquist se aplica en este sentido se le suele denominar teorema de muestreo de Nyquist.

Ley de Shannon-Hartley

El teorema de Nyquist supone la utilización de un canal de comunicación perfecto, es decir sin ruido. En la

realidad los canales tienen un ruido aleatorio, llamado también ruido térmico, que se mide por su valor relativo a

la señal principal, y se conoce como relación señal-ruido, S/R o S/N (signal-noise, ruido en inglés). El valor se

suele indicar en decibelios (dB), que equivalen a 10 log10 S/N (así 10 dB equivalen a una relación de 10, 20 dB a

una relación de 100 y 30 dB a una de 1000). Dado que la percepción de la intensidad del sonido por el oído

humano sigue una escala logarítmica la medida en decibelios da una idea más exacta de la impresión que

producirá un nivel de ruido determinado; este parámetro se utiliza por ejemplo para medir la calidad de los

componentes de una cadena musical de alta fidelidad. En 1948 Shannon y Hartley generalizaron el teorema de

Nyquist al caso de un canal de comunicación con ruido aleatorio, derivando lo que se conoce como la ley de

Shannon-Hartley, que está expresada en la siguiente ecuación:

C = H log2 (1 + S/N)

Por ejemplo, con un ancho de banda de 3 KHz y una relación señal-ruido de 30 dB (o sea 1000, valor

considerado bueno en el sistema telefónico analógico) obtenemos una velocidad de transmisión máxima de 29

902 bps. Si la relación señal-ruido desciende a 20 dB (valor bastante normal) la velocidad máxima baja a 19 963

bps.

Si lo expresamos en términos de eficiencia obtendremos:

E = log2 (1 + S/N)

Vista de este modo la Ley de Shannon-Hartley establece una eficiencia máxima para un valor dado de la relación

señal-ruido, independientemente de la frecuencia a la que trabaje el canal. así por ejemplo, para una relación

señal-ruido de 40 dB la eficiencia máxima teórica es de 13,3 bps/Hz. Los valores típicos de eficiencia suelen estar

entre 0,25 y 10 bps/Hz.

Conviene destacar que tanto el teorema de Nyqusit como la Ley de Shannon-Hartley han sido derivados en base a

planteamientos puramente teóricos y no son fruto de experimentos; por tanto su validez puede considerarse

universal y los contraejemplos deberían tratarse con el mismo escepticismo que las máquinas de movimiento

perpetuo. Haciendo un cierto paralelismo con la Termodinámica se podría decir que el Teorema de Nyquist

equivale al primer principio de la Termodinámica (que postula la ley de conservación de la energía) y la Ley de

Shannon-Hartley equivale al segundo principio, que establece que no es posible convertir totalmente en trabajo

útil la energía obtenida de una fuente de calor, por ejemplo en un motor.

2.2.- MEDIOS DE TRANSMISIÓN

El medio de transmisión, es probablemente la parte más crítica en el diseño de una red, especialmente cuando se

trata de una LAN. Mientras que el conjunto de protocolos a utilizar suele estar determinado de antemano por

factores externos , y tiene por tanto poco margen de maniobra, en el medio físico de transmisión se dan

generalmente varias posibilidades razonables; además las inversiones que se hacen en infraestructura suelen ser la

parte más importante de la red y la más difícil de modificar más adelante. Por otro lado, este es un campo que por

suerte o por desgracia evoluciona con mucha rapidez, y lo que hoy puede parecer adecuado quizá no lo sea

dentro de dos años; para tomar una decisión acertada es necesario hacer una estimación objetiva de las

necesidades actuales y futuras, y una valoración adecuada de las tecnologías disponibles tomando en cuenta su

relación costo/prestaciones.

Ahora profundizaremos en los diversos medios de transmisión utilizados actualmente. El alumno debe tener en

cuenta que este es un campo tan dinámico que para cuando termine sus estudios es probable que hayan surgido

nuevos sistemas de transmisión que aquí no hayamos ni mencionado. Afortunadamente existen multitud de

revistas de ámbito nacional e internacional que tratan con más o menos detalle de las novedades que se producen

en cuanto a medios de transmisión; los fabricantes de equipos suelen estar también bien informados de estos

temas, y su literatura es otra fuente de información.

2.2.1.- Pares de cobre

Este es el medio de transmisión mas común, consistente en un par de hilos de cobre aislados, de alrededor de 1

milímetro de diámetro. Un cable suele llevar varios hilos (típicamente 4 u 8) que normalmente están doblados dos

a dos formando una doble hélice, como una molécula de ADN, por lo que se le suele denominar cable de pares

trenzados (twisted pair). Esto se hace para minimizar la interferencia eléctrica que pueden recibir de fuentes

próximas, como por ejemplo los pares vecinos, y la que pueden emitir al exterior. Los cables pueden o no estar

apantallados.

Todo el sistema telefónico se basa en el uso de este tipo de medio de transmisión. Se utilizan tanto para

transmisión digital como analógica. El ancho de banda depende de múltiples factores, entre ellos el grosor del

cable, la distancia, el tipo de aislamiento, el grado de trenzado, etc. Pueden llegar a transmitir velocidades del

orden de Mbps a varios kilómetros. Hoy en día todos los sistemas de red local soportan este tipo de cable, que es

junto con la fibra óptica el más utilizado. Debido a sus características es de esperar que siga siendo popular

durante bastantes años.

Existen varias especificaciones de cables de cobre que difieren fundamentalmente en la frecuencia máxima a la

que pueden trabajar, que a su vez viene determinada principalmente por la densidad de vueltas y por el tipo de

material aislante que recubre los pares. Estas especificaciones se conocen como categorías y son las siguientes:

Categoría Frecuencia máxima (MHz) Usos Vueltas/metro

1 No se especifica Telefonía, datos a corta distancia y baja velocidad 0

2 1 LANs de baja velocidad (1 Mbps) 0

3 16 LANs hasta 10 Mbps 10-16

4 20 LANs hasta 16 Mbps 16-26

5 100 LANs hasta 100 Mbps, ATM a 155 Mbps 26-33

Tabla 2.2: Características principales de los cables según su categoría

Actualmente en instalaciones de datos nuevas se utiliza casi exclusivamente cable categoría 5 ya que el precio es

sólo ligeramente mayor y sus prestaciones son claramente superiores (téngase en cuenta que en el costo total de

una instalación el costo del cable es sólo una parte). Conviene mencionar que la clasificación en categorías,

además de aplicarse a un cable aislado se aplica a instalaciones ya hechas; a menudo sucede que una instalación

hecha con cable categoría 5 no puede funcionar a 100 MHz debido a que el operario no ha puesto suficiente

cuidado en la instalación: errores comunes son por ejemplo destrenzar una longitud excesiva en los conectores,

apretar demasiado las bridas o doblar excesivamente el cable es la falta (por ejemplo al soldar los conectores.

Normalmente los problemas de montaje sólo se pondrán de manifiesto al funcionar a 100 MHz, no a velocidades

inferiores.

En cada una de las categorías anteriores existen diferentes cables de acuerdo al tipo de apantallamiento que

llevan. El más habitual en redes locales es el que no lleva apantallamiento de ningún tipo (más allá del que

proporciona el hecho de llevar los pares trenzados); este se conoce como cable UTP (Unshielded Twisted Pair).

Existe también cable en el que los pares llevan una pantalla hecha de hilos de cobre formando una malla, y se

llama cable STP (Shielded Twisted Pair) ; este cable es bastante voluminoso debido a la pantalla, lo cual encarece

su precio y su costo de instalación, por lo que existe una variante más barata en la que la pantalla esta formada

por papel de aluminio en vez de por malla de cobre, con lo que se consigue reducir considerablemente el precio y

el diámetro (parámetro que determina el costo de instalación); a este cable se le conoce como FTP (Foil Twisted

Pair) o también ScTP (Screened Twisted Pair).

Existe una fuerte polémica sobre si es mejor utilizar en redes locales el cable sin apantallar (UTP) o apantallado

(STP o FTP), con argumentos en ambos sentidos. En grandes distancias se usa mas el cable apantallado ya que

tiene menor atenuación. Según los equipos de transmisión que se utilicen, la velocidad que puede obtenerse de un

par trenzado puede variar considerablemente, desde unos pocos Kbps hasta varios Mbps.

2.2.2.- Cable coaxial

El cable coaxial es otro medio de transmisión común. Tiene mejor apantallamiento que el par trenzado de

cualquier tipo y categoría, por lo que puede llegar a distancias y velocidades mayores. En transmisión de datos

suelen usarse dos tipos de cable coaxial: el de 50 ohmios y el de 75. El de 50 se utiliza en transmisión digital y se

suele denominar cable coaxial de banda base; el cable de 75 ohmios se utiliza en transmisión analógica y se

denomina cable coaxial de banda ancha; el término banda ancha tiene su origen en la transmisión telefónica,

donde se utiliza para indicar cualquier canal con una anchura mayor de 4 KHz.. Las instalaciones de televisión por

cable utilizan este tipo de cable y se suelen utilizar estas mismas redes para la transmisión de datos.

Un cable coaxial esta formado por un núcleo de cobre rodeado de un material aislante; el aislante está cubierto

por una pantalla de material conductor, que según el tipo de cable y su calidad puede estar formada por una o dos

mallas de cobre, un papel de aluminio, o ambos. Este material de pantalla está recubierto a su vez por otra capa

de material aislante.

Por su construcción el cable coaxial tiene una alta inmunidad frente al ruido, y puede llegar a tener unos anchos

de banda considerables. En distancias de hasta 1 Km es factible llegar a velocidades de 1 ó 2 Gbps. El cable

coaxial debe manipularse con cuidado ya que por ejemplo un golpe o doblez excesivo pueden producir una

deformación en la malla que reduzca el alcance del cable.

Los sistemas de LAN 'tradicionales' (Ethernet y Token Ring) utilizan cable coaxial de 50 ohmios. Las longitudes

máximas por ejemplo en el caso de Ethernet (10 Mbps) llegan a 500 metros. Actualmente puede utilizarse

también cable de par trenzado categoría 5.

2.2.3.- Fibras ópticas

Si hubiera que mencionar un único factor como el principal causante del elevado desarrollo que han tenido las

comunicaciones telemáticas en los años recientes, ese factor sería sin duda las fibras ópticas.

Recordemos que tanto el teorema de Nyquist como la ley de Shannon-Hartley basan sus restricciones en un

parámetro fundamental: la frecuencia de la onda portadora. Así pues, si queremos transmitir una señal digital por

ondas electromagnéticas a más velocidad deberemos subir la frecuencia; siguiendo por este camino llegamos a la

luz visible; sólo necesitamos tres elementos: un emisor, un medio de transmisión, y un detector. El emisor

transmite un bit por baudio, es decir, tiene dos estados posibles: un pulso de luz representa un 1 y la ausencia de

pulso un 0. El medio de transmisión es una fibra de vidrio ultrafina (su diámetro es de unas pocas micras). El

detector genera un pulso eléctrico cuando recibe luz. La transmisión por fibra óptica siempre es simplex; para

conseguir comunicación full-duplex es necesario instalar dos fibras, una para cada sentido, o trabajar a dos

frecuencias diferentes.

Para conseguir que la luz que sale del emisor sea 'capturada' por la fibra hasta su destino, y no se pierda por

difusión hacia el exterior se aprovecha una propiedad de las ondas conocida como reflexión, consistente en que

cuando una onda pasa de un medio a otro es parcialmente reflejada hacia el primero como si se tratara de un

espejo; la proporción en que la onda se refleja depende de los índices de refracción de ambos medios (una

propiedad física característica de cada material relacionada con la velocidad de la luz en ese medio) y del ángulo

de incidencia, a mayor ángulo mayor reflexión (el ángulo se mide referido a una línea perpendicular a la superficie

de separación de ambos medios); cuando la luz pasa de un medio con mayor índice de refracción a uno con

menor índice existe un ángulo de incidencia, conocido como ángulo límite, por encima del cual la luz se refleja

totalmente. Así, si el rayo de luz incide de forma suficientemente longitudinal en la fibra y cuando incide en el

borde supera el ángulo límite 'rebotará' y quedará 'atrapado' en la fibra, pudiendo así viajar grandes distancias sin

apenas pérdidas. Sería posible utilizar como medio de reflexión la superficie exterior de la fibra, aprovechando

que el aire tiene un menor índice de refracción que el vidrio, pero esto requeriría tener controlado el entorno

exterior para asegurar que la fibra siempre está rodeada de aire, lo cual es casi imposible; en su lugar lo que se

hace es utilizar dos fibras concéntricas, la interior con un índice de refracción mayor transporta la luz, y la

exterior actúa como 'jaula' para evitar que ésta escape.

Existen básicamente dos sistemas de transmisión de datos por fibras ópticas: los que utilizan LEDs

(Light-Emitting Diode) y los que utilizan diodos láser. En los sistemas que utilizan LEDs la transmisión de un

pulso de luz (equivalente a un bit) genera múltiples rayos de luz, pues se trata de luz normal no coherente; se dice

que cada uno de estos rayos tiene un modo y a la fibra que se utiliza para transmitir luz de emisores LED se la

denomina fibra multimodo. Las fibras se especifican indicando el diámetro de la fibra interior y exterior; las fibras

multimodo típicas son de 50/100 y 62,5/125 micras (diámetro interior de 62.5 micras y exterior de 125); a título

comparativo diremos que un cabello humano tiene un diámetro de 80 a 100 micras.

Los diodos láser emiten luz coherente, hay un único rayo y la fibra se comporta como un guía-ondas; la luz se

propaga a través de ella sin dispersión; la fibra utilizada para luz láser se denomina monomodo. Las fibras

monomodo se utilizan para transmitir a grandes velocidades y/o a grandes distancias. La fibra que transmite la luz

en una fibra monomodo es de un diámetro muy pequeño, de 8 a 10 micras (solo unas pocas veces la longitud de

onda de la luz que transmite); una fibra monomodo típica es la de 8,5/125 micras.

Para la transmisión de luz por fibras ópticas se utilizan tres rangos de frecuencias, aquellos en los que las fibras

muestran menor absorción (mayor 'transparencia'). Son bandas situadas alrededor de 0,85, 1,30 y 1,55 micras, y

se encuentran por tanto en la zona infrarroja del espectro; se conocen como primera, segunda y tercera ventana,

respectivamente. La primera ventana tiene mayor atenuación y es poco utilizada. La segunda ventana, que tiene

una anchura de 18 THz (THz = 1 TeraHertzio = 1000 GHz = 1012 Hz), es la que más se utiliza. La tercera

ventana tiene una anchura de 12,5 THz y es la que presenta menor atenuación y se utiliza en fibra monomodo

cuando se quiere cubrir una gran distancia sin repetidores (por ejemplo la fibra Valencia-Mallorca funciona

actualmente en tercera ventana sin repetidores). Suponiendo una eficiencia de 1 bps/Hz la segunda y tercera

ventanas suministrarían un ancho de banda de 30 Tbps!. El pico a 1,4 micras que separa ambas ventanas se debe a

la presencia de cantidades residuales de agua en el vidrio. Es de esperar que la continua mejora de las técnicas de

fabricación de fibras ópticas amplíe estas ventanas con lo que en el futuro se dispondrá de un ancho de banda aún

mayor. Para mejor aprovechar las fibras ópticas de largo alcance actualmente se utilizan dos longitudes de onda

por fibra en cada una de estas ventanas, mediante lo que se conoce como multiplexación por división en longitud

de onda en banda ancha (wideband WDM, Wavelength Division Multiplexing). Se están desarrollando prototipos

de WDM en banda estrecha, que permitirá extraer aún más ancho de banda de una sola fibra, pudiendo llegar a

compartir una misma fibra varias empresas portadoras. Probablemente WDM será el próximo hito en la carrera de

las nuevas tecnologías de transmisión de datos, marcada hoy por ATM y SONET/SDH.

Para la interconexión de fibras ópticas se utilizan tres sistemas. El primero emplea conectores, que ofrecen

máxima versatilidad pues pueden ser manipulados a voluntad por cualquier persona; sin embargo introducen una

pérdida de la señal de un 10% aproximadamente (0,5 dB). El segundo utiliza un empalme mecánico, que consiste

en unir y alinear los extremos con cuidado; pierde un 5% de señal (0,2 dB) y lo puede realizar en unos cinco

minutos una persona entrenada. El tercero es una fusión o soldadura de las dos fibras; en este caso la pérdida de

señal es muy pequeña, pero la unión ha de llevarla a cabo un técnico especializado con equipo altamente

sofisticado.

En una comunicación por fibra óptica el emisor transmite con una potencia determinada y el receptor tiene una

sensibilidad mínima para captar la señal de manera fiable. Dicha potencia y sensibilidad suelen medirse en una

unidad llamada dBm, que se calcula de la siguiente manera:

potencia (dBm) = 10 log (P)

donde P es la potencia del emisor en milivatios. Así, un emisor con una potencia de 1 milivatio equivale a 0 dBm,

con un microvatio a -30 dBm, y así sucesivamente.

Un emisor LED tiene una potencia típica entre -10 y -25 dBm, y uno láser entre 0 a -13 dBm. Por otro lado, la

potencia mínima que un receptor debe recibir para poder detectar la señal sin errores es de -20 a -35 dBm en

LEDs y de -20 a -45 dBm en láser.

Cuando una señal viaja por una fibra se produce una atenuación debido a los empalmes y conectores, y a la

absorción de la luz por la fibra; en segunda ventana esta pérdida es de aproximadamente 1 dB/Km en fibras

multimodo y de 0,4 dB/Km en fibras monomodo. Al valor así obtenido se debe añadir 1,5 dB debido a otros

factores que no detallaremos. Con estos datos y sabiendo la longitud de fibra y el número de conectores y

empalmes es posible calcular la pérdida de señal que se producirá en un trayecto determinado; si conocemos la

potencia del emisor y la sensibilidad del receptor podremos calcular la distancia máxima a la que la señal llegará

de manera fiable.

Por ejemplo, si utilizamos fibra multimodo, emisores LED de -15 dBm de potencia y receptores de sensibilidad

mínima de -25 dBm y tenemos dos parejas de conectores en el trayecto (0,5 dB cada una) podremos resistir una

pérdida de 7,5 dB en la fibra, equivalente a una distancia de 7,5 Km. Conviene mencionar que esta sería la

distancia máxima teórica; en la práctica se suele añadir un factor de seguridad a estos cálculos reduciendo los

valores al menos en un 30% para tomar en cuenta los efectos de cambios de temperatura, envejecimiento del

material, instalación mecánica incorrecta, etc.

Cuando se transmite un pulso por una fibra multimodo los rayos se reflejan múltiples veces antes de llegar a su

destino, con ángulos diversos (todos por encima del ángulo límite) lo cual hace que la longitud del trayecto

seguido por los rayos que forman el pulso no sea exactamente igual para todos ellos; esto produce un

ensanchamiento del pulso en su recepción, conocido como dispersión, que limita el ancho de banda utilizable, ya

que el emisor no puede enviar los pulsos con la rapidez que en principio podría; la dispersión es función de dos

factores: el ancho de banda y la longitud de la fibra, y se calcula como el producto de ambas magnitudes, así por

ejemplo una fibra de 2 Km que transmita a 155 Mbps (equivalente a 155 MHz) tendrá una dispersión de 310

MHz Km. Con las fibras, emisores y receptores actuales la dispersión máxima tolerable es de 500 MHz Km; por

ejemplo, si se transmite con fibras multimodo a 622 Mbps (que es la distancia máxima que suele utilizarse con

este tipo de fibras) la distancia máxima que puede utilizarse viene limitada a 800 metros por el efecto de

dispersión. A 155 Mbps esta distancia es de 3,2 Km, y a 100 Mbps de 5 Km. Volviendo al ejemplo de antes, la

distancia de 7,5 Km que en principio habíamos calculado como posible por la atenuación no podría funcionar a

velocidades superiores a 66 Mbps. Es fácil comprender por que en distancias grandes se utiliza fibra monomodo.

En ocasiones se habla con demasiada alegría de la capacidad de gigabits de las fibras ópticas; conviene destacar

que dicha afirmación solo es aplicable, al menos hoy en día, a las fibras monomodo. Actualmente se esta

trabajando en el desarrollo de pulsos con una forma especial de manera que los efectos de dispersión se cancelen

mutuamente. Estos pulsos se llaman solitones y son un campo muy activo de investigación.

A menudo los fabricantes dan cifras orientativas del alcance de sus equipos, como por ejemplo que la distancia

máxima en fibra multimodo es de 2 Km o en monomodo de 15 a 30 Km. Estos valores suelen ser muy

conservadores y no dar problemas, pero en casos que haya muchos conectores o empalmes, o que queramos

superar las distancias que da el fabricante, deberemos proceder a hacer los cálculos detallados para asegurarnos

que no superamos la atenuación máxima recomendable; para los cálculos deberemos conocer la potencia del

emisor y la sensibilidad del receptor.

En redes locales, donde las distancias no son muy grandes, se suele utilizar emisores LED y fibras multimodo, ya

que son mas baratos que los láser, tienen una vida mas larga, son menos sensibles a los cambios de temperatura y

son mas seguros. En cambio las compañías telefónicas, que normalmente necesitan largas distancias y altas

velocidades, utilizan casi exclusivamente emisores láser y fibras monomodo.

2.2.4.- Comparación de fibra óptica y cable de cobre

A menudo en el diseño del cableado de una red local es necesario elegir entre fibra óptica o cable de cobre, ya

que la mayoría de los sistemas de red local admiten el uso de ambos medios. En la mayoría de los casos las únicas

opciones que vale la pena considerar son el cableado de cobre UTP categoría 5 y la fibra óptica multimodo

62,5/125 (salvo que por distancia tuviéramos que usar fibra monomodo); el cable de cobre permite llegar a 155

Mbps hasta 100m y la fibra a 622 Mbps hasta 800 m, o 155 Mbps hasta 3 Km. Así pues, si la distancia a cubrir es

superior a 100 metros es preciso usar fibra. Además se recomienda utilizar fibra cuando se da alguna de las

siguientes circunstancias:

El cableado une edificios diferentes; en este caso el uso de cable de cobre podría causar problemas debido a

posibles diferencias de potencial entre las tierras de los edificios que podrían provocar corrientes inducidas en el

cable.

Se prevé pasar a velocidades superiores a 155 Mbps más adelante; si la distancia es superior a 500-800 metros se

debería además considerar la posibilidad de instalar fibra monomodo.

Se desea máxima seguridad en la red (el cobre es más fácil de interceptar que la fibra).

Se atraviesan ambientes que pueden resultar corrosivos para los metales

Se sospecha que puede haber problemas de interferencia eléctrica por proximidad de motores, luces fluorescentes,

o equipos de alta tensión (por ejemplo, equipos de laboratorio).

Para evaluar la necesidad o no de instalar fibra para evitar las interferencias producidas por la red eléctrica existe

una serie de recomendaciones sobre la distancia mínima a mantener que hemos recopilado en la Tabla 2.3.

Potencia (en KVA)

Menos de 2 Entre 2 y 5 Mas de 5

Líneas de corriente o equipos eléctricos no apantallados 13 cm 30 cm 60 cm

Líneas de corriente o equipos no apantallados pero próximos a cables de tierra 6 cm 15 cm 30 cm

Líneas apantalladas (p. ej. dentro de tubo metálico con toma de tierra) 0 cm 15 cm 30 cm

Transformadores y motores eléctricos 1 m 1 m 1 m

Luces fluorescentes 30 cm 30 cm 30 cm

Tabla 2.3: Separación mínima recomendada entre líneas de alimentación eléctrica y cables de datos UTP. Se

supone que la tensión en las líneas eléctricas es menor de 480 voltios.

Cuando no se requiere fibra es recomendable utilizar cobre, ya que es más barato el cable, la instalación y las

interfaces de conexión de los equipos; además es más fácil realizar modificaciones en los paneles de conexión,

empalmes, etc.

TEMA 3: EL NIVEL DE RED

6.1.- INTRODUCCIÓN

Objetivo: encaminar los paquetes del origen al destino.

Es la capa que conoce la topología de la red. Se implementa en dos tipos de nodos:

Hosts: generan o reciben paquetes de otro host, nunca encaminan paquetes destinados a o provenientes de otros

nodos. Se conocen también con los nombres de: ordenadores, nodos terminales (end node), DTEs (en

terminología X.25), o Sistemas Finales (End Systems, ES) en terminología ISO.

Routers, conmutadores o nodos de tránsito: se utilizan para encaminar paquetes entre hosts. También se les llama

nodos de tránsito (routing node), conmutadores o switches (en X.25, frame relay y ATM), o Sistemas

Intermedios (Intermediate Systems, IS) en ISO. Antiguamente en Internet a los routers se les llamaba gateways

(pasarelas). Hoy en día el nombre pasarela se reserva a niveles superiores, normalmente de aplicación. Los routers

suelen ser ordenadores especializados y dedicados, diseñados específicamente para esa función, con sistemas

operativos en tiempo real, aunque en ocasiones también se utilizan ordenadores normales como routers.

En ocasiones un router ha de intercambiar paquetes generados por él con otro nodo (router o host); en este caso

ambos nodos actúan como hosts.

Para su comunicación con el resto de la red los routers tienen normalmente varias interfaces físicas, y los hosts

normalmente una; aunque poco frecuente también es posible que un router tenga una sola interfaz, y que un host

tenga varias por razones de rendimiento o fiabilidad. Cuando un host tiene varias interfaces decimos que está

'multihomed'.

En cada interfaz física de un nodo funciona una instancia independiente del nivel físico y del nivel de enlace; por el

contrario el nivel de red es normalmente global para todo el nodo. En Internet cada interfaz física ha de tener

necesariamente una dirección de red diferente, al menos (puede tener varias).

Los routers junto con las líneas que los unen constituyen la subred (subred = frontera usuario-proveedor).

En las LANs, al ser el medio físico broadcast, todos los nodos comunican directamente entre sí, sin necesidad de

routers; por lo que la capa de red es prácticamente inexistente; a cambio el nivel de enlace es más complejo

(subcapa MAC).

Los puentes MAC, en especial los puentes por encaminamiento desde el origen, desempeñan una función hasta

cierto punto equivalente a la de un router.

La interfaz del nivel de red con el de transporte es la que utilizará el usuario (nivel de transporte) para acceder al

servicio.

Los servicios que ofrece el nivel de red deberán en lo posible aislar al nivel de transporte de detalles tales como

tipo de tecnología física (LAN, WAN, broadcast, etc.), número y topología de las subredes, etc.

Las direcciones de red que se presenten al nivel de transporte deberán tener un formato homogéneo, cualquiera

que sea el medio físico o subred utilizados.

Los servicios de red pueden ser orientados a conexión (CONS) o no orientados a conexión (CLNS).

En un servicio CLNS (p. ej. Internet o ISO CLNS):

Se implementan las primitivas SEND PACKET y RECEIVE PACKET, y poco más.

No se garantiza el orden de llegada de los datagramas.

Cada datagrama ha de llevar la dirección de destino. Cada uno ha de averiguar la ruta por sí mismo.

Cada router ha de mantener una tabla que indique por que interfaz debe encaminar los paquetes en función de su

destino, pero no conserva información de las conexiones (pues no las hay); se dice que el router no tiene estados

o que es 'stateless').

Si un router de la red queda fuera de servicio la única consecuencia será la pérdida de los datagramas que

estuvieran en proceso en el router en ese momento, no se pierde ninguna información sobre la conexión, ya que

no había conexión; los hosts intentarán buscar una ruta alternativa para comunicarse.

Es difícil llevar a cabo un control de congestión, u ofrecer una QoS (calidad de servicio).

En un servicio CONS (p. ej. ATM o X.25):

Las dos entidades establecen primero la conexión de forma explícita (un circuito virtual o VC) y le asignan un

identificador. Esta conexión se utiliza para enviar todos los datos y luego se libera, también de forma explícita.

El orden de entrega de los paquetes está garantizado.

Los paquetes no necesitan llevar la dirección de destino (pero sí el número del VC por el que van a viajar). La

ruta está marcada por el VC mientras éste está establecido. El router (o conmutador) ha de tomar nota de los

VCs existentes en cada momento (decimos que el conmutador tiene estados o que es 'statefull').

Cada conmutador ha de mantener una tabla que le indique la interfaz de entrada y de salida para cada VC que

pasa por él.

Si un conmutador queda fuera de servicio desaparecerán todos los VCs que pasen por él en ese momento, y los

hosts afectados dejarán de comunicar; la información de los VCs se perderá (salvo que se tratara de PVCs).

Es fácil efectuar un control de congestión, y también asegurar una QoS.

En una red CLNS el nivel de transporte es más complejo pues se ha de ocupar de mas funciones que en una

CONS. Normalmente el nivel de transporte en una red CLNS es CONS (p. ej.: IP es CLNS y TCP es CONS).

Generalmente una red CONS es fiable y una CLNS es no fiable (entendemos por no fiable que no garantiza la

entrega).

Apartados que veremos en este tema:

Algoritmos de routing: como elegir la ruta más adecuada.

Algoritmos de control de congestión: como resolver (o evitar) situaciones de saturación en la red.

Internetworking: como se conectan e interoperan diferentes redes entre sí

Capa de red en Internet

Capa de red en ATM

6.2.- ALGORITMOS DE ROUTING

Una función fundamental de la capa de red en los routers es decidir por que interfaz se manda el paquete recibido.

Con datagramas esto se hace para cada paquete; con VCs se hace sólo para cada nuevo circuito.

Un algoritmo de routing debe ser:

Correcto

Simple

Robusto

Estable

Justo

Óptimo

A menudo justo y óptimo son características contrapuestas.

Encaminamiento o routing estático: las rutas están basadas en información de la topología no obtenida en tiempo

real, sino previamente. Se fija cada posible ruta de antemano, según la capacidad de la línea, el tráfico esperado, u

otros criterios. No es posible responder a situaciones cambiantes (p. ej. saturación, exceso de tráfico o fallo de

una línea). Al realizar los cálculos offline es posible aplicar algoritmos muy sofisticados, aun cuando sean

costosos en el cálculo.

Encaminamiento o routing dinámico: las rutas se fijan en cada momento en función de información en tiempo real

que los routers reciben del estado de la red. Se utilizan algoritmos autoadaptativos y es preciso utilizar un

protocolo de routing que permita a los routers intercambiar información sobre el estado de la red. Los algoritmos

no pueden ser demasiado complejos pues han de implementarse en los routers y ejecutarse cada poco tiempo.

El principio de optimalidad

Si Castellón está en la ruta óptima de Valencia a Tarragona, entonces el camino óptimo de Castellón a Tarragona

está incluido en dicha ruta.

Una consecuencia de este principio es que todas las rutas óptimas para llegar a un punto determinado forman un

árbol con raíz en el punto de destino. El árbol no contiene bucles (decimos que es un spanning tree) y siempre es

posible llegar al punto de destino en un número finito de saltos ('hops').

Encaminamiento por el camino mas corto (estático y dinámico)

Para saber elegir el camino más corto primero debemos definir como medimos la distancia. La longitud de un

trayecto se mide como la suma de las longitudes de cada uno de los tramos, o enlaces que se atraviesan.

Generalmente la 'longitud' de un enlace se mide como una combinación de diversos factores, por ejemplo:

Velocidad del enlace (información estática)

Tráfico medio (puede ser información estática o dinámica)

Retardo (información dinámica medida enviando paquetes de prueba)

Costo (información estática especificada por el usuario)

El peso relativo que se da a cada uno de los factores que intervienen en el cálculo del costo de un trayecto se

denomina métrica. La métrica puede ser fijada o modificada al configurar el router.

Si se utiliza información invariable (velocidad del enlace o costo) este algoritmo puede aplicarse a un

encaminamiento estático.

Si se emplean parámetros dinámicos (tráfico medio, retardo) obtenidos en tiempo real el algoritmo puede

utilizarse para encaminamiento dinámico.

Existen diversos algoritmos que permiten calcular el camino más corto entre dos nodos de un grafo. Uno de los

mas conocidos es debido a Dijkstra.

Inundación, o flooding (estático)

Consiste en enviar cada paquete por todas las interfaces, excepto por la que se ha recibido.

Puede multiplicar el tráfico si existen bucles en la topología, ya que en ese caso se envían paquetes duplicados.

Para limitarlo se fija un número máximo de saltos para cada paquete igual al máximo de saltos que hay hasta

llegar al punto mas lejano de la red (decimos que ese número de saltos constituye el tamaño o diámetro de la red).

Otra posibilidad es que cada router mantenga una lista de paquetes enviados para evitar reenviarlos de nuevo (la

lista no necesita ser exhaustiva, puede decir por ejemplo 'para el destino X recibidos todos hasta el 1900, y

además 1912 y 1915'). Los paquetes han de estar numerados de manera no ambigua.

También puede usarse inundación selectiva: el paquete se envía sólo por las líneas que aproximadamente van en la

dirección correcta; por ejemplo si el paquete va hacia Córdoba se enviará por las líneas que van al sur solamente.

La inundación se utiliza en algunos algoritmos de routing multicast.

Encaminamiento basado en el flujo (normalmente estático)

Toma en cuenta la cantidad de tráfico medio que soportan las líneas, y en base a esta información intenta

optimizar el conjunto de las rutas para utilizar el camino menos congestionado en cada caso.

Se ha de conocer bastante bien el tráfico, y éste ha de ser muy regular; se pueden aplicar algoritmos relativamente

sofisticados ya que el cálculo de rutas se hace offline y se carga en el router después.

Encaminamiento por vector distancia (dinámico)

Fue el algoritmo original de ARPANET. Se usó en DECNET e IPX, y se usa en Appletalk. Se usa en el

protocolo RIP (Routing Information Protocol), que hasta 1988 era el único utilizado en Internet. También se

utiliza en los protocolos propietarios IGRP y EIGRP de Cisco, que es la marca más importante en routers IP, y

una de las más importantes en equipos de comunicaciones para redes de datos. También se conoce como

algoritmo de Bellman-Ford o Ford-Fulkerson, que son los autores de la idea.

Cada router mantiene una tabla (vector) que le indica la distancia mínima conocida para cada router destino y que

línea utilizar para llegar a él. La tabla se actualiza regularmente con información obtenida de los routers vecinos.

La distancia puede medirse en saltos, retardo, paquetes encolados, etc., o una combinación de estos u otros

parámetros. Para medir el retardo el router envía un paquete de prueba que debe ser respondido por el router

remoto (por ejemplo en IP se utilizan paquetes especiales denominados ECHO).

En routing con vector distancia las noticias buenas se propagan rápidamente, pero se reacciona lentamente a las

malas. Esto se conoce como el problema de la cuenta a infinito. Se han ideado multitud de trucos para resolver

este problema, pero cada solución propuesta introduce otros inconvenientes.

Encaminamiento por el estado del enlace

El encaminamiento basado en el estado del enlace tiene cinco fases:

1. Descubrir los routers vecinos y averiguar sus direcciones.

2. Medir el retardo o costo de llegar a cada vecino

3. Construir un paquete que resuma toda esta información

4. Enviar ese paquete a todos los routers

5. Calcular el camino mas corto a cada router

Para conocerse los routers al encenderse envían paquetes de presentación (HELLO) por todas sus interfaces; los

paquetes HELLO son respondidos con mensajes identificativos por los routers.

Para conocer el retardo los routers envían paquetes de prueba (p. ej. ECHO) que son respondidos por el router

remoto, y miden el tiempo de ida y vuelta. En ocasiones se toma en cuenta el tiempo en cola, y en ocasiones no.

Ambas opciones tienen sus ventajas e inconvenientes.

Con toda la información obtenida el router debe construir un paquete y enviarlo a todos los otros routers. Para

esto utiliza inundación. Los paquetes se numeran para detectar (y descartar) duplicados, e ignorar paquetes

obsoletos (si llega el paquete 26 después de haber recibido el 28 se descarta). Además cada paquete tiene una

vida limitada, al cabo de la cual es descartado.

Con toda la información obtenida el router conoce perfectamente la topología de la red, y puede calcular el

camino óptimo mediante el algoritmo de Dijkstra, por ejemplo.

Entre los protocolos dinámicos que utilizan routing por el estado del enlace destaca OSPF (Open Shortest Path

First) que es un protocolo de routing estándar de Internet. Otro protocolo de estado del enlace también utilizado

en la Internet es IS-IS (Intermediate System-Intermediate System). IS-IS es multiprotocolo, es decir, soporta

múltiples protocolos de red por encima. OSPF esta basado en IS-IS, pero no es multiprotocolo.

Encaminamiento jerárquico

Para ir en coche de Valencia a Milán utilizamos un mapa detallado de España e Italia, pero no necesitamos

normalmente uno detallado de Francia, nos basta con uno de carreteras principales de Europa.

A medida que una red crece la cantidad información de routing aumenta de forma exponencial con el tamaño de

la red, ya que cada router ha de calcular las rutas óptimas a todos los demás. Esto incrementa el tráfico, la

memoria en los routers, y la complejidad de los cálculos necesarios para obtener las rutas óptimas. Decimos que

los algoritmos de routing no escalan bien o no son escalables.

Para reducir este problema las redes se organizan en niveles jerárquicos; se divide la red en regiones, y sólo un

número reducido de routers de cada región (los routers interregionales) puede comunicar con el exterior. Las

rutas quizá no sean tan óptimas, pero se simplifica la gestión y el mantenimiento de las tablas de routing, y se

reduce el tráfico de gestión de la red.

En la práctica se suelen dar dos o más niveles jerárquicos de routing.

Se puede demostrar que el número óptimo de niveles para una red de N routers es ln N, con una tabla de e ln N

entradas en cada router. Por ejemplo para 150 routers lo óptimo serían 5 niveles, con 14 entradas por router.

Encaminamiento broadcast

En algunos casos se necesita enviar un paquete a todos los destinos posibles en una red, es decir se quiere hacer

un envío broadcast.

A veces esto se hace por inundación, ya que es especialmente apropiada en este caso. Sin embargo se pueden

producir bucles en la red.

Otro método es el routing multidestino. Se manda un único paquete con todas las direcciones a las que debe

enviarse, y en cada router se replica en aquellas interfaces donde esta justificado, es decir, las que son parte de la

mejor ruta para alguno de los destinos.

Otro algoritmo es construir el spanning tree correspondiente al origen, y seguirlo, replicando el paquete allí donde

haya una bifurcación. El spanning tree no tiene bucles. El sistema es óptimo, ya que se asegura que la distribución

se hará generando el número mínimo de paquetes y sin duplicados. Pero requiere que cada router conozca cuales

de sus interfaces forman parte del spanning tree para el router origen, y cuales no. Con routing del estado del

enlace los routers poseen esta información.

Por último el algoritmo de encaminamiento por el camino inverso intenta emular al spanning tree cuando la

información sobre la topología no está disponible. Consiste en lo siguiente: el router examina la dirección origen

del paquete recibido, y la interfaz por la que le ha llegado; si la interfaz es la vía habitual para esa dirección es

bastante probable que el paquete no sea un duplicado, por lo que lo reenviará por todas las interfaces excepto por

aquella por la que vino; si no es la interfaz habitual para esa dirección el paquete se descarta pues es muy probable

que sea un duplicado. Esta técnica evita que se produzcan bucles y consigue una eficiencia bastante buena,

aunque no tanto como el spanning tree ya que algunos paquetes no llegaran a su destino por la ruta óptima.

Encaminamiento multicast

Para el envío de paquetes multicast primero hay que crear el grupo multicast. Una vez creado diferentes usuarios

pueden unirse al grupo, o abandonarlo. Las tareas de gestión del grupo son en principio independientes del

routing multicast.

Cuando un usuario (o proceso que depende de un host conectado a un router), se une a un grupo multicast debe

informar a su router, y éste a sus vecinos.

Cada router que quiera emitir paquetes multicast ha de construir el spanning tree de toda la subred, colocándose

él como raíz. A continuación 'poda' el árbol (podar= to prune en inglés), dejando sólo las ramas necesarias para

hacer llegar los paquetes a los routers que forman parte del grupo multicast.

Si se utiliza routing por el estado del enlace cada router conoce la topología en detalle, por lo que puede proceder

a podar todo el árbol sin más, de abajo hacia arriba.

Con routing por vector distancia se puede utilizar encaminamiento por el camino inverso; cuando un router

detecta que ninguno de los hosts que dependen de él está interesado en la emisión envía un mensaje PRUNE por

la interfaz por la que recibe el tráfico multicast, para indicar al emisor que no desea recibir los paquetes multicast.

Cuando un router ha recibido mensajes PRUNE por todas sus interfaces menos por la que le está enviando

paquetes multicast, envía a su vez un mensaje PRUNE por ésta para que el emisor proceda a 'podar' la rama

correspondiente.

En vez de empezar enviando los paquetes a todos los routers e ir podando las ramas innecesarias también es

posible adoptar la postura inversa, donde los routers que deseen recibir tráfico multicast lo soliciten. El uso de

una u otra estrategia depende de si la audiencia va a ser 'densa' (es decir, va ha haber un porcentaje elevado de

'espectadores') o 'dispersa', (va a haber un porcentaje reducido).

6.3.- ALGORITMOS DE CONTROL DE CONGESTIÓN

Denominamos congestión a la circunstancia en la que el rendimiento de la red (o una parte de ella) se degrada

debido a la presencia de demasiados paquetes.

La congestión es un problema global, que se da en el nivel de red como consecuencia del tráfico agregado de

varias fuentes sobre un enlace o router de baja capacidad.

Por el contrario el control de flujo es una circunstancia que solo puede darse en conexiones punto a punto (es

decir, a nivel de enlace o a nivel de transporte).

Tanto en congestión como en control de flujo suelen utilizarse mecanismos de notificación al emisor para que

baje el ritmo. La congestión es más compleja, ya que generalmente el emisor no es el verdadero causante del

problema, y se limita a reenviar hacia atrás el aviso recibido; entretanto seguirán llegando irremediablemente

paquetes que agravarán la situación. En líneas de alta velocidad y elevado retardo (gran distancia) este problema

se acentúa.

En muchos casos la solución a un problema de congestión se traduce en un control de flujo en el host que genera

el tráfico.

Normalmente la congestión se produce porque pretende pasar más tráfico por una línea de lo que ésta es capaz de

absorber. Por ejemplo un router recibe mucho tráfico de varias líneas de 2 Mbps todo dirigido a una sola línea

también de 2 Mbps. Generalmente el cuello de botella es la línea de transmisión, pero en algunos casos la

congestión puede ser causada por el propio router (CPU lenta).

Inicialmente los buffers intentan salvar la situación, pero si la situación dura bastante los buffers se llenan y los

routers empiezan a descartar paquetes.

A menudo cuando se produce congestión en un router el problema crece y se propaga con rapidez a otros routers

vecinos (algo parecido a un atasco de tráfico), pudiendo llegar a ser un problema en toda la red.

Principios generales del control de congestión

Para el control de la congestión caben dos planteamientos:

Diseñar las cosas de entrada para que la congestión no pueda llegar a ocurrir.

Tomar medidas que permitan detectar la congestión y adoptar medidas correctoras en su caso.

Entre los parámetros que permiten detectar la presencia de congestión se encuentran por ejemplo:

Porcentaje de paquetes descartados

Longitud media de las colas en las interfaces

Número de paquetes que dan timeout y se retransmiten (se supone que esto no se debe a errores)

Retardo medio por paquete

Desviación media del retardo por paquete

Para informar sobre situaciones de congestión el receptor pueden utilizar paquetes de alerta, o incluir la

información en un campo especial de los paquetes de datos que devuelve (aviso 'piggybacked'). También puede el

emisor enviar paquetes para sondear el estado de la red.

Es preciso llegar a un compromiso, ya que si se es demasiado conservador se puede desaprovechar la capacidad

de la red; por el contrario, si se es muy atrevido se puede llegar a situaciones de congestión de las que sea difícil

salir. En general suele ser preferible pasarse de conservador.

Para resolver la congestión solo hay dos posibles medidas:

Reducir el tráfico informando al emisor o buscando rutas alternativas.

Aumentar la capacidad (por ejemplo activando canales RDSI).

Sistemas o políticas ('policies') de prevención de congestión

Entre los factores a nivel de enlace que pueden influir en el nivel de congestión se encuentran:

El intervalo de timeout; si es pequeño originará retransmisiones innecesarias

El tamaño de ventana; si es grande es más fácil que se produzca congestión

El uso de retroceso n o repetición selectiva; el retroceso n genera más tráfico

El uso o no de ACK piggybacked; si no se usa se genera más tráfico

En el nivel de red son los siguientes:

Uso de circuitos virtuales o datagramas (hay mejor control cuando se trata de circuitos virtuales).

Mecanismo de encolamiento y criterios de selección (prioridades)

Mecanismo de descarte de paquetes (hay paquetes marcados como imprescindibles?)

Algoritmo de routing (es posible evitar una zona congestionada?)

Vida media de los paquetes (si duran demasiado poco tendrán que ser retransmitidos, si demasiado terminarán

siendo inútiles)

En el nivel de transporte se dan básicamente los mismos factores que en el nivel de enlace; la principal diferencia

es que la estimación del timeout adecuado es mucho más difícil al no ser una comunicación entre entidades

vecinas.

Perfiles de tráfico y vigilancia del tráfico ('traffic shaping' y 'traffic policing')

El tráfico a ráfagas es la principal causa de congestión. Si todos los ordenadores transmitieran siempre un flujo

constante sería muy fácil evitar las congestiones.

Los perfiles de tráfico (traffic shaping) establecen unos márgenes máximos al tráfico a ráfagas. Suelen utilizarse

para fijar una QoS entre el operador y el usuario; entretanto el usuario respete lo establecido el operador se

compromete a no descartar paquetes (actúa como una especie de contrato de QoS).

Se denomina vigilancia del tráfico (traffic policing) a la labor de monitorización o seguimiento del tráfico

introducido por el usuario en la red para verificar que no excede el perfil pactado.

Uno de los sistemas utilizados para establecer perfiles de tráfico es el conocido como algoritmo del pozal

agujereado (leaky bucket): el host puede enviar ráfagas que son almacenadas en un buffer de la interfaz, la cual

envía a la red un caudal constante; si la ráfaga es de tal intensidad o duración que el buffer (pozal) se llena, los

paquetes excedentes son descartados. Para definir un pozal agujereado se utilizan dos parámetros, el caudal r con

que sale el flujo a la red, y la capacidad del buffer C.

Por ejemplo supongamos que con r=2 MB/s y C= 1 MB un ordenador envía una ráfaga de 1MB en 40 mseg

(equivalente a 25 MB/s); la ráfaga tardará en enviarse 500 mseg; si el ordenador envía otra ráfaga de 1 MB

durante esos 500 mseg el buffer se llenará y se perderán datos.

El pozal agujereado suprime completamente las ráfagas en la red. A veces interesa algo más de flexibilidad; en

esos casos se utiliza el algoritmo del pozal con créditos (token bucket). Podemos considerarlo como una versión

mejorada del pozal agujereado: cuando el host no envía datos a la interfaz ésta va sumando créditos (tokens)

hasta un máximo igual a la capacidad del buffer (el cubo); los créditos acumulados pueden utilizarse después para

enviar ráfagas con un caudal M mayor de lo normal; cuando se agotan los créditos el caudal vuelve a su valor

normal r, como en el caso del pozal agujereado. Los parámetros que definen un pozal con vale son r, la capacidad

del buffer C y el caudal máximo permitido M (normalmente igual a la velocidad de la interfaz física).

Supongamos que r=2 MB/s, C= 1 MB y M = 25 MB/s. Siguiendo con el ejemplo anterior, si el buffer está lleno

de créditos cuando llega la ráfaga ésta será enviada a la red a 25 MB/s, o sea a la misma velocidad que la envía el

host. Si el buffer está solo medio lleno (500 KB de créditos) se producirá una ráfaga de 25 MB/s durante 22 mseg

y seguirá un caudal de 2 MB/s durante 228 mseg (hay que tomar en cuenta que durante la ráfaga siguen llegando

créditos, pero no después ya que se van consumiendo a medida que llegan). Por último, si no hubiera créditos

disponibles el comportamiento sería idéntico al del pozal agujereado.

En ocasiones se combina un pozal con créditos seguido de un pozal agujereado de r mayor; con lo que se

permiten ráfagas pero de forma controlada.

Especificaciones de flujo

Se conocen con este nombre el conjunto de parámetros que especifican el caudal y calidad de servicio esperados

en una transferencia de datos entre dos entidades, para poder realizar de forma eficiente el perfil de tráfico y la

vigilancia de éste.

Algunos de estos parámetros son los siguientes:

Máximo tamaño de paquete

r y C si se utiliza pozal agujereado

r, C y M si se utiliza pozal con vale

Tasa de pérdidas (p. ej. 1 byte/hora)

Cantidad máxima de paquetes consecutivos que pueden descartarse.

Retardo máximo (p. ej. 100 mseg)

Variación máxima en el retardo, o jitter (p. ej. 10 mseg, equivalente a retardo ± 5 ms).

Control de admisión (redes de circuitos virtuales)

El control de admisión consiste en impedir el establecimiento de nuevos VC que pasen por la zona congestionada.

Si para cada VC se conoce la capacidad que necesita es posible controlar el acceso de forma que nunca se

produzca congestión. En general esta técnica no usa los recursos de manera eficiente, por lo que es normal prever

un cierto grado de sobresuscripción, u overbooking.

Paquetes de asfixia ('choke packets')

Se puede aplicar tanto en redes de VC como de datagramas.

El router sigue de cerca la situación de cada una de sus líneas, monitorizando por ejemplo el grado de utilización,

la longitud de la cola o la ocupación del buffer correspondiente. Cuando el parámetro inspeccionado supera un

determinado valor considerado peligroso se envía un paquete de asfixia ('choke' packet) al host considerado

'culpable' para que reduzca el ritmo.

La evaluación del parámetro a monitorizar se suele hacer con una fórmula del tipo:

unuevo = auviejo + (1-a) f

donde f es el valor instantáneo medido del parámetro (utilización, tamaño de la cola u ocupación del buffer), u el

valor medio, y a una constante que permite regular el peso que se le quiere dar a los valores anteriores, o dicho de

otro modo con que rapidez se quiere reaccionar a las situaciones nuevas.

Los paquetes de asfixia se envían al host, ya que es éste y no el router el verdadero origen de la congestión. Los

hosts cuando reciben estos paquetes suelen reducir a la mitad la velocidad con la que envían datos a la red. Esto

lo pueden hacer reduciendo por ejemplo el tamaño de ventana (del protocolo a nivel de transporte) o cambiando

los parámetros del pozal agujereado o pozal con vale, si utilizan alguno de estos algoritmos para controlar su

flujo. En una situación de congestión normalmente serán muchos los hosts que recibirán este tipo de paquetes.

En ocasiones interesa que los paquetes de asfixia tengan un efecto inmediato en cada uno de los routers que

atraviesan en su camino hacia el host origen del tráfico; esto ocurre sobre todo cuando la conexión es de alta

velocidad y el retardo grande (gran distancia por ejemplo). En esencia se trata de resolver la congestión de forma

inmediata distribuyendo el tráfico en curso entre los buffers de los routers que hay por el camino, mientras el

mensaje de alerta llega al verdadero causante de los problemas.

Por desgracia la obediencia a los paquetes de asfixia es completamente voluntaria; si un host decide hacer caso

omiso de las advertencias no se le puede obligar. Si un host reduce su ritmo mientras otros no lo hacen el primero

saldrá perjudicado pues obtendrá una parte aún menor del ya escaso ancho de banda.

Así pues, en situaciones de saturación se plantea el problema de como repartir el ancho de banda de forma justa

entre los usuarios. Existen varios mecanismos que intentan resolver este problema:

Encolamiento justo (fair queuing): el router mantiene una cola independiente por cada host y envía los paquetes

en turno rotatorio ('round robin'); el problema es que los usuarios con paquetes grandes obtienen mas ancho de

banda. Una versión mejorada investiga el tamaño de los paquetes para hacer un reparto homogéneo en número de

bytes transmitidos por host.

Encolamiento justo ponderado (weighted fair queuing): permite establecer prioridades, ya que en ocasiones

interesa dar mas prioridad a algunas maquinas (por ejemplo servidores) o a algunos servicios (aplicaciones

interactivas, por ejemplo). La prioridad se puede establecer por direcciones o por tipo de servicio (por ejemplo

más prioridad a los servicios interactivos).

Derramamiento de la carga

La solución extrema para resolver la congestión es descartar paquetes. En ocasiones los paquetes llevan alguna

indicación de su grado de importancia, en cuyo caso los routers intentan descartar los menos importantes

primero. Por ejemplo, sería bastante grave si un router para resolver una situación de congestión descartara

paquetes de asfixia enviados por otro router.

A veces el nivel de aplicación puede dar información sobre la prioridad de descarte de los paquetes. Por ejemplo

en cualquier aplicación con tráfico isócrono suele ser preferible descartar el paquete viejo al nuevo ya que el viejo

seguramente es inútil, mientras que en transferencia de ficheros es al contrario pues en muchos casos el receptor

no aceptará el paquete nuevo mientras no reciba el viejo (retroceso n). En los ficheros MPEG (formato estándar

de vídeo digital) algunos fotogramas son completos y otros son diferencias respecto a los fotogramas contiguos;

descartar un paquete de un fotograma completo es mas perjudicial. En todos estos casos es preciso que el nivel

de transporte identifique claramente los paquetes poco importantes para que los routers sepan descartarlos de

manera selectiva en caso necesario.

En algunos casos el paquete a nivel de red se utiliza para encapsular otros de mayor tamaño del nivel de

transporte, por lo que si se descarta un paquete de la secuencia se tendrán que reenviar todos los demás; en este

caso se pueden descartar todos los paquetes del mismo grupo pues su envío será inútil de todos modos. Por

ejemplo cuando se utiliza una red ATM para transportar tráfico TCP/IP las celdas transportan encapsulados

datagramas IP que pueden llegar a ser de 9180 bytes, por lo que un paquete se traduce en unas 190 celdas ATM.

Si por congestión se descarta alguna celda de un datagrama IP no tiene sentido enviar las demás celdas del mismo

datagrama. Algunos conmutadores ATM implementan técnicas conocidas como Early Packet Discard y Partial

Packet Discard que permiten al conmutador realizar ese descarte inteligente.

Control del jitter

En aplicaciones isócronas (audio y vídeo) la fluctuación en el retardo o jitter, es tan importante o más que el

retardo mismo.

Para intentar minimizar el jitter en la red es preciso que cada router analice si el paquete va adelantado o atrasado

respecto a su 'horario' normal; si va adelantado lo pondrá al final de su cola, y si va atrasado lo pondrá al

principio. De esta forma se reduce el jitter para todos los paquetes.

Control de congestión para tráfico multicast

Hasta ahora hemos supuesto que todo el tráfico tenía un único destino, es decir era tráfico unicast. Existen como

ya hemos visto algoritmos de routing específicos para tráfico multicast y broadcast. Recientemente se ha

investigado bastante todo lo relativo al tráfico multicast, ya que es se prevé un gran aumento de tráfico de este en

aplicaciones de vídeoconferencia o vídeo casi bajo demanda. Muchas de las aplicaciones que envían tráfico

multicast son isócronas, por lo que tienen unos requerimientos severos en el retardo y el jitter, y por tanto

soportan mal la congestión.

Generalmente se considera necesario que los usuarios puedan incorporarse o abandonar un grupo multicast sin

necesidad de reserva o planificación previas. Imaginemos por ejemplo un servicio de televisión digital en el que

los usuarios van haciendo continuamente 'zapping' de un canal a otro; en un momento dado los usuarios que estén

viendo el mismo canal forman un grupo multicast, pero el grupo puede cambiar con bastante rapidez.

El protocolo RSVP (Resource reSerVation Protocol) permite manejar estas situaciones, evitando la congestión.

Para funcionar requiere construir el spanning tree correspondiente al grupo multicast (lo cual no es misión de

RSVP sino del algoritmo de routing). Una vez construido el árbol uno cualquiera de los receptores envía un

mensaje de reserva hacia el emisor empleando el encaminamiento del camino inverso que hemos visto al hablar de

routing broadcast. Cada router por el que pasa el paquete de reserva toma nota del ancho de banda solicitado y lo

asigna, o bien devuelve un mensaje de error si no hay capacidad disponible. Si todo va bien al final del proceso el

receptor ha reservado el ancho de banda necesario en todo el camino.

Cuando a continuación otro receptor envía su mensaje de reserva ésta solo se efectuará en aquella parte del

trayecto que no sea común con el primer receptor y no haya sido por tanto ya reservada por éste. De esta forma

se asegura un uso óptimo de las líneas a la vez que se evita por completo la congestión (suponiendo que RSVP

no realiza sobresuscripción).

RSVP es actualmente un estándar Internet, y existen ya routers comerciales que lo implementan. Las primeras

pruebas de uso de RSVP para servicio comerciales de televisión interactiva se han llevado a cabo a finales de

1996.

Es interesante observar que, aunque se trate de un estándar Internet, RSVP tiene más parecido con un protocolo

CONS que con un CLNS, ya que los routers tienen que guardar una cierta información de la conexión activa,

algo equivalente a lo que sería un VC; dicho de otro modo, ya no son 'stateless' sino 'statefull'.

6.4.- LA CAPA DE RED EN LA INTERNET

La Internet es un compendio de redes diferentes que comparten un protocolo, o pila de protocolos comunes (IP a

nivel de red y sobre todo TCP a nivel de transporte); cada una de estas redes es administrada por una entidad

diferente: universidades, redes académicas nacionales, proveedores comerciales , operadores, multinacionales,

etc. Como consecuencia de esto las políticas de uso son muy variadas.

Técnicamente a nivel de red la Internet puede definirse como un conjunto de sistemas autónomos conectados

entre sí que utilizan el protocolo de red IP.

IP es una red de datagramas, no orientada a conexión, con calidad de servicio 'best effort', es decir, no hay QoS,

no se garantiza la entrega de los paquetes ya que en momentos de congestión éstos pueden ser descartados sin

previo aviso por los routers que se encuentren en el trayecto.

El protocolo IP

Toda información en una red IP ha de viajar en datagramas IP. Esto incluye tanto las TPDUs (Transport Protocol

Data Units) de TCP y UDP, como cualquier información de routing que se intercambie en la red (paquetes

ECHO, HELLO, PRUNE; de asfixia, etc.).

El tamaño de un datagrama IP se especifica en un campo de dos bytes, por lo que su valor máximo es de 65535

bytes, pero muy pocas redes admiten este valor. Normalmente el nivel de enlace no fragmenta, por lo que cada

paquete viaja en una trama; por tanto el tamaño máximo de paquete viene determinado por el tamaño máximo de

trama característico de la red utilizada. El tamaño máximo de paquete de una red se conoce como MTU

(Maximum Transfer Unit).; a continuación damos algunos ejemplos de valores de MTU característicos de las

redes más habituales:

Protocolo a nivel de enlace MTU

PPP (valor por defecto) 1500

PPP (bajo retardo) 296

SLIP 1006 (límite original)

X.25 1600 (varía según las redes)

Frame relay al menos 1600 normalmente

SMDS 9235

Ethernet version 2 1500

IEEE 802.3/802.2 1492

IEEE 802.4/802.2 8166

Token Ring IBM 16 Mb 17914 máximo

IEEE 802.5/802.2 4 Mb 4464 máximo

FDDI 4352

Hyperchannel 65535

ATM 9180

Es bastante normal utilizar 1500 como valor de MTU. Cualquier red debe soportar como mínimo un MTU de 68

bytes.

El datagrama tiene dos partes: cabecera y texto; la cabecera tiene una parte fija de 20 bytes y una opcional de

entre 0 y 40 bytes (siempre múltiplo de 4).La parte fija de la cabecera tiene la siguiente estructura:

Campo Longitud (bits)

Versión 4

IHL (Internet Header Length) 4

Tipo de servicio 8

Longitud total 16

Identificación 16

Reservado 1

DF (Don't Fragment 1

MF (More Fragments) 1

Fragment offset 13

TTL (Time To Live) 8

Protocolo 8

Checksum de cabecera 16

Dirección de origen 32

Dirección de destino 32

Opciones 0-320

El campo versión permite que coexistan en la misma red sin ambigüedad paquetes de distintas versiones; la

versión actualmente utilizada de IP (que corrresponde a la estructura de datagrama que estamos estudiando) es la

4. Como veremos mas tarde se empieza a extender el uso de una nueva versión, la 6, con una estructura de

datagrama diferente.

El campo IHL especifica la longitud de la cabecera, en palabras de 32 bits, ya que ésta puede variar debido a la

presencia de campos opcionales. Se especifica en palabras de 32 bits. La longitud mínima es 5 y la máxima 15,

que equivale a 40 bytes de información opcional. La longitud de la cabecera siempre ha de ser un número entero

de palabras de 32 bits, por lo que si la longitud de los campos opcionales no es un múltiplo exacto de 32 bits se

utiliza un campo de relleno al final de la cabecera.

El campo tipo de servicio se compone de dos subcampos: la prioridad (denominada precedencia) y el tipo de

servicio (TOS). Los primeros tres bits permiten especificar una prioridad entre 0 y 7 para cada datagrama,

pudiendo así marcar los paquetes normales con prioridad 0 y los importantes (por ejemplo paquetes de asfixia)

con prioridad 7. La prioridad actúa alterando el orden de los paquetes en cola en los routers, pero no modifica la

ruta de éstos. Dada la actual abundancia de ordenadores personales y estaciones de trabajo gestionadas por el

usuario final, existe un gran debate sobre si es conveniente la existencia de un campo prioridad, ya que el usuario

podría descubrir que obtiene mejor servicio con alta prioridad y utilizar sistemáticamente el valor 7 para todo tipo

de paquetes; en la práctica muchos equipos ignoran este campo y cuando hacen uso de el es únicamente dentro de

la red (es decir, entre routers). Los cuatro bits siguientes actúan como flags denominados D, T, R y C

respectivamente. El primero indica que se desea un servicio de bajo retardo (D=Delay); el segundo que se quiere

elevado rendimiento (T=Throughput), el tercero que se quiere una elevada fiabilidad (R=Reliability), y el cuarto

que se quiere un bajo costo (C=Cost). Las combinaciones válidas del subcampo TOS son las siguientes:

Valor TOS Descripción

0000 Valor por defecto

0001 Mínimo costo económico

0010 Máxima fiabilidad

0100 Máximo rendimiento

1000 Mínimo retardo

1111 Máxima seguridad

Para cada aplicación existe un valor de TOS recomendado. Por ejemplo, para telnet y logon remoto se

recomienda 1000 (mínimo retardo), para FTP 0100 (máximo rendimiento) y para NNTP (news) 0001 (mínimo

costo económico).

Algunos routers utilizan el subcampo TOS para encaminar los paquetes por la ruta óptima en función del valor

especificado; también pueden utilizarlo para tomar decisiones sobre que paquetes descartar en situaciones de

congestión. Algunos routers simplemente ignoran este subcampo.

El campo longitud total especifica la longitud del datagrama completo (cabecera incluida) en bytes. El valor

máximo es 65535 bytes.

El campo identificación lo usa el emisor para marcar en origen cada datagrama emitido, y permite al receptor

reconocer las partes correspondientes en caso de que se haya producido fragmentación por el camino.

El bit DF (Don't Fragment) cuando está a 1 indica a los routers que no fragmenten el paquete, ya que el receptor

no está capacitado para reensamblarlo. Por ejemplo, si un ordenador arranca su sistema operativo a través de la

red solicitará que el ejecutable correspondiente se le envíe desde algún servidor a través de la red como un único

datagrama. Si un datagrama con el bit DF puesto no puede pasar por una red el router lo rechazará con un

mensaje de error al emisor. Existe una técnica para averiguar el MTU de una ruta (denominada 'path MTU

discovery') que consiste en enviar un datagrama grande con el bit DF puesto al destino deseado; si se recibe un

mensaje de error se envía otro mas pequeño, hasta que el emisor averigua a base de tanteos cual es el valor de

MTU de la ruta correspondiente, y a partir de ahí puede utilizarla para todos los datagramas (siempre que la ruta

no cambie sobre la marcha).

El bit MF (More Fragments) a 1 especifica que este datagrama es realmente un fragmento de un datagrama

mayor, y que no es el último. Si está a 0 indica que este es el último fragmento (o bien que el datagrama original

no esta fragmentado).

El campo fragment offset sirve para indicar, en el caso de que el datagrama sea un fragmento de un datagrama

mayor, en que posición del datagrama mayor empieza este fragmento. Los cortes siempre se realizan en frontera

múltiplo de 8 bytes (la unidad elemental de fragmentación), por lo que este campo en realidad cuenta los bytes de

8 en 8. Al ser su longitud de 13 bits el número máximo de fragmentos es de 8192, que da cabida a la longitud

máxima de un datagrama (8192 x 8 = 65536). Los fragmentos pueden llegar desordenados, por lo que el último

fragmento puede llegar al receptor sin que haya recibido aun todos los fragmentos; la información fragment offset

junto con longitud del último fragmento (bit MF a 0) le permite al receptor calcular la longitud total del

datagrama original.

El campo TTL (Time To Live) permite descartar un datagrama cuando ha pasado un tiempo excesivo viajando

por la red y es presumiblemente inútil. En el diseño original se pretendía que el valor de este campo (que

inicialmente podía valer por ejemplo 64) se decrementara en cada router en un valor igual al tiempo en segundos

que el paquete había empleado en esa parte del trayecto, restando como mínimo 1 en cualquier caso. En la

práctica medir tiempos en una red es mucho más difícil de lo que parece (los relojes de los routers han de estar

muy bien sincronizados), por lo que todas las implementaciones se limitan sencillamente a restar 1 al valor de

TTL de cada paquete que pasa por ellos, sin analizar el tiempo que el paquete ha invertido en el salto. Como de

cualquier forma hoy en día es muy raro que un paquete tarde más de un segundo en cada salto esto es

aproximadamente conforme con el diseño original. El valor inicial de TTL de un paquete fija el número máximo

de saltos que podrá dar, y por tanto debería ser suficientemente grande como para que pueda llegar a su destino.

El TTL evita que por algún problema de rutas se produzcan bucles y un datagrama pueda permanecer 'flotando'

indefinidamente en la red.

El campo protocolo especifica a que protocolo del nivel de transporte corresponde el datagrama. La tabla de

protocolos válidos y sus correspondientes números son controlados por el IANA (Internet Assigned Number

Authority) y se especifican (junto con muchas otras tablas de números) en un RFC muy especial, denominado

'Assigned Numbers', que se actualiza regularmente; el vigente actualmente es el RFC 1700. Algunos de los

posibles valores del campo protocolo son los siguientes:

Valor Protocolo Descripción

0 Reservado

1 ICMP Internet Control Message Protocol

2 IGMP Internet Group Management Protocol

3 GGP Gateway-to-Gateway Protocol

4 IP IP en IP (encapsulado)

5 ST Stream

6 TCP Transmission Control Protocol

8 EGP Exterior Gateway Protocol

17 UDP User Datagram Protocol

29 ISO-TP4 ISO Transport Protocol Clase 4

38 IDRP-CMTP IDRP Control Message Transport Protocol

80 ISO-IP ISO Internet Protocol (CLNP)

88 IGRP Internet Gateway Routing Protocol (Cisco)

89 OSPF Open Shortest Path First

255 Reservado

El campo checksum sirve para detectar errores producidos en la cabecera del datagrama; no es un CRC sino el

complemento a uno en 16 bits de la suma complemento a uno de toda la cabecera (incluidos los campos

opcionales si los hubiera), tomada en campos de 16 bits; para el cálculo el campo checksum se pone a ceros. Este

campo permite salvaguardar a la red de un router que alterara los campos de cabecera de un datagrama, por

ejemplo por un problema hardware. El campo checksum se ha de recalcular en cada salto, ya que al menos el

TTL cambia. Esto supone un serio inconveniente desde el punto de vista de rendimiento en routers con mucho

tráfico.

Los campos dirección de origen y dirección de destino corresponden a direcciones IP según el formato que

veremos luego.

Los campos opcionales de la cabecera no siempre están soportados en los routers y se utilizan muy raramente; de

estos podemos destacar los siguientes:

Record route: Esta opción pide a cada router por el que pasa este datagrama que anote en la cabecera su

dirección, con lo que se dispone de una traza de la ruta seguida para fines de prueba o diagnóstico de problemas.

Debido a la limitación en la longitud de la cabecera como máximo pueden registrarse 9 direcciones, lo cual es

insuficiente en algunos casos.

Source routing: permite al emisor especificar la ruta que debe seguir el datagrama hasta llegar a su destino.

Existen dos variantes: strict source routing permite especificar la ruta exacta salto a salto, de modo que si algún

paso de la ruta no es factible por algún motivo se producirá un error. Con loose source routing no es preciso

detallar todos los saltos, puede haber pasos intermedios no especificados.

Timestamp: esta opción actúa de manera similar a record route, pero además de anotar la dirección IP de cada

router atravesado se anota en otro campo de 32 bits el instante en que el datagrama pasa por dicho router.

De estos el más utilizado es source routing, y aún éste se usa poco pues generalmente se prefiere usar en su lugar

encapsulado IP en IP, que es más eficiente.

Direcciones IP

Cada nodo (host o router) en una red IP se identifica mediante al menos una dirección única de 32 bits. Las

direcciones IP se suelen representar por cuatro números decimales separados por puntos, que equivalen al valor

de cada uno de los cuatro bytes que componen la dirección. Por ejemplo una dirección IP válida sería

147.156.23.208.

Si un nodo dispone de varias interfaces físicas (cosa habitual en los routers) cada una de ellas deberá tener

necesariamente una dirección IP distinta si se desea que sea accesible para este protocolo. Es posible además, y en

algunas situaciones resulta útil, definir varias direcciones IP asociadas a una misma interfaz física.

Las direcciones IP tienen una estructura jerárquica. Una parte de la dirección corresponde a la red, y la otra al

host dentro de la red. Cuando un router recibe un datagrama por una de sus interfaces compara la parte de red de

la dirección con las entradas contenidas en sus tablas (que normalmente sólo contienen direcciones de red, no de

host) y envía el datagrama por la interfaz correspondiente.

En el diseño inicial de la Internet se reservaron los ocho primeros bits para la red, dejando los 24 restantes para el

host; se creía que con 254 redes habría suficiente para una red que tan solo era fruto de un proyecto de

investigación del DoD. Ya en 1980 se vio que esto resultaría insuficiente, por lo que se reorganizó el espacio de

direcciones reservando una parte para poder definir mas redes más pequeñas. Para dar mayor flexibilidad y

permitir diferentes tamaños se optó por dividir el rango de direcciones en tres clases adecuadas para redes

grandes, medianas y pequeñas, conocidas como redes de clase A, B y C respectivamente:

Una red de clase A (que corresponde a las redes originalmente diseñadas) se caracteriza por tener a 0 el primer bit

de dirección; el campo red ocupa los 7 bits siguientes y el campo host los últimos 24 bits. Puede haber hasta 126

redes de clase A con 16 millones de hosts cada una.

Una red de clase B tiene el primer bit a 1 y el segundo a 0; el campo red ocupa los 14 bits siguientes, y el campo

host los 16 últimos bits. Puede haber 16382 redes clase B con 2 millones de hosts cada una.

Una red clase C tiene los primeros tres bits a 110; el campo red ocupa los siguientes 21 bits, y el campo host los 8

últimos. Puede haber hasta dos millones de redes clase C con 254 hosts cada una.

Para indicar qué parte de la dirección corrresponde a la red y qué parte al host se suele utilizar una notación

denominada máscara, consistente en poner a 1 los bits que corresponden a la parte de red y a 0 los que

corresponden a la parte host. Así por ejemplo diremos que una red clase A tiene una máscara 255.0.0.0, lo cual

equivale a decir que los ocho primeros bits especifican la red y los 24 restantes el host. Análogamente decimos

que una red clase B tiene una máscara 255.255.0.0 y una clase C una máscara 255.255.255.0.

Existe además direcciones (no redes) clase D cuyos primeros cuatro bits valen 1110, que se utilizan para definir

grupos multicast (el grupo viene definido por los 28 bits siguientes).

Por último, la clase E, que corresponde al valor 11110 en los primeros cinco bits, está reservada para usos

futuros.

De los valores de los primeros bits de cada una de las clases antes mencionadas se deduce que el rango de

direcciones que corresponde a cada una de ellas es el siguiente:

Clase A: de 1.0.0.0 a 127.255.255.255

Clase B: de 128.0.0.0 a 191.255.255.255

Clase C: de 192.0.0.0 a 223.255.255.255

Clase D: de 224.0.0.0 a 239.255.255.255

Clase E: de 240.0.0.0 a 247.255.255.255

Así pues, en la práctica es inmediato saber a que clase pertenece una dirección determinada sin más que saber el

primer byte de su dirección.

La asignación deedirecciones válidas de Internet la realizan los NICs (NIC = Network Information Center). Al

principio había un NIC para toda la Internet pero luego se crearon NICs regionales (por continentes);

actualmente muchos países tienen un NIC propio; en España el NIC es administrado por RedIRIS.

Además del reparto de direcciones por clases según hemos visto existen unos convenios que es importante

conocer:

La dirección con el campo host todo a ceros no se utiliza para ningún host pues se reserva para indicar la red

misma.

La dirección con el campo host todo a unos no se utiliza para ningún host pues se reserva para indicar la

dirección broadcast correspondiente a toda la red.

La dirección 255.255.255.255 (todo a 1) se utiliza para indicar broadcast en la propia red.

Así por ejemplo, si tenemos la red 200.200.200.0 (clase C) reservaremos la dirección 200.200.200.0 para denotar

la red misma, y la dirección 200.200.200.255 para envíos broadcast a toda la red; dispondremos pues de 254

direcciones para hosts (no 256).

Algunas redes están reservadas para fines especiales:

La red 127.0.0.0 se utiliza para pruebas loopback; todas las implementaciones de IP devuelven a la dirección de

origen los datagramas enviados a esta dirección sin intentar enviarlos a ninguna parte.

Las redes:

10.0.0.0,

172.16.0.0 a 172.31.0.0, y

192.168.0.0 a 192.168.255.0

están reservadas por convenio para redes privadas ('intranets'); estos números no se asignan a ninguna dirección

válida en Internet y por tanto pueden utilizarse para construir redes, por ejemplo detrás de un cortafuego, sin

riesgo de entrar en conflicto de acceso a redes válidas de la Internet.

Subredes

Supongamos que una empresa dispone de varias oficinas, cada una con una LAN, todas ellas interconectadas

entre sí, y que desea unirlas mediante el protocolo TCP/IP; una de dichas oficinas (la principal) dispone además

de una conexión a la Internet; sería posible asignar por ejemplo una red clase C diferente para cada oficina, pero

esto supone solicitar al NIC una clase C para cada nueva oficina que se conecte, y al ser cada red independiente

de las demás la gestión se complica; por ejemplo no es posible definir una dirección broadcast para toda la

empresa, para el acceso desde el exterior se ha de contemplar una entrada distinta en las tablas de routing para

cada, etc.

En estos casos resulta útil disponer de algún mecanismo que permita dividir una red IP en trozos o subredes,

creando así un nivel jerárquico intermedio entre la red el host; de esa forma la empresa podría por ejemplo

solicitar una clase B y asignar fragmentos de dicha red a cada oficina a medida que fueran creándose.

Supongamos que a la empresa se le asigna la clase B 156.134.0.0; de los 16 bits que en principio corresponden al

host podría reservar los primeros 8 para la subred y dejar los 8 siguientes para el host, de esta forma habría 256

subredes de 256 direcciones cada una. Desde fuera la red de la empresa seguiría siendo 156.134.0.0, ya que la

estructura de subred no sería visible.

Las subredes se añadieron a la Internet en 1982 para crear ese nivel jerárquico intermedio entre la red y el host,

dando así mayor flexibilidad en el reparto de direcciones dentro de una red.

Para dividir la red en subredes se define una máscara en la que están a 1 los bits de la dirección que corresponden

a la red-subred, y a cero los que corresponden al host. Por ejemplo, la máscara 255.255.255.0 divide una red

clase B en 256 subredes de 256 hosts pues tiene puestos a 1 los primeros 24 bits (16 de la clase B mas 8 de la

subred). Se pueden hacer divisiones que no correspondan con bytes enteros, por ejemplo si la máscara fuera

255.255.252.0 se estarían reservando los primeros 6 bits para la subred y dejando 10 para el host; de esta forma

podría haber hasta 64 redes de 1024 hosts.

Al crear subredes las direcciones con el campo host todo a 0 y todo a 1 quedan automáticamente reservadas para

la designación de la subred y para la dirección broadcast, respectivamente. Así si la red 156.134.0.0 se subdivide

con la máscara 255.255.255.0 se crean 256 subredes del tipo 156.134.subred.host, siendo 156.134.subred.0 la

dirección que identifica a toda la subred y 156.134.subred.255 la dirección broadcast de la subred. El número de

hosts de una subred es siempre dos menos que el número de direcciones que abarca.