Anexo A. TR.098 Parámetros específicos de fabricante

EMPRESA DE TELECOMUNICACIONES DE BOGOTA S.A. ESP
PRUEBAS DE INTEROPERABILIDAD CPE ADSL2+ 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 ADSL2
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. 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.
Cumple /
No Cumple
ADSL2 Actividad /Sincronismo
Actividad WIFI (802.11 b/g/n/AC)
Funcionalidad WPS y (opcional)
Observaciones:
Requerimiento
Tráfico TCP para red privada (router)
5. WAN
Cumple /
Requerimiento
No cumple
Tráfico UDP red pública (bridge)
Cumple /
No cumple
Observaciones:
Requerimiento
(ADSL) G.DMT ITU-T G.992.1
6. MODULACIÓN xDSL
Cumple /
Requerimiento
No Cumple
ADSL2+, G.DMT.bis plus ITU-T
G.992.5. anexo M
3
Cumple /
No Cumple
ADSL2+, G.DMT.bis plus ITU-T G.992.5.
(ADSL) G.Lite: ITU-T G.992.2
Auto-negociación del estándar xDSL
(ADSL/ADSL2+/ADSL2+M ) de
acuerdo con la configuración del
DSLAM
(ADSL2) G.DMT.bis ITU-T G.992.3
Para datos se require el perfil en los puertos
ADSL en Anexo M
Observaciones:
Requerimiento
7. 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
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 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.
DHCP Server tenga la función de
selección por diferentes SSID
Sincronización del módem por medio
de servidor NTP o SNTP.
Configurar un NAT y un PAT por PVC
Configurar un NAT y un PAT por VLAN.
Habilitar y/o deshabilitar NAT por
cada PVC en modo routing.
Soporte mínimo 16 host y/o componentes de
red en la LAN y
El fabricante debe traer los recursos para
Habilitar y/o deshabilitar NAT por
cada VLAN en modo routing.
4
Cumple /
No cumple
la ejecución y demostración de esta
prueba.
Habilitar el servicio NAT - IP MAPPING
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)
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
Configuración de una segunda
dirección IP en la LAN. La interfaz
debe trabajar con las dos direcciones
IP simultáneamente.
RIP versión 2
Observaciones:
Requerimiento
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
capa 2 y 3.
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
nivel DSL
5
Cumple /
No cumple
* 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.
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 el estado de cada PVC
El CPE debe mostrar SNR a nivel
WIFI
El CPE debe soportar TR-098
Observaciones: Observaciones: *Se validará de acuerdo con los recursos, si no es posible realizar la prueba el
OFERENTE deberá garantizar el cumplimiento de esta funcionalidad.
Prueba
11.1
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
Prueba
11.2
GESTION
Pasos de implementación
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
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.
CUMPLE
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
NO CUMPLE
GESTION
Pasos de
Resultados esperados
implementación
Ingresar a la plataforma
El CPE permite acceso a través de Telnet y por Http a
ACS
través del puerto XXXX y no permite acceso al HTTP
Modificar el parámetro de
a través del puerto 80.
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
Resultado
Comentarios
Requerimiento
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 (Customer), 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.
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 no se pueda cambiar la
contraseña del usuario o ningún
parámetro de la configuración WAN.
Validar que el usuario
Customer tenga acceso
ala configuración de
virtual server
Validar que el usuario
Customer tenga acceso
a configurar la opción de
DDNS.
Validar que el usuario
Customer 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
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.
Validar que aún se tiene gestión del
CPE a través de la plataforma del ACS
Resultado
CUMPLE
NO CUMPLE
Comentarios
13. SOPORTE DE VOZ SOBRE IP (VoIP) PARA CPE CON FUNCIONALIDAD IAD
Cumple /
Requerimiento
Requerimiento
No cumple
Softphone VALIDAR XLITE
Sofphone Counther Path Bria
Sofphone Audiocodes VMAS
Pruebas detalladas de Voz sobre
puertos FXS (Ver anexo pruebas VOZ)
Cumple /
No cumple
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
14. 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
Establecimiento de VPNs desde el
cliente hacia Internet (Passthrough
IPSec).
Filtros por direcciones MAC para
acceso a la red por medio de la
wireless
*Cantidad de conexiones simultaneas
del WiFi en grupos de 8, 16, 25 o
superior , OBLIGATORIA
Configuración SSID2 red privada en
router
Soportar múltiples SSIDs
Posibilidad de selección de canales WIFI
*Funcionalidad WPS, el recurso debe ser
demostrado por el fabricante
Configuración SSID1 red pública en bridge
Medición de la velocidad de los dispositivos
8
Cumple /
No Cumple
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
15. THROUGHPUT
Las pruebas de Throughput del apartado 15.1 se realizarán a cero (0) metros. Las pruebas
de Throughput del apartado 15.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.
15.1. TROUGHPUT A CERO METROS
SENTIDO DOWN
Cumple /No
Cumple
Requerimiento
Tráfico Unicast, MTU (1500 bytes),
CPE en modo bridge, durante 15
minutos debe tener un throughput de 17
Mbps
Requerimiento
Cumple /No
Cumple
Tráfico Unicast, MTU (1500 bytes), CPE
en modo router, durante 15 minutos
debe tener un throughput de 17 Mbps
*Dos (2) PVCs: El primero para 10 Mbps
de tráfico multicast, modo bridge, MTU
(1500 bytes) y el segundo para 7 Mbps
de tráfico unicast, modo router, MTU
(1500 bytes). El throughput debe ser
10Mbps / 7Mbps 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.
Tráfico Multicast, MTU (1500 bytes),
CPE en modo bridge, durante 15
minutos debe tener un throughput de 17
Mbps
15.2 TROUGHPUT CON DISTANCIA
DOWN
Requerimiento
Cumple /
No Cumple
Tráfico Unicast, MTU (1500 bytes),
CPE en modo bridge, a una distancia
de 100 metros, durante 10 minutos
debe tener un throughput de 16Mbps
Tráfico Unicast, MTU (1500 bytes),
CPE en modo bridge, a una distancia
de 2000 metros, durante 10 minutos
debe tener un throughput de 6 Mbps
Observaciones:
Requerimiento
Cumple /
No Cumple
Tráfico Unicast, MTU (1500 bytes), CPE
en modo bridge, a una distancia de
1500 metros, durante 10 minutos debe
tener un throughput de 10 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
Hw.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.
El 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:
PROCEDIMIENTOS DEL PROTOCOLO
Referencia
Requerimiento
15
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
Cumple
No
Cumple
Anexo A. TR.098 Parámetros específicos de fabricante “X_gowe2_com”.
Read
Parameter
InternetGatewayDevice.ManagementServer.
X_gowe2_com_managementserver
Type
Write4
7
Description
Define un servidor ACS secundario que tendrá
permisos de Lectura/Escritura de los parámetros
relacionados con We2.
URL del servidor secundario. Apunta al ACS de
We2.
Object
R
R
URL
InternetGatewayDevice.WANDevice.{i}.WAN
ConnectionDevice.{i}.X_gowe2_com_We2Tu
nnel
String(256)
R
R
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
KeepAliveIdleTimer
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
txDataPDUs
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.
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
currentServerIP
unsignedInt
"-"
O
currentServerPort
unsignedInt
"-"
O
Número total de Hello-Hotspot timeouts
IP del servidor de túneles (Access Controller) en
uso.
Puerto UDP del servidor de túneles (Access
Controller) en uso.
currentTWait
txKeepAliveIdleMessages
unsignedInt
"-"
O
Valor actual de Twait
unsignedInt
"-"
O
Número total de mensajes keepalive idle
txKeepAliveAbsoluteMessages
unsignedInt
"-"
O
unsignedInt
"-"
O
Número total de mensajes keepalive absolute
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.
rxKeepAliveAcks
connect-mgmt-server
Para constancia de la realización del protocolo de pruebas de interoperabilidad de CPEs
ADSL2+ más We2 se firma el presente documento por los responsables de las Empresas
participantes:
18
Glosario
ACL
ALG
Anexo M
ADSL
DDNS
DHCP
DMZ
IGMP
IGMP
Snooping
LAN
LLC
Mapeo
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
19
dirección IP y
puerto
NAT
NAPT
NTP
PAT
PPPoE
puertos FXS
SIP
SNAP
SNTP
SSID
VC-Mux.
VOIP
cuando la conexión a Internet de dicho sistema atraviesa un dispositivo con
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).
20
WAN
We2
Wi-Fi
WLAN
WPA2
WPS
Wide Area Network es un tipo de red de computadoras capaz de cubrir distancias
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