Item 1: Routers del backbone (PEs)

Transcripción

1 UNIVERSIDAD DE LA REPÚBLICA OFICINAS CENTRALES LICITACIÓN PÚBLICA No. 04/15 Adquisición de equipamiento para la Red Académica Uruguaya (RAU) PLIEGO DE CONDICIONES PARTICULARES 1 - OBJETO DEL LLAMADO Y CARACTERÍSTICAS La Universidad de la República llama a Licitación Pública N 04/15 para la adquisición de equipamiento, routers, para la Red Académica Uruguaya RAU. Item 1: Routers del backbone (PEs) Se requiere adquirir hasta 3 ruteadores que oficiarán de PEs en el modelo descripto en la memoria descriptiva de la Red Modelo Anexo 1, los cuales deberán soportar las características y protocolos necesarios para implementar los servicios descriptos en los puntos 2), 3) y 4) de la memoria descriptiva de la Red Modelo Anexo 1. Asimismo deberá contar con, por lo menos, los siguientes requerimientos: Interfaces físicas: 4 interfaces Ethernet 1/10Gbps: 2 para las conexiones con cada uno de los otros 2 PEs 1 para la conexión con el servicio de acceso a Internet 1 para conectar los sitios remotos 2 interfaces Ethernet 1Gbps Se deberá ofertar como opcional la substitución de las 4 interfaces 1/10Gbps por 4 interfaces 40/100 Gbps. Se deberá ofertar como opcional la substitución de las 2 interfaces 1 Gbps por 2 interfaces 10 Gbps. Performance: Los equipos deberán soportar una Matriz de conmutación de 200Gbps non-bloking, con capacidad de ampliación al doble (400Gbps). Se valorará especialmente el grado de cumplimiento de los equipos con las características técnicas y normas especificadas en el Anexo 2.

2 Item 2: Routers remotos (CEs) En esta etapa se requiere adquirir hasta 15 routers que oficiarán de CEs en el modelo descripto en la memoria descriptiva de la Red Modelo Anexo 1. Cada CE debe soportar las características y protocolos necesarios para implementar los servicios descriptos en el punto 4) de la memoria descriptiva de la Red Modelo Anexo 1, en particular, los que se detallan en el Anexo 2. Asimismo, deberá contar con por lo menos, las siguientes interfaces físicas: 2 interfaces Ethernet 100Mbps/1 Gbps 1 para la conexión con el PEs 1 para la conexión con la red interna del sitio Se deberá ofertar como opcional la inclusión de una tercera interface de 100Mbps/1 Gbps. Performance: Los equipos deberán soportar una capacidad de forwarding del orden de 1 Gbps o 500Kpps. Se valorará especialmente el grado de cumplimiento de los equipos con las características técnicas y normas especificadas en el Anexo 2. Garantía Todo el equipamiento se deberá cotizar con 3 años de garantía. Mantenimiento Se deberá cotizar el servicio de mantenimiento anual, especificando entre otras características: modalidad (on-site, off-site), qué incluye (equipos, mano de obra, etc), tiempo mínimo de servicio de mantenimiento garantizado, nivel profesional del personal técnico. Se deberá especificar el tiempo de disponibilidad de repuestos de todos los elementos que componen los equipos (chasis, placas, interfaces, etc), para sustituir en caso de fallas. Para los equipos del backbone se debe cotizar mantenimiento on-site. Capacitación Se requiere cotizar cursos de capacitación sobre configuración y administración de los equipos ruteadores del backbone. En particular se deberá cotizar capacitación en la gestión de redes MPLS. Para todos los cursos se deberá especificar la duración de cada uno en cantidad efectiva de horas para un mínimo de 6 personas. 2 - RECEPCIÓN DE LAS DE LA OFERTAS Y APERTURA La apertura tendrá lugar en la División Suministros, Av. 18 de Julio 1968 planta baja, el día 18 de noviembre, a la hora 11. La recepción de las ofertas se realizará personalmente contra recibo en el horario de 9 a 16 horas en los días previos al acto de apertura y en éste, hasta la hora indicada, en la División Suministros, Dep. Compras, Avda. 18 de Julio 1968, planta baja., hasta el día y hora fijada para la apertura. No se aceptarán ofertas presentadas fuera del lugar y horario indicados. A efectos de la presentación de las ofertas, el oferente deberá estar registrado en el RUPE.

3 3 - RETIRO DE PLIEGOS Los interesados en participar en este llamado podrán retirar los pliegos de condiciones en la Sección Compras de esta División de lunes a viernes de 9 a 16 horas y en el sitio Web de Compras Estatales. Los pliegos de esta licitación no tienen costo. 4- PLAZO PARA EFECTUAR CONSULTAS Podrán efectuarse consultas a los correos electrónicos: compras@oce.edu.uy. diviss@oce.edu.uy, hasta el día 10 de noviembre de Las respuestas válidas a las consultas, se efectuarán hasta el día 13 de noviembre de En caso de solicitarse prórroga al plazo de recepción y apertura de la licitación, se deberá plantear con una anticipación mínima de 5 ( cinco) días hábiles previos a la fecha de apertura. La UdelaR se reserva el derecho de concederla o no. 5 - PRESENTACIÓN DE LAS OFERTAS Las propuestas deberán presentarse en sobre cerrado en idioma español, redactadas en forma clara y precisa (original y 2 copias) firmadas por el oferente o sus representantes con aclaración de firmas. Deberá contener además de todos los datos identificatorios del oferente, el domicilio real y el constituido a los efectos del presente llamado, un número de teléfono y una dirección de correo electrónico ( no excluyente) para ser notificado y/o citado. Toda cláusula imprecisa, ambigua, contradictoria u oscura a criterio del organismo, se interpretará en el sentido más favorable a éste. Las ofertas deberán venir acompañadas de la: Constancia de Voto: Acorde Ley Nº /1989, es requisito imprescindible para intervenir en cualquier procedimiento de compra ante las oficinas del estado, que al momento de la presentación de la oferta, se exhiba la credencial cívica y la constancia de voto de las elecciones municipales de los titulares o representantes de las empresas oferentes, o en su defecto las constancias sustitutivas correspondientes expedidas por las juntas electorales respectivas; con excepción de aquellos casos donde dicha documentación se encuentre validada en el R.U.P.E..6 - GARANTÍAS Garantía de Mantenimiento de Oferta. A la fecha y hora de apertura de ofertas el proponente que cotice por un monto superior al tope de la licitación abreviada, deberá haber constituido una Garantía de Mantenimiento de Oferta, en los términos y condiciones establecidas en el Art. 64 del TOCAF. Los valores correspondientes deberán ser depositados en la Sección Caja de la División Tesorería de Oficinas Centrales, 18 de julio 1968, dentro del horario de 9 a 12 horas, hasta media hora antes de la fecha de apertura Garantía de Cumplimiento del Contrato. El/los proponente/s que resulte/n adjudicatario/s por un monto superior al 40% del tope de la licitación abreviada, deberá/n constituir en la Tesorería de la Administración la garantía de cumplimiento de contrato, por un monto equivalente al 5% (cinco por ciento) del monto total adjudicado, impuestos incluidos, en los términos y condiciones establecidos en el Art. 64 del T.O.C.A.F., una vez intervenido el procedimiento por el Tribunal de Cuentas de la República, en un plazo de cinco días hábiles. La falta de constitución de esta garantía en tiempo y forma, dentro de los 5 días hábiles posteriores al vencimiento del plazo originario previsto, podrá hacer caducar los derechos del adjudicatario, pudiendo la Administración ejecutar la garantía de mantenimiento de oferta, iniciar las acciones que pudieran corresponder contra el adjudicatario, por los daños y perjuicios que cause su incumplimiento, tomar como antecedente negativo en futuras licitaciones este hecho y, reconsiderar el estudio de la licitación con exclusión del oferente adjudicado en primera instancia. La garantía de fiel cumplimiento de contrato se devolverá dentro de los 30 (treinta) días

4 hábiles siguientes a la recepción del equipamiento. 7.- VALOR DE LA INFORMACION TECNICA PRESENTADA. Los datos indicados por el proponente referidos a los elementos contenidos en la oferta, tendrán carácter de compromiso. Si se verifica que no responden estrictamente a lo establecido en la propuesta, la Universidad de la República podrá rechazarlos de plano, rescindiendo el contrato respectivo sin que ello dé lugar a reclamación de clase alguna. 8- COTIZACION DE LA PROPUESTA. Cotizar en condiciones de pago crédito 30 días. Las ofertas podrán presentarse en moneda nacional o en moneda extranjera. En el caso de las cotizaciones en dólares u otras monedas extranjeras, para la comparación de las ofertas, se tomará en cuenta el tipo de cambio interbancario comprador o arbitraje del día anterior de la fecha de apertura. Para el caso de que el tiempo insumido para el pago sobrepase este plazo, el oferente podrá establecer un recargo que no podrá superar el interés vigente para los recargos por financiación que cobra la Dirección General Impositiva. No podrán aplicarse fórmulas paramétricas para calcular recargos por demora en los pagos. Las ofertas deberán deberán incluir incluir en el precio la totalidad de los impuestos que correspondan, explicitándose claramente cuáles son (si correspondiere). En caso de que esta información no surja de la propuesta, se considerará que el precio cotizado comprende todos los impuestos. En caso de presentación de paramétrica que incida en el precio ofertado, la variación tendrá validez desde el momento de la fecha de apertura hasta la fecha de entrega. 9 - PLAZO DE MANTENIMIENTO DE LAS PROPUESTAS Las ofertas serán válidas y obligarán al oferente por el término de 90 días, a contar desde el día siguiente al de la apertura de las mismas. El vencimiento del plazo establecido precedentemente no liberará al oferente, salvo que medie notificación escrita a esta División manifestando su decisión de retirar la oferta y falta de pronunciamiento de esta última en el término de diez días hábiles perentorios. 10- CRITERIO DE EVALUACIÓN DE LAS OFERTAS Las ofertas se evaluarán de acuerdo a los siguientes aspectos: ASPECTO FACTOR DE PONDERACIÓN Técnico 50% Precio 30% Antecedentes del oferente 20% Aspecto Técnico: Se evaluará la calidad técnica de la propuesta, el grado de cumplimiento de las normas técnicas descriptas en el Anexo 2, y características opcionales por encima de los requisitos mínimos. Este factor se ponderará con un valor de hasta un 50%. Precio: El precio se ponderará hasta un valor del 30% y para el mismo se utilizará la siguiente paramétrica: valor = 30 * resultado valoración P mín donde resultado de valoración = P ofertado P ofertado = cada uno de los diferentes precios ofertados.

5 Antecedentes del oferente: Se tendrán en consideración las experiencias con las empresas oferentes de los últimos 3 años en la adquisición de servicios similares al solicitado en la licitación. Este factor se ponderará con un valor de hasta un 20% Ambiente de pruebas Como parte del proceso de adjudicación podrá haber una instancia de pruebas, en la que técnicos designados por UdelaR puedan validar el correcto funcionamiento de un conjunto de configuraciones a acordar con el oferente, representativas de los escenarios expuestos en la memoria descriptiva de la Red Modelo Anexo 1. El armado del ambiente será responsabilidad del oferente, y éste puede hacer uso tanto del mismo modelo hardware y software ofertado, como así también de una alternativa de menores prestaciones, en la medida que la experiencia de uso y el esquema de configuraciones se corresponda con el de la solución ofertada. El armado del ambiente y el acceso al mismo por parte de los técnicos de UdelaR, será sin costo para esta. Se considerará aceptable el acceso directo o remoto, a un ambiente físico o virtual, dentro o fuera de fronteras. La interacción con el ambiente puede darse a través de una Graphical User Interface (GUI) o mediante una Command Line Interface (CLI) PRUEBAS DE INTEROPERABILIDAD Será responsabilidad del oferente asegurar la interoperabilidad de los equipos del backbone con los routers marca Cisco de las series 19xx y 29xx ya existentes en la red, de acuerdo a los servicios de red requeridos descriptos. Este hecho deberá manifestarse en la propuesta realizada por los oferentes. SeCIU podrá solicitar la realización de pruebas de interoperabilidad, a realizar en forma conjunta con la empresa adjudicataria, entre los equipos adjudicados y los routers ya existentes en la red. El detalle de las pruebas lo definirá SeCIU, y se le comunicará al adjudicatario con anticipación. El adjudicatario deberá suministrar todos los instrumentos necesarios para realizar estas pruebas. Se dejará sin efecto la adjudicación en caso de que se constaten problemas de interoperabilidad en las pruebas ADJUDICACION.La adjudicación de la licitación será realizada por la Universidad de la República, quedando condicionada a la intervención preventiva de la legalidad del gasto que corresponda. La Universidad de la República se reserva el derecho de adjudicar la licitación a la/s oferta/s que considere más conveniente para sus intereses y las necesidades del Servicio, declarar desierta o rechazar todas las ofertas, así como solicitar ampliación de información o seguir otros cursos de acción por razones de buena administración, de acuerdo previsto en el T.O.C.A.F. Podrá aumentar o reducir la cantidad a adjudicar en los mismos términos previstos por el art. 74 del T.O.C.A.F NEGOCIACIONES.Cuando sea pertinente la Administración podrá utilizar el mecanismo de la negociación de acuerdo a lo previsto en el Art. 66 del T.O.C.A.F. En el caso de presentación de ofertas similares, podrán, si se considerara conveniente para la Administración, entablarse negociaciones reservadas y paralelas con aquellos oferentes que se precalifiquen a tal efecto, a fin de obtener mejores condiciones técnicas, de calidad o precio PLAZO Y LUGAR DE ENTREGA. Plazo: no podrá ser superior a 120 días. Lugar: los equipos se entregarán en el local de Seciu ubicado en Colonia 2066, Montevideo 15.- RECEPCIÓN.

6 Los artículos adquiridos se recibirán por personal autorizado, quién procederá a controlar la entrega, pudiendo rechazar el material que a su juicio se estime en mal estado o que no se ajuste a lo pactado. En caso de que algún elemento no cumpla lo establecido, el proveedor, a su costo, deberá sustituirlo por el adecuado, no dándose trámite a la recepción hasta que no se haya cumplido la exigencia precedente CLAUSULAS ESPECIALES. Las firmas adjudicatarias deberán estar al día con las obligaciones fiscales y leyes sociales EXENCION DE RESPONSABILIDAD. La Universidad de la República podrá desistir del llamado en cualquier etapa de su realización o podrá desestimar todas las ofertas. Ninguna de estas decisiones generará derecho alguno de los participantes a reclamar por gastos, honorarios o indemnizaciones por daños y perjuicios NORMATIVA APLICABLE. Esta Licitación se enmarca, en lo aplicable, en lo dispuesto en el T.O.C.A.F. aprobado por el decreto 150/2012 y las leyes, decretos y resoluciones vigentes a la fecha de apertura de la licitación. **************

7 ANEXO 1 Memoria descriptiva de la Red Modelo 1) Introducción Este capítulo describe las principales características del nuevo backbone IP/MPLS para la Red Académica Uruguaya (RAU). Se requiere un backbone a ser constituido en esta primera etapa por tres nodos (PEs) carrier-grade (con capacidad de contar con fuente, control, forwarding y backplane redundantes), cada uno en un punto geográficamente distinto. Los puntos en cuestión son: el Servicio Central de Informática Universitaria (SeCIU), el Hospital de Clínicas (HoCli) y la Facultad de Ingeniería (FIng). Esta red también comprende routers a ser emplazados en sitios remotos (CEs), parte de los mismos serán equipos existentes y parte serán adquiridos en esta compra, y por tanto se incluyen requerimientos de funcionamiento conjuntos. Sobre este backbone se implementarán diversos servicios y cada router MPLS cumplirá al mismo tiempo varias funciones: i. la de backbone propiamente dicho (tráfico entre los tres puntos), ii. la conexión redundante y balanceada entre la RAU e Internet (hoy centralizada en SeCIU) y iii. las conexiones de acceso hacia el resto de los puntos que integran la RAU (también centralizadas en SeCIU hoy día). En un principio la implementación de los servicios se hará usando VPNs (capas 2 y 3) según los estándares industriales: point-to-point (pseudowire), virtual private LAN service (VPLS) y virtual private routed network (VPRN). Se ha optado por usar OSPF como protocolo interno de routing (IGP), y por la simplicidad de la topología en esta instancia se planea delegar la negociación de túneles en el protocolo LDP (Label Distribution Protocol). Los tres nodos son el primer paso en un proyecto de despliegue geográfico de la RAU. Se ha apuntado a un diseño escalable, capaz de integrar en el futuro nuevos nodos en estos y otros puntos. No se prevé superar el número de veinte nodos en el backbone en el mediano plazo. Asimismo, esta red académica es la plataforma para explorar nuevas tecnologías y debe tener flexibilidad entonces para acompasar la evolución de los protocolos. En este sentido los routers deben ser provistos para soportar otros estándares, como RSVP-TE y SDN. El presente documento presenta diversas configuraciones de uso que deben tomarse como ejemplos de aplicación dentro de un conjunto potencialmente mayor. Los casos no pretenden agotar la casuística del uso que se le dará a esta red. En el Anexo 2 Normas y características técnicas se incluye una lista no exhaustiva de los estándares a soportar por los nodos ofertados, para los modelos de: chasis, controladoras, placas de forwarding y de línea, así como el software ofrecido a todo nivel. De ser necesarios distintos modelos en las placas de línea para implementar la red modelo, el hecho debe ser debidamente detallado en la oferta.

8 2) Tecnologías y servicios en el backbone IP/MPLS Todas las conexiones en este proyecto son provistas por ANTEL. Ellas incluyen las conexiones entre los nodos del backbone, las conexiones de acceso y las conexiones de los tres puntos con Internet. En esta etapa todas las conexiones serán soportadas sobre el backbone IP/MPLS de ANTEL. En un futuro próximo y a medida que los aumentos de ancho de banda lo justifiquen, se espera migrar a ópticas las conexiones entre nodos del backbone, pero en su versión inicial el backbone IP/MPLS de la RAU será un overlay de la red de ANTEL, soportado sobre servicios punto-a-punto Ethernet (pseudowire Ethernet/ LAN2LAN). La figura Figura 1 muestra el esquema de la configuración base, donde todos los enlaces punto-apunto entre los PEs (HoCli, FIng y SeCIU) tendrán una velocidad de línea de 1Gbps (1000baseT). En un futuro próximo estas conexiones evolucionarán a 10Gbps (10GigE XFP). Se valorará que las interfaces físicas de las placas de línea de 1Gbps y 10Gbps puedan ajustarse mediante SFPs+ (small form-factor pluggable). Los routers de este backbone deben soportar interfaces Ethernet de 1Gbps y 10Gbps. Se valorará la posibilidad de contar con interfaces de 40Gbps y 100Gbps. En todos los casos se pide compatibilidad con los estándares IEEE: 802.1ad (Q-in-Q), 802.1q (VLANs) y 802.1p (QoS). El IGP de la RAU será OSPFv2 (RFC2328) en una única área backbone. Las interfaces físicas y lógicas serán numeradas con direcciones privadas. Los routers a adquirir deben soportar las extensiones al protocolo OSPF para ingeniería de tráfico (RFC3630). Se valorará además soportar OSPFv3 (RFC5340 y RFC5329). En una primera etapa la señalización de los túneles (LSPs) entre switches MPLS (LSRs) se hará mediante el protocolo LDP (RFC5036). La configuración de suministros incluidos en esta oferta debe soportar además el uso de túneles negociados mediante RSVP-TE (RFC3209). Se requiere tratamientos distintos para los diferentes tipos de tráfico en cada punto de la red. Esta red debe soportar el soporte para Diff-serv según el estándar RFC3270. Se pide que la red ofrecida permita la integración con otros componentes bajo la arquitectura SDN (Software Defined Networking), según los estándares de OpenFlow definidos por la ONF (Open Networking Foundation). Se valorará el soporte de la arquitectura Path Computation Element (PCE), tanto del lado cliente (router) como del servidor, el cual se cotizará, indicando las características de SW y HW y los algoritmos de Ingeniería de Tráfico soportados, para una red de decenas de routers. También se valorará el soporte de la tecnología Virtual extensible Local Area Network (VXLAN,

9 RFC7348), en los escenarios de despliegue donde los componentes ofertados (CEs y routers del backbone) puedan actuar como VXLAN gateways. La distribución de la información de routing se realizará sobre M-BGP (Multiprotocol BGP/RFC4760). La red ofertada debe soportar completamente las familias de direcciones: ipv4, ipv6, vpnv4, vpnv6 y l2vpn. Los servicios a soportar en este backbone son: Pseudo-Wire Emulation Edge-to-Edge (PWE3), MPLS Unicast IP Forwarding, Layer 2 MPLS VPN (VPLS BGP-based y LDP-based), Layer 3 MPLS VPN (VPRN-BGP/MPLS-IP-VPN). Se requiere soporte para Multicast: Internet Group Management Protocol Versión 3, Protocol Independent Multicast (PIM). 3) Conexiones con Internet En la nueva RAU la conexión pública con ANTEL, hoy centralizada en SeCIU, se multiplica y pasa a distribuirse entre los tres nodos. La figura Figura 2 muestra el esquema correspondiente a la implementación elegida. En cada uno de los tres nodos se destinará una interface o sub-interface del router, conjuntamente con dos interfaces en sendos routers de borde de ANTEL, para formar parte de una LAN virtual (VPLS en la red de ANTEL). Posteriormente se establecerán sesiones BGP entre todos los routers a efectos de balancear y al mismo tiempo proteger el tráfico entregado/recibido en cada sitio. Este control se implementará mediante una combinación de prefijos de distinta especificidad, comunidades y otros atributos de BPG. Las sesiones ebgp podrán ser establecidas entre una VRF de cada router y los routers de borde de ANTEL o desde la tabla nativa, esto es, los updates pertenecen a las familias: vpnv4vpnv6 o ipv4-ipv6. La solución ofertada debe implementar al menos los siguientes atributos opcionales de BGP: COMMUNITY (Comunidades BGP) y MULTI_EXIT_DISC (Multi Exit Discrtiminator o MED). 4) Conexiones de acceso

10 La heterogeneidad en las conexiones de acceso es mayor que las del backbone, y está condicionada al tipo de tecnología disponible. Actualmente, en los sitios remotos se dispone de un parque de routers Cisco modelos 19xx y 29xx que formarán parte de la red. Como común denominador los puntos remotos contarán con una única conexión de acceso con la red de ANTEL, que implementa a su vez una LAN virtual (VPLS) hacia dos interfaces o sub-interfaces de un mismo nodo de RAU, o de dos nodos distintos. Ambas posibilidades deben ser soportadas. La figura Figura 3 presenta la variante en la que las interfaces (ia e ib) de la VPLS pertenecen a nodos distintos. En caso de terminar más de un sitio remoto en un mismo puerto, la red de ANTEL sobre la que la VPLS está implementada marcará cada sitio con un tag Ethernet diferente, eventualmente con distintas prioridades (802.1p). Este o-tag (por outer-tag) se asocia entonces a cada sitio remoto. Complementariamente se espera tener al menos dos implementaciones posibles para separar el tráfico entre los puntos de acceso y el backbone: con VRFs en los CEs y sin VRFs en los CEs. CEs con soporte de VRFs: El primer caso soporta solapamiento de direcciones IP y separa el tráfico en el uplink del CE usando tags Ethernet (i-tags por inner-tags), uno por VRF. Al llegar al router de la RAU, los frames arrastran entonces una combinación de dos tags: o-tag/i-tag, que permite identificar punto-remoto y red-privada respectivamente, definiendo por tanto una asociación uno-a-uno entre cada combinación de tags y una VRF, o un VRF to Attachment Circuit según la RFC4364 (BGP/MPLS IP Virtual Private Networks). En la Figura 4 se representa esa implementación.

11 Además de separar el tráfico, este esquema de VRFs sin MPLS en el los routers de acceso (VRFLite), debe poder mantener procesos de routing independientes por cada VRF y/o circular publicaciones entre el backbone y los CEs mediante un único proceso mediante M-BGP, cuando esas publicaciones se marquen con el Router Distinguisher correcto. También debe ser posible la coexistencia de VPNs IP con Ethernet. En este caso debe poder configurarse en el CE un grupo de bridge por cada VRF-L2 que agrupe las interfaces pertenecientes a la misma con la VLAN correspondiente en el uplink. Una vez en el backbone, el tráfico debe ingresar al Pseudo-wire o la VPLS correcta. CEs sin soporte de VRFs: En otros casos no es posible o deseable implementar VRFs en los CEs, ni separar los tráficos de las distintas redes en el uplink. Aunque ahora en el remoto no habría solapamiento de IPs, sigue siendo mandatorio implementar VPNs para conectar a la red-privada correcta en el backbone. Esta situación, contemplado en la RFC4364, establece una situación de una a varias entre un Attachment Circuit y las VRFs. El tráfico IP será clasificado en la VRF correcta siguiendo un mapeo estático entre rangos IP y VRFs. La Figura 5 esquematiza la situación anterior. En esta alternativa el CE tendrá un único default-gateway que será protegido mediante un proceso de VRRP por cada remoto entre las interfaces de los PEs. Para mantener un control adecuado del tráfico entre VPNs se requiere la separación efectiva del tráfico entre VRFs del CE. Se exige por tanto contar en los CEs con PBR (Policy Based Routing), concretamente para forzar el envío hacia el default-gateway de todo tráfico originado en una VRF con destino en cualquier otra subred que tenga presencia local en el CE. 5) Dimensiones de la Red Modelo

12 La red contará, inicialmente, con 3 PEs (en el backbone) y 60 CEs (sitios remotos). A mediano plazo esta podrá crecer hasta 10 PEs y 100 CEs

13 ANEXO 2 Normas y características Técnicas Este anexo describe las normas y características que deberían cumplir los equipos ofertados. En algunos aspectos se especifican características obligatorias. El grado de cumplimiento de estas se tomará como factor importante en la evaluación técnica. * ALTA DISPONIBILIDAD Los nodos del backbone deberían implementar las siguientes características que aseguren su máxima disponibilidad. a) b) c) d) e) f) g) h) i) j) k) l) Fuente AC: mínimo (1+1) Soporte de Non Stop Forwarding Soporte de In Service Software Upgrade Stateful Switch Over (SSO) Soporte de Non Stop Routing Fast Re-route (node y link protection) Secondary path Link Aggregation Bidirectional Fault Detection en los protocolos OSPF, LDP y BGP PseudoWire redundancy VRRP Soporte de Graceful Restart (GR) y Non Stop Routing en los protocolos OSPF, BGP, LDP, RSVP-TE m) Soporte de Redundancia de Control (1+1). Se deberá cotizar como opcional los elementos necesarios adicionales para cumplir con esta redundancia. n) Soporte de Redundancia de Switch Fabrics (1+1). Se deberá cotizar como opcional los elementos necesarios adicionales para cumplir con esta redundancia. * INTERFACES ÓPTICAS Las interfaces ópticas deberán poder ser conectadas con jumpers de fibras monomodo que cumplan con las normas G.652 del UIT-T. Se deberá indicar el tipo de conector utilizado en el equipo, debiendo estar el mismo de acuerdo al estándar EIA/TIA. Se deberá explicitar si las tarjetas ópticas requieren de un transceiver externo (plugin GBIC, SFP, XFP u otro). * ALIMENTACIÓN Los equipos del backbone deberán ser alimentados a 220VAC con una tolerancia de +/- 20%. Se deberá indicar el consumo de cada módulo del equipo. Los equipos deberán disponer de dos entradas de alimentación de corriente, de forma de poder funcionar en condición de hot-standby,.

14 * CALIDAD DE SERVICIO E INGENIERÍA DE TRÁFICO La solución deberá contemplar los siguientes requerimientos: o) Las interfaces de red deberán tener como mínimo 8 colas, una para cada ALTA DISclase de servicio en MPLS. p) Se deberá poder limitar el ancho de banda dentro de las interfaces/sub-interfaces de acceso ( attachment-circuit ) de las VPNs. q) Se deberá tener soporte de H-QoS. r) Se deberá tener soporte de E-LSP y L-LSP. s) El número mínimo de attachment-circuit donde se realizará el control de calidad de servicio debe ser de al menos 1000 en todas las interfaces físicas solicitadas.. * SERVICIOS Los nodos del backbone deben soportar los siguientes servicios: a) b) c) d) e) Pseudo-Wire Emulation Edge-to-Edge (PWE3) MPLS Unicast IP Forwarding Layer 2 MPLS VPN (VPLS BGP-based y LDP-based) Layer 3 MPLS VPN (VPRN-BGP/MPLS-IP-VPN) Multicast para las familias de direcciones ipv4, ipv6, vpnv4, vpnv6, y en la integración de estos con servicios de capa-2 Ethernet Deberá ser posible vincular el tráfico proveniente de una interfaz de acceso marcado con uno o más niveles de VLAN tags (Q-in-Q o IEEE 802.1q), a un PW Ethernet, una VPLS o una VPN MPLS. También deberá ser posible clasificar tráfico dentro de una misma interfaz según rangos de direcciones IP de origen. * ESCALABILIDAD Cada nodo del backbone debería superar cualquier combinación de los siguientes valores. Cantidad mínima de VRFs: Cantidad mínima de PW Ethernet: Cantidad mínima de VPLSs: Cantidad mínima de túneles RSVP: Cantidad máxima de nodos en el área OSPF: * PROTOCOLOS Y ESTÁNDARES De acuerdo a la red modelo descripta anteriormente, los nodos de la red deberán soportar los protocolos básicos Ethernet y deberían cumplir con las siguientes normas según corresponda:

15 a) b) c) d) e) f) g) h) i) j) k) l) m) n) o) p) IEEE IEEE 802.3u (Fast Ethernet) IEEE 802.3z (Gigabit Ethernet) IEEE 802.3ae (10Gigabit Ethernet) IEEE 802.3ba (100Gigabit Ethernet) IEEE 802.1d (Spanning Tree) IEEE 802.1w (Rapid Spanning Tree) IEEE 802.1s (Multiple Spanning Tree) IEEE 802.1p (Clases de Servicio) IEEE 802.1q (VLAN) IEEE 802.3ac (VLAN tagging) IEEE 802.3x (Control de flujo) IEEE 802.3ad (Link Aggregation) IEEE 802.1ad (Provider Bridges) IEEE 802.3ah (Ethernet Operation, Administration and Maintenance) IEEE 802.1ag (Connectivity Fault Management) Los nodos del backbone deberán implementar el protocolo de ruteo interno OSPF, y deberían cumplir con las siguientes normas específicas: a) RFC OSPF Versión 2 b) RFC Traffic Engineering (TE) Extensions to OSPF Versión 2 c) RFC OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) d) RFC Dynamic Hostname Exchange Mechanism for OSPF e) RFC OSPFv2 HMAC-SHA Cryptographic Authentication f) RFC OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type g) RFC Hiding Transit-Only Networks in OSPF Los nodos del backbone deberán soportar MPLS y deberían cumplir con los siguientes normas no siendo la lista exhaustiva: a) b) c) d) e) f) g) h) i) j) k) l) RFC Multiprotocol Label Switching Architecture RFC LDP Specification RFC Graceful Restart Mechanism for Label Distribution Protocol RFC Resource ReSerVation Protocol (RSVP) Versión 1 Functional Specification RFC BGP/MPLS IP Virtual Private Networks (VPNs) RFC Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling RFC Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling RFC Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks RFC Virtual Router Redundancy Protocol (VRRP) RFC Framework for IP Multicast in MPLS. draft-ietf-bfd-mpls-07.txt (BFD for MPLS LSPs) draft-ietf-pwe3-redundancy-01.txt (Pseudowire Redundancy)

16 m) n) o) p) draft-ganti-mpls-diffserv-elsp-02.txt (E-LSP) RFC Extensions to RSVP-TE for Point-to-Multipoint TE LSP RFC Encapsulation Methods for Transport of Ethernet over MPLS Networks RFC Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Los nodos del backbone deberán soportar Multicast y deberían cumplir con los siguientes normas no siendo la lista exhaustiva: a) b) c) d) e) f) g) h) i) j) k) l) m) n) o) p) RFC Host Extensions for IP Multicasting RFC Internet Group Management Protocol, Versión 3 RFC Protocol Independent Multicast-Sparse Mode (PIM-SM) RFC Multicast Source Discovery Protocol (MSDP) RFC Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) RFC PIM Group-to-Rendezvous-Point Mapping RFC Using IGMPv3 and MLDv2 for Source-Specific Multicast RFC Source-Specific Multicast for IP RFC Source-Specific Protocol Independent Multicast in 232/8 RFC Anycast-RP Using Protocol Independent Multicast (PIM) RFC Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) draft-rosen-vpn-mcast-14 RFC Multicast Source Discovery Protocol (MSDP) RFC Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) RFC Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages RFC Multicast in MPLS/BGP IP VPNs RFC BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs Todos los nodos deberán soportar IPv6 y deberían cumplir con las siguientes normas sin ser esta una lista exhaustiva: a) b) c) d) e) f) g) h) i) j) k) RFC Path MTU Discovery for IPv6 RFC Internet Protocol v6 (IPv6) Specification RFC Neighbor Discovery for IPv6 RFC Transmission of IPv6 Packets over Ethernet Networks RFC Management Information Base for IP Versión 6 RFC Management Information Base for IP Versión 6 RFC IP Versión 6 over PPP RFC Default Address Selection for IPv6 RFC Unique Local IPv6 Unicast Addresses RFC IPv6 Addressing Architecture RFC Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versión 6 (IPv6) Specification. Los nodos del backbone deberán soportar Graceful Restart y deberían cumplir con las según las siguientes normas:

17 a) b) c) d) e) RFC Graceful Restart para BGP RFC Graceful Restart para LDP RFC Graceful Restart para BGP con MPLS RFC Graceful Restart para OSPF RFC Graceful Restart para RSVP-TE Los nodos del backbone deberán soportar BGP y deberían cumplir con las siguientes normas: a) RFC Border Gateway Protocol 4 (BGP-4) b) RFC Multiprotocol Extensions for BGP-4 c) RFC BGP Support for Four-octet AS Number Space Los nodos del backbone deberán soportar los siguientes protocolos CE-PE en las VPN MPLS: a) RIP, BGP-4. Los nodos del backbone deberán soportar Traffic Engineering y deberían cumplir con las siguientes normas específicas: a) b) c) d) e) f) RFC A Provider Architecture DiffServ & TE RFC Requirements for Traffic Engineering over MPLS RFC RSVP Cryptographic Authentication RFC RSVP Cryptographic Authentication (Updated Message Type Value) RFC Extensions to RSVP for Tunnels RFC Fast reroute Extensions to RSVP-TE for LSP Tunnels Los nodos del backbone deberán soportar las siguientes normas de Calidad de Servicio: a) RFC Multi-Protocol Label Switching (MPLS) Support of Differentiated Services * SOFTWARE DEFINED NETWORK (SDN) Los equipos del backbone deberá soportar el modelo SDN. Se deberá especificar el grado de soporte de este modelo en los equipos ofertados, y el grado de compatibilidad con el protocolo Openflow. * OPERACIÓN Y MANTENIMIENTO Los equipos ofertados deben permitir la funcionalidad de monitoreo a través SNMP v2c y SNMPv3. Así mismo deberá soportar el protocolo NetFlow version 9 (RFC3954) como mecanismo de recolección información del tráfico IP. Los nodos del backbone deberán soportar: a) Hot-Swap, se deberá poderse insertar o remover tarjetas sin apagar el equipo y, en caso de ser tarjetas de interfaces, sin afectar el servicio en el resto del equipo. b) Gestión, se podrá hacer a través de consola serial y puerto Ethernet (por cobre).

18 c) Poseerá interfaz de comando (CLI) que permita acceder a la totalidad de las funcionalidades y configurar la totalidad de los parámetros del equipo. Además, esta interfaz deberá ser accesible remotamente mediante Telnet y Secure Shell (SSH). d) SNMP, deberán soportar SNMP Versión 2c (RFC 3416, RFC 3417, RFC 3418) y Versión 3 (RFC 2570, RFC 2576, RFC 2786, RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418). e) En caso de cumplir con SNMPv2c, se deberá detallar cuáles operaciones están implementadas por los correspondientes agentes SNMP. Si cumple con SNMPv3 deberá indicarse cuáles aplicaciones están implementadas en la entidad SNMP de dicha versión. Deberá implementar las operaciones de GET y SET. La implementación de los agentes o entidades SNMP deberá permitir la consulta de contadores estadísticos cumpliendo con la RFC 1213 y RFC f) SNTP, deberá implementar Simple Network Time Protocol (SNTP, RFC 1361) o Network Time Protocol (Versión 3) RFC