Anexo I - Especificaciones Técnicas de la Red de Acceso Multiservicio MPLS/IP

Transcripción

1 Anexo I - Especificaciones Técnicas de la Red de Acceso Multiservicio MPLS/IP Proyecto Red IP/MPLS ARSAT SA Página 1 de 69

2 ÍNDICE Contenido 1. OBJETIVO INTRODUCCIÓN ALCANCE METODOLOGÍA DE RESPUESTA DESCRIPCION DE LA SOLUCION TECNOLOGICA A COTIZAR ARQUITECTURA DE REFERENCIA SITIOS A CONECTAR DESCRIPCIÓN DE LA TOPOLOGÍA DE LA RED TOPOLOGÍA JERÁRQUICA DE RED NIVEL CORE NIVEL DE AGREGACIÓN/DISTRIBUCIÓN NIVEL DE ACCESO CARACTERISTICAS TECNICAS Y PRESTACIONES REQUERIDAS CARACTERÍSTICAS TÉCNICAS CARACTERÍSTICAS GENERALES DEL EQUIPAMIENTO CAPACIDAD DE CONMUTACIÓN DISPONIBILIDAD Y REDUNDANCIA INTERFACES ETHERNET CAPA FÍSICA (NIVEL 1 OSI) PROTOCOLO DE NIVEL ATM CAPA FÍSICA (NIVEL 1 OSI) PROTOCOLO DE NIVEL SDH CANALIZADAS CAPA FÍSICA (NIVEL 1 OSI) PROTOCOLO DE NIVEL E1/T CAPA FÍSICA (NIVEL 1 OSI) PROTOCOLO DE NIVEL ROUTING PROTOCOLOS DE RUTEO REQUERIDOS Proyecto Red IP/MPLS ARSAT SA Página 2 de 69

3 POLICY ROUTING FUNCIONALIDADES POLICY ROUTING PERFORMANCE EN IPV PROTOCOLO IPV PERFORMANCE EN IPV OTRAS FUNCIONALIDADES DE ROUTING MPLS (MULTI PROTOCOL LABEL SWITCHING) FUNCIONALIDADES ACCESS LIST VPN-MPLS GESTIÓN DE VPN MPLS CLASE DE SERVICIO Y CALIDAD DE SERVICIO DIFFSERV DIFFSERV MPLS DIFFSERV-AWARE MPLS TRAFFIC ENGINEERING MÉTODOS DE CLASIFICACIÓN ALTA DISPONIBILIDAD TRAFFIC ENGINEERING TRAFFIC ENGINEERING FAST RE ROUTE (TE-FRR) PWE3 (PSEUDO-WIRE EMULATION EDGE-TO-EDGE) VPLS PATH MTU DISCOVERY VIRTUAL ROUTER REDUNDANCY PROTOCOL (VRRP) TUNNELING Y ENCRIPCIÓN DE DATOS MEDIANTE IPSEC ROUTER VIRTUAL TUNNELING SINCRONISMO FUENTES DE SINCRONISMO OPERACION Y MANTENIMIENTO MEF ELMI (ETHERNET LOCAL MANAGEMENT INTERFACE) IEEE 802.3AH OAM IEEE 802.1AG (ETHERNET CONNECTIVITY FAULT MANAGEMENT) ITU Y.1731 (PERFORMANCE FAULT MANAGMENT) INTEROPERABILIDAD DE OAM CAPACIDADES DE GESTIÓN PROVISTAS POR EL ELEMENTO DE RED Proyecto Red IP/MPLS ARSAT SA Página 3 de 69

4 INTERFACES GESTION FUNCIONALIDADES ASOCIACIÓN ENTRE FUNCIONALIDADES E INTERFACE FALLAS CONFIGURACIÓN PERFORMANCE CONTABILIZACIÓN (ACCOUNTING) SEGURIDAD INVENTARIO DE ELEMENTOS ADMINISTRACIÓN DE SOFTWARE REGISTROS (LOGS) COPIA DE RESPALDO (BACKUP) / RESTAURACIÓN (RESTORE) ROADMAP GESTIÓN ROADMAP EQUIPAMIENTO VALORES MINIMOS DE FUNCIONALIDADES BÁSICAS POR TIPO DE NODO ACCESO [O] OBJETO REQUERIDO TOPOLOGIA DE REFERENCIA DESCRIPCION TECNICA DEL OBJETO REQUERIDO NODO DE ACCESO TIPO 1 - AN REQUERIMIENTOS DE HARDWARE REQUERIMIENTOS DE SOFTWARE NODO DE ACCESO TIPO 2 - AN REQUERIMIENTOS DE HARDWARE REQUERIMIENTOS DE SOFTWARE CANTIDAD DE EQUIPOS TRAMO TRAMO TRAMO MAQUETA TOPOLOGIA Y SITIOS DE DESPLIEGUE SUMINISTRO Y SERVICIOS ALCANCE DEL SUMINISTRO DOCUMENTACION EJECUTIVA CRONOGRAMA DE EJECUCION DE TRABAJOS PROYECTO TÉCNICO DE LA PRESENTACIÓN Proyecto Red IP/MPLS ARSAT SA Página 4 de 69

5 12. CURSOS DE CAPACITACIÓN PRUEBAS DE CALIFICACION PRUEBAS DE HOMOLOGACION Y STRESS PRUEBAS FUNCIONALES Y DE INTEROPERABILIDAD PRUEBAS DE STRESS GARANTIA DE DISEÑO Proyecto Red IP/MPLS ARSAT SA Página 5 de 69

6 1. OBJETIVO El objetivo del presente documento es establecer las especificaciones técnicas para la provisión de equipos de acceso, software, mano de obra y accesorios para la puesta en marcha, operación, optimización de la red y asistencia técnica, permitiendo el desarrollo e implementación de la Red Federal de transporte de datos de alta capacidad basados en tecnología IP/MPLS 2. INTRODUCCIÓN Esta especificación forma parte del proyecto que reúne la planificación, estructuración y desarrollo de la obra Red Federal de Fibra Óptica de Telecomunicaciones, para integrar sistemas multiservicios de voz, datos y video en una misma red. Esta Red Multiservicio debe integrar, a través de enlaces de fibra óptica, a la totalidad de las localidades sobre la traza. Además, esto permitirá la interconexión de otros puntos y localidades vía vínculos alternativos compatibles con la red. De esta forma, se logra, extender sus servicios a Prestadores locales de Servicios de Telecomunicaciones y a Empresas de los estados provinciales y otros organismos públicos. La presente especificación da las pautas y características de los componentes a ofrecer para lograr la correcta prestación de los servicios solicitados. El oferente deberá presentar un esquema y una plataforma que debe responder los requerimientos del presente pliego respetando la arquitectura solicitada La Contratista deberá hacerse cargo de la confección de la documentación según lo determinado en este Documento. 3. ALCANCE El alcance de la obra incluye la realización del diseño, la ingeniería de detalle, la instalación y puesta en condiciones de funcionamiento de la red, asistencia técnica, provisión de los equipos activos, pasivos y sus repuestos, y otras acciones complementarias como la capacitación integral del personal técnico de ARSAT. Además, incluye la provisión de una herramienta de gestión y monitoreo a instalarse en el nodo principal de la red y las tareas de prueba de toda la infraestructura montada, de acuerdo a las especificaciones indicadas en el presente documento. El oferente, deberá contemplar la topología inicial que se presenta, teniendo en cuenta que el equipamiento, software y servicios ofertados deberá ser escalable, flexible, para soportar futuros crecimientos de tráfico y nuevos servicios. El sistema deberá ser capaz de soportar múltiples servicios con flexibilidad de crecimiento según la demanda por sitio o región y con el mínimo impacto a nivel de ingeniería para las necesidades actuales y futuras. La Red Multiservicio deberá ser apta para transportar voz, datos y video sobre una plataforma de MPLS, para incorporar señales de TV y telefonía celular, servicios Proyecto Red IP/MPLS ARSAT SA Página 6 de 69

7 punto a punto, punto a multipunto, multipunto a multipunto, tanto layer 2 como layer 3 (IPv4 e IPv6), triple play, desde el inicio. Este sistema será concebido para integrar redes de larga distancia para prestación de servicios de Internet, redes privadas virtuales (VPNs), emulación de circuitos punto a punto, punto multipunto, anillos o redes malladas basada en una red de alta capacidad, con facilidades de extracción e inserción de tráfico en los nodos primarios, secundarios y subtendido definidos en la red, y respectivas plataformas de soporte, tales como servicios de traslación de nombres y direcciones (DNS), autenticación, registros de auditoria, así como los sistemas de gestión de equipos, formación, garantía, puesta en servicio, apoyo y asistencia técnica. El sistema propuesto deberá ser flexible y reconfigurable para adaptarse a las necesidades actuales y futuras, y que simplifique las operaciones de red tanto en el despliegue, activación del servicio, adición de servicios, agregación, reconfiguración y mantenimiento. 4. METODOLOGÍA DE RESPUESTA. Se deberá responder a cada punto mediante la indicación cumple ó no cumple. Dichas respuestas deben ser justificadas fehacientemente y con documentación adicional que aporte a la respuesta. Se deberá responder en cada punto para cada versión de equipamiento ofertada (aclarando explícitamente a cual se refiere). En los casos de funcionalidades (features) disponibles a futuro, se deberá aclarar explícitamente la versión y la fecha en que dicha funcionalidad estará disponible. Al responder el punto a punto, se deberá evitar el uso de expresiones tales como toma conocimiento o toma nota u otras que den lugar a interpretaciones erróneas, y por lo tanto, estas serán interpretadas como No Cumple. Los puntos indicados con [O], son de cumplimiento obligatorio. 5. DESCRIPCION DE LA SOLUCION TECNOLOGICA A COTIZAR A continuación se detallan las principales características y datos relevantes de la solución tecnológica a cotizar, bajo las condiciones y especificaciones técnicas que se describen en el presente documento. La tecnología a implementar, debe brindar una arquitectura MPLS homogénea. Es decir que, desde cualquier nodo de acceso (AN) a cualquier otro, atravesando el backbone de la red, se debe tener tecnología MPLS. Esta Red Multiservicio constituye la Red Federal de Fibra Óptica de telecomunicaciones y el alcance de este concurso, corresponde a los denominadas tramos I, II y III. En cada tramo, se definen tres tipos de nodos en donde se deberá proveer el equipamiento necesario dependiendo de su funcionalidad en la red: Proyecto Red IP/MPLS ARSAT SA Página 7 de 69

8 Nodo Primario: es el que alojará equipamiento para cumplir el rol P y PE de la red. Nodo Secundario: es el que alojará equipamiento con rol PE y AN. Nodo Subtendido: es el que alojará equipamiento para cumplir el rol AN de la red Arquitectura de Referencia En la figura 1, se muestra un esquema genérico de los roles de red objeto del presente requerimiento. Los mismos deberán tomarse como referencia, en los casos que sea necesario, para la presentación de la oferta. Para ver el detalle de la cantidad de sitios y equipamiento involucrado, consultar la lista de sitios a servir por tramos, en Anexo II del PET Lista de sitios a servir por tramos. Figura 1 La ubicación de los nodos primario, secundario y subtendido, corresponde con localidades que se encuentran sobre la traza, o próxima a esta, la vinculación entre nodos primarios, y entre nodo primario y nodo secundario, se realiza por un par de fibra. Sobre este par de fibra se obtienen enlaces indicados como servicio/lambda a partir de una plataforma DWDM (fibra coloreada). La vinculación de nodo secundario con nodo de subtendido, y entre nodos de subtendido, se lleva a cabo por medio de un segundo par de fibra, sin el soporte de una plataforma DWDM (fibra oscura). Toda este conjunto estará instalado sobre la misma traza y ducto físico. Proyecto Red IP/MPLS ARSAT SA Página 8 de 69

9 5.2. Sitios a Conectar El tramo I es el conformado por la fibra óptica que recorre el centro del país de este a oeste, teniendo inicio en la localidad de Abasto, provincia de Buenos Aires, y final en la localidad de San Rafael, provincia de Mendoza. Las localidades a servir en este tramo se encuentran en el Anexo II del PET- Lista de Sitios a Servir por Tramos. El tramo II es el conformado por la fibra óptica que recorre el centro del país de Centro a Norte, teniendo inicio en la localidad de Benavidez, provincia de Buenos Aires, y final en la localidad de Resistencia, provincia de Chaco. Las localidades a servir en este tramo se encuentra en el Anexo II del PET- Lista de Sitios a Servir por Tramos. El tramo III es el conformado por la fibra óptica que recorre el sur del país, teniendo inicio en la localidad de Rio Gallegos, provincia de Santa Cruz, y final en la localidad de Ushuaia, provincia de Tierra del Fuego. Las localidades a servir en este tramo se encuentran en el Anexo II del PET- Lista de Sitios a Servir por Tramos. La red debe integrar, a través de enlaces de fibra óptica, a la totalidad de las localidades dentro de la traza, permitiendo a futuro también la vinculación, vía enlaces compatibles alternativos, de otros puntos y localidades, pudiendo así y en conjunto, extender sus servicios a prestadores locales de servicios de telecomunicaciones y a Empresas del Estado Provincial y otros Organismos Públicos. Existen previsiones de ampliación de dicha Red a otros lugares y localidades, en el ámbito provincial, mediante etapas complementarias de este proyecto y que formarán parte de otros procesos licitatorios o concursales. Además, prevé conectarse con sistemas nacionales e internacionales de telecomunicaciones. Aquí se describen las características mínimas que debe cumplir la solución tecnológica a ofertar. Se propone un esquema y una plataforma que debe servir de base a la presentación de Ofertas del presente Concurso. Particularmente, la red a proveer estará compuesta por Nodos Primarios sobre una plataforma de routing MPLS, enlazados formando una malla con vínculos de distinta capacidad, y Nodos Secundarios, con idéntica plataforma MPLS, enlazados, en la mayoría de los casos a dos nodos Primarios en 10 Gbps a cada uno. Ambos tipos de Nodos se encontrarán interconectados y trabajarán integralmente sobre la misma red de fibra óptica. Complementariamente, los nodos de acceso (AN) estarán integrados como Nodos de Subtendido, vinculados en topología bus entre dos Nodos Secundarios, en 10 Gbps, a través de la misma red de fibra óptica indicada, en otro par de hilos de fibra. La eficiencia de funcionamiento de la red integral será alcanzada por la mínima necesidad de personal requerido para administrar la totalidad del sistema, de forma centralizada. El soporte y mantenimiento de esta funcionalidad es parte integral de esta contratación, por lo que el Oferente deberá prever las necesidades de equipamiento y programas normalizados de administración y gestión de la red. La OBRA se entregará con todos los servicios funcionando que fueren necesarios. Proyecto Red IP/MPLS ARSAT SA Página 9 de 69

10 La Contratista deberá hacerse cargo de la realización de la documentación ejecutiva según lo determinado en este documento Descripción de la Topología de la Red La red será implementada en redes malladas ópticas distribuidas en regiones. Cada región formará una red mallada compuesta por anillos ópticos, de tal manera que asegure máxima redundancia de conexión. Actualmente se implementarán los tres tramos especificados anteriormente, que formarán parte de dicha red. Es importante notar que la solución está concebida por regiones, tanto desde el punto de vista de tráfico, de implementación, protección y segurización. Dada la vasta extensión de la red, el equipamiento ofrecido deberá poder interoperar con redes construidas con equipos de otros fabricantes, el oferente deberá indicar las opciones de acoplamiento entre redes y garantizar su funcionalidad. [O] Topología Jerárquica de Red La red, basada en tecnología DWDM, cuenta con dos pares de pelos de FO en una red mallada. Para la red Core se utilizará un par de pelos de fibra óptica que vincularán los nodos Primarios y Secundarios. Se utilizará el segundo par de pelos de fibra óptica para vincular los nodos del subtendido de la red para la agregación de tráfico que actuará como tributario del backbone de la red. La topología de la totalidad de la red, presenta un esquema jerárquico con tres niveles A continuación se presenta un esquema: Fig 2: Topología Jerárquica. Proyecto Red IP/MPLS ARSAT SA Página 10 de 69

11 Nivel Core Se define así al nivel de transporte de largo alcance (LA), conformado por los Nodos definidos como primarios y que actuarán como concentradores de tráfico donde tributará todo el tráfico con destino Nacional e Internacional. Estos nodos además tendrán la funcionalidad de distribuir el tráfico regional. El equipamiento a instalar en un nodo primario estará preparado para cursar el siguiente tipo de tráfico. 1. Tráfico con otros nodos del Core. 2. Colectar tráfico Local y regional 3. Colectar y distribuir tráfico de los nodos secundarios y sub-nodos. El nodo primario Benavidez, tendrá adicionalmente la gestión del tráfico internacional Nivel de Agregación/Distribución Está conformado en los Nodos Primarios, por medio del equipamiento de rol PE. El equipamiento deberá cursar el siguiente tipo de tráfico. 1. Tráfico con equipamiento con rol P. 2. Tráfico con nodos de subtendido, a través de nodos secundarios. 3. Colectar y distribuir tráfico con el nivel de acceso. La capa de agregación estará compuesta por equipos PE de alta capacidad localizados en las grandes áreas metropolitanas o a través de las redes interprovinciales Nivel de Acceso Está conformado por el equipamiento con rol AN, ubicados en los nodos de subtendido Un nodo de subtendido estará preparado para cursar el siguiente tipo de tráfico. 1. Tráfico con nodos secundarios (Agregación/Distribución de tráfico). 2. Colectar tráfico Local. 3. Tráfico con otros nodos de subtendido. Dado que lo vínculos entre nodos primarios y entre nodos primarios con nodos secundarios se realiza por medio de tecnología DWDM, las interfaces ópticas y sus respectivos patchcords ópticos del equipamiento se deberán proveer. Para la vinculación de los nodos del subtendido, se deberá prever que las interfaces ópticas del equipamiento soporten la distancia entre los mismos. Estas distancias se encuentran en el Anexo II del PET- Lista de sitios a servir por tramos. Proyecto Red IP/MPLS ARSAT SA Página 11 de 69

12 6. CARACTERISTICAS TECNICAS Y PRESTACIONES REQUERIDAS 6.1. Características Técnicas a. La nueva red estará soportada en su totalidad bajo el protocolo TCP/IP donde los equipos será de naturaleza MPLS/IP [O]. Seguidamente se detallan características generales que deberán los equipos de Acceso. b. Se deberá presentar un esquema general detallando los bloques componentes del equipo AN propuesto (procesador, matriz de conmutación, bus, placa de línea, etc.), indicando la funcionalidad específica de cada uno de los mismos y su interrelación. [O] Características Generales del Equipamiento Las características detalladas a continuación son de cumplimiento para todo el equipamiento solicitado. a. Especificar el modelo de cada uno de los equipos propuestos para el equipamiento rol AN.[O] b. Se deberá especificar y detallar si el equipo se basa en procesamiento centralizado (placas específicas para procesar el tráfico) o en procesamiento distribuido (procesamiento en las placas de interfaz). [O] c. El oferente deberá presentar un diagrama general indicando las dimensiones mecánicas de los equipos [O]. d. En la solución presentada el oferente deberá indicar detalladamente la versión y reléase de software del equipo como así también de cada uno de los módulos que lo integren. [O] e. El oferente deberá indicar la posición en el equipo/bastidor de cada bloque de funcionamiento; tarjeta sub-bastidor, etc.[o] f. El oferente deberá presentar las planillas de cálculo de consumo eléctrico y disipación térmica para cada uno de los equipos presentados de acuerdo a la configuración de hardware. [O] g. El oferente deberá indicar el consumo eléctrico y disipación térmica máxima para cada uno de los equipos presentados. [O] h. El oferente deberá describir adicionalmente las opciones de alimentación soportadas por los equipos, incluyendo sus respectivas tolerancias [O] i. Se requiere que los equipos AN presentados soporten alimentación de corriente continua de 48 volts, y se deberá indicar las tolerancia mínimas y máximas. En el Anexo II del PET - Lista de sitios a servir por tramos, se encuentra indicado el tipo de alimentación utilizado en cada sitio. En los que se indica 220v el equipo será de 48V pero se deberá proveer de un conjunto rectificador-baterías de tal manera de adaptar los 220VCA a 48VCC, con las Proyecto Red IP/MPLS ARSAT SA Página 12 de 69

13 autonomías en caso de falla de la fuente de alimentación especificado en el anexo antes mencionado. [O] j. El oferente deberá describir adicionalmente las opciones de alimentación soportadas por los equipos, incluyendo sus respectivas tolerancias [O] k. El oferente deberá detallar las condiciones ambientales de operación de cada equipo presentado [O]. l. El oferente deberá indicar las características de temperatura, humedad y estándares internacionales a los que responde. [O] Capacidad de Conmutación El oferente deberá describir detalladamente la capacidad de conmutación del equipo y de cada uno de los bloques que lo integre en bit/s (indicando el tamaño del paquete considerado) y pps (paquetes por segundos), la respuesta presentada debe habilitar la identificación de las distintas configuraciones del equipo y la capacidad de carga sin llegar al estado de congestión [O]. Incluir: a. Tipo de procesamiento (centralizado o distribuido) b. Capacidad de matriz de conmutación [Gbps] c. Capacidad de backplane, [Gbps] d. Capacidad de conmutación por slot, [Gbps] e. Capacidad de forwarding por chassis [Mpps] f. Capacidad de forwarding por slot, [Mpps] g. Cantidad máxima de puertos de 1 Gbps operando a velocidad de linea, full duplex, con encapsulado ethernet. Adicionalmente, indicar la misma cantidad asumiento un rendimiento de cada puerto dado por datagramas IP de 64 bytes con headers ethernet, 802.1q, y 1 label MPLS h. Cantidad máxima de puertos de 10 Gbps operando a velocidad de linea, full duplex, con encapsulado ethernet. Adicionalmente, indicar la misma cantidad asumiento un rendimiento de cada puerto dado por datagramas IP de 64 bytes con headers ethernet, 802.1q, y 1 label MPLS i. Cantidad máxima de puertos de 40 Gbps operando a velocidad de linea, full duplex, con encapsulado ethernet. Adicionalmente, indicar la misma cantidad asumiento un rendimiento de cada puerto dado por datagramas IP de 64 bytes con headers ethernet, 802.1q, y 1 label MPLS j. Cantidad máxima de puertos de 100 Gbps operando a velocidad de linea, full duplex, con encapsulado Ethernet. Adicionalmente, indicar la misma cantidad asumiento un rendimiento de cada puerto dado por datagramas IP de 64 bytes y 1 label MPLS k. Los valores de performance expresados deberán ser validos independientemente de las funcionalidades implementadas. El oferente deberá indicar los puntos de congestión del equipo para cada uno de los bloques que lo integren. Proyecto Red IP/MPLS ARSAT SA Página 13 de 69

14 Disponibilidad y Redundancia a. El oferente deberá indicar el MTBF del equipo y de cada uno de los componentes presentados. [O] b. El oferente deberá especificar la posibilidad de redundancia de cada uno de los bloques descriptos. [O] c. El oferente deberá indicar el proceso llevado a cabo en el equipo al fallar cada uno de los distintos módulos que poseen redundancia. [O] d. El oferente deberá indicar para el punto c el impacto en los servicios prestados por el equipo. [O] e. El oferente deberá indicar para el punto c si existen módulos que deben ser reinicializados, en caso afirmativo deberá detallar esos módulos. [O] f. El oferente deberá indicar, en caso de re inicialización de módulos o corte de servicio, para distintas condiciones (tráfico, configuración, hardware, etc.) los tiempos típicos de restablecimiento del servicio. [O] g. La plataforma deberá soportar la inserción y remoción en servicio (hotswap) de los módulos de interfaces de línea, procesador central, fuentes de alimentación, matriz de conmutación, o de cualquier modulo removible, sin pérdida de paquetes ni disrupción del servicio. Detallar funcionamiento.[o] Proyecto Red IP/MPLS ARSAT SA Página 14 de 69

15 6.2. Interfaces Para cada tipo de interfaz y modelo de equipo propuesto según aplique y se indique, se requiere responder punto a punto [O]: a. El soporte de las interfaces requeridas. b. El soporte de la cantidad mínima indicada de interfaces requeridas. c. La cantidad máxima de interfaces soportadas por el equipo. d. La cantidad máxima de VLANs (C-VLAN) activas que soporta cada una de las interfaces. e. la cantidad máxima de VLANs (S-VLAN) activas que soporta cada una de las interfaces f. La cantidad máxima de VLANs (C-VLAN) activas en combinación con S-VLAN activas que soporta cada una de las interfaces. g. La cantidad máxima de direcciones MAC soportadas por interfaz/ slot. Detallar que ocurre con el tráfico cursado cuando las mismas alcanzan sus valores máximos h. La cantidad máxima de entradas ARP soportadas por interfaz, slot, chasis. Si se asume que cada entrada de la tabla de ARP es una dirección MAC, este valor debería coincidir con lo indicado en g i. Valor máximo de MTU configurable j. El oferente deberá especificar la modularidad para cada una de las interfaces requeridas. k. El oferente deberá especificar la capacidad nominal con respecto al throughput máximo de cada una de las interfaces requeridas en función de paquetes de 64, 128, 256, 512, 1024 y 1500 bytes, en el caso de ser inferior a la interfaz en cuestión deberá detallar dicha limitación. l. El oferente deberá especificar la capacidad nominal con respecto al procesamiento de paquetes máximo de cada una de las interfaces en pps (paquetes por segundo). m. El oferente deberá indicar el impacto en la performance en el caso de aplicar en forma simultánea los servicios. En el caso que se especifique algún tipo de impacto, el mismo deberá detallarse describiendo dicha limitación. n. El impacto en la performance del equipo equipado completamente con cada una de las interfaces requeridas con distintos umbrales de carga, ej. 50%, 80% y 99%. o. El oferente deberá indicar sobre la interoperabilidad de cada una de las interfaces con la de otros fabricantes, incluyendo de equipamiento de transporte. Proyecto Red IP/MPLS ARSAT SA Página 15 de 69

16 ETHERNET Capa Física (Nivel 1 OSI) El oferente deberá responder punto a punto para cada una de las interfaces mencionadas, lo solicitado en el punto 6.2.Se indican con [O] las interfaces que son de soporte obligatorio. a. Fastethernet (de acuerdo a 802.3u). Capacidad de 100 Mbps operando en modo full dúplex con frame Ethernet y VLANs (802.1q ). Con soporte óptico y eléctrico.[o] b. Gigabit Ethernet óptica (de acuerdo a IEEE 802.3z). Capacidad : 1 Gbps operando en modo full dúplex con frame Ethernet y VLANs (802.1q ) [O] c. 10Gigabit Ethernet óptica (de acuerdo a IEEE 802.3ae). Capacidad: 10 Gbps operando en modo full dúplex con frame Ethernet y VLAN (802.1q ). [O] d. 40Gigabit Ethernet (de acuerdo al avance de 802.3ba ). Capacidad: 40 Gbps operando en modo full dúplex con frame Ethernet y VLAN (802.1q ). e. 100Gigabit Ethernet óptica (de acuerdo a IEEE 802.3ba). Capacidad: 100 Gbps operando en modo full dúplex con frame Ethernet y VLAN (802.1q ). f. Indicar otros tipos de interfaces Ethernet soportadas. [O] Protocolo de Nivel 2 El oferente deberá responder punto a punto el soporte de: a. Link aggregation según 802.1ad [O]. i. Indicar los tipos de LAG soportados por el equipo (manual, estático y/o dinámico). Detallar el funcionamiento de cada uno de los tipos soportados. ii. Indicar la cantidad de interfaces que pueden conformar un grupo Link Aggregation y dónde radica la limitación. iii. Indicar si es posible agrupar interfaces de distintas tarjetas. De ser posible indicar la cantidad de máxima de interfaces que se pueden agrupar y cuantas tarjetas pueden utilizarse para realizar dicha tarea. iv. Indicar que funcionalidad mencionada en ésta especificación no es soportada en un grupo Link Aggregation. v. Indicar en qué parámetro/s se basa el algoritmo de balanceo del equipo (source MAC, destination MAC, source IP, destination IP o combinatorias). Especificar si el equipo permite cambiar el/los parámetros mediante configuración. Proyecto Red IP/MPLS ARSAT SA Página 16 de 69

17 b. Link aggregation según 802.1AX. c. Multi Chasis Link Aggregation. i. Indicar los tipos de LAG soportados por el equipo (manual, estático y/o dinámico). Detallar el funcionamiento de cada uno de los tipos soportados. ii. iii. iv. Indicar la cantidad de interfaces que pueden conformar un grupo Link Aggregation y dónde radica la limitación. Indicar si es posible agrupar interfaces de distintas tarjetas. De ser posible indicar la cantidad de máxima de interfaces que se pueden agrupar y cuantas tarjetas pueden utilizarse para realizar dicha tarea. Indicar que funcionalidad mencionada en ésta especificación no es soportada en un grupo Link Aggregation. v. Indicar en qué parámetro/s se basa el algoritmo de balanceo del equipo (source MAC, destination MAC, source IP, destination IP o combinatorias). Especificar si el equipo permite cambiar el/los parámetros mediante configuración. d. Funcionalidad de VLAN Translation (cambio del valor de VLAN ID de la trama cuando el equipo hace el forwarding de una interfaz a otra). [O]. e. Jumbo Frames (MTU hasta 8000 Bytes). Indicar el valor máximo configurable. [O]. f. Suprimir el aprendizaje de MAC address sobre un puerto físico y en una VLAN. Si para realizar dicha función emplea un protocolo (es decir realiza la funcionalidad de manera dinámica), especificar el mismo. [O]. g. El equipo debe poder configurar y operar en simultáneo sobre todas las interfaces físicas el total de las 4094 VLANs. Debe poder segregar los dominios de capa 2 sobre cada una de las interfaces físicas. De existir alguna limitación, indicar dónde radica la limitación y el porqué. [O]. Proyecto Red IP/MPLS ARSAT SA Página 17 de 69

18 ATM Capa Física (Nivel 1 OSI) El oferente deberá responder punto a punto para cada una de las interfaces mencionadas, lo solicitado en el punto a. E3 eléctrica (de acuerdo a: ITU-T G.703 y G.804) b. STM-1 S nm óptica y eléctrica (de acuerdo a: ITU-T G.957, ITU-T G.783/G.958, ITU-T G.825 y ITU-T G.707). [O] Protocolo de Nivel 2 El oferente deberá responder punto a punto el soporte de: a. ATM UNI 3.1 y 4.0, de acuerdo a: ATM Forum Proyecto Red IP/MPLS ARSAT SA Página 18 de 69

19 SDH Canalizadas Capa Física (Nivel 1 OSI) El oferente deberá responder punto a punto para cada una de las interfaces mencionadas lo solicitado en el punto , el soporte de a. E1 CH eléctrica (de acuerdo a: ITU-T G.703) b. E3 CH eléctrica (de acuerdo a: ITU-T G.703, ITU-T 6.704) c. STM-1 CH óptica y eléctrica, canalizada en DS0, E1 y E3 (de acuerdo a: ITU-T G.957, ITU-T G.783/G.958, ITU-T G.825, ITU-T G.703, ITU-T G.704 y ITU-T G.707) [O] d. STM-4 CH óptica,, canalizada en DS0, E1 y E3 (de acuerdo a: ITU-T G.957, ITU- T G.783/G.958, ITU-T G.825, ITU-T G.703, ITU-T G.704 y ITU-T G.707) Protocolo de Nivel 2 El oferente deberá responder punto a punto el soporte de : a. PPP (Point to Point Protocol) de acuerdo a: RFC 1661 b. PPP in HDLC Framing, de acuerdo a: RFC 1662 c. HDLC Standard d. Compatibilidad con Cisco-HDLC e. Frame Relay f. Multilink PPP g. Multilink Frame Relay E1/T Capa Física (Nivel 1 OSI) El oferente deberá responder punto a punto el soporte de : a. E1 (G.703), especificar: i. Tipo de interface ii. Tipo de codificación b. T1 (ANSI T1.403), especificar: i. Tipo de interface ii. Tipo de codificación Protocolo de Nivel 2 El oferente deberá responder punto a punto el soporte de: a. PPP (Point to Point Protocol) de acuerdo a: RFC 1661 b. PPP in HDLC Framing, de acuerdo a: RFC 1662 c. HDLC Standard Proyecto Red IP/MPLS ARSAT SA Página 19 de 69

20 d. Frame Relay e. Multilink PPP f. Multilink Frame Relay 6.3. Routing En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. En el caso de las normas que se hayan publicado en el IETF en carácter de RFC dentro de los veinticuatro meses inmediatos anteriores a la fecha de publicación del presente concurso, y que el proveedor no la haya implementado aún, se deberá indicar expresamente la fecha de cumplimiento prevista en su roadmap y el tipo de compromiso asumido en el mismo. El oferente deberá responder para cada uno de los protocolos y funcionalidades requeridas los siguientes puntos: a. El soporte del protocolo de ruteo y funcionalidad. b. Una descripción detallada de la implementación para cada protocolo de ruteo y funcionalidad. c. El impacto en la performance del equipo para cada protocolo de ruteo y funcionalidad soportada como así también en la combinación de los mismos, en función de: CPU, memoria, otros recursos. Especificar i. Recursos mínimos de memória requeridos para utilizar cada protocolo. d. Recursos mínimos de uso del Procesador utilizados por cada protocolo e. Indicar la versión y release de software para cada una de los protocolos de ruteo y funcionalidades soportadas, en el caso que dicho protocolo y/o funcionalidad se implemente en versiones futuras (en roadmap) indicar la versión y su fecha comprometida de implementación. f. Especificar la relación entre el hardware y dicha funcionalidad / protocolo de ruteo, o sea, detallar si está soportada independientemente del hardware implementado (interfaces, procesador, etc.). g. Indicar si el equipo requiere hardware adicional (placa o modulo específico) para la implementación de dicha funcionalidad / protocolo de ruteo, en este caso describir detalladamente el hardware y software necesario. Proyecto Red IP/MPLS ARSAT SA Página 20 de 69

21 h. Cantidad máxima de rutas soportadas para cada protocolo de ruteo i. La cantidad de memoria utilizada en el procesador para el punto anterior. j. Cantidad máxima de instancias de ruteo soportadas en cada protocolo k. Una descripción detallada que explique las razones de los límites indicados o la no aplicación de la funcionalidad al rol del equipamiento en la topología de red a implementar Protocolos de Ruteo Requeridos a. Rutas Estáticas para IPv4 [O] b. Rutas estáticas para IPv6 [O] c. RIPv2 (Routing Information Protocol versión 2), de acuerdo a: RFC 2453[O]. Indicar el soporte de las siguientes funcionalidades: i. Autenticación MD5 (RFC 2082) ii. Autenticación Criptográfica (RFC 4822) iii. Triggered extensions (RFC 2091) iv. RIP for IPv6 (RIPng)(RFC 2080) d. BGP (Border Gateway Protocol), EBGP (Exterior Border Gateway Protocol), IBGP (Interior Border Gateway Protocol), MP-BGP (Multiprotocol Border Gateway Protocol), de acuerdo a las siguientes RFC / drafts y funcionalidades: i. RFC 3107 Carrying label information in BGP-4 [O] ii. RFC 1700 Assigned Numbers iii. RFC 3232 Assigned Numbers iv. RFC 4271 A Border Gateway Protocol 4 (BGP-4) [O] v. RFC 1772 Application of the Border Gateway Protocol in the Internet [O] vi. RFC 1997 BGP Communities Attribute [O] vii. RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option viii. RFC 2439 BGP Route Flap Damping [O] ix. RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing x. RFC 4760 Multiprotocol Extensions for BGP-4 xi. RFC 2918 Route Refresh Capability for BGP-4 xii. RFC 5065 Autonomous System Confederations for BGP [O] xiii. RFC 5492 Capabilities Advertisement with BGP-4 xiv. RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 xv. RFC 4360 BGP Extended Communities Attribute [O] xvi. RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)[O] xvii. RFC 4724 Graceful Restart Mechanism for BGP [O] Proyecto Red IP/MPLS ARSAT SA Página 21 de 69

22 xviii. RFC 4781 Graceful Restart Mechanism for BGP with MPLS xix. RFC 4893 BGP Support for 4-byte ASN.[O] xx. Draft-rtgwg-bgp-pic-00 BGP Prefix Independent Convergence e. OSPF (Open Shortest path First)[O], de acuerdo a las siguientes RFC / drafts y funcionalidades: i. RFC 1370 Applicability Statement for OSPF ii. iii. iv. RFC 2328 OSPF Version 2 [O] RFC 2370 The OSPF Opaque LSA Option RFC 5340 OSPF for IPv6 (OSPF v3) [O] v. RFC 3137 OSPF Stub Router Advertisement vi. vii. RFC 3509 Alternative Implementations of OSPF Area Border Routers RFC 3623 Graceful OSPF Restart [O] viii. RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. ix. RFC 5082 The Generalized TTL Security Mechanism (GTSM) x. RFC 3906 Calculating Interior Gateway Protocol (IGP) Routes OverTraffic xi. xii. Engineering Tunnels RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS RFC 4136 OSPF Refresh and Flooding Reduction in Stable Topologies xiii. RFC 4203 Label Switching (GMPLS) OSPF Extensions in Support of Generalized Multi-Protocol xiv. RFC 6001 Generalized MPLS (GMPLS) Protocol Extension for Multi-Layer xv. and Multi-Region Networks (MLN/MRN) RFC 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions xvi. RFC 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi- Protocol Label Switching (GMPLS) Traffic Engineering (TE) xvii. RFC 6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths xviii. RFC 4552 Authentication/Confidentiality for OSPFv3 [O] xix. RFC 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) own bit Extension for L3VPN xx. RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS xxi. RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)[O] xxii. RFC 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) Proyecto Red IP/MPLS ARSAT SA Página 22 de 69

23 xxiii. RFC Multiprotocol Label Switching (MPLS) Label Stack Entry "EXP" Field Renamed to "Traffic Class" Field [O] xxiv. RFC 4750 OSPF Version 2 Management Information Base xxv. RFC 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization xxvi. RFC 4812 OSPF Restart Signaling xxvii. RFC 4813 OSPF Link-Local Signaling xxviii. RFC 4970 Extensions to OSPF for Advertising Optional Router Capabilities xxix. RFC 5088 OSPF protocol extensions for Path Computation Element xxx. RFC 5185 OSPF Multi-Area Adjacency [O] Indicar: 1. Cantidad máxima de adyacencias [O] 2. Cantidad máxima de entradas en DBase [O] xxxi. RFC 5187 OSPFv3 Graceful Restart [O] xxxii. RFC 5329 Traffic Engineering Extensions to OSPF Version 3 xxxiii. RFC 5340 OSPF for IPv6 (OSPF v3) Indicar: 1. Cantidad máxima de adyacencias [O] 2. Cantidad máxima de entradas en LSDB [O] xxxiv. RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates[O] f. IS-IS (Intermediate System to Intermediate System) [O], de acuerdo a: i. ISO ii. iii. iv. RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP v. RFC 4301 Security Architecture for the Internet Protocol vi. vii. viii. RFC 3260 New Terminology and Clarifications for Diffserv RFC 6040 Tunneling of Explicit Congestion Notification RFC 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS ix. RFC 5304 IS-IS Cryptographic Authentication x. RFC 6232 Purge Originator Identification TLV for IS-IS xi. xii. RFC 6233 IS-IS Registry Extension for Purges RFC 1142 OSI IS-IS Intra-domain Routing Protocol Proyecto Red IP/MPLS ARSAT SA Página 23 de 69

24 xiii. RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates. [O] g. Multicast Routing Protocol, de acuerdo a las siguientes RFC / drafts y funcionalidades: i. Protocol Independent Source Specific Multicast (PIM-SSM) a. RFC 4601 Protocol Independent Multicast - Sparse Mode (PIM- SM):Protocol Specification [O] b. RFC 5796 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) c. RFC 6226 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages ii. RFC 1112 Host extensions for IP multicasting (IGMP Version 1) iii. RFC 3376 Internet Group Management Protocol, Version 3 iv. RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2)for Source-Specific Multicast v. RFC 2236 Internet Group Management Protocol, Version 2 [O] vi. RFC 2710 Multicast Listener Discovery (MLD) for IPv6 vii. RFC 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol viii. RFC 3446 Anycast Rendevous Point (RP) mechanism using PIM and MSDP ix. RFC 3569 An Overview of Source-Specific Multicast (SSM) x. RFC 3618 Multicast Source Discovery Protocol (MSDP) xi. RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 xii. RFC 4607 Source-Specific Multicast for IP [O] xiii. RFC 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM) h. Multicast in MPLS/BGP IP VPNs (Se debera indicar la arquitectura e implementación recomendada por el oferente). a. RFC 4605 Internet Group Management Protocol (IGMP) /Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") b. RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast c. RFC 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements d. RFC 5501 Requirements for Multicast Support in Virtual Private LAN Services. e. RFC 5294 Host Threats to Protocol Independent Multicast (PIM). f. RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches Proyecto Red IP/MPLS ARSAT SA Página 24 de 69

25 g. IGMP report suppression.(especificar Implementacion) h. IGMP proxy. i. Mapeo de IGMPv2 a IGMPv3 j. Soporte de Multicast Inter- AS.(especificar Implementación) i. Performance y características en multicast, responder por cada punto: a. Performance de forwarding de paquetes multicast b. Impacto de la Replicación de los paquetes multicast en la performance del tráfico unicast,en especial en la latencia c. Indicar cantidad máxima de rutas IPv4 Multicast sobre la tabla global. Cada una asociada a una adyacencia de PIM establecida. d. Indicar si las funcionalidades anteriores, están basadas en software o hardware y el impacto de CPU. e. Indicar el máximo de rutas mcast para la MRIB, y el recomendado. f. Indicar escalabilidad desde el punto de vista de señalización, time-intervals y distribución de los tráficos multicast para las soluciones requeridas. g. Indicar la máxima tasa de Joins igmp concurrentes al chasis que puede soportarse. h. Indicar la máxima tasa de Joins igmp concurrentes a una interfaz que puede soportarse. i. Indicar otros protocolos soportados útiles/necesarios para la solución de los escenarios. j. Indicar si el equipo soporta access-list u otro mecanismo para filtro de grupos mcast. k. Indicar si el equipo soporta access-list u otro mecanismo para filtro de igmp joins Policy Routing La funcionalidad consiste en la capacidad del equipo para el soporte de ruteo por origen. Proyecto Red IP/MPLS ARSAT SA Página 25 de 69

26 Funcionalidades Policy Routing a. Describir detalladamente la implementación de esta funcionalidad b. Deberá soportar el ruteo en base a los siguientes orígenes : i. Dirección IP ii. Interfaz iii. Interfaz lógica (VLAN, PVC, sesión PDP) iv. Indicar el número máximo de instancias de Policy Routing que pueden ser implementadas simultáneamente Performance en IPv4 Para los siguientes puntos indicar: a. La cantidad máxima de entradas de tabla de forwarding IPv4. [O] b. La cantidad máxima de entradas de tablas de ruteo IPv4. [O] c. La cantidad máxima de interfaces de red IPv4 por chasis. [O] d. La cantidad máxima de interfaces de red IPv4 por placa. [O] e. Indicar la cantidad de interfaces IPv4 lógicas máximas por chasis, la máxima por slot y la máxima por puerto.[o] f. Indicar la cantidad de prefijos Ipv4 sobre la tabla global. [O] Protocolo IPv6 Se deberán soportar las facilidades relacionadas a IPv6 de acuerdo a las siguientes RFC / drafts y funcionalidades: a. RFC 2460 Internet Protocol, Version 6 (IPv6) Specification. [O] b. RFC 4291 IP Version 6 Addressing Architecture. [O] c. RFC 5952 A Recommendation for IPv6 Address Text Representation d. RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators e. RFC PE- IPv6 packets transported from PE to PE inside MPLS network. [O] f. RFC 4213-Basic Transition Mechanisms for IPv6 Hosts and Routers. [O] g. RFC 4861 Neighbor Discovery for IP Version 6 (IPv6). [O] h. RFC 4311 IPv6 Host-to-Router Load Sharing. i. RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes j. RFC 4862 IPv6 Stateless Address Autoconfiguration k. RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification l. RFC 4884 Extended ICMP to Support Multi-Part Messages m. RFC 2464 Transmission of IPv6 Packets over Ethernet Networks. [O] n. RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet o. RFC 5095 Deprecation of Type 0 Routing Headers in IPv6 Proyecto Red IP/MPLS ARSAT SA Página 26 de 69

27 p. RFC 5722 Handling of Overlapping IPv6 Fragments q. RFC 5871 IANA Allocation Guidelines for the IPv6 Routing Header r. RFC 6437 IPv6 Flow Label Specification s. RFC 6564 A Uniform Format for IPv6 Extension Headers t. RFC 3046 DHCP Relay Agent Information Option. u. RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) v. RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) w. RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) x. RFC 6221 Lightweight DHCPv6 Relay Agent y. RFC 6422 Relay-Supplied DHCP Options z. RFC 6642 Rebind Capability in DHCPv6 Reconfigure Messages aa. RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses. bb. RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address cc. RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses dd. RFC 3484 ó RFC 6724 Default Address Selection for Internet Protocol version 6. ee. RFC 3587 IPv6 Global Unicast Address Format ff. RFC 5643 Management Information Base for OSPFv3 gg. Posibilidad de establecer túneles (Ipv6 sobre Ipv4): Automatic 6to4 Tunnels y Manually Configured IPv6 over IPv4 Tunnel hh. Soporte de Access control list para IPv6. [O] ii. QoS (marcado/clasificación/encolado) según el modelo DIFFSERV [O]. jj. Multicast Address Family Support for Multiprotocol BGP para IPv6 kk. PIM Source-Specific Multicast (PIM-SSM) ll. PIM Sparse Mode (PIM-SM) mm. Static Multicast Routing (mroute) for IPv6 nn. RFC 1981 Path MTU Discovery for IP version 6 oo. RFC VPE (IPv6 packets transported from PE to PE inside VPN-MPLS network). [O] pp. RFC 2472 IP Version 6 over PPP. qq. RFC 5072 IP Version 6 over PPP rr. RFC 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol ss. En forma adicional a los puntos anteriores, indicar el soporte de Ipv6 para todas las funcionalidades de los equipos propuestos, en el caso que dicha funcionalidad se encuentre en roadmap indicar su fecha de disponibilidad comercial Performance en IPv6 El oferente deberá responder los siguientes puntos: a. La cantidad máxima de entradas de tabla de forwarding IPv6. Describir que factor impone el límite [O]. b. La cantidad máxima de entradas de tablas de ruteo IPv6. [O] c. La cantidad máxima de interfaces de red IPv6 por chasis. [O] Proyecto Red IP/MPLS ARSAT SA Página 27 de 69

28 d. La cantidad máxima de interfaces de red IPv6 por placa. [O] e. Cantidad máxima de prefijos VPNv6. [O] Otras Funcionalidades de routing Detallar funcionalidades adicionales que soporta la solución MPLS (MULTI PROTOCOL LABEL SWITCHING) El soporte de dicha funcionalidad es de carácter obligatorio [O] donde se indique, y su funcionamiento deberá estar en un todo de acuerdo con las normas establecidas por el IETF (según la lista de RFC & drafts siguientes) y el MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. En el caso de las normas que se hayan publicado en el IETF en carácter de RFC dentro de los veinticuatro meses inmediatos anteriores a la fecha de publicación del presente concurso, y que el proveedor no la haya implementado aún, se deberá indicar expresamente la fecha de cumplimiento prevista en su roadmap y el tipo de compromiso asumido en el mismo: i. RFC 2205 Resource Reservation Protocol Version 1 Functional Specification. ii. RFC 3936 Procedures for Modifying the Resource reservation Protocol (RSVP) iii. RFC 4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow iv. RFC 5946 Resource Reservation Protocol (RSVP) Extensions for Path- Triggered RSVP Receiver Proxy v. RFC 6437 IPv6 Flow Label Specification vi. RFC 2702 Requirements for Traffic Engineering Over MPLS, vii. RFC 3031 Multiprotocol Label Switching Architecture [O], viii. RFC 6178 Label Edge Router Forwarding of IPv4 Option Packets ix. RFC 3032 MPLS Label Stack Encoding.[O] x. RFC 3037 LDP Applicability xi. RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels xii. RFC 3936 Procedures for Modifying the Resource reservation Protocol (RSVP) xiii. RFC 4874 Exclude Routes - Extension to Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) xiv. RFC 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) xv. RFC 6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects xvi. RFC 5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages xvii. RFC 3213 Applicability Statement for CR-LDP xviii. RFC 3214 LSP Modification Using CR-LDP xix. RFC 3270 MPLS Support of Differentiated Services (E-LSP, L-LSP) xx. RFC 3443 Time To Live (TTL) Processing in MPLS Networks [O], xxi. RFC 3468 Decision on MPLS Signaling Protocols Proyecto Red IP/MPLS ARSAT SA Página 28 de 69

29 xxii. RFC 3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery xxiii. RFC 3471 Generalized Multi-Protocol Label Switching (GMPLS) xxiv. RFC 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control xxv. RFC 4872 RSVP-TE Extensions in Support of End-to-End. Generalized Multi- Protocol Label Switching (GMPLS) Recovery xxvi. RFC 4873 GMPLS Segment Recovery xxvii. RFC 6003 Ethernet Traffic Parameters xxviii. RFC 6205 Generalized Labels for Lambda-Switch-Capable (LSC)Label Switching Routers xxix. RFC 3473 Generalized MPLS Signaling, RSVP-TE Extensions xxx. RFC 4003 GMPLS Signaling Procedure for Egress Control xxxi. RFC 4783 GMPLS - Communication of Alarm Information xxxii. RFC 4873 GMPLS Segment Recovery xxxiii. RFC 4874 Exclude Routes - Extension to Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) xxxiv. RFC 3478 Graceful Restart Mechanism for Label Distribution Protocol xxxv. RFC 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls xxxvi. RFC 3479 Fault Tolerance for the Label Distribution Protocol (LDP) xxxvii. RFC 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions xxxviii. RFC 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering Metric ( Support for TE and IGP Metrics for CSPF ) xxxix. RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) xl. RFC3815 Definitions of Managed Objects for MPLS LDP. xli. RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. xlii. RFC 4125 Maximum Allocation Bandwidth Constraints Model fordiffservaware MPLS Traffic xliii. RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffservaware MPLS Traffic Engineering. xliv. RFC 4201 Link Bundling in MPLS Traffic Engineering (TE) xlv. RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (LSP PING y TRACEROUTE) xlvi. RFC 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels xlvii. RFC 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping xlviii. RFC 6426 MPLS On-Demand Connectivity Verification and Route Tracing xlix. RFC 6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM) l. RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks li. RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). [O] lii. RFC 6073 Multisegment Pseudowire. liii. RFC 6723 Update of the Pseudowire Control-Word Negotiation Mechanism Proyecto Red IP/MPLS ARSAT SA Página 29 de 69

30 liv. lv. lvi. lvii. lviii. lix. lx. lxi. lxii. lxiii. lxiv. lxv. lxvi. lxvii. RFC 4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) RFC 4950 ICMP Extensions for Multiprotocol Label Switching [O], RFC 5036 LDP Specification [O], RFC 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) RFC 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) RFC 5332 MPLS Multicast Encapsulations RFC 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions RFC 5561 LDP Capabilities [O], RFC 5654 Requirements of an MPLS Transport Profile RFC 5586 MPLS Generic Associated Channel RFC 6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) RFC 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths RFC 5085 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV). [O] RFC 5884 Bidirectional Forwarding Detection (BFD) [O] Argumentar cada uno de los siguientes puntos: a. Describir la implementación de la funcionalidad. b. Soporte de encapsulamiento en Ethernet. [O] c. Para el MPLS-LDP, indicar los distintos métodos soportados. d. El equipo debe poder soportar la creación manual de LSPs. [O] e. Especificar el impacto en la performance del equipo actuando como edge- LSR, en función de: CPU, memoria, otros recursos. f. Especificar el impacto en la performance del equipo actuando como LSR, en función de: CPU, memoria, otros recursos. g. Especificar el impacto en la performance del equipo actuando como LSR y edge-lsr simultáneamente, en función de: CPU, memoria, otros recursos. h. Indicar La cantidad máxima de entradas de labels MPLS de forwarding. Detallar el o los factores que imponen el límite. i. Indicar la cantidad máxima de entradas de labels MPLS. [O] j. Indicar La cantidad máxima de MPLS LSP s.. Detallar el o los factores que imponen el límite. k. Indicar los distintos protocolos de ruteo soportados dentro de la funcionalidad de MPLS, garantizando y describiendo las extensiones de los mismos de acuerdo a sus respectivas normas, siendo obligatorio [O] el soporte de: BGP, MP-BGP, OSPF. l. Soporte de MPLS-LDP [O]. Indicar los distintos métodos soportados para control (independent, ordered), para distribución (DU, DoD), para retención (Liberal, Conservative). m. Adicionalmente indicar otros protocolos soportados por el equipo (MPLS- BGP, MPLS-RSVP-TUNNELS y MPLS-CR-LDP), incluyendo el cumplimiento de las normas asociadas a cada uno de ellos. n. Indicar la versión y release de software para el soporte de dicha funcionalidad. Proyecto Red IP/MPLS ARSAT SA Página 30 de 69

31 o. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.). p. Indicar La cantidad máxima de RSVP-TE LSP s. Máximo número de LSP (Head End), Máximo número de LSP (Transit). Máximo número de LSP (Egress) q. Especificar la interoperabilidad con equipamiento de otros fabricantes. r. Indicar si el equipamiento soporta LSP Punto a Multipunto Funcionalidades En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. En el caso de las normas que se hayan publicado en el IETF en carácter de RFC dentro de los veinticuatro meses inmediatos anteriores a la fecha de publicación del presente concurso, y que el proveedor no la haya implementado aún, se deberá indicar expresamente la fecha de cumplimiento prevista en su roadmap y el tipo de compromiso asumido en el mismo Access List a. Se deberá soportar la aplicación de listas de acceso que permitan la identificación del tráfico de acuerdo a los siguientes parámetros incluyendo sus combinaciones [O]: i. IP origen ii. IP destino, iii. Protocolo iv. Puerto v. Precedencia / DSCP b. Se deberá soportar la aplicación de listas de acceso que permitan la identificación del tráfico de VoIP (Flujos RTP) iniciados por protocolos H.323, SIP, MGCP, H.248. c. Indicar y describir otros flujos que pueden ser identificados (ej. FTP Get / Put, etc.) d. Detallar todas las funcionalidades que pueden ser aplicadas a una lista de acceso (permitir / denegar el flujo, aplicar políticas de QoS, etc.) e. Indicar el número máximo de listas de acceso que pueden ser aplicadas a una interfaz f. Indicar el número máximo de listas de acceso que pueden ser aplicadas a una sub-interfaz. g. Indicar el número máximo de listas de acceso que pueden ser aplicadas por placa o módulo de acceso. h. Indicar el número máximo de listas de acceso que pueden ser aplicadas en el equipo. Proyecto Red IP/MPLS ARSAT SA Página 31 de 69

32 i. Especificar el impacto en la performance del equipo, placa e interfaz al procesar el máximo número de listas de acceso soportadas, en función de: CPU, memoria, otros recursos. j. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) VPN-MPLS El soporte de dicha funcionalidad es de carácter obligatorio [O], y su funcionamiento deberá estar en un todo de acuerdo con las normas establecidas por el IETF (según RFC 4364) y el MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. El oferente deberá responder los siguientes puntos: a. Describir la implementación de dicha funcionalidad. b. Indicar el impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. c. Cantidad máxima de VPNs soportadas por el equipo d. Cantidad máxima de VRFs con QoS soportadas por el equipo e. Cantidad máxima de VRFs con QoS y mcast soportadas por el equipo f. Cantidad máxima de rutas soportadas en cada VPN. g. Una descripción detallada que explique las razones de los límites indicados. h. Indicar los protocolos de ruteo soportados por la VPN, o sea, el protocolo entre el CE (customer equipment) y el edge-lsr. Para estos protocolos detallar el número máximo de instancias y rutas soportadas. i. Especificar los distintos métodos de acceso a las VPNs-MPLS, indicando si soporta el acceso desde cualquier interfaz o si presenta limitaciones al respecto. Los siguientes métodos de acceso son obligatorios [O]: i. Interfaces (Ethernet). ii. Subinterfaces (Ethernet). j. Indicar y detallar el soporte de que clientes de distintas VPNs puedan acceder a una VPN compartida para obtener algún servicio en particular, es decir que pueda existir una VPN que brinde servicios a otras VPN [O]. k. Detallar las funcionalidades asociadas a una VRF (ACL por VRF, NAT/PAT por VRF, etc.). l. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.). m. Indicar la versión y release de software para el soporte de dicha funcionalidad. n. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otro fabricante. o. Especificar el soporte de todo el conjunto de funcionalidades necesarias para implementar el modelo InterAS VPN opción A, B y C [O]. p. Se deberá poder publicar o importar prefijos de tal manera de poder armar topologías Hub-Spoke, Full Mesh [O] Proyecto Red IP/MPLS ARSAT SA Página 32 de 69

33 q. Se deberá poder redistribuir dentro de la VPN-L3 prefijos publicados por ruteo estático, RIP, ebgp, OSPF, IS-IS. [O] r. Se debe poder limitar el número de prefijos por cada VPN-L3.[O] s. Se deberá poder realizar los peering de ibgp contra al menos dos equipos Route Reflector (modalidad activo/standby) Gestión de VPN MPLS El oferente deberá indicar si posee un sistema de gestión propio o de terceros que realice todas o alguna de las siguientes funcionalidades, indicando cuales: a. Recolección de datos relacionados a MPLS-VPN del equipo propuesto junto a otros equipamientos con soporte MPLS-VPN. b. Procesamiento de los datos obtenidos según el punto a, en forma centralizada. c. Provisión en el equipo propuesto de la configuración necesaria para implementar el nuevo plan calculado en el punto b. d. El oferente deberá indicar las MIBs de MPLS-VPN con que cuenta el equipamiento Clase de Servicio y Calidad de Servicio El soporte de QoS es de carácter obligatorio. El oferente deberá responder a los siguientes puntos: a. Soporte de QoS (marcado, clasificación, shaping, encolado) aplicado en interfaces 10 GE y subinterfaz lógica. [O] b. Soporte de QoS (marcado, clasificación, shaping, encolado) aplicado en interfaces 1 GE y subinterfaz lógica. [O] c. Soporte de QoS (marcado, clasificación, shaping, encolado) aplicado en interfaces 1 FE y subinterfaz lógica. [O] d. Soporte de colas de alta prioridad de baja latencia. Detallar cantidad de colas soportadas de este tipo y su funcionamiento. Indicar la performance de diseño en términos de valores de latencia, jitter y descartes de paquetes de cada cola. [O] e. Soporte de colas con posibilidad de asignar un ancho de banda mínimo garantizado en cada una, en condiciones de congestión. [O]. f. Posibilidad de re-utilización automática del ancho de banda mínimo definido en e. por una clase de servicio diferente a la asignada originalmente a la cola, ante la ausencia de trafico de ésta [O]. g. Posibilidad de asignar un límite superior de ancho de banda a cada cola [O]. h. Jerarquía de calidad de servicio de tres niveles [O]. i. Ancho de banda garantizado por C-VLAN y S-VLAN (jerarquía de shapping) [O] j. Soporte de las funcionalidades de marcado, clasificación, shaping, encolado por cada subinterfaz lógica, utilizando un mínimo de 5 colas y 5 clases de servicio [O] k. Soporte de WRED en las clases de servicio aplicadas a las interfaces y subinterfaces en 10 GigabitEthernet Proyecto Red IP/MPLS ARSAT SA Página 33 de 69

34 l. Soporte de WRED en las clases de servicio aplicadas a las interfaces y 8subinterfaces en 1 GigabitEthernet m. Soporte de WRED en las clases de servicio aplicadas a las interfaces y subinterfaces en 1 FastEthernet n. Indicar el soporte de WRED en las clases de servicio aplicadas a todas las interfaces y subinterfaces soportadas o. Indicar el soporte de Mapeo entre CoS de nivel 2 a DSCP de nivel 3. Considerar que la trama de nivel 2 puede estar formada con un header de uno o dos tags 802.1q(Inner y Outer Tag) [O] p. Indicar el soporte de Mapeo entre DSCP de nivel 3 a CoS de nivel 2. Considerar que la trama de nivel 2 puede estar formada con un header de uno o dos tags 802.1q (Inner y Outer Tag) [O] q. Indicar el soporte de Mapeo entre DSCP de nivel 3 a MPLS EXP. Indicar las formas de mapeo. [O] r. Indicar el soporte de Mapeo entre COS de nivel 2 a MPLS EXP. Indicar las formas de mapeo. Considerar que la trama de nivel 2 puede estar formada con un header de uno dos tags 802.1q (Inner y Outer Tag) [O] s. Describir detalladamente la implementación de dichas funcionalidades a nivel plano y para vpn. Describir el funcionamiento por hop. t. Describir los distintos mecanismos soportados para el manejo de CoS/QoS implementados. u. Describir si es posible asignar anchos de banda equitativamente o asignando pesos entre n usuarios discriminados por IP que se encuentren compartiendo un mismo vínculo. v. Describir detalladamente los procesos de: clasificación, marcado, encolamiento y scheduling. w. Describir el manejo de las colas dentro del equipo. x. Indicar si el equipo soporta asignar colas por: 1. Interfaz física 2. Interfaz lógica 3. Placa y. Indicar la cantidad de colas que soporta el equipo por: 1. Interfaz física 2. Interfaz lógica 3. Placa 4. Chasis z. Indicar si existe alguna limitación en términos de escalabilidad entre la cantidad de colas y la cantidad de sub interfaces, por puerto, por slot, por chasis aa. Especificar el impacto en la performance del equipo para cada uno de los mecanismos empleados y para su combinación, en función de: CPU, memoria, otros recursos. bb. Especificar si dichas funcionalidades están implementadas en hardware o en software. cc. Indicar la versión y release de software para el soporte de dicha funcionalidad (por cada mecanismo descripto. En el caso que algunos componentes de dicha funcionalidad se implementen en versiones futuras (en roadmap) indicar la versión y su fecha de implementación. Proyecto Red IP/MPLS ARSAT SA Página 34 de 69

35 dd. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad (por cada mecanismo descripto) esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) ee. Especificar la interoperabilidad de dicha funcionalidad (por cada mecanismo descripto) con equipamiento de otros fabricantes DiffServ El soporte de dicha funcionalidad es de carácter obligatorio [O]. La implementación de dicha funcionalidad deberá estar en todo de acuerdo a las normas establecidas por el IETF (RFC 2474, RFC 2475, RFC 2597, RFC 2598, RFC 3246, RFC 3260). En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. El oferente deberá responder a los siguientes puntos: a. Describir detalladamente la implementación de dicha funcionalidad. b. Especificar el impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. c. Especificar si dichas funcionalidades están implementadas en hardware o en software. d. Indicar la versión y release de software para el soporte de dicha funcionalidad, en el caso que dicha funcionalidad se implemente en versiones futuras (en roadmap) indicar la versión y su fecha de implementación. e. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) f. Especificar la interoperabilidad de dicha funcionalidad con la equipamiento de otros fabricantes DiffServ MPLS El soporte de dicha funcionalidad es de carácter obligatorio [O]. La implementación de dicha funcionalidad deberá estar en todo de acuerdo a las normas establecidas por el IETF (RFC 3270, RFC 5462). El oferente deberá responder a los siguientes puntos: Proyecto Red IP/MPLS ARSAT SA Página 35 de 69

36 a. Describir detalladamente la implementación de dicha funcionalidad, indicando las modalidades soportadas. b. Describir los distintos mecanismos utilizados para su implementación. c. Especificar el impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. d. Especificar si dichas funcionalidades están implementadas en hardware o en software. e. Indicar la versión y release de software para el soporte de dicha funcionalidad. f. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) g. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros fabricantes DiffServ-aware MPLS Traffic Engineering El soporte de dicha funcionalidad es de carácter obligatorio. La implementación de dicha funcionalidad deberá estar en todo de acuerdo a las normas establecidas por el IETF (RFC 4124). El oferente deberá responder a los siguientes puntos: a. Describir detalladamente la implementación de dicha funcionalidad, indicando las modalidades soportadas. b. Describir los distintos mecanismos utilizados para su implementación. c. Especificar el impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. d. Especificar si dichas funcionalidades están implementadas en hardware o en software. e. Indicar la versión y release de software para el soporte de dicha funcionalidad. f. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) g. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros fabricantes. h. Indicar el soporte, describir la implementación y casos de aplicación recomendados. Proyecto Red IP/MPLS ARSAT SA Página 36 de 69

37 Métodos de clasificación La funcionalidad consiste en los distintos métodos de clasificación de tráfico soportados. El soporte de dicha funcionalidad es obligatorio [O]. El oferente deberá responder a los siguientes puntos: a. Describir detalladamente la implementación de dicha funcionalidad. b. Especificar los distintos mecanismos utilizados para su implementación c. Soporte de clasificación por DiffServ. [O] d. Soporte de clasificación por dirección IP. [O] e. Soporte de clasificación por puerto físico (interfaz). [O] f. Soporte de clasificación por puerto lógico (sub-interfaz, VLANs, etc.). [O] g. Clasificación mediante el uso de 802.1p. [O] h. Soporte de clasificación por tipo de protocolo, describir los soportados. i. Soporte de reclasificación, consiste por ejemplo: en recibir un flujo clasificado por DiffServ o 802.1p y reclasificarlo. [O] j. Indicar y describir la cantidad máxima de reglas que soporta por interfaz física y logica. k. Especificar el impacto en la performance del equipo para cada uno de los métodos empleados y para su combinación, en función de: CPU, memoria, otros recursos. l. Indicar la versión y release de software para el soporte de dicha funcionalidad, en el caso que algunos componentes de dicha funcionalidad se implementen en versiones futuras (en roadmap) indicar la versión y su fecha de implementación. m. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) Alta disponibilidad Consiste en un conjunto de distintas funcionalidades que se detallan a continuación. El oferente deberá responder si cumple con el soporte, describir la implementación e indicar los límites de escalabilidad: a. Non-Stop Forwarding (NSF) i. OSPF [O] ii. BGP iii. LDP [O] [O] iv. Multicast v. IS-IS vi. RSVP b. Stateful Switchover (SSO) c. OSPF Graceful Restart [O] d. BGP Graceful Restart [O] e. LDP Graceful Restart [O] f. OSPF Fast Convergence. Proyecto Red IP/MPLS ARSAT SA Página 37 de 69

38 g. MP-iBGP Graceful Restart [O] h. Bidirectional Forwarding Detection (BFD), en las siguientes modalidades: i. BFD para OSPF [O] ii. BFD para BGP [O] iii. BFD para LDP [O] iv. BFD for IPv4 and IPv6 (Single Hop); RFC 5881.Indicar ademas: i. Sincronismo entre LDP y OSPF a. Cantidad de sesiones BFD máxima por tarjeta de línea b. Cantidad de sesiones BFD máxima por chasis. Limitado al número de linecard del chassis. j. Proteccion de sesiones routing para mantenerlas activas ante fallas de puerto de linea / módulo de línea. k. Herramientas de troubleshooting de MPLS : MPLS OAM (LSP ping/ Traceroute) l. Non-Stop routing (NSR) i. OSPF [O] ii. BGP [O] iii. LDP [O] iv. Multicast Adicionalmente, el oferente deberá responder al siguiente punto: - Indicar si poseen roadmap o cumplen el soporte de RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV), RFC 6478, Pseudowire Status for Static Pseudowires Traffic Engineering El oferente deberá responder a los siguientes puntos: a. Describir la implementación de dicha funcionalidad. b. Indicar la versión y release de software para el soporte de dicha funcionalidad, en el caso que dicha funcionalidad se implemente en versiones futuras (en roadmap) indicar la versión y su fecha de implementación. c. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) d. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros fabricantes e. Especificar los protocolos IGP-TE que soporta el equipo, junto a los atributos que el equipo es capaz de propagar de los LSPs correspondientes, por este medio. f. Especificar si el equipo posee algoritmo de CBR (Constraint Base Routing), indicando a que RFC y/o draft del organismo IETF responde. g. Especificar si el equipo soporta tuneles MPLS-TE en subinterfases dot1q. Proyecto Red IP/MPLS ARSAT SA Página 38 de 69

39 h. Indicar que tipo de señalización para la creación y mantenimiento de túneles MPLS-TE utiliza el equipo ( RSVP-TE, CR-LDP i. Indicar si esta funcionalidad responde a otros drafts publicados en la organización IETF, indicando el/los nombre/s del/de los mismo/s. j. El impacto en la performance del equipo actuando como edge-lsr, en función de: CPU, memoria, otros recursos. k. El impacto en la performance del equipo actuando como LSR, en función de: CPU, memoria, otros recursos. l. El impacto en la performance del equipo actuando como edge-lsr (túnnel headend, túnnel tail-end) y LSR (transit tunnel) simultáneamente, en función de: CPU, memoria, otros recursos Traffic Engineering Fast Re Route (TE-FRR) El oferente deberá responder a los siguientes puntos: a. Describir la implementación en sus tres modalidades: link/node/shared Risk Link Group b. Tiempo de restauración medio c. Cantidad máxima de tuneles de backup admitidos por cada instancia a proteger d. Cantidad máxima de tuneles de backup admitidos por el equipo e. Describir los métodos de troubleshoting y OAM asociados f. Indicar el soporte de RFC 4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object g. Indicar el soporte de RFC 6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute PWE3 (Pseudo-Wire Emulation Edge-to-Edge) De acuerdo a las descripciones de los manifiestos RFC 4664 y RFC 4665, el oferente debera responder sobre PWE3 acorde al marco establecido en estas dos RFC. La funcionalidad consiste en la emulación de circuitos (ATM, FR, Ethernet, TDM, etc.) end to end a través de la red IP-MPLS. El soporte de dicha funcionalidad es de carácter obligatorio [O], y su funcionamiento deberá estar en un todo de acuerdo con las normas establecidas por el IETF (según la lista de RFCs siguientes) y el MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas i. RFC Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. [O] ii. RFC 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN iii. RFC IANA Allocations for Pseudowire Edge to Edge Emulation (PWE) para Pseudowired tipo 0x04 (Ethernet Tagged Mode) y Pseudowired tipo 0x05 (Ethernet Raw Mode) [O] iv. RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)[O] Proyecto Red IP/MPLS ARSAT SA Página 39 de 69

40 v. RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks [O] vi. RFC 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks [O] vii. RFC 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service. [O] viii. RFC 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to- Edge ix. RFC 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks x. RFC 4906 Transport of Layer 2 Frames Over MPLS xi. RFC 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to- Edge xii. RFC 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) [O] xiii. RFC 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) [O] xiv. RFC 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) xv. RFC 6718 Pseudowire Redundancy. [O] xvi. draft-ietf-pwe3-redundancy-bit - Preferential Forwarding Status bit definition [O] El oferente deberá responder respecto al equipamiento propuesto, los siguientes puntos: [O] a. Describir detalladamente la implementación de dicha funcionalidad, indicando las normas y/o drafts conformes en su implementación. b. Indicar y detallar las distintas encapsulaciones de capa 2 soportadas (particularmente ethernet) para el transporte sobre MPLS. c. Indicar y detallar el soporte de ethernet Q -in- Q sobre PWE3. d. El impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. e. Indicar la versión y release de software para el soporte de dicha funcionalidad, en el caso que dicha funcionalidad se implemente en versiones futuras (en roadmap) indicar la versión y su fecha de implementación. f. Especificar la relación entre el hardware y dicha funcionalidad, o sea, detallar si dicha funcionalidad esta soportada independientemente del hardware implementado (interfaces, procesador, etc.) g. Indicar el soporte de modo los modos de transporte Ethernet Raw Mode y Ethernet Tagged Mode de acuerdo a RFC 4448 h. Asignación manual de VC Labels. i. Para los tipos PWE Encapsulation tipo 4 y tipo 5 [RFC 4446]; Indicar las cantidades máximas admisibles. j. Indicar la cantidad máxima de PWE soportada por Chasis/ Slot / Ports según corresponda. Indicar de (Considerar el número en forma bidireccional),tambien describir todos los recursos lógicos que se deben tener en cuenta para realizar la emulación de un servicio E-Line sea Proyecto Red IP/MPLS ARSAT SA Página 40 de 69

41 provisionado localmente o involucre equipos remotos : a. PW Raw Mode b. PW Tagged Mode c. Attachtment Circuits d. Otros k. Indicar la cantidad de pseudowired soportados en modo redundante tanto para el modo Independiente como Maestro/Esclavo (ver draft-ietf-pwe3- redundancy-bit-xx.txt).indicar y explicar la implementación utilizada. l. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros fabricantes, tanto para single pseudowired como para pseudowired redundante VPLS La funcionalidad consiste en la emulación de Servicios Ethernet point-to-multipoint, multipoint-to-multipoint, end to end a través de una red MPLS.La arquitectura para proveer la emulación de los servicios deberá estar de acuerdo a la RFC 4762 o RFC 4761, RFC 5462 de acuerdo a la implementacion elegida por el proveedor. Dado que la emulación está orientado al transporte de Ethernet se deberá tener en cuenta las particularidades definidas en RFC 4448 (EoMPLS) para el full mesh de PEs interviniendo en la VPLS. Para el caso de la señalización se debera tener en cuenta las especificaciones de RFC 4447, RFC 5036 (LDP) y RFC 4760 (BGP). a. De acuerdo a lo antes mencionado responder cada uno de los siguientes puntos incluyendo en el caso que corresponda las recomendaciones y/o drafts asociados: b. Soporte de la arquitectura VPLS [O].Describir detalladamente la implementación de dicha funcionalidad. c. LDP RFC 4762 Virtual Private LAN Services using LDP signaling [O] d. BGP RFC 4761 BGP Autodiscovery and Signaling for VPLS. e. Indicar los protocolos soportados y el utilizado en la solución para realizar el proceso Discovery de los PE Remotos f. Indicar la cantidad máxima de Instancias de Switching (Services Instances, Bridge Domain, etc) soportadas por Chasis, funcionando en modo Qualified y Unqualified,,el número especificado debe considerar VPLS de al menos 2 peer (Nro. de PEs=3): g. Máximo número de VPLS Qualified Mode h. Máximo número de VPLS Unqualified Mode [O] i. Indicar la cantidad máxima de MACs que puede aprender cada instancia de Switching (VSI, Bridge Domain, etc). [O] j. Indicar el número máximo de peer remotos que pueden establecerse por Instancia VPLS. [O] k. Indicar el número máximo de puntos de acceso(ac) por VPLS. [O] l. Para el caso de VPLS funcionando en modo jerarquico (H-VPLS), indicar la cantidad de pseudowired de accesos soportados por cada VPLS. [O] m. Indicar el soporte para que Link Aggregation Groups puedan conectarse como puntos de acceso de una VPLS. n. Indicar el soporte de Flooding BPDU (SPT, RSPT,etc) dentro de una VPLS Proyecto Red IP/MPLS ARSAT SA Página 41 de 69

42 o. Indicar el soporte de un mecanismo para configurar una máxima utilización de CPU para el proceso de VPLS. p. Indicar el soporte de uno o varios LSP backups al LSP primario que se utiliza para realizar el peer entre dos PE pertenecientes a las misma VPLS. Detallar el funcionamiento y el numero de LSP backup soportados y si se le pueden asignar diferentes prioridades ante un eventual switchover. q. Para el caso del punto anterior en el caso de soportarlo, indicar si se puede realizar LSP Load Balancing entre los LSP pertenecientes a al VPLS peer.indicar funcionamiento y en base a que campo se realizar el balanceo (UDP/TCP,IP,MAC,etc). r. Indicar el soporte de un mecanismo para realizar MAC limit [O]. a. Por VPLS b. Por port de acceso a VPLS s. Indicar el soporte de un mecanismo para controlar el tráfico de Brodcast, Multicast, Unknowk- Unicast packet Limit por VPLS [O]. t. Indicar el soporte de modificacion de MAC-ADDRESS Aging y el rango de tiempo soportado u. Indicar y explicar que mecanismo provee la solución para evitar la duplicación de MAC ADDRESS dentro de una instancia VPLS. v. Para poder obtener un mejor control del flooding de frames dentro de la VPLS, indicar el soporte de Split Horizont configurable : [O] a. Por puerto físico b. Por subinterfaz lógica c. Por Vlan a. Por Bundle de Vlans Path MTU Discovery Su funcionamiento deberá estar en un todo de acuerdo con las normas establecidas por el IETF ( según la lista de RFC siguiente) y el MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. De acuerdo a lo antes mencionado indicar si la implementación está de acuerdo las siguientes recomendaciones y/o drafts: a. RFC 1191 Proyecto Red IP/MPLS ARSAT SA Página 42 de 69

43 Virtual Router Redundancy Protocol (VRRP) Su funcionamiento deberá estar en un todo de acuerdo con las normas establecidas por el IETF (según la lista de RFC siguiente) y el MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el oferente deberá garantizar su cumplimiento una vez estandarizadas las mismas. De acuerdo a lo antes mencionado indicar si la implementación está de acuerdo a las siguientes recomendaciones y/o drafts: a. RFC 5798 [O] b. VRRP support for MPLS VPNs [O] c. Funcionalidades de rápida convergencia de VRRP. d. Indicar el número de instancias y,o grupos VRRP soportadas por puerto fisco, por subinterfaz lógica, por slot, por chasis [O] Tunneling y encripción de datos mediante IPSEC A continuación se detallan los aspectos requeridos sobre IPSec para los equipos propuestos. Se deberá responder punto a punto lo siguiente: a. La capacidad del equipo propuesto para lograr la generación y/o terminación de túneles IPSec, debiendo este ser compatible con las normas establecidas por el IETF (RFC 4301, 4302, 4835, 2403, 2404, 2405, 4303, 4835, 5282, 5996, 5998, 4109,2451 y 6040). b. Describir la implementación de la funcionalidad de encripción. c. Describir para cada equipo propuesto, las modalidades de manejo de llaves o claves de seguridad soportadas. d. Indicar la compatibilidad con algoritmos de encripción DES. Indicar la compatibilidad con equipos de otros fabricantes. e. Indicar la compatibilidad con algoritmos de encripción 3DES (Triple DES) con longitud de clave de 168 bits. Indicar la compatibilidad con equipos de otros fabricantes. f. Indicar la compatibilidad con algoritmos de encripción AES (Advanced Encription Standard según RFC 5246, 5746, 5878, 6176, 3394, 3537, y 3565). Indicar la compatibilidad con equipos de otros fabricantes y describir además sus características. g. Especificar el impacto en la performance del equipo para cada uno de los mecanismos empleados y para su combinación, en función de: CPU, memoria, otros recursos. h. Indicar la cantidad máxima de túneles IPSec en forma simultánea, que soporta el equipo propuesto. Indicar en qué condiciones se detalla tal característica. i. Indicar la cantidad máxima de túneles IPSec que puede generar y/o terminar el equipo por unidad de tiempo (medido en segundos), y el throughput de datos soportado por cada túnel. j. Especificar la existencia o no, de mecanismos para limitar el número de túneles IPSec admitidos por el equipo. En caso de existir describirlos detalladamente. k. Especificar, en caso de no existir mecanismo de control que sucede con el equipo superado el número máximo de túneles IPSec soportados. Proyecto Red IP/MPLS ARSAT SA Página 43 de 69

44 l. Indicar la versión (release) de software para el protocolo en cuestión. En caso que el mismo fuera implementado en versiones futuras (en hoja de ruta o roadmap); se deberá indicar la versión correspondiente y su fecha comprometida de implementación. m. En caso que aplique, indicar la existencia de limitaciones entre el hardware presentado (interfaces, procesador, etc.) y dicha funcionalidad Router Virtual Describir e indicar el soporte de cada uno de los siguientes puntos a. Soporte de múltiples instancias de router virtual en un mismo equipo, separadas lógicamente. Detallar como se realiza la implementación. b. Indicar cuál es la cantidad máxima de rutas que se pueden almacenar en cada tabla de routing de router virtual. c. Indicar si hay alguna limitación en el tipo y cantidad de interfaces físicas y lógicas que se pueden asociar y referenciar a cada router virtual. d. Indicar si existe alguna limitación en relación a los protocolos de ruteo que se pueden asociar y referenciar a las rutas de cada tabla de routing del router virtual. e. Indicar cuál es la relación ente las instancias de router virtual y la cantidad de memoria que debe tener el equipo. Indicar si se requiere memoria adicional al equipamiento presentado en el item: Descripción de equipos. f. Indicar impacto en la performance del equipo, en función de: CPU, memoria, otros recursos. g. Especificar, en caso de existir, mecanismos para el ruteo del tráfico internamente entre routers virtuales (como por ejemplo: virtual interface, ruteo por políticas, etc.) Tunneling Indicar el soporte de los siguientes tipos de túneles: a. GRE, Generic Routing Encapsulation, según RFC 2784, RFC 2890 b. Generic Routing Encapsulation (GRE) Tunnel Keepalive c. L2TPv2 RFC 2661 Layer Two Tunneling Protocol d. L2TPv3 RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) De acuerdo a lo antes mencionado,por cada funcionalidad de túnel requerida, describir e indicar el soporte de cada uno de los siguientes puntos: i. La capacidad del equipo propuesto para lograr la generación y/o terminación de túneles). ii. Describir la implementación de la funcionalidad. iii. Especificar el impacto en la performance del equipo para cada uno de los mecanismos empleados y para su combinación, en función de: CPU, memoria, otros recursos. iv. Indicar la cantidad máxima de túneles en forma simultánea, que soporta el equipo propuesto. Indicar en qué condiciones se detalla tal característica. Proyecto Red IP/MPLS ARSAT SA Página 44 de 69

45 v. Indicar la cantidad máxima de túneles que puede generar y/o terminar el equipo por unidad de tiempo (medido en segundos), y el throughput de datos soportado por cada túnel. vi. Especificar la existencia o no, de mecanismos para limitar el número de túneles admitidos por el equipo. En caso de existir describirlos detalladamente. vii. Especificar, en caso de no existir mecanismo de control que sucede con el equipo superado el número máximo de túneles soportados. viii. Indicar la versión (release) de software para el protocolo en cuestión en caso que el mismo fuera implementado en versiones futuras (en hoja de ruta o roadmap); se deberá indicar la versión correspondiente y su fecha comprometida de implementación. ix. En caso que aplique, indicar la existencia de limitaciones entre el hardware presentado (interfaces, procesador, etc.) y dicha funcionalidad Sincronismo a. El equipamiento debe estar preparado para soportar el estándar IEEE1588v2. [O] b. El equipamiento debe estar preparado para soportar el estándar G.8261 (Synchronous Ethernet) Fuentes de Sincronismo a. Indicar si el equipo es capaz de tomar el sincronismo de una entrada externa. b. Indicar si el equipo es capaz de recuperar el sincronismo proveniente de una red de paquetes (IEEE1588v2) desde cualquier tipo de interfaz. c. El equipo deberá cumplir funciones de boundary clock (regenerar y proveer sincronismo según estándar IEEE1588v2). [O] d. El equipo deberá soportar y cumplir funciones de transparent clock ( corregir tiempo de estadía en equipos,de paquetes según estándar IEEE1588v2). [O] e. Indicar si el equipo puede equiparse con un módulo de GPS interno. f. Indicar si el equipo soporta BITS (Building Integrated Timing Supply). g. Adicionalmente a lo indicado en los ítems anteriores, indicar otros protocolos y/o estándares de sincronismo soportados por el equipo OPERACION y MANTENIMIENTO MEF ELMI (ETHERNET LOCAL MANAGEMENT INTERFACE) a. Indicar el soporte de ELMI (Ethernet Local Management Interface) según lo especificado en el MEF 16, el cual define el protocolo y procedimientos necesarios para permitir la auto configuración de los dispositivos CE y los medios para la notificación del estatus de los EVCs y de la UNI. b. Indicar si el ELMI es implementado por hardware o por software. c. Indicar cuantas instancias de ELMI son soportadas. Proyecto Red IP/MPLS ARSAT SA Página 45 de 69

46 IEEE 802.3AH OAM a. Indicar el soporte de 802.3ah OAM b. Indicar la frecuencia mínima de configuración para el envío periódico de paquetes para realizar la detección de fallas (802.3ah OAM link monitoring). c. Indicar el soporte de OAM Remote Loopback. d. Indicar si 802.3ah es un proceso implementado por hardware o por software. e. Indicar si se soporta 802.3ah simultáneamente con ELMI IEEE 802.1AG (ETHERNET CONNECTIVITY FAULT MANAGEMENT) a. Indicar el soporte de 802.1ag, especificando el soporte de los siguientes protocolos: i. Continuity Check Protocol (CCM). ii. iii. Loopback Protocol (LBM, LBR) Linktrace Protocol (LTM, LTR) b. Indicar el soporte de RDI en los mensajes CCM. c. Indicar el soporte de los TLV opcionales: Port Status TLV e Interface Status TLV. d. Indicar la cantidad máxima de MEPs, MIPs y MA soportados por puerto, placa y chasis. e. Indicar en que tipo de interfaces (untag, VLAN, EoMPLS end point, ruteados, etc) son soportados los MEPs y MIPs diferenciando por tipo de MP (UP y DOWN) f. Indicar si los procesos de 802.1ag son implementados en software o hardware. g. Indicar la cantidad de MEPs y MIPs soportados para los siguientes intervalos de tiempo de envío de los mensajes CCM: i. 3,3 ms ii. iii. iv. 10 ms 100 ms 1 seg v. 10 seg h. Especificar si la base de datos de CCM es soportada en los MIPs (opcional en el Standard) a fin de que los mensajes LTM lleguen a destino aunque las MAC hayan sido borradas por aging time. i. Indicar si existe interoperabilidad probada con equipamiento de otros fabricantes. Proyecto Red IP/MPLS ARSAT SA Página 46 de 69

47 ITU Y.1731 (PERFORMANCE FAULT MANAGMENT) a. Especificar el soporte de las siguientes funciones de monitoreo de performance: i. Frame loss ratio ii. Frame delay iii. Frame delay variation iv. Throughput b. Debido a que los protocolos CCM, LBR/LBM, LTM/LTR no son compatibles totalmente entre los definidos por la ITU y los definidos por la IEEE 802.1ag, especifique cuales mensajes (ITU o IEEE) son utilizados para las funciones del punto anterior. c. Especifique si se soporta AIS. d. Indicar si existe interoperabilidad probada con equipamiento de otros fabricantes INTEROPERABILIDAD DE OAM. a. Indicar si existe interoperabilidad entre ELMI y 802.1ag b. Indicar si existe interoperabilidad entre 802.3ah y 802.1ag c. Indicar si existe interoperabilidad entre 802.1ag y MPLS OAM d. Indicar si existe interoperabilidad entre 802.1ag y BFD Proyecto Red IP/MPLS ARSAT SA Página 47 de 69

48 6.6. CAPACIDADES DE GESTIÓN PROVISTAS POR EL ELEMENTO DE RED INTERFACES GESTION a. El equipo presentado deberá soportar como mínimo las siguientes interfaces de gestión : i. Fallas: SNMPv1, SNMPv2 o SNMPv3 y Syslog. [O] ii. Configuración: SNMP [O], TFTP [O], FTP [O], Telnet o SSH2 (Secure Shell versión 2) [O]. iii. Performance: SNMPv1, SNMPv2 o SNMPv3. [O] iv. Accounting: generación de accounting y redirección a gestores a definir. v. Seguridad: Radius o TACACS [O] b. El oferente deberá especificar y detallar otras interfaces de gestión que no hayan sido indicadas en a) (por ejemplo: Q3, TL1, HTTP, API propietarias, etc.), indicando las funcionalidades asociadas para cada una de ellas. c. Para las interfaces SNMP, detallar las MIBs soportadas por el equipo (MIBII, Technology-specific MIB, Vendor-specific MIB). Adicionalmente se requiere una descripción de la MIB Vendor-specific soportada y sus funcionalidades asociadas en el equipo. d. El equipo debe contar con la capacidad de gestionar MIBs RMON y SMON. Adicionalmente se deberán detallar y entregar estas MIBs. e. El oferente deberá entregar para ARSAT la totalidad de las MIBs SNMP y sus diccionarios (traducción y descripción de los campos de la MIB) correspondientes a los elementos de red y al sistema de gestión propuestos. f. El equipo deberá disponer de un port exclusivo de management. Indicar otros ports que permitan realizar la gestión mencionada. g. Debe tener la posibilidad de limitar o restringir todas las funcionalidades de management (Telnet, SNMP, etc.) a través de un port / interfaz exclusivo para tal función. Proyecto Red IP/MPLS ARSAT SA Página 48 de 69

49 FUNCIONALIDADES Asociación entre funcionalidades e interface Indicar para cada interfaz descripta en el punto anterior las funcionalidades de gestión asociadas. Completar la siguiente tabla. Grupo de tareas SNMP Telnet SSH/ TFTP/ Radius/ Otras SFTP FTP Tacacs+ Fallas a) Envío de alarmas en forma espontánea b) Visualización remota del status del sistema c) Visualización del histórico de alarmas presente en el equipo Configuración d) Configuración de las VPN-MPLS e) Configuración del servicio VPDN f) Configuración de parámetros de QoS g) Configuración de umbrales (para funcionalidad de alarmas y performance) h) Carga remota de software, firmware y configuraciones Performance i) Recolección de parámetros de performance j) Configuración y recolección de resultados de tests Accounting k) Recolección de reportes de utilización de puertas Seguridad l) Control de Accesos Inventario de Elementos m) Recolección de datos de inventario Fallas a. Deberá contar con mecanismos para el envío de eventos/mensajes espontáneos de alarmas (ej. traps SNMP) mediante una interfaz SNMP y/o SysLog. Se deberá entregar la descipción de cada uno de ellos (incluyendo la descripción de cada trap SNMP soportado) [O]. b. El oferente deberá indicar la cantidad máxima de destinos a los que un trap SNMP puede ser enviado en forma simultánea. c. El oferente deberá indicar la posibilidad de configurar distintos destinos para el envío de traps SNMP por grupo de alarmas/eventos. d. El oferente deberá indicar la existencia de un mensaje de cese/fin de alarma para cada tipo de alarma existente en el equipo. e. Se deberán detallar los diferentes tipos de alarmas indicados (ej. equipamiento, comunicación, entorno, procesamiento, QoS, etc.). Deberá entregar una lista con la descripción de todas las alarmas/eventos enviados por el Network Element. f. El oferente deberá detallar el formato de alarma utilizado, detallando las especificaciones particulares del proveedor. El mismo deberá incluir como mínimo la siguiente información: Id_Alarma, Id_Origen, Proyecto Red IP/MPLS ARSAT SA Página 49 de 69

50 Modulo-Sub_Modulo, Fecha_Inicio/Fin, Hora_Inicio/Fin, Gravedad_Evento, Descripción_Evento. [O] g. El oferente deberá indicar los mecanismos de pruebas remotas soportados por el equipo. Detallar estos mecanismos describiendo las interfaces de testing habilitadas para estas funcionalidades Configuración a. Cada una de las funciones existente dentro del equipo deberán poder ser configuradas en forma remota [O]. Detallar los mecanismos e interfaces para cumplir con dicha funcionalidad. b. El equipo deberá disponer de un mecanismo de activación/desactivación de componentes (placas, ports). c. El equipo debe proveer la posibilidad de realizar download y upload en forma remota de nuevas versiones de software y configuraciones [O]. d. Deberá detallar el impacto en el equipo al ejecutar un cambio de software. Detallar el proceso. e. Deberá contar con mecanismos de configuración de direcciones (interfaces y loopback). Indicar los mecanismos utilizados en la gestión de los pools de direcciones. f. El oferente deberá detallar los mecanismos implementados para la configuración de las funcionalidades requeridas Performance a. El equipo propuesto debe poseer MIBS SNMP que permitan la medición de los parámetros de Performance de los mismos [O]. b. Como mínimo deberán poder monitorearse los siguientes parámetros: i. CPU ii. Memoria iii. Trafico entrante y saliente por interfaz/sub-interfaz ( expresada en bits y en paquetes) iv. Errores por interfaz/sub-interfaz v. QoS / CoS descriptas en el punto Clase de Servicio y Calidad de Servicio de esta RFP ( indicando los bytes /paquetes que pasan por las mismas y los bytes / paquetes descartados) c. El oferente deberá poner a disposición, de todas las MIBs de los equipos ofertados. [O]. d. Adicionalmente el oferente deberá detallar todas las mediciones de performance realizadas por el equipo que complementen a las solicitadas en el punto b. (indicando las variables de la MIB relativas a la performance). e. El equipo debe contar con un mecanismo de configuración de umbrales de activación/generación de alarmas de performance. El oferente deberá describir los mecanismos soportados. f. El oferente deberá indicar si el equipo permite la realización de mediciones de performance (latencia, disponibilidad, tasa de error) entre nodos de la red. Proyecto Red IP/MPLS ARSAT SA Página 50 de 69

51 Contabilización (accounting) El equipo debe contar con un mecanismo de generación y almacenamiento de los datos de uso de los recursos de los elementos de red (discriminando por interfaz física, protocolo, dirección IP, etc.) Seguridad a. El equipo deberá contar con la posibilidad de definir distintos perfiles de usuarios. b. El oferente deberá detallar los mecanismos implementados para la definición de perfiles. Como mínimo deberán existir tres niveles: observador, operador y administrador. c. El acceso al elemento de red deberá realizarse mediante el ingreso de un nombre de usuario y de un password. [O] d. El oferente deberá detallar la capacidad de generar alarmas de seguridad (accesos exitosos, intentos fallidos de login, etc.) al sistema de gestión. e. El oferente deberá detallar la capacidad de almacenar en un log local los accesos y los comandos efectuados sobre el equipo (auditoria de seguridad). f. El equipo deberá permitir la configuración de la base de usuarios en forma remota mediante el empleo del protocolo TACACS o Radius. Indicar el/los protocolos soportados. g. El equipo deberá permitir restringir el logeo múltiple de un mismo usuario. h. Debe asegurar las reglas de construcción de password de usuario acordes al nivel de seguridad solicitado. Por ejemplo, password del tipo alfanumérico y de longitud mayor o igual a 10 caracteres Inventario de Elementos a. Se deberá indicar si el equipo posee la funcionalidad de inventario de recursos físicos y lógicos del propio elemento. [O] b. Para los recursos físicos (elementos de hardware) el equipo deberá registrar la existencia de cada módulo individual, respetando los niveles de agregación propios de la arquitectura del elemento de red, p. ej. bastidor, sub-bastidor, placa, módulo, etc. c. El sistema debe reflejar las versiones de hardware para cada módulo individual. d. El sistema debe reflejar las versiones de firmware y software para cada módulo individual. Detallar los casos en que aplica Proyecto Red IP/MPLS ARSAT SA Página 51 de 69

52 Administración de Software a. El oferente deberá describir las funcionalidades de administración de software implementadas en el elemento de red. [O] b. El oferente deberá indicar si el equipo cuenta con la posibilidad de mantener dos o más versiones de software residentes en el equipo con el objetivo de permitir el cambio de versiones. [O] c. El oferente deberá describir el procedimiento de cambio de versión de software y firmware Registros (Logs) a. El equipo deberá contar con distintos Registros que permitan soportar información correspondiente a la gestión de comandos, de fallas, de acceso y de seguridad del sistema completo. [O] b. Indicar el tipo de estructura implementada para cada tipo de Registro y tamaños máximos. c. El equipo deberá disponer de una administración automática de los Registros Copia de respaldo (Backup) / Restauración (Restore) a. El Equipo de deberá permitir la realización de copia de respaldo y restauración de los datos de configuración, de fallas y de performance que se encuentran almacenados en el mismo. [O] b. El oferente deberá detallar los procedimientos de restauración de la información en caso de pérdida de datos. c. El oferente deberá indicar si el equipo dispone de la posibilidad de manejar backups automatizados Proyecto Red IP/MPLS ARSAT SA Página 52 de 69

53 Roadmap gestión a. El oferente detallará el roadmap respecto a las capacidades de gestión provistas por el equipo [O], en cuanto a: b. Interfaces c. Funcionalidades / servicios d. Escalabilidad e. Indicando en cada caso el grado de compromiso con las fechas establecidas (por ejemplo: comprometido, propuesto, conceptual, etc.). En todos los casos se deberá indicar fechas de disponibilidad comercial Roadmap equipamiento Para la respuesta al presente ítem, considerar como Roadmap, a todos aquellos atributos futuros del equipamiento como consecuencia de su evolución. Los atributos actuales, deberán responderse en los puntos correspondientes de la especificación. El oferente detallará el roadmap del producto en el periodo [O] en cuanto a: a. Interfaces b. Funcionalidades / servicios c. Escalabilidad Para cada caso, indicar las fechas de disponibilidad comercial, como así también su grado de compromiso (propuesto, comprometido, etc) 7. VALORES MINIMOS DE FUNCIONALIDADES BÁSICAS POR TIPO DE NODO ACCESO [O] En el Anexo III del PET Parámetros mínimos del Equipamiento de Acceso se especifican los valores y condiciones mínimas requeridas tanto a nivel de hardware como de software. Se deberán tener en cuenta para la definición del equipamiento ofertado. Proyecto Red IP/MPLS ARSAT SA Página 53 de 69

54 7.1. OBJETO REQUERIDO TOPOLOGIA DE REFERENCIA Basado en el esquema de la figura 1,se muestra dónde y cómo se localiza el equipo AN dentro de la arquitectura general a usarse. Se deberá tomar como referencia de tal manera de proveer las funcionalidades requeridas. Tanto para el AN tipo 1 como para el AN tipo 2 la provisión del servicio se brindara en sus interfaces UNI y transportaran el mismo hacia el Nodo de Servicio (Servicios L2 y Servicios L3) en este caso referenciado como npe (Network PE) DESCRIPCION TECNICA DEL OBJETO REQUERIDO A continuación se describen los dos modelos de AN requeridos desde el punto de vista de funcionalidades de software y hardware como asi también los valores de escalabilidad solicitados. Es deseable que ambos modelos de equipos sean de la misma familia de producto Nodo de Acceso Tipo 1 - AN Requerimientos de Hardware Fig 3: Modelo de AN1 ( Hard y Soft Integrado) Chasis Cantidad de slots = 4 Carrier Class: Fuentes, Procesadoras, Swichts Fabrics, Ventiladores redundantes. Interfaces UNI Interfaces 40 x 1 GE - Colas = 32K Entrada/Salida Interfaces 8 x 10GE (Sobresubscripta) - Colas = 32K Entrada/Salida Proyecto Red IP/MPLS ARSAT SA Página 54 de 69

55 Nota: Dependiendo de la tarjeta de línea ofertada, se deberá considerar la relación que por cada 10 puertos físicos,7 ópticas deberán ser Giga Ethernet (10KM alcance) y 3 FastEthernet (2km alcance). Interfaces NNI Interface 1 x 100GE* - Colas = 256 Interface 8 x 10GE - Colas = 256 Entrada/Salida GE: Ópticas SFP; 10GE: Ópticas XFP o SPF+**.Fibra Óptica: Monomodo * En roadmap. (Deseable) ** Ver Anexo II del PET Lista de Sitios a Servir, para la distancia entre nodos. Capacidad de Conmutación por slot 60G (Full Duplex), Capacidad de Conmutación por Chasis = 480G Otros Parámetros Vlans = 4094 ( 802.1q o 802.1ad). OAM El equipamiento deberá poseer un mecanismo de OAM para detección temprana de fallas y poder disparar los mecanismos de restauración ( IGP o EGP ). Sesiones BFD = 256@ 50 ms QoS El equipamiento en sentido saliente, para asegurar un correcto distribución de BW deberá controlar el tráfico hacia el acceso con un mecanismo de Policing / Shaping ( H-QoS) permitiendo la distinción de flujos basado en S-VLAN / C-VLAN /Clase de servicio. Se deberán poder definir por servicio provisionado hasta 5 diferentes clases de servicios cada una con su valor de 802.1p. y la configuración de los parámetros de CIR*,EIR* y EBS* con valores definibles desde 512bits/s a 10Gbits/s y granularidad de 256kbits/s. (* : MEF 10.1 punto ). El equipamiento en sentido entrante, para una correcta clasificación del tráfico deberá poder distinguir en el caso de interfaces Ethernet, frames (untagged), frames 802.1q y frames 802.3ad (doble dot1q).en base esta clasificación se deberán poder encapsular en MPLS, para su conexión a un PWE (Eline Service), a una VPLS (E-LAN Service) y una VRF ( L3VPN Service). Timing El equipamiento deberá soportar el transporte y regeneración de sincronismo basado en IEEE 1588v2, el equipamiento deberá ser Hardware Ready IEEE 1588 v2 para poder corregir el tiempo de estadía de los paquetes de sincronismo (Modo Transparent Clock) y/o poder regenerar y proveer sincronismo como un master clock ( Modo Boundary Clock). En el caso de trabajar en modo BC deberá poder soportar como mínimo 10 clientes OC via interfaces Ethernet. Para los dos casos se Proyecto Red IP/MPLS ARSAT SA Página 55 de 69

56 deberá considerar que el Master Clock puede ser de otro proveedor pero de acuerdo al estándar IEEE 1588v2.A continuación se muestran los dos escenarios de como trabajara el AN. Fig 4: Corrección y Distribución de Sincronismo Requerimientos de Software Infraestructura IGP: OSPFv2 /IS-IS El equipamiento deberá poseer un mecanismo de Loop Free Alternate basado RFC 5286, para permitir tener predefinido un camino backup ante falla y lograr tiempos de convergencia más bajos, comparado a equipamiento sin esta funcionalidad. LDP: LDP Downstream on Demand. LDP Downstream Unsolicited. Según RFC El equipamiento deberá poseer estos dos mecanismos de distribución de etiquetas, pudiéndose conectar contra el acceso con equipos de acceso más simples con LDP DoD y con equipo de core usando LDP DU. BGP: BGP Carrying Labeled - basado en RFC 3107 El equipamiento deberá poseer este mecanismo para lograr la jerarquización de LSP al estar la red dividida en distintos dominios de operación y poder desplegar servicios entre los diferentes dominios. Cant. Prefijos IPv4 + BGP (T. Global) = 1M. BGP-PIC: El equipamiento deberá poseer un mecanismo de rápida convergencia de BGP. L2VPN - Emulación de PWE Ethernet - según RFC 4448 Cant. PWE = 4000 (Raw y Tagged Mode) Cant. PWE(Redundante) = 2000 (Raw y Tagged Mode) Emulación de VPLS (Unqualified Mode) - según RFC 4762 Cant. VPLS = 2000 ; Cant. AC Chasis = 6000 Proyecto Red IP/MPLS ARSAT SA Página 56 de 69

57 Cant. MAC Chasis = 256k Learn. Rate: Macs/ seg. El equipamiento deberá poseer los dos mecanismo anteriores de tal manera de poder proveer los servicios E-Line, E-LAN según lo especificado en el Metro Ethernet Fórum (MEF 6.1). L3VPN - Emulación de VPN4 - según RFC Cant. VPN = 1000 Cant. Rutas VPNv4 = 500 x VRF Cantidad de Interfaces IP = Nodo de Acceso Tipo 2 - AN Requerimientos de Hardware Fig 5: Modelo de AN2 ( Hard y Soft Integrado) Chasis Cantidad de slots = 2 Para nodos subtendidos Cantidad de slots = 3 Para nodos colocalizados con DWDM Carrier Class: Fuentes, Procesadoras, Swichts Fabrics, Ventiladores redundantes. Interfaces: Interfaces UNI Interfaces 10 x 1 GE/FE - Colas = 32K Entrada/Salida x tarjeta Proyecto Red IP/MPLS ARSAT SA Página 57 de 69

58 Interfaces 20 x 1 GE/FE - Colas = 32K Entrada/Salida x tarjeta Interfaces Interfaces x tarjeta Interfaces x tarjeta 2 x 10GE (Sobresubscripta) - Colas = 32K Entrada/Salida x tarjeta 1 x10ge (Sobresubscripta)+ 5 x 1GE/FE - Colas = 32K Entrada/Salida 2 x10ge (Sobresubscripta)+ 5 x 1GE/FE - Colas = 32K Entrada/Salida GE: Ópticas SFP (LX); FE: Óptico; 10GE: Ópticas XFP o SFP+ (LX o ZX)* *Ver Anexo II del PET Lista de Sitios a Servir, para la distancia entre nodos. Nota: Dependiendo de la tarjeta de línea ofertada, se deberá considerar la relación que por cada 10 puertos físicos,7 ópticas deberán ser Giga Ethernet (10km alcance) y 3 FastEthernet (2km alcance). Interfaces NNI Interface 4 x 10GE - Colas = 256 Interface 2 x 10GE - Colas = 256 GE: Ópticas SFP (LX); FE: Óptico; 10GE: Ópticas XFP o SFP+ (LX o ZX)* *Ver Anexo II del PET Lista de Sitios a Servir, para la distancia entre nodos. Fibra Óptica a usar: monomodo. Capacidad de Conmutación 20G (Full Dúplex) por Slot, Capacidad de Conmutación por Chasis = 80G Otros Parámetros Vlans = 4094 ( 802.1q o 802.1ad). OAM El equipamiento deberá poseer un mecanismo de OAM para detección temprana de fallas y poder disparar los mecanismos de restauración ( IGP o EGP ). Sesiones BFD = 50@ 50 ms QoS El equipamiento en sentido saliente, para asegurar un correcto distribución de BW deberá controlar el tráfico hacia el acceso con un mecanismo de Policing / Shaping ( H-QoS) permitiendo la distinción de flujos basado en S-VLAN / C-VLAN /Clase de servicio. Se deberán poder definir por servicio provisionado hasta 5 diferentes clases de servicios cada una con su valor de 802.1p. y la configuración de los parámetros de CIR*,EIR* y EBS* con valores definibles desde 512kbits/s a 10Gbits/s y granularidad de 256kbits/s. (* : MEF 10.1 punto ). Proyecto Red IP/MPLS ARSAT SA Página 58 de 69

59 El equipamiento en sentido entrante, para una correcta clasificación del tráfico deberá poder distinguir en el caso de interfaces Ethernet, frames (untagged), frames 802.1q y frames 802.3ad (doble dot1q).en base esta clasificación se deberán poder encapsular en MPLS, para su conexión a un PWE (Eline Service), a una VPLS (E-LAN Service) y una VRF ( L3VPN Service). Timming El equipamiento deberá soportar el transporte y regeneración de sincronismo basado en IEEE 1588v2, el equipamiento deberá ser Hardware Ready IEEE 1588 v2 para poder corregir el tiempo de estadía de los paquetes de sincronismo (Modo Transparent Clock) y/o poder regenerar y proveer sincronismo como un master clock ( Modo Boundary Clock). En el caso de trabajar en modo BC deberá poder soportar como mínimo 5 clientes OC via interfaces Ethernet. Para los dos casos se deberá considerar que el Master Clock puede ser de otro proveedor pero de acuerdo al estándar IEEE 1588v2.A continuación se muestran los dos escenarios de como trabajara el AN. Fig 6: Corrección y Distribución de Sincronismo Requerimientos de Software Infraestructura IGP: OSPFv2 /IS-IS El equipamiento deberá poseer un mecanismo de Loop Free Alternate basado RFC 5286, para permitir tener predefinido un camino backup ante falla y lograr tiempos de convergencia más bajos, comparado a equipamiento sin esta funcionalidad. LDP: LDP Downstream on Demand. LDP Downstream Unsolicited.Según RFC El equipamiento deberá poseer estos dos mecanismos de distribución de etiquetas, pudiéndose conectar contra el acceso con equipos de acceso más simples con LDP DoD y con equipo de core usando LDP DU. BGP: BGP Carrying Labeled - basado en RFC 3107 El equipamiento deberá poseer este mecanismo para lograr la jerarquización de LSP al estar la red dividida en distintos dominios de operación y poder desplegar servicios entre los diferentes dominios. Proyecto Red IP/MPLS ARSAT SA Página 59 de 69

60 Cant. Prefijos IPv4 + BGP (T. Global) = 200k. BGP-PIC: El equipamiento deberá poseer un mecanismo de rápida convergencia de BGP. L2VPN - Emulación de PWE Ethernet - según RFC 4448 Cant. PWE = 512 (Raw y Tagged Mode) Cant. PWE(Redundante) = 256 (Raw y Tagged Mode) Emulación de VPLS (Unqualified Mode) - según RFC 4762 Cant. VPLS = 256 ; Cant. AC Chasis = 800 Cant. MAC Chasis = 64k Learn. Rate: 2000 Macs/ seg. El equipamiento deberá poseer los dos mecanismo anteriores de tal manera de poder proveer los servicios E-Line, E-LAN según lo especificado en el Metro Ethernet Fórum (MEF 6.1). L3VPN - Emulación de VPN4 - según RFC Cant. VPN = 500 Cant. Rutas VPNv4 = 200 x VRF Cantidad de Interfaces IP = 500 x chasis CANTIDAD DE EQUIPOS El oferente deberá tener en cuenta para la cotización del equipamiento, la información brindada a continuación, como así también la información brindada en el Anexo II del PET Lista de sitios a servir por tramos. Proyecto Red IP/MPLS ARSAT SA Página 60 de 69

61 TRAMO TRAMO TRAMO MAQUETA El oferente deberá considerar incluir en el equipamiento de maqueta todos los modelos propuestos y sus tarjetas, de tal manera que la maqueta pueda representar una topología usada en la red en producción. Proyecto Red IP/MPLS ARSAT SA Página 61 de 69

62 Se deberá cotizar también para el caso de maqueta, los diferentes tipos de placas con interfaces E1 y STM PROVISION DE RACKS El proveedor al momento de la instalación deberá incluir el rack para el soporte de AN tipo 1 (AN1) y AN tipo 2 (AN2). El rack deberá ser del tipo ETSI de 19 y las unidades de rack de alto deberán ser acorde al equipo propuesto. Se deberá considerar que el rack se instalara en un shelter o en un edificio ARSAT. Proyecto Red IP/MPLS ARSAT SA Página 62 de 69

63 TOPOLOGIA Y SITIOS DE DESPLIEGUE Tramo I Fig. 7 Tramo I Fig. 8 Proyecto Red IP/MPLS ARSAT SA Página 63 de 69

64 Tramo II Fig. 9 Tramo III Fig SUMINISTRO Y SERVICIOS [O] A los efectos de la presentación de la propuesta, la misma deberá considerar a los equipos, elementos, materiales principales, y servicios que se detallan a Proyecto Red IP/MPLS ARSAT SA Página 64 de 69