Redes de Área Amplia (WAN)

Una red de área amplia puede ser descripta como un grupo de redes
individuales conectadas a través de extensas distancias geográficas. Los
componentes de una red WAN típica incluyen:

• Dos o más redes de área local (LANs) independientes.

• Routers conectados a cada LAN
• Dispositivos de acceso al enlace (Link access devices, LADs)
conectados a cada router.

• Enlaces inter-red de área amplia conectados a cada LAD

La combinación de routers, LADs, y enlaces es llamada inter-red.

La inter-red combinada con las LANs crea la WAN.

Un dispositivo de acceso al enlace (LAD) es necesario para convertir las

señales para ser transmitidas desde la LAN en un formato compatible con el
tipo de enlace de área amplia inter-red utilizado.

Las conexiones entre LADs pueden ser punto a punto o a través de la red
intermedia de un proveedor de servicios de red.

Nota: Una red intermedia se define como una red utilizada para conectar dos o
más redes.
En un enlace punto a punto, los LADs se comunican directamente entre sí
sobre un circuito de telecomunicaciones. Este circuito puede ser temporal,
como el de una red conmutada de telefonía pública, o permanente, por ejemplo
una línea de datos dedicada contratada a un proveedor.

Algunos ejemplos de LAD incluyen:

• Modem.
• Data service unit/channel service unit (DSU/CSU).
• Terminal adapter (TA).
• Packet assembler/disassembler (PAD).
• Frame Relay access device (FRAD).

En un enlace de red intermedia, los LAD son conectados una red de transporte
de datos, controlada y administrada por uno o más proveedores de servicios de
red. Las conexiones al proveedor de servicios de red son realizadas usando
enlaces punto a punto temporales o permanentes. Una vez que los datos son
recibidos por el proveedor de servicios de red, son transferidos hasta la LAN de
destino a través de una red de área amplia inter-red dedicada.

Los proveedores de servicio de red reciben múltiples flujos de datos en forma

simultánea desde varias organizaciones. Todos los datos son transferidos un
paquete a la vez por la red del proveedor de servicios, potencialmente con
cada paquete tomando un camino diferente. El enrutamiento se basa en la
información de direccionamiento incluida en el paquete.

Existen muchas conexiones y rutas posibles en la topología en forma de malla

de la red del proveedor. Varias tecnologías de enrutamiento y conmutación a
alta velocidad son utilizadas por el proveedor de servicios de red para dirigir los
paquetes hasta su destino. Dado que existen múltiples caminos, un paquete
puede ser enrutado para evitar cualquier falla o área congestionada de la red,
el enrutamiento del paquete es dinámico.

Cuando se usan las redes de alta velocidad de un proveedor de servicos de red

como enlaces de red intermedios, no existe un circuito predefinido de extremo
a extremo entre las LAN comunicadas; es por ello que las tasas de transmisión
de la inter-red pueden ser aumentadas o disminuidas según se requiera
mediante acuerdos con el proveedor de servicios de red.

Internet es la red intermedia global más grande. Otros ejemplos incluyen redes
satelitales y de relevo de tramas (Frame Relay).

X.25

Uno de los protocolos estándar más ampliamente utilizado es X.25 del ITU-T,
que fue originalmente aprobado en 1976 y que ha sufrido numerosas revisiones
desde entonces. El estándar especifica una interfaz entre un sistema host y
una red de conmutación de paquetes. Este estándar se usa de manera casi
universal para actuar como interfaz con una red de conmutación de paquetes y
fue empleado para la conmutación de paquetes en ISDN. El estándar emplea
tres niveles de protocolos:

• Nivel físico
• Nivel de enlace
• Nivel de paquete

Estos tres niveles corresponden a las tres capas más bajas del modelo OSI. El
nivel físico define la interfaz física entre una estación (computadora, terminal)
conectada a la red y el enlace que vincula esa estación a un nodo de
conmutación de paquetes. El estándar denomina a los equipos del usuario
como equipo terminal de datos – DTE (Data Terminal Equipment) y al nodo
de conmutación de paquetes al que se vincula un DTE como equipo terminal
de circuito de datos – DCE (Data Cicuit-terminating Equipment). X.25 hace
uso de la especificación de la capa física X.21, pero se lo sustituye en muchos
casos por otros estándares, tal como RS-232 de la EIA.

Figura 1. Uso de los Circuitos Virtuales

El nivel de enlace garantiza la transferencia confiable de datos a través del

enlace de datos, mediante la transmisión de datos mediante una secuencia de
tramas. El estándar del nivel de enlace se conoce como LAPB (Link Access
Protocol Balanced). LAPB es un subconjunto de HDLC de ISO en su variante
ABM (Asynchronous Balanced Mode).

El nivel de paquete ofrece un servicio de circuito virtual externo. Este servicio le

permite a cualquier subscriptor de la red establecer conexiones lógicas,
denominados circuitos virtuales, con otros subscriptores. Un ejemplo de esto
se muestra en la Figura 1. En este ejemplo, la estación A tienen establecidos
dos circuitos virtuales uno con B y otro con D; la estación C posee una
conexión de circuito virtual con D; y el servidor B tiene establecida una
conexión de circuito virtual con D.

En este último nivel, por cada acceso a la red, se definen dos entidades, DTE y
DCE, que representan al sistema final del usuario y a la red respectivamente.
En términos generales, hay dos categorías de DTEs: los que operan en modo
de paquetes y los que no lo hacen; estos últimos, no soportan en forma nativa
los protocolos X.25, por lo que requieren de los servicios de sistemas
intermediarios encargados de realizar las correspondientes adaptaciones,
generalmente denominados PADs (Packet Assembler/Disassembler).

La Figura 2 muestra la relación entre los niveles de X.25. Los datos de usuario
se pasan en forma descendente al nivel 3 de X.25, el cual le agrega
información de control como una cabecera, creando un paquete.
Alternativamente, los datos de usuario se pueden segmentar dentro de
múltiples paquetes. La información de control del paquete sirve para varias
finalidades, entre las que se incluyen las siguientes:

1. Identificar el número de un circuito virtual particular al que se deben

asociar estos datos.
2. Proveer números de secuencia que se pueden utilizar para controlar el
flujo y los errores sobre la base de circuitos virtuales.

Luego, el paquete X.25 completo se pasa a la entidad LAPB, la cual agrega

información de control al principio y al final del paquete, formando una trama
LAPB. Nuevamente, la información de control contenida en la trama se
requiere para la operación del protocolo LAPB.

Servicio de circuito virtual

El servicio de circuito virtual que ofrece X.25 proporciona dos tipos de

circuitos virtuales. Una llamada virtual (virtual call) es un circuito virtual que
se establece dinámicamente utilizando los procedimientos de establecimiento
de llamada (call setup) y de liberación de llamada (call clearing). Un circuito
virtual permanente (permanent virtual circuit) es un circuito virtual fijo
asignado por la red; la transferencia de datos se produce igual que con las
llamadas virtuales, pero no se requiere del establecimiento o la liberación.

La Figura 3 muestra una secuencia típica de eventos sobre un circuito virtual.

La parte ubicada a la izquierda de la figura muestra los paquetes
intercambiados entre la máquina del usuario A y el nodo de conmutación de
paquetes al cual ésta se vincula; la parte derecha de la figura muestra los
paquetes que se intercambian entre la máquina de usuario B y su nodo. El
encaminamiento de los paquetes dentro de la red no es visible al usuario.

Figura 3. Secuencia de eventos en el protocolo X.25

La secuencia de eventos es la siguiente:

1. A solicita un circuito virtual a B mediante el envío de un paquete Call

Request al DCE de A. El paquete incluye las direcciones fuente y
destino, como así también el número de circuito virtual que se utiliza
para este nuevo circuito virtual. Las futuras transferencias entrantes y
salientes se identificarán por medio del número de circuito virtual.
2. La red encamina esta solicitud de llamada hacia el DCE de B.
3. El DCE de B recibe el Call Request y le envía a B un paquete Incoming
Call. Este paquete tiene el mismo formato que el paquete Call Request,
pero un número de circuito virtual diferente, seleccionado por el DCE
de B a partir del conjunto de números locales fuera de uso.
4. B indica la aceptación de la llamada mediante el envío de un paquete
Call Accepted especificando el mismo número de circuito virtual que el
paquete Incoming Call.
5. El DCE de A recibe el Call Accepted y le envía a A un paquete Call
Connected. Este paquete tiene el mismo formato que el paquete Call
Accepted pero el número de circuito virtual indicado en el paquete Call
Request original.
6. A y B se intercambian paquetes de datos y de control utilizando sus
respectivos números de circuito virtual.
7. A (o B) envía un paquete Clear Request para terminar el circuito virtual
y recibe un paquete Clear Confirmation.
8. B (o A) recibe un paquete de indicación Clear Indication y transmite un
paquete Clear Confirmation.

Veamos ahora algunos de los detalles de este protocolo.

Formato del paquete X.25

Cableado Estructurado Venta y repracion de computadoras

Figura 4. Formatos de paquetes X.25

La Tabla 1 ilustra los formatos básicos de paquete utilizados en X.25. Para el

caso de datos de usuarios, los datos se dividen en bloques de un tamaño
máximo, y se agrega a cada bloque una cabecera de 24-bits, 32-bits o 56-bits,
conformando así un paquete de datos. Para el caso de los circuitos virtuales
que utilizan números de secuencia de 15-bits, la cabecera comienza con un
octeto identificador de protocolo con el valor 00110000.

La cabecera incluye un número de circuito virtual de 12-bits (contenido en los

campos Group Number y Channel Number). Sobre cada circuito virtual, se
aplican las funciones de control de flujo y de control de errores por medio de los
campos P(S) y P(R). El bit Q no está definido en este estándar, pero le permite
al usuario distinguir dos tipos de datos.

Tipo de paquete Servicio Parámetros

DTE a DCE DCE a DTE VC PVC
Call Setup y Clearing
Call Request Incoming Call X Calling DTE
address,
Called DTE
address,
facilities, call
user data
Call Accepted Call Connected X Calling DTE
address,
Called DTE
address,
facilities, call
user data
Clear Request Clear Indication X Calling DTE
address,
Called DTE
address,
facilities, call
user data
Clear Confirmation Clear Confirmation X Calling DTE
address,
Called DTE
address,
facilities, call
user data
Data e Interrupt
Data Data X X ---
Interrupt Interrupt X X Interrupt
user data
Interrupt Confirm. Interrupt Confirm. X X ---
Control de flujo y Reset
RR RR X X P(R)
RNR RNR X X P(R)
REJ X X P(R)
Reset Request Reset Indication X X Resetting
cause,
diagnostic
code
Reset Confirm. Reset Confirm. X X ---
Restart
Restart Request Restart Indication X X Restarting
cause,
diagnostic
code
Restart Confirm. Restart Confirm. X X ---
Diagnostic
Diagnostic X X Diagnostic
code,
diagnostic
explanation

Tabla 1. Tipos de paquetes y sus parámetros asociados

Además de transmitir datos de usuario, X.25 debe transmitir información de

control relacionada con el establecimiento, mantenimiento y terminación de los
circuitos virtuales. La información de control se transmite en un paquete de
control. Cada paquete de control incluye un número de circuito virtual, definido
por los campos Group Number y Channel Number; el campo Packet Type,
que identifica la función de control particular; e información de control
adicional relacionada con esa función. Por ejemplo, un paquete Call Request
incluye los siguientes campos adicionales:

• Calling DTE address length (4-bits): longitud del correspondiente

campo address, expresado en unidades de 4-bits.
• Called DTE address length (4-bits): longitud del correspondiente
campo address, expresado en unidades de 4-bits.
• DTE addresses (variable): las direcciones de los DTE llamante y
llamada.
• Facilities: una secuencia de especificaciones de facilidad. Cada
especificación consta de un código de facilidad de 8-bits y cero o más
parámetros de código. Un ejemplo de una facilidad es “cobro revertido”.

La Tabla 1 lista los paquetes X.25. La mayoría de ellos ya han sido

comentados. Los restantes, serán comentados brevemente.

Un DTE puede enviar un paquete Interrupt que evita los procedimientos de

control de flujo que se aplican a los paquetes de datos. La red ha de entregar
este paquete al DTE de destino con un prioridad superior a la de los paquetes
de datos en tránsito. Un ejemplo del uso de esta facilidad es la transmisión de
un carácter break desde una terminal.

El paquete Diagnostic proporciona un medio para indicar ciertas condiciones

de error que no warrant una reinicialización. El paquete Registration se
emplea para invocar y confirmar facilidades X.25.

Multiplexación en X.25
Tal vez el servicio más importante que provee X.25 es la
multiplexación. Un DTE puede establecer hasta 4095 circuitos virtuales
simultáneos con otros DTEs empleando un único enlace físico DTE/DCE. El
DTE internamente puede asignar estos circuitos de la manera que le resulta
más conveniente. Los circuitos virtuales individuales podrían estar asociados a
aplicaciones, procesos o terminales, por ejemplo. El enlace DTE/DCE realiza la
multiplexación full-duplex. Es decir, en todo momento, un paquete asociado
con un circuito virtual dado se puede transmitir en cualquier dirección.

Número Categoría Asignación

0 Reservado
1 ... i Circuitos VirtualesFijado en el momento de la
Permanentes suscripción
i+1 … i+n Circuitos UnidireccionalesAsignado por el DCE
Entrantes
j+1 … j+n Circuitos VirtualesAsignado por el DCE
Bidireccionales Asignado por el DTE
k .. 4095 Circuitos UnidireccionalesAsignado por el DTE
 Salientes

Tabla 2. Distribución de canales lógicos según el ITU-T

Para poder determinar cuales paquetes corresponden a cada circuito virtual,

cada paquete contiene un número de circuito virtual de 12-bits. La
asignación de los números de circuito virtual sigue la convención descripta en
la tabla 2. El número cero siempre se reserva para paquetes de diagnóstico
comunes a todos los circuitos virtuales. Cuatro categorías de circuitos virtuales
se asignan a rangos contiguos de números. Los circuitos virtuales
permanentes se asignan a números que empiezan en 1. La siguiente
categoría es la de llamadas virtuales unidireccionales entrantes.

Esto significa que sólo las llamadas entrantes provenientes de la red se podrán
asignar a estos números; no obstante, el circuito virtual es bidireccional (full-
duplex). Cuando llega una solicitud de llamada, el DCE selecciona un número
sin utilizar de esta categoría.

La categoría de las llamadas virtuales unidireccionales salientes son

aquéllas iniciadas por el DTE. En este caso, el DTE selecciona un número sin
utilizar de los asignados a este tipo de llamadas.

Esta separación en categorías tiene por finalidad evitar la selección simultánea

del mismo número para dos circuitos virtuales diferentes por parte del DTE y
del DCE.

La categoría de las llamadas virtuales bidireccionales está disponible para la

asignación compartida por el DTE y el DCE.

Control de flujo y control de errores

El control de flujo y el control de errores en el nivel de paquetes de X.25 es

virtualmente idéntico tanto en su formato como en su procedimiento al control
de flujo utilizado por HDLC. Se emplea un protocolo de ventana deslizante.
Cada paquete de datos incluye un número de secuencia de envío, P(S), y un
número de secuencia de recibido, P(R). Por default, se emplean números de
secuencia de 3-bits. Opcionalmente, el DTE puede solicitar, a través del
mecanismo de facilidad del usuario, el uso de números de secuencia de 7-bits
o de 15-bits.

El valor de P(S) lo asigna el DTE en todos los paquetes salientes asociados a

cada circuito virtual; esto es, el P(S) de cada paquete de datos nuevo asociado
a un circuito virtual es mayor en 1 que el del paquete precedente sobre el
mismo circuito virtual, módulo 8 (o módulo 128 o módulo 32768).

P(R) contiene el número del siguiente paquete esperado desde el otro extremo
de un circuito virtual; de esta manera se implementa un mecanismo de
asentimientos embebidos (piggybacked acknowledgment). Si uno de los
extremos no tiene datos para transmitir, puede asentir los paquetes entrantes
utilizando los paquetes de control RR (Receive Ready) y RNR (Receive not
Ready), con el mismo significado que en HDLC. El tamaño de la ventana
default es 2, pero puede establecerse hasta un valor 7 para el caso de números
de secuencia de 3-bits, 127 para el caso de números de secuencia de 7-bits, y
32767 para el caso de números de secuencia de 15-bits.

Los asentimientos (en la forma del campo P(R) de un paquete de datos, RR o

RNR) y, en consecuencia el control de flujo, pueden tener significado local o
extremo-a-extremo, según como se encuentre fijado el bit D. Cuando D=0 (el
caso usual), el asentimiento posee significado local, entre el DTE y la red. Lo
utiliza el DCE local y/o la red para asentir los paquetes y controlar el flujo
proveniente desde el DTE hacia la red. Cuando D=1, los asentimientos
provienen desde el DTE remoto.

El esquema de control de errores es ARQ N-vuelta-atrás. Un asentimiento

negativo tiene la forma de un paquete de control REJ (Reject). Si un nodo
recibe un asentimiento negativo, deberá retransmitir el paquete especificado y
todos los paquetes subsiguientes.

Reset y Restart

X.25 provee dos facilidades para la recuperación de condiciones de error.

La facilidad Reset se utiliza para reinicializar un circuito virtual. Esto significa
que los números de secuencia en ambos extremos se ponen en cero.
Cualquier paquete de datos o interrupción que se encuentre en tránsito, se
pierde. Le corresponde a un protocolo de capa superior la recuperación de
estos paquetes que se pierden. Un Reset se puede disparar debido a un cierto
número de condiciones de error, incluyendo la pérdida de un paquete, un error
en el número de secuencia, congestión, o pérdida de un circuito virtual interno
de la red. En este último caso, los dos DCEs deben reconstruir el circuito virtual
internamente para soportar el circuito virtual externo DTE-DTE. El DTE o el
DCE pueden iniciar un Reset con un paquete Reset Request o Reset
Indication. El receptor responde con un Reset Confirmation.
Independientemente de quién inicie el Reset, el DCE involucrado es el
responsable de informarle al otro extremo.

Una condición de error más seria requiere de un Restart. El envío de un

paquete Restart Request es equivalente al envío de un Clear Request por
todas las llamadas virtuales y un Reset Request por todas las llamadas
permanentes. Nuevamente, o el DTE o el DCE pueden iniciar la acción. Un
ejemplo de una condición de Restart es la pérdida temporaria del acceso a la
red.

Frame Relay
Frame relay, FR o relevo de tramas, al igual que ATM, está diseñado para proveer un
esquema de transmisión más eficiente que X.25. Los estándares para FR maduraron
muchos antes que los de ATM, al igual que los productos comerciales. En
consecuencia, existe una importante base de productos FR instalados. No obstante, el
interés se está trasladando hacia ATM para las redes de alta velocidad.

Introducción

La solución tradicional de conmutación de paquetes hace uso de X.25, la cual determina

la interfaz Usuario-Red. Las características claves de X.25 son las siguientes:

• Paquetes de control de llamada (call control packets) utilizados para establecer y

liberar circuitos virtuales, los que son transportados en el mismo canal y el
mismo circuito virtual que los paquetes de datos. En consecuencia, se utiliza
señalización en-banda.
• La multiplexación de los circuitos virtuales tiene lugar en la capa 3.
• Tanto la capa 2 como la capa 3 incluyen mecanismos de control de flujo y de
control de errores.

Esta solución trae aparejada un considerable overhead. En cada salto dentro de la red, el
protocolo de enlace de datos requiere del intercambio de una trama de datos y una trama
de asentimiento.

Más aún, en cada nodo intermedio, se deben mantener tablas para cada circuito virtual
relacionadas con la administración de la llamada e información asociada a los
mecanismos de control de flujo y control de errores del protocolo X.25.

Todo este overhead se puede justificar cuando existen importantes probabilidades de

error sobre cualquiera de los enlaces de la red, pero deja de serlo en las redes modernas
que emplean facilidades de comunicación digital.

Las redes de hoy en día emplean tecnologías de transmisión digital confiable sobre
enlaces de transmisión confiables de alta calidad (muchas veces fibra óptica). A esto se
suma que, con el uso de fibra óptica y la transmisión digital, se pueden alcanzar altas
tasas de datos. En este ambiente, el overhead de X.25 no sólo resulta innecesario sino
que degrada la efectiva utilización de las altas tasas de datos disponibles.

La tecnología FR ha sido diseñada para eliminar gran parte del overhead que impone
X.25 sobre los sistemas de usuario final y sobre la red de conmutación de paquetes. Las
diferencias principales entre FR y el servicio de conmutación de paquetes X.25 son las
siguientes:

• La señalización de control de llamada se transporta sobre una conexión lógica

separada de la de datos de usuario. En consecuencia, los nodos intermedios no
necesitan mantener tablas de estado o realizar el procesamiento de mensajes
relacionados con el control de llamada sobre la base de llamadas individuales.
• La multiplexación y la conmutación de las conexiones lógicas tienen lugar en la
capa 2 en lugar de la capa 3, eliminando una capa completa de procesamiento.
 • No hay control de flujo ni control de errores salto a salto. El control de flujo y el
control de errores extremo-a-extremo son responsabilidad de una capa superior,
en caso que sean utilizados.

En consecuencia, con FR se envía una sola trama de datos de usuario desde la fuente
hasta el destinatario, y se transporta de vuelta, también dentro de una trama, un
asentimiento generado en una capa superior. No existe intercambio de tramas de datos y
de asentimientos salto-a-salto.

Consideremos las ventajas y desventajas de esta solución. La principal desventaja

potencial de FR, comparado con X.25, es la de haber perdido la habilidad de realizar un
control de flujo y de errores salto-a-salto. (Si bien FR no provee control de flujo y
control de errores, resulta fácil hacerlo en una capa superior). En X.25, los circuitos
virtuales múltiples se establecen por un único enlace físico, y LAPB está disponible en
el nivel de enlace para proporcionar una transmisión confiable desde la fuente hasta la
red de conmutación de paquetes, y desde ésta hasta el destinatario.

Además, en cada salto dentro de la red, se puede utilizarlo como protocolo de enlace de
datos para lograr confiabilidad. Con el uso de FR, este control a nivel de enlace salto-a-
salto se pierde. Sin embargo, dado el incremento de la confiabilidad de las facilidades
de transmisión y de conmutación, esta desventaja no es fundamental.

La ventaja de FR es que se ha mejorado el procesamiento asociado con las

comunicaciones. La funcionalidad del protocolo requerida en la interfaz usuario-red se
reduce, al igual que el procesamiento interno en la red. Como consecuencia de ello,
pueden esperarse menores retardos y mayor throughput. Los estudios indican una
mejora en el throughput de un orden de magnitud o más al emplear FR en comparación
con X.25. La recomendación ITU-T I.233 indica que FR se deberá utilizar con
velocidades de acceso de hasta 2Mbps.

Arquitectura del protocolo Frame Relay

La figura describe la arquitectura de protocolo que soporta el
servicio en modo bearer. Se deben considerar dos planos separados de
operación: el plano de control (plano-C), que tiene que ver con el
establecimiento y liberación de conexiones lógicas, y el plano de usuario
(plano-U), responsable de la transferencia de los datos de usuario entre los
suscriptores. En consecuencia, los protocolos del plano-C se aplican entre un
suscriptor y la red, en tanto que los protocolos del plano-U proveen
funcionalidad extremo-a-extremo.
Figura 1. Arquitectura del protocolo en la interfase Usuario-Red

Plano de Control

El plano-C para los servicios en modo bearer utiliza un canal lógico separado
para la información de control. En la capa de enlace de datos se emplea LAPD
(Q.921) para proporcionar un servicio de control de enlace de datos confiable
(con control de flujo y control de errores) entre el usuario (TE) y la red (NT)
sobre un canal D. Este servicio de enlace de datos es usado para el
intercambio de mensajes de señalización de control Q.933.

Plano de Usuario

Para la transferencia de información entre usuarios finales se utiliza LAPF

(Q.922), que es una versión mejorada de LAPD. En FR sólo se utilizan las
funciones LAPF núcleo (LAPF core) para realizar las tareas de:

• Delimitación, alineación y transparencia de tramas

• Multiplexación y demultiplexación de tramas utilizando el campo
Address
• Inspección de la trama para asegurar si la misma consta de un número
entero de octetos antes de la inserción de zero bit o luego de la
extracción de zero bit
• Detección de errores de transmisión
• Funciones de control de congestión

Las funciones LAPF núcleo en el plano-U conforman una subcapa de la capa

de enlace de datos. Proveen el servicio de transferencia de tramas desde un
suscriptor a otro, sin control de errores ni control de flujo. Además, el usuario
puede optar por la inclusión de funciones adicionales de enlace de datos
(equivalentes a funciones entremo-a-extremo de la capa de red) las cuales no
son parte del servicio FR.

Empleando las funciones núcleo, la red ofrece un servicio de conmutación de

tramas orientado a conexión que opera en la de capa de enlace con las
siguientes propiedades:

• Preservación del orden de transferencia de tramas desde un extremo a

otro de la red.
• Baja probabilidad de pérdida de tramas.
Transferencia de datos de usuario

La operación de FR para la transferencia de datos de usuario se explica mejor

si tenemos en cuenta el formato de la trama (Figura 2). Este formato está el
definido por el protocolo LAPF núcleo, y es similar a los de LAPD y LAPB con
una omisión obvia: no hay campo de control. Este hecho tiene las siguientes
implicancias:

• Hay un solo tipo de trama, el que es utilizado para transportar datos de

usuario. No existen tramas de control.
• No es posible emplear señalización en-banda; una conexión lógica sólo
puede transportar datos de usuario.
• No es posible realizar control de flujo ni control de errores, debido a que
no existen los números de secuencia.
EA Address Field Extension bit
C/R Command/Response bit
FECN Forward Explicit Congestion Notification
BECN Backward Explicit Congestion
Notification
DLCI Data Link Connection Identifier
D/C DLCI o DLCI-CORE control indicator
DE Discart Eligibility

Figura 2. Formato de las tramas del protocolo LAPF núcleo.

Los campos Flag y Frame Check Sequence (FCS) funcionan igual que en
LAPD y LAPB.

El campo Information transporta datos de la capa superior. Si el usuario

selecciona la implementación de funciones de control de enlace de datos
extremo-a-extremo adicionales, entonces este campo contendrá una trama de
enlace de datos; una selección común será el uso del protocolo LAPF completo
(conocido como protocolo de control LAPF), para realizar funciones por encima
del protocolo LAPF núcleo. Debemos observar que el protocolo implementado
de esta manera se aplica estrictamente entre los suscriptores finales y es
transparente para la red FR.

El campo Address posee una longitud default de 2-octetos y se puede

extender a 3 y 4-octetos.

El mismo transporta un identificador de conexión de enlace de datos (DLCI

- data link control identifier) de 10, 17 o 24 bits, respectivamente. El DLCI
cumple la misma función que el número de circuito virtual en X.25: permite que
múltiples conexiones lógicas FR sean multiplexadas sobre un único canal.
Como en X.25, el identificador de conexión sólo tiene significado local: cada
extremo de la conexión lógica asigna su propio DLCI del pool de números local
no utilizados, y la red se deberá encargar de asociar uno con otro. La
alternativa de utilizar el mismo DLCI en ambos extremos podría requerir de
algún tipo de administración global de los valores de DLCI.

Los bits EA (address field extension) determinan la longitud del campo

Address y, en consecuencia, del DLCI.

El bit C/R es específico de la aplicación (el protocolo estándar FR no lo utiliza).

El resto de los bits de la cabecera tienen que ver con el control de congestión,
que se analiza a continuación.

Control de congestión en Frame Relay

La especificación I.370 define los objetivos del control de congestión en FR,
que son los siguientes:

• Minimizar el descarte de tramas.

• Mantener, con un alto grado de probabilidad y un mínimo de variación,
una calidad de servicio acordada.
• Minimizar la posibilidad que un usuario final pueda monopolizar los
recursos de la red a expensas de los demás usuarios finales.
• Ser simple de implementar, e introducir un mínimo overhead tanto en el
usuario como en la red.
• Distribuir los recursos de red equitativamente entre los usuarios finales.
• Limitar la propagación de la congestión hacia elementos dentro de la
red y hacia otras redes.
• Operar de manera eficiente independientemente del flujo de tráfico en
cualquier dirección entre los usuarios.
• Minimizar la variación en la calidad de servicio ofrecido a las conexiones
FR particulares bajo condiciones de congestión (por ejemplo, las
conexiones lógicas individuales no deberán experimentar una repentina
 degradación cuando se avecina una congestión o cuando la misma ya
se ha producido)

En una red FR, resulta difícil realizar el control de congestión debido a las
limitadas herramientas que se encuentran disponibles en los switches FR (los
nodos de conmutación de tramas). El protocolo FR ha sido ajustado para
maximizar el throughput y la eficiencia. Una consecuencia de esto es que un
switch FR no puede controlar el flujo de las tramas entrantes desde un
suscriptor o un switch FR adyacente empleando el tradicional protocolo de
control de flujo de ventana deslizante, tal como se hace en HDLC.

El control de congestión es una responsabilidad compartida por la red y los

usuarios finales. La red (es decir, el conjunto de switches FR) está en la mejor
posición para monitorear el grado de congestión, mientras que los usuarios
finales están en la mejor posición para controlar la congestión limitando el
flujo de tráfico que ingresa a la red.

Figura 3. Los efectos de la congestión

La Tabla 1 lista las técnicas de control de congestión definidas en los

diferentes documentos de ITU-T y ANSI.
La estrategia de descarte tiene que ver con la respuesta más importante
frente a la congestión: cuando la congestión se torna lo suficientemente severa,
la red se ve forzada a descartar tramas.

Lo deseable es que esto se haga de la manera más equitativa para todos los
usuarios.

Los procedimientos para evitar la congestión se emplean al comienzo de la

congestión, a los fines de para minimizar su efecto sobre la red. En
consecuencia, estos procedimientos se deberían comenzar a utilizar antes del
punto A de la Figura 3, para prevenir que la congestión avance hacia el punto
B. En la proximidad del punto A, los usuarios finales deberían detectar una
ligera evidencia de que la congestión se está incrementando. Por lo tanto,
deberá existir algún mecanismo de señalización explícita desde la red que
desencadene los procedimientos para evitar la congestión.

Los procedimientos de recuperación de congestión se utilizan para evitar que

la red colapse en la fase de congestión severa. Estos procedimientos
generalmente se inician cuando la red ha comenzado a descartar tramas
debido a la congestión. Las tramas descartadas han de ser reportadas por
alguna capa superior de software (por ejemplo, el protocolo de control LAPF o
TCP) y sirven como un mecanismo de señalización implícita. Los
procedimientos de recuperación de congestión operan en torno al punto B y
dentro de la región de congestión severa como se muestra en la Figura. 3.

ITU-T y ANSI consideran que los procedimientos para evitar la congestión con
señalización explícita y la recuperación de congestión con señalización
implícita deben ser formas complementarias del control de congestión llevado
adelante por el servicio bearer.

Técnica Tipo Función Elementos Claves

Control de descarte Estrategia de descarte Provee una guía para laBit DE
red en lo relativo a
cuáles tramas descartar
Notificación deEvitar la congestión Provee una guía paraBit BECN o Mensaje CLLM
congestión explícita los sistemas finales
Backward acerca de la existencia
de congestión en la red
Notificación deEvitar la congestión Provee una guía paraBit FECN
congestión explícita los sistemas finales
fordward acerca de la existencia
de congestión en la red
Notificación deRecuperación deEl sistema final infiereNúmeros de secuencia en la
congestión implícita congestión sobre la existencia dePDU de capa superior
congestión a partir de la
pérdida de tramas

Tabla 2. Técnicas de control de congestión en FR.

Administración de la tasa de tráfico
Como última medida, una red FR debe descartar tramas para enfrentar la
congestión. No hay manera de evitar esta situación. Debido a que cada switch
FR de la red posee una capacidad finita de memoria disponible para el
encolamiento de tramas (Figura 4), resulta posible que se produzca el
desbordamiento de una cola, siendo necesario el descarte de la última trama
arribada o alguna otra.

La manera más simple de enfrentar la congestión es que la red FR descarte

tramas de manera arbitraria, sin tener en cuenta la fuente de una trama
particular. En este caso, debido a que no existe ninguna forma de premiar a un
sistema final que transmite a la tasa acordada, la mejor estrategia para
cualquier sistema final será la de transmitir tramas tan rápidamente como le
resulte posible. Esto, por supuesto, exacerba el problema de la congestión.

Figura 4 Interacción de las colas dentro de una red de datos

A los fines de ofrecer una asignación de recursos más equitativa, el servicio FR

bearer incluye el concepto de una tasa de información comprometida CIR
(committed information rate). Esta es una tasa, expresada en bits por segundo,
que la red se compromete a garantizarle a una conexión particular. Cualquier
dato transmitido por encima del CIR es vulnerable de ser descartado en caso
de congestión. A pesar del uso del término “comprometido”, no existe garantía
que aún el CIR sea satisfecho. En casos de congestión extrema, la red se
puede ver forzada a proveerle a una conexión dada un servicio por debajo del
CIR. Sin embargo, llegado el momento de descartar tramas, la red elegirá
tramas de aquellas conexiones que se encuentran excediendo su CIR antes de
descartar tramas de conexiones que se encuentran dentro del suyo.

En teoría, cada switch FR deberá administrar sus acciones de tal manera que
el total de los CIRs no exceda su capacidad. Además, el total de los CIRs no
deberán exceder la tasa de datos existente en la interfaz usuario-red, conocida
como la tasa de acceso. La limitación impuesta por la tasa de datos se puede
expresar de la siguiente manera:
Σi CIRi,j ≤ Tasa_de_Accesoj

donde:

CIRi,j = Tasa de información comprometida por conexión i sobre el canal j

Tasa_de_Accesoj = Tasa de acceso de usuario del canal j; un canal es un

canal TDM con una tasa de datos fija entre el usuario y la red

Las consideraciones que se hagan acerca de la capacidad del switch FR

pueden dar por resultado la selección de valores menores para ciertos CIRs.

En el caso de conexiones permanentes de FR, el CIR correspondiente a cada

conexión se debe establecer en el momento en que se acuerda la conexión
entre el usuario y la red. Para el caso de conexiones conmutadas, el parámetro
CIR se negocia durante la fase de establecimiento del protocolo de control de
llamada.

El CIR provee una manera de discriminar cuáles tramas se descartarán durante

la fase de congestión.

El mecanismo de discriminación emplea el bit DE (discard eligibility) de la

trama LAPF (Figura 2). El switch FR al cual se conecta la estación de usuario
realiza una función de medición (Figura 5).

Si el usuario se encuentra enviando datos por debajo del CIR, el switch FR no

alterará el bit DE de las tramas que arriban a él. Si la tasa excede el CIR, dicho
switch FR establecerá este bit sólo en las tramas en exceso y luego las
reenviará; tales tramas pueden seguir su camino hasta el destino final o
pueden ser descartadas si encuentran congestión. Finalmente, se define una
tasa máxima, de tal manera que todas aquellas tramas por encima del máximo
serán descartadas por el switch FR de entrada a la red.

Figura 5. Operación del CIR

El CIR, por sí mismo, no provee mucha flexibilidad en lo que se refiere a la

administración de las tasas de tráfico. En la práctica, un switch FR realiza
mediciones de tráfico sobre cada conexión lógica durante un intervalo de
tiempo específico para esa conexión y luego toma decisiones en base a la
cantidad de datos recibidos durante ese intervalo. Se requieren, además, dos
parámetros adicionales, asignados en el caso de las conexiones permanentes
y negociados en el caso de las conexiones conmutadas:

• Tamaño de ráfaga comprometido (Bc): la cantidad máxima de datos

que la red acuerda en transferir, bajo condiciones normales, medida
durante un intervalo T. Estos datos pueden ser contiguos o no (es decir,
estos datos pueden aparecer en una trama o en varias tramas).
• Tamaño de ráfaga en exceso (Be): la cantidad máxima de datos por
encima de Bc que la red intentará transferir, bajo condiciones normales,
medida durante un intervalo T. Estos datos no se encuentran
garantizados en el sentido que la red no se compromete a entregarlos
bajo condiciones normales. Dicho de otra manera, los datos que
representan Be son entregados con una probabilidad menor que los
datos dentro de Bc.

Las cantidades Bc y CIR se encuentran relacionadas. Debido a que Bc es la

cantidad de datos comprometida que el usuario puede transmitir a lo largo de
un tiempo T, y CIR es la tasa a la cual se pueden transmitir los datos
comprometidos, se tiene que:

T = Bc/CIR

La Figura 6, basada en una figura de la Recomendación ITU-T I.370, ilustra la

relación entre estos parámetros. En cada gráfico, la línea sólida representa la
cantidad acumulada de bits de información transferidos sobre una conexión
dada desde el tiempo T=0. La línea punteado etiquetada como “Tasa de
Acceso” representa la tasa de datos del canal que contiene esta conexión. La
línea punteada etiquetada “CIR” representa la tasa de información
comprometida medida durante un intervalo T.

Se debe observar que cuando se está transmitiendo una trama, la línea sólida
es paralela a la línea “tasa de acceso”; cuando se transmite una trama por un
canal, éste está dedicado a la transmisión de dicha trama. Cuando no se está
transmitiendo ninguna trama, la línea sólida es horizontal.

La Fig. 6a muestra un ejemplo en el que se han transmitido tres tramas durante

el intervalo de medición, y el número total de bits contenido en las tres tramas
es menor que Bc. Notemos que durante la transmisión de la primer trama, la
tasa temporaria real de transmisión excede el CIR.

Esto no tiene consecuencias porque el switch FR sólo tiene en cuenta el

número acumulado de bits a lo largo de todo el intervalo.

En la Fig. 6b, la última trama que se transmite durante el intervalo hace que
dicho número exceda Bc. En concordancia con esto, el bit DE de esa trama
será establecido por el switch FR.

En la Fig. 6c, la tercera trama excede Bc y por lo tanto está marcada para su
potencial descarte.
La cuarta trama excede Bc + Be y se descarta.

Figura 6. Ilustración de la relación entre los Parámetros de Congestión

Procedimientos para evitar la congestión con Señalización Explícita

Resulta deseable la utilización de toda la capacidad disponible en una red FR y

aún así reaccionar ante la congestión y hacerlo de una manera equitativa. Esta
es la finalidad de las técnicas explícitas para evitar la congestión. En términos
generales, cuando emplean estos procedimientos, la red alerta a los sistemas
finales acerca del crecimiento de la congestión dentro de la red y los sistemas
finales toman acciones para reducir la carga entregada a la red.

A medida que se fueron desarrollando los estándares para los procedimientos

explícitos, se consideraron dos estrategias. Un grupo consideró que la
congestión siempre ocurre lentamente y casi siempre en los switches FR de
salida. Otro grupo analizó los casos en los cuales la congestión crece muy
rápidamente en los switches FR internos y era requerida una rápida y decidida
acción para evitar la congestión en la red. Se analizarán las dos soluciones que
se reflejan en las técnicas explícitas evitar la congestión Forward y Backward,
respectivamente.

Para el caso de la señalización explícita, se proveen dos bits del campo

Address. Estos bits pueden ser establecidos por cualquier switch FR que
detecte congestión. Si un switch FR recibe una trama en la cual uno o ambos
bits están establecidos, no debe modificarlos antes de reenviar la trama. En
consecuencia, los bits constituyen señales enviadas por la red al usuario final.
Veamos la función específica de cada uno de ellos:

Notificación explícita de congestión backward (BECN)

Notifica al usuario que se deberán iniciar los procedimientos para evitar la

congestión; el procedimiento se aplicará sobre el tráfico que fluye en sentido
opuesto al de la trama recibida. Indica que las tramas que transmite el usuario
sobre esa conexión lógica pueden encontrar recursos congestionados.

Notificación explícita de congestión forward (FECN)

Notifica al usuario que se deberán iniciar los procedimientos para evitar la

congestión; el procedimiento se aplicará sobre el tráfico que fluye en el mismo
sentido de la trama recibida. Indica que esa trama, sobre esa conexión lógica,
ha encontrado recursos congestionados.

Analicemos de qué manera utilizan estos bits la red y el usuario. En primer

lugar, para que la red responda, resulta necesario que cada switch FR
monitoree el nivel de encolamiento. Si las longitudes de las colas comienzan a
crecer alcanzando un nivel peligroso, entonces se deberán establecer alguno o
ambos bits FECN y BECN para tratar de reducir el flujo de tramas que
atraviesa dicho switch FR. La elección de uno u otro bit puede estar
determinada en que si los usuarios finales sobre una conexión lógica dada
están preparados para responder a uno u otro de estos bits, lo cual se puede
determinar en tiempo de la configuración. En cualquier caso, el switch FR
cuenta con opciones para decidir cuáles conexiones lógicas deberán ser
alertadas acerca de la congestión. Si la congestión se está volviendo bastante
seria, deberían ser notificadas todas las conexiones lógicas que pasan por un
switch FR. En los momentos iniciales de la congestión, el switch FR podría
notificar solamente a los usuarios correspondientes a aquellas conexiones que
están generando la mayor parte del tráfico.

La respuesta del usuario está determinada por el receptor de las señales

BECN o FECN. El procedimiento más simple es la respuesta a la señal BECN:
el usuario simplemente reduce la tasa a la cual están siendo transmitidas las
tramas hasta que cesa de recibir la señal. La respuesta a un FECN es algo
más compleja, dado que requiere que el usuario que la recibe notifique a su par
remoto en esa conexión la necesidad de restringir su flujo de tramas. Las
funciones núcleo que se utilizan en el protocolo FR no soportan este tipo de
indicaciones; en consecuencia, se debe realizar en una capa superior, como
por ejemplo, la capa de transporte. El control de flujo también lo podría llevar a
cabo el protocolo de control LAPF u algún otro protocolo de control de enlace
que se implemente por encima de la subcapa FR. El protocolo de control LAPF
resulta particularmente útil debido a que incluye mejoras a LAPD que le
permiten al usuario ajustar el tamaño de la ventana.