EMPRESA ARGENTINA DE SOLUCIONES SATELITALES S.A. ARSAT CONCURSO PRIVADO Nº 12/2014. Generador de Trafico y Emulador de Protocolos

Transcripción

1 EMPRESA ARGENTINA DE SOLUCIONES SATELITALES S.A. ARSAT CONCURSO PRIVADO Nº 12/2014 Generador de Trafico y Emulador de Protocolos PLIEGO DE ESPECIFICACIONES TÉCNICAS 1

2 Contenido 1 OBJETIVO ALCANCE DE LA PROPUESTA REQUISITOS Y ESPECIFICACIONES TÉCNICAS INTERFACES de LAN IEEE 802.3u 100Mbps (fastethernet) IEEE 802.3z 1000Mbps (Gigabit Ethernet) IEEE 802.3ae 10Gbps (10 Gigabit Ethernet) IEEE 802.3ba 100Gbps (100 Gigabit Ethernet) FUNCIONALIDADES Layer 2 - General Vlan tagging IEEE 802.3ac Trunking IEEE 802.1Q Vlan Stacking (QinQ) IEEE 802.1ad Layer 2 ETHERNET Performance & Stress Ethernet Interfaces at full line rate Traffic Interface Stress IP Packet Delay Variation Metric Ethernet BERT Test L2 performance IPv4/6 Análisis and Performance IPv4 Análisis IPv6 Análisis Ipv4 Performance Ipv6 Performance ROUTING Requisitos generales OSPF BGPv MPLS Functionality & Performance Introducción Requerimientos MPLS Traffic Engineering Introducción Requerimientos MPLS Virtual Private Networks Layer 3 BGP-MPLS VPN BGP-MPLS VPN Setup BGP-MPLS VPN Scalability Layer 2 MPLS VPN CALIDAD DE SERVICIO Introducción Requerimientos generales para verificar capacidades de QoS de un router Traffic Emulation Usuarios

3 4.10 Exportación de datos/resultados/gráficos Chasis del GAM Hot-swappable Acceso remoto multiusuario Soporte de interfaces Soporte de daisy-chain Tipo de placas de 1Gbps Tipo de placas de 10Gbps Tipo de placas de 100Gbps Tipo de chassis REQUISITOS GENERALES Instalación del equipamiento Acondicionamiento para Provisión de entrega Documentación Documentación Técnica Manuales de Instalación y Configuración Manuales de Capacitación Inspección de Recepción Pruebas de Certificación Técnica Evolución Técnica del instrumento ofertado Roadmap Actualizaciones de Software y Hardware Garantía Técnica Antecedentes y Recursos Técnicos CAPACITACIÓN ANEXOS DE LA ESPECIFICACIÓN TÉCNICA Planillas de Cotización

4 1 OBJETIVO El presente documento tiene como finalidad establecer los requisitos mínimos que deben satisfacer los instrumentos y/o placas de medición acerca de parámetros específicos de protocolos y tecnologías utilizadas en redes empleadas por ARSAT. La presente Especificación Técnica deberá cubrir las funcionalidades de Generador, Analizador, y Emulador de protocolos y tráfico para redes de datos según se detalla en los puntos 3 y 4 del presente documento. 2 ALCANCE DE LA PROPUESTA El oferente deberá presentar una oferta que contemple el siguiente hardware: o o o 1 Chasis de 8 slots mínimo. 4 interfaces de 10GE, con soporte de ópticas SFP+,SM. 8 interfaces de 1 GE duales, Eléctricas-RJ45/Ópticas-SFP-SM). En cuanto al licenciamiento el mismo deberá contemplar las siguientes licencias de usuarios y de emulación de protocolos: o Operación Licencias para 5 usuarios simultáneas para generación y análisis de tráfico. o Emulación de Protocolos IGP/EGP OSPFv2 y OSPFv3 ISISv4 y OSPFv6 LDP y RSVP-Te BGPv4 Servicios L2 PWE VPLS-BGP VPLS-LDP Servicios L3 L3VPN IPv6 6PE 6VPE OAM BFD Multicast PIM IGMPv2/IGMPv3 Link Bundle LACP 4

5 3 REQUISITOS Y ESPECIFICACIONES TÉCNICAS Se establecen a continuación los diversos requisitos que deben cumplir las partes ofertadas. Cada requisito solicitado deberá responderse punto a punto por el OFERENTE. Se aceptarán únicamente respuestas del tipo CUMPLE, NO CUMPLE. En caso de contestar con CUMPLE, se DEBE justificar la respuesta. Los ítems indicados con la letra [O] son obligatorios, por lo tanto el no cumplimiento implica eliminación de la oferta. El resto de los ítems son opcionales y serán calificados por ARSAT. 3.1 INTERFACES de LAN Las placas deben soportar los siguientes tipos de interfaz de LAN Ethernet. Para cada una de estas interfaces se considerara la provisión de: a) Estadísticas y alarmas.[o] b) Generación de tráfico wire-speed. [O] c) Conformidad con los estándares mencionados. [O] IEEE 802.3u 100Mbps (fastethernet) La placa debe soportar la interfaz Fast Ethernet: IEEE 802.3, 100BASE-TX, y 100BASE-FX. [O] IEEE 802.3z 1000Mbps (Gigabit Ethernet) La placa debe soportar la interfaz Gigabit Ethernet IEEE 802.3z y los siguientes Gigabit Interface Converter (GBIC) o conector eléctrico especificado: SFP 1000BASE-SX, 850nm laser on multi mode fiber. [O] SFP 1000BASE-LX, 1300nm laser on single mode and multi-mode fiber. [O] SFP 1000BASE-ZX, 1550nm laser on single mode fiber. [O] IEEE 802.3ae 10Gbps (10 Gigabit Ethernet) La placa debe soportar la interfaz (IEEE 802.3ae 10Gbps) con los siguientes SFP+ o XFP: GBASE-SR/SW, 850nm laser on multi-mode fiber. [O] GBASE-LR/LW, 1300nm laser on single mode and multi-mode fiber. [O] GBASE-ER/EW, 1550nm laser on single mode fiber. [O] IEEE 802.3ba 100Gbps (100 Gigabit Ethernet) La placa debe soportar la interfaz (IEEE 802.3ab 100 Gbps) con los siguientes CFP: 5

6 GBASE-SR, 850nm laser on multi-mode fiber GBASE-LR, 1300nm laser on single mode and single-mode fiber. 6

7 4 FUNCIONALIDADES 4.1 Layer 2 - General Vlan tagging IEEE 802.3ac Las placas deben soportar la funcionalidad de vlan tagging de acuerdo con el estándar IEEE 802.3ac, donde se especifica el formato de trama extendido para soportar Vlans (Virtual Local Área Networks). [O] Trunking IEEE 802.1Q Las placas deben soportar la funcionalidad de trunking según lo especificado en IEEE 802.1Q. [O] Vlan Stacking (QinQ) IEEE 802.1ad Las placas deben ser capaces de generar tráfico a través de tramas IEEE 802.1ad con dos o más etiquetas (tags) de VLAN. [O] 4.2 Layer 2 ETHERNET Performance & Stress Ethernet Interfaces at full line rate Las placas deben ser capaces de realizar mediciones de throughput, latency y frame-loss at full line rate según las RFC 2544 y RFC 1242 sobre las interfaces indicadas en el punto 3.1 (Interfaces de LAN) del presente documento ya sea utilizando cobre o fibra óptica. [O] Traffic Interface Stress Las placas deben ser capaces de generar y recibir tráfico en simultaneo al 100% de velocidad de línea (wire speed) en todas sus interfaces 10/100/1000Base-T, 1000Base-X, 10GBase-X en redes full-dúplex y con todos los tamaños de paquetes definidos en RFC [O] IP Packet Delay Variation Metric Las placas deben ser capaces de medir jitter (IP Packet Delay Variation según RFC 3393), para determinar la capacidad de transporte de redes ethernet para transmitir tráfico sensible al retardo (Ej: VoIP). [O] Ethernet BERT Test Indicar el soporte de la funcionalidad de Bit Error Rate Test (BERT) para interfaces definidas en el punto 3.1 (Interfaces de LAN) del presente documento. [O] L2 performance Las placas deben poder cuantificar la performance de dispositivos de conmutación en L2 ethernet de acuerdo con los estándares RFC 2889 y RFC 2285, (donde se definen métodos confiables y repetitivos) para evaluar la performance de dispositivos con interfaces indicadas en el punto 3.1 (Interfaces de LAN) del presente documento. A continuación se especifican cada uno de los procedimientos de medida expuestos en las RFC 2889 y RFC 2285, y se solicita lograr indicar la configuración de hardware y software necesarios para el instrumento de medición para llevar a cabo cada una de las siguientes mediciones: 7

8 Fully meshed throughput, frame loss and forwarding rate [O] Sobre una topología de tráfico del tipo full mesh, como es definido en la RFC 2889 sección 5.1, Las placas deben determinar: a) El rendimiento de envío de tramas del DUT/SUT* b) Perdida de paquetes de envío de tramas del DUT/SUT* c) Tasa máxima de envío de tramas del DUT/SUT * *DUT: Device Under Test *SUT: System Under Test Partially meshed one-to-many/many-to-one [O] Las placas deben ser capaces de determinar el rendimiento del DUT cuando se transmiten tramas desde un puerto hacia varios otros puertos o viceversa. Se debe obtener como medición la capacidad de conmutar tramas del dispositivo en tramas por segundo. Los distintos tamaños de tramas a utilizar están definidos en la RFC 2889 sección Partially meshed multiple devices [O] Las placas deben ser capaces de medir el rendimiento, perdida de paquetes y tasa de envío de tramas de dispositivos con múltiples puertos y conectados entre sí a través de un enlace de alta velocidad. Los parámetros a medir son frames per second y tasa de transferencia (throughput) de acuerdo con la recomendación de la RFC 2889 sección Partially meshed unidirectional traffic [O] Las placas deben ser capaces de determinar el rendimiento del DUT/SUT cuando múltiples flujos de datos unidireccionales se reciben por algunos puertos del DUT/SUT y son enviados por otros puertos al instrumento generador de tráfico. Los parámetros a medir son tasa de envío de frames per second (tramas/segundo) y throughput (tasa de transferencia) para cada uno de los tamaños de trama recomendados en la RFC 2889 sección Forward Pressure and Maximum Forwarding Rate [O] Las placas deben soportar la realización de las pruebas detalladas a continuación de acuerdo a las recomendaciones de la RFC 2889 sección 5.6: a) Forward Pressure* b) Maximum forwading rate* *Nota: Forward Pressure: para realizar esta prueba se satura al dispositivo enviándole tráfico a una velocidad mayor que la soportada por la interfaz, con un retardo entre tramas inferior al equivalente de 96 bits. Se debe asegurar que el DUT en el puerto de salida transmita apropiadamente según el estándar IEEE con un retardo entre tramas superior a los 96 bits mencionados. Maximum forwading rate: se mide de la misma manera que en el punto 5.1 de este documento (RFC2889), pero partiendo de los valores hallados en el mismo. 4.3 IPv4/6 Análisis and Performance 8

9 El objetivo de las pruebas siguientes acerca del Internet Protocol en su versión 4 (IPv4) y en su versión 6 (Ipv6) tienen como finalidad verificar la performance de los DUT evaluando su rendimiento y latencia para varios perfiles de tráfico IPv4 Análisis Las placas deben poder generar grandes volúmenes de trafico IP a través de todas las interfaces enumeradas en los puntos 3.1 del presente documento, y proveer capacidades de análisis mediante su captura, decodificación y posterior análisis de los datos obtenidos. Las herramientas con que dispongan las placas deben habilitar al instrumento para realizar: Captura y análisis de datos online. [O] Estadísticas en tiempo real. [O] Captura y análisis de datos offline. [O] Presentación de datos decodificados. [O] Filtrado y búsqueda de datos capturados [O] Presentación gráfica de flujos medidos on line en función del tiempo. [O] IPv6 Análisis Las placas deben poder generar grandes volúmenes de trafico IP a través de todas las interfaces enumeradas en los puntos 3.1 del presente documento, y proveer capacidades de análisis mediante su captura, decodificación y posterior análisis de los datos obtenidos. Las herramientas con que dispongan las placas deben habilitar al instrumento para realizar: Captura y análisis de datos online. [O] Estadísticas en tiempo real. [O] Captura y análisis de datos offline. [O] Presentación de datos decodificados. [O] Filtrado y búsqueda de datos capturados. [O] Presentación gráfica de flujos medidos on line en función del tiempo. [O] Ipv4 Performance Las placas deben ser capaces de generar tráfico a nivel IP desde cualquiera de las interfaces enunciadas en los puntos 3.1 (Ethernet) del presente documento, generando múltiples flujos desde distintas redes simuladas. Las características de QoS deben ser analizadas en múltiples flujos en tiempo real para determinar la performance de Gigabit o Terabit routers. Algunas de las cualidades con que debe contar el instrumento son: 9

10 Simulación de tráfico a gran escala, pudiendo simular escenarios de tráfico similares al de Internet Generación de múltiples flujos de tráfico UDP/TCP simultáneos. [O] Generación de patrones de tráfico simple, parcial y full-mesh. [O] Mediciones en tiempo real de throughput, latencia y packet loss por flujo. [O] Programas de aplicación para la creación de escenarios de prueba configurables por el usuario. [O] Ipv6 Performance Las placas deben ser capaces de generar tráfico a nivel IP desde cualquiera de las interfaces enunciadas en los puntos 3.1 (Ethernet) del presente documento, generando múltiples flujos desde distintas redes simuladas. Las características de QoS deben ser analizadas en múltiples flujos en tiempo real para determinar la performance de Gigabit o Terabit routers. Algunas de las cualidades con que debe contar el instrumento son: Simulación de tráfico a gran escala, pudiendo simular escenarios de tráfico similares al de Internet. [O] Generación de múltiples flujos de tráfico UDP/TCP simultáneos. [O] Generación de patrones de tráfico simple, parcial y full-mesh. [O] Mediciones en tiempo real de throughput, latencia y packet loss por flujo. [O] Programas de aplicación para la creación de escenarios de prueba configurables por el usuario. [O] 4.4 ROUTING Requisitos generales Requisitos generales que deben cumplir las placas/puertos para el empleo de protocolos de ruteo: a) Generar tráfico wire-speed. [O] b) Emular protocolos. [O] c) Medir desempeño y compararlo en tiempo real. [O] d) Que las placas/interfaces sean hotswap para evitar la necesidad de relanzar (rebooting) y reconfigurar el equipo. [O] e) Poder anunciar prefijos de redes (network prefixes) en BGP como ser AS, comunidad, local preference, weight, MED, etc. [O] f) Que posea mecanismo que automatice la configuración de varios prefijos de red. [O] g) Generar paquetes IP, pertenecientes a las redes anunciadas. [O] h) Enviar tráfico en una configuración full meshed, Ej: Enviar desde una Interfaz del instrumento trafico cuyo destino son redes anunciadas por otra interfaz del instrumento, y que esta Interfaz mida parámetros como Packet Loss, Delay, Jitter, etc. del trafico recibido que corresponde al enviado por la primera interfaz. [O] 10

11 i) Capacidad de monitoreo de la actividad en los protocolos OSPFv2, OSPFv3, IS- ISv4,IS-ISv6,BGP-4, LDP, etc. concurrentemente. [O] OSPF A continuación se enumeran algunas de las pruebas que deben realizar las placas para el protocolo de ruteo OSPF. Para cada una de ellas se solicita: OSPF Adjacency Scalability Esta prueba encuentra el número máximo de routers OSPF con el cual el DUT puede establecer adyacencia total. [O] Maximum OSPF LSAs Learned Esta prueba encuentra el número máximo de entradas a la base de datos topológica de OSPF que un DUT puede adicionar antes que el Link Information contenido en los paquetes de link-state advertisements (LSAs) deje de aprenderse. De esta manera queda determinado el numero de LSA s que el DUT puede aprender. [O] OSPF LSA Initial Convergence Esta prueba mide el tiempo que le toma a un DUT para enviar tráfico de nuevas rutas después de recibir y procesar los link-state advertisements (LSA s) en su base de datos topológica. [O] Emulación OSPF: LSAs Las placas deben soportar de las siguientes características: a) Tipo 1, 2,3,4,5 y 7. [O] b) Router Network, Summary 3, Summary 4, AS-External, Typo 7 (NSSA). [O] c) Tipo 9 a 11. [O] d) Opaque link Local, Opaque Area Local, Opaque AS Wide. [O] Emulación OSPF: Tipos de Router Las placas deben soportar de las siguientes características: a) Inter-Area Routers. [O] b) Area Bourder Routers. [O] c) AS Border Routers. [O] Emulación OSPF: Tipos de Redes Las placas deben soportar de las siguientes características: a) Point-to-Point. [O] b) Point-to-Multipoint. [O] c) Broadcast. [O] d) NMBA. [O] Emulación OSPF: Mensajes Las placas deben soportar de las siguientes características: 11

12 a) Hello. [O] b) Database Description. [O] c) Link State Request. [O] d) Link State Update. [O] e) Link State Acknowledgement. [O] Interfaces OSPF La emulación del protocolo de ruteo OSPFv2 y OSPFv3 deberá estar disponible para las interfaces indicadas puntos 2.1 del presente documento. [O] BGPv4 A continuación se enumeran algunas de las pruebas que debe realizar el instrumento/placas/puertos para el protocolo de ruteo BGP. Para cada una de ellas se solicita: BGP-4 Conformance Tests Las placas/puertos deben verificar la conformidad del DUT respecto a los estándares del protocolo de enrutamiento BGP-4. Los mensajes de formato del DUT/SUT y su comportamiento en cuanto al enrutamiento deben ser examinados para verificar su conformidad con el estándar. Para ello, el comportamiento del protocolo es verificado mediante: [O] a) Open Message Format b) Update Message Format c) Path Attributes d) Update Message Error Handling e) BGP Finite State Machine f) Update Message Handling g) Aggregation h) Route Reflectors i) BGP-4 Communities Mediante la realización de un conjunto de pruebas que aborde cada uno de estos aspectos, se debe determinar la correcta implementaron del protocolo BGP-4 en el sistema bajo prueba (SUT). Los estándares con los que debe verificarse la conformidad del protocolo son: El draft draft-ietf-idr-bgp4-xx o su versión más actualizada RFC 2796 BGP Route Reflection An alternative to full mesh IBGP RFC 1997 BGP-4 Communities BGP-4 Scalability & Stability Las placas deben brindar la posibilidad de simulación del protocolo de enrutamiento BGP-4 en escalas comparables a lo utilizado en Internet, siendo capaz de: a) Generar más de prefijos BGP. [O] b) Verificar y exigir (stress) para la implementación del protocolo. [O] 12

13 c) Provocar cambios en el estado de las rutas (flapping) simulando inestabilidad en la red. [O] d) Determinar los tiempos de convergencia para las rutas. [O] e) Generación de trafico wire-speed paralelamente al ruteo. [O] BGP-4 Peer Scalability Mediante esta prueba se debe determinar el número máximo de vecindades BGP-4 que puede establecer el DUT. [O] Maximum BGP-4 Routes Learned Con esta prueba se busca determinar el número máximo de entradas que un DUT puede agregar en su tabla de enrutamiento hasta llegar al límite en que ya no logre aprender o propagar más rutas. [O] BGP-4 Route Learning Time Esta prueba mide el tiempo que demora el DUT en enviar tráfico hacia nuevas rutas luego de recibir y procesar las actualizaciones de las rutas ( routing updates ) en su tabla de enrutamiento. [O] Route Convergence Time Esta prueba mide el tiempo que demora el DUT en converger y redireccionar tráfico hacia una ruta con mayor preferencia luego de un cambio de topología en la red. [O] Performance Impact of Unstable/Flapping Routes Con esta prueba se mide la performance total de un SUT bajo condiciones de enrutamiento inestables, donde los cambios de topología y disponibilidad de la red provocan un gran número de routing updates en el core. Se mide la tasa de envío de paquetes y latencia promedio de los paquetes durante un proceso de flapping donde las rutas se remueven y vuelven a aprender. [O] Interfaces BGP La emulación del protocolo de ruteo BGP-4 para las familias de IPv4 e IPv6 deberá estar disponible para las interfaces indicadas puntos 3.1 del presente documento. [O] 4.5 MPLS Functionality & Performance Introducción A continuación se indican las características a medir con respecto al Multi-Protocol Label Switching (MPLS) considerando sus funcionalidades básicas y performance en cuanto a escalabilidad de los DUT/SUT a ser probados. Las placas deben contar con las funcionalidades para cumplir con las pruebas especificadas más adelante, el objetivo de las pruebas es verificar el correcto funcionamiento de un Label Switched Router (LSR) o un Label Edge Router (LER). Las mismas requieren la simulación de una red externa con algún Interior Gateway Protocol (IGP) como OSPF/ISIS para poder llevar a cabo las mediciones de MPLS. Ejemplo de Topología de la prueba, en este ejemplo para la medición de Transit LSR Functionlity : 13

14 LSR1 Puerto A Topologia de red simulada A DUT Puerto B Topologia de red simulada B LSR2 Ingress LSR Egress LSR Requerimientos Las placas deben ser capaces de establecer túneles LSP dinámicamente a través del sistema bajo prueba (SUT). Las placas deben presentar las siguientes capacidades: Emulación de protocolos de señalización (RSVP-TE o LDP/CR-LDP) para establecer dinámicamente los túneles LSP. [O] Emulación automática de protocolos de ruteo IGP: OSPFv2/ISISv4. [O] Habilidad para insertar labels automáticamente y enviar paquetes etiquetados en caminos establecidos dinámicamente. [O] Las placas deben ser capaces de realizar el siguiente listado de pruebas, para cada una especificar si las funcionalidades del equipo ofertado permiten o no realizar tales pruebas. Considerar, que la configuración de la red bajo prueba debe ser genérica, donde para cada prueba el rol a cumplir por el DUT varia (Ingress LER, egress LER, transit LSR), pero la configuración básica de red se mantiene constante. La red debe estar simulada en software por el instrumento actualizando la información de los enlaces mediante LSAs automáticos: a) LDP Forwarding for TRANSIT LSR. [O] Mediante esta prueba, Las placas deben verificar que el DUT sea capaz de crear túneles LSP cumpliendo el rol de Transit LSR usando LDP para distribuir las etiquetas MPLS. También debe verificar que recibe y envía de manera correcta los paquetes etiquetados de MPLS a través del camino LSP. El alcance de esta prueba afecta los planos de datos y control, y la interacción entre ambos. El funcionamiento del DUT como Transit LSR debe estar en conformidad con las RFC 5036 (LDP Specification), RFC 2328 (OSPF Version 2) y RFC 1142 (ISISv4). b) LDP Forwarding for INGRESS LER. [O] Mediante esta prueba se debe verificar que el DUT sea capaz de crear túneles LSP actuando como Ingress LER empleando LDP, verificando además el agregado de etiquetas a los paquetes recibidos y enviando los paquetes etiquetados de MPLS hacia el LER de salida. También aquí se afectan ambos planos de control y de datos y se debe verificar la conformidad con las RFC 5036 (LDP Specification) y RFC 2328 (OSPF Versión 2). c) LDP Forwarding for EGRESS LER. [O] En la presente prueba se verifica que el DUT sea capaz de crear túneles LSP actuando como un Egress LER usando LDP para distribuir las etiquetas, 14

15 removiendo correctamente las etiquetas de los paquetes recibidos y enviando los paquetes de datos a nivel IP hacia el próximo router destino. Nuevamente se afectan ambos planos de control y de datos y se debe verificar la conformidad con las RFC 3036 (LDP Specification) y RFC 2328 (OSPF Versión 2) y RFC d) Penultimate Hop Popping LSR Functionality. [O] Mediante esta prueba se logra verificar la habilidad para un penúltimo LSR de remover ( pop ) etiquetas de un paquete proveniente de una red MPLS, y propagarlo sin etiqueta al LSR de salida. Para esta prueba Las placas deben ser capaces de: Usando un IGP tal como OSPF, deberá anunciar una topología simulada de red por uno de los puertos. Usando algún protocolo de señalización MPLS, tal como RSVP-TE o CR/LDP, deberá crear un LSP entre el ultimo LSR router simulado en su topología, previo al puerto de salida del instrumento, este LSP atravesará el SUT, alcanzando vía el puerto de entrada, al router Egress LSR simulado por el instrumento. Enviar paquetes etiquetados de un puerto al otro. Las placas deben medir el número de paquetes trasmitidos y recibidos sobre los dos puertos y verificar que los paquetes recibidos no tengan etiqueta. e) LSP Setup Time. [O] Esta prueba debe determinar cuánto tiempo demora el SUT para establecer un número dado de LSPs. f) MPLS Scalability. [O] Esta prueba determina el número máximo de LSPs que una red puede soportar estando configurada con routers de tránsito (LSR). g) RSVP-TE Tunnel Establishment Stress Test. [O] Esta prueba consiste en cambiar continuamente el estado (flapping) de un número determinado de túneles LSP durante un lapso definido mientras se realizan estadísticas y recogen logs de Resource Reservation Protocol Traffic Engineering (RSVP-TE). La prueba involucra los planos de control y de datos y debe cumplir con las recomendaciones de las RFC 2205 (RSVP) y RFC 3209 (RSVP-TE: extensions to RSVP for LSP tunnels). h) RSVP-TE forwarding Performance. [O] El objetivo de esta prueba consiste en medir la capacidad del DUT para enviar paquetes etiquetados por MPLS correctamente hacia un túnel RSVP estable mientras otros túneles están continuamente cambiando de estado (flapping). La prueba involucra los planos de control y de datos y debe cumplir con las recomendaciones de las RFC 2205 (RSVP) y RFC 3209 (RSVP-TE: extensions to RSVP for LSP tunnels). 4.6 MPLS Traffic Engineering 15

16 4.6.1 Introducción Traffic engineering permite controlar el tráfico de una red de manera predecible mediante el establecimiento de caminos forzados hacia destino predefinidos. Nota: En este caso el DUT es un router MPLS que soportara las siguientes tecnologías: IGP con extensión de TE, tipo OSPF-TE, protocolos de señalización del tipo RSVP-TE o CR- LDP Requerimientos Indicar si las placas poseen las funcionalidades necesarias para cumplir cada una de los siguientes puntos: RSVP-TE Las placas deberán soportar la simulación de RSVP-TE tanto en señalización, conmutación, como para la determinación de limitaciones de escalabilidad en el SUT/DUT. [O] LDP/CR-LDP Las placas deberán soportar la simulación de LDP/CR-LDP tanto en señalización, conmutación, como para la determinación de limitaciones de escalabilidad en el SUT/DUT. [O] 4.7 MPLS Virtual Private Networks Considerando a las MPLS-VPN genéricamente podemos definir los dos tipos de servicio brindados como de Acceso a VPNs administradas o servicios de VPNs L2 extremo a extremo. En la primera de ellas se trata de una BGP-MPLS VPN de capa 3 mientras que las segundas son VPNs L2 que transportan protocolos como ATM, FR, Ethernet, etc. En las siguientes pruebas se consideraran dos casos principales: BGP-MPLS VPN: es un servicio de capa 3 (capa de red para IPv4 e IPv6), considerado como de Acceso a VPNs administradas, dado que son administradas completamente por el Service Providers. (Proveedor de Servicios). L2 Ethernet VPN: es un servicio de transporte de capa 2 Ethernet que permite a los usuarios finales administrar la capa de red Layer 3 BGP-MPLS VPN Estas pruebas apuntan a la creación de BGP-MPLS VPNs según la definición de la RFC 4364 (BGP-VPN). En este tipo de VPNs, el protocolo MPLS es utilizado para enviar paquetes a través de un Backbone IP, y el protocolo BGP es utilizado para distribuir rutas y etiquetas sobre el mismo. El conjunto de pruebas a realizar por el instrumento son las indicadas a continuación: BGP-MPLS VPN Setup Las placas/puertos deben medir tanto para IPv4 como para IPv6 las capacidades de un Provider Edge (PE): a) Armar VPNs usando MP-iBGP sobre LSPs preestablecidos. [O] 16

17 b) Recibir los paquetes provenientes de un Customer Provider Edge (CPE) y enviarlos de manera correcta (agregando las etiquetas o labels necesarios) hacia la red BGP-MPLS. [O] c) Recibir los paquetes desde la red BGP-MPLS y enviarlos a un CPE removiendo las etiquetas correctamente. [O] BGP-MPLS VPN Scalability Las placas/puertos deben ser capaces de determinar el número máximo de tablas VPN Routing and Forwarding (VRF) que un equipo Provider Edge (PE) puede soportar tanto para IPv4 como para IPv6. [O] Layer 2 MPLS VPN Si bien todavía no hay un estándar totalmente completo que especifique a las VPNs en capa 2, existen algunos RFCs y otros drafts en Internet que han ganado popularidad y se encuentran implementados por una buena parte de los fabricantes de dispositivos MPLS. Estos documentos son los RFC 4664 y 4665, y aquellos que tratan sobre la tecnología Virtual Private LAN Services (VPLS) o su versión jerarquizada Hierarchical-Virtual Private LAN Services (H-VPLS). VPLS permite interconectar redes LAN de manera transparente sobre una red MPLS y existen dos implementaciones de esta tecnología: distribución del control vía BGP ( draft Kompella : draft-ietf-ppvpn-vpls-bgp), y la distribución del control vía LDP ( draft Lasserre-vKompella : draft-ietf-ppvpn-vpls-ldp). Se solicita en los siguientes puntos especificar el soporte del instrumento de estos RFCs/drafts o sus versiones más actualizadas, e indicar si pueden llegar a realizarse las mediciones indicadas más abajo: PWE3 encapsulated traffic scalability El objetivo es probar el comportamiento funcional de un equipo PE mientras se configuran circuitos virtuales Martini (Martini VCs) y se envía tráfico a través de estos VCs una vez establecidos. La prueba debe permitir al operador verificar la señalización (plano de control) y envío de datos (plano de datos) encapsulados según el RFC 4905 (Martini-ENCAP) verificando las extensiones de los LDPs como así también el proceso de encapsulación y desencapsulación Martini. La encapsulación Martini se ha actualizado por el IETF a través del PWE3 Working Group donde se denomina como Pseudowires a las conexiones establecidas entre pares de Providers Edge Routers, de manera similar a los túneles Martini. Los draft más actualizados a la fecha de redacción del presente documento son: RFC Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) RFC Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. RFC Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. RFC IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) RFC Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). [O]. RFC Encapsulation Methods for Transport of Ethernet over MPLS Networks. [O]. RFC Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks. RFC Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks. RFC Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks. RFC Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service. 17

18 Debido a la actualización permanente de estos RFCs/drafts y al proceso de estandarización en que se encuentran estas tecnologías será deseable que el instrumento/placas sean compatibles con las versiones más actualizadas de los mismos y contar con la disponibilidad en roadmap de sus próximas evoluciones. [O] VPLS Functionality La tecnología de Virtual Private LAN Services (VPLS) se encuentra en pleno proceso hacia la estandarización, y el área de Internet responsable de definirlos es el L2VPN Working Group de la IETF. Hasta la fecha de redacción del presente documento, el L2VPN WG ha aprobado los draft mencionados anteriormente: RFC 4664 (draft-ietf-l2vpn-l2-framework) RFC 4665 (draft-ietf-l2vpn-requirements) RFC 4762 [O]. RFC 4761 [O]. Las diferencias principales entre ellos son la señalización y la funcionalidad de autodiscovery. Para la señalización uno de ellos utiliza LDP (RFC 4762) mientras el otro utiliza BGP (RFC 4761). Uno de ellos es agnóstico acerca de un método para descubrir nuevos equipos Providers Edge de VPLS (autodiscovery) mientras el segundo utiliza el protocolo BGP para dicha función. Se considerará ventajoso que el instrumento sea compatible con ambos procedimientos posibilitando la realización de las siguientes pruebas tanto basadas en señalización LDP como BGP. En ambos escenarios, el dispositivo bajo prueba (DUT) es un VPLS-enabled Provider Edge (PE), y debe cumplir las consideraciones descriptas a continuación: a) Se requiere que el instrumento pueda simular la topología de una red MPLS de un Service Provider (SP) y soporte los protocolos de routing y señalización necesarios. [O] b) El instrumento también debe ser capaz de simular el tráfico de un cliente VPLS en ambos sentidos, generando múltiples VLANS o trafico Ethernet sin vlan-tag a velocidades de interfaz wire speed (para las interfaces indicadas en los puntos 3.1 del presente documento), realizando mediciones de performance en tiempo real. [O] c) Finalmente, debe proveer una manera de detectar fácilmente fallas de aislación entre distintas VPNs sometiendo al DUT a las más exigentes condiciones de carga. [O] Bajo estas premisas, las funcionalidades de VPLS a verificar son: a) Las placas/puertos deben medir la habilidad del DUT para establecer un fullmesh de VPLS VC LSPs sobre túneles LSP preestablecidos. [O] b) Las placas/puertos deben verificar que el DUT aprende direcciones MAC y las publica en su tabla VPLS-FIB. [O] c) Las placas/puertos deben verificar que el encapsulamiento y envío (o flooding) de tráfico VPLS se realiza correctamente, conteniendo tanto direcciones conocidas como desconocidas por el DUT. [O] VPLS Scalability 18

19 Bajo las mismas condiciones que el punto anterior, se considerará ventajoso que el instrumento/placas sean compatibles con ambos RFCs (4762 y 4761) posibilitando la realización de las siguientes pruebas tanto basadas en señalización LDP como BGP. En ambos escenarios, el dispositivo bajo prueba (DUT) es un VPLS-enabled Provider Edge (PE), y debe realizar dos pruebas fundamentales: a) El instrumento (placas/puertos) debe determinar cuántas VPNs VPLS es capaz de establecer y mantener el DUT con las placas ofertadas. [O] b) El instrumento (placas/puertos) debe verificar que las VPNs sean totalmente independientes y aisladas entre si aun sometiendo al DUT a las condiciones más severas de carga con las placas ofertadas. [O] - Nota: Las anteriores pruebas son las más relevantes, ya que deben simularse las condiciones de Internet más estresantes para los equipos, donde se verifique si pueden los DUT establecer y mantener las sesiones LDP o BGP, aprender MAC address, replicar tramas, encapsular y enviar el tráfico de los clientes sin interferir entre las distintas VPNs configuradas; todo ello en forma simultánea. Dado que las tecnologías anteriormente mencionadas no se encuentran estandarizadas en forma completa, generalmente están implementadas en software sobre los DUT y se desea cuantificar mediante tales pruebas los niveles de procesamiento y recursos de memoria insumidos en dichos equipos bajo fuertes condiciones de carga H-VPLS Functionality En los RFCs 4762 y 4761 se definen como deben implementarse las topologías de VPLS con jerarquía (H-VPLS) para ser usado en grandes redes en las que VPLS tenga problemas de escalabilidad. Para Hierarchical-Virtual Private LAN Services (H-VPLS) las siguientes características deben sumarse a las ya expuestas para VPLS, y se deberá indicar si son soportadas por las placas de medición: a) H-VPLS service establishment for PE VPLS switches. b) H-VPLS configuration for multi-tenant unit (MTU) VPLS switches. c) Per-port MPLS pseudo wires with tunnel. d) Per-port-per-Vlan MPLS pseudo wires with tunnel. e) Per-port MPLS pseudo wires without tunnel. f) Concurrent types of pseudo wires. Los DUT participantes en esta prueba pueden cumplir la función de Provider Edge (PE) o Multi-Tenant Unit (MTU) y ambas funcionalidades deben ser sometidas a prueba por el instrumento H-VPLS Scalability De la misma manera que para VPLS se solicita que el instrumento/placas sean capaces de verificar la escalabilidad de una red H-VPLS. Se considerará ventajoso que el instrumento sea compatible con ambos RFCs (4762 y 4761) posibilitando la realización de las siguientes pruebas tanto basadas en señalización LDP como BGP. Dado que los DUT participantes en esta prueba pueden cumplir la función de Provider Edge (PE) o Multi-Tenant Unit (MTU) deben realizarse dos pruebas fundamentales para cada una de sus funciones posibles: a) El instrumento (placas/puertos) debe determinar cuántas VPNs H-VPLS es capaz de establecer y mantener el PE con las placas ofertadas. 19

20 b) El instrumento (placas/puertos) debe verificar que las VPNs sean totalmente independientes y aisladas entre si aun sometiendo al PE a las condiciones más severas de carga con las placas ofertadas. c) El instrumento (placas/puertos) debe verificar que las VPNs sean totalmente independientes y aisladas entre si aun sometiendo al MTU a las condiciones más severas de carga con las placas ofertadas. 20