Integración de tecnologías de acceso de banda ancha. Proyecto HIAD

Integración de tecnologías de acceso de banda ancha:
proyecto HIAD
C. López Bravo, J. García Reinoso1, F.J. González Castaño1,
P.S. Rodríguez Hernández1, J.M. Pousada Carballo1, J. García Haro
Área de Ingeniería Telemática
Universidad Politécnica de Cartagena
[email protected]
1. Introducción
El proyecto HIAD (High Integration Access Device) consiste en el desarrollo de
un equipo de central, para integración de tecnologías de acceso de banda ancha. El
equipo está formado por una tarjeta que integra dos tipos diferentes de interfaces, o de
tecnologías de acceso: RDSI o xDSL, para las conexiones con los usuarios, y FO OC-3,
para la conexión a una red troncal ATM (figura 1)
Usuarios
EQUIPO de
CENTRAL
HIAD
FO
Red
Trocal
Figura 1: HIAD
La ventaja de utilizar xDSL en las conexiones con los usuarios es que se
pueden ofrecer servicios de banda ancha, utilizando el cableado existente. Esto supone
un ahorro tanto en costes como en tiempo, ya que no es necesario iniciar ningún tipo de
obra civil.
Otra de las ventajas que ofrece este sistema es que la comunicación con los
usuarios se basa en protocolos ATM, de forma que se unifica el protocolo empleado
extremo a extremo por el operador de telecomunicaciones.
1
Departamento de Tecnologías de las Comunicaciones, Universidad de Vigo,
javier/pedro/[email protected].
En los siguientes apartados se describe la arquitectura del HIAD en la fase
actual, que solo contempla ADSL en la parte de usuario, así como algunos detalles de la
implementación, el funcionamiento y las prestaciones del prototipo.
2. Motivación
Este trabajo está financiado por la Comisión Europea y la Comisión
Interministerial de Ciencia y Tecnología, a través del proyecto TIC 1FD97-2248-C0201. En el proyecto participa la empresa Versaware S.L. (Vigo), y se cuenta con una
expresión de interés de Telenor (Noruega), a raíz de una reunión conjunta en la Zona
Franca de Vigo que tuvo lugar en el año 1999.
Además del desarrollo del equipo HIAD, el proyecto persigue que un grupo
unversitario español adquiera experiencia en el manejo de diversas tecnologías para
desarrollo físico de sistemas telemáticos de banda ancha (Motorola MPC860 [1] y
EVB92501 [2], sistemas operativos pSOS+ [3] y VxWorks [4]).
3. Arquitectura del prototipo HIAD
3.1 Arquitectura hardware
Para la construcción de un prototipo del equipo de central se ha decido utilizar la
placa de desarrollo EVB92501 de Motorola (ATMC-EVB). Esta placa:

Incorpora numerosos puertos de entrada y salida: Ethernet, RS-232, ADI,
etc., que facilitan la comunicación con otros sistemas. Desde un PC se
puede descargar los módulos de inicio, preparar la memoria FLASH, etc.

Incluye en una sola placa los dos tipos de interfaces que necesitamos (ADSL
y FO OC-3).

Y, razón fundamental, cuenta con un circuito -MC92501- capaz de procesar
celdas ATM, y concentrar el tráfico generado por distintos usuarios en una
sola línea de salida.
Los componentes principales de la placa son:

Un microprocesador MPC860, basado en PowerPC. Es el encargado del
control de los demás subsistemas de la placa.

Un controlador ATM MC92501 [5], que trabaja en el nivel ATM, y realiza
funciones de gestión de tráfico (celdas OAM), control de flujo de datos
(UPC), conversión de direcciones y generación de estadísticas. Está formado
por dos procesadores de celdas, ingress y egress, y sus interfaces UTOPIA
(nivel 2). El MC92501 gestiona su propia memoria, en la que almacena la
información relativa a las conexiones que se puedan abrir.

Un transceptor AX tmATM-SONET/SDH, CY7C955 [6]. Es la interfaz entre
el equipo HIAD y la red ATM propiamente dicha. Este circuito se encarga
de convertir las celdas ATM (recibidas desde la interfaz UTOPIA) en tramas
serie SONET para transmisión por FO, y viceversa.

Un bus UTOPIA (nivel 1 y 2), que permite la conexión de la placa con otros
dispositivos. Es el nexo de unión entre los usuarios y el MC92501, y entre
éste y la FO.

Un generador de tráfico y un dispositivo de almacenamiento para cada
sentido de comunicación (ingress y egress). Estos dispositivos permiten
comprobar el funcionamiento del equipo HIAD sin necesidad de trabajar con
tráfico real. Una vez que se trabaje con tráfico real, permiten encaminar el
tráfico procedente de los usuarios hacia la FO, y viceversa (las celdas
almacenadas en el grabador ingress se envían al generador de tráfico egress).

Y, finalmente, un conjunto de componentes auxiliares: memorias y puertos
de comunicación (RS-232, Ethernet, ADI).
Para realizar desarrollos sobre la placa EVB92501, se puede conectar un PC a
través de un puerto ADI (modo depuración), del puerto RS-232 o del puerto Ethernet
(modo de funcionamiento normal). En la figura 2 se muestra la disposición de todos los
componentes (incluido el PC) y su interconexión:
Figura 2: ATMC-EVB
3.2 Arquitectura software
Tras una evaluación de pSOS+ y VxWORKS, se eligió éste último para el
desarrollo del equipo HIAD. VxWorks dispone de un entorno de desarrollo, llamado
Tornado, que se instala en el PC externo. Tornado dispone de editores, compiladores y
diversas aplicaciones que permiten descargar imágenes en la placa ATMC-EVB.
Incluye, además, una herramienta para desarrollo de BSPs (Board Support
Package). Permite añadir periféricos específicos, o portar el sistema operativo a placas
no soportadas. Aunque la distribución de VxWorks incluye un BSP genérico para
MPC860, ha sido realizar adaptaciones para la placa ATMC-EVB. En especial, se ha
reflejado la existencia del MC92501, su memoria, los generadores y grabadores de
tráfico y la interfaz de FO.
3.2.1 Funciones de HIAD
3.2.1.1 Configuración inicial
Los procedimientos de inicio siguen las órdenes un NMS externo. Para ello, se
utiliza un agente SNMP que se ejecuta en el núcleo de VxWorks. La configuración
incluye el número de interfaces ADSL activas (o, en otras palabras, número de modems
ADSL conectados a HIAD) y el número de conexiones que se van a poder abrir, tanto
VPC, como VCC. La configuración se puede cambiar, pero es preciso reiniciar o
reconstruir todas las tablas de conexiones y los contadores de celdas.
3.2.1.2 Apertura de conexiones y enlaces
Los circuitos virtuales que se crean son permanentes. Es decir, se asume que el
control de admisión es ajeno al equipo de central. Sin embargo, si puede ser necesario
mantener un control de flujo que garantice que los usuarios no sobrepasan las tasas de
transferencia que han contratado. Los parámetros relacionados con la calidad de servicio
(PCR, MSB, etc.) y el tipo de tráfico (UBR, ABR, CBR, etc.), se especifican cuando se
activa una conexión para el transporte de datos.
El número de conexiones, el sentido de la comunicación para cada una de ellas y
la categoría de servicio ofrecido son especificadas por el NMS.
3.2.1.3 Gestión del tráfico del sistema
Una vez creadas y activadas las conexiones, los usuarios pueden utilizarlas. A
partir de este momento, las funciones del HIAD son:

Encaminamiento de las celdas de la red a los usuarios, y viceversa.

Control del flujo UP y DOWN.

Monitorización del tráfico que circula en ambos sentidos.
3.2.1.3.1 Encaminamiento de celdas
Conexiones punto a punto: El esquema de comunicaciones se muestra en la figura 3:
USUARIO (modem
ADSL)
Par
Trenzado
HIAD
Interfaz
ADSL
92501
Interfaz
FO
FO
Conmutador de
acceso a la red
Figura 3: conexión punto a punto
El tráfico generado por los usuarios se encamina hacia la interfaz FO a través del
HIAD. La salida FO se dirige al conmutador de acceso a la red. En sentido inverso, el
tráfico de red de la FO llega al HIAD, desde donde es distribuido hacia el usuario
correspondiente.
Este tipo de configuración supone que:

Primero, hay que enlazar los dos tramos de la comunicación, es decir, la
conexión entre los usuarios y el HIAD, y la conexión entre el HIAD y la red.
Por cada conexión que se abre entre un usuario y el HIAD debe abrirse otra,
entre el HIAD y la interfaz de FO (salvo en el caso de conexiones multicast,
que veremos más adelante). A continuación, hay que unir ambas conexiones,
actualizando las tablas de contexto que el MC92501 mantiene por cada
conexión abierta. El HIAD permite, si así se desea, que se active solo uno de
los dos sentidos de la comunicación.

Tras ello, se debe realimentar del tráfico. Todas las celdas procesadas por el
ATMC-EVB en sentido ingress (ya sean generadas por los usuarios, o
procedentes de la red) vuelven a ser procesadas en sentido egress.
La realimentación se puede hacer de dos formas: por hardware, utilizando el
dispositivo correspondiente [2], o por software, sirviéndose de los
generadores y grabadores. Es decir: todo lo que se almacena en el grabador
de ingress es leído por el microprocesador y enviado al generador de egress,
de donde regresa al MC92501. Para la elaboración del prototipo esto es
suficiente. La realimentación consigue dos objetivos:
Por un lado, como se explicará en el siguiente apartado, posibilita la
realización de control de flujo en el tráfico de los usuarios y en el tráfico que
procede de la red. Por otro, la modificación de las cabeceras de las celdas,
cuando proceda (por ejemplo, en el tratamiento de celdas multicast).
Conexiones punto a multipunto: En el caso de conexiones punto a multipunto, se abren
varias conexiones entre los usuarios y el HIAD, y una sola conexión entre éste y la red.
Consecuentemente, todas las conexiones de usuario se enlazan con la conexión de red, y
solo se activa uno de los sentidos de comunicación, redusuarios. En nuestra
implementación, esta configuración es programada por el NMS.
La gestión del tráfico multicast se basa en la capacidad del MC92501 para
extraer celdas del flujo de datos y entregarlas al microprocesador, así como para recibir
celdas de éste e insertarlas de nuevo en el flujo de datos. Las conexiones multicast
pueden distinguirse por sus identificadores. Si el MC92501 detecta uno de esos
identificadores en la cabecera de una celda, la envía a una cola de extracción. Una vez
en la cola, el generador de interrupciones del ATMC-EVB avisa al microprocesador.
Entonces, el MPC860 extrae la celda de la cola, busca en sus tablas las conexiones de
usuario por donde debe enviarla, hace tantas copias como sea necesario, y las envía, una
a una, hacia una cola de inserción. Una vez en la cola de inserción, las celdas replicadas
se van insertando en el flujo de datos, aprovechando los huecos que vayan quedando
libres.
3.2.1.3.2 Control de flujo
El MC92501 permite la realización de control de flujo. En principio, esto es
posible para los dos sentidos de la comunicación, ingress y egress (en función del valor
de uno de los parámetros de configuración MC92501). El problema es que el control es
sobre un sentido o sobre el otro, pero no sobre los dos a la vez. Se podría pensar
entonces que podemos tener control sobre lo que generan los usuarios y no sobre el
tráfico que solicitan a la red, violando sus contratos. Sin embargo la arquitectura que
hemos seleccionado evita este problema, como se puede ver a continuación.
Se ha dicho que, cuando se abre una conexión, ésta tiene asociados unos
parámetros relativos a la categoría del servicio. Cada sentido de la comunicación tiene
su propio conjunto de parámetros. A partir de estos parámetros se construyen las
estructuras que definen el control de flujo UPC. Con los parámetros de sentido
usuariored se construyen las estructuras de control UPC en sentido ingress de los
usuarios, controlando la salida hacia la red. Con los parámetros en sentido
redusuarios se construyen las estructuras de control UPC para el ingress de la FO,
controlando así la demanda de los usuarios. De esta forma, el control se hace en ambos
casos en sentido ingress, pero en realidad se controlan los dos sentidos de la
comunicación, usuriored.
3.2.1.3.3 Cómputo del tráfico
El MC92501 mantiene tablas de contadores, con entradas para cada una de las
conexiones que estén abiertas. La estructura de estas entradas se puede configurar, de
forma que las celdas se cuenten conjuntamente o separándolas en función de su bit de
prioridad CLP.
Además, el MC92501 también mantiene una tabla de contadores para cada línea
activada, es decir, para cada modem ADSL conectado, y para la interfaz de FO. Esto
permite hacer una tarificación por tráfico global, independientemente de las conexiones
que tenga abiertas un usuario.
4. El agente SNMP en el proyecto HIAD
En este apartado se describe la implementación del agente SNMP desarrollado
para el HIAD. En los RFCs se detallan las estructuras de datos que se deben crear para
el control de un dispositivo mediante el protocolo de gestión de redes SNMP, pero la
descripción de la utilización y forma de acceder a los datos son un tanto oscuras. Por lo
tanto, se han seguido las recomendaciones en los casos que se explican con rigor, pero
se han hecho suposiciones en los casos en los que las especificaciones no eran del todo
claras o no existían.
Se comenzará haciendo una pequeña introducción del protocolo SNMP y de su
misión en este proyecto.
4.1 El protocolo SNMP
El SNMP (Simple Network Management Protocol) es un protocolo sencillo de
administración de redes. Tanto es así, que en la primera versión sólo se incluían cuatro
posibles llamadas: set, get, get-next y trap. La complejidad reside casi exclusivamente
en el NMS (Network Management System), que es el encargado de monitorizar la red y
decidir los pasos a ejecutar.
Así, la red puede verse como un conjunto de nodos administrados (que deben
poseer al menos un agente SNMP), y al menos un NMS.
Figura 4: Red SNMP
La figura 4 nos muestra una posible red administrada mediante el protocolo
SNMP. Existe un NMS que controlará los dispositivos que se pueden administrar.
Vemos que algunos nodos poseen un agente SNMP. Estos nodos son potenciales
puntos a administrables. Un NMS no administra necesariamente cualquier nodo con
agente SNMP, puesto que existe un sistema de claves.
Cada nodo con agente SNMP posee una estructura de datos llamada MIB
(Management Information Base), jerárquicamente distribuida. Así, dependiendo de qué
se desee administrar, se puede incluir una parte del árbol MIB o no. Por ejemplo,
iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1) tiene objetos que muestran
información del nodo administrado: nombre, ubicación, tiempo desde el último reset,
etc.
4.2 Misión del SNMP en el proyecto HIAD.
El HIAD es un dispositivo concentrador de líneas ADSL hacia ATM. En ATM
se debe iniciar los circuitos virtuales, antes de que los datos fluyan. En el HIAD se ha
optado por PVC (Permanent Virtual Circuits) -aunque la implementación de SVC
(Switched Virtual Circuits) no se excluye en una fase posterior-. Los PVC son fijos y
no tienen que generarse cada vez que se quiere comunicar dos entidades. Por tanto, cada
vez que se inicie el agente, se deben crear estos circuitos, y esta misión se encomienda
al NMS.
Además, se puede tener control SNMP de todas las interfaces del dispositivo,
como Ethernet, puerto serie, etc, por lo que se puede llevar una estadística de los
paquetes que las atraviesan.
4.3 Modificación de las conexiones.
Para que el tráfico pueda fluir entre dos puntos de una red orientada a la
conexión, como es el caso de ATM, es necesario establecer circuitos. Como se ha
comentado en párrafos anteriores, los PVC deben activarse al arrancar el HIAD. Para
poder realizar una conexión, se debe realizar unas acciones determinadas. Será el NMS
quien las solicite, y el agente SNMP del HIAD quien las ejecute.
Una conexión lleva asociada una serie de parámetros básicos. En la
terminología de los RFCs SNMP se distinguen varias definiciones que son importantes
para comprender el mecanismo de activación de conexiones.
Una interfaz es un punto por el que pueden entrar datos. Con esta definición,
podemos llamar interfaz a una línea ADSL, a una línea ethernet o incluso a un
generador de tráfico. En nuestro caso, tendremos dos tipos de interfaces: las líneas
ADSL y las líneas FO. El equivalente en la terminología de los circuitos es el puerto.
Una conexión es el segmento de línea entre dos dispositivos por el que fluyen los
datos. Es decir, entre los modems ADSL y el HIAD se define una conexión.
Una conexión cruzada es la intersección lógica de dos conexiones. Es decir,
cuando el flujo proveniente de una conexión se encamina hacia otra.
La representación del tipo de tráfico definida en los RFCs difiere de las del
ATM Forum, pero se puede establecer una relación sin mayor problema.
La secuencia que debe seguir el NMS para poder comunicar un usuario con la
red sería la siguiente:



Se define un grupo de tipos de tráfico que podrá usarse en cualquier conexión.
Se abren las conexiones en cada interfaz.
Se cruzan las conexiones necesarias.
Se debe tener en cuenta que las conexiones pueden ser tanto bidireccionales como
unidireccionales. Estas últimas son útiles en caso de multicast. Se debe tener en cuenta
que solo se pueden cruzar conexiones que tengan la misma dirección.
4.4 Ejemplo de utilización
En el siguiente gráfico se puede una posible configuración del HIAD.
Figura 5: Ejemplo de configuración HIAD
El NMS envía las instrucciones necesarias para que el agente SNMP del HIAD
cree 6 conexiones. Dos conexiones para la interfaz uno, a la que está conectado un
modem ADSL, y otras dos para la interfaz dos, a la que está conectado otro modem
ADSL. También se crean dos conexiones en la interfaz FO. Tras ello se cruzan estas
conexiones para poder mandar datos. Se ve que existe una conexión multicast, entre
una conexión FO y dos lineas de modems.
4.5. Monitorización de información en redes ATM.
En toda red de datos es necesario realizar estadísticas de comportamiento a lo
largo del tiempo. Esto es interesante para futuras ampliaciones, ya que las estadísticas
reflejan cuáles son los recursos más utilizados; es útil para poder facturar el gasto de
cada usuario, e incluso para el propio NMS, para poder tomar decisiones sobre el
comportamiento de un determinado dispositivo.
Las RFCs de monitorización en ATM proporcionan mecanismos para la
definición de los tipos de datos y el momento y forma de recolectarlos.
El método descrito en el RFC2513 [7] es genérico y permite recolectar más tipos
de datos que los necesarios en nuestra implementación, por lo que se han eliminado
algunos aspectos.
Existen dos formas de recolección de datos. Se puede hacer con un
temporizador o, ante determinados eventos. Si se escoge la primera opción, el agente
SNMP crea un temporizador que se conectará a una función encargada de la
recolección. En el segundo caso, se llama directamente a la función.
En el RFC2512 [8] se detallan todos los datos que se pueden almacenar sobre
una determinada conexión. En el RFC2513 se describen los pasos a seguir para la
obtención de dichos datos.
El funcionamiento con temporizador sería el siguiente:
1. El NMS le pide al agente que cada n segundos se recolecte la información
solicitada. Esta información puede escogerse entre todo el espectro de
posibilidades del RFC2512.
2. El agente recolecta esta información y la guarda en un archivo, cuyo nombre
ha sido asignado por el NMS.
3. El NMS, mediante FTP, adquiere el fichero creado por el agente SNMP.
5. Conclusiones
El proyecto HIAD es un proyecto ambicioso, validado por uno de los principales
operadores europeos de telecomunicación, en el que se quiere concentrar, en un mismo
dispositivo, numerosas formas de acceso a las redes de la información. No obstante,
uno de nuestros principales objetivos es la adquisición de experiencia sobre tecnologías
de desarrollo de sistemas telemáticos de banda ancha.
En la fase actual, se ha logrado implementar la parte de concentración de ADSL,
lo que ha generado amplia información y experiencia para poder añadir más
funcionalidad y poder llegar a un dispositivo HIAD pleno en un futuro cercano.
La placa de evaluación del circuito MC92501 de Motorola, ATMC-EVB, ha sido de
gran ayuda, ya que nos permitió manejar los recursos básicos del prototipo HIAD. Sin
embargo, según se avanzaba, se ha detectado falta de potencia para el equipo HIAD
final. Definitivamente, se hace necesaria la inclusión de otro circuito que realice tareas
complementarias. Una solución posible es el MC92400, anunciado por Motorola, pero
no nos consta disponibilidad en el mercado.
7. Líneas Futuras
Resta mucho trabajo para conseguir un equipo HIAD definitivo. Se tiene que tomar una
decisión sobre el sucesor del MC92501. Se ha citado el MC92400, pero otra opción es
un cambio de tecnología. Una solución interesante es la familia de circuitos de Sierra,
aunque también hemos barajado otras alternativas de Lucent o Transwitch. La
migración desde el prototipo actual hacia los nuevos circuitos no sería difícil. La parte
de control de SNMP es independiente al circuito que se elija. El resto del software
deberá sufrir ligeros retoques, pero la arquitectura se mantiene.
8. Referencias
[1] MOTOROLA, “MPC860 PowerQUICC – User’s Manual”, 1996.
[2] MOTOROLA, “ATM Cell Processor Evaluation Board User´s Manual”.
[3] Integrated Systems, “pRISM+ for pSOSystem”.
[4] WindRiver Systems, “VxWorks Programer’s Guide”.
[5] MOTOROLA, “MC92501 – ATM Cell Processor User´s Manual”.
[6] CYPRESS Semiconductor Corporation, “AX ATM-SONET/SDH Transceiver”,
November, 1999.
[7] McCloghrie, K.,Heinanen J.,Greene, W. and A. Prasad, “Managed Objects for
Controlling the Collection and Storage of Accounting formation for ConnectionOriented Networks”, RFC2513, February 1999.
[8] McCloghrie, K.,Heinanen J.,Greene, W. and A. Prasad, “Accounting Information for
ATM Networks”, RFC2512, February 1999.