INSTITUTO COSTARRICENSE ELECTRICIDAD

SECTOR TELECOMUNICACIONES

LICITACIÓN Por Registro NO.: 2006-LG-000038-PROV.

ADQUISICIÓN DE:

Herramienta para Desarrollo de Redes de Datos

APERTURA OFERTAS:

A LAS 09:00 HORAS DEL DÍA 19 DE SETIEMBRE DEL 2005

SAN JOSÉ, COSTA RICA

AÑO 2006

ÍNDICE

Página

CAPITULO ICONDICIONES GENERALES..........................¡ERROR! MARCADOR NO DEFINIDO.

CAPITULO IICONDICIONES PARTICULARES.................................................................................2

2.1. Licitación.................................................................................................................22.2. Invitación a Concursar:...........................................................................................22.3. Apertura de Ofertas:................................................................................................22.4. Consultas y Aclaraciones........................................................................................22.5. Vigencia de Oferta..................................................................................................22.6. Precios....................................................................................................................22.7. Tiempo de Entrega y Lugar.....................................................................................22.8. Garantía de Participación y Cumplimiento..............................................................22.9. Vigencia Garantia de los Equipos / Materiales o Servicios.....................................22.10. Modalidad y Forma de Pago.................................................................................22.11. Estudio y Adjudicación..........................................................................................22.12. Cláusula Penal o Multas.......................................................................................22.13. Sistema de Valoración y Comparación...................................................................22.14 Garantía de Fabricación de Software...................................................................22.15. SoporteTécnico.....................................................................................................22.16. Garantía de Suministros de Software...................................................................22.17 Garantía de Respaldo...........................................................................................22.18 Responsabilidad de Reparación...........................................................................22.19. Contestación al Cartel y Declaración de Cumplimiento........................................2

CAPITULO IIICONDICIONES Y ESPECIFICACIONES TÉCNICAS ..................................................2

1 Condiciones Generales...............................................................................................22 Características Específicas.........................................................................................2

CAPITULO IV CAPACITACIÓN ...........................................................................................................2

1.Generalidades.............................................................................................................22 Detalle de los Cursos..................................................................................................2

2

CAPITULO I

CONDICIONES GENERALES

Para este concurso regirán las "Condiciones Generales del Cartel Tipo de Licitaciones" publicadas en la Gaceta No. 139 del 16 de Julio del 2004" Estas pueden ser adquiridas en la Proveeduría del ICE, sita 450 metros al norte del Edificio Central en Sabana Norte, en el Área de Expedientes y Garantías, o bien accediendo a la siguiente dirección electrónica:

https://www.grupoice.com/PELWeb/consultaDocumentos.do

3

CAPITULO II

CONDICIONES PARTICULARES

2.1. LICITACIÓN.El Instituto Costarricense de Electricidad, que en lo sucesivo se denominará ICE, ente descentralizado y autónomo de la República de Costa Rica, domiciliado en San José y con cédula jurídica No. 3-000-042139-02, invita a participar en la Licitación Por Registro 2006-LG-000038 para la adquisición de una (1) Herramienta para Desarrollo de Redes de Datos

2.2. INVITACIÓN A CONCURSAR:LICITACIÓN POR REGISTRO: N°.2006-LG-000038-PROVPRESUPUESTO: (¢)181 650 000.00 Año 2006

FINANCIAMIENTO: I.C.E

2.3. APERTURA DE OFERTAS:

El Instituto Costarricense de Electricidad, recibirá ofertas hasta las 09:00 horas del día 19 de SETIEMBRE del 2006

2.3.1 La oferta será entregada en sobre cerrado en la Proveeduría del I.C.E., sita en Sabana Norte, 400 metros norte de la esquina este de las Oficinas Centrales, antes de la hora señalada para el acto de apertura de ofertas con la siguiente leyenda:

Instituto Costarricense de ElectricidadLicitación Por Registro N°.2006-LG-000038-PROVAdquisición De: Herramienta para Desarrollo de Redes de Datos

2.4. CONSULTAS Y ACLARACIONES

2.4.1. Las consultas y aclaraciones relativas a esta licitación deberán realizarse por carta o facsímil (FAX), a la siguiente dirección, con copia a la dependencia usuaria mencionada en el punto 2.4.2.

4

CARTA:Instituto Costarricense de ElectricidadAptdo. 10032-1000

San José Costa RicaLicitación Por Registro N°.2006-LG-000038-PROVAtención Proveeduría

Fax: (506) 220 - 8163Aptdo. 10032-1000San José Costa RicaLicitación Por Registro N°.2006-LG-000038-PROVAtención Proveeduría

Se le comunica a todos los potenciales oferentes que la normativa que se indica en el presente pliego de condiciones puede ser accedida en la siguiente dirección electrónica:

https://www.grupoice.com/PELWeb/consultaDocumentos.do

2.4.2. Correspondencia.

Toda la correspondencia entre el adjudicatario y el ICE, además de la facturación para efectos de pago, deberá hacerse en idioma español

DEPENDENCIA USUARIA

Oficina : Desarrollo de Plataformas - UENSIVANúmero telefónico : 243-6207Número de facsímil: 520-1744RESPONSABLE : Ing. José Pablo León Vargas, MEE

2.5. VIGENCIA DE OFERTA

La vigencia mínima de las oferta será de 120 días hábiles a partir de la fecha de apertura de ofertas.

2.6. PRECIOS 2.6.1. Los precios cotizados serán CPT (conforme los Incoterms 2003

agregándole que el ICE paga los seguros), depósito Aduanero del ICE ò en bodegas ICE Colima Tibás, según sea el caso. Dichos precios deberán cotizarse unitarios y totales, firmes y definitivos, reservándose el ICE el derecho de adjudicar en forma total o parcial.

5

2.6.2. Los oferentes deben cotizar por separado los bienes y los servicios (de instalación, capacitación, mantenimiento)

2.6.3 La oferta deberá indicar por separado los impuestos que la afecten, de no hacerlo se le aplicará el artículo No. 52.7 del Reglamento General de Contratación Administrativa.

2.7. TIEMPO DE ENTREGA Y LUGAR.

2.7.1. El adjudicatario deberá entregar los equipos dentro de los 30 días naturales a partir de la Notificación de la Orden de Compra por parte del ICE.

2.7.2. El adjudicatario deberá entregar los equipos en los Almacenes Fiscales del ICE, en Colima de Tibás.

2.8. GARANTÍA DE PARTICIPACIÓN Y CUMPLIMIENTO

Garantía de Participación

2.8.1 La garantía de participación será por un monto de un 1% del valor total cotizado con una vigencia no menor de 6 meses calendario, contados a partir de la fecha de apertura de las ofertas.

Garantía de Cumplimiento

2.8.2 La garantía de cumplimiento será por un monto de un 5 % del valor total adjudicado, con una vigencia mínima de 18 meses contados a partir de la firmeza del acto de adjudicación.

2.9. VIGENCIA GARANTIA DE LOS EQUIPOS / MATERIALES O SERVICIOS

Los oferentes deben garantizar que los bienes a suministrar, junto con los componentes que no sean de su manufactura, (tienen que ser nuevos y de última tecnología) tienen garantía y calidad sobre los materiales empleados, diseños, buena operación y las capacidades y eficiencias asignadas por el fabricante, durante un período no menor de 90 días contado a partir de la fecha en que el ICE reciba el objeto del contrato a entera satisfacción. Igualmente en el caso de servicios deberá garantizarse que los mismos se brindarán con la más alta calidad, eficacia, eficiencia y por personal capacitado.

6

2.10. MODALIDAD Y FORMA DE PAGO.

2.10.1. Los pagos de los bienes o servicios se llevarán a cabo de la siguiente manera:

50% de total contra la entrega de la herramienta de software en el Almacén Fiscal del ICE, en Colima de Tibás;

20% del total contra la instalación de la herramienta de software y

30% contra la recepción final de la herramienta de software, a satisfacción del ICE.

Los pagos serán bajo los mecanismos normales de pago del ICE, 30 dias naturales.

2.10.2 Las facturas deben presentarse en original y tres (3) copias en idioma español, después de la recepción a satisfacción por parte del ICE, de cada una de las dos fases (Primera y Segunda) definidas en el presente cartel.

2.11. ESTUDIO Y ADJUDICACIÓN

El ICE resolverá el presente concurso dentro de los 90 días hábiles siguientes contados a partir de la fecha de apertura de ofertas. El ICE se reserva el derecho de prorrogar éste plazo en caso de considerarlo necesario.

2.12. CLÁUSULA PENAL O MULTAS

2.12.1. Si existiera atraso en la entrega del suministro o la prestación del servicio de acuerdo con las condiciones del cartel y de la oferta, el adjudicatario deberá pagar al ICE por concepto de cláusula penal la suma de 0.4 % del valor total adjudicado por cada día natural de atraso.

2.12.2. Igualmente si existe una defectuosa ejecución del objeto contratado, el

adjudicatario deberá pagar al ICE por concepto de multa la suma de 0.4 % del valor adjudicado por cada día natural en que persista esta condición. Para los puntos 2.12.1 y 2.12.2 el máximo será de 25 % del valor total del contrato.

7

2.13. SISTEMA DE VALORACIÓN Y COMPARACIÓN

Las ofertas que cumplan con todas las especificaciones técnicas y legales del presente cartel, serán evaluadas de acuerdo al sistema de valoración y comparación.

Precio Menor (100 %)

2.14. GARANTÍA DE FABRICACIÓN DE SOFTWARE.Las herramientas de software deberán contar con garantía original del fabricante por al menos 90 días sobre la calidad de los materiales empleados, diseños, operación, capacidades y eficiencias. El oferente debe garantizar que los bienes a suministrar, junto con los componentes que no sean de su manufactura, son nuevos y de última generación.

El adjudicatario quedará comprometido a reponer, por su cuenta y riesgo, incluyendo el transporte y cualquier otro gasto adicional, los materiales que se pruebe se han dañado durante el período de garantía por deficiente embalaje o por cualquier otra causa que se compruebe de responsabilidad del adjudicatario.

La garantía se suspenderá durante el tiempo que le tome al Adjudicatario reparar el equipo. En caso de reemplazo del software por defectos de fabricación se suspende para luego continuar el periodo de garantía a partir de la fecha en que se hizo el reemplazo correspondiente del software..

2.15. SOPORTE TÉCNICO.

Los oferentes deben garantizar soporte técnico en:

Servicios ofrecidoso Se deberá suministrar asesoría técnica sin costos y hasta la

conclusión del presente contrato para que el ICE pueda evacuar cualquier consulta relacionada con los equipos adquiridos en los ítems objeto del cartel.

Personal asignado.o Ingenieros de la empresa certificados en las herramientas de

software.

Disponibilidad

8

o Durante el periodo de instalación y pruebas debe garantizarse una disponibilidad del 100% para las herramientas de software que se encuentren en recepción provisional.

En caso de incumplimiento de los tiempos definidos por el ICE se aplicarán las multas definidas en este cartel.

2.16. GARANTÍA DE SUMINISTROS DE SOFTWARE.

El oferente deberá garantizar la existencia y el suministro de piezas de software y actualizaciones, incluyendo los componentes que no sean de su manufactura.

2.17. GARANTÍA DE RESPALDO.

El oferente deberá demostrar mediante documento original del fabricante, en idioma español o en otro idioma con traducción bajo responsabilidad del oferente, que cuenta con el debido respaldo del fabricante específicamente para los equipos, repuestos y servicios ofertados en la presente licitación.

Esta garantía de respaldo debe cubrir la garantía de fabricación, la garantía de servicio y mantenimiento, y la garantía de repuestos y consumibles.

2.18. RESPONSABILIDAD DE REPARACIÓN

Los equipos, componentes y software con daños en el período de garantía, serán entregados al representante o directamente al adjudicatario para su reparación, quienes correrán con la sustitución temporal de la parte o equipo que garantice la continuidad del servicio contratado. Asimismo, el adjudicatario correrá con los costos de envío, reparación, devolución e instalación.

En caso de incumplimiento del adjudicatario, el ICE se aplicará las multas definidas en este cartel.

2.18.1. INFORMACIÓN TÉCNICA Y ECONÓMICA

Toda oferta deberá suministrar, en idioma español, la información completa y suficiente que permita su análisis y estudio comparativo para efectos de adjudicación.

Si los bienes cotizados son fabricados bajo una norma diferente a la estipulada, se deberá suministrar copia de la misma.

9

2.18.2. EXISTENCIA DE ACTUALIZACIONES

El oferente deberá garantizar la existencia y el suministro de actualizaciones incluyendo los componentes que no sean de su manufactura, durante 1 año a partir de la Recepción Definitiva.

2.19. CONTESTACIÓN AL CARTEL Y DECLARACIÓN DE CUMPLIMIENTO

2.19.1. Para facilitar el análisis de ofertas el ICE solicita que el cartel sea contestado en cada párrafo enumerado, incisos, cláusulas y apartados, que compongan este documento.

2.19.2. El oferente brindará en la respuesta, en idioma español, de cada uno de los numerales con toda la información necesaria, de forma tal que el ICE pueda comprobar sin lugar a dudas el cumplimiento de éstos.

2.19.3. El cartel debe ser contestado en idioma español.

2.19.4. En caso que el oferente presente información técnica ésta debe ser suministrada en español y la oferta debe contener las referencias explícitas, número de página, sección y párrafo al documento que la contiene de manera que se pueda verificar el cumplimiento de los requisitos establecidos en el pliego cartelario.

10

CAPITULO III

CONDICIONES Y ESPECIFICACIONES TÉCNICAS

INTRODUCCIÓN

La herramienta solicitada debe permitir al ICE acelerar el desarrollo de nuevos servicios sobre la red IP (Red Avanzada Internet, RAI), reducir costos de operación y mantenimiento, validar configuraciones de equipo y planificar el crecimiento y/u optimización de la red en el corto, mediano y largo plazo.

CONDICIONES GENERALES

1.1 La herramienta solicitada debe permitir como mínimo, realizar las siguientes funciones generales:

1.1.1 Crear diferentes topologías de red en forma automática

1.1.2 Recopilar e introducir diferentes parámetros de tráfico sobre las topologías de la red creadas

1.1.3 Realizar simulaciones sobre variaciones de parámetros fundamentales de la red (tráfico, redundancias, protocolos, fallas, nodos, etc.)

1.1.4 Generar reportes luego del proceso de simulación.

1.1.5 Obtener el presupuesto correspondiente a la red optimizada.

1.2 La herramienta solicitada debe ejecutarse (como mínimo) en alguno de los siguientes sistemas operativos:

Windows NT

Windows 2000

Windows XP

Windows 2003

UNIX

1.3 Todas las capacidades solicitadas en el Capítulo III son de acatamiento obligatorio y la herramienta ofrecida deberá cumplir con todas ellas sin necesidad de piezas de software o licencias adicionales que no estén consideradas en el costo total de la oferta.

1.4 El oferente debe indicar la configuración de hardware requerida para ejecutar en forma eficiente la herramienta ofrecida (Disco duro, RAM, etc) y cualquier requerimiento a nivel de versión del sistema operativo.

1.5 El oferente deberá entregar los manuales de usuario, documentación técnica y operativa en idioma español de la herramienta de software. Debe entregarse al menos

11

dos (2) copias impresas de toda la documentación, así como cinco (5) discos compactos (CD) con toda la documentación en formato digital.

1.6 El soporte técnico y las actualizaciones deben garantizarse al menos por un (1) año, a partir de la recepción satisfactoria por parte del ICE de la herramienta ofrecida.

1.7 El oferente debe aportar un listado de clientes del fabricante que hayan adquirido la misma herramienta ofrecida, donde se incluya toda la información para su comprobación. (Nombre del cliente, Teléfono, contacto, e-mail, año de compra del producto, versión de software adquirida, nivel de satisfacción del cliente).

CARACTERÍSTICAS ESPECÍFICAS

2.1MODELO VIRTUAL DE RED:

Dentro de las características específicas de la herramienta se requieren en forma obligatoria las siguientes:

2.1.1 Contar con un ambiente de red virtual que permita replicar el comportamiento de la red real mediante la creación de un modelo de la misma en una estación de trabajo independiente

2.1.2 Crear el modelo de red virtual a partir de archivos de configuración de los diferentes elementos que componen la red.

2.1.3 La creación del modelo de red virtual se debe realizar a través de una interfaz de edición que permita incluir los elementos de la red en el sistema. Dicho editor debe contar al menos con las siguientes facilidades:

2.1.3.1 Herramienta gráfica para crear la red con acciones tipo “Drag and Drop”

2.1.3.2 Capacidad de Zoom

2.1.3.3 Contar con documentación en línea

2.1.3.4 Contar con ayuda en línea que indique al operador las funciones de cada botón

2.1.3.5 Contar con un área de mensajes en los cuales se desplieguen alertas y notificaciones

2.1.3.6 Se debe permitir la creación del modelo topológico virtual de la red real. Dicho modelo debe incluir la representación de los diferentes nodos y enlaces que componen la red IP del ICE.

2.1.3.7 Se debe permitir el trabajo de edición en múltiples ventanas simultáneas, sin que por esto se afecte en forma dramática el rendimiento del equipo.

2.1.4 La introducción del modelo de la red se debe realizar en las siguientes formas : (todas son obligatorias)

12

2.1.4.1 Introducción manual de nodos y enlaces realizando las interconexiones según el criterio del operador

2.1.4.2 Introducción rápida del modelo: La herramienta debe contar con la facilidad de introducir una red completa mediante el uso de información de red pre-determinada tal como:

Tipo de topología de red: estrella, malla, bus, anillo, etc

Tipos de nodo y cantidad de nodos.

Tipos de enlaces: WAN y LAN entre otros, y sus velocidades asociadas.

2.1.4.3 Importación de topologías de red a través de archivos de configuración de los elementos que componen la red IP del ICE. El oferente debe explicar la forma en que se realiza dicha importación

2.1.4.4 A través del editor se debe permitir la introducción de parámetros de tráfico dentro del modelo topológico de la red. Dicha incorporación de información de tráfico se debe realizar como mínimo de las siguientes formas:

2.1.4.5 En forma manual mediante la definición de atributos en los nodos. Se debe contar con al menos los siguientes esquemas de modelado de tráfico:

Nodos que generen tráfico general (paquete por paquete)

Generación de tráfico de diferentes tipos de aplicaciones específicas como por ejemplo: FTP, vídeo, http, Voz, e-mail e inclusive tráfico para aplicaciones no estándar (patrones de tráfico atípicos)

Flujos de tráfico como porcentaje de utilización de enlaces

Flujos de tráfico generados desde un punto inicial de la red a un punto final (end to end)

2.1.4.6 Mediante la importación de datos de tráfico desde fuentes externas: La herramienta debe permitir la importación de datos de tráfico desde fuentes externas. Las fuentes externas soportadas deben ser, al menos las siguientes:

Archivos de texto ASCII: Se deben soportar archivos ASCII con formato CSV

Archivos provenientes de hojas de cálculo electrónicas comerciales

Archivos provenientes de programas tales como Netflow Collector (Cisco). Indicar la versión (“release”) soportado.

Archivos provenientes de al menos 2 herramientas conocidas de captura de tráfico (tales como Sniffer, Net Metrix, Net Scout, etc.)

2.2PLANIFICACIÓN DEL CRECIMIENTO DE LA RED:

La herramienta debe permitir al operador la realización de diversas funciones que permitan la planificación del crecimiento de la red mediante la generación de escenarios que analicen los resultados de cambios variados en aspectos tales como: cambios en topología,

13

cambios en capacidades de enlaces, creación de rutas alternas, cambios de protocolos, etc. Dicha planificación de red se debe realizar como mínimo, a través de los siguientes elementos:

2.2.1 Una vez que se ha creado la topología de red virtual la herramienta debe permitir configurar umbrales de tráfico que el ICE defina como objetivos de crecimiento (Por ejemplo, utilizaciones de red que no excedan el 70% en cualquier enlace de la red IP). Se deben definir diferentes umbrales para diferentes tipos de enlace.

2.2.2 Con los umbrales objetivo debidamente definidos, la herramienta debe contar con un módulo que le permita realizar un análisis de los diferentes flujos de tráfico que recorren la red. Dicho módulo debe permitir realizar una simulación de tráfico en períodos predefinidos.

2.2.3 El módulo de análisis de flujo de tráfico debe generar reportes de utilización según los siguientes parámetros:

2.2.3.1 Utilización promedio: Para cada flujo de tráfico se calcula la utilización promedio durante un periodo definido de tiempo

2.2.3.2 Tráfico pico individual: Para cada flujo de tráfico se calcula la tasa máxima (pico) durante un periodo de tiempo específico. Este reporte representa el escenario extremo en el cual todos los flujos operan a su máxima capacidad

2.2.3.3 Tráfico pico simultáneo: Se debe hacer un reporte que muestre en que momento se presentó la mayor transferencia de tráfico de un flujo particular

2.2.3.4 Tráfico en intervalos específicos: Se debe hacer un reporte que muestre la utilización promedio en un intervalo definido y para un flujo específico

2.2.4 Con los reportes generados del módulo de análisis de flujo de tráfico se debe extraer las siguientes conclusiones:

2.2.4.1 Identificar los enlaces sobre-utilizados y los enlaces sub-utilizados

2.2.4.2 La identificación de enlaces sobre-utilizados y sub-utilizados debe darse a nivel gráfico (códigos de colores definidos) y a nivel de porcentaje de utilización

2.2.4.3 Identificar los flujos de tráfico individuales que provocan la sobre-utilización de los enlaces.

2.2.4.4 Identificar los puntos finales de los flujos de tráfico que atraviesan los enlaces.

2.2.4.5 Identificar la contribución porcentual de cada flujo de tráfico en la utilización del enlace.

Identificar que flujos de tráfico no pudieron ser enrutados sobre un enlace particular y la razón de esta falla de enrutamiento.

2.2.5 La herramienta debe permitir configurar eventos de falla individuales y/o ejecutar análisis de fallas mediante procesos de iteración hasta cubrir todos los posibles

14

escenarios de falla. A través del análisis de fallas se podrá determinar el correcto diseño de rutas alternativas dentro de la red.

2.2.6 Los análisis de fallas se deben realizar tanto sobre nodos como sobre enlaces de la red ya sea en forma individual, parcial o total dentro de la red.

2.2.7 El análisis de fallas debe generar reportes que permitan al usuario conocer la siguiente información:

2.2.7.1 Enlaces que se van a sobre-utilizar en caso de una o más fallas de un enlace primario o de algún nodo de la red

2.2.7.2 El número máximo de flujos de tráfico que se enrutan sobre un enlace en caso de una falla de algún elemento de la red. Se debe contar con un reporte en el que se identifique cual o cuales fallas son las que generarán la mayor cantidad de fallos de enrutamiento

2.2.7.3 El máximo porcentaje de ancho de banda que debe ser re-enrutado como resultado de una falla en un nodo o enlace de la red

2.2.8 La herramienta debe permitir incluir facilidades para introducir esquemas de crecimiento de tráfico proyectado en forma global a todos los enlaces o en forma individual por enlace

2.2.9 La herramienta debe permitir la creación de modelos de crecimiento de tráfico según el tipo de tráfico.

2.2.10 Una vez realizado el análisis de fallas y la verificación de la utilización bajo diferentes escenarios, la herramienta debe permitir al usuario planear los diferentes cambios a la red en estudio para prever los problemas encontrados. Dentro de los posibles cambios que la herramienta debe permitir simular se encuentran los siguientes:

2.2.10.1 Aumentar la capacidad de los enlaces: Al descubrir los enlaces sobreutilizados la herramienta debe permitir aumentar la capacidad del enlace, las capacidades de enlaces deben cubrir el rango desde 2 Mbps hasta los 10 Gbps como mínimo. El aumento de capacidad de enlaces se debe hacer tanto en forma general sobre todos los enlaces o sobre enlaces individuales debidamente seleccionados

2.2.10.2 Realizar acciones de ingeniería de tráfico: La herramienta debe permitir mover diferentes flujos de enlaces saturados a otros enlaces utilizando reconfiguraciones en las reglas de enrutamiento o a través de técnicas de ingeniería de tráfico tales como MPLS

2.2.10.3 Modificar la topología de la red: La herramienta debe permitir realizar cambios de topología de la red con el fin de eliminar problemas de enlaces sobre-utilizados o flujos congestionados. Entre los cambios de topología que se puedan realizar se encuentran los siguientes: Añadir enlaces directos, disminución de hops de enrutamiento, cambios de nodos, etc.

2.2.10.4 Variar la estrategia de enrutamiento de la red: Debe permitirse cambiar los protocolos de enrutamiento en toda la red o en parte de ella con el fin de determinar el efecto sobre la red.

15

2.2.11 La herramienta debe generar un reporte de validación que permita al usuario verificar que todos los cambios realizados no rompen reglas de enrutamiento ni provocan errores dentro de la red.

2.3ANÁLISIS DE ESTIMACIÓN DE COSTOS

La herramienta debe realizar un análisis de estimación de costos que permita al usuario realizar lo siguiente:

2.3.1 Generar reportes de costos detallados para ser incluidos en propuestas de mejora o de optimización de arquitecturas de red.

2.3.2 Aplicar los parámetros de costo unitarios para cada elemento de red presente en el proyecto de diseño.

2.3.3 Aplicar un modelo de costos sobre la topología de red, para estimar el costo total de un proyecto de diseño.

2.4ANÁLISIS DE ENRUTAMIENTO IP/MPLS DENTRO DE LA RED:

La herramienta debe realizar un análisis de enrutamiento que permita al usuario verificar lo siguiente:

2.4.1 Errores de configuración dentro de los nodos IP.

2.4.2 Consumo de los recursos de la red tales como utilización de enlaces, rutas alternas, capacidad de nodos, etc

2.4.3 Como se comportan los protocolos de red ante cambios en nodos o enlaces

2.4.4 Causas de una falla de enrutamiento

2.4.5 Publicación de tablas de direccionamiento dentro de la red, de forma tal que no afecten los planes de direccionamiento establecidos (sumarización)

2.4.6 Alcance dentro de la red (reachability).

2.5REPORTES - ANÁLISIS DEL COMPORTAMIENTO ANTE CAMBIOS:

La herramienta debe contar con un módulo de análisis de flujo de tráfico que permita tanto a los planificadores de la red como a los operadores de la misma, realizar diagnósticos de problemas de rendimiento (performance) de la red actual o predecir futuros problemas según esquemas de variación de elementos de la red como: volumen de tráfico, tipos de tráfico, fallas en nodos, fallas en enlaces, errores de configuración, etc.

Para comprobar si el diseño de red es robusto y tolerante a fallas, el módulo de análisis de flujo debe permitir la generación de reportes de los siguientes tipos:

16

2.5.1 Reportes de configuración: Estos reportes deben incluir información de la configuración de los diferentes nodos que componen la red. Dentro de este tipo de reportes se deben generar al menos los siguientes:

2.5.1.1 Configuración de la pila de protocolos TCP/IP en cada nodo: Incluyendo configuraciones de protocolos como BGP, IGRP, IS-IS, RIP, OSPF, entre otros.

2.5.1.2 Direcciones IP en cada interfaz de los nodos de la red

2.5.1.3 Resumen de listas de acceso

2.5.1.4 Filtrado de direcciones IP

2.5.1.5 Reporte de rutas activas

2.5.1.6 Configuraciones de LSR y LSP a nivel del MPLS

2.5.2 Reportes de desempeño: Deben incluir información sobre el uso de diferentes recursos dentro de la red. Se deben generar al menos los siguientes reportes:

2.5.2.1 Mostrar valores máximos, mínimos y promedio de tráfico sobre enlaces escogidos

2.5.2.2 Tráfico generado por cada interfaz

2.5.2.3 Tablas de envío de rutas

2.5.2.4 Cantidad de hops en una trayectoria

2.5.2.5 Niveles de sobre-subscripción

2.5.2.6 Tamaños de paquetes transmitidos sobre los enlaces

2.5.3 Reportes de análisis de impacto por fallas: Estos reportes deben incluir información sobre el efecto que tienen los diferentes tipos de fallas que se simulen en la topología de red. Se deben generar al menos los siguientes reportes

2.5.3.1 Reporte de línea de base: Este reporte debe brindar información comparativa entre el comportamiento de la red en un ambiente previo a la generación de fallas y en otro ambiente bajo diferentes niveles de fallas

2.5.3.2 Impacto de demanda ante fallas: Este reporte debe generar información sobre el impacto que diferentes fallas en elementos de la red (nodos y/o enlaces), provocan en el ancho de banda re-enrutado, ancho de banda incapaz de ser utilizado, conexiones no satisfechas, re-enrutamientos no generados, etc.

2.5.3.3 Tráfico mínimo, promedio y máximo sobre enlaces en escenarios de fallas en diferentes nodos

2.5.4 Reportes de validación: Este es un reporte que debe indicar si el modelo de red es consistente. Este reporte debe generar listados de posibles errores, advertencias, violaciones a reglas que se encuentran en los diferentes elementos de la red.

17

2.5.5 Se debe permitir generar vistas sobre las diferentes rutas que se generan dentro de la topología de red. Dichas rutas se deben identificar sobre el mapa de la red mediante códigos de colores u otra simbología entre puntos de inicio y fin.

2.6IDENTIFICACIÓN DE PROBLEMAS

La herramienta solicitada debe contar con un módulo de identificación y diagnóstico de problemas. Este módulo debe permitir la validación de reglas de configuración para los diferentes elementos de la red. Cada regla permite examinar la configuración de los elementos de la red según un criterio pre-definido el cual en caso de no cumplirse debe generar un mensaje de error, status o advertencia.

2.6.1 Dentro del grupo de reglas que se deben soportar se encuentran las siguientes:

2.6.1.1 Reglas sobre enrutamiento BGP: Identificación de vecinos inapropiados, detección de números inválidos de AS, direcciones inválidas de vecinos entre AS, entre otros.

2.6.1.2 Reglas sobre enrutamiento OSPF/IS-IS: Identificación de áreas discontinuas, áreas de tránsito inapropiadas, identificación de enlaces virtuales inconsistentes, costos inválidos, errores en cálculo de ancho de banda de referencia, retardo de transmisión inválido, entre otros.

2.6.1.3 Reglas sobre enrutamiento IP: Máscaras de sub-red incorrectas, direcciones IP inválidas, direcciones físicas inválidas, gateway por defecto incorrecto, rutas que están definidas para atravesar un router específico pero en el mismo no se encuentran programadas, lazos de enrutamiento, entre otros.

2.6.1.4 Reglas sobre configuración SNMP: Debilidades de seguridad, cantidad correcta de servidores SNMP, traps configurados pero sin envío, entre otros.

2.6.1.5 Reglas no standard: La herramienta debe permitir la creación de reglas particulares por parte del usuario.

2.6.2 El módulo de identificación de problemas debe generar reportes con base en las violaciones a las reglas planteadas. Dicho reporte debe contener al menos la siguiente información:

2.6.2.1 Despliegue de los errores y advertencias encontradas

2.6.2.2 Despliegue de las reglas que se están cumpliendo o violando

2.6.2.3 Resumen de la cantidad de errores o advertencias generadas

2.7MODELADO DE NODOS Y PROTOCOLOS:

La herramienta debe contar con la habilidad de modelar nodos que manejen al menos, los siguientes protocolos y funcionalidades respectivas:

18

2.7.1 Pila de Protocolos TCP/IP

2.7.1.1 Diferentes calidades de servicio (IP TOS & Diffserv QoS)

2.7.1.2 Diferentes algoritmos de tratamiento de colas (FIFO, Priority Queuing, WFQ, MWRR, Custom Queuing, DWRR, MDRR)

2.7.2 IPv4

2.7.3 MPLS

2.7.3.1 CPSF

2.7.3.2 RSVP

2.7.3.3 CR_LDP

2.7.3.4 Redes privadas virtuales basadas en MPLS (RFC 2547)

2.7.4 IP Multicast

2.7.5 BGP

2.7.5.1 Importe de “BGP Router Information Base” para análisis de puntos de conexión con redes externas

2.7.5.2 Reflectores de Rutas y Confederaciones

2.7.6 EIGRP

2.7.7 IGRP

2.7.8 OSPF

2.7.9 IS-IS

2.7.10 RIP

2.7.11 SS7

2.7.12 ATM

2.7.13 PNNI

2.7.14 LAN

2.7.15 Bibliotecas de información de elementos de red de los fabricantes más reconocidos en el campo de las redes de datos.

2.7.16 Bibliotecas de información de elementos de red genéricos, con posibilidad de modificar sus características.

2.7.17 De preferencia (no es obligatorio) que incluya los siguientes protocolos:

19

2.7.16.1 GSM

2.7.16.2 GPRS

2.7.16.3 UMTS

2.7.16.4 802.11 a/b/g (WiFi)

2.7.16.5 802.15 (WiMax)

2.8ARQUITECTURA DE SOFTWARE:

2.8.1 Modelado orientado a objetos: El modelado deberá ser de tipo orientado a objetos pertenecientes a clases, para permitir que los nodos y protocolos sean modelados como clases, con herencia y especialización, con sus características y comportamiento definidos en forma de un conjunto de atributos configurables. A partir de la estructura de clases debe permitir descomponer el modelo jerárquicamente en los siguientes niveles: aplicaciones, subredes, los dispositivos que componen dichas subredes y la arquitectura interna de cada uno de ellos.

2.8.2 Modelado claro y simple: Deberá integrar herramientas de construcción de gráficas con las que se puedan modelar de forma sencilla y simple, el comportamiento de objetos, que al interconectarse con otros objetos permita formar dispositivos, los que a su vez interconecten dispositivos usando enlaces para formar redes, además crear y organizar escenarios múltiples de redes para el diseño de proyectos. Debe permitir especificar la topología y configurar sus nodos y enlaces.

2.8.3 La herramienta debe tener la capacidad para que el usuario modele:

2.8.3.1 Nodos: Definir la forma en que se interconectan y reflejar las siguientes operaciones:

Su comportamiento por medio de una máquina de estados

Gestión de paquetes.

Gestión de subcolas atendiendo diversas prioridades.

Conexión de módulos para transferencia de los paquetes.

Conexión de módulos para intercambiar información de control.

Indicar la relación de módulos.

Acceso a nodo desde otro nodo por medio de un enlace conectado al mismo.

Envío de paquetes fuera del nodo a través de un enlace conectado al mismo.

2.8.3.2 Enlaces: En función del valor de sus parámetros (ancho de banda, latencia, número de canales, porcentaje de errores esperado).

2.8.3.3 Procesos y colas: Dentro de un nodo, asignar un comportamiento predefinido a los módulos, los procesadores y las colas.

20

2.8.3.4 Análisis integrado: Deberá poseer herramientas para la obtención de los resultados de simulación. Debe ser flexible para seleccionar los parámetros a evaluar, realizar un conjunto de simulaciones y tratar estadísticamente los resultados obtenidos, además deberá facilitar el trazado de la información y el análisis de curvas de tiempo, histogramas, de probabilidad de funciones, de curvas paramétricas, y los intervalos de confianza. Debe permitir al usuario definir estadísticas nuevas e incluirlas en sus propios modelos y seleccionar las estadísticas recogidas durante la simulación. Debe disponer de una amplia variedad de estadísticas de rendimiento predefinidas que pueden ser recogidas automáticamente durante la simulación, sin intervención del usuario.

2.8.3.5 Análisis de Escenarios: Deberá permitir a los usuarios crear diferentes escenarios al modificar los parámetros y los atributos de los modelos y, a su vez, analizar el impacto de tales cambios en la conectividad de la red y la topología.

2.8.3.6 Políticas de Verificación: Deberá permitir a los usuarios establecer requisitos de conectividad entre cualquier punto de la red, y verificar el cumplimiento de estas políticas en comparación con la configuración actual de la red o un escenario nuevo. También deberá permitir comprobar la conectividad punto a punto dentro de la red entera.

2.8.3.7 Análisis de Redes: Deberá generar reportes de utilización, trayectorias de demanda y costos de enlaces, ejecutar cualquier tipo de escenarios de casos hipotéticos (“what if...”) y reportar cuellos de botella en la red, carga de tráfico, y tasas de pérdida de paquetes.

2.8.4 Interfaz Gráfica y Animación: El modelador deberá tener interfaz Gráfica (GUI) de alta resolución, para permitir observar gráficamente el comportamiento del modelo mediante animación durante la evolución de la simulación.

2.8.5 Análisis de errores (Debugger): El sistema debe ser capaz de analizar los errores surgidos durante la compilación de los modelos o durante la ejecución de las simulaciones para validar el comportamiento de simulación o localización de problemas.

2.8.6 Importar y exportar datos de otras aplicaciones: Deberá tener la capacidad para importar y exportar datos, así como resultados de simulaciones desde y hacia otras aplicaciones tales como: XML, Microsoft Word, Microsoft Excel, Microsoft Access, Microsoft SQL, y Microsoft Visio, en sus versiones más recientes.

2.8.7 Bibliotecas detalladas de protocolos y modelos de aplicación: El sistema deberá incorporar una extensa biblioteca de funciones para simplificar el escribir modelos de protocolo (Ver punto 7 de Capítulo III). Así como incorporar funciones especializadas en redes de comunicaciones y sistemas de información.

2.8.8 Soporte para dispositivos de red de diversos fabricantes: El sistema deberá contar con una biblioteca de información de los equipos de comunicaciones de los fabricantes más renombrados en el campo de las redes de datos para operadores, así como incorporar información de equipos genéricos, esta biblioteca deberá incluir información específica de equipos y su configuración básica, que permita la rápida creación de modelos de conexión entre equipos.

21

2.8.9 Mapas de Topología: Deberá ser capaz de generar mapas multiprotocolo de vistas físicas y lógicas de la red. Debe visualizar preferencias a la medida, agrupar nodos, buscar dispositivos, y sobreponer mapas geográficos sobre los que se puedan identificar diferentes localidades, o incluso países.

2.8.10 Trazado de Ruta: Debe permitir mostrar las rutas entre puntos de conexión gráficos, seleccionados por el usuario en la simulación, esta opción deberá permitir a los usuarios supervisar cada ruta para localización de fallas.

2.8.11 Reportes Web: De preferencia (no es obligatorio), deberá permitir a los usuarios acceder a informaciones de valoración y mapas de topología usando Internet o intranet.

22

CAPITULO IV – CAPACITACIÓN

1. GENERALIDADES

1.1 Cursos de Capacitación

1.1.1 El oferente deberá cotizar dos (2) cursos de capacitación con los contenidos que considere pertinentes, para ser impartidos en Costa Rica, a personal técnico y profesional encargado del Sistema.

1.1.2 El oferente deberá cotizar los precios unitarios por persona y por curso.

1.2  Idioma y Evaluación

1.2.2 El curso en Costa Rica debe ser impartido totalmente en idioma Español, claro y correcto, ya sea por el instructor o mediante traducción simultánea.

1.2.3 Durante el desarrollo del curso este aspecto será evaluado por los medios que el ICE considere competentes. Si se incumple con lo anterior el adjudicatario tendrá la obligación de repetir el curso sin ningún costo adicional.

1.3 Cronograma de Actividades

1.3.1 Se deberá presentar con la oferta un cronograma de actividades tentativo el cual se podrá ajustar previa coordinación con el Administrador del contrato con 15 días de anticipación de la capacitación propuesta.

1.4 Obligación del Adjudicatario

1.4.1 El ICE se reservará la opción de adquirir o no, la propuesta de capacitación del oferente.

1.4.2 En caso de que los cursos se adquieran, la práctica de los mismos será sobre equipos del oferente y no sobre equipos del ICE.

2. DETALLE DE LOS CURSOS

2.1 Los cursos de capacitación deberán ser para siete (7) personas de la UEN Servicios de Información y Valor Agregado (UENSIVA), sobre la instalación del software, diseño e ingeniería del sistema, pruebas preliminares, operación, gestión, mantenimiento del sistema y procedimientos de averías (troubleshooting).

2.2 Para la capacitación, el oferente deberá presentar detalladamente una descripción de los cursos a impartir, que contemple como mínimo los siguientes aspectos:

2.2.1 Los objetivos específicos por sesión, es decir, lo que será capaz de hacer el participante una vez finalizada cada sesión

2.2.2 Un temario detallado, para cada día, que garantice que se alcanzarán los objetivos propuestos, a satisfacción del ICE.

23

2.2.3 Adjuntar curriculum vitae de los instructores en idioma español, que impartirán los cursos. Tanto los cursos como los instructores deberán ser certificados por los fabricantes del sistema.

2.2.4 La duración de cada curso en días y una especificación del total de horas de teoría, así como el total de horas de práctica.

2.2.5 Detalle de las prácticas que se van a realizar y el equipo a utilizar por los participantes.

2.2.6 Los requisitos para recibir cada uno de los cursos.

2.3 En caso de requerirse equipo para impartir el curso en Costa Rica, el Adjudicatario será el responsable de su introducción al país.

2.4 Los materiales tales como manuales, folletos u otros requeridos en el curso, deberá proveerlos el adjudicatario, el costo debe ser incluido como parte del costo del curso

2.5 La fecha exacta de inicio de los cursos se establecerá de común acuerdo entre el ICE y adjudicatario.

2.6 La capacitación deberá cubrir todos los módulos del proyecto, así como del sistema de administración de servicios que los integre, que considere como mínimo (pero no únicamente):

2.6.1 Descripción básica de la estructura y funcionamiento del software.

2.6.2 Adquirir destrezas para efectuar en forma eficiente las labores de pruebas de aceptación, operación y mantenimiento del equipo y de ingeniería de sistemas.

2.6.3 Principios de interconexión del sistema a la Red IP y las interfaces utilizadas.

2.6.4 Explicar los servicios de redundancia y seguridad.

2.6.5 Manejar detalladamente todo lo referente a sincronización, operación y respaldo de los servicios del sistema..

2.6.6 A nivel operativo y mantenimiento, obtener amplios conocimientos en rutinas preventivas, fallas, alarmas, averías y puesta en operación del Sistema. Por otro lado, lograr la interpretación de datos, tráfico, estadísticas y sistemas de protección.

2.6.7 Variables de diseño, configuraciones de interconexión, dimensionamiento de los componentes del sistema.

24