 |
Novática
es la revista de ATI (Asociación de
Técnicos de Informática).
Nota importante: Se permite la reproducción de este artículo, excepto si está marcado con © o Copyright, debiéndose en todo caso citar su procedencia Important notice: This article can be reprinted except if marked with © or Copyright. If reprinted full mention of the source is mandatory |
Novática 128 (Julio-Agosto 1997)
INTERNET2 O LA PROXIMA GENERACION DE INTERNET (PARTE SEGUNDA)
Traducción: María del Carmen Ugarte García, Samuel Linares, Miguel Angel Jiménez, Rafael Fernández Calvo
Notas:
1. Contexto y diseño
En Octubre de 1996 representantes de unas 40 universidades con centros de investigación y organizaciones similares se reunieron en Chicago y acordaron trabajar juntos en el Proyecto Internet2 (a menudo también llamado "I2" en otras partes de éste y de otros documentos). Los participantes en este encuentro crearon también un Comité de Dirección de Internet2 y diversos grupos de trabajo.
Hasta la fecha, más de 100 instituciones se han comprometido a participar en Internet2. Cada institución se ha comprometido a:
1.A. Requisitos de Aplicación
En muchas facultades y universidades está surgiendo un conjunto de aplicaciones de red avanzadas. Esto enriquecerá enormemente la enseñanza, el aprendizaje, la colaboración y las actividades de investigación. Por ejemplo:
Internet2 trata de hacer posible estas nuevas aplicaciones. Esto se conseguirá colaborando con el sector de las tecnologías de la información para desarrollar estándares comunes y servicios de soporte para los nuevos tipos de aplicaciones y para asegurar la disponibilidad de los servicios avanzados de comunicaciones requeridos. Muchas de las tecnologías de servicio de comunicaciones necesarias están todavía en fases precompetitivas de desarrollo. Todas ellas deberían beneficiarse enormemente de un campo de pruebas que abarque a la comunidad investigadora y educativa.
Otras instituciones investigadoras, educativas y gubernamentales se enfrentan a necesidades muy similares a las de la educación superior en lo que se refiere a aplicaciones y comunicaciones. Estas necesidades han engendrado varias iniciativas de redes de alto rendimiento que igualan y superan en distintos aspectos a Internet2, especialmente el proyecto NSF vBNS (National Science Foundation’s very high speed Backbone Network Service) y el conjunto de iniciativas "Próxima Generación de Internet" (Next Generation Internet) anunciado por la Casa Blanca el pasado otoño. Nosotros tenemos la total intención de que Internet2 se desarrolle de acuerdo con estas otras iniciativas, aumentando así la sinergia, minimizando la duplicación y maximizando la compatibilidad e interoperabilidad entre las aplicaciones y redes resultantes.
El conjunto de áreas de actuación mencionado anteriormente implica el correspondiente conjunto de requisitos de comunicaciones para Internet 2. Las aplicaciones futuras pueden requerir tipos adicionales de servicios. Es importante que el diseño de I2 sea lo suficientemente flexible como para abarcar tanto los requisitos conocidos actualmente como los nuevos requisitos a medida que éstos se vayan conociendo.
Fundamental para el diseño de la infraestructura de la Internet2 es el mantenimiento de un "servicio portador común" para la comunicación entre las aplicaciones de red. El "servicio portador" es la interfaz básica de transporte de información para las comunicaciones de área extensa, de forma análoga a la capa 3 en el modelo de red ISO. Una de las características más potentes de la Internet actual es la capacidad de un nodo de comunicarse con cualquier otro en un formato de transporte compatible. Deberemos conservar esta misma potencia en Internet2.
En la medida de lo posible, el servicio portador de I2 debe ser compatible con las prestaciones comunes de Internet ya existentes. Esa infraestructura existente seguirá siendo la ruta de acceso para quienes no participen en Internet2, así como para las universidades miembro servidas por Proveedores de Servicios Internet locales (PSIs).
El servicio portador común hoy en día es el Protocolo Internet (IP o Internet Protocol) versión 4. I2 desplegará IP versión 6 (IPv6) tan pronto como sea posible. Pero todas las implementaciones deberán ser compatibles con la anterior versión IPv4.
Además de implementar IPv6, I2 debe permitir a las aplicaciones especificar una "calidad de servicio" (QoS o Quality of Service) de red en cuestiones tales como la velocidad de transmisión, el retardo limitado y los límites de variación del mismo, el rendimiento y la planificación. Conseguir todos estos requisitos tan pronto como sea posible es el reto del diseño que hemos emprendido. Afortunadamente, las tecnologías necesarias para dar estos servicios se han venido desarrollando durante varios años y las versiones iniciales de producción están casi preparadas para una comprobación en serio sobre el terreno.
Más allá de las tecnologías en sí, los participantes
en Internet2 requerirán tanto servicios más rentables como
servicios con costes predecibles. La provisión de servicios avanzados
y sistemas de soporte no será barata. Puesto que estos servicios
migrarán al mercado de productos, queremos estar seguros que existe
un modelo económico sólido para su uso. El diseño
de ingeniería para la infraestructura del Proyecto I2 debe permitir
al usuario final la gestión tanto de los costes como de los servicios.
1.B. Panorámica de la Ingeniería
Toda la arquitectura para la infraestructura de Internet2 se basa en unas cuantas consideraciones técnicas y prácticas. Una de éllas es la necesidad de minimizar los costes totales para las universidades participantes proporcionando el mismo circuito de conexión local de alta capacidad para el acceso, tanto a la Internet comercial como a los servicios avanzados. Además, podrán incorporarse otros proyectos y programas universitarios mediante una arquitectura flexible de interconexión regional. Por ejemplo, un servicio de red de área metropolitana podría ofrecer servicio Internet de alta capacidad a estudiantes y a residencias de las facultades, y la universidad necesitaría una interconexión de gran capacidad con ese servicio.
Para servicios avanzados de área extensa, un solo servicio de interconexión entre gigapops (probablemente el vBNS patrocinado por la NSF) sería suficiente en un principio. Un número determinado de proveedores de servicios sería capaz de ofrecer servicios avanzados a medida que las tecnologías se fueran transfiriendo al sector privado. El diseño de Internet2 debe optimizar la capacidad de las universidades para adquirir servicios prestados por la más amplia variedad de proveedores.
En la figura 1 se muestra la arquitectura completa de Internet2. El nuevo elemento clave en esta arquitectura es el gigapop (de gigabit capacity point of presence o "punto de presencia con capacidad de gigabits") – un punto de interconexión de tecnología avanzada y alta capacidad donde los participantes de I2 pueden intercambiar tráfico de servicios avanzados con otros participantes del proyecto. Las universidades de una determinada región geográfica se unirán en un gigapop regional para conseguir una variedad de servicios Internet.
Cada universidad (como Alpha y Baker en la figura 1) instalará un circuito de alta velocidad al gigapop que le corresponda, a través del cuál obtendrá el acceso tanto a los servicios de la Internet comercial como a los avanzados de Internet2. Los gigapops, por tanto, se unirán para adquirir y gestionar la conectividad entre los mismos en una organización cuya estructura y forma legal aún está por determinar, pero que provisionalmente se llama "Entidad Colectiva" (Collective Entity, CE). Potencialmente, en el gigapop habría un amplio rango de servicios disponibles, limitados tan sólo por las razones del mercado y por la absoluta prioridad y aislamiento de los servicios I2
Para cumplir los requisitos de los desarrolladores y aplicaciones de Internet2, debe existir soporte para servicios avanzados, tanto en los centros universitarios como en los gigapops. Dentro de los centros habrá muchas formas de afrontar este requisito, formas que no nos proponemos enumerar aquí. En los gigapops el servicio de interconexión de área extensa debe dar soporte tanto al servicio de calidad diferenciada como al transporte de alta capacidad y seguridad. Puesto que estas capacidades aún no están disponibles en los ejes principales de la Internet comercial, la Entidad Colectiva establecerá una red de interconexión de propósito especial entre gigapops. Esperamos que inicialmente esta interconexión la proveerá el vBNS de la NSF. Con el tiempo, sin embargo, la conectividad vBNS se incrementará con otras rutas de interconexión con el fin de dar a I2 un conjunto de conexiones redundantes y extensas.
El concepto de gigapop puede incrementar enormemente la competencia en el mercado entre los proveedores de servicios Internet y ayudar a asegurar servicios I2 rentables a largo plazo. Esta debería ser la forma más común para que las redes de usuarios finales tuviesen acceso a una gran variedad de servicios de comunicaciones, desde el transporte básico Internet hasta la "replicación" (caching) y provisión de contenidos.
Internet2 tiene cuatro componentes técnicos principales:
La mayoría de los gigapops surgirán de la colaboración regional, a menudo adhiriéndose a acuerdos ya existentes o a mecanismos a nivel de los Estados de la Unión, aunque algunos de ellos podrían ser suministrados comercialmente. La mayoría de las conexiones entre centros universitarios y gigapops se negociarán por la universidad y/o el gigapop; la mayoría de las conexiones entre gigapops se negociarán a través de los propios gigapops mediante la Entidad Colectiva.
El despliegue completo de las aplicaciones I2 requiere servicios de red de próxima generación sobre una base extremo-a-extremo. Esto implica actualizaciones muy importantes en la mayoría de las redes de los centros universitarios. Como ya apuntamos anteriormente, los miembros de I2 son responsables respectivamente, de adaptar sus redes universitarias a los estándares I2. Aunque habrá que comentar requisitos específicos a medida que vayan surgiendo, damos por supuesto que este trabajo está en buenas manos.
En el resto de este documento nos centramos en el resto de los temas
críticos: los gigapops y su nube de interconexión de red.
1.C. Alcance, Contexto y Planificación
Internet2 debe estimular el desarrollo y despliegue de aplicaciones multimedia avanzadas en tiempo real, y la infraestructura de red y diferenciación de servicio necesarios para soportarlas. Puesto que la conectividad I2 está limitada sólo a los miembros del proyecto (un número relativamente pequeño de instituciones educativas), esta iniciativa no es un sustitutivo de la Internet comercial. En todo caso, sí esperamos que las experiencias que se adquieran en este proyecto terminen influyendo en la Internet comercial.
I2 será una red de producción basada en estándares
pero precompetitiva y no un experimento de investigación de redes.
Más aún, un principio clave es el de usar tecnología
ajena siempre que sea posible. No obstante, en la implementación
de I2 debemos tener muy en cuenta algunas cuestiones de investigación
y son éstas las que diferencian a I2 de un servicio comercial. Las
cuestiones de investigación relativas a la red en sí misma
(diferenciadas de las áreas específicas de aplicación)
incluyen:
I2, por supuesto, funciona en el contexto más amplio de otras redes nacionales importantes. Por poner un ejemplo importante, las redes específicas gestionadas por otras agencias federales, como la NASA y del Departamento de Energía, son elementos importantes del entorno de redes de investigación. Las necesidades de esos organismos públicos respecto a mediciones y estadísticas pueden ir acopladas a los desarrollos de I2. Y, claramente, iniciativas públicas como el reciente Colaboratorio de Fusión Magnética están relacionadas con los objetivos de aplicación de I2. I2 busca complementar y mejorar otras iniciativas de red de alto rendimiento y a gran escala, y colaborar, cooperar y unirse a ellas tanto como sea posible. Deseamos y esperamos que en adelante no sea necesario pagar una conexión directa distinta a los laboratorios de las universidades. Muy al contrario, las redes principales federales pueden conectarse a los gigapops y utilizar o construirse sobre el enlace entre centros universitarios y gigapops.
Existen distintas formas para llevar a cabo esta simbiosis. La coordinación es la clave. Los laboratorios federales tienen una importancia crítica para el proyecto Internet2. Las redes federales proveen conectividad para experimentos académicos clave. La coordinación debería realizarse en las áreas de la ingeniería, encaminamiento, estadísticas y partes de diagnósticos y averías. Debería crearse un foro regular entre los responsables de Internet2 y de las redes federales para intercambiar información y planificar conjuntamente actividades avanzadas de red.
Existen ya unos pocos gigapops prototipo. En algunos aspectos, por ejemplo, la Red de Investigación y Educación del Área Metropolitana de Chicago es un modelo parcial para un gigapop. Están a punto de madurar proyectos similares en Carolina del Norte y California. Esperamos que estos y otros pocos centros pioneros sean capaces de manejar su tráfico propietario de I2 bastante rápidamente, con casi total seguridad en los próximos seis meses. También esperamos que estos gigapops puedan comunicarse entre sí en ese mismo plazo, pero con un gran ancho de banda que probablemente anticipe las capacidades de calidad de servicio.
Esperamos también que el número de miembros de I2 cuyas
redes universitarias proporcionen capacidades I2 crezca considerablemente
durante los próximos seis meses. En los siguientes 12 meses esperamos
que la mayoría de los miembros de I2 actualice al menos sus redes
universitarias principales, la mayoría de los gigapops se torne
operativa y las conexiones entre los miembros de I2 y los gigapops estén
funcionando. Transcurridos 24 meses desde el comienzo del proyecto, esperamos
que los profesores e investigadores en los centros universitarios I2 tengan
acceso regular al servicio de red I2 para sus aplicaciones de red.
1.D. Soporte y asistencia a los usuarios finales
No pensamos que los operadores del gigapop proporcionen asistencia directa o servicios similares a los usuarios finales. Esos usuarios cuyas aplicaciones requieren servicios I2 deberán obtener asistencia a través de los departamentos de Informática de sus universidades.
Esos departamentos, a nivel de universidad y de Centro de Operaciones de Red, podrán participar en los foros de tecnología I2 patrocinados por I2. Adelantamos que la Entidad Colectiva administrará las listas de distribución electrónica y los recursos de comunicaciones habituales.
Cada red regional, estatal o nacional de I2 deberá tener un Centro
de Operaciones de Red (NOC, Network Operations Center)
asociado. Este NOC interactuará con otros NOCs de
red y NOCs universitarios para diagnosticar y resolver problemas.
Se espera que los usuarios finales informen de los problemas a sus NOCs
locales.
1.E. Principios
Seis principios básicos surgieron en nuestras deliberaciones y merece la pena repetirlos aquí antes de pasar a materias más técnicas:
2. Gigapops
2.A. Estructura y servicios
Desde un punto de vista lógico, un gigapop es un punto regional de interconexión de red que, normalmente, provee acceso a la red inter-gigapop para algunos miembros I2.
Organizativamente, se espera que los gigapops los implementen una o más universidades, aunque puede haber excepciones. Por ejemplo, la Entidad Colectiva podría encargarse de gestionar ciertos gigapops, las universidades podrían operar otros en su propio nombre y en el de sus instituciones vecinas, y otros podrían ser gestionados por entidades comerciales.
No es práctico ni posible encargar a una sola entidad la operación de todos los gigapops. El funcionamiento del gigapop y la coordinación se realizará a través de una organización tipo paraguas, a la que hemos llamado simplemente Entidad Colectiva, pendiente de futuras discusiones estructurales. Un precedente para este modo de operación se dio en los principios de Internet. Lo mismo sigue ocurriendo hoy en el Grupo de Operadores de la Red de América del Norte (NANOG). La Entidad Colectiva debe decidir estándares comunes para interconectar gigapops y para la gestión de los protocolos que se intercambiarán para dar soporte a los servicios avanzados de comunicación. Esta gestión incluirá temas tan "raros" como las medidas de utilización para la asignación de costes, así como datos de investigación que harán posible la caracterización del sistema en su conjunto.
Desde un punto de vista físico, un gigapop es un lugar seguro y ambientalmente acondicionado que alberga un conjunto de equipos de comunicaciones y hardware de soporte. Los circuitos terminan allí, tanto si se trata de redes de miembros de I2 como de redes de área extensa para transportar datos, sean I2 o comerciales. Se da por supuesto que las redes miembro de I2 no son redes de tránsito, es decir, no generan tráfico entre un gigapop e Internet. Los gigapops darán servicio a redes no de tránsito de usuarios finales a través de la apropiada gestión del encaminamiento IP (protocolos Internet). Los gigapops I2 no darán servicio a redes comerciales de tránsito, ni está permitido el acceso ilimitado de los datos a través de tales redes por medio de la infraestructura de encaminadores del gigapop. Los enlaces entre gigapops solamente conducirán tráfico entre centros Internet2.
Una función clave de un gigapop es el intercambio del tráfico I2 con un ancho de banda específico y otros atributos de calidad de servicio. Además, el tráfico estándar IP puede ser intercambiado por medio de proveedores de servicio Internet que tengan una terminación en el gigapop, eliminándose así la necesidad de tener conexiones de alta velocidad separadas entre las redes de las universidades participantes y otros puntos de intercambio de los PSIs. En algunos casos, los gigapops atenderán a clientes y a fines más allá de la comunicación entre desarrolladores de aplicaciones I2. En concreto, los gigapops deben enlazar las redes de centros universitarios I2 con:
Los gigapops deben participar en la gestión operativa de I2, recogiendo datos sobre la utilización y compartiendo entre sí y con los operadores de las redes universitarias toda la información necesaria para programar, prevenir, hacer el seguimiento, solucionar los problemas y responsabilizarse del servicio de red I2.
Prevemos que cada gigapop podría dar servicio a entre cinco a diez miembros de I2. Con una distribución equilibrada esto implica la existencia de una docena de gigapops, pero pensamos que el número es improbable que sea tan bajo. Primero porque la geografía influirá fuertemente sobre la agrupación en gigapops y los miembros I2 no se distribuyen geográficamente en conjuntos de seis nodos. En segundo lugar, en muchos casos es probable que sean numerosas las iniciativas estatales o regionales que darán lugar a gigapops que den servicio tanto a I2 como a otras necesidades (que se tratan más abajo). En tercer lugar, por diversas razones algunos miembros implementarán sus propios gigapops, incrementando aún más el número de ellos.
¿Pueden los gigapops suministrar además servicios similares a miembros que no pertenezcan a I2, quizá incluso comercialmente? Hemos discutido este punto con cierta amplitud. Nuestra conclusión es que una entidad que suministre conectividad a miembros I2 será considerada un gigapop I2 si, y solamente si, reúne las condiciones funcionales y operacionales que especificamos abajo, y lo hace sin dar servicios I2 --especialmente encaminamiento y transporte entre gigapops-- intencionada o accidentalmente a usuarios o aplicaciones que no pertenezcan a I2.
La última condición se cumple siempre que un gigapop I2
es parte de alguna gran entidad, quizás simplemente un edificio
que además alberga otro equipamiento de conectividad, o quizás
un sofisticado sistema de intercambio capaz de ordenar internamente el
tráfico perteneciente a I2 y el ajeno. Principalmente este es un
problema de terminología. Podemos clasificar las cosas que un gigapop
debe hacer en tres categorías:
En la práctica, esperamos que los gigapops se dividan en dos tipos principales:
Especificamos estos diferentes tipos porque creemos que algunas agrupaciones de miembros supondrán situaciones complejas con alto tráfico, procedente y destinado a diversos centros situados en cualquier lugar, mientras que otras supondrán agrupaciones relativamente simples y pequeñas en las que la arquitectura será mucho más modesta. Lo que sea útil para el primer caso será destructivo para el último; lo que fuese suficiente para las últimas se colapsaría si tuviese que satisfacer las necesidades de las primeras.
Si dichos tipos son de distinto grado o si son solapables será algo que sabremos sólo a medida que I2 se vaya implementando y, más concretamente, a medida que los miembros se agrupan en gigapops. Dado el rápido crecimiento del número de miembros de I2 y de los potenciales miembros de los consorcios gigapop, podría ser necesario contar con algunos nodos centrales de intercambio cuya única función sea conectar unos gigapops con otros. Como desde un punto de vista conceptual éstos formarán parte de la "nube" de interconexión de gigapops de la red, los consideraremos sólo en este contexto.
Las conexiones externas a gigapop del tipo Elementos de Conmutación ATM (Asynchronous Transfer Mode) deben ser circuitos directos SONET desde los conmutadores ATM del centro universitario a otros centros gigapop, o bien un servicio ATM pleno desde operadores comerciales. Los Elementos de Conmutación ATM sirven para multiplexar el nivel de ancho de banda del enlace a través de circuitos permanentes o virtuales (PVCs o SVCs). De esta forma, la conectividad de los intra e inter-gigapop se puede optimizar y asignar un ancho de banda para pruebas o para otros requisitos especiales.
El servicio principal del gigapop lo suministran los elementos de encaminamiento
IP. Estos pueden ser realimentados directamente desde SONET/PPP
externos o circuitos síncronos de alta velocidad, o vía enlaces
PVC/SVC hasta la línea ATM. Todas las decisiones sobre soporte
de calidad de servicio y de encaminamiento IP las toma el equipo que realiza
el reenvío de los paquetes IP y los datos sobre utilización
se extraen allí. Según lo vaya permitiendo la tecnología,
el equipamiento de reenvío de paquetes IP hará uso de la
capa ATM para establecer QoS o SVC dinámicos con el
fin de dar soporte a los diferentes requerimientos de servicio IP.
2.B. Requisitos funcionales
Una función clave del gigapop I2 es intercambiar tráfico
de un ancho de banda específico, así como otros atributos
de calidad de servicio (QoS) entre las redes de miembros I2 y el
núcleo de la red I2. Para lograr este objetivo, un gigapop debe
satisfacer una variedad de requisitos funcionales específicos.
2.B.1. Protocolos
Dado que el Servicio Común Portador de Internet2 es IP, es evidente que cualquier dispositivo de tercera capa de un gigapop dará soporte IP. Pero, ¿qué tipo de IP?. Actualmente el estándar es IPv4, pero el proyecto Internet2 puede ayudar a todos a migrar a IPv6. Por ello, todos los dispositivos de capa 3 de los gigapops deberían soportar IPv6 además de IPv4 tan pronto como estén disponibles implementaciones estables.
Por supuesto, IP no es el único protocolo en el conjunto TCP/IP.
Todo los protocolos de soporte habituales se supone que estarán
disponibles allí donde se necesiten. Además, se espera que
el IGMP (con soporte multicast), y el RSVP (con soporte
de reserva de recursos) sean muy importantes para este proyecto y por tanto
deberían estar disponibles en todos los dispositivos relevantes
de los gigapops.
2.B.2. Encaminamiento (Routing)
Los gigapops son responsables de implementar cualquier política
de usuario referente a Internet2. Por ejemplo, en la medida en que se utilice
vBNS para proveer conectividad entre los gigapops, éstos
deben enviar a su conexión vBNS solamente tráfico
destinado a otros centros I2. Hay que destacar que la conectividad física
de un gigapop no implica permiso o capacidad para intercambiar tráfico
con cualquier otra entidad que tenga una conexión con ese gigapop.
Las políticas de encaminamiento de los gigapops serán usadas
no solamente para hacer cumplir las reglas de Internet2, sino también
los acuerdos bilaterales que controlarán el intercambio de tráfico
entre los gigapops. Volveremos al tema del encaminamiento en la Sección
3.
2.B.3. Velocidad
La velocidad de conexión dentro de un gigapop o en el intercambio
con otros gigapops variará ampliamente, dependiendo del número
y la intensidad de las aplicaciones nativas I2 que estén funcionando
en sus respectivos centros universitarios. El asunto crucial para cada
gigapop es asegurar que posee la capacidad adecuada para manejar la carga
prevista de tráfico. Los conmutadores que proporcionen la interconectividad
primaria en un gigapop y los enlaces desde esos conmutadores a encaminadores
de gigapop adyacentes deberán ser dimensionados de tal forma que
el número de paquetes perdidos dentro del gigapop sea próximo
a cero.
2.B.4. Modos de enlace
La conectividad inicial de capa 2 con otros gigapops se espera que utilice
PVCs ATM desde el vBNS más algunos enlaces dedicados
que pueden ser PVCs o SVCs ATM, o meros enlaces SONET.
Los enlaces entre encaminadores gigapop conectados a enlaces de una red
de área extensa serán normalmente suministrados por conmutadores
de alto rendimiento, normalmente mediante servicios celulares o basados
en tramas (frame-based), dependiendo de las necesidades de cada
gigapop específico.
2.B.5. Medición del uso
Los costes de la conectividad inter-gigapops no se conocen todavía
y otros costes del gigapop variarán según las circunstancias
y los servicios ofertados, por lo que no es posible decir mucho sobre los
requisitos de contabilidad de costes. Obviamente, cualquier mecanismo de
precios que se escoja debe ser técnicamente viable. Los gigapops
deben por tanto guardar y compartir las estadísticas de uso necesarias
para una razonable asignación del coste entre los miembros.
2.B.6. Agrupamientos regionales
Los gigapops son por definición puntos de agregación,
pero en algunas áreas los costes del transporte digital deben fomentar
una jerarquía de uniones y puntos de intercambio dentro de una región.
En tales casos, la Entidad Colectiva debe jugar el papel constructivo de
coordinar una conectividad rentable para las instituciones afiliadas a
Internet2. Un objetivo clave para la gestión de puntos de intercambio
a tan bajo nivel es mantener la coherencia en toda la infraestructura Internet2,
tanto en lo que respecta a las prestaciones técnicas como a los
procedimientos y políticas de gestión de red.
2.B.7. Transferencia de tecnología
Dado que todo el proyecto Internet2 tiene como uno de sus objetivos
la transferencia de la tecnología Internet de siguiente generación
a la comunidad Internet, los gigapops deben jugar un papel clave en la
transferencia de la tecnología a las instituciones miembro. A pesar
de que los detalles variarán de un área a otra, es una oportunidad
importante para los operadores de gigapop compartir información
con otras instituciones miembro sobre el despliegue y la gestión
de las redes universitarias multidifusión y con soporte multi-QoS
que están surgiendo.
2.B.8. Colaboración entre los gigapops
A pesar de que la conectividad multidifusión con multi-QoS
para todos los miembros Internet2 es un objetivo importante y explícito
del proyecto, no todos los miembros I2 se verán involucrados en
todos los experimentos de aplicaciones avanzadas. En efecto, algunos de
estos experimentos implicarán a instituciones a las que dará
servicio un único gigapop. De cualquier modo, un escenario probable
sería el de varios gigapops colaborando en la experimentación
de aplicaciones específicas y otros proyectos. Por ejemplo, varios
gigapops deberían trabajar junto a empresas privadas para facilitar
conectividad avanzada para formación asíncrona a distancia
desde instituciones miembros a hogares de su entorno, de igual forma que
los gigapops podrían facilitar el intercambio de tráfico
local entre la comunidad de Proveedores de Servicios Internet en su región.
2.B.9. ¿Quién puede conectarse?
La decisión sobre qué instituciones u otros puntos de
intercambio o de agregación pueden conectarse a un determinado gigapop
le corresponde a la dirección de ese gigapop. La decisión
sobre quién puede intercambiar tráfico en un gigapop dependerá
de acuerdos bilaterales entre quienes se conecten así como de las
reglas establecidas por ese gigapop. Sin embargo, sólo los miembros
de Internet2 pueden intercambiar tráfico a través de la red
"principal" de Internet2, que es la que enlaza entre sí a todos
los gigapops.
2.B.10. Otros servicios del gigapop
Es razonable imaginar que los gigapops deberían alojar nodos caché o incluso servidores de contenido para dar soporte a las actividades de los participantes. Dado que la recogida de datos sobre las operaciones de un gigapop es uno de los requisitos básicos, se necesitan discos de gran capacidad en los centros. El caching será un medio muy efectivo para reducir la demanda de enlaces de área extensa para algunos tipos de servicios. De igual modo, el contenido ubicado en el gigapop debería estar fácilmente disponible para los participantes I2 vecinos, así como para los enlaces de área extensa.
Como servicio opcional para algunos participantes I2, deberían
estar disponibles ATM y otros niveles de enlace a través de acuerdos
especiales con los operadores del gigapop. Se puede prever que algunos
investigadores se beneficiarán de un sistema de pruebas de área
extensa de este tipo. Con apropiadas medidas de seguridad, ese sistema
se podría suministrar sin interferir con los servicios de producción
normales de I2.
2.B.11. Expectativas de rendimiento
A pesar de que un objetivo clave del proyecto I2 es entender cómo
se comporta una red con calidad de servicio múltiple en condiciones
de congestión, el gigapop no debería llegara a ser un cuello
de botella para acceder a los servicios de comunicaciones de área
extensa. La capacidad de ancho de banda total requerida por cada participante
I2 variará, pero se espera que fluctúe en el rango que va
desde fracciones de DS-3 hasta tanto como OC-12 (622 Mbps).
El diseño interno del gigapop debe ser capaz de gestionar el caudal
de procesamiento adicional demandado por todos los participantes locales
y las conexiones de área extensa. Los gigapops deben ser capaces
de suministrar el ancho de banda adicional mientras dan servicio a un número
de clientes con requerimientos especiales de calidad de servicio.
2.C. Responsabilidades operativas
Es importante que el proyecto I2 tenga un punto focal para la gestión del conjunto de las operaciones. Como dijimos al principio, esto requeriría cierta organización --una Entidad Colectiva (EC)-- a través de la cual los gigapop colaborarían para conseguir el ancho de banda y alcanzar sus otros objetivos, que por supuesto incluyen la gestión de ka red. Muy al final la EC requeriría un coordinador técnico a nivel nacional y un consejo coordinador que se reuniese regularmente. Cómo se definen éstos y otros elementos será uno de los temas clave de la gestión de I2.
Uno de los objetivos globales que tiene planteado I2 es la capacidad de estudiar el comportamiento de este complejo y dinámico sistema. Tal estudio incluirá la caracterización de los flujos de tráfico, el análisis del comportamiento de las colas en un ambiente en el que sistemas diferenciados se comunican entre sí, la monitorización del rendimiento extremo-a-extremo de I2, la revisión de la asignación de diversos costes y modelos de recuperación de costes en función del uso real del sistema. Una parte de la arquitectura del gigapop debe ser un conjunto de datos integrados con medidas de seguridad apropiadas, pero con suficiente detalle y precisión para dar soporte a estudios y análisis serios.
I2 suministrará servicios dinámicos extremo-a-extremo. Esto quiere decir que los usuarios finales pueden solicitar servicios concretos de red entre dispositivos en I2, donde se supone que esos servicios serán suministrados independientemente del número de proveedores de red involucrados en el trayecto. Estarán disponibles varios niveles de servicio y se podrán solicitar conexiones múltiples a diferentes niveles de servicio en cada momento. El usuario final no siempre conseguirá los servicios solicitados si los recursos no están disponibles para suministrar el nivel de servicio. De cualquier forma, una vez que se ha hecho la solicitud a ese determinado nivel de servicio, esa solicitud quedará garantizada.
Dada la naturaleza extremo-a-extremo de I2, el funcionamiento de la red necesitará más coordinación entre operadores de red que entre operadores de red y usuarios finales en la mayoría de las áreas de Internet. Esta coordinación debería ser lo más automatizada posible. La Internet actual carece de las herramientas y los protocolos para gestionar múltiples niveles de servicio. Uno de los objetivos de I2 será trabajar con los organismos de fijación de estándares y con los desarrolladores para crear estos protocolos y herramientas. En el desarrollo de estos protocolos y herramientas debemos tener en cuenta que al final serán usados en la Internet comercial, que opera en un ambiente distinto de confianza y cooperación que la comunidad académica.
La gestión de los servicios I2 desde los gigapops necesita ser
examinada desde dos puntos de vista. El primero se refiere a las peticiones
de servicios del usuario final y el segundo a los sistemas de red encargados
de proporcionar esos servicios. Es necesario considerar desde esos puntos
de vista tanto las operaciones normales como la resolución de problemas.
2.C.1. Gestión de red
La petición por parte de un usuario final de un servicio tendrá lugar a través del uso de una aplicación. Dicha aplicación será responsable de interactuar con el usuario final para seleccionar los niveles de servicio y aconsejar sobre la disponibilidad y el coste del servicio. La aplicación será además responsable de interactuar con el sistema de red para obtener los servicios. La manera en que las aplicaciones, el sistema operativo y la interfaz de red funcionarán juntos dependerá de la implementación de la plataforma. Buscamos un objetivo difícil: presentaciones uniformes al usuario final. Lo idóneo, por ejemplo, sería que los mensajes de error se estandarizaran de tal forma que el usuario final entendiera el error incluso si no conoce el sistema, de la misma forma que todo el mundo entiende una señal de ocupado en un teléfono, además de conocer la acción correcta a realizar.
La gestión del sistema de red que suministrará los servicios I2 debe implicar a una o más redes gestionadas por distintas entidades. La red necesita funcionar como un único sistema desde el punto de vista del usuario final. Esto requiere que las redes que funcionan independientemente coordinen las peticiones de red. Se necesita autentificación y autorización para el uso de los recursos antes de que el servicio requerido pueda ser garantizado. A continuación, el sistema debe determinar si los recursos están disponibles o no para lo que se requiere y, si es necesario, reservarlos. Una vez que la petición del servicio está garantizada, es preciso recoger datos sobre los recursos de red consumidos para el control apropiado del recurso o para contabilidad de costes. Para hacer funcionar un servicio extremo-a-extremo, cada red implicada en el camino debe seguir estos pasos de forma coordinada.
Las herramientas actuales para monitorización y diagnosis de
red ven la red como dispositivos y enlaces de comunicaciones individuales.
Normalmente esto es simplemente un status arriba-abajo y alguna carga simple
de información. Estas herramientas no ven el sistema de red como
un todo ni consideran la representación extremo-a-extremo. Hay que
desarrollar herramientas que tengan en consideración los problemas
que plantea la operación extremo-a-extremo con varios niveles de
servicio a través de múltiples redes. De igual forma, deberían
definirse procedimientos para los operadores humanos de diferentes redes
con el fin de facilitar la planificación y la resolución
de problemas.
2.C.2. Monitorización de nivel de servicio y datos
La Internet actual tiene un nivel de servicio "lo mejor posible dentro de lo que se pueda". En este ambiente es fácil tratar con total igualdad a todos los usuarios o distribuir los costes basándose en parámetros no dinámicos como el ancho de banda de la conexión. Cuando estén disponibles múltiples niveles de servicio, se debe implementar algún tipo de control de recursos o informe de costes, con retroalimentación hacia el usuario final para asegurarse de que se solicita el nivel de servicio apropiado.
Como no es obvio cuál es el mejor modelo de asignación de costes para I2, I2 será usado inicialmente para desarrollar y probar métodos de asignación de costes. Algunos objetivos están claros:
2.C.3 Seguridad
Obviamente hay una seguridad que puede ser suministrada en la capa de red y hay otra seguridad que simplemente no se puede alcanzar sin degradar enormemente otros servicios.
Los problemas de seguridad de I2 se pueden dividir en tres categorías:
La estrategia de Internet ha sido siempre que los usuarios finales son responsables de la seguridad de las aplicaciones. Sin embargo, los protocolos y las herramientas han evolucionado muy lentamente para cumplir esta estrategia. Esto ha dado lugar a que las medidas de seguridad, tales como los cortafuegos, hayan tenido que tomarse a nivel de red. A pesar de que la seguridad a nivel de red para las aplicaciones es a menudo restrictiva, podría ser empleada en la red I2 para suministrar la seguridad requerida para las aplicaciones. El uso de seguridad a nivel de red para las aplicaciones debería estar tan próximo al sistema de usuario final como fuera posible, por ejemplo, en el nivel LAN o del centro universitario.
3. Fuentes y especificaciones de conectividad
La arquitectura básica que concebimos para la infraestructura de comunicaciones de Internet2 se ilustra en la Figura 3. Los distintos segmentos de red de este diagrama encajan en dos grandes categorías: los que conectan la aplicación de los usuarios finales con el gigapop de centro universitario (algunos de los cuales, en la Figura 3, se incluyen en las nubes reticulares de los centros) y los que interconectan gigapops. Puesto que la primera es en gran medida una responsabilidad de la universidad, dando por supuesto que se cumplen los estándares básicos, dedicaremos la mayor parte de nuestra atención a las conexiones entre gigapops y al encaminamiento y a otros protocolos aplicables a todos los segmentos de red de I2.
3.A Intracampus y Campus-a-Gigapop
Los objetivos del proyecto I2 no pueden conseguirse a no ser que las redes de las universidades se actualicen a fin de proporcionar el soporte adecuado para las aplicaciones avanzadas. Esto supone contar con una red de centro universitario (campus) en la que puedan florecer aplicaciones que requieren gran ancho de banda, bajo retardo, baja alteración (low jitter) y/o encaminamiento multidifusión (multicast routing). Prevemos que los diferentes centros tomarán distintas decisiones sobre cómo conseguir este objetivo. Algunos deberán confiar en redes principales de conmutación celular, mientras que otros optarán por soluciones Ethernet basadas en tramas (frames), quizás en conjunción con sencillos esquemas de prioridades. Otros seguirán RSVP u otras técnicas de reserva de ancho de banda. En prácticamente todos los casos, los miembros de I2 necesitarán actualizar sus redes con un gasto importante; que supondrá normalmente la mayor parte de su inversión en I2.
Uno de los objetivos importantes de investigación de I2 es llegar a comprender qué grado de diferenciación de servicio es suficiente. No será una decisión fácil. Por ejemplo, quienes estén interesados en sustituir los servicios telefónicos convencionales por una red de servicios integrados podrán tener mayores necesidades que quienes se centren en herramientas de trabajo en grupo.
Suponemos que la mayoría de los centros universitarios Internet2 requerirán solo circuitos de alta capacidad hasta el gigapop más cercano y encaminadores (routers) de funcionalidad avanzada como sus pasarelas (gateways) para el centro. Los centros que deseen dar soporte a servicios adicionales o experimentales también podrían instalar un multiplexor o conmutador ATM entre el circuito de conexión al gigapop y el límite del centro.
Normalmente las conexiones campus-a-gigapop llevarán menos tráfico (medio y máximo) que las conexiones entre gigapops y también podrán llevar tráfico no perteneciente a I2. En algunos casos aún no hay ninguna fórmula económicamente factible o disponible comercialmente para conseguir los niveles de calidad de conexión campus-a-gigapop de I2 y en esos casos la calidad seleccionable de calidad de servicio podría no estar disponible para una universidad miembro hasta que el problema se haya resuelto.
Los miembros de I2 también se han comprometido a dar soporte al servicio I2 límite-a-usuario final en sus centros. Esperamos que esa conectividad I2 estará disponible:
Los requisitos claves para las interconexiones de red entre los gigapops son que proporcionen
Si bien los gigapops serán necesarios para proporcionar algunos servicios IP, serán recomendables pero no imprescindibles para dar soporte a otros experimentos de comunicaciones entre universidades. En concreto, los gigapops pueden trabajar con los centros conectados para gestionar conexiones basadas en otros servicios de comunicaciones, como ATM directo. Además de estas alternativas de capa de nivel bajo, se espera que los gigapops implementen encaminamiento y transporte de datos multidifusión como soporte a MBONE y arquitecturas similares.
Esperamos que el modo inicial de conexión entre los gigapops será la red NSF vBNS. Más adelante se espera que ésta se amplíe y mejore con otras formas de conectividad entre gigapops. Otros posibles enlaces incluyen
De cualquier modo, ésta también es una razón para retrasar la búsqueda de múltiples proveedores, ya que el problema de la existencia de varios proveedores de calidad de servicio se prevé que será difícil de resolver. Además, la capacidad de gestión de red que hemos perfilado para I2 requiere que los suministradores de red proporcionen importantes cantidades de datos sobre la operación. Hasta ahora los suministradores han sido reacios a proporcionarlos y las negociaciones para obtenerlos probablemente serán largas y complejas.
Aunque es probable que habrá algunos enlaces punto a punto entre los gigapops para satisfacer las necesidades específicas de ancho de banda o servicio, por el momento no esperamos construir y gestionar una red nacional totalmente mallada por todo el país para I2 utilizando circuitos dedicados convencionales. Por el contrario, prevemos que existirán circuitos virtuales proporcionados por una nube reticular comercial o por la vBNS, a no ser que un análisis adicional muestre que la estrategia de "arréglatelas tú mismo" sea más rentable o necesaria para conseguir los objetivos técnicos.
La Entidad Colectiva que hemos mencionado varias veces es indispensable para el diseño, adquisición y operación de la nube reticular de I2, sea quien sea el que la suministre. Nosotros creemos que la Entidad Colectiva debería tomar alguna forma empresarial, de forma que pueda negociar y hacer cumplir los contratos de forma efectiva. La decisión sobre si la Entidad Colectiva debería legalizarse para este propósito específico o para fines más amplios es una cuestión política que debe ser tomada a alto nivel.
3.C Protocolos de Encaminamiento y Calidad de Servicio
En Internet 2, el encaminamiento de la capa Internet será gestionado por los protocolos IPv4 e IPv6.
Los gigapops Internet 2 los construirán consorcios de universidades y los consorcios tendrán su propia infraestructura para interconectar su(s) gigapop(s) y sus miembros. En muchos casos, los gigapops del consorcio proveerán servicios gigapop específicos propios a los miembros del mismo antes de que se conecten a otros gigapops. En particular, los consorcios pueden tener establecidas normas de encaminamiento para el tráfico propio y entre ellos mismos, así como entre ellos mismos y otros servicios de red, antes de que se conecten con cualesquiera de los demás. A diferencia de otras redes en las que la red principal y todos los conmutadores de la misma pertenecen y son gestionados conjuntamente, Internet2 se construirá enlazando diversos organismos que tienen administraciones distintas pero coordinadas entre sí.
La experiencia pasada ha mostrado que es realmente fácil para una entidad que proporcione servicios especializados a sus miembros dejar abiertas a otras entidades rutas inadecuadas. La información de encaminamiento, por tanto, necesita ser filtrada, idealmente, y el encaminamiento entre los gigapops llevado a cabo mediante el uso de un protocolo de encaminamiento entre dominios. Esto daría a los consorcios de gigapops más libertad en sus normas de encaminamiento y proporcionaría protección mutua contra filtrados accidentales de rutas.
De todas formas, también queremos proporcionar soporte para encaminamiento basado en calidad de servicio. Hasta el momento el soporte para calidad de servicio en encaminamiento entre dominios es prácticamente inexistente. Hay aquí un compromiso entre la funcionalidad y la previsión de comportamiento de red. Si es posible una estrecha coordinación entre los gigapops, entonces podremos intentar usar un protocolo intra-dominios. Este tipo de coordinación estrecha sólo será posible si el número de participantes en Internet2 sigue siendo pequeño (donde "pequeño" se entiende en términos de nivel de coordinación, por ejemplo, un nivel de coordinación en el que los administradores de encaminamiento intercambian regularmente correo electrónico reconociéndose por sus nombres de pila).
Dado que no hay ningún protocolo de encaminamiento que satisfaga todas nuestras necesidades y no parece que vaya a haber ninguno durante varios años, necesitamos encontrar formas de abordar el problema y promover la investigación sobre encaminamiento a largo plazo.
A continuación aparecen los comentarios sobre las posibles familias
distintas de protocolos. En primer lugar comentamos los fundamentos del
encaminamiento, con o sin conocimiento de calidad de servicio, y después
se comentan las posibilidades de mejora que serán importantes para
Internet2. En todos los casos, la utilidad de los distintos aspectos del
encaminamiento de calidad de servicio puede investigarse a la vez que se
realizan exploraciones de gestión de recursos, asignando valores
a los recursos de red, y de fijación de precios.
3.C.1 Encaminamiento para IPv4
I2 la utilizarán los miembros de I2 únicamente como una red de tránsito para comunicarse con (1) otros participantes de Internet2, ó (2) otras redes especiales de investigación (como la vBNS o ESnet) a través de rutas prefijadas. Un consorcio podrá establecer conexiones con la Internet comercial y con otros servicios para sus propios fines, pero no propagará a Internet2 ninguna información recibida de los mismos. La información de encaminamiento debe ser filtrada estrictamente. Generalmente un gigapop propagará la información de encaminamiento solamente a aquellos centros reconocidos como participantes en el proyecto Internet2. Además un gigapop podría propagar información de encaminamiento para centros de otras redes de investigación si el origen de esa información de encaminamiento en Internet2 es una ruta prefijada para ese centro y/o red. Las rutas prefijadas serán decididas por la Entidad Colectiva.
Las decisiones sobre la propagación de rutas en un consorcio de gigapops son competencia del consorcio únicamente. Recomendamos que un consorcio propague a sus miembros la información acerca de la posibilidad de comunicarse con otros participantes en Internet2 a través de Internet2, pero tan solo si los miembros pueden asegurar la no filtración de esta información fuera del consorcio. Esto es, un consorcio formado en su integridad por universidades miembro, no puede pedir inadvertidamente a fuentes exteriores a Internet2 que, a través de él, se conecten a centros situados en cualquier otra parte de Internet2, a no ser que se trate de una ruta prefijada para la interconexión con esas fuentes. Internet2 no proporcionará encaminamiento de tránsito hacia otras redes principales (backbones).
Los protocolos de encaminamiento con capacidad de calidad de servicio para IPv4 aun son escasos, si es que existen. No hay soporte para calidad de servicio ni en BGP (Border Gateway Protocol) ni en IDRP (Inter Domain Routing Protocol). Aún se está trabajando en lograr OSPF (Open Shortest Path First) con capacidad de calidad de servicio.
El PNNI (Private Network to Network Interface) integrado es una posibilidad. El propósito de I-PNNI (Integrated - Private Network to Network Interface) es usar el protocolo de encaminamiento desarrollado para PNNI tanto para ATM como para IP. PNNI se ha diseñado a partir del conocimiento adquirido en el uso de sus predecesores y tiene ventajas como diseño de protocolo de encaminamiento. I-PNNI está pensado para ofrecer encaminamiento basado en calidad de servicio, tanto para IP como para ATM. No es un protocolo inter-dominios (si bien se está investigando esta posibilidad), pero tiene abstracción y agregación de elementos de red.
El encaminamiento con capacidades de calidad de servicio para IPv4
será parte de la agenda de desarrollo de Internet2. Esto no significa
que sea la comunidad Internet2 la que necesariamente haga ese trabajo,
sino que la comunidad Internet2 dará prioridad a promover el desarrollo
de encaminamiento con capacidad de calidad de servicio mediante varios
métodos.
3.C.2. Encaminamiento para IPv6
El encaminamiento para IPv6 está aun bajo desarrollo. I-PNNI está pensado para dar soporte a IPv6. IDRP, en teoría, tiene soporte para IPv6 pero las implementaciones IDRP no se consideran estratégicas y necesitarán más trabajo. IDRP tiene soporte limitado para calidad de servicio. En estos momentos, parece que IDRP será reemplazado por un nuevo proyecto, BGP4++. Se han elaborado especificaciones preliminares de OSPF y RIP (Routing Information Protocol) para IPv6, pero no se está desarrollando OSPF con capacidades de calidad de servicio. Aquellos centros que deseen experimentar con IPv6 pueden usar RIPv6 o rutas estáticas hasta que los protocolos de encaminamiento apropiados estén. Esto es factible, puesto que esperamos que en un futuro próximo haya unos pocos centros que estén trabajando con IPv6 y será posible, pues, una estrecha coordinación entre ellos. Las rutas estáticas necesitarán ser implementadas sin tener en cuenta ninguna jerarquía de relación en el Proyecto Internet2. El encaminamiento con calidad de servicio para IPv6 formará parte de la agenda de desarrollo de Internet2.
Las direcciones IPv6 pueden ser asignadas por la Entidad Colectiva.
3.C.3. Información de rutas en la capa ATM
La información de rutas de ATM será necesaria ya que muchas de las funciones de red relativas a la calidad de servicio con las cuales deseamos experimentar implican asignación dinámica de recursos en la capa ATM. Se puede esperar de ATM que use conexiones virtuales permanentes para algunas funciones (por ejemplo, transportar paquetes IP, lo cual no requiere conexiones virtuales especiales) y conexiones virtuales conmutadas para otras. Donde sea posible, las conexiones virtuales conmutadas son siempre preferibles a las conexiones virtuales permanentes, para minimizar la complejidad de la configuración y para soportar reencaminamiento en caso de problemas de red.
Ya se ha desarrollado encaminamiento intra-dominio para ATM (PNNI). En estos momentos no hay filtros de normas disponibles en ningún producto comercial ATM. En todo caso, el encaminamiento ATM tiene soporte efectivo para calidad de servicio. Hasta que no esté disponible encaminamiento más sofisticado, el encaminamiento ATM no dispondrá de filtrado. Esto es factible ya que se espera que algunos centros estén trabajando con ATM en un futuro próximo y será posible una estrecha coordinación entre ellos. También es factible con menos coordinación que el encaminamiento IP, ya que la configuración de la conexión virtual puede manejarse y monitorizarse.
Las direcciones ATM pueden ser asignadas por la Entidad Colectiva.
3.C.4. Encaminamiento y Jerarquía Internet2
Las secciones siguientes sólo se refieren a los niveles más
altos de Internet2 y ven las capas más bajas como opacas, aunque
hacen recomendaciones sobre ellas. Las reglas generales expuestas para
interacciones entre gigapops, así como entre gigapops y redes externas,
se aplican a cualquier nivel en Internet 2.
3.C.5 Dimensiones de Calidad de Servicio
Basándonos en lo expuesto hasta aquí (algo que probablemente cambiará a medida que las aplicaciones concretas empiecen a tomar forma), esperamos que I2 permita demandas en al menos cinco dimensiones de calidad de servicio (QoS o Quality of Service):
Prevemos que el tráfico I2 implicará encaminamiento IP
sobre conmutación ATM y sobre transmisión SONET, pero,
como ya esbozamos al hablar de conectividad, es todavía muy pronto
para resolver este asunto. Suponemos que RSVP y protocolos similares
comunicarán las peticiones de calidad de servicio y que la gestión
de los enlaces de nivel superior e inferior de la jerarquía de red
satisfará esas peticiones.
4. Elementos de Acción
Parte del trabajo necesario para hacer real Internet2 ya se ha hecho y estará completado en unos seis meses desde el principio del proyecto, esto es, en el verano de 1997. Una parte mucho mayor del trabajo llevará otros doce meses aproximadamente, lo cual nos lleva a un total de dieciocho meses. Alguno de los trabajos llevará probablemente los seis meses posteriores restantes del periodo de implementación de Internet2, cuya duración prevista son dos años. A continuación agrupamos algunos de los puntos focales clave para nuestro trabajo conjunto de los próximos dos años.
4.A. Las Universidades
Muchos de los miembros de I2 tienen ya planes, y por tanto proyectos activos, para actualizar sus redes a niveles de servicio I2. En general estas mejoras comienzan con la red principal de la universidad y con unos pocos centros con conexiones especiales. Creemos que todas las instituciones miembro de I2 tendrán sus proyectos de actualización de red en marcha dentro del plazo fijado de seis meses y que la mayoría de estos proyectos estarán finalizados –al menos para la red principal y un conjunto de centros distribuido razonablemente– en el plazo fijado de dieciocho meses. Esperamos que la conectividad a nivel I2 esté disponible de forma rutinaria para la mayoría de las universidades I2 en el plazo fijado de dos años.
Los principales elementos inmediatos de acción de red para las universidades I2 son cuatro:
Aquí, los elementos clave son siete:
Los elementos clave aquí son tres y son casi idénticos a los de los gigapops:
Varios elementos de acción adicionales recaerán sobre todos los que estemos involucrados con I2, actuando conjuntamente a través de nuestros consorcios de gigapop y el organismo "para todo" llamado Entidad Colectiva, cualquiera que sea la forma que éste tome. Suponemos que el actual Comité de Dirección de I2 evolucionará con el proyecto, tal vez convirtiéndose en un Comité más amplio, en el que estarían representados todos los actores de I2 para debatir e implementar objetivos, esfuerzos, asignación de costes y políticas. No nos corresponde a nosotros resolver está cuestión organizativa, pero el/los grupo(s) resultantes deberán tener que decidir sobre estos temas:
Internet2 sólo puede triunfar si cada uno de los principales actores –las universidades miembro, los consorcios de gigapop que ellas creen, la entidad nacional que ordena la conectividad inter-gigapop y los diversos socios comerciales y gubernamentales en su conjunto– lleva a cabo su cometido en el tiempo marcado.