Protocolo Frame-Relay

Introducción

Frame Relay surgíó como un estándar de facto (1990), producido por un grupo de varios fabricantes de equipos. Nacíó para cubrir necesidades del mercado no satisfechas hasta el momento en el sector de las comunicaciones. Se trataba de una solución transitoria, pero que ha logrado una gran aceptación, y su papel en la actualidad es importante.

El estándar de facto evoluciónó hacia varios estándares oficiales, como son:

• • FR Fórum (Asociación de Fabricantes): Cisco, DEC, Stratacom y Nortel.
  • 
    

    Ansí

    Fuente de normativas Frame-Relay.
  • 
    ITU-T también dispone de normativa técnica de la tecnología Frame-Relay.

Sin embargo, estas tres fuentes de normas no siempre coinciden (ambigüedad), cosa que no pasaba en X.25.

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.

Tecnología Frame - Relay

Las principales carácterísticas de Frame-Relay son:

• • 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:

Línea de 2 Mbps.

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

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 carácterí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.

Por tanto, tenemos lo siguiente:
 

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

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.

Las perdidas de datos en Frame-Relay no son preocupantes si disponemos de un protocolo de Nivel Superior que resuelva el problema para las aplicaciones que no toleren perdidas de datos. A pesar de esto, la no fiabilidad es muy baja, ya que los medios de transmisión tienen una probabilidad de error (P_e) bajísima.

• • QoS:

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

Frame-Relay ofrece dos tipos de conexiones:

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

El servicio que suelen ofrecer los operadores de redes FR sólo incluye PVC´s, y es utilizado típicamente para dar servicios de comunicaciones dentro de una corporación.
 
 

Arquitectura de Protocolos

Introducción

En cada sistema final y sistema intermedio, tenemos dos arquitecturas distintas y separadas: la correspondiente al plano de usuario y la correspondiente al plano de control.

• • 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).

NOTA: a nivel físico, existirá una separación de los flujos de información de usuario y de control.

• • Plano de Gestión:

    
    Se identifican dos protocolos: ILMI (Ínterin Local Management Interface) y CLLM (Consolidated Link Layer Management).

(Ver Tema 1)

Formato de Trama

Nos referimos al formato existente en el plano de usuario. En este formato no se establece una longitud máxima de trama, pero debe ser un múltiplo entero de octetos (es decir, la trama está alineada a octeto), lo cual se puede observar en la figura. Conviene destacar que el protocolo define también el orden de transmisión de los bits de la trama por línea. Este orden es, según se ha querido dar a entender con la figura, de derecha a izquierda. La transmisión es en serie por la línea y un bit va detrás de otro. Un sistema final o intermedio que reciba una trama debe saber el significado de cada bit que le llega, y este significado depende del orden de ese bit dentro de su 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.

Los sistemas pueden almacenar las tramas de formas diferentes. No olvidemos que la representación interna de la información dentro de un sistema puede tener diferentes significados, según el convenio que haya adoptado la implementación de esa máquina. Existen los convenios extremista mayor y extremista menor  (Big-Endian y Little- Endian en inglés), y éstos, a su vez pueden  estar referidos a bits, bytes o palabras. El sistema debe tener esto en cuenta para operar adecuadamente con los bits que tiene almacenados, y al transmitir o recibir bits de tramas, hacerlo en el orden que establece el protocolo.

(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 Uní para datos entrantes y salientes de la red. Además, cada circuito se trata de un CVP, y no de un CVC.
 
 

Control de Congestión

El control de congestión no es una función local, sino global (participan todos los sistemas). Veamos algunos conceptos:

Tráfico ofrecido: 

Tráfico cursado: 

Por la gráfica siguiente, queda claro que el objetivo de la tecnología de redes será evitar entrar en la zona de congestión.

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)

El intentar no llegar a esta Zona de Congestión, es decir, procurar que se curse la mayor cantidad de tráfico ofrecido, significa utilizar técnicas de congestión.

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 Éxplicit Congestión Notification): Notificación de congestión en el sentido de la transmisión.
  • 
    BECN (Backward Éxplicit Congestión 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.

El bit BECN y el FECN se usan para avisar que hay congestión (la red los cambia de 0 a 1 y viceversa):

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.
 
 

QoS

Es posible contratar para cada conexión una calidad de servicio distinta. Dicha calidad está definida mediante ciertos parámetros:

• • 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.

Se define una relación entre el tiempo real y el volumen de información transferida:

• • 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·Tc

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

El caudal físico (C) de la línea de acceso también se contrata. Así el operador dimensiona la red en función de los parámetros contratados por sus abonados.

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.

• • Be

    
    Volumen de información en exceso: la información cursada durante el intervalo T_c que exceda de B_c + B_eno 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á.
    

Este método se aplicará para cada circuito virtual de ingreso a la red.

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.
 
 

Bc = CIR·Tc

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.
 
 

Multiplexación

Consiste en cursar varias conexiones del nivel superior sobre una sola conexión del nivel inferior:

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).
 
 

Plano de Control y Señalización

• • Protocolos

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

DLCI = 11?1

XID se utiliza en F-R para llevar la información de CLLM. Si no se utiliza F-R sobre RDSI se utiliza un DLCI determinado.

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)

Se encarga de comprobar el estado del acceso físico. F-R no tiene temporizador, por lo que supervisa el estado del acceso físico para, mediante protocolo de señalización, informar de que se ha dañado o hay errores.

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).
 
 

Líneas de Acceso

(Las empresas que ofrecen servicio y las que ofrecen acceso no suelen ser la misma)

Conclusiones

Frame Relay no es un protocolo especialmente diseñado para soportar tráfico multimedia, audio y vídeo en tiempo real. No hay garantías sobre el retardo de tránsito, pero en la práctica las redes suelen estar bien dimensionadas y el retardo de tránsito es pequeño y no varía apreciablemente.

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.