3.1 Introducción

El estandar de facto evolucionó hacia varios estándares oficiales, como son:

• FR Forum (Asociación de Fabricantes): Cisco, DEC, Stratacom y Nortel.
• ANSI: fuente de normativas Frame-Relay.
• ITU-T también dispone de normativa técnica de la tecnología Frame-Relay.

Las principales carencias y limitaciones que presenta X.25 son:

• X.25 es un estándar que impone una sobrecarga de procesamiento muy grande. Esta complejidad tan elevada impide operar a velocidades de línea altas. Un ejemplo es que, en la práctica, la ventana del nivel 3 impone limitaciones en velocidad.

• Hay que tener en cuenta que una red de conmutación tiene recursos compartidos, y su funcionamiento depende de la carga de la red (a mayor carga el retardo se incrementa y el flujo disminuye). Como no resulta posible predecir el estado de la red, no sabemos cuanto tardará en transmitirse un paquete, ni podemos garantizar un caudal mínimo. Es decir: X.25 no garantiza Calidad de Servicio (QoS). Este problema se ha resuelto en Frame Relay, y existen garantías respecto al caudal.

• El rango de caudales en acceso en que X.25 opera normalmente va desde 1.2Kb/s hasta 64 Kb/s. Existen equipos que permitirían operar a una velocidad mucho mayor en la línea de acceso. Pero eso implicaría una congestión mayor en las líneas troncales (que conectan sistemas intermedios) de la red. Y precisamente lo que resultaría muy costoso económicamente es aumentar las velocidades a las que operan estos sistemas intermedios.

• Una aplicación muy importante de X.25 es el teleproceso o acceso a un mainframe desde terminales remotos. La velocidad de 64 Kbps sí puede resultar suficiente para cualquier terminal, pero es una cifra escasa para la línea que conecta al superordenador con la red.

• Otras aplicaciones que no satisface X.25 son una rápida y efectiva interconexión de LANS, así como aplicaciones multimedia con udio y vídeo en tiempo real.

• Otra diferencia de Frame Relay respecto a X.25 es la separación entre el plano de usuario y el plano de control. Existen dos arquitecturas de protocolos diferentes para los datos de usuario y los datos de control. En X.25 los procedimientos de control y los datos de usuario utilizaban los mismos medios, y eso daba lugar a problemas en casos de congestión.

• Algo más a tener en cuenta es que la mejora de los medios de transmisión (P_e baja) a convertido en innecesario el complejo control de errores que proporcionaba X.25.

3.2 Tecnología Frame - Relay

• Es un protocolo de Acceso a Subred (regula interfaz usuario-red)

• El funcionamiento interno no está normalizado (igual que en X.25), por lo que sólo lo está el interfaz usuario-red.

• Frame-Relay posibilita tráfico impulsivo, así como múltiples terminales de usuario.

• Frame-Relay ofrece una simplificación de los servicios que ofrece. Para comprender mejor el por qué de las simplificaciones que ofrece Frame-Relay, pasemos al siguiente ejemplo:

Paquetes de aproximadamente 131 octetos (~ 1000 bits).

El nodo asociado a esta línea debería procesar paquetes cada , y el hecho de tener varias líneas accediendo a cada nodo, así como saliendo de el, encarecería demasiado los equipos:
 
 

En Frame-Relay, para reducir este coste, se realizan las siguientes simplificaciones de protocolo:

• Separación (funcional) del Plano de Usuario y Plano de Control:

(NOTA: Plano de Usuario: parte de la arquitectura de protocolo por la que circulan los datos del usuario. Plano de Control: parte de la arquitectura de protocolo por la que circulan datos entre el usuario y la red para supervisar la red)

• En X.25, estos planos no estaban separados, lo que complicaba el diseño de los equipos. La separación en Frame-Relay se debe a que se tiende a diseñar en el equipo una parte distinta para procesar cada plano, ya que la característica deseada para el usuario es conseguir MAS CAUDAL, y para el de control, tener FLEXIBILIDAD (se tiende a la implementación software de los equipos en el plano de control y hardware en el plano de usuario).
• Simplificaciones en el Plano de Usuario:

• Suprime el Nivel 3 del plano de usuario. Pero como Frame Relay ofrece un servicio orientado a conexión, nos surge la siguiente pregunta: ¿Qué ocurre con el establecimiento y liberación de las llamadas? Pues que se lleva al plano de control del nivel 3. ¿ Y con la función de multiplexión de conexiones ? La función de multiplexión se pasa al nivel 2 en FR.

• Suprime funciones del Nivel 2 en el plano de usuario.

Así pues, los equipos que procesan las tramas deben realizar un procesamiento menor.
 
 

3.3 Servicio Frame-Relay

• Orientación a conexión (CO).
• Es no fiable, con garantías de caudal mínimo, por lo que se acepta que proveedor pierda datos (PDUs). Con fiable nos referimos a que tramas errores pueden ser detectadas y descartadas en los nodos de la red (comprobando el CRC) sin avisar a los sistemas finales. Esta no fiabilidad es, por supuesto, fruto de las simplificaciones en el protocolo comentadas anteriormente.

• QoS: El cliente tiene garantizadas (por contrato) las prestaciones que obtendrá de la red.

• Circuitos Virtuales Permanentes(PVC): están definidos en todos los estándares.
• Circuitos Virtuales Conmutados (CVC): Éstos solo han sido definidos en el estandar propuesto por la ITU-T y no por el estandar de facto.

3.4 Arquitectura de Protocolos

3.4.1 Introducción

• Plano de Usuario:

(a) Nivel Físico (dos opciones):

• Línea de Serie (interfaces físicas: V.35, G.703)
• RDSI (BRI, PRI)

(b) Nivel de Enlace: en la recomendación de ITU-T, el protocolo utilizado es LAP-F.

• Plano de Control (en la práctica no se utilizan):
 
• Se instala sobre el mismo plano de usuario, utilizando el mismo nivel físico, excepto en RDSI, que se utiliza el Canal D para el plano de Control.
• Nivel 2: el mismo que RDSI, es decir, LAP-D.
• Nivel 3: Se usa el protocolo Q.933 (similar al Q.931 usado en establecimiento y liberación de llamadas en RDSI).

• Plano de Gestión: Se identifican dos protocolos: ILMI (Interin Local Management Interface) y CLLM (Consolidated Link Layer Management).

3.4.2 Formato de Trama

• CRC (también llamado FCS): Código de detección de errores. Es un código cíclico. Es necesario, ya que cuando se detecta una trama con error, se descarta.
• DATOS: . En este campo es donde van los datos del Nivel superior, es decir, esta información se mete en la trama y, en recepción, se pasa directamente al nivel superior. Su longitud máxima no está definida en el estándar de facto (no está normalizada), pues no se pudo llegar a un acuerdo. Normalmente los operadores de redes FR la sitúan alrededor de 1600 bytes. Esta gran diferencia con X.25 (128 octetos) es debida a la escasa P_e. El Nivel superior entrega los datos, y estos son encapsulados en una trama. Por último, añadir que este campo está alineado a octeto, es decir se exige al usuario del servicio que entregue un número entero de octetos.
• FLAG: Tiene el mismo formato que en LAB-B (01111110), y también se utiliza para separar tramas consecutivas. Cuando no hay tramas que transmitir, se generan guiones continuamente.
• CAMPO DE CONTROL: Llamamos campo de control a los bytes que siguen al Flag y que están por delante de los Datos de usuario. Puede tener varios formatos (como en X.25), pero normalmente suele tener 16 bits de longitud (2 octetos):

• DLCI: Data Link Circuit Identifier. Estos diez bits son el identificador de conexión de enlace de datos. Permite definir hasta 1024 circuitos virtuales. Ya habíamos avanzado que la función de multiplexión se realiza en el nivel 2, y con el DLCI se identifica al canal lógico al que pertenece cada trama. Los números de canal lógico se asignan por contratación. Equivale al NCL de X.25.
• E A: Extended Address. Campo de extensión de dirección. Puesto que se permiten más de dos octetos en el campo de control, este primer bit de cada octeto indica (cuando está marcado con un '0') si detrás siguen más octetos o bien (cuando está marcado con un '1') si se trata del último del campo de control. Emplear más de dos bytes resulta bastante infrecuente y se utiliza en el caso de que la dirección de multiplexión (en el campo DLCI) supere los 10 bits.
• C R: Bit de Comando / Respuesta. Es parecido al bit "Q" de X.25, y al igual que ocurría con éste, no es un bit utilizado por la red. Se introduce por compatibilidad con protocolos anteriores, como los del tipo HDLC. Cuando el protocolo de enlace es fiable, utilizan este bit.
• F C, B C y F C: Bits para control de congestión y se verán más adelante en este tema.

(NOTA: La velocidad de llegada de tramas al nodo depende de la longitud de las tramas y del caudal. El nodo a de ser capaz de procesar las tramas según llegan. Luego, el que se queden en el nodo y tarden en salir es otra cosa, y depende del tráfico)
 
 

Vemos como, a diferencia de X.25, en Frame-Relay tendremos DLCIs diferentes en el UNI para datos entrantes y salientes de la red. Además, cada circuito se trata de un CVP, y no de un CVC.
 
 

3.4.3 Control de Congestión

 

Tráfico ofrecido: 

Tráfico cursado: 

Pero, ¿ por qué tiene esta forma la gráfica?

• En redes de medio compartido, la red pierde tiempo en solucionar las colisiones.
• En redes sin medio compartido, esta gráfica se debe a la limitación de la capacidad de conmutación de los nodos. Cuando a un nodo le llegan datos que no puede cursar, los descarta, quedándose sin llegar a su destino (curva cae)

Los controles de congestión consisten en técnicas estadísticas, nunca deterministas. En Frame-Relay, esta función está implementada en parte en el Plano de Usuario.

En X.25 el control de congestión se realizaba mediante el Control de Flujo (se detienen fuentes cuando se detecta tráfico excesivo en algún punto del circuito virtual). En Frame-Relay se usa el mecanismo de NOTIFICACIÓN Y DESCARTE:

"Cuando se detecta una zona congestionada, se notifica al usuario que envía los datos que pasan por esa parte de la red, el cual disminuye la tasa de tráfico inyectado. Si el usuario no lo hace, la red descartará los datos que considere oportuno (aceptable, ya que F-R es un servicio no fiable). Esta pérdida, si es de porcentaje elevado, provoca el cese del funcionamiento a las entidades de nivel superior, por lo que el usuario intentará evitar este tipo de situaciones".

Debemos recordar que en Frame-Relay, este descarte de tramas tiene lugar a Nivel 2.

La implementación de la técnica de NOTIFICACIÓN Y DESCARTE se realiza mediante los campos FECN, BECN y DE en el campo de control de la trama que ya fueron introducidos anteriormente:

• FECN (Forward Explicit Congestion Notification): Notificación de congestión en el sentido de la transmisión.
• BECN (Backward Explicit Congestion Notification): Notificación de congestión en el sentido contrario a la transmisión.
• DE (Discard Eligibility): Las tramas que tienen este bit a "1" son susceptibles de descarte en situaciones de congestión.

Hay que señalar que la congestión es unidireccional, pues puede haber caminos distintos para los dos sentidos de la transmisión y mientras uno puede estar sufriendo problemas de tráfico (congestión), el otro puede no tenerlos. Los bits FECN y BECN notifican congestión a los dos extremos de una conexión de la siguiente forma:  A una trama que atraviesa una zona congestionada se le pone su bit FECN a '1'. La red identifica las tramas de esa conexión que circulan en sentido contrario y en ellas marca el bit BECN también a '1'.

Es decir, la red F-R sólo notifica la congestión al origen y al destino, y del N. Superior dependerá seguir estas indicaciones (indicando al N. Superior del origen que reduzca la tasa, etc.) o no hacerlo, en cuyo caso, F-R procederá a descartar tramas.
 
 

3.4.4 QoS

• CIR (Committed Information Rate) (bits/s): Es la tasa de información comprometida, es decir, el caudal medio garantizado que la red se compremete a dar en una conexión durante un intervalo de tiempo definido (Tc). Es un parámetro asociado a cada sentido de la transmisión de cada circuito virtual.

• T_c (Commited rate measurement interval): Intervalo de observación (es el tiempo hasta el cual ha sido representado la gráfica anterior). Parámetro del algoritmo para calcular el CIR).

• C·T_c : Máximo volumen de información que se podría cursar en T_c (es lo que posibilita el canal).

En el interfaz usuario-red se controla, para cada circuito virtual, que los usuarios se ajusten a los parámetros Bc, y Be que han negociado. Si la red está bien diseñada no debe perder datos que no superen el tráfico comprometido.

Definimos dos zonas en el diagrama:

• B_c (Committed burst size): Es el volumen de información comprometida: durante el intervalo T_c la compañía se compromete a transmitir un volumen B_c.

• B_e : Volumen de información en exceso: la información cursada durante el intervalo T_c que exceda de B_c + B_e no se sabe si llegará o no a su destino (la compañía no lo garantiza). El volumen de información que exceda de B_c + B_e seguro que no llegará.

Existe un bit en la trama (bit DE) que es activado por la red en tramas que superen Bc (es decir aquellas que pertenezcan a Be) para indicar que esas tramas deberían ser descartadas en preferencia a otras, si es necesario. El servicio permite que el propio usuario también pueda marcar este bit para indicar la importancia relativa de una trama respecto a otras (en este caso, estas tramas no se contabilizan como pertenecientes a la zona bajo B_c, sino como perteneciente a la zona sobre B_c y bajo B_c + B_e, no contando para el CIR).

(NOTA: La mayoría de las compañías sólo definen el parámetro B_e.)

El parámetro C·T_c está asociado a la capacidad física de las líneas, y es lo primero que contrata el abonado. Luego, sobre esa línea física, se definen mallas de circuitos virtuales , cada uno con su CIR asociado.
 
 

El CIR no es la capacidad física a la que se transmite. Esa velocidad es la de la capacidad del canal. El CIR sólo es el caudal medio (estadístico).

Si el T_c se toma grande, existe la posibilidad de transmitir grandes picos de información en algunos momentos y nada de información en otros. Por tanto, un T_c pequeño nos garantiza el que la transmisión sea más homogénea (esto interesa a la empresa, ya que así se evita sobredimensionar las redes).

Algunas preguntas al respecto:

Pregunta: Manteniendo el CIR, ¿qué le conviene más a un abonado, un Tc grande o pequeño? Al usuario le resulta atractivo que Tc sea muy grande, porque  Bc también lo será, y aunque en media se deba mantener la velocidad CIR, está capacitado para enviar ráfagas de datos mayores,  pues el límite de datos máximo (Bc) ha aumentado.

Para el operador es conveniente que Tc baje. Con Tc grande, si  todos los usuarios deciden mandar simultáneamente ráfagas de tráfico de longitud máxima Bc, podría encontrar problemas para cursar todo el tráfico por la red

Generalmente cuando se envía una trama se desconoce el estado de la red. Tramas por encima de Bc son susceptibles de ser descartadas cuando la congestión de la red aumenta en las rutas que atraviesan dichas tramas. Por ello la red notifica este aumento de la probabilidad de descarte de tramas mediante los bits FECN y BECN. Se requiere que los terminales actúen de forma coherente y reduzcan el tráfico enviado a la red, porque de lo contrario las tramas de usuario que superen Bc están en peligro de ser descartadas en nodos de red congestionados.

Pregunta: ¿Por qué se notifica al destino la congestión? Para que sea consciente de que se pueden estar perdiendo tramas que tienen marcado el bit DE a '1', y porque algunos protocolos de niveles superiores tienen capacidad de control de flujo extremo a extremo y pueden tomar medidas al respecto.
 
 

3.5 Multiplexación

En F-R, cada conexión de Nivel Inferior cursa una sola conexión de nivel Superior, por lo que no necesito multiplexar.

Se utilizan DLCIs de 10 bits que, como vimos, no suponen ningún problema, ya que el número de circuitos virtuales es muy inferior.
 
 

La arquitectura de protocolos del interfaz podría ser:
 
 

Si sólo tenemos un DLCI, para poder utilizarlos deberíamos hacer algo como la arquitectura descrita. Normalmente tenemos un número reducido de DLCIs (uno o dos).
 
 

3.6 Plano de Control y Señalización

• Protocolos ILMI y CLLM
• CLLM - Trama XID (eXchange IDentification) sobre Canal D (ISDN)

DLCI = 11?1

Independientemente de cual sea la longitud de DLCI, CLLM utiliza el DLCI que tenga el campo todo a 1.

El protocolo CLLM se utiliza para enviar información de control de congestión, en aquellos casos en que no hay tramas en sentido contrario al congestionado (para informar al usuario de la congestión).

El ILMI se puede enviar de dos maneras dependiendo de como esté integrado:

• Trama UI (Unnumbered Information) sobre Canal D (RDSI)
• DLCI = 0?0 (forma más habitual, pues casi no se usa F-R sobre RDSI)

También se encarga de comprobar el estado de cada DLCI (dado de alta o baja).

También envía mensajes de Status Enquiry/Status: permite sincronizar el equipo del abonado con el de la red para que ambos estén en el mismo estado (comprobar si hay línea, que los DLCIs estén funcionando correctamente, etc).
 
 

3.7 Líneas de Acceso

3.8 Conclusiones

Además la disponibilidad de estas redes es muy alta, y por  todo ello muchas compañías usan redes FR para cursar este tipo de tráfico. En general se considera que son suficientemente buenas para cursar tráfico telefónico, en el que lo más importante (más que la probabilidad de error) es tener una elevada disponibilidad.
 

Vuelta al Indice de Apuntes