Experiencias en la organización de un centro proveedor de servicios Internet

L. Álvarez, A. Ocón, E. Rubio y M. Galán

Resumen

En este artículo se describen los elementos más significativos de la experiencia en la gestión del "equivalente de un ISP" para satisfacer las necesidades de acceso remoto de los usuarios de una Universidad. Se estructura bajo la forma de una breve reseña histórica, describiendo las etapas más importantes desde el punto de vista de los servicios ofrecidos al usuario, finalizando con el estudio de algunos escenarios aconsejables en la actualidad, de cara a establecer un centro de estas características.

Primera Etapa (1.990-93)

Merece la pena recordar que hace tan sólo ocho años algo tan habitual hoy en día como el concepto de "Proveedor de Servicio Internet" (PSI ó ISP en nomenclatura anglosajona) resultaba totalmente desconocido para la gran mayoría de usuarios de equipos informáticos. En nuestro país, tan sólo algunos centros de cálculo de universidades y centros de investigación (por la parte académica) y unas pocas pero muy entusiastas empresas privadas comenzaban a sentar las bases de lo que sería una de las actividades más frenéticas asociadas a la explosión del fenómeno Internet.

De hecho, nuestros comienzos (y los de la gran mayoría de los ISPs "históricos") fueron como simples proveedores de cuentas de correo electrónico. Era casi impensable (por escasez de recursos en general y de ancho de banda en particular) el disponer de una infraestructura capaz de soportar un gran número de usuarios conectados por un espacio de tiempo superior a unos pocos minutos (lo necesario para enviar y recibir en modo "offline" los mensajes de uno o unos pocos usuarios). La solución, por tanto, consistía en la implantación de una pequeña batería de módems en una máquina UNIX (algunos empleando Terminal Servers, otros con módems directamente conectados al "backplane" o multiplexor) y hacer uso del protocolo UUCP (Unix to Unix Copy) [1], para establecer la comunicación entre el servidor y los usuarios.

A dichos usuarios se les suministraba un "kit" de acceso (normalmente de fabricación propia, a base de modificar alguno de los paquetes UUCP adaptados a PC —UUPC-) en el que a base de "scripts" de comandos y algún pequeño programa escrito en "C", se conseguía modificar algún programa de gestión de correo (BMAIL, Pegasus Mail, etc.) con mecanismos de llamada automática, transferencia y recepción de mensajes bajo protocolo UUCP, conversión de direcciones UUCP a RFC822, etc.[2].

Básicamente, este sistema tenía como principales inconvenientes (aparte del obvio de limitar la conectividad a correo electrónico y a algunas alternativas al trabajo "on-line" verdaderamente curiosas como FTPMail, GOPHERmail y similares), la especificidad del kit de acceso para determinados clientes (típicamente MS-DOS, con ciertas dificultades bajo Windows 3.11/95 y casi imposible para entornos Mac) y la necesidad de disponer de personal altamente cualificado por parte del proveedor del servicio. De hecho, la amalgama de servicios implicados (gestión de los módems, de las cuentas de usuario, de la UUCP, del sendmail, etc.) implicaba que cualquier llamada relativa a un problema (por sencillo que fuese) acabase indefectiblemente en manos de los especialistas en comunicaciones.

Segunda Etapa (1.994-95)

Entre los años 93 y 94 se vino a producir la primera etapa de la revolución ocasionada por la implantación del WWW como estándar de intercambio de información en Internet. Los usuarios comenzaron a demandar conexiones "reales" a Internet desde sus equipos y los proveedores respondieron proporcionando la segunda generación de "kits" de acceso. Básicamente se trataba de habilitar conexiones SLIP o PPP en equipos (386 y 486) bajo Windows 3.11 (y más tarde Win95). El problema principal por parte de los usuarios era la dificultad de incorporar a su sistema operativo todas las herramientas necesarias (todavía estaban lejanos los días del CD-ROM estándar en cualquier equipo doméstico), y en que aspectos hoy superados, como la configuración del módem, dejaban bastante que desear.

Desde el punto de vista del proveedor, esta etapa supuso un gran incremento en el número de módems (provocado por el aumento de tiempo de conexión de cada usuario, además del propio incremento de usuarios), y un cambio más cualitativo en la absoluta dependencia del ancho de banda como principal indicador de la calidad de servicio ofrecida. Es en este momento cuando nos vemos inmersos en una persecución inacabable entre consumo de los usuarios y conexión con el exterior. Además, una cierta parte de los usuarios seguían con el anterior sistema basado en UUCP, y por tanto, la gestión del servicio se complica aun más. Para colmo de males, las conexiones SLIP y PPP (basadas en PAP) seguían produciéndose bajo una "conversación" o "chat" sostenida sobre conexiones de terminal convencionales, al igual que la UUCP, dificultando la detección y solución de problemas del usuario.

Tercera Etapa (1.996-98)

La verdadera revolución llega de la mano de Telefónica con la implantación del servicio InfoVía. Por una parte, no sólo crece el número de usuarios sino también su propia tasa de crecimiento, mientras que para los proveedores se complica la gestión al necesitar una herramienta hasta entonces desconocida (el protocolo Radius y sus programas de gestión, entonces cerrados y extrañamente "hackeados" por Telefónica), diferentes enlaces sobre Frame-Relay (CIR/EIR de Infovía, CIR/EIR de Internet, etc.), configuración de los diferentes Centros Proveedores de Infovía provinciales, etc. Indudablemente, aparece una gran ventaja como es la posibilidad de disponer de una número casi ilimitado de módems gestionados externamente (aunque casi todos los proveedores mantienen sus baterías locales a efectos de proporcionar conexiones más estables y rápidas).

La irrupción en el mercado del Windows 95 comienza la etapa en la que se simplifican los Kits de acceso a nivel de usuario (aunque en los primeros tiempos la conexión a Internet no estaba en absoluto contemplada como estándar en dicho sistema, y si no se disponía del CD-ROM del producto, el proceso podía ser más que penoso) [3]. De cualquier forma, no olvidemos que cualquier ISP tenía que mantener los servicios anteriores, con lo que se tenían usuarios bajo UUCP, bajo acceso local a Internet con PPP "conversacional" (que fueron rápidamente migrados a versiones de PPP con autenticación CHAP, es decir, no orientada a "script") y con acceso a través de InfoVía. A medida que los problemas de conectividad se simplifican (entre otras cosas, por el incremento del "nivel cultural internáutico" medio de los usuarios), aparece la pesadilla de una gestión fragmentada en multitud de pequeños programas que se han ido confeccionando sin un estilo uniforme, un control de los accesos por InfoVía casi inexistente, clientes que acceden por RDSI, que reclaman números fijos IP, etc., etc.

Cuarta Etapa (desde primeros de 1.999)

La puesta en marcha del "mal llamado" servicio de InfoVía Plus [4] (y su marcha atrás —impuesta legalmente, todo hay que decirlo- en la calidad del servicio prestado a los usuarios) y la consiguiente avalancha de usuarios de InfoVía descontentos que solicitan acceso mediante nodo local coincide —afortunadamente— con la aparición de programas de gestión del protocolo Radius "realmente abiertos", de tal forma que muchos ISPs comienzan a plantearse la necesidad de integrar la gestión de todos sus accesos bajo un mismo sistema.

La primera aproximación a este tipo de soluciones se suele producir integrando todos los elementos de acceso (módems, TAs RDSI, etc.) bajo un software (típicamente el PortSlave) que permite realizar la autenticación de usuarios mediante protocolo Radius [5], precisamente en el mismo servidor que gobierna los accesos mediante InfoVía Plus. De esta forma, se dispone de una única "base de datos de usuarios" con todas las mejoras que esto conlleva (evitación de accesos simultáneos indeseados, duplicidades y/o incoherencias en la información, etc.).

Las ventajas de este sistema se aprecian tanto en lo relativo a la autenticación (al unificar la estructura de datos del usuario —cuentas en Unix— y sus características —determinadas por la pertenencia o no a grupos de usuario determinados—) como muy especialmente de cara a la auditoría ("accounting") de los accesos. Así, se puede obtener de manera unificada todos los datos relativos a cada conexión (número de teléfono entrante, tipo de llamada —analógica o RDSI—, velocidad de acceso negociada, bytes transmitidos y recibidos, tiempo real de la conexión, etc.) y muy especialmente se pueden trazar e identificar los posibles problemas en las conexiones (pareja username/password incorrecta, solicitud de acceso de forma no autorizada —RDSI, entradas simultáneas, Dirección IP fija, etc. —, desconexiones indeseadas por pérdida de calidad de la línea, módems o "routers" mal configurados), etc.

Indudablemente, un factor crítico del éxito en la implantación de este tipo de sistemas ha sido el "aligeramiento" de la carga de trabajo para el personal de mantenimiento del ISP. Como se puede comprobar en la tabla adjunta, se estima que la relación entre usuarios y personal de soporte ha aumentado en los centros consultados hasta llegar casi a quintuplicarse. Aún más, todos los ISP consultados han coincidido en que, actualmente, las cuestiones básicas de los usuarios pueden ser resueltas por personal de cualificación media, pudiéndose dedicar los especialistas a tareas más asociadas con el incremento de productividad [6].

Tabla 1.- Etapas consideradas en la evolución de un ISP.

Conclusiones

En la actualidad, uno de los grandes dilemas a los que se enfrenta todo ISP es la conveniencia o no de "automatizar" al máximo todos los elementos de acceso, evitando el empleo de soluciones tipo "portslave" en máquinas Unix a expensas de adquirir hardware específico que gestione de forma integral todas las llamadas entrantes. Ejemplos clásico de este tipo de hardware son la familia de equipos PortMaster de Livingstone/Lucent, los PM4000 de Cyclades, etc. En general, se trata de procesadores de propósito específico que, conectados a accesos primarios RDSI, permiten gestionar en primera instancia las llamadas entrantes por RDSI y, a través de placas de emulación de conexión analógica, las llamadas convencionales a diferente velocidad (hasta V.90). Como ventaja principal, ofrecen la posibilidad de eliminar las baterías de módems y sus incontables problemas (físicos y lógicos), teniendo como principal inconveniente, antes que su precio, la "relativa cautividad" que aplican al proveedor, tanto en lo relativo al servicio prestado como en cuanto a la posible capacidad de respuesta ante los cambios que indudablemente nos deparará el futuro inmediato (ADSL, etc.).

Así, podríamos decir que hoy en día, cualquier organización (académica o comercial) con intención de organizar un ISP y que no quiera "morir en el intento", debería platearse una solución integrada (como la descrita en el apartado anterior), basada en soluciones abiertas, estándar y multifabricante. La supremacía evidente del entorno Linux y en general de herramientas de software "a la FSF" facilitan bastante la consecución de estos objetivos en lo relativo al software. Con respecto al hardware, nos limitaremos a destacar los peligros de la dependencia de un solo fabricante en mercados tan dinámicos como este.

Referencias

1. A Gentle Introduction to Taylor UUCP. http://metalab.unc.edu/LDP/LDP/nag/node154.html
2. Pegasus Mail. Manual de usuario (con indicaciones de conexión remota vía UUCP). CICEI-ULPGC. Accesible en ftp://ftp.ulpgc.es/ulpgc/pmail
3. Guía de conexión a través de InfoVía. CICEI-ULPGC. Servicio de Reprografía de la ULPGC.
4. Infovía Plus. http://www.telefonica-data.com/esp/mapa/WCWIPT580.htm
5. Lista de distribución sobre Radius en ISPs. http://ISP-Lists.ISP-Planet.com/isp-radius/archives/
6. "Modelo de Innovación de Campus. Implantación e integración de las Tecnologías de la Información en el ámbito de la ULPGC". Antonio Ocón Carreras. Tesis Doctoral.

Luis Álvarez Álvarez,
 alvarez [at] cicei [dot] ulpgc.es
Antonio Ocón Carreras,
 ocon [at] cicei [dot] ulpgc.es
Enrique Rubio Royo
 rubio [at] cicei [dot] ulpgc.es
Manuel Galán Moreno
 manolo [at] cicei [dot] ulpgc.es
CICEI
U. de Las Palmas de Gran Canaria