EMPRESA DE TELECOMUNICACIONES DE BOGOTA S.A. ESP PRUEBAS DE INTEROPERABILIDAD CPE VDSL2 con We2 Compañía Interesada Equipo Fecha Febrero de 2014 1 CONDICIONES PARA LA EJECUCION DE LAS PRUEBAS Las pruebas se realizaran en días laborales de lunes a viernes y en el horario comprendido entre las 7 AM a 4 PM. ETB definirá el tiempo estimado para las pruebas el cual no será modificado bajo ninguna circunstancia. El tiempo definido en ETB para la ejecución de las prueba al CPE es de 9 días, de acuerdo a la programación y cantidad de proveedores que participen. El interesado debe dejar las muestras en el laboratorio de ETB para aquellos equipos que cumplan con la totalidad de pruebas obligatorias del presente documento. Todas las pruebas obligatorias consignadas en el protocolo son de estricto cumplimiento en los equipos en prueba. Se dará por terminada la ejecución del protocolo de pruebas en caso del no cumplimiento de cualquiera de las pruebas de Interoperabilidad del CPE con las redes y servicios de ETB. Para la participación del proceso de contratación el proveedor debe haber aprobado de manera satisfactoria el proceso de homologación del CPE. Máximo se aceptará la presencia de dos (2) personas en representación de la compañía interesada. Los representantes de la compañía interesada deben traer mínimo dos CPE con sus respectivos accesorios. Los representantes de la compañía interesada deben traer dos (2) computadores portátiles para la configuración de los equipos y para la ejecución de las pruebas. Todos los equipos se recibirán mediante acta firmada por parte ETB y el delegado por el proveedor, en el laboratorio de ETB el día de inicio de la prueba. El orden de ejecución de los puntos del protocolo puede ser modificados a criterio de ETB. A continuación se presenta la lista de verificación de las funcionalidades a ser probadas: FORMATO GENERAL PARA PRUEBAS DE INTEROPERABILIDAD VDSL2 INICIO FIN DD Proveedor: MM AA DD MM AA INFORMACION ETB Persona Representante: Teléfono: Identificación: e_mail: C.C. C.C. Ingeniero del laboratorio de pruebas: Teléfono: 2 ETB: e_mail: 1 DESCRIPCION EQUIPO Marca: Serial: Ver. Firmware: Modelo: Chipset Memoria flash Memoria RAM Tipo de antena Numero de antenas 2 DIRECCIONES IP Descripción Dirección / Máscara Observaciones: IP GESTION WEB IP GESTION TELNET User Password 3. INTERFAZ Cumple / Requerimiento No cumple Interfaz WIFI (802.11 b/g/n/AC) Los 4 puertos FastEthernet deben estar en modo switch. Requerimiento LAN. (4) FastEthernet Auto sense. Función Auto MDI-X Cumple / No cumple Observaciones: Requerimiento 4. INDICADORES VISUALES Requerimiento Cumple / No Cumple Power (Estado sobre el equipo de la alimentación eléctrica) Actividad de cada uno de los puertos LAN Estado de conexión y desconexión de la red Internet. Observaciones: Requerimiento (ADSL) G.DMT ITU-T G.992.1 ADSL2+, G.DMT.bis plus ITU-T G.992.5. (ADSL2) G.DMT.bis ITU-T G.992.3 Cumple / No Cumple VDSL2 Actividad /Sincronismo Actividad WIFI (802.11 b/g/n/AC) Estado de conexión VOIP Y WPS 5. MODULACIÓN xDSL Cumple / Requerimiento No Cumple ADSL2+, G.DMT.bis plus ITU-T G.992.5. anexo M (ADSL) G.Lite: ITU-T G.992.2 G.993.2 VDSL2 (perfiles 8a, 8b, 8c, 8d, 12a, 12b, 17a) Auto-negociación del estándar xDSL (ADSL/ADSL2+/ADSL2+M / VDSL2) de acuerdo con la configuración del DSLAM. Observaciones: G.993.5 VDSL2 3 Cumple / No Cumple Requerimiento 6. CARACTERISTICAS ATM Cumple / Requerimiento No cumple Múltiples PVC simultáneos configurables con diferentes clases de encapsulamiento, mínimo 5 (3 Router y 2 Bridge). Cumple / No cumple Rango VCI (32 a 255): Rango VPI(0-255) Observaciones: Requerimiento Packet Transfer Mode (PTM) 7. CARACTERISTICAS PTM Cumple / Requerimiento No cumple Soportar mínimo cinco servicios en modo PTM, los cuales pueden ser configurados en modo bridge y/o como router simultáneamente (3 Router y 2 Bridge). 802.1P QoS Probar los servicios de Multicast. DHCP Relay NTP server con modulación PTM Cumple / No cumple Observaciones: Requerimiento Mac Encapsulation routing (MER) LLC/SNAP BRIDGING. Probar por http PPPoE (PPPoE over Ethernet teniendo el CPE modo router y con NAT) Probar por http Permanencia del PPPoE aún en ausencia de tráfico Observaciones: Requerimiento NAT/NAPT (PVCs PPPoE y MER) 8. ENCAPSULAMIENTO Cumple / Requerimiento No cumple RFC 2684 Modo Bridge LLCSNAP/VC-Mux. Probar por http. Cumple / No cumple PPPoE pass through desde LAN/WAN Probar por http RFC 2684 modo router con NAT/SIN NAT/NAPT habilitado. 9. SERVICIOS IP Cumple / Requerimiento No cumple SIP ALG habilitable y des-habilitable desde la interfaz web. Virtual Server (NAT/NAPT en asociación de puertos específicos y/o protocolos) habilitando la gestión WEB en puerto diferente al 80. DMZ (Soporta servidores internos en LAN para ser accedidos por Host Externos ). DHCP Server deshabilitado en la LAN con CPE configurado como bridge DHCP Server tenga la función de selección por diferentes puertos LAN Configuración de al menos dos PVC con NAT (PPPoE y MER) y otro sin NAT (MER) DHCP Server en la LAN con CPE configurado como router. DHCP Client en la WAN y generación de DHCP opción 60 DHCP Server tenga la función de selección por diferentes SSID Configurar un NAT y un PAT por PVC. DHCP server hacia la LAN Sincronización del módem por medio de servidor NTP o SNTP. Configurar un NAT y un PAT por VLAN. 4 Cumple / No cumple Soporte mínimo 16 host y/o componentes de red en la LAN y El fabricante debe traer los recursos para la ejecución y demostración de esta prueba. Habilitar el servicio NAT - IP MAPPING Conectividad y compartir archivos entre dispositivos entre OTT, PC y STB (opcional) Habilitar y/o deshabilitar NAT por cada PVC en modo routing. Habilitar y/o deshabilitar NAT por cada VLAN en modo routing. Protocolos especiales que puedan hacer transporte RTSP a ALG, RTCP a ALG, UPNP, TR069, TR111. Observaciones: Requerimiento Enrutamiento Estático por dirección IP destino. Mapeo de puertos Ethernet y SSID específicos a PVC ATM específicos Mapeo de puertos Ethernet y SSID específicos a VLAN PTM especificas. IGMP pass-through (en CPE modo Bridge y sin NAT) RIP versión 2 Configuración de una segunda dirección IP en la LAN. La interfaz debe trabajar con las dos direcciones IP simultáneamente. Enrutamiento mapeo en una determinada WAN según destino Observaciones: Requerimiento 10. ENRUTAMIENTO Cumple / Requerimiento No cumple Enrutamiento estático y diferenciado por PVC. Enrutamiento estático y diferenciado por VLAN Cumple / No cumple IGMP versión 2 IGMP Snooping IGMP Proxy (opcional) Enrutamiento multicast desde la WAN hasta la LAN, con el CPE en modo router (opcional) 11. GESTION Cumple / No cumple Requerimiento Gestión por HTTP para todas las configuraciones Locales. Reinicio desde la interfaz web. Gestión por HTTP para todas las configuraciones Remotas Configuraciones local y remota (PPPoE, MER con y sin NAT, Bridge). Gestión del CPE por medio de un pool definido. Restricción de las demás direcciones diferentes a las del pool. (SSH, HTTP y TELNET) puertos default y puerto 7378 y el 23 Restablecer a valores de fábrica por software Actualización remota de firmware vía FTP o TFTP. Copia de la configuración del CPE a un PC vía FTP,TFTP o Texto plano. Al apagar y encender el equipo se debe guardar los cambios realizados antes del reinicio del equipo. El CPE debe mostrar estadísticas de interfaz AAL5 (ATM) El CPE debe mostrar la configuración de Restablecer a valores de fábrica por Hardware (mínimo 5 segundos, máximo 8 segundos para restablecer a valores de fábrica) Verificación de conectividad IP PING con un host destino. Verificación del estado de sincronización del CPE Restauración de la configuración del CPE vía FTP, TFTP o Texto plano. Verificación de conectividad PPPoE El CPE debe mostrar SNR a nivel DSL El CPE debe mostrar atenuación a 5 Cumple / No cumple capa 2 y 3. El CPE debe soportar TR-069 Issue1 Amendment 2 1. Configurar la URL, usuario y password de la plataforma ACS. 2. Confirmar registro de CPE en plataforma. 3. Después que la plataforma actualice configuración en el CPE reiniciar el CPE 4. y confirmar que la nueva configuración obtenida se mantenga en el CPE nivel DSL El CPE debe mostrar las direcciones MAC de los equipos que se encuentran conectados por las interfaces alámbricas e inalámbrica. El CPE debe mostrar SNR a nivel WIFI El CPE debe mostrar el estado de cada PVC Observaciones: Prue ba 11.1 GESTION Pasos de implementación Descripción Validar que la Gestión por CLI o HTTP está configurada en el CPE en los del puerto XXXX y el XX remotamente Resultado Comentarios Pru eba 11.2 Descripción Modificación de puerto HTTP de la gestión del CPE por el puerto XXXX a través de la plataforma ACS: XX remotamente Resultado Comentarios Ingresar al CPE a través de TELNET Ingresar el CPE a través del SSH A través de un navegador ingresar a la URL: http://IP _CPE:XXXX A través de un navegador ingresar a la URL: http://IP _CPE El CPE permite acceso a través de Telnet y por Http a través del puerto XXXX y no permite acceso al HTTP a través del puerto 80. CUMPLE NO CUMPLE GESTION Pasos de implementación Ingresar a la plataforma ACS Modificar el parámetro de puerto de acceso HTTP al XXXX Aplicar el perfil a CPE y validar: A través de un navegador ingresar a la URL: http://IP _CPE:XXXX A través de un navegador ingresar a la URL: http://IP _CPE CUMPLE Requerimiento Resultados esperados Resultados esperados El CPE permite acceso a través de Telnet y por Http a través del puerto XXXX y no permite acceso al HTTP a través del puerto 80. NO CUMPLE 12. SEGURIDAD Cumple / No cumple 6 Requerimiento Cumple / No cumple Filtro de Paquetes o listas de Acceso: (por MAC, por IP/rangos, protocolos y puertos TCP/UDP). La gestión debe contar (User y Password) con un nivel de acceso para lectura, diagnostico y configuración parámetros wireless. Este usuario no debe permitir la opción restart default factory. La gestión debe contar (User y Password) con un nivel de acceso para gestión completa. Acceso al CPE que tenga un mecanismo que evite la visualización del password de acceso vía consola, telnet y web. Observaciones : Prueba 12.1 Descripción Validar que el usuario con privilegios de consulta (Custumer), no pueda realizar cambios en la configuración de administración del CPE ni parámetros WAN de la conexión. Autenticación CHAP/PAP Soporta VPNs pass-through (IPSec/IKE) La clave en una sesión PPPoE debe aparecer encriptada El protocolo de autenticación CHAP/PAP debe cambiar de acuerdo con los requerimientos del BRAS (Modo Auto). SEGURIDAD Pasos de implementación Ingresar al CPE con usuario Customer Ingresar a menú de configuración de contraseña o el menú de configuración WAN. Validar que no se pueda cambiar la contraseña del usuario o ningún parámetro de la configuración WAN. Resultados esperados El CPE no permita la modificación de la configuración del CPE a través de la modificación del código fuente. Validar que el usuario Custumer tenga acceso a la configuración de virtual server Validar que el usuario Custumer tenga acceso a configurar la opción de DDNS. Validar que el usuario Custumer no tenga acceso a las páginas de administración del CPE Resultado CUMPLE NO CUMPLE Comentarios Prueba 12.2 Descripción Las ACL de gestión del CPE deben mantenerse después de un reinicio a factory default del CPE. Para esto se solicita que la versión de firmware SEGURIDAD Pasos de implementación A través de hardware y software llevar el CPE a factory default. Reiniciar el CPE Ingresar a la configuración del CPE a la sección de ACL Validar que las ACL se encuentran configuradas y funcionando. 7 Resultados esperados Las ACL deben mantenerse configuradas y habilitadas después del reinicio al factory default. para pruebas tenga pre configuradas listas de acceso.ACL Resultado Validar que aún se tiene gestión del CPE a través de la plataforma del ACS CUMPLE NO CUMPLE Comentarios 13. SOPORTE DE VOZ SOBRE IP (VoIP) PARA CPE CON FUNCIONALIDAD IAD Cumple / Requerimiento Requerimiento No cumple Softphone VALIDAR XLITE Cumple / No cumple Sofphone Counther Path Bria Sofphone Audiocodes VMAS Sofphone Broadsoft UC One Observaciones : Requerimiento Detección o lectura de paquetes marcados DSCP. Observaciones: 14. QoS Cumple / Requerimiento No cumple Encolamientos de paquetes marcados DSCP. Cumple / No cumple 15. INTERFAZ WIFI Requerimiento Cumple / No Cumple Requerimiento 802.11b/g/n/AC Para N garantizar > 150Mbps y para AC garantizar 2.4 Gbps a 5 Gbps Conexión y navegación en Internet por medio de la interfaz wireless Ganancia antena: 2dBi y 5dBi * Conectividad entre usuarios alámbricos e inalámbricos en configuración bridge Conectividad entre usuarios alámbricos e inalámbricos en configuración routed El CPE debe entregar la dirección IP por DHCP a los usuarios wireless PPPoE Passthrough (usuarios pueden levantar sesiones PPPoE utilizando la interfaz Wireless) El CPE debe mostrar las direcciones MAC de los equipos que se encuentran conectados por la interfaz wireless. SSID - Sistema Abierto (Lo anuncia) WPA2-PSK AES SSID - Sistema Cerrado (no lo anuncia) WPA2-PSK TKIP Soportar múltiples SSIDs Establecimiento de VPNs desde el cliente hacia Internet (Passthrough IPSec). Filtros por direcciones MAC para acceso a la red por medio de la wireless Posibilidad de selección de canales WIFI *Funcionalidad WPS, el recurso debe ser demostrado por el fabricante *Cantidad de conexiones simultaneas del WiFi en grupos de 8, 16, 25 o 8 Cumple / No Cumple superior , OBLIGATORIA Medición de la velocidad de los dispositivos conectados de manera simultánea sobre WiFi. Observaciones: *Se validará de acuerdo con los recursos, si no es posible realizar la prueba el OFERENTE deberá garantizar el cumplimiento de esta funcionalidad. 9 16. THROUGHPUT Las pruebas de Throughput del apartado 16.1 se realizarán a cero (0) metros. Las pruebas de Throughput del apartado 16.2 se realizarán utilizando distancia (bucles de par trenzado 0.4). En los dos apartados se utilizará un instrumento generador de tráfico y el tráfico generado será en el sentido Down (DSLAM al CPE). Las pruebas se realizarán con diferentes MTUs y con tráfico multicast y unicast. El throughput es el promedio en Mbps o Kbps al cual el CPE no presenta pérdida de paquetes. 16.1. TROUGHPUT A CERO METROS SENTIDO DOWN/UP Cumple / No Cumple Requerimiento Requerimiento Cumple / No Cumple Tráfico Unicast, MTU (1300 -1500 bytes), CPE en modo bridge, durante 15 minutos debe tener un throughput de 80 Mbps en sentido down y en sentido up un throughput de 50 Mbps Tráfico Unicast, MTU (1300 -1500 bytes), CPE en modo routed, durante 15 minutos debe tener un throughput de 80 Mbps en sentido down y en sentido up un throughput de 50 Mbps *Dos (2) PVCs: El primero para 40 Tráfico Multicast, MTU (1300 -1500 Mbps de tráfico multicast, modo bridge, bytes), CPE en modo bridge, durante 15 MTU (1500 bytes) y el segundo para 40 minutos debe tener un throughput de 80 Mbps de tráfico unicast, modo routed, Mbps en sentido down. y en sentido up un MTU (1300 -1500 bytes). El throughput throughput de 50 Mbps. debe ser 40Mbps / 40Mbps durante 15 minutos Observaciones: *Se validará de acuerdo con los recursos, si no es posible realizar la prueba el OFERENTE deberá garantizar el cumplimiento de esta funcionalidad. 16.2 TROUGHPUT CON DISTANCIA DOWN Requerimiento Cumple / No Cumple Tráfico Unicast, MTU (1300 -1500 bytes), CPE en modo bridge, a una distancia de 100 metros, durante 10 minutos debe tener un throughput de 64 Mbps Tráfico Unicast, MTU (1300 -1500 bytes), CPE en modo bridge, a una distancia de 1500 metros, durante 10 minutos debe tener un throughput de 17 Mbps Observaciones: Requerimiento Cumple /No Cumple Tráfico Unicast, MTU (1300 -1500 bytes), CPE en modo bridge, a una distancia de 1000 metros, durante 10 minutos debe tener un throughput de 35 Mbps 16. DESEMPEÑO ELECTRICO Cumple / Requerimiento Requerimiento No cumple Desempeño en cortes de fluido eléctrico o en variaciones de tensión: (No debe perder la configuración) Observaciones 10 Cumple / No cumple Requerimiento 17. SERVICIO We2 Cumple / No cumple Requerimiento Cumple / No cumple Pruebas Servicio We2 ver Anexo requerimientos correspondientes al servicio We2 Observaciones ANEXO REQUERIMIENTOS CORRESPONDIENTES AL SERVICIO WE2 HARDWARE FISICOS, ELECTRICOS Y MECANICOS Referencia Requerimiento Phy.1 LED Estado SSID Público(opcional) Phy.2 LED Estado Túnel We2(opcional) Phy.3 Posibilidad de conectar antena externa(opcional) Cumple No Cumple Observaciones: HARDWARE Referencia (c.1 Hw.2 Requerimiento Cumple Flash suficiente para almacenar el ALG We2 embebido junto con el resto de software del CPE. La cantidad de flash necesaria variará con la arquitectura. La implementación de referencia de We2, en una arquitectura de 32 o 64 bit ocupa menos de 100 Kbytes Memoria RAM suficiente para la operación del ALG We2 embebido. El consumo de memoria de la implementación de referencia de We2 es de menos de 5 Kbytes y es independiente del número de clientes conectados.. Hw.3 Además del SSID standard privado, se soporta un SSID público abierto. Hw.4 802.11a/g Hw.5 802.11 N, si se soporta Debe ser posible deshabilitarlo1. (condicional) Hw.6 Soportar encriptación asistida por hardware 2 para maximizar performance. 1 We2 ha detectado problemas con ciertos dispositivos conectándose en modo N y se recomienda tener la opción de deshabilitarlo. 2 Este requerimiento afecta al SSID privado (encriptado) que comparte CPU con el público abierto. 11 No Cumple Hw.7 Doble banco de memoria EEPROM Hw.8 Se soporta al menos un Interfaz WAN Hw.9 Botón de reinicio a valores por defecto Observaciones: FUNCIONALIDAD GLOBAL Referencia GF.1 Requerimiento El CPE debe soportar al menos 2 SSIDs: uno abierto para el público utilizado y otro con la seguridad habilitada para uso privado. GF.2.1 Red Pública: formada por el SSID público y la interfaz TAP creada por el ALG We2 para la recepción y envío de tramas ethernet. (TR068) GF.2.2 Red Privada: formada por el SSID privado y todas las interfaces del switch Ethernet. GF.3 Configuración de dirección IP del Interfaz WAN estáticamente o dinámicamente GF.4 Habilidad para configurar múltiples PVCs en el interfaz WAN. GF.5 Habilidad para configurar direcciones IP diferentes a cada uno de los PVCs estática ó dinámicamente GF.6 Habilidad para mapear el tráfico originado en el We2 ALG a un PVC determinado. GF.7 Separación estricta de tráfico entre la red privada y la pública. GF.8 Habilidad para preservar una cantidad de ancho de banda para la interfaz privada. La Interfaz pública debe disponer of al menos 2 Mbps. GF.9 No debe haber limitación en cuanto al número de estaciones asociadas. De forma combinada (SSID Público + privado) debe permitirse hasta 25 estaciones asociadas por CPE. (Recomendado) GF.10 No se podrá habilitar Filtrado de MAC para el SSID público. Filtrado de MACs sólo aplicará y, sólo será configurable manualmente o con WPS para el SSID privado. GF.11 El CPE no radia el SSID público si el túnel We2 está caído. GF.12 Tráfico entre estaciones asociadas al SSID público no debe ser posible. El tráfico sólo podrá fluir en ambas direcciones entre Interfaz WiFi y We2 ALG. GF.13 NAT sólo será aplicable al tráfico IP originado en la red privada. (un pvc en bridge y otro en routed) 12 Cumple No Cumple GF.14 Una vez configurado el ALG, el SSID público no se podrá deshabilitar administrativamente en el CPE3. El CPE debe disponer de un par de claves RSA (privada y pública) asociada al hardware del CPE y creada en fábrica. El inventario proporcionado por el fabricante a ETB debe incluir, junto con la MAC que se usará en el SSID público y el número de serie, la clave pública del router. La clave pública y privada debe estar accesible internamente al We2 ALG y la clave pública debe poder leerse también vía TR069. GF.15 GF.16 El procedimiento de verificación requiere contar con un CPE flasheado y consiste en: Pre-requisito: existe conectividad entre el CPE y el We2 director “director.gowe2.com” 1. Configurar la clave pública del router en We2 NET 2. We2 NET y CPE tienen configurado el mismo pre-shared key 3. Encender el router y verificar que se recibe un We2 TP REDIRECT en respuesta al Hello-Hotspot enviado. (Firma del hello-hotspot verificada con éxito) 4. Configurar una clave pública errónea para el CPE en WE2 NET 5. Encender el router y verificar que no se recibe respuesta al Hello-Hotspot (hello hotspot descartado por el we2 director al no poder verificar la firma) . La aplicación We2 ALG debe disponer de una clave privada y pública a usar por defecto en caso de que el CPE no disponga de claves hardware. Esta clave privada y pública estará hardcodeada en el software del cliente (todos los CPEs del fabricante corriendo el cliente tendrán la misma) y el valor de la clave pública por defecto debe proporcionarse a ETB. Esta clave pública por defecto será devuelta por TR069 cuando la hardware no esté disponible. Procedimiento es igual como el del numeral GF.15. Se requiere para su verificación contar con un CPE flasheado. Pre-requisito: existe conectividad entre el CPE y el We2 director “director.gowe2.com” 1. Configurar la clave pública del router en We2 NET 2. We2 NET y CPE tienen configurado el mismo pre-shared key 3. Encender el router y verificar que se recibe un We2 TP REDIRECT en respuesta al Hello-Hotspot enviado. (Firma del hello-hotspot verificada con éxito) 4. Configurar una clave pública errónea para el CPE en WE2 NET 5. Encender el router y verificar que no se recibe respuesta al Hello-Hotspot (hello hotspot descartado por el we2 director al no poder verificar la firma) Observaciones: 3 Una vez configurado, el SSID público no se podrá deshabilitar en el CPE. La suspensión/reanudación del servicio podrá hacerla ETB suspendiendo/activando la subscripción en We2 NET ó el usuario desde la aplicación de We2 deshabilitando/habilitando el servicio de compartición de Internet asociado. Cuando la subscripción está desactivada o el servicio deshabilitado, We2 NET no permitirá al CPE establecer el túnel, lo que deshabilita automáticamente la radiación del SSID. 13 GESTIÓN DEL CPE REQUISITOS Referencia Requerimiento GOAM.1 El CPE debe soportar gestión remota de acuerdo con TR.069 GOAM.2 El CPE debe soporta el modelo de datos TR.098 tal y como se indica en la TR.069. GOAM.3 El CPE debe soportar los procedimientos de actualización de firmware remota sobre el Interfaz WAN indicados en TR069. GOAM.4 El CPE debe proporcionar la habilidad al We2 ALG para interaccionar con la entidad de gestión en el CPE con el fin de modificar el estado y la configuración del Interfaz Wi-Fi correspondiente al SSID público. GOAM.5 El CPE debe proporcionar la habilidad para que el ALG pueda pedir que el CPE se conecte a un servidor de ACS secundario. (opcional) GOAM.6 Si se implementa GOAM5, el ACS secundario podrá acceder sólo a la configuración de los parámetros correspondientes al ALG WE2. (Condicional) GOAM.7 GOAM.8 GOAM.9 GOAM.10 GOAM.11 Si se implementa GOAM5, la URL de conexión al servidor secundario se integraráen el modelo de datos de TR098 con el siguiente parámetro específico de fabricante: (condicional) InternetGatewayDevice.ManagementServer.X_gowe2_com_managementserver. URL (condicional) El We2 ALG requiere un número mínimo de parámetros de configuración que se integran en el modelo de datos de TR.098 como parámetros específicos del fabricante: "X_gowe2_com". (Ver lista en Anexo). El We2 ALG podrá soportar de forma opcional los parámetros de configuración y operacionales indicados como opcionales en la tabla del Anexo. Si los parámetros opcionales de configuración no se soportan como parámetros configurables, sus valores por defecto deben estar hardcoded. Todos estos parámetros se integrarán en el modelo de datos de TR098 como parámetros específicos del fabricante “X_gowe2_com”. (opcional) El CPE debe soportar los procedimientos de configuración remota de TR069 y en el caso particular del We2 ALG, debe soportar la configuración del We2 ALG mediante un fichero de configuración específica de fabricante ((TR.098 InternetGatewayDevice.DeviceInfo.Vendor-ConfigFile.{i} ) El CPE debe soportar el procedimiento de “factory reset” de TR069 que permiten resetear el router a la configuración de fábrica y fuerza la conexión al ACS del ISP para actualizar el firmware y obtener la configuración. GOAM.12 El CPE intentará arrancar primero desde flash, después desde el ACS y por último vía TFTP desde cualquiera de los puertos cableados. GOAM.13 Los parámetros de configuración del ALG We2 no deben estar disponibles al usuario desde la interfaz local de gestión, sino únicamente al ACS primario (y secundario si soportado) y al ALG We2. GOAM.14 Una vez configurado, la activación y desactivación del SSID público en el CPE debe estar sólo disponible al ALG de We2 (ver GF14) GOAM.15 El CPE debe soportar NTP para la sincronización de la hora del CPE. 14 Cumple No Cumple ARCHITECTURA SOFTWARE Referencia Requerimiento SWA.1 El We2 ALG debe poder abrir un socket UDP sobre el que enviar y recibir We2 T-PDUs al y desde el controller de We2 en un puerto destino configurable SWA.2 El We2 ALG debe ser capaz de crear un interfaz TAP sobre el que recibir y enviar tramas Ethernet desde y a los clientes asociados al SSID público. SWA.3 El We2 ALG debe implementar el We2 Tunnelling Protocol para establecer, mantener y tirar los túneles We2 con el We2 Access controller. Un túnel We2 encapsula tramas Ethernet sobre UDP. SWA.4 El We2 ALG debe poder comunicarse con la entidad de gestión local a fin de poder acceder a los parámetros de We2. SWA.5 El We2 ALG debe poder comunicarse con la entidad de gestión local a fin de solicitar que se conecte al servidor ACS. SWA.6a SWA.6b Cumple No Cumple Cumple No Cumple El WE2 ALG tiene un bloque funcional de control que implementa el We2 TP e interactúa con la entidad de gestión. El plano de control se implementa en "user land". El We2 ALG tiene un bloque funcional de plano de datos que recibe tramas ethernet del interfaz TAP, las encapsula en el túnel y las envía al Access Controller; y des-encapsula tramas ethernet recibidas en el túnel y las envía al interfaz TAP. SWA.7 El plano de datos debe estar implementado en el Kernel para optimización de performance (menos ciclos de CPU). (opcional) SWA.8 Plano de datos y plano de control utilizan el mismo socket UDP. Observaciones: PROTOCOLO DEL TUNEL WE2 MENSAJES DEL PLANO DE CONTROL Referencia Requerimiento Hello Hotspot Hello Hotspot Ack Hotspot KeepAlive Hotspot KeepAlive Ack Redirect HotSpot Connect-to-Mgmt-Server Observaciones: 15 PROCEDIMIENTOS DEL PROTOCOLO Referencia Requerimiento Cumple No Cumple Cumple No Cumple Inicialización del CPE Establecimiento del Túnel We2 en un CPE autorizado Establecimiento del Túnel We2 en un CPE no autorizado Mantenimiento del Túnel We2 con tráfico en la interfaz TAP Mantenimiento del Túnel We2 sin tráfico en la interfaz TAP Transferencia de datos. Recepción de PDUs de datos Transferencia de datos. Envío de PDUs de datos Transferencia de mensajes de control. Recepción de PDUs de control Transferencia de mensajes de control. Envío de PDUs de control Gestión del CPE Observaciones: CASOS DE FALLO Referencia Requerimiento Recuperación del túnel We2 tras un reinicio del CPE Recuperación del túnel We2 tras una pérdida de conexión Reintentos de establecimiento del túnel We2 Observaciones: 16 Anexo A. TR.098 Parámetros específicos de fabricante “X_gowe2_com”. Read Parameter Write4 7 Object R R Description Define un servidor ACS secundario que tendrá permisos de Lectura/Escritura de los parámetros relacionados con We2. URL InternetGatewayDevice.WANDevice.{i}.WAN ConnectionDevice.{i}.X_gowe2_com_We2Tu nnel String(256) R R URL del servidor secundario. Apunta al ACS de We2. Object R R BEDirector String(256) R R Define el túnel We2. Dirección del Backend de We2. Es donde todos los routers deben apuntar al enviar el Hello-Hotspot inicial para establecer el túnel. Por defecto: "director.gowe2.com" DirectorUDPPort unsignedInt R R Puerto UDP usado para el Hello-Hotspot inicial contra el Backend. Por defecto: “8000” OpenSSID string(32) R R PresharedKey String(64) R "-" BEPublicKey String(256) R R SSID usado en la interfaz WLAN pública para We2. Pre-shared key usada para la autenticación mutua en el Hello-Hotspot y Redirect. Secreto definido por el operador. We2 BE public key usada para la autenticación del backend en el CPE durante el procedimiento de Redirect. PublicKey String(256) "-" R CPE RSA public key usada en la autenticación del Hello-Hotspot del CPE en el backend. TimeoutHello unsignedInt O O HelloMaxAttempts unsignedInt O O Hello-Hotspot timeout. Por defecto: 10 sec Hello-Hotspot Max número de intentos. Por defecto: 5. TwaitMin unsignedInt O O Tiempo mínimo de espera entre intentos de establecimiento del túnel. Por defecto: 60 sec TwaitMax unsignedInt "-" O Tiempo máximo de espera entre intentos de establecimiento del túnel. Por defecto: 3600 sec O El keep alive idle timer es reiniciado cada vez que se recibe una PDU del servidor. Cuando el timer expira, se envía un keep-alive message al servidor para comprobar el estado del túnel. Por defecto: 60s InternetGatewayDevice.ManagementServer. X_gowe2_com_managementserver KeepAliveIdleTimer Type unsignedInt "-" KeepAliveAbsoluteTimer unsignedInt "-" O Para asegurar los reportes RTT se envían mensajes keep alive cuando este absolute timer expira. Por defecto: 300 KeepAliveMaxAttempts unsignedInt "-" O Máximo número de intentos antes de que el túnel sea declarado caído. Por defecto: 2 KeepAliveTimeout InternetGatewayDevice.WANDevice.{i}.WAN ConnectionDevice.{i}.X_gowe2_com_We2Tu nnel.Stats unsignedInt "-" O Timeout de no hay respuesta. Por defecto: 5 object "-" O Parametros operacionales y estadísticas del tunel We2. 4 Read/Write: “R”=Required, “O”=Optional, “C”=Conditional 17 Read Parameter rxPDUs discardedPDUInvalidHeader Type Write4 7 Description unsignedInt "-" O unsignedInt "-" O discardedPDUInvalidTID unsignedInt "-" O discardedUnsupportedProtocolVersion unsignedInt "-" O Número total de PDUs recibidas desde el backend. Número total de PDUs descartadas por cabecera invalida. Número total de PDUs descartadas por un TID incorrecto. Número total de PDUs descartadas por versión incorrecta. rxCtrlPDUs unsignedInt "-" O Número total de PDUs de control recibidas. rxDataPDUs unsignedInt "-" O discardedPDUInvalidTT unsignedInt "-" O rxFwdDataPDUs unsignedInt "-" O txCtrlPDUs unsignedInt "-" O Número total de PDUs de datos recibidas. Número total de PDUs descartadas debido a un TT inválido. Número total de PDUs de datos enviadas hacia la interfaz radio. Número total de PDUs de control enviadas hacia el BE. txDataPDUs unsignedInt "-" O Número total de PDUs de datos enviadas hacia el BE. txPDUs unsignedInt "-" O discardedInvalidTypeCtrolPDU unsignedInt "-" O discardedInvalidSequence unsignedInt "-" O Número total de PDUs enviadas. Número total de PDUs de control descartadas debido a PDU inválida. Número total de PDUs de control descartadas por número de secuencia inválido. currentSequenceNumber unsignedInt "-" O Número de secuencia actual. nextExpectedPDU unsignedInt "-" O Próxima PDU de control esperada. lastReceivedPDU unsignedInt "-" O Tipo de última PDU de control enviada. rxRedirectMessages unsignedInt "-" O discardRedirectInvalidFormat unsignedInt "-" O discardRedirectInvalidPrimaryID unsignedInt "-" O discardRedirectAuthFail unsignedInt "-" O Número de mensajes de redirección recibidos. Total de redirecciones descartadas debido a un formato inválido. Total de redirecciones descartadas debido a un Primary ID inválido. Total de redirecciones descartadas debido a un fallo en la autenticación. txHelloHotspotMessages unsignedInt "-" O Número total de Hello-Hotspot transmitidos. rxHelloHotspotAckMessages unsignedInt "-" O Número total de Hello-Hotspot-ACK recibidos. helloHotspotTimeout unsignedInt "-" O Número total de Hello-Hotspot timeouts currentServerIP unsignedInt "-" O currentServerPort unsignedInt "-" O IP del servidor de túneles (Access Controller) en uso. Puerto UDP del servidor de túneles (Access Controller) en uso. currentTWait unsignedInt "-" O Valor actual de Twait txKeepAliveIdleMessages unsignedInt "-" O Número total de mensajes keepalive idle txKeepAliveAbsoluteMessages unsignedInt "-" O Número total de mensajes keepalive absolute rxKeepAliveAcks unsignedInt "-" O Número total de mensajes Keep Alive Acks recibidos keepAliveTimeouts unsignedInt "-" O Número total de keep alive timeouts lastRTTReport unsignedInt "-" O unsignedInt "-" O Último RTT en milisegundos Número de mensajes de conexión al management server recibidos. connect-mgmt-server Para constancia de la realización del protocolo de pruebas de interoperabilidad de CPEs ADSL2+ con We2 se firma el presente documento por los responsables de las Empresas participantes: Glosario 18 ACL ALG Anexo M ADSL DDNS DHCP DMZ IGMP IGMP Snooping LAN LLC Mapeo dirección IP y Una lista de control de acceso o ACL (del inglés, access control list) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido. En el contexto de las redes de computadoras , una puerta de enlace de nivel de aplicación [ 1 ] ( también conocida como ALG o puerta de enlace de capa de aplicación ) consta de un componente de seguridad que aumenta un cortafuegos o NAT empleado en una red de ordenadores . Este componente siempre debe estar en ejecución. Un estado parado significa la seguridad del sistema es vulnerable. Es un estándar de la ITU (Unión Internacional de Telecomunicaciones), también referido como 'ADSL2+M'. ITU G.992.5 Annex M amplía la capacidad del ADSL2+ doblando el número de bits de subida, sacrificando distancia en cobre. Línea de Suscripción Digital Asimétrica. ADSL es un tipo de línea DSL. Consiste en una transmisión de datos digitales (la transmisión es analógica) apoyada en el par simétrico de cobre que lleva la línea telefónica convencional o línea de abonado El DNS dinámico (DDNS) es un servicio que permite la actualización en tiempo real de la información sobre nombres de dominio situada en un servidor de nombres. El uso más común que se le da es permitir la asignación de un nombre de dominio de Internet a un dispositivo con dirección IP variable (dinámica). Esto permite conectarse con la máquina en cuestión sin necesidad de tener conocimiento de que dirección IP posee en ese momento. Dynamic Host Configuration Protocol - Es un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después. En seguridad informática, una DMZ o zona desmilitarizada (a veces referido como una red perimetral) es una subred física o lógica que contiene y expone los servicios de cara al exterior de una organización a una red más grande y no es de confianza, por lo general en Internet. El propósito de una DMZ es añadir una capa adicional de seguridad a la red local de una organización (LAN), un atacante externo sólo tiene acceso directo a los equipos en la zona de distensión, más que cualquier otra parte de la red. El nombre se deriva del término "zona de distensión", una zona entre los estados-nación en la que no se permite la operación militar. El protocolo de red IGMP se utiliza para intercambiar información acerca del estado de pertenencia entre enrutadores IP que admiten la multidifusión y miembros de grupos de multidifusión. Los hosts miembros individuales informan acerca de la pertenencia de hosts al grupo de multidifusión y los enrutadores de multidifusión sondean periódicamente el estado de la pertenencia IGMP snooping es el proceso de escuchar a Internet Group Management Protocol (IGMP) el tráfico de red. La característica permite a un conmutador de red de escuchar en la conversación IGMP entre hosts y routers. Al escuchar estas conversaciones el switch mantiene un mapa de enlaces que necesitan que las secuencias de multidifusión IP. Multicasts pueden ser filtrados de los enlaces que no los necesitan y por lo tanto los controles de los puertos que reciben tráfico de multidifusión específico. Local Area Network) es la interconexión de varios ordenadores y periféricos. Su extensión esta limitada físicamente a un edificio o a un entorno de 200 metros o con repetidores podríamos llegar a la distancia de un campo de 1 kilómetro. Su aplicación más extendida es la interconexión de ordenadores personales y estaciones de trabajo en oficinas, fábricas, etc., para compartir recursos e intercambiar datos y aplicaciones. En definitiva, permite que dos o más máquinas se comuniquen. Control de enlace lógico LLC ("Logical Link Control") define la forma en que los datos son transferidos sobre el medio físico, proporcionando servicio a las capas superiores. Para el funcionamiento de una aplicación en un determinado sistema, se produce cuando la conexión a Internet de dicho sistema atraviesa un dispositivo con 19 puerto NAT NAPT NTP PAT PPPoE puertos FXS SIP SNAP SNTP SSID VC-Mux. VOIP WAN capacidades de NAT o PAT (Network Address Translation – Port Address Translation), es decir, un dispositivo al que se conectan varias máquinas (cada una con su IP) y que les da salida a todas ellas a través de una IP única. Network Address Translation - Traslación de Dirección de Red es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se asignan mutuamente direcciones incompatibles. Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes transportados. También es necesario editar los paquetes para permitir la operación de protocolos que incluyen información de direcciones dentro de la conversación del protocolo. Netword Adrress and Port translation Traslación de direcciones de red por puerto. Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los efectos de la latencia variable. Port Address Translation es una característica del estándar NAT, que traduce conexiones TCP y UDP hechas por un host y un puerto en una red externa a otra dirección y puerto de la red interna. Permite que una sola dirección IP sea utilizada por varias máquinas de la intranet. Con PAT, una IP externa puede responder hasta a ~64000 direcciones internas. Point to Point Protocolo over Ethernet (PPPoE). Protocolo punto a punto sobre Ethernet. FXS (sigla de Foreing Exchange Station) es el conector en una central telefónica o en la pared de nuestro hogar, que permite conectar un teléfono analógico estándar. Hay unas tarjetas que sirven para conectar teléfonos analógicos normales a un ordenador y, mediante un software especial, realizar y recibir llamadas hacia el exterior o hacia otras interfaces FXS. Las tarjetas para conectar un ordenador a la Red Telefónica Conmutada son las FXO. Session Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual. El Subnetwork Access Protocol (SNAP) es un protocolo recogido por la norma IEEE 802 que permite direccionar diferentes protocolos utilizando un SAP (Service Access Point) público. Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los efectos de la latencia variable. El SSID (Service Set IDentifier) es un nombre incluido en todos los paquetes de una red inalámbrica (Wi-Fi) para identificarlos como parte de esa red. El código consiste en un máximo de 32 caracteres que la mayoría de las veces son alfanuméricos (aunque el estándar no lo especifica, así que puede consistir en cualquier carácter). Todos los dispositivos inalámbricos que intentan comunicarse entre sí deben compartir el mismo SSID. Multiplexación circuito virtual o VC -MUX es uno de los dos (el otro es la encapsulación LLC ) mecanismos para identificar el protocolo realizado en ATM Adaptation Layer 5 ( AAL5 ) fotogramas especificados por RFC 2684 , Encapsulación multiprotocolo sobre ATM. Voz sobre Protocolo de Internet, también llamado Voz sobre IP, Voz IP, VozIP, (VoIP por sus siglas en inglés, Voice over IP), es un grupo de recursos que hacen posible que la señal de voz viaje a través de Internet empleando un protocolo IP (Protocolo de Internet). Esto significa que se envía la señal de voz en forma digital, en paquetes de datos, en lugar de enviarla en forma analógica a través de circuitos utilizables sólo por telefonía convencional como las redes PSTN (sigla de Public Switched Telephone Network, Red Telefónica Pública Conmutada). Wide Area Network es un tipo de red de computadoras capaz de cubrir distancias 20 We2 Wi-Fi WLAN WPA2 WPS desde unos 100km hasta unos 1000 km, dando el servicio a un país o un continente. Un ejemplo de este tipo de redes sería Internet o cualquier red en la cual no estén en un mismo edificio todos sus miembros (sobre la distancia hay discusión posible). Muchas WAN son construidas por y para una organización o empresa particular y son de uso privado, otras son construidas por los proveedores de Internet (ISP) para proveer de conexión a sus clientes. El “Social WiFi” de We2 multiplicará el alcance del WiFi gratis llegando a áreas urbanas y residenciales con un objetivo: impulsar la interacción entre personas, comercios y la propia Ciudad Es un mecanismo de conexión de dispositivos eléctricos de forma inalámbrica. Es un sistema de comunicación inalámbrico flexible muy utilizado como alternativa a las redes de las área local cableadas o como extensión de estas. Usan tecnologías de radiofrecuencia que permiten mayor movilidad a los usuarios al minimizar las conexiones cableadas. WPA2 (Wi-Fi Protected Access 2 - Acceso Protegido Wi-Fi 2) es un sistema para proteger las redes inalámbricas (Wi-Fi); creado para corregir las vulnerabilidades detectadas en WPA WPA2 está basada en el nuevo estándar 802.11i. WPA, por ser una versión previa, que se podría considerar de "migración", no incluye todas las características del IEEE 802.11i, mientras que WPA2 se puede inferir que es la versión certificada del estándar 802.11i. Wi-Fi Protected Setup es un estándar del 2007, promovido por la Wi-Fi Alliance para facilitar la creación de redes WLAN. Esta función esta activa por defecto e un alto número de routers comerciales FIN DE DOCUMENTO RESPONSABLES: POR ETB POR EMPRESA ___________________________________ Nombre ETB ___________________________________ Nombre C. C. 21