8

ARQUITECTURA DE
COMUNICACIONES ENTRE
COMPUTADORAS. MODELO
GENERALIZADO DE PROTOCOLOS
8.1

GENERALIDADES

La expresin transmisin de datos se refiere a la transferencia de una seal o conjunto de datos

entre dos puntos, sin tener en cuenta el contenido de ellos. Sin embargo, cuando las computadoras, terminales u otros dispositivos de procesamiento de datos intercambian datos, el alcance es
mucho ms amplio. Consideremos por ejemplo, la transferencia de un archivo entre dos computadoras, diagramado en la figura 8.1.
Estacin 1
Estacin 2
Para este fin habr una trayectoProtocolo
orientado
ria de datos entre las dos computadoras,
a la aplicacin
transferencia
transferencia
directamente o a travs de una red de
de archivos
de archivos
comunicaciones (figura 8.1). Para esta
transferencia se requiere efectuar las cuaProtocolo Sistema
Servicios
Servicios
tro tareas mostradas en la tabla 8.1. Debe
a Sistema
de red
de red
haber un alto grado de cooperacin entre
los dos sistemas o los dos computadores.
Este intercambio de informacin cuyo
Protocolo
Protocolo
propsito es tener una accin cooperativa
de acceso
de acceso
Red de
a la red
a la red
es conocido como comunicacin entre
Comunicaciones
computadoras. Similarmente, al conjunto de dos o ms computadoras que estn
interconectadas va una red de comuniFigura 8.1 Transferencia de archivos entre
caciones es conocido como una red de
dos computadoras
computadoras.
TAREA

1. El sistema origen debe activar tanto la trayectoria directa de transmisin de datos como informar a la red
de comunicaciones de la identidad del sistema destino.
2. El sistema origen o fuente debe asegurarse que el destino est preparado para recibir los datos.
3. La aplicacin de transferencia de archivos del sistema fuente debe confirmar que el programa de administracin de archivos del sistema destino est listo para aceptar y almacenar el archivo que se le va a enviar.
4. Si los formatos de los archivos utilizados en los dos sistemas son incompatibles, uno de los sistemas debe realizar la traduccin de formatos.
Tabla 8.1 Tareas para la transferencia de archivos entre dos sistemas
97

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

Para analizar la comunicacin entre computadoras y las redes de computadoras, es necesario

comprender dos conceptos muy importantes, a saber:
Protocolos
Arquitectura de comunicaciones entre computadoras

8.2

PROTOCOLOS CARACTERSTICAS

El concepto de procesamiento distribuido y de redes de computadoras implica que las entidades

en diferentes sistemas necesitan comunicarse. Nosotros usamos los trminos entidad y sistema en un sentido muy general.
Ejemplos de entidades son los programas de aplicacin de los usuarios, paquetes de
transferencias de archivos, sistemas de administracin de base de datos, facilidades de correo
electrnico y terminales. Ejemplos de sistemas son las computadoras, los terminales y los sensores remotos. Ntese que en algunos casos la entidad y el sistema en el cual sta reside son coexistentes, tal como en el caso de los terminales.
En general, una entidad es todo aquello capaz de enviar o recibir informacin y un sistema es un objeto fsicamente distinto que contiene una o ms entidades.
Para que dos entidades se comuniquen exitosamente deben hablar el mismo lenguaje. Lo
que se comunique, cmo esto se comunique o cundo esto sea comunicado, deben ceirse a un
conjunto de convenciones aceptados mutuamente entre las entidades involucradas. Este conjunto
de convenciones es el protocolo, que puede definirse como el conjunto de reglas que gobiernan el
intercambio de datos entre dos entidades. Los elementos claves de un protocolo son:
Sintaxis: Incluye tales cosas como formato de datos, codificacin y niveles de seal.
Semntica: Incluye la informacin de control para la coordinacin y el manejo de errores.
Temporizacin: Incluye la adaptacin de velocidad y el secuenciamiento.

8.3

PROTOCOLO GENERALIZADO

En este captulo trataremos sobre el concepto de protocolo de comunicaciones generalizado. Aqu

se muestra que los protocolos son fundamentales para todo tipo de comunicaciones de datos y
describiremos sus caractersticas y funciones.
8.3.1
CARACTERSTICAS
Las caractersticas ms importantes de los protocolos son:
Directo /Indirecto
Monoltico /Estructurado
Simtrico /Asimtrico
Normalizado /No normalizado
Seguidamente pasaremos a describir cada una.
8.3.1.1
DIRECTO O INDIRECTO
Las comunicaciones entre dos entidades pueden
ser directas o indirectas. La figura 8.2 muestra
estas situaciones.
Si dos sistemas comparten un enlace
punto a punto, las entidades de estos sistemas
podran comunicarse mutuamente; esto es, la informacin de datos y de control pasan directamente entre las entidades sin la intervencin de
un agente activo. Lo mismo puede decirse de
una configuracin multipunto, aunque aqu las
entidades estn relacionadas con el aspecto de
control de acceso, haciendo el protocolo ms
completo. Si los sistemas se conectan a travs
98

(a) Punto a punto

(b) Red Multipunto o en Broadcast

Nube

(c) Red de conmutacin

Nube

Nube

Nube

(d) Internet
Figura 8.2 Medios de conexin de sistemas
de comunicaciones

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

de una red de comunicaciones conmutada, un protocolo directo ya no es posible. Las dos entidades deben depender para su funcionamiento de otras entidades. Un caso ms extremo es cuando
las dos entidades no comparten la misma red conmutada sino que estn indirectamente conectadas
a travs de dos o ms redes. El conjunto de estas redes interconectadas se denomina internet.
Una consideracin importante de diseo de un protocolo parte de las dos ltimas configuraciones 8.2c y 8.2a. Esto nos indica que las entidades y sus protocolos deben tener en cuenta
las caractersticas de los sistemas o redes intermedios. Idealmente los sistemas intermedios deberan ser transparentes y el protocolo entre las dos entidades debera ser el mismo que para un enlace punto a punto.
8.3.1.2
MONOLTICO O ESTRUCTURADO
Comunicar dos entidades de diferentes sistemas es una tarea muy compleja para ser manejada
como una unidad. Por ejemplo, considere un paquete de correo electrnico que est corriendo sobre dos computadoras conectadas sobre un enlace con protocolo HDLC. Para ser verdaderamente
monoltico, el paquete de correo debera incluir toda la lgica del HDLC. Y si la conexin fuera
hecha sobre una red de conmutacin de paquetes, el paquete an necesitar la lgica HDLC (o
una equivalente) para conectarse a la red.
Tambin se requerir una lgica para partir los mensajes de correo en trozos del tamao
de los paquetes, la lgica para pedir un circuito virtual y otros aspectos. El correo slo debera ser
enviado al sistema de destino y la entidad cuando stas estn activas y listas para recibir. Se requiere una lgica para esta clase de coordinacin y la lista puede continuar. Un cambio en cualquier aspecto significa que todo este inmenso paquete debe ser modificado, con el riesgo de introducir bugs difciles de encontrar.
Una alternativa es usar un diseo estructurado y tcnicas de implementacin. En vez de
usar un solo protocolo, hay un conjunto de protocolos que exhiben una estructura jerrquica o por
capas. Al ms bajo nivel se implementan las funciones ms primitivas en las entidades de bajo nivel, las cuales proveern servicios a las entidades de alto nivel. Por ejemplo podra haber un mdulo HDLC, el cual es una entidad que puede ser invocada por una facilidad de correo electrnico
cuando sta la requiera.
Estacin 1
Estacin 2
La figura 8.3 sugiere
Protocolo orientado a la aplicacin
en trminos generales un conAplicacin
Aplicacin
junto estructurado de protocolos y muestra el caso ms exProtocolo de proceso a proceso
Servicios
Servicios
tremo de dos estaciones conecde red
de red
tadas a travs de mltiples redes conmutadas. Las estaciones
Protocolo de
acceso a red 1
1 y 2 tienen cada cual una o
ms aplicaciones que desean
comunicarse. Entre cada par de
Protocolo
Red A
Red B
entidades (ejemplo: mdulos de
interredes
correo electrnico) un protocoProtocolo nodo a nodo
lo orientado a la aplicacin es
necesario, el cual coordina las
Protocolo de
actividades de los dos mdulos
entrada y salida
de aplicacin y asegura una
Protocolo de
semntica y sintaxis comunes.
acceso 2
Este protocolo necesita
Terminal
saber muy poco acerca de la faFigura 8.3 Relacin entre protocolos de comunicaciones
cilidad disponible en las comunicaciones, pero hace uso de la
entidad, de los servicios de red que s le proveen. La entidad de servicios de red tendr un protocolo de proceso a proceso con una entidad correspondiente en la otra estacin. La entidad de ser99

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

vicios de red tendr un protocolo de proceso a proceso con la entidad correspondiente en la otra
estacin. Este protocolo podra manejar aspectos tales como control de flujo y control de errores.
Adems habr protocolo entre la estacin 1 y la red A, y entre la estacin 2 y la red B. Para una
red en broadcast, el protocolo incluira una lgica de control de acceso al medio. Para una red de
conmutacin de paquetes se requiere una lgica para el establecimiento de los circuitos virtuales.
Ntese que un diferente y ms sencillo protocolo de acceso a la red ser provisto para los
dispositivos menos inteligentes, tales como los terminales. Internamente en cada red se requiere
un protocolo nodo a nodo para conectar los pares de nodos y tambin puede ser usado un protocolo de entrada y salida. Ejemplos de estos protocolos son discutidos cuando se explican la interconectividad de redes.
8.3.1.3
SIMTRICO O ASIMTRICO
Un protocolo puede ser simtrico o asimtrico, aunque la mayora de protocolos que hemos estudiados son simtricos. Esto es, que ellos involucran comunicaciones entre entidades pares. La simetra puede ser dictada por la lgica de una central (por ejemplo: un proceso de usuario y un
proceso de servidor), o por el deseo de mantener una de las entidades o sistemas lo ms simple
posible. Un ejemplo es el modo normal de respuesta (NRM) del HDLC. Tpicamente esto involucra que la computadora debe invocar y seleccionar un nmero de terminales. La lgica del terminal es totalmente simple.
8.3.1.4
NORMALIZADO O NO NORMALIZADO
Un protocolo no normalizado es Transmisores
Receptores
aquel construido para una situacin de comunicaciones especS1
fica o, en el peor caso, para un
R
modelo particular de computa1
dora. El incremento del uso del
S2
procesamiento distribuido y la
decreciente inclinacin de los
R
clientes de permanecer engan2
chados a un solo vendedor indiS3
ca que todos los vendedores deS3
R
ben incrementar protocolos que
3
cumplan con las normas del
S4
CCITT o de organizaciones
normativas. En la figura 8.4 se
dan ambos casos. Seguidamente (a) Sin normalizacin.12 protocolos
diferentes, 24 implementaciones
describimos las funciones de un
de protocolo.
protocolo.

Transmisores

Receptores

S1
R
1
S2
R
2
S3
R
3
S4

(b) Con normalizacin.

1 protocolo, 7 implementaciones de protocolo.

Figura 8.4 El uso de protocolos normalizados

8.3.2
FUNCIONES
Ahora consideremos un conjunto de funciones que forman las bases de todos los protocolos. No
todos los protocolos tienen todas estas funciones, pues implicara una duplicacin de esfuerzos.
Sin embargo, hay circunstancias en que el mismo tipo de funcin est presente en protocolos de
diferentes niveles. Esta discusin es necesariamente bastante abstracta. En ella se da una panormica integral de las funciones de los protocolos, las que agrupamos en las siguientes categoras:
Segmentacin y reensamble
Sincronizacin
Encapsulacin
Secuenciamiento
Control de conexin
Direccionamiento
Control de flujo
Multiplexaje
Control de errores
Servicios de Transmisin
A continuacin desarrollamos cada una de estas funciones.
100

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

8.3.2.1
SEGMENTACIN Y REENSAMBLE
Un protocolo est relacionado con el intercambio de trenes de datos entre dos entidades. Esta
transferencia puede ser caracterizada como una secuencia de bloques de datos de un tamao determinado. En el nivel de aplicacin, nos referimos como a la unidad lgica de transferencia de
datos como un mensaje. Ahora bien, mientras la entidad de aplicacin enva datos en mensajes,
los protocolos del nivel inferior podran necesitar esos datos en bloques de un tamao fijo ms
pequeo. Este proceso es llamado segmentacin o fragmentacin. Por conveniencia, nos referiremos al bloque de datos intercambiados entre dos entidades mediante un protocolo como un PDU
(Protocol Data Unit). Hay varios motivos para llevar a cabo la segmentacin dependiendo del
contexto. Entre las razones tpicas estn:
Una red de comunicaciones puede aceptar solamente bloques de datos de hasta cierto tamao. Por ejemplo la red DDN limita los bloques de mensajes a 8063 bytes de longitud.
El control de errores puede ser ms eficiente con una unidad PDU pequea. Pocos bytes necesitarn retransmitirse usando bloques pequeos con la tcnica selectiva de repeticin.
Los PDU de tamao pequeo pueden requerir una asignacin de bloques ms pequeos. Tal
como ejemplo el protocolo de entrada a salida de la red ARPANET.
Una entidad puede requerir
que los datos sean transferiUsuario
Usuario
dos con un cierto cierre, de
A
B
tiempo en tiempo, para llevar
a cabo operaciones de control, reinicio y recuperacin.
Los bloques pequeos tenEntidad de
Entidad de
drn un retardo ms corto.
protocolo
protocolo
Las desventajas de la segmentacin de hacer los bloques los ms
grandes posibles son:
Figura 8.5 Segmentacin y reensamble
Cada unidad PDU contiene
una cantidad fija de sobrecabecera; de aqu que cuanto ms pequeo sea el bloque, mayor ser el porcentaje de sobrecabecera.
La llegada de una unidad PDU genera una interrupcin en el procesador que debe ser aprendida. Por consiguiente, los bloques ms pequeos requieren ms interrupciones.
Se gasta ms tiempo procesando numerosas unidades PDU de tamao pequeo.
La contrapartida de la segmentacin es el reensamble. Al ser recibidos los datos fragmentados son
reensamblados para obtener los mensajes a nivel de aplicacin.
En la figura 8.5 se muestra que el usuario A desea enviar un mensaje al usuario B, pero el mensaje
es segmentado en tres unidades PDU antes de la transmisin y reensamblados, una vez recibidos,
antes de ser entregado a B.
8.3.2.2
ENCAPSULACIN
Usuario
Usuario
A
B
Cada PDU no slo tiene datos
sino tambin informacin de
datos
datos
control. An ms algunos
PDUs contienen solamente informacin de control y no daEntidad de
Entidad de
tos. La informacin de control
protocolo
protocolo
datos
datos
tiene tres categoras generales:
Direccin: La direccin
Control
Control
del remitente y el destinaFigura 8.6 Encapsulacin
tario como se ha indicado.
Cdigo de deteccin de
errores: Se incluye algn tipo de secuencias de control de trama para deteccin de errores.
101

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

Control de protocolo: Se incluye informacin adicional para implementar las funciones de

protocolo listadas en el final de esta seccin.
La adicin de informacin de control de los datos es referida como encapsulacin. Los datos son
aceptados o generados por una entidad y encapsulados dentro de un PDU que contiene datos adems de control de informacin. Ver la figura 8.6.
8.3.2.3
CONTROL DE LA CONEXIN
Existen dos mtodos fundamentales para transferir informacin:
a) Transferencia de datos no orientada a la conexin (ConnectionLess) - DATAGRAMA
Una entidad puede transmitir datos a otra entidad de una manera no planeada y sin una coordinacin previa. Esto es conocido como transferencia de datos no orientados a la conexin. Un ejemplo de este uso es el datagrama.
b) Transferencia de datos orientada a la conexin (Connection Oriented) - PAQUETE
Este tipo de transferencia es preferible, y en algunos
Peticin de conexin
casos an obligatoriamente requerido, si las estaciones anticipan un gran intercambio de datos y que ciertos detalles de su protocolo deban trabajarse dinmiConexin aceptada
camente. Se establece una conexin o asociacin lgica entre las entidades. Ocurren 3 fases (figura 8.7):
Datos y confirmaciones
Fase I : Establecimiento de la conexin.
Entidad
Entidad
Fase II : Transferencia de datos.
de
de
Fase III : Terminacin de la conexin.
protocolo
protocolo
Datos y confirmaciones
Con protocolos ms sofisticados tambin puede haber
una interrupcin de la comunicacin, as como fases
Peticin de desconexin
de recuperacin para enfrentar los errores y otros tipos de interrupciones.
Durante la fase de establecimiento, las dos entidades
acuerdan intercambiar datos. Tpicamente una estaConfirmacin de desconexin
cin puede emitir una peticin de conexin hacia la
Figura 8.7 Las fases de una transferencia
otra. Una autoridad central puede o no puede estar
de datos orientada a la conexin
involucrada. En protocolos ms simples, la entidad
destinataria puede aceptar o rechazar la peticin. En caso de aceptar la peticin, se inicia la comunicacin. En propuestas ms complejas, estas fases incluyen negociacin entre las entidades respecto a la sintaxis, semntica y temporizacin del protocolo. Ambos sistemas deben, por supuesto, usar el mismo protocolo. Pero el protocolo puede permitir ciertas caractersticas opcionales
que deben ser acordadas mediante la negociacin. Por ejemplo, el protocolo podra especificar un
PDU de 8000 bytes y una de las estaciones podra desear restringirla a slo 1000 bytes.
Continuando el establecimiento de comunicacin, se inicia la fase de transferencia de datos. Durante esta fase, la informacin de datos y de control, tales como control de flujo y control de errores, es intercambiada. Finalmente una estacin o la otra puede desear terminar la conexin y lo
lleva a cabo emitiendo una peticin de terminacin. Alternativamente, una autoridad central podra forzar la terminacin de una comunicacin.
8.3.2.4
CONTROL DEL FLUJO
En esencia sta es una funcin realizada por la entidad receptora o destinataria para limitar la cantidad de datos o la velocidad a que estos datos estn siendo enviados por la entidad transmisora.
La forma ms simple de control de flujo es el procedimiento de stop-and-wait, en el cual cada
PDU debe ser confirmado antes que el prximo pueda ser enviado. Los protocolos ms eficientes
involucran la tcnica de ventana corrediza que es una forma de crdito que se le brinda al transmisor para que pueda remitir tramas sin una confirmacin.
El algoritmo del SNA denominado Pacing y el comando de ARPANET denominado
ready-for-next-message estn relacionados muy cercanamente. El control de flujo es un buen
ejemplo de una funcin que se debe implementar en los protocolos.
102

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

8.3.2.5
CONTROL DE ERRORES
Son necesarias tcnicas para protegerse contra la prdida o dao de la informacin de datos y la
informacin de control. La mayor parte de tcnicas involucran deteccin de errores, basadas en la
secuencia de revisin de tramas y la retransmisin de unidades de PDU. Las retransmisiones son a
menudo activadas por un temporizador. Si una entidad transmisora falla en recibir una confirmacin de una PDU dentro de un perodo determinado, entonces proceder a retransmitir la trama
enviada anteriormente. Como el control de flujo, el control de errores es una funcin que debe ser
llevada en varios niveles de los protocolos.
8.3.2.6
SINCRONIZACIN
Es necesario que dos estaciones que se comunican, se encuentren simultneamente en estados
bien definidos, por ejemplo: en estado de inicializacin, transferencia de datos y terminacin de
una llamada, es decir, que se encuentren sincronizados. De all viene la funcin de sincronizacin.
Para este efecto, se debe haber programado previamente un conjunto de parmetros tales como:
tamao de ventana, fases de la comunicacin (establecimiento, transferencia de datos), valores de
los temporizadores, etc. Estos parmetros pueden ser vistos como variables de estado y su coleccin define el estado de una entidad.
8.3.2.7
SECUENCIAMIENTO
Esta funcin brinda el orden en el que las tramas o unidades de datos estn siendo enviados por
medio de su numeracin en secuencia. Esta funcin slo tiene sentido en el contexto de la transferencia de datos orientada a la conexin. El secuenciamiento sirve a tres propsitos principales:
Una entrega ordenada, es decir, las tramas en orden.
Control de flujo.
Control de errores.
Considere primero el caso de una entrega ordenada. Si dos entidades no estn directamente conectadas hay el riesgo de que las unidades PDU no llegarn en el orden en que fueron enviadas debido a que podran haber recorrido trayectorias diferentes.
8.3.2.8
DIRECCIONAMIENTO (ADDRESSING)
Para que dos entidades puedan comunicarse, ellas deben ser capaces de identificar una a la otra.
Por ejemplo, en una red de difusin amplia (LAN) cada estacin observa a todos los paquetes para
ver si alguno contiene su identificativo (direccin). Sobre una red de conmutacin, la red necesita
conocer la direccin de la estacin destino para enrutar apropiadamente los datos o para establecer
una conexin. Se debe hacer una distincin entre los siguientes trminos:
Nombre : Especifica cul es este objeto.
Direccin : Especifica dnde se encuentra este objeto.
Ruta
: Indica cmo llegar hasta este objeto.
Este aspecto de nombres y direcciones de entidades no admite una nica solucin, seguidamente
listamos y explicamos los tpicos que deben considerarse.
Estructura de nombre.
Nombre de conexin.
Nombre de grupo.
Conocimiento del nombre.
Nombre de puertas.
a)
Estructura de nombre
La estructura de nombre se usa para nombres globales y puede ser una estructura jerrquica o una
estructura plana. Una estructura plana es aquella en la que cada entidad tiene un nombre global,
que es nico a travs de todo el dominio de comunicaciones.
Una estructura jerrquica debera incluir nombres que tengan la siguiente estructura:
SISTEMA.ENTIDAD, o en el caso de redes mltiples: RED.SISTEMA.ENTIDAD. Los campos SISTEMA
y RED contienen identificativos globales de un formato fijo. La ENTIDAD debe ser el nombre de
una longitud fijada a un mximo determinado. El nombre podra tener una significancia global, en
cuyo caso el sistema que contiene a la entidad deber contener una tabla de mapeo de identificadores de entidades globales a identificadores de entidades locales.
103

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

b)
Conocimiento de nombre
Una entidad slo puede enviar datos o pedir una conexin a una entidad cuyo nombre sta conoce.
c)
Nombre de la conexin
Este caso es usado en la fase de la transferencia de los protocolos orientados a la conexin, en la
cual se da un nombre a cada conexin que es establecida entre dos entidades. El uso del nombre
de la conexin tiene varias ventajas:
Reducida sobrecabecera: Los nombres de conexiones son generalmente ms corto que los
nombres globales. Como ejemplo tenemos el protocolo X.25, donde se asigna un nmero de
circuito virtual a los circuitos virtuales cuando son establecidos. Dicho nmero est contenido en todos los paquetes de datos referentes a esa conexin.
Enrutamiento: Una vez establecida una conexin una ruta puede ser definida, por ejemplo
para SNA, pero no para ARPANET. El nombre de la conexin sirve para identificar la ruta
para el manejo de las unidades PDU futuras. Este concepto es aplicado en el IP Switching.
Multiplexaje: Trataremos esta funcin en trminos ms generales ms adelante. Aqu hacemos notar que una entidad podra desear tener ms de una conexin simultneamente. As,
todos las unidades PDU entrantes deben ser identificadas por su nombre de conexin.
d)
Nombre de la puerta
ste es un nombre de entidad global. Si cada entidad tiene un solo nombre de puerta, este concepto no tiene mucho sentido. Sin embargo, hay a menudo casos de mltiples nombres de puertas que
son asociadas con una entidad. Esto puede ser usado para proporcionar multiplexaje, as como fue
usado con los nombres de conexin. Por ejemplo, un mdulo de servidor de archivos puede estar
disponible para atender a varios usuarios simultneamente. Tambin los nombres de puerta pueden indicar diferentes puntos de entrada dentro de una entidad. Por ejemplo, un servidor de archivos podra tener diferentes puntos de entrada, por ejemplo: uno para usuarios autorizados slo para leer datos y otro punto de entrada para usuarios autorizados para leer y actualizar datos.
e)
Nombre de grupo
ste es un nombre que se refiere a ms de una entidad o puerta. Un nombre de grupo puede ser
broadcast, que significa que es direccionado para todas las entidades dentro de un dominio, o
puede ser multicast, es decir que est direccionado a un subconjunto especfico de entidades.
8.3.2.9
MULTIPLEXAJE
Esta funcin se logra por medio de los nombres de conexin, los cuales permiten mltiples conexiones simultneas. Otro tipo de multiplexaje se da en el mapeo de
las conexiones de un nivel sobre otro. El multiplexaje
puede ser usado en una de dos direcciones (figura 8.8).
Multiplexaje hacia arriba: Este ocurre cuando mltiples conexiones de alto nivel son multiplicadas o
comparten una conexin de un nivel inferior nica.
Esto puede ser necesario para hacer ms eficiente el
uso del servicio del nivel ms bajo o proveer a varias
conexiones de alto nivel un ambiente donde slo
existe la conexin a un bajo nivel nico.
Multiplexaje hacia abajo: Significa que una conexin de alto nivel puede ser colocada en la parte
superior de varias conexiones de bajo nivel, de tal
manera que el trfico de la conexin de alto nivel
pueda ser dividido entre las mltiples conexiones de
bajo nivel. Esta tcnica puede ser usada para proporcionar confiabilidad, performance o eficiencia.
104

conexin de alto nivel

(a) Uno a uno

conexin de bajo nivel

(b) Multiplexaje hacia abajo

(downward multiplexing)

(c) Multiplexaje hacia arriba

(upward multiplexing) - Inverse mux

Figura 8.8 Multiplexaje de

conexiones de protocolos

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

8.3.2.10
SERVICIOS DE TRANSMISIN
Un protocolo puede proporcionar una variedad de servicios adicionales a las entidades que lo
usan. Aqu presentamos tres tipos de servicios:
Prioridad: Mensajes prioritarios tales como de control de conexin.
Grado de servicio: Ofrece determinados niveles de caudal y retardo.
Seguridad: Se pueden establecer mecanismos de restriccin de acceso (firewalls), etc.

8.4

CLASIFICACIN DE LOS
PROTOCOLOS

PROTOCOLOS

En la figura 8.9 presentamos una clasificacin general de

los protocolos, en base a su tipo de sincronismo. Luego
en la figura 8.10 y 8.11 detallamos cada categora.
Seguidamente analizamos brevemente a los protocolos
sncronos y asncronos.

8.4.1

Sncronos

Asncronos

Figura 8.9 Clasificacin general

de los protocolos por
su sincronismo

PROTOCOLOS SNCRONOS

8.4.1.1
PROTOCOLOS CON ESTACIN PRIMARIA/SECUNDARIA
a)
Por encuesta: SDLC y BSC
SDLC: Es un subconjunto del protocolo HDLC, el cual ser tratado con mucho detalle en
una seccin completa. Al comprender el HDLC implcitamente se est conociendo el SDLC.
BSC: Es un protocolo orientado al byte o caracter. Fue un protocolo muy popular en los aos
60, y actualmente no es usado, pues los protocolos basados en el HDLC son ms eficientes.
b)

No encuesta (Non-polling): TDMA

TDMA: Es protocolo
PROTOCOLOS SNCRONOS
de acceso mltiple por
divisin de tiempo (Time Division Multiple
Estacin
Par a par
Hbrido
Primaria/Secundaria
Access) es una forma
(Peer to peer)
sofisticada del multiplexaje por divisin de
encuesta
No encuesta
Con prioridad
Sin prioridad
tiempo (TDM). Aqu, Por(Polling)
HDLC
(non-priority)
(non-polling)
(Priority)
una estacin es designada como una estacin
SDLC
Token Ring
L L L L
TDMA
Ethernet
Token Bus
A A
BSC
primaria (denominada a
A
L
P P
menudo estacin de reP B D C
ferencia). La responsaFigura 8.10 Clasificacin general de los protocolos sncronos
bilidad de la estacin de
referencia es aceptar peticiones o solicitudes de las estaciones secundarias, las cuales son indicaciones de que una estacin secundaria desea usar el canal. Las peticiones son enviadas como parte de las transmisiones salientes de las estaciones secundarias dentro de un campo de control especial. Peridicamente, la estacin de referencia transmite una trama de control sealando a la estacin
que puede usar el canal durante un determinado perodo. Una vez recibida esta trama, llamada trama de permiso, la estacin secundaria designada ajusta su temporizacin para transmitir
dentro del perodo previamente designado.

8.4.1.2
PROTOCOLOS PAR A PAR (Peer to peer)
a)
Sin prioridad
ETHERNET: Este protocolo probabilstico, est gobernado por la norma 802.3 conocido
tambin como Acceso mltiples por percepcin de presencia de portadora con deteccin de
105

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

colisiones (CSMA/CD - Carrier Sense Multiple Access with Collision Detection). Sobre este
protocolo trataremos en detalle en el mdulo de redes de rea local (LAN).
b)

Con prioridad
TOKEN BUS: Este protocolo determinstico, empleado en las redes de rea local, est gobernado por la norma 802.4 del IEEE y se emplea en aplicaciones de manufactura. ste utiliza una topologa tipo bus pero proporciona el acceso al canal como si ste fuera un anillo,
usando el mismo principio del protocolo TOKEN RING.
TOKEN RING: Este protocolo determinstico, gobernado por la norma 802.5 del IEEE, es
empleado en las redes LAN de IBM. ste utiliza una ficha o testigo (TOKEN) para dar oportunidad a una estacin para que pueda transmitir. Lo trataremos en detalle ms adelante.

8.4.1.3
PROTOCOLO HBRIDO - HDLC
Este importante protocolo es la base para ms de ocho tipos de protocolos y est explicado detalladamente a nivel de bit en un captulo dedicado.
8.4.2
PROTOCOLOS ASNCRONOS
Estos protocolos son generalmente propietarios, es decir que son elaborados por empresas privadas, y estn basados en el formato asncrono.
8.4.2.1
HISTORIA
Estos protocolos tienen como prototipo inicial al telgrafo, desarrollado en 1832 por Samuel F.B.
Morse. En 1938, despus de varios intentos, l y Alfred Vail disearon un cdigo para representar
las letras del alfabeto con espacio (ausencia de corriente elctrica), puntos (una corriente elctrica
de corta duracin) y lneas (una corriente elctrica de ms larga duracin: tres veces la longitud de
un punto). Este cdigo era el Cdigo Morse. Estaba diseado inteligentemente, pues a los caracteres utilizados con ms frecuencia les asignaron smbolos de cdigo ms corto. Por ejemplo, a la
letra e se le asign el valor de un solo punto, mientras que a la z se le asign lnea, lnea, punto, punto. Esta longitud variable de cdigo redujo el nmero de golpes que el operador tena que
hacer e interpretar y disminuy el nmero de seales transmitidas a travs del circuito.
Uno de los mayores problemas era la interferencia entre smbolos, causada por los tiempos de subida y bajada que sufra la onda cuadrada telegrfica al viajar por el filtro pasabajo que
constitua la lnea telegrfica. Para disminuir tal efecto se intentaron varios recursos, como elevar
el voltaje (con consecuencias infortunadas como la destruccin de un cable trasatlntico). Otra
tcnica fue la corriente doble, es decir se asign a la corriente en un sentido representar a la lnea,
a la corriente en otro sentido representar al punto y a la ausencia de corriente representar al espacio. La telegrafa por corriente doble mejor considerablemente la velocidad de transmisin.
Thomas Edison tambin contribuy al campo de las comunicaciones. En 1874 desarroll
la novedosa idea del telgrafo cuadruplex, que describa ms de un smbolo por seal. Esta idea se
conoce hoy como la sealizacin
PROTOCOLOS ASNCRONOS
multinivel y es parte integral de las
comunicaciones modernas.
Ahora desarrollaremos los
Start/Stop XMODEM YMODEM BLAST
siguientes protocolos asncronos:
Kermit
MNP
XMODEM
Baudot
YMODEM
X.3
BLAST
TELNET
Kermit
Figura 8.11 Clasificacin general de los protocolos asncronos

8.4.2.2
XMODEM
Durante los das remotos de los inicios de las comunicaciones de datos, el campo estaba habitado
por aficionados que queran experimentar con esta interesante nueva tecnologa. Uno de los mayores problemas era el intercambio de informacin entre computadoras. Ward Cristianasen resol106

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

vi este problema en 1977, escribiendo un programa que atenda dos problemas: el software de la
PC y los protocolos orientados al canal telefnico. En esos aos los mdems operaban a 300 bps.
Cristianasen escribi un programa de transferencia de archivos y lo puso para dominio pblico.
Hoy existen varias versiones de este programa, siendo las ms famosas: MODEM7 y XMODEM.
El XMODEM es un protocolo con las siguientes caractersticas:
Stop and wait.
Half duplex.
Dependiente del cdigo.
Utiliza el Automatic ReQuest (ARQ).
Tiene un campo de datos fijo de 128 bytes.
Transfiere los datos en tramas de nivel 2 (aunque le llaman paquetes).
La trama que utiliza para transferir informacin se muestra en la figura 8.12.
El SOH, es la cabecera de inicio (Start Of Header) usada para indicar el inicio de la trama. El siguiente byte nos indica el nmero de trama que se est enviando. Normalmente se inicia con la
trama nmero 1, despus de la inicializacin. El campo que sigue contiene el complemento de 1s
del nmero de secuencia. Se transmite este valor con el fin de chequear la validez del nmero de
secuencia. El receptor suma en un OR-EX estos dos nmeros y si el resultado es cero, significa
que no hay error. Si no es cero, el
XMODEM enviar una confirmaComplemento
nmero de
Datos
cin negativa al transmisor para pe1's de la
Checksum
SOH
secuencia
128
Bytes
secuencia Nr
dir que retransmita la trama. El
campo de datos puede contener
Figura 8.12 Unidad de protocolo del XMODEM
cualquier tipo de sintaxis (Binario,
ASCII, Boleano, texto, etc.).
El byte de Checksum sirve para verificar slo si los datos han llegado sin error.
Adems para operar tiene temporizadores que le sirven para detectar tiempos excesivos de falta de
respuesta de una estacin.
8.4.2.3
YMODEM
Es muy similar al XMODEM, sin embargo tiene caractersticas adicionales, que son:
Puede abortar la transferencia de un archivo con dos caracteres consecutivos Cancel (CAN
en ASCII).
Utiliza el algoritmo CRC-16 del CCITT.
Emplea bloques de datos de 1 kilobyte en vez de 128 bytes que usa el XMODEM.
Permite el modo mezclado de enviar cabeceras con STX para bloques de 1 kilobyte y SOH
para bloques de 128 bytes.
Permite enviar mltiples archivos simultneamente usando caracteres de control adicionales.
8.4.2.4
BLAST
Este protocolo muy popular permite un procedimiento full duplex con ventana corrediza. Para
control de errores usa el CRC. Permite la transferencia de archivos binarios y de texto.
8.4.2.5
KERMIT
Este protocolo fue diseado para la transferencia de archivos y fue desarrollado en la Universidad
de Columbia. Es uno de los protocolos utilizados ms ampliamente en la industria. Este robusto
protocolo permanece transparente a los sistemas operativos. El procedimiento de transferencias es
un poco similar al XMODEM.
El proceso de transferencia empieza despus que el transmisor recibe un paquete NAK, luego de
ste, enva un send initiate packet, para iniciar la negociacin de la transferencia del archivo.
Despus, el transmisor enva un paquete de cabecera del archivo conteniendo el nombre del archivo y sus caractersticas. La recepcin exitosa de la cabecera de archivo habilita al transmisor para
empezar a enviar datos. Cada unidad de datos es confirmada por el receptor. Despus que el proceso de transferencia del archivo ha terminado, el abonado que llama enva un paquete de End Of
107

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

File (EOF), en el cual indica que no tiene ms archivos en enviar y detiene el proceso. El paquete
que utiliza el Kermit, tiene 6 campos mayores (ver la figura 8.13).
El campo MARK est codificado
como un ASCII SOH. Esto signifiMARK
LEN
SEQ
TYPE
DATA CHECK Formato
ca el inicio del paquete.
El campo LEN es un campo que
Datos de
define el nmero de bytes que conhasta 96 0 - 63
Tipo de usuario o Checksum
SOH
tiene el paquete.
o
bytes
paquete control de
CRC
El campo SEQ indica la secuencia
archivos
de cada paquete. Se utiliza un contador que una vez que alcanza el
nmero 63, retorna a 0 para reiniE = error
D = DATOS
ciar la cuenta.
B = Fin de texto (EOT)
Y = ACK
El campo TYPE define al tipo de
Z = Fin de archivo (EOF)
N = NAK
paquete. En la figura se presentan
T = reservado
S = enviar paquete de inicio
estos tipos.
X = visualizar texto en pantalla
F = cabecera de archivo
A = atributo
El campo DATA contiene los datos
del usuario o informacin de conFigura 8.13 El paquete de protocolo Kermit y sus tipos
trol respecto a la transferencia del
archivo o bien no muestra nada.
El campo CHECK sirve para precisar si el paquete se da en la transmisin. El Kermit permite
varias opciones: una de ellas usa un Checksum simple y la otra, un Chequeo Redundante Cclico.

8.5

ARQUITECTURA DE COMUNICACIONES ENTRE COMPUTADORAS

Habiendo introducido el concepto de protocolo, ahora presentaremos el concepto de arquitectura

de comunicaciones entre computadoras. Para tal efecto establecemos las siguientes premisas:
La tarea para comunicarse entre dos entidades de sistemas diferentes es demasiado complicada para ser manejada por un solo proceso o un solo mdulo. Debe haber un alto grado de cooperacin entre las dos computadoras. La tarea puede ser dividida en varias tareas menores, cada
una de las cuales pues ser implementada por separado.
Retornemos a nuestro ejemplo de la aplicacin de transferencia de archivos que requiere
efectuar cuatro tareas, que ya hemos enumerado en la tabla 8.1. De las cuatro tareas, la 3 y la 4
pueden ser llevadas a cabo por un protocolo de nivel de aplicacin orientado a la comunicacin
implementada en el paquete de transferencia de archivos. Los respectivos mdulos en los dos sistemas intercambian archivos y comandos. Luego, para que estos paquetes de transferencia de archivos intercambien datos, cada uno invocar al mdulo de servicio de comunicaciones respectivo. Estos mdulos son responsables de asegurar que los comandos y datos que realicen la transferencia de archivos sean confiablemente intercambiados entre los sistemas. Es decir que, entre
otras tareas, los mdulos de servicios de comunicaciones ejecutarn la tarea 2 usando un protocolo de sistema a sistema.
Finalmente se procede a transferir los datos a la red. Para tal efecto, debe notarse en este
punto que la naturaleza del intercambio de datos entre los sistemas es independiente de la naturaleza de la red con que ambos se interconecten. Por ello, en vez de implementar la interface con la
red en el mdulo de servicios de comunicaciones, es preferible hacer un tercer mdulo: uno de acceso a la red, que se encargue de realizar la tarea 1 para interactuar con la red.
As, observamos que, en vez de un solo protocolo, hay un conjunto estructurado de protocolos que implementan la funcin de comunicaciones, estructura que se conoce como una arquitectura de comunicaciones de computadoras.

8.6

UN MODELO DE TRES CAPAS

De acuerdo al ejemplo y en trminos generales las comunicaciones de datos involucran a tres

agentes tales como: aplicaciones, computadoras y redes. Por lo cual, parece natural organizar la
108

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

tarea de comunicaciones en tres capas relativamente independientes, tales como:

Capa de acceso a la red.
Aplicacin de
archivos y comandos de
Capa de transporte.
transferencia
transferencia de archivos
de archivos
Capa de aplicacin.
Estas capas se ilustran en la figura 8.14.
Mdulo de
8.6.1

servicios de

mensajes relacionados

Aplicacin de
transferencia
de archivos
Mdulo de
servicios de

CAPA DE ACCESO A
a comunicaciones
comunicaciones
comunicaciones
LA RED
Mdulo de
Mdulo de
Esta capa incluye el intercambio de datos
acceso a
acceso a
Red de
la red
la red
comunicaciones
entre la computadora y la red a que se
conecte. La computadora que llama o
interfase
interfase
computadora origen, la cual enva inlgica de red
lgica de red
formacin, debe proporcionar a la red la
direccin de la computadora a la que est
Figura 8.14 Capas del modelo de arquitectura de
llamando o computadora destino, de tal
comunicacin entre computadoras
manera que la red pueda enrutar los datos a la direccin apropiada. Adems podra invocar ciertos servicios a la red tal como prioridad
que podran ser proporcionados por la red.
El software especfico usado en esta capa depende del tipo de red; para lo cual se han
desarrollado diferentes normas para conmutacin de circuitos, conmutacin de paquetes, redes de
rea local y otros. Por esta razn, tiene sentido separar estas funciones que tienen que ver con el
acceso a la red. De esta manera, el software restante que se encuentra sobre esta capa de acceso a
la red no tiene que estar involucrado en los aspectos especficos de la red que han de utilizarse. Es
decir, el mismo software de alto nivel debera funcionar apropiadamente sin tener en cuenta el tipo de red a la que se conecte la computadora.
8.6.2
CAPA DE TRANSPORTE
Esta capa es la encargada de que los datos sean intercambiados confiablemente. Esto es, nos gustara que nos aseguren que todos los datos lleguen a la aplicacin destino y que ellos lleguen en el
mismo orden en el que fueron enviados. Para este efecto es necesario tener mecanismos que nos
proporcionen confiabilidad, los cuales, conforme veremos posteriormente son esencialmente independientes de la naturaleza de las aplicaciones.
8.6.3
CAPA DE APLICACIN
Esta capa contiene toda la lgica necesaria para soportar diversas aplicaciones de usuario. Para
cada tipo diferente de aplicacin, es necesario un mdulo separado, pertinente para ella.

8.7

MODELO OSI. ASPECTOS GENERALES

El propsito de este modelo de referencia internacional de normas de interconexin de sistemas

abiertos es proporcionar una base comn para la coordinacin de normas relacionadas con el propsito de interconectar sistemas, a la vez que se permite que las normas existentes sean colocadas
en una perspectiva dentro del modelo de referencia general.
El trmino interconexin de sistemas abiertos (OSI Open System Interconnection) califica normas para el intercambio de informacin entre sistemas que son abiertos uno al otro en virtud del uso mutuo de las normas aplicables. Que un sistema sea abierto no implica ninguna implementacin particular de sistemas, tecnologa, o medios de interconexin, sino se refiere al mutuo reconocimiento y soporte de normas aplicables. Tambin es propsito de esta norma internacional identificar reas para desarrollar o mejorar las normas, y dar una referencia comn para
mantener la consistencia de todas las normas relacionadas. Estas normas internacionales no intentan servir como una especificacin de implementacin, o servir de base para la aprobacin de las
implementaciones actuales, o proveer el suficiente nivel de detalle para definir con precisin los
servicios y protocolos de la arquitectura de interconexin; en vez de esto, brindan una estructura
conceptual y funcional que permite a los grupos de expertos internacionales trabajar productiva e
109

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

independientemente para desarrollar normas para cada capa del modelo de referencia de la OSI.
8.7.1

PRINCIPIOS DE ESTRUCTURA DE CAPAS

Una tcnica estructural ampliamente aceptada y elegida por la ISO es la de estructura de capas o
de niveles (layering). Las funciones de comunicaciones son particionadas en un conjunto vertical
de capas. Cada capa lleva a cabo un subconjunto de funciones requeridas para comunicarse con
otro sistema. sta se basa en la capa prxima de ms bajo nivel para llevar a cabo funciones ms
primitivas y para coordinar los detalles de estas funciones. Esta capa provee servicios a la prxima capa ms alta. Idealmente, las capas deberan estar definidas de tal manera que los cambios en
una capa no requieran cambios en otra capa. De esta manera, se divide un problema en un mayor
nmero de problemas ms pequeos y, por ende, ms manejables.
Los principios usados en definir las capas OSI son las siguientes:
No crear ms capas de las que sean estrictamente necesarias.
Crear una frontera en un punto donde la descripcin de servicios puede ser pequea y el nmero de interacciones a travs de la frontera sea minimizada.
Crear capas separadas para manejar funciones que son manifiestamente diferentes en el proceso llevado a cabo o en la terminologa involucrada.
Aglutinar funciones similares dentro de la misma capa.
Seleccionar barreras en un punto donde la experiencia pasada haya demostrado que sean exitosas.
Crear una capa que tenga funciones localizadas fcilmente, de tal manera que la capa pueda
ser totalmente rediseada y sus protocolos cambiados en una mayor manera para tomar ventaja de los nuevos avances en la tecnologa arquitectural, de hardware y de software sin cambiar los servicios esperados desde y provistos por las capas adyacentes.
Crear una frontera donde pueda ser til algn punto en el tiempo, para tener una interface correspondiente normalizada.
Crear una capa donde haya la necesidad de diferentes niveles de abstraccin en el manejo de
los datos, tal como por ejemplo: morfologa, sintaxis, semntica, etc.
Permitir cambios de las funciones de los protocolos que han de hacerse dentro de la capa sin
afectar a otras capas.
Crear fronteras para cada capa, para su capa superior y su capa inferior solamente. Similares
principios han sido aplicados a las subcapas.
Crear ms subgrupos y organizaciones o funciones para formar subcapas dentro de una capa
en casos donde servicios de comunicaciones distintivos lo requieran.
Crear, cuando sea necesario, dos o ms capas con una funcionalidad, aunque sea mnima, para permitir una operacin de interface con las capas adyacentes.
Permitir el by-pass de las subcapas.
El atractivo del enfoque del modelo OSI es su promesa de resolver el problema de comunicaciones entre computadoras heterogneas. Dos sistemas, no importantes cuan diferentes sean,
pueden comunicarse efectivamente si ellos tienen en comn lo siguiente:
Que ellos implementen el mismo conjunto de funciones de comunicaciones.
Que estas funciones estn organizadas en el mismo conjunto de capas. Capas pares deben
proveer la misma funcin, pero ntese que no necesariamente ellas deben proveerlas en la
misma manera. Las capas pares deben compartir un protocolo comn.
8.7.2

EL MODELO OSI

Ampliando el concepto anterior, la tabla 8.2 nos presenta la estructura de un conjunto de protocolos de capas en una forma de jerarqua y en la figura 8.15 se diagrama el modelo de interconexin
de sistemas abiertos (Open Systems Interconnection - OSI) o modelo OSI.
110

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

Este modelo lo desarroll la Organizacin Internacional de Normalizacin (International Standards Organization ISO) como
un modelo de arquitectura de comunicaciones entre computadoras
y es la estructura bsica para el
desarrollo de las normas de los
protocolos.
Brevemente definiremos
las funciones de cada capa. Este
modelo permite el desarrollo de
los protocolos que efectan las
funciones de cada nivel de manera independiente.

8.8

RED DE
CONMUTACIN DE
PAQUETES X.25

Una red de conmutacin de paquetes tiene cinco componentes

principales, que mostramos en la
tabla 8.3 y en la figura 8.16. Estos
son los siguientes:
1.
2.
3.
4.
5.

Componentes de acceso local

Concentradores
Nodos de conmutacin
Enlaces troncaleros
Centro de gestin de red

N I V E L

6
7

Tabla 8.2 Modelo OSI de 7 capas o niveles

APLICACIN X

A continuacin, describimos la
composicin y funciones de estos grupos.

TRANSPORTE

Estos comprenden: terminal del

usuario, mdems y enlaces de
acceso local.

APLICACIN X
APLICACIN

AH datos de aplicacin

PRESENTACIN

SESIN

COMPONENTES DE
ACCESO LOCAL

datos de aplicacin

APLICACIN

Tabla 8.3 Componentes de una red

8.8.1

F U N C I N

Posibilita la transmisin de un tren de bits no estructurados sobre el medio fsico.

FSICO
Trata con las caractersticas: mecnicas, elctricas, funcionales y de procedimiento.
Permite una transferencia confiable de informacin
a travs del enlace fsico. Enva bloques de datos
ENLACE
(tramas) con la sincronizacin necesaria y los requeridos controles de flujo y de errores.
Provee a las capas superiores la independencia de
las tecnologas de transmisin y conmutacin de
RED
datos usadas para interconectar los sistemas. Es
responsable de establecer, mantener y terminar
las conexiones a nivel de la red.
Transfiere datos transparente y confiablemente enTRANSPORTE tre los puntos extremos, proporcionando control de
flujo y recuperacin de errores.
Provee la estructura de control para las comunicaciones entre aplicaciones. Establece, administra y
SESIN
termina las conexiones (sesiones) entre aplicaciones cooperativas.
Proporciona independencia a los procesos de apliPRESENTACIN cacin de las diferencias de las representaciones
de datos (sintaxis).
Brinda a los usuarios acceso al ambiente OSI y
APLICACIN
proporciona servicios de informacin distribuida.

PH
SH
TH

RED

NH

ENLACE

FAC

unidad de datos

PRESENTACIN

unidad de datos

SESIN

unidad de datos

TRANSPORTE

unidad de datos
datos (campo - I)

RED
FCS F

bits

FSICO

ENLACE
FSICO

Trayectoria de comunicaciones
Figura 8.15 Operacin del modelo OSI

a)
Terminal de usuario
ste puede ser un computador principal con un procesador de comunicaciones, un computador
personal emulando a un terminal asncrono o un controlador de comunicaciones que tiene conectados varios terminales.
b)
Mdems
Estos son dos mdems sncronos, con velocidades desde 9,6 a 64 Kbps, los cuales estn instalados: uno, en el lado del usuario y otro, en el lado de la red.
111

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

c)
Enlaces de acceso local
Estos estn conformados por las lneas telefnicas dedicadas o conmutadas, segn sea el caso. Estas lneas
tambin pueden ser canales va enlaces PCM, microondas o fibra ptica.

NCC

8.8.2
CONCENTRADORES
Este equipamiento se encarga de
concentrar a los terminales. Sus funciones principales se presentan en la
tabla 8.4.
F U N C I N

1
2
3
4
5
6
7

Agrupar varios terminales de usuario a

fin de que compartan un enlace.
Asegurar la compatibilidad entre los
terminales de los usuarios y los nodos
de la red de conmutacin.
Establecer y liberar las llamadas.
Entregar paquetes a los nodos de
conmutacin.
Convertir cdigos de ser necesario
( A S C I I a E B C D I C ).
Adaptar velocidades de transmisin.
Enviar informacin del destino y la duracin de la llamada para facturar.

Tabla 8.4 Funciones del concentrador

8.8.4

F U N C I N

Almacenamiento y mantenimiento de base

1 de datos de configuracin de la red (nodos,
concentradores).
Configurar las interfaces de usuarios, puer2
tas de nodos y concentradores.
3

Cargar el software de configuracin de los

nodos y concentradores.

Coleccin de las estadsticas de operacin

de nodos y concentradores.

Recepcin de alarmas de averas en los

nodos y concentradores.

6 Pruebas de comportamiento de la red.

7 Recoleccin de datos para facturacin.
Tabla 8.6

Funciones del centro de

gestin

Concentrador

Enlace troncalero

Conmutador

2 enlaces de concentrador

NCC

Centro de gestin

Figura 8.16 Diagrama de una red de

conmutacin de paquetes

En el concentrador se paquetiza la informacin hacindola completamente compatible para la red de

conmutacin de paquetes. Para adaptar cualquier protocolo (Asncrono, SDLC) se carga en el concentrador
un software denominado PAD (Packet Assembler Disassembler). El concentrador trabaja en concordancia
con el computador central, y es un equipo informtico
programable y con funciones complejas
8.8.3
NODOS DE CONMUTACIN
Son los nodos que conforman la red troncal (Backbone). Sus funciones se presentan en la tabla 8.5.

ENLACES
TRONCALEROS DE RED

Son los enlaces fsicos que interconectan a los nodos de conmutacin los
cuales son transportados va microon-

Componentes de acceso local

F U N C I N

Asegurar que los paquetes se enruten desde su nodo origen

1
hasta el nodo destino.
Proveer medios de proteccin contra errores (retransmitiendo
2
paquetes cuando es necesario).
3 Restablecer las llamadas despus de fallas.
Proporcionar informacin para diagnstico de comportamiento
4
de la red.
5 Soportar el acceso directo de computadores X.25 (hosts).
Tabla 8.5 Funciones de los nodos de conmutacin

das, satlite y fibra ptica. Estos enlaces generalmente son dos entre cada nodo, con fines de redundancia
y sus velocidades de transmisin son del rango de
9.6, 19,2; 28,8 y 64 Kbps.
8.8.5
CENTRO DE GESTIN
Este centro es el responsable del control y monitorizacin de la red y sus funciones principales se muestran en la tabla 8.6.
La base de datos es una copia maestra de todo el
112

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

software de operacin y configuracin que se encuentra residente en los nodos y concentradores

de la red. All se encuentran las tablas de enrutamiento y los perfiles de las interfaces de los usuarios. El NCC tiene terminales de consola, por los cuales un operador puede administrar la red.

8.9

ARQUITECTURA DE REDES

Existen arquitecturas de red propietarias tales como la SNA (Systems Network Architecture) de
IBM, la DNA (Digital Network Architecture) de la DEC (Digital Equipment Corporation). Por
otro lado hay arquitecturas abiertas tales como la OSI (Open Systems Interconnection) de la ISO
(International Standards Organization).
En la tabla 8.7, mostramos los niveles de la arquitectura de la red DECnet/DNA:
En la fase IV de DECnet, la
DECnet/DNA
N I V E L
DEC cambi la arquitectura
7 Aplicacin: Presenta aplicaciones
Terminal Remoto para software
DNA para que se pareciese
del usuario.
VAX.
tanto como fuera posible a
6 Presentacin: Traduce datos.
Protocolo de acceso a los datos
la arquitectura OSI. DEC( DAP-Data Access Protocol ).
net Phase IV est construi5 Sesin: Controla el dilogo.
Servicio de nombres distribuidos
do alrededor de la arquitec( DNS-Distributed Name Service).
tura de protocolos DECnet
4 Transporte: Asegura integridad de Protocolo de Servicios de Red
y DECnet Phase V usa los
los mensajes.
( NSP-Network Service Protocol ).
protocolos DECnet y OSI.
DECnet tiene una orienta3 Red: Encamina transmisiones.
Protocolo de encaminamiento
cin al paradigma par - a IS IS.
par tanto en la red fsica y
2 Enlace: Detecta errores.
DDCMP, Ethernet, HDLC, X.25.
los niveles de protocolos
1 Fsico: Conecta dispositivos a la red. Ethernet Primaria.
comparado con la red SNA
Tabla 8.7 Arquitectura SNA
de IBM.
8.9.1

ARQUITECTURA SNA DE IBM

La SNA aparece en 1974, siendo el esquema de interconexin de la familia de los productos 3270.
Aqu se incluyen computadoras centrales (Hosts), sistemas de tipo medio, terminales 3270 y
computadoras de sobremesa (Desktop).
Esta breve introduccin servir para distinguir cmo el SNA, arquitectura jerrquica y
centralizada, encaja en los paradigmas par - a - par y cliente - servidor de hoy en da. SNA se dise
en los das en que un gran nmero de terminales no programables se conectaban a los Host de
IBM. Esta arquitectura proporcionaba un enrutamiento esttico, de tal manera que un usuario que
estuviese trabajando en uno de los terminales pudiera accesar a cualquiera de los host interconectados. Antes del SNA, los usuarios tenan que abrir una sesin en un terminal diferente y en una
lnea diferente para cada anfitrin. Las aplicaciones podran comunicarse con terminales usando
uno de los varios mtodos de acceso, por ejemplo: la opcin de comparticin de tiempo (Time
Sharing Option TSO) usaba el mtodo de acceso de telecomunicaciones (Telecommunications
Access Method TCAM) y el Sistema de Control de Informacin de Usuario (Customer Information Control System CICS) us el Mtodo Bsico de Acceso a Telecomunicaciones (Basic Telecommunications Access Method BTAM) y el Subsistema de Ingreso de Trabajos (Job Entry
Subsystem JES) utiliz el Mtodo de Acceso de Terminal Remoto (Remote Terminal Access
Method RTAM). Una de las caractersticas originales fue la comparticin de terminales, la cual
fue implementada usando el VTAM como el mtodo comn de acceso a telecomunicaciones para
las aplicaciones de Host. En esa poca se estaba desarrollando el TCP/IP, que tena el objetivo de
interconectar computadores de diferente tamao, incluso computadoras personales y no slo
Hosts. Es decir, TCP/IP se dise para los ambientes par - a - par, predominantes en la actualidad.
El SNA no es apropiado para ambientes multiprotocolos, multivendedor, cliente-servidor
y par - a - par, dominantes hoy en da. Estos paradigmas se crearon, fundamentalmente a nivel de113

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

partamental, a fin de que cada administrador diseara y construya su propia red de rea local
(LAN), la cual se interconectara con otras LAN en la red corporativa de la empresa.
Frente a esta situacin, IBM introdujo las Comunicaciones Avanzadas entre Programa y
Programa (Advanced Program - to - Program Communications APPC) para permitir la comunicacin entre programas y la Conectividad Avanzada Par - a - Par (Advanced Peer - to - Peer Networking APPN) para hacer frente al TCP/IP.
El APPN proporciona un entorno descentralizado de computacin de red, que permite a
sistemas grandes y pequeos actuar como pares.
La estrategia ms reciente de IBM, BluePrint, consiste en continuar apoyando al APPN a
la vez que adopta los protocolos TCP/IP y OSI. Un ejemplo es el Multiprotocolo de Red de
Transporte (Multiprotocol Transport Network MPTN), que independiza a las aplicaciones de los
protocolos de red de capas subyacentes, logrndose de esta manera que una aplicacin escrita para
un cierto protocolo de red pueda ser utilizada por otros protocolos de ese nivel.
En la figura siguiente se comparan la pila (stack) de los protocolos SNA con sus similares del modelo OSI. Es interesante destacar que la ISO confeccion el modelo OSI utilizando como modelo a la arquitectura de IBM.
El nivel fsico permite muchas conexiones diferentes.
En nivel enlace de datos define al protocolo SDLC (Syncronous Data Link Control) y al
protocolo de red LAN Token Ring.
El control de trayectoria controla en enrutamiento y puede dividir los datagramas y reensamblarlos para adaptarlos a los medios de transmisin.
El nivel de transmisin define los servicios orientados a la conexin que permiten establecer
enlaces entre dos puntos terminales para controlar el flujo de datos y garantizar su entrega.
El nivel de flujo de datos administra las conversaciones entre los puntos extremos a fin de
evitar congestin y prdida de datos.
El nivel de presentacin se encarga de las conversiones de los datos y las interfaces con las
aplicaciones.
El nivel de transaccin provee la interface a las aplicaciones para accesar a servicios de red
Una red SNA consta de
Hosts, controladores de
comunicaciones, controladores de grupo, multiplexores, terminales (mquinas
PC con programas de emulacin) y perifricos (p.e:
impresoras).
8.9.2 ARQUITECTURA
DE SISTEMAS
ABIERTOS DE
WINDOWS
La arquitectura WOSA
(Windows Open Systems
Architecture) de Microsoft
(figura 8.17) permite el desarrollo de aplicaciones sobre las plataformas del entorno Windows. Incluye interfaces modulares, diversas API (Application Program Interface) para la

Procesador
de texto con
capacidad
de correo

Base de datos
frontal

Aplicacin
de correo

Otras
aplicaciones

APIs de Windows
Interface Proveedora de Servicios (Service Provider Interface-SPI)

Sistema de
mensajera
Servicios de
impresin
Sistema distribuido
de archivos

Funciones de
Administracin

Servicios de
directorio

Administracin
de licencias

Seguridad
Sistema de
mensajera

Figura 8.17 Arquitectura WOSA

114

CAP. 8 ARQUITECTURA DE COMUNICACIONES. MODELO GENERALIZADO DE PROTOCOLOS

programacin de aplicaciones, permitiendo que una aplicacin creada tenga acceso a los servicios
de red como el correo electrnico, bases de datos y conexiones con servidores. Es una estrategia
tipo Middleware, las cual est integrada con el sistema operativo a fin de permitir el desarrollo de
aplicaciones en grupos de trabajo, de manera que los usuarios puedan colaborar entre s.
Dentro de WOSA estn integrados Windows for Workgroups, Mail y Scheduler+. WOSA
tambin se usa para la implementacin de la Vinculacin e Incrustacin de Objetos (Object Linking and Embedding OLE) y el nuevo sistema operativo orientando a objetos llamado Cairo.
WOSA tiene una API para las aplicaciones cliente y una Interface Proveedora de Servicios (Service Providers Interface - SPI) para las aplicaciones servidoras. Con una SPI un vendedor de bases de datos puede crear un dispositivo de base de datos compatible con WOSA para el
entorno Windows. De esta manera, los desarrolladores de aplicaciones cliente pueden crear interfaces para accesar a la base de datos sin tener que escribir el cdigo especfico de ese dispositivo.
Los siguientes componentes del WOSA son:
Interface de Programacin de Aplicaciones de Mensajera (Messaging Application Programing Interface MAPI): Proporciona acceso a las funciones del correo electrnico a la
vez que se trabaja dentro de otras aplicaciones tales como un procesador de textos, etc. Compite con la mensajera independiente del fabricante (Vendor Independent Messaging VIM)
que es soportada por Lotus, IBM, Apple, Novel y Borland.
Conectividad de bases de datos abierta (Open Database Connectivity ODBC): Define las
conexiones entre los componentes del sistema operativo Windows y los servicios de base de
datos frontales (Front-end) y posteriores (Back-end). Permite el acceso a cualquier dato almacenado en cualquiera de los servidores que se encuentren en la red.
API de Windows Socket: Este software resuelve las incompatibilidades entre las muchas variedades de TCP/IP para Windows que existen. Est desarrollado en base al Berkeley Sockets,
desarrollado por la Berkeley Software Distribution (BSD) versin 4.3 de la Universidad de
Califormia (Berkeley). Proporciona servicios orientados a la conexin y datagramas.
API para SNA: Establece el modo como las aplicaciones Windows acceden a los Host IBM.
API del servidor de licencias: Ayuda a que los administradores observen y controlen el uso.

115