2.b pliego
DESCRIPTION
TRANSCRIPT
Página 1 de 124
PROYECTO TÉCNICO DE EJECUCIÓN
Implantación de infraestructura de red FTTH
neutra municipal y cabecera de televisión
Junta Vecinal de Arroyal
Página 2 de 124
1 MEMORIA
1.1 MEMORIA DESCRIPTIVA.
1.1.1 PROPIETARIO / PROMOTOR Junta Vecinal de Arroyal, pedanía de Alfoz de Quintanadueñas, provincia de
Burgos.
1.1.2 OBJETO
Implantación de infraestructura de red FTTH neutra municipal y cabecera de televisión
El objetivo del proyecto es la creación de una parte de la infraestructura de ingeniería
telecomunicaciones de red que permita en un futuro cercano dotar al municipio de Arroyal
de una topología de red tipo "Open Acces", que posibilite implementar servicios de banda
ancha, mediante el acceso en fibra óptica, al cliente final.
Dicha infraestructura permitiría crear y desarrollar una infraestructura tecnológica y de
innovación posibilitando la creación de nuevos servicios de valor añadido tanto a las
empresas instaladas como a las que se quieran establecer en el municipio, así como a sus
habitantes. Se fomenta el desarrollo tecnológico a través de la puesta en marcha de
servicios que acerquen progresivamente las nuevas tecnologías a toda la ciudadanía. Se
pretende por tanto, acelerar la penetración de la Sociedad de la información y del
conocimiento.
La red de fibra óptica potenciaría, el desarrollo de proyectos empresariales innovadores con
carácter tecnológico en sectores como el de las telecomunicaciones, la electrónica y la
informática.
Dicha red de fibra óptica asimismo podría permitir la diversificación del tejido económico
mediante el desarrollo de proyectos empresariales que giren en torno a la administración
Página 3 de 124
electrónica, la telefomación, la teleasistencia posibilitando un ahorro y un mejor servicio a
sectores como el de la tercera edad, teleasistencia sanitaria, comercio local etc
Esta red de fibra óptica pretendería conseguir los siguientes objetivos:
- Promocionar el uso masivo entre la población de los servicios y aplicaciones avanzados de
telecomunicaciones emergentes como son la videoconferencia y el tratamiento de
información multimedia.
- Facilitar el despliegue de infraestructuras de acceso a la información multimedia con
capacidad, calidad y eficiencia adecuadas.
- Añadir nuevos servicios a la oferta de servicios al ciudadano existente en el momento
actual.
1.2 MEMORIA CONSTRUCTIVA.
1.2.1 DESCRIPCIÓN DE LAS OBRAS A REALIZAR
1.2.1.1 Labores de ingeniería
El tendido, empalme y conexionado del cable, así como la obra civil necesaria para la
ejecución del sistema de canalizaciones u otras construcciones auxiliares requiere un
estudio previo de cada uno de los tramos o fases de ejecución para valorar y conocer las
necesidades y requerimientos de los mismos
Los principales aspectos a definir son los siguientes:
• Tipo de canalizaciones a ejecutar. Sus dimensiones, sección de tuberías, pavimentación y
acabados y tipo y composición de arquetas y de construcciones auxiliares
• Métodos de tendido a utilizar en cada uno de los tramos
Página 4 de 124
• Número y tipo de empalmes y segregaciones a realizar en cada tramo si los hubiera
• Número y tipo de cajas de empalme a instalar en cada tramo si los hubiera
• Metodología de limpieza y adecuación de canalizaciones existentes
• Definición del número aproximado de catas en caso de ser necesario
• Controles y exámenes de calidad de la obra civil. Estanqueidad, acabados, normativa
aplicable
• Controles y exámenes de calidad del cableado: Estudios reflectométricos OTDR
1.2.1.2 Canalizaciones
La estructura topológica correspondiente al sistema de cableado FTTH objeto del presente
proyecto se corresponde con la de un sistema de distribución por premisas árbol/estrella. Es
por esto por lo que el diseño del sistema de canalizaciones contemplado en este proyecto
viene definido por una estructura paralela.
Red de canalización de distribución Se considera canalización de distribución
al conjunto de troncales de canalización discurrentes entre el NODO
PRINCIPAL, o CPD, y los dos de acceso.
En todos las cajas de distribución , se deberán de instalar 2 tubos, uno
quedara ocupado por el cable de fibra y otro quedara libre para posibles
ampliaciones.
Página 5 de 124
1.2.1.3 Plataforma de pasivos FTTH
Para la elaboración del desglose de la fibra a desplegar se detallan los siguientes aspectos:
Topología y distribución
Estudio de las canalizaciones.
Construcción de la red
Conectividad
Implantación
1.2.1.4 Arquitectura, topología y estructura
La tecnología de telecomunicaciones FTTH (del inglés Fiber To The Home), también
conocida como fibra hasta el hogar, se basa en la utilización de cables de fibra óptica y
sistemas de distribución ópticos adaptados a esta tecnología para la distribución de servicios
avanzados, como el Triple Play, telefonía, internet, HDTV, etc. a los hogares y negocios de
los vecinos.
Se trata de una arquitectura basada en conductores de fibra ópticos del tipo SingleMode
(monomodo) y divisores ópticos pasivos (Splitters). En conjunto, se obtiene un sistema cuya
principal característica es la de carecer de elementos electrónicos susceptibles de averías,
cortes de alimentación, etc. El dispositivo divisor óptico, dependiendo de la dirección de la
transmisión, divide el haz entrante y lo distribuye hacia múltiples fibras o lo combina dentro
de una misma fibra. La filosofía de esta arquitectura se basa pues en compartir los costes
del segmento óptico entre los diferentes terminales, de forma que se pueda reducir el
número de fibras ópticas. Así, por ejemplo, mediante un splitter óptico, una señal de vídeo
se puede transmitir desde una fuente a múltiples usuarios.
La tecnología FTTH propone la utilización de fibra óptica hasta el domicilio del usuario. La
red de acceso entre el abonado y el último nodo de distribución puede realizarse con una o
dos fibras ópticas dedicadas a cada usuario (una conexión punto-punto que resulta en una
topología en estrella) o una red óptica pasiva (del inglés Passive Óptical Network, PON) que
usa una estructura arborescente con una fibra en el lado de la red y varias fibras en el lado
correspondiente a la red de dispersión/usuario.
Página 6 de 124
La topología en estrella/árbol provee de 1 ó 2 fibras dedicadas a un mismo usuario y en ella
se distinguen tres tramos o elementos estructurales.
Para cuantificar las inversiones que se precisan se ha dividido la red de acceso en
diferentes tramos, evaluando las necesidades de inversión en cada uno de ellos.
Los tramos considerados han sido los siguientes:
• Central GPON/FTTH (CPD): Ubicación donde se instala un equipo terminal de línea
óptica, OLT (Óptical Line Terminator), o nodo de terminación donde convergen las
FO procedentes de la red de distribución. En este apartado se considera la dotación
de un habitáculo técnico con los elementos necesarios tales como tabiquería y
pintura, pavimento técnico, aire acondicionado, fuerza y alumbrado.
• Red de alimentación o canalización principal. Nivel de distribución primaria: Es el
tramo de la red de acceso comprendido entre el repartidor óptico modular principal
(ROM-Principal), situado a la salida de la central hasta los repartidores ópticos
modulares secundarios (ROM-ZONA). Aquí se considera el coste del abatimiento,
conexionado y certificación del cableado FO, más el resto de elementos necesarios
tales como cajas o botellas de empalme, splitters (en caso de considerarse
necesarios) protecciones, señalizaciones, armarios y obra civil necesaria.
Los costes de este tramo se refieren a las UI actuales consideradas dentro del geotipo del
ámbito municipal de cada Zona, más un margen de crecimiento y escalabilidad de un 30%,
independientemente de que el despliegue de red de alimentación se efectúe de forma previa
a las solicitudes de conexión de los usuarios.
• Red de alimentación o canalización secundaria. Nivel de distribución secundaria:
Corresponden al tramo de red de acceso comprendido entre los ROM-ZONA y las CTO
(Caja Terminal Óptica) Aquí se considera el coste del abatimiento, conexionado y
certificación del cableado FO, más el resto de elementos necesarios tales como cajas o
botellas de empalme, protecciones, señalizaciones, armarios, obra civil necesaria y CTO’s
(Cajas Terminales Ópticas). Estas últimas irán dotadas de splitters de capacidad referida a
las UI actuales consideradas dentro de cada portal o RITU/RITI (en caso de que exista ICT),
más un margen de crecimiento y escalabilidad de un 30%, independientemente de que el
despliegue de red de alimentación se efectúe de forma previa a las solicitudes de conexión
de los usuarios.
Este aspecto viene apoyado por el hecho de que en nuevos desarrollos urbanísticos, las
infraestructuras de obra civil necesarias para albergar, entre otros, los servicios de
Página 7 de 124
telecomunicaciones son realizadas por los promotores y pueden ser cedidas a la
administración local.
1.2.1.5 Distribución
En este apartado se estudia la distribución de la red.
1.2.1.5.1 Central GPON/FTTH. Infraestructura para el CPD.
1.2.1.5.2 Red de alimentación o canalización
Se trata del nivel de distribución principal.
Listado, definición y ubicación de los nodos . Numeración de 01-NN
Estudio del trazado Central <-----------> Nodo tramo a tramo.
Informe sobre trazados sobre plano, identificación de las canalizaciones, características,
estado, fotografías.
• Nº y longitud de fibras destinados a cada nodo
• Descripción de la obra civil, en caso de ser necesario
1.2.1.6 Componentes
1.2.1.6.1 A) Canalizaciones
4.300 metros de Micro‐zanja de 15cm de profundidad y 1,5cm de anchura mediante
Página 8 de 124
Corte en aglomerado incluyendo extracción, soplado y retirada de Materiales sobrantes a vertedero autorizado. Instalación de fibra Óptica correspondiente y relleno de Zanja mediante mortero sin retracción SIKA GROUT
1.2.1.6.1 B) Acometida a viviendas
Se indicará un precio para la acometida a vivienda desde las cajas exteriores en el término
de Arroyal que incluya como mínimo 20 metros de cable óptico drop G-657, una hora de
instalación con 2 personas ,al menos una roseta óptica y latiguillo óptico entre roseta y ont.
Como el diseño de la red y el lugar de colocación de las cajas exteriores puede afectar el
precio de dicha acometida, formará parte de los criterios de valoración de diseño de red, por
lo cual se indicará en el Sobre «C».
Página 9 de 124
2 INTRODUCCIÓN CABECERA DE TELEVISION LASER
La demanda y necesidad de los usuarios de acceder a la información, y de los operadores de
proporcionar el servicio, hace que las redes de banda ancha estén experimentando un crecimiento tal
que conlleva una ampliación casi constante de las capacidades de las infraestructuras de banda
ancha. La evolución tecnológica, optimización de costes… hacen posible cada vez más, que la fibra
óptica pueda llegar hasta el hogar, siendo más demandada y los usuarios más exigentes con la
calidad del servicio que reciben. Hoy está a su alcance.
La distribución en redes CATV ha evolucionado en los últimos años, la Sociedad de la Información ha
experimentado un rápido desarrollo, debido, en gran parte, a la mayor competitividad impulsada por la
regulación del Mercado de las Telecomunicaciones y a la aparición de nuevos servicios de banda
ancha.
El resultado de estos dos factores se ha traducido en una necesidad de mejores redes de
comunicaciones capaces de ofrecer un mayor ancho de banda a un menor coste.
La actual tecnología ADSL, estrella indiscutible en el panorama europeo, utilizada por los operadores
telcos, tecnología que sigue explotando el bucle de abonado en cobre, presenta una limitación
importante. Aunque en nuevas versiones como ADSL2 y ADSL + el máximo ancho de banda que
puede ofrecer se acerca a los 20Mbps en canal descendente y los 4 en canal ascendente, estos
valores disminuyen drásticamente a medida que el usuario se aleja de la central, dando lugar al
conocido “problema de la última milla”. Igualmente redes de cable de operadores en coaxial, que
pasaron de dar servicio de Tv, a sumar el servicio de telefonía y acceso Internet mediante sistemas
de cablemodem DOCSIS y EURODOCSIS, no superan en sus primeras versiones la limitación típica
de 36Mbps.
La demanda de mayor ancho de banda hace replantearse a operadores sus estrategias, iniciándose
una carrera por el aumento de la velocidad y ancho de banda de sus servicios. En este sentido, la
tecnología de la fibra óptica se presenta como una firme solución al problema gracias a la robustez, a
su potencial ancho de banda ilimitado y al continuo descenso de los costes asociados.
Las Redes Ópticas Pasivas toman su modelo de las redes CATV, recicladas para ofrecer servicios de
banda ancha mediante la habilitación del canal de retorno. Esto exige la evolución de las redes
coaxiales a redes de arquitecturas mixtas HFC, FTTC. FTTB, redes CATV compuestas por varios
nodos ópticos unidos con la cabecera a través de fibra óptica, de las cuales se derivan, mediante una
arquitectura compartida de cable coaxial, los accesos a los abonados.
Página 10 de 124
Habitualmente en CATV cada nodo óptico ataca a un determinado número de usuarios (en función
del ancho de banda que se quiera asignar a los usuarios), utilizando cable coaxial y splitters
(divisores) eléctricos. Las redes ópticas pasivas sustituyen tramos de coaxial por tramos de fibra
óptica monomodo y derivadores eléctricos por divisores ópticos, llegando a la FTTH (fiber to the
home).
La arquitectura de futuro, las redes PON, se posicionan como apuesta fiable, por su coste contenido
en equipamiento y la eficiencia de las topologías, lo que aporta un incentivo adicional frente a los
despliegues tradicionales basados en conectividad punto a punto.
El despliegue de las redes de telecomunicaciones que transportan datos en el más amplio de los
sentidos, Triple-Play, requiere una gran inversión por parte de las operadoras, pero también abre la
oportunidad a otros actores en el mercado, mediante arquitectura de redes neutras. Por ello se está
popularizando el despliegue de redes ópticas pasivas (PON, pasive optical network), que permiten
desplegar redes de fibra hasta el hogar sin la necesidad de componentes activos intermedios entre la
cabecera y el hogar del usuario, siendo una solución al problema de la última milla.
Página 11 de 124
Redes Neutras
El concepto de "red neutral" no es único, pudiendo tener distintas matizaciones en función al contexto
de su utilización. En primer término podemos decir que su utilización es más común en el derecho y
la teoría política que en la ingeniería de redes. No obtente, el concepto de "neutralidad tecnológica"
puede utilizase en la relación entre la arquitectura de las redes y el marco de regulación de las
mismas.
En informes y trabajos realizados en la UE y en EEUU, en un intento de delimitar el régimen legal,
podemos ver el concepto de “red neutra”, que sin ser restrictivos para la expansión de las
telecomunicaciones, guiarán la actividad bajo pautas claras y principios de operación que aseguren el
buen funcionamiento de las redes y eviten la irrupción de monopolios que distorsionen las
condiciones de acceso a la información del usuario.
Redes PON
Una Red Óptica Pasiva (PON) se basa en tecnología punto multipunto, y permite eliminar todos los
componentes activos existentes entre la cabecera del proveedor de servicios de telecomunicaciones
y el usuario, introduciendo en su lugar componentes ópticos pasivos para encaminar el tráfico por la
red. La utilización de estos sistemas pasivos, cuyo elemento principal es el dispositivo divisor o
distribuidor óptico, también conocido como splitter, reduce considerablemente los costes de
instalación y mantenimiento de red.
Estructura de una red PON-FTTH
Una red óptica pasiva es una red punto-multipunto formada básicamente por:
La transmisión se realiza entre OLT y múltiples ONTs utilizando la red de fibra óptica común. En esta
red de fibra están presentes los divisores ópticos que son los responsables de encaminar la señal
procedente de la OLT a cada una de las ONT.
• Sistema OLT (Optical Line Terminal – Terminal
Óptico de Línea) localizado en las instalaciones del
operador.
• Red de fibra óptica monofibra con una topología
árbol-rama
• Divisor óptico (splitter)
• ONTs o ONUs (Optical Network Terminal o/&
User - Terminal Óptico de Red o/y Usuario), ubicadas
Página 12 de 124
Ventajas evidentes del uso en redes de la tecnología PON:
• Mayor distancia, permite dar servicio a usuarios localizados a distancias de hasta 20 Km
desde la central (o nodo óptico). Esta distancia supera con creces la máxima cobertura de
las tecnologías DSL (máximo 5Km desde la central).
• Minimizan el despliegue de fibra en el bucle local al poder utilizar topologías árbol-rama
mucho más eficientes que las topologías punto-a-punto.
• Simplifica la densidad del equipamiento de central, por el uso de las arquitecturas árbol-
rama, reduciendo el consumo.
• Mayor densidad de ancho de banda por usuario en redes ópticas pasivas, debido a la
mayor capacidad de la fibra para transportar información que las alternativas de cobre
(xDSL y CATV)
• La Superposición de señal óptica de Televisión procedente de una cabecera CATV en
otra longitud de onda, es permitida en arquitectura punto-multipunto, sin realizar
modificaciones en los equipos portadores de datos.
• Elevan la calidad del servicio y simplifican el mantenimiento de la red,
• Crecer a mayores tasas de transferencia superponiendo longitudes de onda
adicionales.
Las redes PON, aunque como concepto existen desde la década de los 90, solo en los últimos años
han alcanzado una madurez tecnológica para permitir que numerosos operadores comiencen a
utilizarlas en forma masiva. En estos momentos es la opción preferida para la construcción de futuras
redes de acceso al abonado, una vez agotadas las posibilidades de crecimiento de las tecnologías
xDSL.
El objeto del presente pliego es el suministro, integración e implantación de una plataforma que proporcione servicios avanzados de TV digital, tanto en formato MPEG-2 y MPEG-4 para recepción de contenidos en Alta Definición (HD) y contenidos de pago sobre una red FTTH.
De acuerdo a los requisitos necesarios para la puesta en marcha de la solución esta se basa en:
‐ Plataforma de recepción de canales digitales terrestres (TDT) además de canales de Satélite más puerta de acceso a canal local.
‐ Conversión de modulación a fibra óptica con la potencia necesaria para poder llegar a la ONT con los niveles adecuados.
Página 13 de 124
‐ Descodificador bidireccional MPEG-4/MPEG-2 que soporta HD además de puerto Ethernet con sistema de acceso condicional embebido que permite proporcionar servicios que se detallan más adelante:
o Servicios de suscripción. Paquetes básicos y premium o Servicios de OPPV (Ordered Pay Per VIew) o Servicios de IPPV (Impulse Pay Per View) o Servicios de PPT (Pay Per Time) o Servicios de NVoD (Near Video on Demand)
Los servicios de NVoD requieren una inversión adicional y se ofertan como una extensión de la
oferta básica.
2.1 Alcance
El alcance de la plataforma digital solicitada es:
12 mux Número de programas de TV 60
Número de usuarios Ilimitado
Número de paquetes de suscripción Ilimitado.
Observaciones importantes:
De la parrilla de programación de 7 mux TDT, vía terrestre se asume que llegarán al punto de
ubicación de captación de señal. Queda a disposición del cliente la agrupación de estos canales
para conformar los paquetes que permitan las distintas suscripciones a los abonados del sistema
de cable.
Página 14 de 124
3 DESCRIPCIÓN DEL PRODUCTO SOLICITADO
La plataforma IKCATV, consta de los siguientes subsistemas:
• Sistema de captación de señales digitales TDT y TV-SAT. • Plataforma digital de recepción, procesado y modulación de señales TDT y TV-
SAT • Conversión de la plataforma digital a señal óptica. • Sistema de acceso condicional para servicios de gestión y control TV digital por
cable de altas prestaciones. • Recepción de usuario, Set-top boxes (STB) de MPEG 4 / MPEG 2 de Alta
definición y puerto Ethernet.
3.1 Subsistema de captación de señal TDT y TV-SAT Este subsistema es el que tiene la función de la recepción de las señales de TV‐TDT y las de
TV‐SAT.
Están bien diferenciados los elementos para la captación de TV, las señales DVB‐T, COFDM de
la TDT en UHF, mediante antena yagi directiva y para la captación de las DVB‐S/S2 de satélite
se instalaran sistemas parabólicos. Para la recepción TV‐SAT se instalaran dos sistemas
parabólicos con sus correspondientes LNB´s cuatro para tener acceso a las distintas
polaridades horizontal/vertical (alta y baja), según se seleccionen los canales a distribuir.
Las señales RF, las COFDM y las QPSK/8PSK, serán transportadas mediante cableado coaxial
hasta los equipos de procesado y amplificación de RF/FI y conversión a señales ópticas.
3.2 Subsistema de procesado de señal TDT y TV-SAT Las señales ya recepcionadas por los sistemas de captación son procesadas
independientemente.
Las señales DVB‐T (TDT), mediante procesadores ágiles de señal con doble conversión
disponiendo filtros FOS en FI, siendo válido para el tratamiento de señales en MPEG‐2 y
MPEG‐4. Una vez procesadas las señale digitales, son amplificadas en potencia para atacar el
combinador TV‐TDT/TV‐SAT.
Las señales de TV‐SAT, tanto las DVB‐S/S2 y seleccionando la polaridad que se desea
distribuir, serán amplificadas por un sistema banda ancha de 950‐2150 MHz, uno por
polaridad, polaridades donde estarán los programas que posteriormente se desean visionar
en el usuario.
Página 15 de 124
Las señales TV‐TDT y TV‐SAT ya tratadas, amplificada y transmoduladas , señales procesadas
en los equipos en abierto o MultCrypt, Interfaz común, estando preparados para la insertar
PCMCIAS + tarjetas para canales incriptado, son mezcladas para atacar al transmisor óptico
doble que transportarán la señales ya digitalizadas de TDT y TV‐SAT.
Las señales digitales después de su paso por el transmisor óptico, encargado de la conversión
eléctrica/óptica, serán amplificadas para poder abordar la red de distribución FTTH. Las señal
de TV serán mezcladas mediante un wavelength con las señales de la OLT de Data, voz y
atacar a los spliters ópticos de la FTTH y cableado monomodo de la red multiservicio hasta los
ONT de usuario.
Se ha considerado para el calculado del conjunto óptica, transmisor y amplificadores ópticos,
que el rango mínimo de señal digital en la ONT son ‐20dBm.
Página 16 de 124
3.3 Arquitectura de la plataforma
En base a la información disponible suministrada por el cliente, se ha diseñado una
arquitectura centralizada, que tiene menores costes de inversión y de gestión. Esta
arquitectura de red está basada en una cabecera totalmente centralizada en la que las
señales de TV se captan en un punto central, donde se encriptan y multiplexan por medio del
Sistema de Acceso Condicional (CAS) vía VPN. Desde este punto único se distribuyen los
transport streams ya conformados a elección del cliente.
Los canales generados por el propio operador, como son típicamente los canales de
subscripción PPV, NVOD, local etc. se producirían también de manera totalmente
centralizada.
La arquitectura funcional de la solución técnica propuesta se muestra en la siguiente figura:
Jardín de Antenas
SMS
Anillo Optico
Internet
Sistema de recepción digital
Gestor local
Tx
ServiciosContenidos
CASMonitorización
Pto Azul
Terminal usuario
ONT
AmplFO
AmplFO splitter
splittersplitter
Arquitectura funcional de la plataforma
Página 17 de 124
En la figura aparecen los principales sistemas que configuran la plataforma técnica del
servicio:
CAS : Este sistema gestiona todo el empaquetado comercial de los canales de TV. Se encarga
de generar los flujos de ECMs y EMMs que se insertan en la Cabecera DVB a través de una
interfaz estándar DVB‐Simulcrypt. Dispone de una base de datos donde las principales
entidades son: las tarjetas, los eventos, los canales o servicios, los productos y los derechos.
• La interfaz SMS‐API: El sistema de gestión de clientes, denominado indistintamente CRM o SMS, se integra con el CAS a través de esta interfaz, cuyas principales funciones son: alta de tarjeta, baja de tarjeta, envío de derechos de un producto a una tarjeta y envío de un mensaje a una tarjeta o conjunto de tarjetas. El suministro del SMS no está incluido en el proyecto.
• Sistema de recepción digital: Este sistema se encarga de captar los programas en cofdm, qpsk.. (procendentes de las distintas antenas) multiplexarlo, encriptar las tramas MPG2/MPEG4 con DVB Simulcript y modularlo en QAM.
• Tx: Que permita la conversión de todas las salidas moduladas y covertirlas a óptica.
3.4 Descripción del Sistema Safeview Las características generales del Sistema son:
• Solución basada en tarjetas de alta seguridad que disponen de las certificaciones más exigentes del mercado. Para garantizar la más alta seguridad del sistema, las tarjetas estarán emparejadas con los STBs.
• Ofrece una gran versatilidad para la creación de nuevos productos de TV gratuitos, de pago y promociones, que pueden ser comercializados con modelos de negocio de tipo prepago y postpago.
• Diseñado para su rápida implantación en todo tipo de receptores.
• Uso extremadamente eficiente del ancho de banda para el envío masivo de derechos PPV, lo que permite alcanzar la máxima escalabilidad en la prestación del servicio.
• Capacidad para crear nuevos servicios de mensajería, fidelización y marketing directo asociados a los de TV de pago y subscripción.
• Cumplimento de estándares que permiten su integración inmediata con las cabeceras DVB.
• Funciones de control paterno, EPG y regionalización incorporadas.
• Integración sencilla con CRMs basada en interfaz webservice.
Página 18 de 124
Smart cards
El sistema Safeview está basado en el uso de una tarjeta inteligente criptográfica basada en
el estándar ISO‐7816. Esta tarjeta posee una gran capacidad de cálculo, con un procesador
criptográfico capaz de manejar claves RSA de hasta 2176 bits, ofreciendo el nivel de
seguridad más alto que permite el estado actual de la tecnología de tarjetas.
En la tarjeta reside la seguridad del sistema en lo que respecta a los receptores de los
usuarios. La tarjeta se aloja en un lector de tarjeta estándar en el STB.
La tarjeta puede estar emparejada con el STB desde fábrica, de tal forma que cada tarjeta
sólo funcione en su receptor correspondiente. El emparejado funciona a nivel de cada uno de
los servicios del bouquet del operador, es decir, el operador puede definir para cada uno de
sus canales si se aplica o no la condición de emparejado.
Todo el tráfico entre el STB y la tarjeta va encriptado para evitar el efecto denominado card‐
sharing.
Servicios comerciales soportados
El Sistema Safeview soportará los siguientes tipos de productos:
• Suscripción
A un conjunto de canales durante un periodo de tiempo definido (micro‐subscripciones de
uno o más días, semanas o meses) o por tiempo indefinido.
Soporta positive addressing, para la renovación automática periódica del derecho en caso de
suscripción por tiempo indefinido.
Soporta un número ilimitado de paquetes de paquetes de uno o más canales.
• Ordered PPV (OPPV)
El OPPV es el servicio mediante el cual el usuario realiza una petición de compra de un
producto PPV al operador a través de cualquier medio (Web, llamada telefónica a un call
Página 19 de 124
center, mensaje corto de móvil, etc.) Una vez efectuada la compra, el derecho se le envía a la
tarjeta del usuario a través de la señal de TV digital.
El producto PPV puede estar compuesto por uno o más eventos, localizados en uno o más
canales.
En caso de multidifusión de un evento PPV, por ejemplo de una película, el Sistema permite
definir el producto de las siguientes formas:
‐ Compra de un evento en una sesión específica (permite ver únicamente esa sesión del evento)
‐ Compra de un evento con derecho a ver todas las sesiones de ese evento un día específico. Esta modalidad se utilizaría por ejemplo en el caso de un servicio tipo NVOD.
‐ Compra de un evento con derecho a ver todas las sesiones de ese evento un fin de semana específico.
Existe la capacidad de asignar un periodo de preview a un evento, mediante el cual el usuario
con tarjeta podrá verlo durante un breve periodo configurable de unos minutos o segundos
sin disponer de los derechos pertinentes.
Es posible asignar el periodo de preview en cualquier momento de la emisión del evento.
El Sistema Safeview permite actualizar el saldo por el aire, de forma que cada vez que el
usuario incremente el saldo de su cuenta o si éste se reduce al adquirir un producto, la tarjeta
reciba una orden de actualización del saldo. Usando esta capacidad, el usuario podrá conocer
su saldo leyendo la tarjeta de forma local mediante su receptor.
Una vez que el usuario haya recibido la confirmación de compra de un producto PPV, tendrá
que esperar a recibir la EMM que contiene los derechos asociados antes de empezar a
disfrutar del evento. Para ello, el sistema dispone de la capacidad de enviar al usuario un
mensaje asociado a la recepción del derecho. Asimismo, el usuario podrá acceder a un menú
de su STB que le muestra los derechos recibidos.
• Impulse Pay per View (IPPV)
Este servicio permite adquirir un producto y generar los derechos asociados a éste de forma
totalmente local en la tarjeta, descontando el saldo almacenado en la tarjeta también de
forma local. Esta forma de PPV es muy cómoda para el usuario, porque la compra y el acceso
Página 20 de 124
resultan instantáneos y es muy útil para el operador en el caso de los eventos masivos, como
por ejemplo, un partido de fútbol, porque todo el proceso se realiza de forma local.
La compra y toda la interacción del usuario se realiza a través de una aplicación embebida.
Si el operador necesita saber qué eventos específicos ha consumido un usuario, es necesario
que el receptor disponga de canal de retorno. En este caso, el receptor se conecta
periódicamente, a un servidor denominado Data Collector Server (DCS) que recoge los
consumos y los carga en el CRM, consolidando así el saldo del usuario.
El Sistema Safeview permite configurar en cada tarjeta el periodo de conexión periódica al
DCS para enviar los consumos almacenados en la tarjeta. Al vencer el periodo de llamada, el
receptor se conectará de forma automática aunque no haya habido cambios en el estado de
los consumos desde la última conexión. El Sistema permite asimismo enviar a una tarjeta una
orden de conexión inmediata.
Safeview permite comercializar un evento o producto de PPV en modo OPPV e IPPV
simultáneamente. En este caso, si no fuera estrictamente necesario conocer de forma exacta
todos los consumos de IPPV, CABLE UNIÓN podría utilizar indistintamente OPPV e IPPV para
vender sus eventos y calcular los consumos globales de cada evento de forma estadística
utilizando como base los datos de OPPV.
El análisis de la necesidad de canal de retorno en los STBs y por tanto del uso del DCS se
realizaría durante la implantación de la plataforma. Este servidor es opcional y no está
incluido en este pliego.
• Pay Per Time (PPT)
Este servicio permite definir periodos de tiempo en minutos (contiguos o no contiguos) de
acceso a un conjunto de eventos o canales. El periodo de tiempo puede estar definido entre
dos fechas dadas. Cada vez que el usuario sintoniza el canal objeto del PPT, se arranca un
reloj local en la tarjeta que descuenta los minutos que le quedan hasta la extinción del
derecho.
Página 21 de 124
• Productos complejos
El Sistema Safeview es muy flexible y permite definir productos complejos a nivel del CAS con
las siguientes características:
‐ Productos compuestos por un conjunto de eventos y un conjunto de canales.
‐ Productos compuestos por un conjunto de eventos y un periodo de tiempo de acceso (PPT) a un conjunto de canales.
‐ Permite incluir nuevos eventos a productos ya creados y asignados sin necesidad de enviar derechos adicionales.
‐ El Sistema Safeview no tiene restricciones a la comercialización simultánea de un evento en múltiples productos, es decir, un mismo evento puede venderse a la vez en modo suscripción (es decir, puede estar incluido en un canal comercializado en modo suscripción), en modo PPV y en modo PPT.
Todos estos tipos de productos pueden comercializarse tanto en formato de OPPV como de IPPV.
• Eventos y canales de acceso libre con tarjeta
El Sistema permite definir eventos y canales “free to view” es decir que aunque no están en
abierto, son de acceso libre y no requieren derechos específicos. Este tipo de servicios
pueden ser útiles por ejemplo, para proteger a modo de control paterno, la emisión de
contenidos de adultos.
Ejemplo: acceso libre a contenidos de adultos a partir de las 12 de la noche si se dispone de
tarjeta.
• Mensajería
El CAS dispone de un potente servicio de envío de mensajes de texto del operador a los
usuarios, que tiene las siguientes características:
‐ La longitud máxima de los mensajes es de 1150 bytes
‐ Los mensajes pueden ser globales (dirigidos a todos los usuarios), o pueden estar dirigidos a un grupo de usuarios o a un usuario en particular.
‐ La recepción de un mensaje puede estar condicionada a que el receptor de éste tenga un perfil determinado.
Página 22 de 124
‐ El perfil almacenado en cada tarjeta puede tener hasta 512 características diferentes a definir.
Los mensajes se envían encriptados y van dirigidos a una tarjeta (se envían en forma de
EMM), a un grupo de ellas o a todas las tarjetas. Una vez recibido este mensaje, puede
presentarse en el receptor de las siguientes formas:
‐ De forma asíncrona, en el momento que se recibe. El mensaje se presenta en forma de banner.
‐ De forma síncrona asociada a la emisión de un contenido (en este caso es necesario automatizar su emisión o hacerlo manualmente).
‐ En la aplicación de compra de eventos, en una solapa dedicada a los mensajes del usuario.
‐ En el momento previo a la emisión de un evento en forma de banner o de pop‐up informativo.
• Servicios de fidelización
El sistema dispone de funciones de fidelización que permiten recibir mensajes publicitarios
asociados al perfil del usuario, obtener puntos por consumir publicidad, participar en juegos,
realizar apuestas sobre eventos televisivos, etc.
Los puntos obtenidos pueden ser utilizados para comprar eventos de pago.
Este servicio es opcional y no está incluido en este pliego.
Página 23 de 124
Interfaz SMS-CAS
Todas las peticiones recibidas y gestionadas por el SMS son enviadas automáticamente al
CAS. La comunicación entre ambos sistemas se realiza a través de una interfaz que tiene las
siguientes características:
• Orientado a Mensajes: Todas las peticiones se encapsulan en mensajes. Cada uno de los mensajes contiene la siguiente información:
‐ Identificación de operación.
‐ Parámetros de la operación.
• El procesamiento de cada una de las peticiones por parte del CAS no es instantáneo. Por tanto, la respuesta por parte del CAS a cada una de las peticiones se realiza en dos fases:
‐ En primer lugar se devuelve un mensaje que confirma la recepción de cada una de las peticiones.
‐ Una vez que la petición es procesada, se devuelve un mensaje que contiene el resultado del procesamiento.
• Las operaciones y parámetros principales ofrecidas por la interfaz del CAS son las siguientes:
Página 24 de 124
Mensaje Parámetros Descripción
create_product
Identificador producto
Lista derechos
Operación por la que el SMS notifica al CAS la creación
de un nuevo producto. El producto está compuesto por
una lista de derechos.
delete_product Identificador producto Operación por la que el SMS notifica al CAS la
eliminación de un producto.
create_right Identificador derecho
Servicio asociado
Evento asociado
Tiempo máximo visión
Inicio derecho
Fin derecho
Operación por la que el SMS notifica al CAS la creación
de un nuevo derecho. El derecho está definido por un
servicio y evento. Además puede incluir un tiempo de
visionado máximo (PPT), y un inicio y fin de validez.
delete_right Identificador derecho Operación por la que el SMS notifica al CAS la
eliminación de un derecho.
Add_right Identificador derecho
Dirección tarjeta
Operación utilizada para dar de alta un derecho o
evento a una tarjeta.
cancel_right Identificador derecho
Dirección tarjeta
Operación utilizada para cancelar la asignación de un
derecho o evento a una tarjeta.
Arquitectura Lógica del CAS
La arquitectura lógica del CAS se representa en la siguiente figura.
SMS/CRM
CAS SAFEVIEW SERVER
SMSIF EIS CMG
EMMG
GestorProgramación EventIF
CRM
Altas/bajas de tarjetas
Activación/desactivación de derechos
Monitorcontinuidad
PSIG
Gestor Programación
Programación de las cadenas emitidas por el operador
Multiplexor (DVB Simulcrypt)
Envío de EMMs
Generación de ECMs
Envío de EITp/f, EITsched
Scrambling management
Página 25 de 124
A continuación se describen cada uno de sus componentes:
EMMG (Entitlement Management Message Generator)
Es el proceso encargado de realizar la transmisión de las EMMs a los multiplexores instalados
en las cabeceras. La transmisión de las EMMs se realiza en modo carrusel, de forma que el
EMMG genera colas de EMMs que transmite de forma repetitiva.
Las colas de EMMs son modificadas permanentemente para:
•• Insertar las nuevas EMMs que se generan desde el MME.
•• Eliminar las que ya no deben ser transmitidas.
•• Reorganizar la cola para ajustar las prioridades de envío de las EMMs
El procesamiento del EMMG se basa, por tanto, en la ejecución permanente de un bucle en
el que se realizan las siguientes acciones:
•• Obtención y sincronización de las EMMs de la BBDD
El EMMG actualiza las EMMS que deben ser transmitidas eliminando aquéllas que han
caducado y añadiendo las que han sido generadas por el MME.
La caducidad de las EMMs depende del tipo de comando que incluyen:
•• Las EMMs globales contienen información necesaria para el funcionamiento de las tarjetas (claves, parches, etc.), y sólo caducan hasta que son reemplazadas.
•• Las EMMs de mensajes contienen avisos o información destinada a un usuario o grupo de usuarios determinado, y tienen una caducidad especificada por el operador del servicio.
•• Las EMMs de asignación y cancelación de derechos caducan cuando finaliza el evento.
•• Regeneración de las colas de EMMs y reasignación de prioridades
El EMMG reasigna la prioridad de envío de las EMMs cada vez que son transmitidas. Cuanta
menor es la prioridad de una EMM, más ciclos tarda en ser transmitida. La política de
asignación de prioridades se basa en los siguientes conceptos:
•• Número de transmisiones previas: La prioridad de la EMM disminuye cada vez que es transmitida.
Página 26 de 124
•• Proximidad del evento de pago relacionado: Las EMMs de asignación de derechos cobran mayor prioridad a medida que se aproxima el inicio del evento relacionado.
•• Envío de las colas de EMMs.
Una vez generadas las colas de EMMs, éstas son transmitidas a los múltiplex
correspondientes. El EMMG permite generar y administrar colas de EMMs específicas para
cabeceras regionales, donde sólo se insertan las EMMs relacionadas con los eventos
transmitidos en ellas.
La comunicación entre el proceso EMMG y el multiplexor cumple el estándar DVB Simulcrypt
(versiones 1 y 2) y, más concretamente, la interfaz EMMG<‐>MUX definida en ese estándar.
MME (Management Message Encryptor)
El proceso MME es el responsable de encriptar las EMMs que son generadas por el proceso
SMSIF.
Para realizar esta encriptación, el MME utiliza un dispositivo de alta seguridad (HSM) con
capacidades de encriptación hardware que permite realizar las siguientes acciones:
•• Almacenar las claves maestras utilizadas para la generación de las EMMs de mayor nivel jerárquico de una forma segura. El dispositivo garantiza la inviolabilidad de las claves almacenadas.
•• Generar y almacenar nuevas claves utilizadas para la encriptación de EMMs de menor nivel jerárquico.
•• Ejecutar los algoritmos utilizados para la encriptación de las EMMs, de forma que las claves no sean extraídas del dispositivo, con el fin de garantizar la seguridad de las mismas.
A medida que el MME encripta las EMMs las almacena en BBDD para su posterior envío por
parte del EMMG.
EIS (Event Information Server)
El EIS es el proceso encargado de gestionar la información acerca de todos los servicios y sus
perfiles asociados. Esta información irá incluida en las ECMs, y permitirá a las tarjetas validar
el acceso a un determinado canal según los derechos instalados en la misma. Asimismo, esta
información permitirá al EIS activar o desactivar la encriptación de cada canal.
El EIS realiza, por tanto, las siguientes acciones:
•• Atender a las peticiones del ECMG para la obtención del perfil de las ECMs.
Página 27 de 124
•• El EIS suministra el ECM_profile actualizado al ECMG cada vez que éste debe generar una nueva ECM.
•• Configurar el multiplexor para abrir o cerrar el canal según la información de los eventos almacenada en la BBDD.
El EIS consulta la información de los eventos de forma que, según el evento esté o no en
abierto, configura el multiplexor para parar o iniciar la encriptación del servicio asociado.
La comunicación con el multiplexor cumple el estándar DVB Simulcrypt y, más
concretamente, la interfaz EIS<‐>SCG definida en dicho estándar.
ECMG (Entitlement Control Message Generator)
El ECMG es el proceso encargado de generar y encriptar las ECMs correspondientes a cada
uno de los canales emitidos en modo cerrado.
La generación de las ECMs se realiza siguiendo los siguientes pasos:
1. Recepción de una petición del multiplexor
El ECMG se mantiene en espera de recibir una petición de generación de CW por
parte del SCS, mediante un mensaje de CW_provisioning, en el que se le envían las
CWs generadas por el multiplexor y el Access Criteria utilizado.
2. Petición de perfil al EIS
El ECMG obtiene del EIS el ECM_profile correspondiente al Acces Criteria
especificado.
3. Generación y encriptación de la ECM
El ECMG genera la ECM a partir de las CWs y el ECM_profile obtenidos, y la encripta
haciendo uso del dispositivo de alta seguridad (HSM).
4. Devolución de ECM
El ECMG envía al SCS la ECM generada utilizando el mensaje ECM_response.
La comunicación con el multiplexor cumple el estándar DVB Simulcrypt y, más
concretamente, la interfaz ECMG<‐>SCS definida en dicho estándar.
Página 28 de 124
GMMG (Global Management Message Generator)
El GMMG es el proceso encargado de generar EMMs de mensajes que van destinadas a una
tarjeta específica, a un grupo determinado de tarjetas, o a todas las tarjetas que cumplan un
criterio o tengan un perfil determinado.
El GMMG utiliza un algoritmo específico para cifrar estas EMMs. Una vez cifradas, las EMMs
son almacenadas en la BBDD junto a las generadas por el EMMG para que sean transmitidas
por el propio EMMG.
SMSIF (Subscriber Management System Interface)
El proceso SMSIF tiene como principales funcionalidades las siguientes:
•• Implementa la interfaz del CAS con el Sistema de Gestión de Usuarios (SMS)
Esta interfaz está definida en detalle en el documento “INTERFAZ SAFEVIEW SMS‐API”,
ofreciendo las siguientes operaciones:
‐ Definición de eventos de los radiodifusores
‐ Definición de productos
‐ Alta y baja de derechos a tarjetas.
El SMSIF arranca un determinado número de threads (establecido por configuración)
para atender las peticiones del SMS y balancear la carga. El proceso es capaz de atender
más de 500 peticiones de forma concurrente.
•• Almacena en BBDD las altas y cancelaciones de derechos recibidas desde el SMS.
Las peticiones son almacenadas en BBDD para su posterior tratamiento, ya que los
derechos individuales no son enviados de forma unicast.
•• Genera las EMMs multicast a partir de los derechos individuales almacenados previamente.
Cada cierto tiempo, (establecido por configuración), el SMSIF recorre la lista de nuevas
peticiones de altas y bajas de derechos y genera las EMMs multicast agrupando las
peticiones del mismo derecho para tarjetas que se encuentren en un mismo grupo
multicast.
Página 29 de 124
Esta estrategia permite conseguir un importante ahorro en las EMMs generadas y
enviadas, sobre todo en momentos en los que se producen picos de peticiones masivas,
ya que se puede llegar a encapsular un mismo derecho para 256 tarjetas en una única
EMM.
EventIF (Event Interface)
El proceso EventIF gestiona los mensajes procedentes de los radiodifusores indicando la
existencia de un nuevo fichero de programación.
El proceso accede al directorio especificado donde se encuentran estos ficheros, y genera los
eventos en BBDD.
Monitor de Continuidad
Este proceso atiende a los mensajes procedentes de los sistemas de continuidad de las
cadenas que señalizan el inicio y fin de los microeventos definidos en las escaletas de
programación.
La recepción de estos mensajes permite sincronizar de una forma automática y con un nivel
de exactitud máximo la encriptación de los canales con los contenidos que están siendo
emitidos, ya que se debe tener en cuenta que la programación de los canales puede incluir
eventos en directo. Esto ocasiona que el inicio o fin de los eventos que aparece en la
programación previamente insertada por los canales difiera de forma considerable de la
emisión real.
La sincronización evita los siguientes problemas:
•• Impide la emisión en abierto de contenidos que deben estar encriptados.
•• Impide la emisión en cerrado de eventos que deben ser emitidos en abierto.
•• Impide la emisión de contenidos encriptados asociando perfiles de acceso correspondientes al evento anterior o posterior, lo que permitiría que un usuario sin derechos para un evento pudiera acceder a él, o viceversa.
Página 30 de 124
PSIG (PSI Generator)
El proceso PSIG permite generar los descriptores privados asociados al sistema de acceso
condicional Safeview en las tablas de señalización.
Envío de derechos
La emisión de los derechos asignados a las tarjetas se realizará mediante EMMs que serán
emitidas en cada uno de los múltiplex donde se emitan servicios de pago. Para ello se
utilizará el ancho de banda destinado para tal fin en cada uno de los múltiplex.
Safeview utiliza un único canal de EMMs en cada múltiplex para el envío de toda la
información.
• Duración del envío de EMMs
Las EMMs de asignación de derechos se enviarán desde el momento de la compra hasta el fin
del evento al que corresponde el derecho.
• Priorización de EMMs
Safeview mantiene un sistema de prioridades para la emisión de EMMs que optimizan el uso
del ancho de banda utilizado. El sistema se basa en los siguientes conceptos:
‐ Las EMMs son enviadas mediante un carrusel.
‐ Las EMMs enviadas en cada vuelta del carrusel de EMMs son seleccionadas según su prioridad. Cuanto menor es la prioridad de la EMM más vueltas del carrusel pasan hasta que se envían.
‐ A las EMMs recién creadas se les asigna una prioridad máxima.
‐ La prioridad de la EMM decrece a medida que es transmitida en cada vuelta.
‐ A medida que se acerca el evento incluido en la EMM, su prioridad deja de disminuir. Cuando el evento está próximo a emitirse, las EMMs vuelven a cobrar prioridad máxima.
• Regionalización de EMMs
Página 31 de 124
Safeview permite emitir diferentes flujos de EMMs por cada múltiplex. Esta característica
permite enviar determinadas EMMs por un único múltiplex, de forma que se ocupe un
menor ancho banda en el resto.
Gracias a esta funcionalidad, se puede aplicar la siguiente estrategia:
‐ En la medida que sea posible, todas las EMMs serán enviadas por todos los múltiplex. Esta política permite al receptor recibir el derecho independientemente del canal al que está sintonizado.
‐ A medida que el volumen de EMMs es elevado, las EMMs que contienen derechos relativos a múltiplex con coberturas regionales o locales son emitidas únicamente por dicho múltiplex.
Soporte de peticiones concurrentes
El Sistema dispone de una gran capacidad de procesado de peticiones concurrentes de
compra de un producto masivo comercializado a través de OPPV.
El procesamiento de las peticiones se realiza en diferentes fases para mejorar el rendimiento.
Durante el proceso es imprescindible soportar la capacidad de procesamiento concurrente
en todos sus puntos. Existen tres puntos críticos en los que se garantiza esta capacidad:
• Sistema de ingesta de peticiones
Las peticiones se pueden realizar a través de SMS, interfaz Web o Call Center. Estas
peticiones son enviadas desde el SMS hasta el CAS a través de una interfaz basada en colas
de mensajes.
La arquitectura del CAS de Safeview permite crear un número elevado de procesos para
extraer y atender a estas peticiones y volcarlas en la BBDD del sistema. Estos procesos
pueden trabajar en paralelo reduciendo el tiempo requerido para su ingesta.
• Sistema de generación de derechos
El sistema de generación de derechos de Safeview está dividido en dos fases:
‐ Fase de generación de los comandos
Página 32 de 124
‐ Durante esta fase se seleccionan las peticiones de un mismo derecho para tarjetas de un mismo grupo multicast, y se genera el comando correspondiente.
‐ Fase de encriptación.
‐ La encriptación de los comandos se realiza por hardware. La tecnología utilizada asegura la encriptación de un mínimo de 500 peticiones por segundo.
• Emisión de derechos
La velocidad de emisión de derechos dependerá del ancho de banda disponible. Si por
ejemplo, se asigna un ancho de banda máximo de 200 kbps, gracias a la tecnología empleada
en Safeview, el número de derechos encapsulados puede llegar a ser de 51.200.
Integración con la cabecera DVB
La integración con la cabecera se realiza de forma totalmente estándar, utilizando el
protocolo DVB Simulcrypt.
Safeview es compatible con el protocolo DVB‐Simulcrypt, tal como se define en los
documentos “Head‐End Implementation of Simulcrypt” y “Digital Video Broadcasting (DVB);
DVB SimulCrypt; Head‐end architecture and synchronization”.
Safeview usa los siguientes protocolos definidos en el estándar para su integración con el
multiplexor:
• ECMG<->SCS
Este protocolo permite recibir las peticiones del multiplexor para la generación de ECMs a
partir de las CWs generadas por el mismo, y enviar las respuestas con la ECM generada.
• EMMG<->MUX
Este protocolo es utilizado por Safeview para el envío de las EMMs al multiplexor.
• EIS <-> SCS
Mediante este protocolo, Safeview implementa la capacidad de definición y gestión de los
diferentes grupos de encriptación. Este protocolo permite que Safeview pueda controlar el
paso de encriptado a abierto y viceversa.
Página 33 de 124
Arquitectura multicabecera
El sistema tendrá una arquitectura centralizada, de forma que desde el mismo sistema se
gestionan todos los multiplexores, independientemente del número de cabeceras en las que
estos multiplexores se distribuyan.
La integración con cada cabecera se realiza de la siguiente forma:
• Flujo de EMMs:
El Sistema permite definir diferentes flujos de EMMs, pudiendo emitirse cada uno de ellos en
uno o más múltiplex. Dependiendo del volumen global de EMMs, de las distintas coberturas
de los canales múltiples, así como del ancho de banda destinado al canal de EMMs en cada
uno de ellos, se podrán seleccionar diferentes configuraciones:
‐ Un flujo de EMMs idéntico para todos los múltiplex.
‐ Un flujo de EMMs específico para cada múltiplex.
‐ Una solución híbrida.
En todos los casos, la comunicación con cada uno de los multiplexores se realizará mediante una
conexión UDP compatible con el protocolo Simulcrypt.
• Flujo de ECMs:
Existirá un flujo de ECMs por cada multiplexor. La comunicación con el multiplexor se establecerá
mediante una conexión TCP compatible con el protocolo Simulcrypt.
Las necesidades de comunicación del CAS con cualquier cabecera con la que interactúa son
independientes de su ubicación. Estas necesidades son las siguientes:
‐ Un flujo UDP único unidireccional para cada multiplexor con un caudal máximo de 200 kbps, de acuerdo a los requisitos de este proyecto. Por este flujo viajarán las EMMs.
‐ Un flujo TCP bidireccional para cada servicio en cada multiplexor. Por él se transmitirán dos mensajes en cada ciclo de un cryptoperiodo. En este caso, es importante que el tiempo de latencia sea el menor posible. Este flujo sirve para provisionar las ECMs requeridas por el multiplexor para cada servicio
En el caso de cabeceras distribuidas, será necesario establecer un enlace de comunicaciones
punto a punto entre el servidor central y la cabecera remota para transportar estos dos flujos.
Como por este flujo viajarán en abierto las CW, será necesario crear entre los dos extremos del
enlace una VPN securizada utilizando el protocolo IPsec.
Página 34 de 124
El tráfico entre las cabeceras, sean locales o remotas, y el CAS, estará protegido por un
cortafuegos en configuración redundante 1+1.
Si los requisitos de disponibilidad global del servicio de pago son altos, sería necesario establecer
un enlace de comunicaciones redundante en modo activo‐activo.
Información de EPG y datos privados
Safeview soporta el envío de información de la Guía Electrónica de Programación (EPG) de forma
estándar según la norma DVB “EN 300 468 Specification for SI in DVB systems”. La información se
adquiere desde un sistema externo, típicamente una base de datos de programación, si el
operador dispone de este sistema, o desde Internet, accediendo directamente a la parrilla de
programación publicada en su página Web por los proveedores de contenidos.
Creación de Productos
Los productos pueden crearse directamente en el CAS y exportarse al CRM, o bien pueden
crearse en el CRM y exportarse automáticamente al CAS a través de la interfaz SMS‐API.
En el segundo caso puede utilizarse la herramienta de creación de productos incluida dentro del
sistema Safeview. Esta herramienta está basada en interfaz Web.
Como ya se ha comentado, la creación de productos permite cualquier combinación de eventos
a uno o más productos (ver figura).
Página 35 de 124
Derecho 1
Derecho 3
Derecho 5
Derecho 2
Derecho 4
Derecho 6
Producto 3Producto 2
Producto 1
SubscripciónServicio: 2
PPVServicio: 1Evento 68898
PPTServicio: 310 horas
PPVServicio: 1Evento 1135
PPVServicio: 1Evento 11223
PPVServicio: 1Evento 322
ProductDefinitons
ProductGen
La interfaz de usuario de la herramienta de creación de productos de Safeview se muestra en la
siguiente figura.
Página 36 de 124
Especificaciones técnicas
Servidor de alta disponibilidad
Doble fuente de alimentación.
Doble procesador dual core
RAID 5.
4 GB RAM
Sistema Operativo SUSE Linux Enterprise Server 10
Base de datos MySQL 5.1
3.5 Set top boxes Se solicitan unos receptores de altas prestaciones pero de bajo coste. Equipos estándar con
tecnología muy probada en múltiples operadores y que se distribuyen en todo el mundo,
incluyendo mercados tan exigentes como el del Reino Unido.
Las cajas solicitadas deben hacer uso de las características de la tecnología Simulcrypt que
permite el uso de más de un Sistema de Acceso Condicional sobre la misma red.
Las características mínimas del equipo son las siguientes:
Se trata de un equipo híbrido QAM‐IP de muy altas prestaciones basado en el chipset
Celestial CSM que soporte la norma de video MPEG4 con resolución HD y que dispone de
capacidad de lectura y grabación digital (PVR ready). Es un equipo con tecnología muy
robusta y probada y que se está desplegando de forma creciente entre los operadores de
cable que quieren ofrecer servicios de video bajo demanda en formato IP y servicios
interactivos avanzados.
El receptor incluirá el sistema operativo Linux y el middleware MHEG5 y con una completa
plataforma de desarrollo de aplicaciones incluida, que permita al operador desarrollar y
descargar aplicaciones Linux y aplicaciones MHEG5 en el receptor de forma totalmente
autónoma.
Este receptor dispondrá de características avanzadas como:
Página 37 de 124
• Preparado para recibir video bajo demanda en formato IP hasta el hogar a través de la interfaz Fast Ethernet. Esta característica estará disponible en junio de 2010.
• Incluye el middleware estándar MHEG5, por lo que está preparado para ofrecer servicios interactivos avanzados como por ejemplo, Punto Azul. IKUSI pondrá a disposición del operador un entorno de desarrollo de aplicaciones MHEG5 para que disponga de la capacidad de incluir y descargar nuevas aplicaciones MHEG5 en el STB por sí mismo, limitado así el grado de dependencia con el suministrador.
• La capacidad de leer y grabar contenidos multiformato en un disco duro o memoria Flash externa (PVR‐ready) en formatos FAT32 y NTFS.
• Soporta Time Shift TV local sobre disco duro o memoria flash externa.
• Salida de audio digital óptica S/PDIF.
• Una EPG de 7 días con capacidad de grabación automática de eventos cuya funcionalidad se adaptará sin coste adicional a los requisitos del operador.
• Una miniguía o navegador de canales con capacidad de inserción de banners publicitarios interactivos.
• Conversión de audio Dolby Downmix.
• Descarga segura de SW (OTA securizada).
• Emparejado con la tarjeta.
• 7 botones en el panel frontal
• Ofrece una interfaz de usuario avanzada para ofrecer servicios de PPV, VoD y mensajería.
• Sistema operativo Linux. IKUSI ofrece al operador el entorno de desarrollo y el entrenamiento necesario para que disponga de la capacidad de incluir y descargar nuevas aplicaciones Linux en el STB por sí mismo, limitado así el grado de dependencia con el suministrador. Safeview verifica internamente la seguridad de las aplicaciones.
Frontend
DVB‐C compliant ITU‐J.83 Annex B
RF & Demodulation
Frequency Frequency range 50‐860 Mhz
Modulation Modulation 16, 32, 64, 128 y 256 QAM, in accordance
with EN 300 429
Bandwidth 6 MHz
Video
Página 38 de 124
Decode
• Support for high definition, high profile H.264 standard at level‐4.1 (1080i capable)
• Support for MPEG‐2 high definition main profile at 1080i
Encode Support PAL, NTSC, SECAM, 480p, 576p, 720p, and
1080i formats.
Output 6‐channel DAC (YPbPr/RGB, S‐video and Composite)
HDMI output
OSD
Color: 32‐bit true color
Alpha blending: 256 levels
2 graphics layers
Advanced 2D BLTer Engine
Number of channels 4000
Audio
Decode • Decodes MP1, MP2, MP3, AC3, AAC streams • 5.1‐channel decoding and down mixing
Sampling rate 32KHz, 44.1KHz, 48KHz
Output Stereo, mono‐left, mono‐right
S/PDIF digital audio output
Front panel
IR remote
7~8 buttons on Front panel.
LED for display.
Rear panel
IEC female x 1 (RF in)
IEC male x 1 (loop through)
Analog Audio Twin RCA Stereo audio outputs (left and
right)
Optical audio digital S/PDIF
1 HDMI output
RCA video composite output
Y/Pb/Pr output
POWER
Página 39 de 124
Smartcard Reader ISO 7816
Ethernet port RJ 45
Power Supply
100‐240 V AC @ 50‐60 Hz
PVR
PVR ready USB PVR ready
USB drive support USB 2.0 & FAT32
Supported formats MP3/MP4/JPEG/External HDD recording
Other aspects
Event programming Yes
User Interface customized with the
operator logo Yes
Languages available Spanish, English, French, Italian, German, Portuguese.
Installation assistant Yes
Seven days EPG for PVR, PPV and
Time Shifting services Yes
Radio Mode Yes
SW download through USB Yes
QAM Signal quality level indicator Yes
Format 4:3 / 16:9 Yes
Punto Azul and other MHEG5
applications Yes
DVB Subtitles EN 300 743 Yes
DCII Subtitles Yes
Logical channel number ordenation Yes
Remote firmware download (OTA) Yes, secured by Safeview. Authorized User Mode and
Automatic Mode are supported.
Linux Operating System Yes, secured by Safeview
Environmental
Página 40 de 124
Operation temperature 0 – 50 ºC
Operation humidity 90%
Storage temperature ‐15 ~ 70 ºC
Dimensions 280mm X 127mm X 37mm
Weight 1,2 Kg.
Interfaz de usuario del receptor
El receptor incluirá una aplicación embebida con interfaz de usuario avanzada para el acceso
a los servicios de PPV, en modalidad OPPV e IPPV. Esta aplicación se alimenta
automáticamente a través de Safeview, incluyendo textos, gráficos e imágenes.
La aplicación tendrá las siguientes características destacadas:
• Incluye mecanismos de control paterno a nivel de evento.
• Soporta los servicios OPPV e IPPV.
• Dispone de capacidad multimedia (imágenes). Todos los componentes de la aplicación se renuevan automáticamente en modo broadcast de acuerdo a los productos definidos por el operador y a sus ventanas de publicación.
• Dispone de capacidades de regionalización. Es posible segmentar la oferta de productos mostrada por la aplicación de forma regionalizada e incluso por perfiles socio‐demográficos.
• Dispone de capacidades de mensajería avanzada. Es posible segmentar los mensajes a nivel individual (una tarjeta) y de grupo (un conjunto de tarjetas), en base al perfil almacenado en cada tarjeta, que dispone de hasta 512 características de cualquier tipo (sociales, geográficas, etc.)
• Tiene una interfaz de usuario muy atractiva y amigable, que puede personalizarse de acuerdo a los requisitos del operador.
A continuación se muestran, a modo de ejemplo, algunas pantallas de la aplicación.
Página 41 de 124
Página 42 de 124
Arquitectura software del receptor
El software del receptor está organizado en tres capas:
Core de Safeview
Contiene el código de Safeview. Este software es propietario, y se suministra al fabricante
mediante una librería.
Capa de adaptación
Capa que debe desarrollar el fabricante a partir de unas cabeceras suministradas por
Safeview. Permite la integración con los drivers del receptor.
APIs de alto nivel
API para la integración con la aplicación del receptor. Ofrece las funciones necesarias para
verificar si hay derechos para desencriptar el video, comprobar el estado de la tarjeta,
comprobar la compra de productos, recibir mensajes, etc.
La siguiente figura muestra la arquitectura en capas del descodificador.
Safeviewhigh-level API
Applicationlayer
Loyalty APIBasic API CAS API SmartCard API
SafeView core softwareSafeview
layer
Safeviewadaptation
layerPSI
adaptationDemux
adaptationSmartcardadaptation
Descrambleradaptation
Manufacturerlayer drivers
Return channeladaptation
OSDadaptation
Actualizaciones software de los terminales
Las actualizaciones del software del receptor se realizarán de forma completamente segura.
Las nuevas versiones se enviarán por la red de cable firmadas por medio de Safeview.
Página 43 de 124
Safeview incluye una herramienta que genera un par de claves, pública y privada para cada
modelo de descodificador. La clave pública se envía al fabricante del receptor para que la
incluya en el módulo que realiza la comprobación del software. La clave privada la guardará
el operador en un lugar seguro. El receptor rechazará toda versión que no haya sido firmada
por la clave privada. . El mecanismo utilizado para señalizar dicho servicio es el SSU (System
software Update) definido por el DVB en ETSI TS 102 006.
3.6 Sistema de recepción digital Constará de dos chasis enracables de una unidad de altura. La configuración recomendada
por sencillez de configuración y manejo es la de dos sistemas independientes, con pasos por
IP y ASI .
El sistema completo contará con la siguiente configuración:
• La configuración de la cabecera estará compuesta por 7 mux COFDM y 8 mux de QPSK/8PSK entrada
• Disponibilidad para el acceso de embebidas de los scramblers necesarios.
• Salida con tarjeta QAM, con multiplexación.
• Sistema de modulación QAM/F. ÓPtica
La siguiente figura muestra una configuración estándar del equipo aunque en el momento de
la instalación se personalizará según la lista de canales definitiva y previo acuerdo con el
cliente.
Página 44 de 124
3.7 Subsistema de Playout (opcional) El subsistema de playout consta de un servidor de vídeo de 2 entradas y una salida con
capacidad para operar en modo de captura y de emisión.
La salida del servidor se realiza en formato MPEG2‐TS SD.
El sistema dispone de una herramienta de playlist que automatiza la emisión de cada uno de
los cuatro canales.
Página 45 de 124
4 ACTIVIDADES Y CALENDARIO DEL PROYECTO
El proyecto se ha configurado con la posibilidad de llave en mano y consta por tanto, de todas las
actividades necesarias para la puesta a punto de la Plataforma. El proyecto concluirá cuando el
servicio que presta esté plenamente operativo.
El plan de proyecto consta de las siguientes tareas:
• Ingeniería: Estudio y diseño del sistema de recepción, transporte y funcionalidades del Terminal de acuerdo a las necesidades presentes y futuras.
• Análisis de la integración técnica: En esta tarea se realizará un análisis detallado de la plataforma técnica, con objeto de conocer, entre otros:
• La interfaz de provisión de su sistema de gestión de clientes (SMS)
• Implantación de la Plataforma: En esta tarea se completará la instalación, configuración y puesta a punto de la Plataforma en las instalaciones de acuerdo a los requisitos de integración del cliente.
• Soporte in situ. Durante un periodo de una semana se prestará soporte técnico in situ con objeto de que la transferencia de conocimiento sea lo más efectiva posible. Las labores a realizar serán:
‐ Operación de la plataforma.
‐ Administración de cambios de configuración, si fueran necesarios.
‐ Resolución de incidencias.
‐ Formación y transferencia de conocimiento a los ingenieros encargados de operar el sistema.
El soporte será prestado por un ingeniero de soporte senior. Este ingeniero estaría soportado
remotamente por el Grupo de Soporte de nivel 3.
La duración prevista de cada una de las actividades es la siguiente:
Actividad Duración (semanas)
Análisis de la integración técnica con la plataforma 6
Implantación de la Plataforma. 0,5
Soporte in situ 1
Página 46 de 124
Este pliego no incluye las labores de integración con el SMS (Sistema de Gestión de
Abonados/Clientes), cuyo diseño se realizará previamente durante la fase de “Análisis de la
integración técnica” al comienzo del proyecto.
Página 47 de 124
5 SOPORTE Y MANTENIMIENTO
Se incluirá un soporte continuado en horario de oficina para los sistemas ofertados.
• Soporte Técnico in situ
• Soporte Técnico de segundo nivel
• Gestión de incidencias
5.1 Soporte Técnico in situ Un técnico desplazado a las instalaciones del cliente realizará durante dos semanas y siempre
dentro del ámbito del proyecto, las tareas de administración relacionadas con:
• Sistema operativo (Linux, Windows) y administración de Base de Datos
• Comunicaciones que a su vez estuviesen relacionadas con las comunicaciones de la solución ofertada
• Servidor CAS
Además de las tareas descritas anteriormente, este grupo prestará soporte para la resolución de
eventos y de productos.
El horario de trabajo de este grupo será inicialmente de 9:00 a 14:00 y de 15:00 a 18:00 in situ.
5.2 Soporte Técnico de segundo nivel Un servicio de soporte técnico remoto con disponibilidad 24 X 7 actuará de soporte a la
operación fuera del horario presencial del soporte “In Situ” mediante correo electrónico y
diagnóstico remoto. Este servicio de soporte se mantendrá pasadas las dos primeras semanas en
las que actuará el soporte in situ anteriormente descrito.
Página 48 de 124
5.3 Gestión de incidencias El nivel de servicio ofrecido para la resolución de incidencias será:
Ref. Tipo de Incidencia
Nivel Descripción
Tipo 1 Emergencia
El software licenciado es inoperable por completo y el
entorno de producción se encuentra parado. Procesos
críticos han fallado o por razones desconocidas, no se
pueden arrancar.
Tipo 2 Urgente
El software licenciado es operacional pero el problema no
se puede evitar; ciertos procesos no‐críticos fallan o, por
razones desconocidas, no se pueden arrancar
Tipo 3 Medio El software licenciado es operacional y el problema se
puede evitar.
Tiempo de respuesta Tiempo de resolución
• 80% inmediato • 20% 2 horas
‐ Tipo 1 ‐ 100% < 8 horas
‐ Tipo 2 ‐ 70% < 24 horas
‐ Tipo 3 ‐ 30% < 72 horas
Página 49 de 124
INSTALACION DE FIBRA OPTICA
Toda la instalación de fibra óptica, que se debe de desplegar, deberá cumplir con el objetivo
de llegar hasta las cajas de distribución de las viviendas, desde los servicios técnicos de
este ayuntamiento, se ha diseñado una red que se refleja a continuación, con unos criterios
que deberán de cumplir cualquier diseño distinto que se presente:
• Todo el diseño, de la red deberá de contemplar el tendido de cables sin empalmes
entre el CPD y las cajas terminales de usuarios (CTU), no están admitidos los
empalmes o botellas, porque se considera, que las tiradas no son excesivamente
largas y de esta forma se evitan problemas futuros.
• La tecnología que se instalara en una segunda fase, será GPON. Con índice de
splitting 1:32
• El criterio de capacidad de fibras de cada cable viene dado por la cantidad de
usuarios finales en la caja, este documento presenta uno tipo, pero será necesario
que cada ofertante presente el que crea adecuado, una vez vista la instalación. Se
valorara que todas las tiradas, tengan fibras y capacidad vacante.
• Las Cajas CTU deberán estar dentro de un armario que las proteja en las
localizaciones que estén a una altura que se puedan tocar sin medios mecánicos y
en el exterior, esto deberá definirlo el ofertante, este ayuntamiento decidirá entre
todas las ofertas, cual es la más adecuada.
• Toda la instalación de los cables de fibra se entiende que incluye, cable, pigtails,
paneles, conectores, enfrentadores, pasa muros, armarios, fusiones, en ambos
lados, CPD y CTU, necesarias y la mano de obra necesaria para su instalación
incluso los medios mecánicos y herramientas que se tengan que comprar o alquilar
para la ejecución de los trabajos. No se admitirá ninguna proposición que no lo
incluya.
• Todas las ofertas, deberán de detallar todos los materiales ofertados, con sus
características y sus correspondientes importes unitarios.
• Todas las fusiones deberán de tener una perdida igual o inferior a 0,05dB, no se
admitirán mediciones superiores.
• Toda la instalación deberá de documentarse, con planos en papel y formato
electrónico, preferiblemente CAD, así mismo se presentaran todas las mediciones de
fibra mediante OTDR.
Página 50 de 124
• Toda la fibra que se instale , deberá de tener las características constructivas
detalladas a continuación:
Realización de empalme (FUSION) de cable de fibra óptica
Deberá realizarse el empalme de cable de fibra óptica por medio del método de arco de
fusión, incluida la preparación de puntas del cable, de modo que todas las fibras queden
correctamente empalmadas y con sus protecciones colocadas, etiquetando los empalmes
con sistemas de larga duración. Protección y ubicación de los empalmes en la
correspondiente caja, incluyendo el suministro del protector de empalme correspondiente.
Sellado de los subconductos de entrada a la caja de empalme.
No serán admitidos empalmes mediante gel o los denominados pre-pulidos en fábrica.
Se realizarán pruebas de reflectometría OTDR SM en ventanas operativas, así como
instalación y conectorización de cable en repartidor óptico incluyendo la instalación del cable
en repartidor, su conectorización por medio de pigtail incluida la preparación de las puntas
del cable, y la instalación de los conectores necesarios de modo que todo el cable (todas
sus fibras) quede perfectamente instalado y conectorizado de acuerdo a los requisitos y
especificaciones recogidas en el presente documento.
Página 51 de 124
Especificaciones técnicas de la construcción del cable:
Parámetros a cumplir de la fibra Estándar y
normas Unidades Valor requerido
Cable compuesto de :
Elemento Resistente Central (ERC) : Plástico reforzado
con fibra de vidrio aislado con polietileno EN 187000 Cumpla
Tubo holgado: material termoplástico, conteniendo fibras
ópticas agrupadas en dos grupos unidos por ligaduras y
relleno con un compuesto de estanqueidad
EN 187000 Cumpla
Elementos pasivos: varillas de material termoplástico EN 187000 Cumpla
Tubos holgados y elementos pasivos cableados en SZ
alrededor del ERC EN 187000 Cumpla
Estanqueidad del núcleo óptico: elementos absorbentes de
la humedad( núcleo seco) EN 187000 Cumpla
Refuerzo dieléctrico: hilaturas de aramida (≥ 56500 dtex) EN 187000 Cumpla
Cubierta exterior de polietileno de baja densidad de color
negro. Bajo la cubierta se colocan dos cordones de
rasgado
EN 187000 Cumpla
Nº de fibras EN 187000 Hasta 512
Nº fibras por tubo EN 187000 Hasta 12
Nº tubos / rellenos capa interna EN 187000 Hasta 4/2
Nº tubos/ rellenos capa externa EN 187000 hasta12/-
Ø exterior de tubo holgado EN 187000 mm 3,5
Ø del ERC / Ø del ERC aislado EN 187000 mm 3,0/ 3,8
Espesor cubierta exterior EN 187000 mm 1,5
Diámetro del cable EN 187000 mm
Peso del cable EN 187000 kg/km 330
Características medioambientales y mecánicas que debe
cumplir el cable :
Max. tensión de trabajo EN 187000 -
501
4200 N con criterio de aceptación: Sin
alargamiento de fibra ∆α ≤ 0,05 dB / 50 m ∆lc≤ 0.6
% Sin daños
Aplastamiento EN 187000 -
504
2000 N / 100 mm con criterio de aceptación
∆α ≤ 0,05 dB. Sin daños
Impacto EN 187000 -
505
5 J, 3 impactos, 10 mm con criterio de aceptación
∆α ≤ 0,05 dB. Sin daños
Página 52 de 124
Radio de curvatura EN 187000 -
513
≥ 15⋅∅cable (mm)
≥ 250 mm 5 giros, 3 ciclos con criterio de
aceptación ∆α ≤ 0,05 dB.
Ciclos térmicos EN 187000 -
601
-25 ºC to + 70 ºC con criterio de aceptación ∆α ≤
0,05 dB/km.
Estanqueidad EN 187000–
605B
1 m cable, 1 m agua, 14 días sin penetración de
agua en el núcleo óptico
Coeficiente de atenuación
EN 188000 -
301 o 302 o
303
λ= 1310 nm
λ= 1550 nm
αλ ( 1310 nm):
Media< 0.36 dB/Km
Máxima < 0.39 dB/Km
αλ ( 1550 nm):
Media< 0.22 dB/Km
Máxima < 0.26 dB/Km
Código de color de las fibras en el tubo
4 grupos de 8 fibras (1-verde 2-rojo 3-azul 4-
amarillo 5-gris 6-violeta 7-marrón 8- naranja) ( uno
sin marcado en anillo, otro con 1 anillo, otro con 2
anillos y otro con 3 anillos)
Código de color de los tubos holgados
Tubos capa 1 :blanco,rojo,azul y verde. Tubos
capa 2
blanco,blanco,blanco,rojo,rojo,rojo,azul,azul,azul,v
erde,verde,verde
Marcado del cable
Fabricante
-año de fabricación
Propietario: -Ayuntamiento Alfoz de
Quintanadueñas-
Número y tipo de fibras en el cable
Marca de metraje
Página 53 de 124
Conductores: Se utilizarán fibras ópticas del tipo monomodo, con índice gradual 9/125 y con características reflejadas en tabla adjunta:
Parámetros a cumplir de la fibra Estándar y normas Unidades Valor requerido
Debe cumplir IEC / EN 60793-2-50 Categoría B.1.3
Debe cumplir ITU-T Recomendaciones G.657.A, G.657.B y G.652.D –
También debe cumplir las tablas A,B,C de la ITU-T G.652 .
Debe cumplir EN 50 173-1:2007, cat. OS2; también se deben cumplir
los requerimientos OS1
Debe cumplir la ISO / IEC 11801:2002, cat. OS1
Debe cumplir la ISO / IEC 24702: 2006, cat. OS2; también se cumplen
los requerimientos OS1
Debe cumplir la IEEE 802.3 – 2002 incl. 802.3ae
Atenuación en cable a 1310 nm EC 60793-1-40 dB/km ≤ 0.36
Atenuación en cable a 1383 nm (Envejecida con H2 de acuerdo a IEC
60793-2-50 tipo B.1.3) EC 60793-1-40 dB/km ≤ 0.36
Atenuación en cable a 1550 nm EC 60793-1-40 dB/km ≤ 0.21
Atenuación en cable a 1625 nm EC 60793-1-40 dB/km ≤ 0.22
Max. cambio en la atenuación en el intervalo 1285 - 1330 nm EC 60793-1-40 dB/km ≤ 0.03
Max. cambio en la atenuación en el intervalo 1525 - 1575 nm EC 60793-1-40 dB/km ≤ 0.02
Max. cambio en la atenuación en el intervalo 1460 - 1625 nm EC 60793-1-40 dB/km ≤ 0.04
No homogeneidad de la traza del OTDR para cualquiera de las dos
longitudes de 1000 m EC 60793-1-40 dB/km Max. 0.1
Índice de refracción de grupo a 1310 nm IEC 60793-1-22 1.467
Índice de refracción de grupo a 1550 nm IEC 60793-1-22 1.467
Índice de refracción de grupo a 1625 nm IEC 60793-1-22 1.468
Diámetro del revestimiento IEC / EN 60793-1-20 µm 125.0 ± 0.7
No circularidad del revestimiento IEC / EN 60793-1-20 % ≤ 0.7
No circularidad del núcleo IEC / EN 60793-1-20 % ≤ 6
Error de concentricidad núcleo-revestimiento IEC / EN 60793-1-20 µm ≤ 0.5
Diámetro del recubrimiento primario -coloreado IEC / EN 60793-1-21 µm 242 ± 7
Diámetro del recubrimiento primario IEC / EN 60793-1-21 % ≤ 5
Erro de concentricidad recubrimiento primario-revestimiento IEC / EN 60793-1-21 µm ≤ 10
Página 54 de 124
Coeficiente de dispersion cromática IEC / EN 60793-1-42
En el intervalo 1285 nm – 1330 nm ps/km • nm ≤ │3│
At 1550 nm ps/km • nm ≤ 18.0
Longitud de onda de dispersion cero, λ0 nm 1312 ± 12
Pendiente de dispersion cero ps/(nm2 • km) ≤ 0.092
Longitud de onda de corte λcc IEC / EN 60793-1-44 nm ≤ 1260
Diámetro del campo modal a1310 nm IEC / EN 60793-1-45 µm 8.9 ± 0.4
Diámetro del campo modal a 1550 nm µm 9.9 ± 0.5
Pérdida por macrocurvaturas : IEC / EN 60793-1-47 dB
10 vueltas en un mandril de radio 15 mm a 1550 / 1625 nm ≤ 0.03 / ≤ 0.1
1 vuelta en un mandril de radio 10 mm a 1550 / 1625 nm ≤ 0.1 / ≤ 0.2
1 vuelta en un mandril de radio 7.5 mm a 1550 / 1625 nm ≤ 0.5 / ≤ 1.0
Coeficiente de dispersión del modo polarizado (PMD) max. No
cableado IEC / EN 60793-1-48 ps/√km ≤ 0.1
Valor del PMDQ Link (calculado con Q=0.01%, N=20) IEC / EN 60794-3 ps/√km ≤ 0.06
Proof test IEC / EN 60793-1-30 Gpa ≥ 0.7 (≈ 1 %
alargamiento)
Radio de curvatura de fibra IEC / EN 60793-1-34 m > 4
Fuerza de pelado (valor de pico) IEC / EN 60793-1-32 N 1.3 ≤ Fpelado pico ≤
8.9
Resistencia a la fatiga dinámica envejecida y sin envejecer (Nd) IEC / EN 60793-1-33 ≥ 20
Resistencia a la fatiga estática (Ns) IEC / EN 60793-1-33 ≥ 23
Página 55 de 124
♦ Control de calidad del cable de fibra óptica
Todos y cada uno de los materiales deberán contar con su certificado de calidad y entregar
las pruebas de fábrica o laboratorio que certifican su calidad y buen funcionamiento.
Para verificar que el cable de fibra es entregado sin daños, se deberán realizar las pruebas
indicadas en la tabla adjunta. Dichas pruebas se realizarán en presencia de inspectores
designados por la Junta Vecinal de Arroyal pudiendo ser técnicos del propio ayuntamiento
de Alfoz de Quintanadueñas o por personal que la Junta Vecinal de Arroyal designe para tal
efecto, se realizarán en las instalaciones del fabricante del cable, o laboratorio homologado
en la unión europea, indicadas por el adjudicatario. Se emitirá, a la finalización de dichas
pruebas, acta de recepción de los cables comprobando su correcta calidad. Los costes de
las citadas pruebas y los de traslado, manutención y alojamiento si los hubiese de los
inspectores designados por este ayuntamiento correrán en su totalidad a cuenta del
adjudicatario.
El adjudicatario, realizara todas las gestiones y controles necesarios para asegurar el
cumplimiento de las especificaciones objeto de este pliego.
Para la aceptación del suministro, los resultados obtenidos de las pruebas, deberán cumplir
los criterios reflejados en el presente pliego.
En el caso, de que una prueba realizada sobre una muestra del total del suministro, no
supere el correspondiente criterio de aceptación, descrito en este pliego, la Junta Vecinal de
Arroyal, se reserva el derecho a rechazar total o parcialmente el suministro. Así mismo y a
criterio exclusivo de la Junta Vecinal de Arroyal si no se cumpliesen una o varias de las
pruebas y no se superasen algún o algunos de los criterios de aceptación descritos en el
presente pliego, el adjudicatario estará obligado a proporcionar un nuevo suministro que
satisfaga los criterios de aceptación de este pliego, realizando las mismas pruebas de
aceptación que al suministro original, pero en este caso se realizaran sobre el 100% del
suministro. Todos los gastos derivados de dicho rechazo, incluyendo la fabricación de
nuevas bobinas como la realización de nuevas pruebas de aceptación, correrán a cargo del
adjudicatario.
La Junta Vecinal de Arroyal, se reserva el derecho a realizar cuantas pruebas considere
necesarias para determinar el cumplimiento de las especificaciones recogidas en este
pliego.
Así mismo con objeto de asegurar la calidad de los materiales, sólo se aceptarán ofertas
de fabricantes de cables que cuenten, al menos, con certificación ISO-9001 e ISO-14.000
Página 56 de 124
debidamente avalados por entidades certificadoras de reconocido prestigio. Dichos
certificados, se deberán de entregar junto con la oferta. La falta de los mismos supondrá la
eliminación directa del proceso de adjudicación.
PRUEBAS DE ACEPTACION CABLES (obligatorias)
DESCRIPCION NORMA
APLICABLE EQUIPO FRECUENCIA
CABLE FINAL
ATENUACION @ 1310 Y @1550 nm. EN-188000-303 OTDR 100%
DIAMETRO DE LA CUBIERTA
EN 60811 MEDIDOR DE
PERFILES
1 muestra por
turno, maquina y
tipo de producto ESPESOR RADIAL DE LA CUBIERTA
DENSIDAD DE LAS CUBIERTAS ASTM D792-91 BALANZA
Pruebas a realizar
en al menos un
cable en
recepción.
RESISTENCIA A LA TRACCIÓN Y
ALARGAMIENTO DE LAS CUBIERTAS
EN 60811 DINAMOMETRO
GOTEO O FLUIDEZ EIA/TIA FOTP81 ESTUFA
ESTANQUEIDAD EN187000/605B COLUMNA DE AGUA
LONGITUD DE ONDA DE CORTE EN-188000-313
BANCO ÓPTICO
Pruebas a realizar
en al menos un
cable en
recepción. Se
medirá una fibra
por tubo
COEFICIENTE DE DISPERSIÓN EN-188000-309
PMD IS 61941-INTERFEROMETRIA
TRACCION DEL CABLE EN-187000-501
BANCO DE
ENSAYOS
MECANICOS
Pruebas a realizar
en al menos un
cable en
recepción. Se
empalmará una
fibra por tubo
IMPACTO EN-187000-505
TORSION EN-187000-508
CURVADO EN-187000-513-1
APLASTAMIENTO EN-187000-504
CICLO TÉRMICO EN-187000-601 CÁMARA
CLIMATICA Pruebas a realizar
en al menos un
Página 57 de 124
PROPAGACIÓN DE LA LLAMA (CABLES
IGNÍFUGOS)
IEC 60332-1 PROPAGACIÓN DE
LA LLAMA
cable en
recepción
5.3.1 Descripción del equipamiento activo de la red FTTH propuesta
5.3.1.1 Introducción Las comunicaciones están evolucionando rápidamente hacia la convergencia de servicios y
aplicaciones sobre IP. Esta convergencia alcanza a las redes de transporte que se
consolidan y adaptan al transporte generalizado de paquetes.
Ethernet es la tecnología preferida para el transporte de tráfico IP al ser simple y económica.
Sin embargo su origen en las redes de empresa hace que no esté adaptada a los
requerimientos de una red destinada a soportar aplicaciones de tipo crítico. Entre los
problemas más destacables están la lentitud de restauración ante fallos y la inestabilidad
introducida en redes de cierta complejidad.
La introducción de MPLS en la red Ethernet permite eliminar los problemas tradicionales de
esta tecnología. MPLS va a dotar a la red ethernet de escalabilidad, estabilidad, fiabilidad,
QoS y soporte multiservicio.
De esta forma la red de transporte Ethernet sobre MPLS se presenta como una alternativa
segura de evolución de la red de transporte tradicional hacia una red de paquetes a prueba
de futuro.
El presente documento describe la propuesta técnica y el equipamiento que propone la
Junta Vecinal de Arroyal para el desarrollo de la red de comunicaciones mediante tecnología
Ethernet sobre MPLS (EoMPLS).
La red propuesta cumple con todos los requisitos de capacidad exigidos y la orienta al
transporte de servicios basados en Ehernet con un aumento de prestaciones en los puntos
de intercambio de tráfico.
Para la red de transporte, la solución propuesta se basa en nodos IP/MPLS, para el
conformado de VPNs de nivel 3 (IP), desarrollándose una red IP/MPLS extremo a extremo.
Para ello, se propone una combinación de nodos de Acceso y el gestor de red.
Página 58 de 124
Para proporcionar los puertos TDM que son necesarios para transportar los primarios se
instalaran los Router´s de Acceso a Servicio de la familia de equipos MPLS.
5.3.1.2 Diseño de Alto nivel de la solución. Red de Core y Agregación
5.3.1.2.1 Descripción del Equipamiento
Para la red de transporte, se presentan las características de la gama de equipamiento de nodos
IP/MPLS. Se incluyen asimismo las descripciones técnicas, del equipo a utilizar para el transporte de
enlaces síncronos E1 mediante la emulación de circuitos en redes de paquetes (CES – Circuit
Emulation Service).
Los equipos necesarios han de ser diseñados desde su origen para el soporte de servicios en
entornos de operador a diferencia de otros equipos que han evolucionados a partir de conmutadores
tradicionales de empresa por lo que no pueden soportar en entorno real el nivel deseable de
prestaciones.
Deberá estar reconocido por los principales operadores mundiales y estar presente en las principales
redes de nueva generación IP/MPLS en el mundo.
El fabricante del equipo, deberá tener un compromiso con la implementación de protocolos estándar
permitiendo una interoperación fácil con otros elementos de la red evitando problemas de operación
o el despliegue de redes “cautivas” de un único suministrador.
Los Conmutadores de Servicio o routers IP/MPLS estarán diseñados y optimizados para proveer
servicios avanzados de Internet y Red Privada Virtual (VPN) basados en Ethernet.
Los routers de altas prestaciones deberán de contar con múltiples características de chasis
disponibles.
5.3.1.2.2 Equipamiento elegido
La funcionalidad deberá ser la misma en todos los equipos ofertados.
La familia de equipos ofertados estará dotada con la tecnología única de procesadores de red
capaces de ser configurados con la flexibilidad que aporta el software y con las prestaciones
Página 59 de 124
de las configuraciones basadas en HW (tecnología denominada “Flexible Fast Path”). Esto
hace que todos los procesos ejecutados en los nodos se desarrollen a velocidad de línea
completa (hasta 50Gbps en las tarjetas actuales), pudiéndose implantar futuros desarrollos de
protocolos o servicios sin necesidad de migración de hardware, a diferencia de otros
fabricantes que necesitan de HW específico para integrar nuevas funciones.
La capacidad del HW de los equipos ofertados hará que sea viable dotar a una red de servicios
ethernet/IP/MPLS con características de calidad de servicio del estilo de ATM/FR. La
capacidad de conformar velocidades a la carta para cada usuario de red basándose en
parámetros como CIR, PIR, CBS y MBS, hacen que cada servicio obtenga de la red los recursos
necesarios para su funcionamiento en cuanto a ancho de banda, retardos y latencias, puesto
que se consigue que el comportamiento de la red de paquetes sea predecible.
Adicionalmente, los equipos ofertados deberán garantizar una velocidad de conmutación de
enlaces y recuperación del servicio en caso de fallo sub‐50ms. Se ha probado la restauración
de hasta 4000 servicios VPLS en menos de 50ms.
Los equipos deberán recoger y guardar una amplia y variada información de contabilidad de
los servicios configurados, de manera que es sencillo generar una facturación o informe de
uso por cliente basándose en múltiples parámetros (tráfico cursado, ancho de banda
contratado, destinos accedidos, etc..)
En el aspecto de la gestión y operación de la red, se incorporará un sistema de gestión, que en
conjunto con las capacidades de las herramientas de análisis y resolución de problemas
integradas en los equipos ofertados, hacen que de una manera rápida y fácil se tenga en todo
momento conocimiento del estado de la red y de los servicios que esta soporta.
Además se incorporaran a los nodos ofertados prestaciones de Non Stop Routing y Non Stop
Services, que garantizan una fiabilidad de 99,999% de la red, integrando capacidades de
actualización de software (parches) sin impacto en el tráfico.
99,999% de Disponibilidad
Página 60 de 124
1. Protocol Reconvergence Standard operation of routing networks. Route around the failed node.
2. Non - stop Forwarding Router continues forwarding traffic during recovery.
3. Graceful Restart Uses neighbors to help recovery. Uses non - stop forwarding
during recovery.
4. Non - Stop Routing Router self - recovers. Transparent to neighbors.
5. Non - Stop Services Extends non - stop routing to Layer 2
/ Layer 3 VPN services.
’ 00:00:00:0 X
milliseconds 00:00:00:0 X milliseconds
00:0 X:XX:XX minutes
MEAN TIME TO REPAIR
• In‐Service Software Upgrades (ISSU) para no detener el servicio
o Minimiza el tiempo de parada en cambios de versiones.
• Non‐stop routing para multicast (PIM‐SM y PIM‐SSM)
o Primer router en garantizar la disponibilidad de los servicios IP multicast.
• Non‐stop routing en IS‐IS y BGP para IPv6
• Stateful IGMP switchover
o Garantiza la continuidad del tráfico multicast, mantiene las traslaciones de IGMP SSM
y los joins de IGMP cuando se produce el cambio de controladora.
• IGMP synchronization Para soporte de redundancia multi‐chasis
o En el empleo de MC‐LAG, el estado de las suscripciones IGMP se mantiene
sincronizado entre los routers.
Página 61 de 124
• Selección del grupo de enlaces agregados basado en QoS, para garantizar la prestación del
servicio.
Diferencias entre Non-Stop Routing y Graceful Restart
Durante un failover de una controladora, en GR (Graceful Restart) la controladora redundante se
apoya en los routers cercanos para acelerar la convergencia de las tablas de routing, pero ha de
crearlas de nuevo.
Con Non‐Stop Routing no es necesario aprendizaje, las tablas de routing están completamente
sincronizadas entre ambas controladoras.
Veamos algunas pruebas de laboratorio:
Durante la prueba se inyectan rutas para el router aprenda y permita converger la tabla de
routing. En un generador se analizan las rutas aprendidas y se dibuja una gráfica.
Durante un failover de una controladora, en GR (Graceful Restart) la controladora redundante se
apoya en los routers cercanos para acelerar la convergencia de las tablas de routing, pero ha de
crearlas de nuevo.
3 rd party GR router
Newly inactive control plane
Newly active control plane
3 rd Party GR Router
Control Plane Switchover
-
Non - Stop Routing Node - level Recovery
Graceful Restart Network - level Recovery
Control Plane Switchover
RIB
RIB RIB
RIB
RIB
Página 62 de 124
Con Non‐Stop Routing, no es necesario aprendizaje, las tablas de routing están completamente
sincronizadas entre ambas controladoras.
Veamos algunas pruebas de laboratorio:
Durante la prueba se inyectan rutas para el router aprenda y permita converger la tabla de
routing. En un generador se analizan las rutas aprendidas y se dibuja una gráfica.
Time
New RoutesLearned
Peer CPULoading
100%
control planecontrol planeswitchoverswitchover
100%
“ Stop-and-Restart-Routing”Network-impact, Peers Help
Time
100%
Non-Stop RoutingPeer CPULoading
100%
New RoutesLearned
control planecontrol planeswitchoverswitchover
Graceful Restart
“ Non-Stop” RoutingSelf-contained & Transparent
Peer“Help”
No Peer CPU Loading
Headless Forwarding
Constant Route Learning
Fast ConvergenceSlowConvergence
Diferencia notable en la convergencia
320 seconds
Routes150k
Time950 sec
Routing Stops for 320 seconds“ Headless Forwarding”
Peer CPU loading >80%Convergence Time(Graceful Restart)
Graceful Restart
Página 63 de 124
Mientras que con la tecnología Non‐Stop Routing :
Non-Stop Routing
Según lo expuesto, el equipamiento Service Router sera capaz de aprender a un ritmo de
10.000 rutas por segundo, lo que implica una reducción muy importante en el tiempo de
recuperación cuando un equipo pierde conectividad o sufre un apagado.
En lo referente a la capacidad de gestión de tráfico IP, como muestra de las excelentes
capacidades de los equipos, los nodos ofertados, serán capaces de procesar hasta 1 millón de
rutas por VPRN (Servicio IP‐VPN).
Con una arquitectura de software y hardware diseñada desde el principio para el suministro
eficaz de servicios basados en SLA, los equipos ofertados, funcionaran como una plataforma
flexible de suministro de servicios VPN basada en Ethernet así como proporciona una óptima
operación de los servicios. Esto permitirá al equipo ofertado conformar, además de redes IP
convencionales, redes privadas de nivel 3 IP basadas en IP/MPLS, redes privadas de nivel 2
Ethernet basadas en control IP/MPLS, posibilitando los siguientes servicios:
Servicios y redes basados en IP
Ethernet VLLs (Virtual Leased Lines).
Routes
1M
Time
100 sec
Time to Learn 1M Routes:
–
“ non - stop routing ” negligible impact
of switchover (no “ flat - line ” )
Figure 11 – BGP Convergence Including Hardware Induced Switchover, 1 Million Prefixes 2 orders of magnitude
- 10 times more routes - 1 tenth the time
Convergence Time (Non - Stop Routing)
Página 64 de 124
Multi‐punto L2 VPNs (Servicio LAN Privado Virtual (VPLS)).
BGP/MPLS VPNs (RFC2547bis) (Sólo 7750).
Acceso Mejorado a Internet (IES – Internet Enhanced Service). Enrutamiento optimizado de
tráfico IP.
Mientras que los routers convencionales están diseñados para transportar sólo tráfico best‐
effort agregado, los equipos ofertados, podrán transportar decenas de miles de servicios
individuales utilizando túneles flexibles IP y MPLS con QoS por puerto o servicio y
contabilidad.
5.3.1.2.3 Generalidades
Los nodos que se ofertarán, deberán suministran prestaciones que alcanzen los 40 Gbps Full Dúplex.
Se suministrara un equipo con un “Network Processor Array” (NPA) completamente programable, el
cual es el corazón del equipo.
La primera versión del FP llegó a 10Gbps, mientras que el nuevo FP2 alcanza velocidades de
100Gbps. Todos estos valores habría que multiplicarlos por 2 para equivalencia con otros fabricantes
que siempre entregan sus valores en conmutación agregada o Half Dúplex.
Cada módulo I/O de un Service Router incorpora un par de motores de reenvío flexible –
subsistemas de procesado y de memoria intermedia (buffer) en la red que activan aplicaciones que
necesitan un filtrado con detalle de paquetes y una flexibilidad completa. Cada módulo suministra
una velocidad en el soporte físico (cable) de hasta 100Gbps, independientemente de las
funcionalidades activadas, incluyendo VPNs con QoS y Listados de Control de Acceso (ACLs), etc.
Concretamente para el equipo ofertado se emplea sendas controladoras con líneas de FP2 de
40Gbps.
Las capacidades de estas funcionalidades son activadas dentro de grandes procesadores dedicados y
optimizados para la manipulación de paquetes, en un único dispositivo denominado “Network
Processor Array (NPA)”.
Ese diseño representa una importante mejora frente a otras soluciones alternativas tales como los
ASICs (que no disponen de flexibilidad suficiente a la hora de programarlos), los procesadores
Página 65 de 124
disponibles en el mercado (que caen entre los dos ideales de flexibilidad y prestaciones) y los
procesadores de uso general (que no tienen prestaciones).
Con una arquitectura optimizada para la manipulación de paquetes, la tecnología “Flexible Fast Path”
consigue unas prestaciones muy superiores a lo que era hasta ahora posible, permitiendo a los
Service Routers combinar la velocidad y densidad de los conmutadores más rápidos con la
flexibilidad para programarlos y la capacidad de los de alto rango, de forma que ofrece nuevos
servicios complejos de manera económica. En el futuro se puede disponer de mejoras mediante una
descarga sencilla de micro‐código, al contrario de la sustitución del hardware necesaria con los
productos convencionales.
5.3.1.2.3.1.1 Hardware de los equipos
Toda la familia de equipos ofertados estará formada por dos módulos principales, el módulo I/O
(IOM) y el módulo de matriz y procesador (SF/CPM).
En el caso del chasis pequeño, no dispone de redundancia, el módulo de matriz y de procesamiento
se encuentran integrados en el chasis, así como una IOM. De esta forma el equipo admite dos MDAs
(Media Dependant Adapter).
En cuanto al chasis mediano y grande, será un equipo totalmente redundante donde la función de la
IOM se integra en la matriz de conmutación. Para identificar la IOM, y que todo el software funcione
de la misma manera que en el resto de la gama, se crea un IOM virtual, que proporciona el nivel de
adaptación al sistema operativo. El módulo de control está también redundado, aunque no es más
que una tarjeta de puertos que se conecta a ambas matrices de conmutación, donde residen las
CPUs, memoria, y el módulo de conmutación.
Se ofrece un esquema de un equipo, sin redundancia para facilitar la comprensión:
Página 66 de 124
Midplane
CCM
Packet Processing Block
SAR/Traf f ic Management Block
MDA/CMA Interface Block
Power Supply Block
MDA/MCM
Forwarding Block
Active CFM
CMA
I/O
Console (RS232)
Management (10/100 Ethernet)
Clock Source Block
Cooling
Control Block CPU
Q2 P2P2
Multi Core CPU
PEM-3High Flow
FAN
MCM-XP
CCM-XP
Los módulos IOM son responsables de conectar los adaptadores dependientes del medio (MDA y
CMA), que proporcionan la terminación de las interfaces físicas (10GE, GE, 10/100 Ethernet, STM‐x,
etc) en el sistema. El IOM procesa las tramas recibidas de un interfaz para tomar todas las decisiones
de conmutación. Implementa las funciones de QoS por servicio, listas de acceso (ACL) y contabilidad.
De forma similar, las tramas que son enviadas hacia los interfaces de salida son recibidas de la matriz,
re‐ensambladas en tramas, procesadas para cumplir con el encapsulado específico de salida. Al igual
que se realizaba en el ingreso de las tramas se realizan las funciones de QoS, filtrado y contabilidad
asociado a la salida.
Cada modulo IOM contiene uno (1) o dos (2) complejos Flexible Fast Path de 10 Gbps, 20Gbps o
50Gbps. Cada IOM soporta dos módulos adaptadores MDA. La flexibilidad inherente a este diseño
permite mezclar tipos de interfaz en cualquier ranura IOM del sistema. Cada complejo proporciona
conexión con la matriz de conmutación.
Página 67 de 124
Cada modulo IOM contiene una CPU para gestionar el hardware de forwarding de cada Flexible Fast
Path así como para participar en el plano de control distribuido.
Cada IOM se inserta en un slot de un chasis mediano o un chasis grande.
En el caso de los chasis grandes todo el chipset está integrado en la tarjeta que realiza todas las
operaciones.
MDA1
MDA1
MDA2
MDA2
SwitchTap
To Fabric B
To Fabric A
To Fabric B
To Fabric A
Two hot-pluggable MDAs per IOM
Fully programmable Flexible Fast Path performs packet processing at wire rate Redundant connections
to switch fabrics (SR-7/12 chassis)
IOM CPU/memory resources for distributed control plane, stats, etc.
1 GBDRAM
IOMControl
CPU
1 GBDRAM
IOMControl
CPU
IOMControl
CPU
SwitchTap
FlexPath
P
FlexPath
PPkt.RAM
CAM
Ctrl.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
PCAM
Pkt.RAM
Ctrl.RAM
FlexPath
Q
FlexPathForwarding
10 GbpsFull-Duplex
FlexPath
P
FlexPath
PPkt.RAM
CAM
Ctrl.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
Q
FlexPath
PCAM
Pkt.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
Q
FlexPathForwarding
10 GbpsFull-Duplex
FlexPath
P
FlexPath
PPkt.RAM
CAM
Ctrl.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
PCAM
Pkt.RAM
Ctrl.RAM
FlexPath
Q
FlexPathForwarding
10 GbpsFull-Duplex
FlexPath
P
FlexPath
PPkt.RAM
CAM
Ctrl.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
Q
FlexPath
PCAM
Pkt.RAM
Ctrl.RAM
FlexPath
Q
FlexPath
Q
FlexPathForwarding
10 GbpsFull-Duplex
Ilustración - Diagrama de bloques de una IOM
El módulo de matriz y control (CFM‐XP) soporta dos funciones separadas en dos zonas lógicas que se
sitúan físicamente sobre una tarjeta para ahorrar ranuras en el chasis:
La primera función es la de matriz de conmutación formado por múltiples elementos de
conmutación. Estos elementos realizan la tarea de enviar celdas recibidas por un puerto de
una tarjeta hacia un puerto en otra.
La segunda función es la de procesamiento de control central del nodo. El subsistema de
control usa dos procesadores que realizan todas las funciones centrales de gestión del chasis e
implementa las pilas de los protocolos (OSPF, IS‐IS, MPLS, etc.). Los procesadores se conectan
también con los elementos de la matriz, enviando y recibiendo el tráfico del plano de control.
Página 68 de 124
Las tarjetas de línea se conectan al equipo grande por el frontal. El equipo soporta dos tipos de
tarjetas:
MDA (Media Dependent Adapter), con el mismo formato que los empleados en los todos los
tipos de chasis, de los que se soporta un subconjunto de ellos que se indican a continuación.
Para la inserción de una MDA en el equipo grande es necesario emplear una tarjeta de
adaptación o carrier .
CMA (Compact Media Adapter), ocupa la mitad que una MDA y se inserta directamente en el
equipo grande, sin necesidad de tarjeta carrier.
El equipo puede albergar las siguiente combinaciones de tarjetas:
8 módulos CMA + 2 MDA+MCM o
6 módulos CMA + 3 MDA+MCM o
4 módulos CMA + 4 MDA+MCM o
2 módulos CMA + 5 MDA+MCM o
6 módulos MDA+MCM
-
Control and Forwarding Module (CFM)
Media Dependent
Adapter (MDA)
Control and Forwarding Module (CFM)
Flexible & Fully
Programmable Fast Path
Forwarding Technology
CPU
MDA Carrier Module (MCM)
MCM
Compact Media Adapter (CMA)
Compact Media Adapter (CMA)
Página 69 de 124
Las MDA y CMA soportadas en los equipos son (para el mayor chasis de el equipo ofertado):
Tipo de MDA Tipo I/F Puertos por chasis
mayor
CMA
1-port GigE SFP CMA-XP SFP 8
5-port GigE SFP CMA-XP SFP 40
8-port CH DS1/E1 CMA RJ48C 64
4-port DS3/E3 CMA 1.0/2.3 Connectors 32
8-port 10/100TX CMA RJ45 64
1-port GigE CMA SFP 8
2-port OC3/12-STM-1/4 SFP CMA SFP 16
8-port T1/E1 ATM/IMA CMA RJ48C 64
ETHERNET MDA
20-port 10/100/1000 RJ45 GigE MDA-XP RJ45 120
20-port GigE MDA-XP – SFP SFP 120
10-port 1GigE SFP MDA-XP SFP 60
2-port 10GigE MDA-XP XFP 12
1-port 10GigE XP MDA-XP XFP 6
20-port 100Base-FX MDA SFP 120
60-port 10/100Base-TX MDA 5 x mini RJ-21 360
Packet over SONET /SDH (POS) MDA´S
8-port OC-3c/STM-1c MDA SFP 48
2-port OC-48c/STM-16c MDA SFP 12
4-port OC-48c/STM-16c MDA SFP 24
ANY SERVICE ANY PORT (ASAP) MDA´s (dos por
chasis)
4-port CH DS3/E3 ASAP Mini SMB 8
12-port CH DS3/E3 ASAP Mini SMB 24
4-port CH OC-3/STM-1 ASAP SFP 8
1-port CH OC-12/STM-4 ASAP SFP 2
Página 70 de 124
CIRCUIT EMULATION SERVICE (CES) MDA´s (dos por
chasis)
1-port CH OC-3/STM-1 CES MDA SFP 2
1-port CH OC-12 CES MDA SFP 2
4-port CH OC3-CES MDA SFP 8
ATM MDAs (dos por chasis)
4-port ATM OC-3c/STM-1c/OC-12c/STM-4c MDA (Multirate) SFP 8
En cuanto al soporte de interfaces ópticos:
Las terminaciones eléctricas y ópticas (SFPs/XFPs) disponibles serán comunes a todos los equipos
ofertados.
Tabla: Interfaces ópticos y eléctricos soportados
Modulo Telcordia / ITU
Conector FO Wave length
Link Budget
Launch Power Max
(dbM)
Launch Power
Min (dBm)
Rx Power Max
(dBm)
Rx Power Min (dBm)
Target Distance
Telcordia / ITU
10/100 Fixed TX RJ21/VHDCI N/A N/A N/A N/A N/A N/A N/A 100m
100 BASE FX
SFP MM LC MM 1310nm 11 -14 -19 -14 -30 2 km
SM LC SM 1310nm 13.5 -14 -19 -7 -32.5 25km
EX LC SM 1310nm 23 0 -5 -8 -17 40km
1000 BASE
SFP
SX LC MM 850nm 7.5 0 -9.5 0 -17 550 m
LX LC SM 1310nm 7.5 -3 -11.5 -3 -19 10 km
EX LS SM 1310nm 18 0 -4,5 -3 -22,5 40 km
ZX LC SM 1550nm 24 5 0 -3 -24 70 km
EZX LC SM 1550nm 30 5 0 -9 -30 120 km
TX RJ-45 N/A N/A N/A N/A N/A N/A N/A N/A
BX10
CWDM LC SM See note
1
24 3 -1 -3 -25 70 km
10G BASE
Fixed
LW/LR Simplex SC SM 1310nm 6.2 0.5 -8.2 0.5 -14.4 10 km
EW/ER Simplex SC SM 1550nm 11.1 4 -4.7 -1 -15.8 40 km
ZW/ZR Simplex SC SM 1550nm 24 2 -2 -9 -26 80km
10G BASE SR LC SM 850nm 2.6 -1 -7.3 -1 -9.9 300m
Página 71 de 124
Modulo Telcordia / ITU
Conector FO Wave length
Link Budget
Launch Power Max
(dbM)
Launch Power
Min (dBm)
Rx Power Max
(dBm)
Rx Power Min (dBm)
Target Distance
Telcordia / ITU
XFP
LR LC SM 1310nm 6.2 0.5 -8.2 0.5 -14.4 10km
ER LC SM 1550nm 11 4 -4,7 -1 -15,8 40 km
ZR LC SM 1550nm tbc tbc tbc tbc tbc 80 km
OC-3c/STM-1c
SFP
SR-0 LC MM 1310nm 10 -14 -20 -14 -30 2km
IR-1 / S-
1.1
LC SM 1310nm 13 -8 -15 -8 -28 21 / 15 km
LR-1 / L-
1.1
LC SM 1310nm 29 0 -5 -10 -34 50 / 40 km
OC-12c/STM-
4c SFP
SR-0 LC MM 1310nm 6 -14 -20 -14 -26 2 km
IR-1 / S-
4.1
LC SM 1310nm 13 -8 -15 -8 -28 21 / 15 km
LR-2 / L-
4.2
LC SM 1550nm 25 2 -3 -8 -28 85 / 80 km
El interfaz de 1GE (Gigabit Ethernet) de cobre soporta velocidades de 10/100/1000 con auto‐
negociación o bien fijando los parámetros del enlace (velocidad y modo de trabajo).
5.3.1.2.4 Soporte de Servicios
Los conmutadores ofertados dispondrán de una capacidad puntera en la industria para soportar los
servicios demandados por los proveedores de servicios. Esta capacidad se centra en el suministro de
servicios avanzados de datos de última generación, en una arquitectura de red IP/MPLS escalable,
gestionable y optimizada en coste.
El amplio abanico de funcionalidades y la densidad puntera en la industria, así como las prestaciones
y la posibilidad de ampliación lo hacen adecuado para una amplia variedad de aplicaciones de router
de servicio, tales como:
Redes privadas de nivel 2
Punto‐a‐punto (VLL)
Punto‐a‐multipunto y multipunto‐a‐multipunto (VPLS)
Redes privadas de nivel 3 (VPN IP)
Página 72 de 124
Acceso mejorado a los recursos de routing general (Internet)
5.3.1.2.4.1 Servicios VPN L2 Punto a punto: VLL Ethernet
La Virtual Leased Line (VLL) se utiliza para transportar paquetes de otro protocolo a través de una red
IP/MPLS.
Básicamente una VLL Ethernet lleva las tramas Ethernet desde el puerto lógico de entrada hasta un
puerto lógico de salida, transportándolos a través de un túnel MPLS en la red.
El tráfico del cliente se encapsula y transporta a través de una red de paquetes, es absolutamente
transparente a los datos y protocolos de los usuarios finales, y no realiza ningún aprendizaje de
MACs.
Servicio Ethernet VLL
Hay despliegues de clientes donde la VLL se protege mediante una conexión de respaldo que debe
terminar en un nodo diferente. La protección MPLS no puede solucionar esta situación. Para dar
respuesta se usan dos o más VLL que actúan en modo activo y standby.
El equipo ofertado deberá conmutar al backup en caso de que se produzca algún fallo en la VLL
principal o en los puertos de conexión con la aplicación.
Página 73 de 124
Ejemplo de uso de VLL para conexión redundante con destino alternativo
5.3.1.2.4.2 Servicios VPN L2 multipunto: VPLS y H-VPLS
Un servicio VPLS (Virtual Private LAN Service) o L2VPN Ethernet “multipunto a multipunto”
es un servicio que emula la funcionalidad de una red de área local (LAN) tradicional. El
servicio VPLS hace posible conectar varios segmentos LAN sobre una red de conmutación
de paquetes (IP/MPLS) haciendo que los segmentos de LAN remotos se comporten como
una LAN única. La misma red de conmutación de paquetes permite ofrecer servicios VPLS
separados a diferentes aplicaciones o clientes.
Concepto general de VPLS
Página 74 de 124
Se quiere disfrutan de una implementación que suministra el ancho de banda y la escalabilidad
necesarios para la puesta en marcha de un servicio multi‐punto provechoso.
El modelo básico de VPLS emplea una malla total de túneles entre los nodos PE que ofrecen el
servicio.
Modelo de servicio VPLS
En muchos despliegues se utilizan dispositivos más pequeños en la red y se agregan en dispositivos
PE más centralizados. Aunque algunas veces se emplean técnicas como las definidas en IEEE 802.1Q,
puede ser beneficioso extender las técnicas de tunelado VPLS a este dominio secundario de acceso.
El modelo jerárquico de VPLS (H‐VPLS) ofrece una solución donde existe un núcleo de red que usa
una malla total de VCs o PW y a partir del cual se extiende la cobertura mediante conexiones radiales
(spokes) que forman un segundo nivel jerárquico en la VPLS.
Página 75 de 124
Ilustración 1 - Modelo de servicio H-VPLS
Esta conectividad jerárquica ofrece varias ventajas a la hora de desplegar una red VPLS de grandes
dimensiones:
Elimina la necesidad de utilizar una arquitectura “full mesh”.
Reduce la carga de señalización en la red.
Simplifica el descubrimiento y la provisión de red.
MTUPE
PE
PEPE
MTU
MTUMTU
MTU
MTU
MTU
Spoke VCs
Hub VCsMTU
PE
PE
PEPE
MTU
MTUMTU
MTU
MTU
MTU
CE Routers
VLANs, Stacked
VLANs or VC Labels
MTUPE
PE
PEPE
MTU
MTUMTU
MTU
MTU
MTU
MTUPE
PE
PEPE
MTU
MTUMTU
MTU
MTU
MTU
Spoke VCs
Hub VCsMTU
PE
PE
PEPE
MTU
MTUMTU
MTU
MTU
MTU
CE Routers
VLANs, Stacked
VLANs or VC Labels
Ilustración 2 - Evolución de VPLS “full mesh” a H-VPLS
Página 76 de 124
5.3.1.2.4.3 Servicios VPN L3 multipunto: VPN IP
El servicio VPN‐IP sólo puede proporcionarse con el equipamiento ofertado en la red IP/MPLS.
5.3.1.2.4.3.1 Servicio VPN-IP
La RFC 4364 detalla un método para distribuir información de enrutamiento y transmitir datos para
proporcionar una red privada virtual de nivel 3 (VPN‐IP) a los clientes finales.
Un servicio VPRN (Virtual Private Routing Network) o VPN‐IP “multipunto a multipunto” es un
servicio que emula la funcionalidad de una red de de nivel 3 (IP) tradicional. El servicio VPN‐IP hace
posible conectar varios dominios de enrutamiento sobre una red de conmutación de paquetes
(IP/MPLS) haciendo que los dominios de enrutamiento remotos se comporten como un único
dominio de enrutamiento. La misma red de conmutación de paquetes permite ofrecer servicios VPN‐
IP separados a diferentes clientes.
El modelo básico de VPN-IP emplea una malla total de túneles entre los nodos PE que
ofrecen el servicio.
Servicio compuesto
PE A PE C
PE B
PE D
IP / MPLS Network
VPRN Service Red
RI - 1
RI - 1
RI - 1
RI - 1 RI - 2
RI - 2
RI - 2
RI - 2
VPRN Service Green
PE A PE C
PE B
PE D
IP / MPLS Network
VPRN Service Red
RI - 1
RI - 1
RI - 1
RI - 1 RI - 2
RI - 2
RI - 2
RI - 2
VPRN Service Green
Página 77 de 124
La funcionalidad Virtual Routing Function (VRF) que posibilita la creación de una VPRN (IP‐VPN) se
encontrara únicamente en los nodos de los equipos ofertados.
El servicio compuesto se basa en la definición de una VPLS en los nodos que se desee, y levantar
interfaces de nivel 3 en una VPRN, de forma similar a como se crean interfaces IP en una VLAN. Este
servicio se apoya en la creación de Spoke SDPs que conectan la VPLS con las VPRN.
VRF
PE
PE
Spoke SDP
VPLS
PE
PE
VRF
PE
COREAggregationVRF
PE
PE
Spoke SDP
VPLS
PE
PE
VRF
PE
COREAggregation
De esta manera se consigue extender el concepto de VPN‐IP concentrando la funcionalidad VRF en
unos pocos nodos de los equipos ofertados.
5.3.1.2.4.4 Acceso mejorado a Internet
El servicio IES (Internet Enhanced Service) es un servicio de conectividad IP donde el cliente se
comunica mediante un interfaz IP a la red del proveedor (PE) para enviar y recibir tráfico IP de
Internet.
Los nodos ofertados soportarán enrutamiento estático y dinámico IGP (OSPF, IS‐IS y RIP) sobre la
conexión PE‐CE. Además, soportara el protocolo de enrutamiento dinámico EGP BGP‐4 .
Las mejoras que introducen los nodos de los equipos ofertados son:
Capacidad de procesamiento a velocidad de línea
Servicios sub‐rate
Soporte de diversos modelos de tarificación incluyendo los basados en uso y destino.
Página 78 de 124
Alta Disponibilidad
Los equipos ofertados presentaran una arquitectura hardware y software diseñada con el objetivo de
maximizar la disponibilidad de los servicios soportados por la red.
Esta alta disponibilidad tiene dos aspectos:
Redundancia Hardware. Asociada a la posibilidad de equipar elementos activos y de respaldo
en el chasis.
Redundancia Lógica. Asociada a la protección de los procesos y entidades lógicas que
intervienen en los servicios y en la conectividad de red.
Redundancia Hardware
Todos los equipos ofertados, deberán poder ser equipados con redundancia de los siguientes
elementos:
Control. Con doble tarjeta CFM‐XP.
Matriz de conmutación. Con doble tarjeta CFM‐XP
Alimentación. Mediante dos fuentes en el chasis.
Ventilación. Mediante ventiladores múltiples en el chasis.
Reloj. Con doble tarjeta CFM‐XP
Los elementos son intercambiables en caliente.
Redundancia Lógica
La redundancia lógica se apoyara en varios mecanismos disponibles en los equipos ofertados:
Alta disponibilidad del plano de control:
o Non‐Stop Service (NSS)
o Non‐Stop Routing (NSR)
o Graceful Restart (GR)
Página 79 de 124
o Redundancia de configuración
Equal Cost Multi‐Path (ECMP)
Redundancia de Interfaz mediante agregación de enlaces LAG
o Subgrupos LAG activo/standby
SONET/SDH APS 1+1
Virtual Router Redundancy Protocol (VRRP)
Subscriber Routed Redundancy Protocol (SRRP)
Ingeniería de tráfico MPLS
o LSPs de backup.
o MPLS Fast Re‐Route
Spanning Tree Protocols
o Aunque el mecanismo de creación de los SDP para las redes VPLS no permite la creación de
bucles en el CORE de la red MPLS, es posible que la red de acceso presente topología de
bucles o que los usuarios puedan provocarlo. Para este problema los equipos ofertados
también deberán soportar diversos protocolos de STP:
o STP, RSTP, 802.1w, MSTP
M‐VPLS. El concepto de management‐VPLS se introduce como consecuencia de activar un
protocolo de STP que esté controlado sólo por los Service Routers y no por los equipos de
acceso. De esta manera son siempre los equipos ofertados los que abren el bucle, mientras
que los Switches se dedican sólo a conmutar las BPDUs, sin participar en el proceso de STP, o
participando si así se desea.
o Lo interesante de esta solución es que mediante STP, se puede hacer que una instancia de
STP gobierne el comportamiento de diferentes VLANs. Esta VLAN por la que se permite
conmutar las BPDUs del STP que se ejecuta en los equipos, la llamaremos m‐VLAN, y entra
en un servicio especial llamado m‐VPLS, donde se ejecuta STP. Cuando la m‐VPLS decide
dónde cortar, podemos asignar que el resto de VPLS del equipo hereden ese corte y se
comporten como la m‐VPLS, pero sin ejecutar STP en ningún caso.
Página 80 de 124
Multichasis LAG o MC‐LAG
o Mediante esta técnica, un nodo de acceso se conecta a dos de los equipos ofertados,
estableciendo un agregado de enlaces estándar 802.3ad. Entre ambos equipos se ejecuta
un protocolo denominado Multichasis Sync, que permite sincronizar las tablas de MAC y
los estados de IGMP snooping de ambos nodos.
o Mediante este protocolo, ambos nodos se comportan como el mismo de cara al equipo de
acceso , pero sólo uno de los caminos está activo.
o La funcionalidad MC‐LAG aplica mayoritariamente a entornos donde un “Service Access
Point” (SAP) se conecta a un servicio VPLS con pseudo wires en el lado de red, de manera
que los mensajes MAC Flush puedan utilizarse para asegurar una topología libre de bucles
y consistente extremo a extremo.
Multichasis RING o MC‐RING
o Es posible emplear esta técnica bien a L2 o a L3.
o Empleando el servicio a L2 puede el anillo entrar en una VPLS.
o Empleando el servicio a L3 los servicios verán directamente la dirección IP virtual de una
VPRN con SRRP, que junto con el protocolo de sincronización MCS (MultiChassis
Synchronization) permite controlar y detectar el estado del anillo mediante los mensajes
intercambiados con el nodo redundante de acceso.
Mesh PWs
MC - LAG
Access Node
SAP
SAP
- 1
- 2
Página 81 de 124
o Si el servicio es a L3, el funcionamiento se basa en emplear una VLAN por el anillo para el
control del bucle. En esa VLAN se levantan interfaces IP que son monitorizados mediante
BFD por los equipos en los extremos del bucle.
o Se pueden bloquear unas VLANs por un lado del anillo y otras por otro, facilitando el uso
de los dos caminos disponibles.
o El problema reside en manejar adecuadamente el flush de las tablas MAC. Para completar
dicho problema tanto Ring‐RSTP, como ERP‐G.8032 disponen de mecanismos para forzar el
flush de las tablas de MAC. Con Ring‐RSTP este flush sólo afecta a las MACs que deben
cambiar el puerto.
o En la solución a nivel 3, la convergencia es más elevada, al recaer sobre BFD la
convergencia de los protocolos de routing (incluso el estático).
IP/MPLS
core Spoke - sdp
mesh - sdp
VRRP
MCS
- 3 - 4
- 1 - 2
Página 82 de 124
Calidad de servicio (QoS)
Ethernet no dispone de ningún mecanismo que garantice la QoS de una conexión extremo a
extremo. Únicamente se dispone de mecanismos capaces de priorizar unos flujos de tráfico frente a
otros, de manera local en cada conmutador de la red.
La QoS se consigue ofreciendo servicios best‐effort en una red diseñada con sobredimensionado.
El sobredimensionado puede eliminar las ventajas económicas de las soluciones Ethernet nativas y
sólo es viable para un tamaño de red pequeño, tanto en número de clientes como en número de
elementos.
Incluso con sobredimensionado, las fluctuaciones estadísticas del tráfico pueden provocar estados de
congestión en la red.
Con MPLS es posible ofrecer garantías estrictas de QoS extremo a extremo, incluso en caso de fallos
en la red ya que MPLS dispone de mecanismos de reserva de ancho de banda para el establecimiento
de túneles.
Los equipos ofertados deberán proporcionar calidad de servicio usando el modelo de servicios
diferenciados (Diff‐Serv). De acuerdo con este modelo, para lograr escalabilidad, se agregan los
micro‐flujos de tráfico en un número reducido de clases de forwarding usadas dentro de la red. Las
funciones de control, policing y shaping asociadas a cada flujo se implementan en el borde de la red,
SRRP
MCS - BSR - 2
IP/MPLS core
- 1 - 2
Página 83 de 124
mientras que dentro de esta se implementan a nivel de forwarding class (tráfico agregado por clase
de servicio).
En la figura se muestra la filosofía de implementación de QoS en una red.
Puntos de aplicación de las políticas de calidad de servicio
Las políticas de calidad de servicio se definen y se aplican en 4 puntos (para cada dirección del
tráfico):
Entrada del Servicio (Service Ingress SI).
Salida de Red (Network Egress NE).
Entrada de Red (Network Ingress NI).
Salida de Servicio (Service Egress SE).
5.3.1.2.4.5 Diferenciación
Los equipos ofertados soportaran 8 clases de forwarding configurables para ofrecer diferentes PHB
(per hop behaviour). El comportamiento real para una clase de forwarding se puede cambiar
mediante la definición de las políticas de QoS más adecuadas.
El mapeado del tráfico a una determinada clase de forwarding y viceversa se realiza en diferentes
puntos:
Página 84 de 124
Entrada del Servicio (Service Ingress SI). Mapeado del tráfico de entrada empleando el
marcado de cliente (802.1p, IP precedence, DSCP) o empleando criterios basados en las
cabeceras IP o MAC.
Salida de Red (Network Egress NE). En este punto se podrá hacer un remarcado de la clase de
forwarding sobre los paquetes entregados a la red (bits EXP en caso de ser paquetes MPLS).
Entrada de Red (Network Ingress NI). Se realiza el mapeado del tráfico de entrada a una clase
de forwarding empleando el marcado de red (MPLS EXP).
Salida de Servicio (Service Egress SE). Se mapea la clase de forwarding al campo 802.1p del
tráfico de salida del servicio.
Clasificación a la entrada de un servicio (SAP)
Buffers y gestión de colas
Cada tarjeta dispondrá de un espacio de memoria para la definición de colas. Deberán disponer de
todo en el chipset integrado, el número de colas hardware disponibles para los planificadores de QoS
asciende a 16K (1K=1024).
Página 85 de 124
En la entrada del servicio se pueden definir 1 cola por tipo de forwarding (unicast, multicast,
broadcast y desconocido) para cada clase de forwarding (8 clases) lo que da un máximo de 32 colas
por servicio SAP.
A la salida del servicio el tráfico ya está clasificado por lo que sólo se definirán hasta 8 colas (una por
clase de forwarding).
Cada cola tiene 3 parámetros de tamaño:
Comitted Burst Size (CBS). Tamaño del buffer tomado del espacio reservado.
Maximum Burst Size (MBS). Máxima profundidad que puede alcanzar la cola. El espacio entre
CBS y MBS se toma de la parte de memoria compartida.
High priority only Buffers (LMBS). Marca el punto a partir del cual la cola sólo admite tráfico
de alta prioridad (in‐profile).
El descarte de paquetes se rige por dos políticas WRED una para tráfico dentro de perfil y otra para
tráfico fuera de perfil.
Planificadores
El scheduling se encarga de distribuir el ancho de banda disponible entre las diferentes fuentes de
tráfico que quieren usarlo. En la práctica esto se traduce en cómo se extrae el tráfico de las colas.
Los equipos ofertados soportaran dos tipos de scheduling:
Scheduling mono‐etapa.
Scheduling jerárquico (multi‐etapa).
Scheduler por defecto en modelo mono‐etapa. Scheduler virtual para scheduling jerárquico multi‐
etapa.
Página 86 de 124
Stric
t Prio
rity
RRRR
RRRR
Real TimeIn Profile
Non RTIn Profile
Real TimeExcess
Non RTExcess
BRR St
rict P
riorit
y
RRRR
RRRR
Real TimeIn Profile
Non RTIn Profile
Real TimeExcess
Non RTExcess
BRR
Scheduler por defecto en modelo mono-
etapa.
Scheduler virtual para scheduling jerárquico
multi-etapa
Planificadores necesarios
Si cada cola no supera su PIR pero puede alcanzarlo simultáneamente con otras fuentes de tráfico si
hay ancho de banda disponible.
Cuando se quiere controlar el tráfico agregado de las colas asociadas a un servicio de forma
individualizada o al tráfico de diferentes servicios asociados a un cliente entonces se debe
implementar una estructura jerarquizada de planificadores con una definición personalizada de las
relaciones entre ellos.
Página 87 de 124
Ejemplo H-QoS con 2 niveles de planificadores
Policing y Shaping
Los equipos ofertados soportan dos estrategias de policing para alcanzar los objetivos de regulación
del tráfico:
Policing y shaping por cola, por SAP en ingress y egress.
Policing de la cola de ingress del SAP sin conformado y con descarte de paquetes fuera de
perfil en el egress.
Aplicando la primera estrategia, los paquetes que dejan una cola asociada a un SAP a una velocidad
menor que el CIR configurado se marcarán como dentro de perfil. Los paquetes que abandonen la
cola a una velocidad mayor que CIR pero menor que PIR se marcarán como fuera de perfil. Los
paquetes fuera de perfil reciben un tratamiento de menor prioridad que los paquetes dentro de
perfil. Además cuando se producen ráfagas superiores a MBS a una velocidad superior al PIR se
realizará un descarte de paquetes. Este es el modelo más apropiado para clases de tráfico de no
tiempo real. Se define PIR>CIR.
Página 88 de 124
La segunda estrategia permite transitar el tráfico de la cola hasta la velocidad PIR, mientras que los
paquetes fuera de perfil son descartados. Este modelo es el más adecuado para servicios de tiempo
real. Se define PIR=CIR.
Class Based Forwarding
Otra de las posibilidades que ofrecerá las redes basadas en nodo ofertado es la de trabajar con
túneles MPLS dedicados a una clase de servicio, llegando a un modelo de trabajo similar al de los L‐
LSPs, en lugar de los E‐LSPs del modelo Diffserv.
Con esta facilidad, se pueden generar topologías lógicas en red independientes para cada una de las
clases de servicio con las que se trabaje, asignando diferentes posibilidades de redundancia o
ingeniería de tráfico, con el objeto de gestionar las mejores características que cada servicio requiera
de la red.
Esta prestación permite que, por ejemplo el tráfico best‐effort utilice unos túneles RSVP‐TE y el
tráfico Expedited Forwarding otros independientes.
Todas estas características permiten desplegar en la red, políticas de calidad de servicio jerárquicas,
que habilitan el control exhaustivo y granular que las nuevas redes multiservicio demandan.
Resumiendo las características más importantes de los SR en lo relativo a QoS:
Soporte de 16k colas hardware
Asignación flexible de colas a servicios, sin vínculo alguno a los puertos de entrada.
Todas las colas Ingress/Egress tienen shaping independiente:
o Permite conformar el tráfico en lugar de descartarlo
o Usuario ‐> Red
o Red ‐> Usuario
Todas las colas Ingress tienen policing independiente
o Policing tipo Frame Relay con CIR, PIR y MBS
Soporta prioridades estrictas y Weighted Round Robin
Página 89 de 124
Ilustración - Asignación flexible de las 8192 colas
Todos estos mecanismos permitirán, no sólo priorizar el tráfico de VoIP, sino otros muchos tipos de
tráfico, GARANTIZANDO que la coexistencia de todos ellos no perjudica a ninguno, y que cada uno
recibe lo que necesita, pudiendo disponer, si hay recursos en la red para ello, de más caudal.
Soporte de tecnologías multimedia y de aplicaciones de multidifusión. El SR ofrece
importantísimas herramientas para el soporte de tecnologías multimedia y aplicaciones de
multicast.
o Habilitación de un canal de retorno para la TV‐interactiva. En la moderna TV, se espera que
el usuario pueda interactuar con la emisión de los contenidos, para juegos, encuestas,
concursos, acceso a Internet, acceso a servicios bancarios, etc. Actualmente la TV es un
medio unidireccional. Los operadores y distribuidores de contenidos quieren cambiar este
carácter unidireccional y aportar la posibilidad de que el usuario envíe información hacia la
red. Los equipos tendrán los mecanismos necesarios en sus SR para capturar la señal que
viene de descodificador, interceptarla y enviarla al Servidor correspondiente para su
tratamiento (banca, concurso, acceso Internet, etc.)
o Inserción de contenidos individualizados, por región o por colectivo. Las emisiones de TV
basadas en Triple‐Play, permiten la definición de contenidos a la carta para los usuarios,
pudiendo, por ejemplo insertar diferentes anuncios en función del perfil de consumo de
Página 90 de 124
cada usuario. Así, en vez de recibir todo el mundo los mismos anuncios, se realiza un
perfilado de usuarios y se envían los contenidos. El equipo ofertado, deberá tener
desarrollado los mecanismos en sus SR para insertar en cada flujo multicast o unicast los
contenidos necesarios, por perfil de usuario, por franja horaria, por ubicación geográfica o
cualquier otro criterio.
Control de tráfico
MPLS dispone de mecanismos de ingeniería de tráfico para conmutar el tráfico basándose en
criterios distintos del de destino: prioridad, tipo de tráfico, etc.
Los factores que deberá cumplir en esta solución de red "Ethernet sobre MPLS" en cuanto a
Mecanismos de Protección son:
Recuperación en 50 ms
Calidad de servicio garantizada durante la transición
Distribución óptima del tráfico después de la caída
Posibilidad de definir servicios con diferentes esquemas de protección
Independientemente de lo definido en los estándares, en los mecanismos de Control de Tráfico así
como de QoS es la tecnología del equipamiento la que permite realizar estas funciones avanzadas.
Además de definirse los caminos alternativos mediante FRR (Fast ReRoute), es posible definir hasta 8
caminos alternativos para el tráfico, de forma que siempre exista un camino disponible. También se
puede emplear esta funcionalidad para enviar los tráficos de diferentes servicios o tráficos del mismo
servicio por diferentes caminos (por ejemplo caminos fijos para el vídeo o la Telefonía) y protegerlos
también mediante FRR.
Aunque ya comentados, los mecanismos de alta disponibilidad englobados en el concepto de Non‐
Stop‐Services (sincronización permanente de ambas controladoras) actuarán también a la hora de
gestionar el tráfico, ya que por ejemplo el proceso de STP (en cualquiera de sus versiones)
permanece sincronizado aún en el caso de producirse un failover de controladora. Esto permite al
tráfico seguir su camino sin requerir de un cambio topológico y la consecuente renovación de la tabla
de forwarding.
Página 91 de 124
Gestionabilidad
También es muy importante tener en cuenta los factores diferenciadores de una solución de red
"Ethernet sobre MPLS" en cuanto a Monitorización de rendimiento y OAM.
La solución MPLS permitirá:
Verificación de la conectividad hasta el punto de red del cliente (pruebas de bucle desde el
centro de gestión)
Verificación de la conectividad extremo a extremo entre sedes del cliente (pruebas de bucle
desde el centro de gestión)
Verificación de la calidad de las conexiones extremo a extremo
Verificación tanto del plano de control como del plano de tráfico de cliente en los equipos de
red
Las propuestas de Ethernet nativa no disponen de capacidad de monitorizar la conectividad del
servicio ni la calidad de las conexiones, si bien existe la posibilidad de verificar el plano de control de
los equipos ethernet implicados pero nunca de verificar el plano de tráfico de cliente.
Sin estas capacidades no se pueden realizar pruebas de validación de la conectividad hasta el punto
de conexión del cliente, por lo que se consideran fundamentales.
Los servicios VPLS disponen de herramientas que permiten realizar pruebas de verificación de
conectividad extremo a extremo entre sedes del cliente.
El equipamiento debe estar diseñado desde el principio para hacer énfasis en los servicios que la red
transporta, permitiendo la definición, provisión, y diagnóstico de los servicios, en vez de continuar
realizando las labores de gestión de red.
Es importante incidir en este concepto, lo importante de la red son los servicios que transporta, y
siempre comenzar el diagnóstico de los problemas con una visión de cómo se han visto afectados los
servicios.
El conjunto de herramientas de gestión, no sólo las nuevas basadas en Ethernet‐OAM, sino las ya
disponibles para la monitorización de los servicios permitirán acortar sensiblemente el tiempo de
diagnóstico y resolución de incidencias, reduciendo el MTTR.
Página 92 de 124
Service Oriented Diagnostics Verify service operational status Testing through customer traffic imitation
Operational, Administration & Maintenance (OAM) tools available in 5620 SAM are:- Service Site Ping VCCV Ping VPRN ping & Trace ATM Ping Tunnel MTU & Ping LSP Ping & Trace Multicast Ping, Trace Mac Ping, Trace, Populate & Purge CPE Ping ICMP Ping, Trace DNS Ping ANCP Loopback 802.3ah and 802.1ag
Source: -
Improve provisioning efficiency by 69% Service
Provisioning
33 minutes
10 minutes Tools required
EMS
Service
Restoration
Source: -
MTTR Fix Identify
Problem Isolation 13 minutes
MTTR Fix Identify
Tools required Problem Isolation 8.3 minutes
Improve Restoration Time by 36%
MTTR = mean time to repair
Página 93 de 124
Escalabilidad
Gracias a la asimilación inmediata que se puede hacer entre VLAN y VPLS, las redes con prestación de
servicios basadas en VPLS, son cada vez más frecuentes.
Es necesaria la posibilidad de desplegar servicios VPLS en redes con cientos de nodos, y decenas de
miles de usuarios. Esta situación es inimaginable con equipamiento Ethernet convencional y routing
IP, si se quieren mantener niveles de disponibilidad adecuados.
Ethernet presenta los problemas derivados del aprendizaje de ingentes cantidades de direcciones
MAC en equipos que no están diseñados para ello, los equipos ofertados como mínimo deberán de
manejar más de 500.000 direcciones MAC en un solo nodo.
Las topologías basadas en Spanning Tree en Ethernet nativa no permiten optimizar el camino entre
dos puntos. Esto conlleva problemas de retardo y jitter en topologías de red grandes. Esto supone
una grave limitación para conexiones de vídeo.
Estos caminos no óptimos requieren un sobredimensionado mucho mayor que incrementan el coste
de la solución en equipos y FO y disminuyen la escalabilidad.
En aquellos despliegues con gran cantidad de nodos, puede ser interesante realizar un despliegue
basado en una estructura con una gran escalabilidad, en vez de definir una estructura plana simple.
Esta solución, mucho más interesante por su escalabilidad y reducción del overhead en los
protocolos de gestión y aprendizaje de MACs, es la desplegada en la mayoría de los
proveedores y consiste en adoptar una topología de H-VPLS (VPLS jerárquica)
VPLS H-VPLS
PW
PW
PW
PW
PW
PW
Página 94 de 124
En el caso de la red que nos compete, los nodos principales serían los encargados de realizar la
concentración del resto de nodos.
Cada nodo de agregación “de acceso” se conecta a los nodos principales empleando una conexión
Spoke‐SDP (PseudoWires –PW‐ que puede ser redundada en otro nodo, por otro camino o por
combinaciones de ambos). Luego entre los 12 nodos se definen los Mesh‐SDP que constituyen la
VPLS interna. Todo el servicio se denomina H‐VPLS.
El aprendizaje de MACs puede activarse o desactivarse de los SDP, de forma que el core de la red
permanezca sin conocimiento de las direcciones MAC de las estaciones finales.
Sistema de Gestión
La gestión de la red para los equipos se realizará mediante el sistema de gestión que se oferte. Dicho
sistema de gestión, deberá soportar las funcionalidades de una capa de gestión de elemento y las
completa con las funciones de provisión y aseguramiento propias de la capa de servicios.
Se compondrá de los siguientes módulos:
Módulo Base para gestión del equipo incluyendo Alarmas, Configuración y Monitoring Módulo Opcional para provisión de Servicios (VLL, (H)VPLS, VPRN RFC2547b) y MPLS (LSP & PW) Módulo Opcional para aseguramiento de Servicios y MPLS así como gestión de performance
La configuración del sistema de gestión, dispondrá de módulos que permiten la gestión sin
elementos externos de los equipos y servicios de transporte configurados en el backhaul de
agregación ethernet/MPLS.
Igualmente se deberá de cumplir la implementación en sistemas HP OPENVIEW
A continuación se describen cada uno de los módulos que compondrán el sistema:
Gestión Básica de elementos:
La comunicación del sistema de gestión con los equipos de red se realiza mediante SNMP y FTP.
Este módulo se encarga de las siguientes funciones:
Mediación con los nodos y Gestión de los equipos. Autodescubrimiento de los nodos y los recursos de red. Configuración del polling y política de actualización de MIBs.
Página 95 de 124
Backup, restauración y actualización de las configuraciones de los nodos. Acceso a los nodos mediante CLI/Telnet. Vista gráfica del equipo con capacidad de “navegar” desde L1 a L3 (chasis/ slots/ cards/ MDAslot/
MDA/ Puerto/ Interfaz/ … Fallos) Gestión de la seguridad Autenticación de usuario basada en password local o en RADIUS/TACACS+ remoto. Gestión del perfil del operador y soporte de acceso a dominios funcionales. Registro de actividad de usuarios y de OSS así como de eventos de autenticación. Inventario y generación de informes Gestión del inventario y capacidad de preparar informes personalizados mediante filtros. Configuración de la recolección de estadísticas y tarificación.
Aseguramiento de servicios:
Este módulo se encarga de:
Aseguramiento de los servicio mediante herramientas de OAM&P cubriendo: Pruebas de conectividad usando ping de servicio en IP, MAC, VLAN y VRF. Trace route de servicio incluyendo verificación del túnel LSP y prueba de MTU. Mirroring de servicio para copiar tráfico de usuario en un puerto de test para análisis detallado. Contabilidad por servicio y por puerto. Verificación de la QoS por servicio. Colección de estadísticas para gestión del rendimiento. Gestión de alarmas inteligente. Correlación de alarmas y síntesis Escalado y des‐escalado de alarmas. Asignación de severidades a las alarmas Registro histórico de alarmas. Gestión de la topología de servicio para facilitar las tareas de assurance Localizador de servicios para buscar y mostrar los parámetros de abonado, servicio, puerto, SDP y
LSP.
Página 96 de 124
Provisión de servicios:
Este módulo se encarga de las siguientes tareas:
• Creación de servicios y gestión de abonados para:
• Servicios Ethernet punto a punto (VLL) y multipunto (VPLS) incluyendo H‐VPLS.
• Servicios de VPN‐IP (VPRN) basadas en BGP.
• Multicast IGMP y PIM‐SM.
• Servicio de acceso mejorado a Internet (IES)
• Servicio peering BGP.
• Proporciona plantillas y asistentes para provisioning rápido y sin errores
• Con mezcla de tecnologías de acceso (Ethernet, SDH, ATM,..)
• Soporte de túneles basados en IP (GRE) y MPLS.
• Herramientas de pruebas para verificar operación.
• Gestión de túneles y trayectos
• Gestión de policía
• Gestión de la política de filtrado MAC e IP
• Definición y aplicación de políticas de calidad en acceso y red.
• Definición de la gestión de colas y pendientes de la policía de descarte WRED.
• Definición de encolado y scheduling incluyendo H‐QoS.
• Política de marcado y forwarding.
• Policing en protocolos IS‐IS, OSPF, BGP, RSTP, IGMP, PIM‐SM.
Página 97 de 124
6 EQUIPAMIENTO ACTIVO GPON
Con objeto de poder ofrecer los servicios “triple play” vídeo RF, IPTV, datos y voz, tanto
tradicional como VoIP, sobre una única plataforma, los licitadores deberán proponer una
solución robusta, que extienda el potencial de ancho de banda que proporciona la fibra
como medio de conexión físico, desde el núcleo de la red (Punto de Interconexión) hasta las
dependencias del usuario.
La solución deberá estar basada en tecnología GPON (Gigabit Passive Optical Networking),
con equipamiento OLT en la central o sala de telecomunicaciones y la ONT en la casa del
usuario.
El licitador, deberá presentar las certificaciones técnicas del fabricante de los equipos
ofertados, que garanticen la capacidad técnica suficiente, para instalar programar y
mantener, el equipamiento electrónico ofertado para este proyecto. En caso contrario
quedará excluido del concurso.
El licitador tiene que cumplir obligatoriamente con los siguientes requisitos.
6.1 Equipo de central OLT
El licitador deberá proporcionar información de la solución GPON propuesta, e incluirá una
arquitectura de alto nivel recomendada para cumplir con las necesidades de servicios
requeridas.
Los licitadores deberán cumplir los requisitos técnicos siguientes: proporcionar información
de los siguientes aspectos técnicos relacionados con la solución y cumplir como mínimo con
todas y cada una de las especificaciones técnicas:
Proporcionar información de la arquitectura de la OLT, información del hardware del equipo,
control, módulos PON, alarmas, etc.
La OLT debe soportar un reloj ETSI 2.048KHz BITS, y suministrarlo a todas las ONTs y a
los CPEs conectados a las ONTs. Indicar nivel de precisión
La OLT debe tener redundancia en la unidad de control NT y en el enlace ascendente
(parte de agregación de la red).
La OLT debe soportar interfaces de 1GE and 10GE en la red y cumplir con los requistos de
agrupación de enlaces en la red acorde a la especificación 802.3ad LAG and LACP.
La OLT debe soportar las siguientes opciones: a) Dirección MAC Fuente/Destino; b)
Etiquetado VLAN; c) Dirección IP Fuente/Destino.
Página 98 de 124
La OLT tiene que disponer de la capacidad de balanceo de carga en caso de fallo en uno de
los enlaces definidos en la agrupación LAG.
La OLT debe poder agrupar como mínimo 2 enlaces y como máximo 8 enlaces en la
función LAG. Los enlaces de agregación GigE/10GigE que se agrupan deben de utilizar
señalización LACP.
Se deben proporcionar los valores MTBF y MTTR para todos los componentes GPON.
El licitador debe proporcionar información de las capacidades de las tarjetas PON y de las
capacidades por sistema. Como mínimo, cada OLT debe atender a 3500 abonados.
El licitador debe proporcionar detalle del consumo de las tarjetas utilizadas, del armazón y
bastidor. Se debe incluir la potencia disipada
La OLT debe permitir que la desconexión de cualquier CPE o cable óptico en la red de
distribución de fibra afecte de forma severa al resto de la red en servicio.
LA OLT deberá disponer un backplane con tolerancia a fallos de forma que el fallo en una
tarjeta GPON no afecte al resto de tarjetas del armazón.
La OLT debe permitir realizar operaciones de conmutación automática y manual en las
unidades de control redundante
El equipo de central OLT debe permitir la funcionalidad de Telecarga SW sin afectar al
servicio cuando se requiera incorporar nuevas versiones en la red.
Los interfaces Gigabit Ethernet de la OLT deben cumplir con la especificación IEEE 802.3z.
Para alcances de media distancia y larga distancia deberán estar implementados acorde al
estándar IEEE 802.3 1000B-LX10 y IEEE 802.3 1000B-ZX respectivamente según lo
especificado en la norma IEEE 802.3ah.
Los interfaces Single-mode Optical GigE deberán estar disponibles en la unidad de red de la
OLT y deberán disponer de módulos Gigabit Interface Converter (GBIC) o módulos
enchufables tipo SFP.
La OLT debe soportar RSTP (rapid spanning tree protocol).
Los interfaces GigE deben soportar de forma sostenida 1000 Mbps en cada dirección,
ascendente y descendente sin pérdida de paquetes.
La OLT deberá proporcionar un mínimo de 4 interfaces Gigabit Ethernet (GigE) interfaces
hacia red para soportar el tráfico ascendente hacia la red IP. LA OLT debe proporcionar
redundancia para estos interfaces. El equipo de central OLT debe tener la capacidad de
proporcionar redundancia de estos interfaces.
Página 99 de 124
La OLT debe soportar la funcionalidad VLAN tagging, por IEEE 802.1Q.
La OLT tiene que soportar VLANs en el enlace Ethernet ascendente, con 4096 VLANs.
Asimismo debe soportar la funcionalidad de VLAN Stacking.
La OLT debe soportar el estándar IEEE 802.1Q (definido como 802.1P bits)
El equipo de central OLT debe ser capaz de soportar en el enlace ascendente tramas de
hasta 2000 bytes.
El licitador proporcionara detalles de cómo el equipo OLT puede ser gestionado acorde al
modelo ISO FCAPS modelo para gestión de red.
La OLT debe disponer de interfaz RS-232 para funciones de mantenimiento y configuración,
se deberá de disponer de gestión fuera y dentro de banda. También se deberá permitir la
gestión de los equipos mediante un equipo de gestión centralizado EMS.
Los equipos de central OLTs deben poder autodescubrirse a petición del dispositivo de
gestión. Así como pre-provisionar servicios, auditar la versión SW instalada y proporcionar
información de los eventos ocurridos en la red.
6.2 Equipo de abonado ONT Se entregarán 79 ONTs de interior
La ONT es la terminación que se instala en la casa del abonado. El licitador debe cumplir
obligatoriamente con las siguientes especificaciones:
Existen variantes de exterior, de interior y de tipo MDU. Un resumen de los distintos tipos de
ONT a los que se da soporte.
La ONT debe ser capaz de proporcionar servicios Triple play, Internet de Alta velocidad, Voz
(SIP/H248) y Video (VoD/IPTV/RF).
La ONT debe proporcionar interfaces Ethernet para conectarse al residential gateway (RG) a
velocidades de Fast Ethernet (FE) y potencialmente Gigabit Ethernet (GE).
La ONT deberá ser gestionada desde la OLT a través del interfaz OMCI.
El licitador deberá proporcionar detalles de la arquitectura de la ONT. Asimismo se
proporcionarán datos de MTBF.
Se deberán indicar tipos de ONT mono-usuario disponibles, debiendo disponer de versiones
de interior y de exterior.
Se deberán indicar tipos de ONT multi-usuario disponibles, requiriendose al menos
versiones para 8 y 24 abonados.
Página 100 de 124
Se deberán indicar, para cada una de las ONTs descritas en los puntos anteriores, el
numero de interfaces:
POTS,
Ethernet,
WiFi,
Video RF
E1
VDSL perfil 30a en ONT’s multi-usuario
Se deberán indicar, para cada una de las ONTs descritas en los puntos anteriores, el
consumo y la disipación.
La salida del interfaz de datos de la ONT/ONU no debe ser afectada por la presencia de
tráfico de voz en los circuitos POTS.
La ONT/ONU sólo permitirá pasar el trafico de paquetes a las direcciones apropiadas, sin
interferencias por otros usuarios.
La ONT debe permitir la activación y desactivación remota de servicios por medio del OMCI.
La ONT por defecto, deberá prohibir paquetes MAC de bridging/forwarding a través de los
puertos de los usuarios.
La ONT deberá proporcionar interfaz óptico a la red de distribución por medio de una única
fibra (single mode).
Los interfaces Ethernet de la ONT deben cumplir con el estándar IEEE 802.3i (10BaseT @
10 Mbps).
Los interfaces Ethernet interfaces de la ONT deben cumplir en su totalidad con el estándar
IEEE 802.3u (100BaseT @ 100 Mbps).
Los interfaces 10/100 BaseT Ethernet de la ONT deben ser capaces de mantener de forma
sostenida en cada dirección (ascendente/descendente) una velocidad de 100 Mbps.
Los interfaces 10/100/1000 BaseT Ethernet de la ONT deben soportar un tráfico de pico de
400 Mbps en cada dirección (ascendente/descendente).
La ONTs deben tener la capacidad de telecargarse remotamente (vía sistema de gestión).
La activación del SW de la ONT se deberá realizar al inicializarse vía operador.
Página 101 de 124
Los contenedores GEM no deben modificarse en las ONTs cuando se produzca un cambio
SW.
La ONT debe disponer de mecanismos de protección que impidan la modificación de la
configuración y del SW por parte del usuario.
La ONT deberá tener un mecanismo sencillo que permita identificar el registro ID con los
datos del usuario cuando se instala ONT por primera vez. LA ONT deberá confirmar que la
petición de configuración se ha realizado satisfactoriamente, en caso contrario deberán
proporcionar mensaje indicando fallo.
La ONT deberá soportar mecanismo de auto descubrimiento proporcionando información de
configuración al sistema de gestión.
Durante el proceso de arranque la ONT debe proporcionar los datos del número de serie a
la OLT y será reconocida dentro de la red.
La ONT deberá ser visible por el gestor EMS y se podrá gestionar remotamente.
La ONT debe soportar ITU-T G.984.5 acorde al WBF como opción.
El interfaz UNI Ethernet UNI debe ser capaz de transmitir tramas de hasta 2000 bytes.
La ONT debe soportar VLAN tagging, por IEEE 802.1Q.
6.3 Características técnicas de la red GPON
El sistema de fibra FTTH GPON debe cumplir con la especificación ITU-T G.984.x para
sistema con una única fibra GPON con velocidad de 2.488 Gbps en descendente y 1.244
Gbps en ascendente en la banda básica.
Cada puerto de la OLT debe soportar velocidades de transmisión 2.488Gbps/1.244Gbps
(Downstream/Upstream)
El sistema debe soportar de hasta un máximo de 3584 abonados por armazón y 62
abonados por PON.
Se debe cumplir la trama con el GPON Encapsulation Method (GEM) para el transporte de
tráfico Ethernet.
La OLT debe soportar la ITU-T Class B+ para el budget óptico con split de hasta 1:64 de
ratio, con un alcance máximo de acorde a ITU-T Recommendation G.984.1.
El sistema debe alcanzar un budget óptico de 28dB sin recurrir a mecanismo de FEC.
Página 102 de 124
La ONT deberá soportar mecanismos opcionales de Forward Error Correction (FEC) como
se define en la norma G.984.3 para tráfico ascendente/descendente.
El sistema tiene que soportar mecanismo de encriptación AES acorde a la norma ITU-T
G.984.3.
La longitud en la clave de encriptación será de 128 y será iniciada por la OLT identificando
para ONT el port ID
El sistema deberá soportar acorde a la norma G.984.3 (longitudes de onda de 1310 nm para
ascendente y 1490 nm descendente) y 1550nm para el video RF en overlay
El nivel de potencia debe de ser el acorde a la norma G.984.3.
El sistema debe soportar mecanismo de DBA acorde a la norma ITU-T Recommendation
G.984.3.
El Licitador deberá proporcionar detalle del mecanismo de asignación dinámica de ancho de
banda (DBA).
El sistema debe soportar los contenedores T-CONT tipo 1, 4 y 5.
El licitador debe especificar el número de TCONTs y puertos GEM PORT-Ids que se
soportan por PON, ONT y UNI.
El sistema debe soportar PON Multicast acorde a la norma ITU G.984.3.
El sistema debe cumplir con el OMCI acorde a la norma ITU-T Recommendation G.984.4.
La ONT debe soportar la norma ITU-T Class B+ para potencia óptica.
La ONT deberá soportar hasta un mínimo de ocho (8) GEM Port-ID por interfaz
Ethernet/VDSL servido.
La instalación de una ONT en un PON existente no deberá impactar en el servicio de
cualquier ONT en el PON.
LA ONT con RF deberá disponer de la función de filtrado para extraer la señal de video.
6.4 Servicios
El sistema deberá soportar asignación asimétrica de ancho de banda para cada servicio.
La OLT deberá ser capaz de asignar direcciones IP a usuarios finales con servicios
RFC2684 mediante DHCP relay. La OLT también deberá funcionar como repetidor para
Página 103 de 124
asignación de dirección IP y para renovación de dirección IP con el fin de evitar en todo
momento las comunicaciones directas entre los dispositivos de usuario y los servidores
DHCP. Se deberán proporcionar detalles de las opciones extendidas DHCP que se soportan
y la manera en la que dichas opciones se emplean para ofrecer servicios avanzados.
Deberá soportarse DHCP relay con Option 82.
Deberá soportarse PPPoE relay tag.
La OLT deberá cumplir con TR-101 en lo que se refiere al manejo de C-Tag/S-Tag.
Asimismo deberá ser capaz de soportar transparent bridging de un puerto en una VLAN, y
soportará también VLANs privadas de cliente (N:1 y 1:1).
Proporcionar detalles de las capacidades de Gestión de Tráfico de la OLT (por ejemplo, las
capacidades de Policing) – en términos de puerto de usuario, VLAN tag o sesión/flujo para
un usuario determinado.
El sistema deberá soportar VLAN stacking, unstacking, y VLAN transparency.
El sistema deberá soportar VLAN Stacking, y permitir cualquier combinación de outer/inner
tag para identificar cualquier combinación de servicio/usuario.
Las VLAN tag(s) de usuario recibidas dentro del GEM Port-ID del usuario en la OLT deberán
ser conservadas, eliminadas, modificadas o encapsuladas Q-in-Q (anidadas) en función de
las opciones de provisión disponibles en el proveedor de servicios.
La OLT deberá conmutar tráfico a partir de VLAN id y direcciones MAC del usuario.
El sistema deberá soportar los bits de prioridad de IEEE 802.1Q (anteriormente los bits
802.1P).
El sistema deberá soportar ocho (8) niveles de prioridad Ethernet por 802.1Q.
Por defecto la OLT deberá prohibir la conmutación de paquetes MAC entre GEM Port-IDs.
La ONT deberá permitir la provision de varios niveles de velocidades de datos, empezando
con 64 Kbps, y continuando hasta 100 Mbps para interfaces 10/100 BaseT y VDSL.
La ONT deberá permitir la provisión de varios niveles de velocidades de datos, empezando
con 64 Kbps, y continuando hasta 400 Mbps para interfaces 10/100/1000 BaseT.
El sistema deberá ser capaz de manejar paquetes marcados con prioridad 802.1p, paquetes
no marcados, marcados con VLAN, o marcados con DSCP con el fin de proporcionar
priorización de tráfico adecuada.
El sistema deberá soportar por defecto marcado mediante 802.1p bits.
Página 104 de 124
El sistema deberá utilizar diferentes GEM Port-IDs por puerto de usuario (aparte del tráfico
Multicast).
El sistema deberá soportar conformado de tráfico ascendente/descendente (“shaping”) por
usuario y por servicio.
Las ONTs deberán soportar conformado de tráfico ascendente (“shaping”) por PortID.
La OLT deberá soportar conformado de tráfico descendente (“shaping”) por usuario y por
servicio.
La OLT deberá proporcionar un mecanismo para asociar la clase de servicio de un GEM
Port-ID a los bits de prioridad Ethernet en la etiqueta de VLAN correspondiente, y viceversa.
Las ONTs deberán soportar “queuing/scheduling” por GEM Port-ID.
En cuanto a tráfico IP, la OLT debe ser capaz de soportar IP QoS avanzado por conexión de
usuario/VLAN/GEM port. Proporcionar detalles de las capacidades de QoS en sentido
ascendente y descendente en la línea GPON. Se deberán proporcionar además las
capacidades IP QoS del lado OLT NNI.
Proporcionar detalles de los mecanismos de QoS marcado de tráfico y scheduling, la
posibilidad de ponderar colas con la misma prioridad y la capacidad para especificar el
tamaño y la profundidad de todas las colas. Detallar el número de colas soportadas por
interfaz. Proporcionar detalles acerca del mapeo/interworking de 802.1p a IP QoS
(Differentiated Services Code Point).
La OLT deberá soportar encolado con Weighted Round Robin (WRR) y Prioridad Estricta en
las conexiones de red.
La OLT deberá soportar la capacidad de especificar la asignación de los registros de
transmisión (egress) y recepción (ingress) a las colas de prioridad estricta y Weighted Round
Robin.
La OLT deberá soportar la capacidad de configurar cualquier combinación de valores de
CoS p-bit a cualquiera de las colas de transmisión (egress).
Los bits de prioridad del tráfico marcado recibido en el puerto Ethernet, lado red en la OLT
deberán ser conservados, eliminados o sobrescritos en función de las opciones de provisión
disponibles en el proveedor de servicios.
La OLT deberá soportar la configuración del tamaño de los registros en las colas de
transmisión y recepción.
Página 105 de 124
La OLT deberá soportar la configuración de la ponderación de cola en las colas Weighted
Round Robin.
La OLT deberá soportar queuing/scheduling por VLAN y por servicio en el sentido de
transmisión (ascendente) en los interfaces lado red.
La OLT deberá soportar la configuración del tamaño y profundidad de todas las colas.
La ONT deberá soportar un mínimo de cuatro (4) colas de prioridad en el puerto de
transmisión (ascendente) para soportar niveles de prioridad.
Las ONTs deberán soportar un mínimo de cuatro (4) colas de prioridad en el sentido de
transmisión (descendente) del interfaz/puerto de usuario para soportar niveles de prioridad
cuando el ancho de banda descendente excede el ancho de banda del puerto de usuario.
La OLT deberá soportar la asociación de GEM Port-IDs en el lado PON a ocho (8) niveles de
prioridad en el lado Ethernet.
Las ONTs deberán ser capaces de utilizar ocho (8) niveles de prioridad Ethernet para
asociar las tramas Ethernet recibidas en el puerto de usuario a GEM Port-IDs en el lado red.
Proporcionar detalles de los puntos de multicast en la arquitectura de la OLT.
La OLT deberá soportar funcionalidad multicast nativa. La OLT deberá soportar
suscripciones estáticas entre la OLT y el router multicast, es decir las peticiones de
suscripción de la OLT deberán ser independientes de las peticiones de suscripción y fin de
suscripción de los usuarios.
Proporcionar detalles sobre la manera en la que la OLT permite acomodar múltiples flujos
multicast por usuario.
La OLT deberá soportar IGMP v3 proxy y snooping.
La ONT deberá soportar funcionalidad multicast native utilizando el GEM port. Indicar
además si la ONT soporta replicación multicast.
La ONT deberá ser capaz por configuración de limitar el máximo número de canales
conmutados por usuario.
Deberá existir un mecanismo para limitar el ancho de banda multicast en el interfaz PON.
Describir qué ocurre cuando este ancho de banda se encuentre infrautilizado.
El sistema deberá ser capaz de seleccionar y encaminar hacia el usuario un mínimo de 64
flujos IGMP multicast por ONT.
Página 106 de 124
Indicar si el sistema soporta control de acceso para multicast. Preferiblemente, esta
funcionalidad deberá implementarse mediante paquetes de canales (es decir, agrupar
aquellos canales multicast que comparten permisos de acceso communes). Detallar la
escalabilidad de esta solución.
La ONT deberá soportar, como opción configurable por software, tanto la señalización H.248
como SIP para VoIP.
En la instancia SIP, la ONT deberá implementer SIP como agente de usuario.
La implementación SIP deberá ser interoperable con el Session Border Controller y el Call
Server del OPERADOR. Indicar, junto con el material adecuado que lo respalde, aquellos
fabricantes de Session Border Controller/Call Server contra los que se ha probado y
desplegado la solución propuesta.
Proporcionar detalles del soporte de Fax grupo 3.
Proporcionar detalles del soporte de modems analógicos incluyendo V34 y V90.
Proporcionar detalles de sobre el soporte de RFC2833 (valores DTMF de 0 a 15 más el
rango extendido de 16 a 255.
La ONT deberá permitir la configuración del marcado de QoS (DSCP y bits de prioridad de
usuario 802.1Q) en el tráfico de voz que genera.
La ONT deberá permitir la configuración del marcado de QoS (DSCP y bits de prioridad de
usuario 802.1Q) en el tráfico de señalización de voz que genera.
La ONT deberá ser capaz de encolar el tráfico ascendente y descendente en colas
jerárquicas configurables tomando como base el marcado de prioridad Ethernet.
Las ONTs deberán soportar IGMP v3 snooping
Las MDU ONTs deberán soportar IGMP v3 proxy
La ONT deberá soportar funcionalidades de llamada basadas en hook flashes.
La ONT deberá soportar funcionalidades de llamada basadas en la transmisión de tonos en
estado de descuelgue.
El sistema deberá soportar la configuración de ancho de banda de alta prioridad suficiente
para el transporte de codificación G.711 de servicios VoIP (es decir, voz sin compresión),
con tamaños de paquete entre 5 y 30 milisegundos.
El codec de la ONT-ATA deberá incluir G.711 (µ-law) por defecto.
La ONT deberá soportar la capacidad de habilitar Voice Activity Detection (VAD).
Página 107 de 124
La ONT deberá mantener el tráfico hacia y desde el cliente VoIP separado respecto del
tráfico hacia y desde el resto del hogar mediante el empleo de un identificador de VLAN
diferente para el tráfico VoIP y/o diferentes GEM port IDs para el tráfico de VoIPs.
El usuario no podrá configurar (o modificar) la dirección IP de la ONT.
6.5 Sistema de gestión
Deberán proporcionarse los detalles completos sobre cómo el Sistema de Gestión es capaz
de operar y manejar los fallos en el sistema. También deberá proporcionarse una breve
descripción de los siguientes puntos:
Describir el Sistema de Gestión de Red (NMS) empleado para monitorizar y gestionar el
sistema FTTH. El NMS deberá proporcionar toda la funcionalidad a través de un moderno
interfaz gráfico de usuario (GUI). Sus responsabilidades de gestión deberán incluir un
conjunto completo de funcionalidades de alarmas, configuración, prestaciones y seguridad.
Describir el proceso de provisión del servicio y tarificación asociada, así como cualquier
solución de terceros que sean compatibles con el producto propuesto.
Detallar los estándares abiertos utilizados dentro del Sistema de Gestión para la integración
con plataformas de gestión y tarificación de terceros.
Indicar el número máximo de usuarios concurrentes que pueden manejarse mediante el
Sistema de Gestión.
Describir el proceso estándar para dar de alta un nuevo usuario. Identificar si es preciso
emplear pre-configuración, si se requieren desplazamientos in situ, etc.
Describir las herramientas y aplicaciones disponibles para gestión mediante craft terminal.
Serán preferibles las soluciones para craft basadas en GUI.
El nodo de red deberá enviar toda la información de alarmas al Sistema de Gestión de Red
(EMS).
En el caso de fallo de enlace entre el Sistema de Gestión de Red (EMS) y el nodo de red
(NE), el Sistema de Gestión deberá generar y mostrar una notificación en su GUI.
En el caso de caída del enlace entre el Sistema de Gestión de Red (EMS) y el Nodo de Red
(NE), el Nodo de Red deberá mantener toda la información de alarmas hasta que el enlace
vuelva a restablecerse, enviando entonces la información almacenada hacia el Sistema de
Gestión (EMS).
Página 108 de 124
El sistema no proporcionará informes autónomos de alarmas al EMS orientados a la
detección posterior de un problema que ya ha sido reportado. Si el problema es resuelto,
dicha resolución deberá ser comunicada al Sistema de Gestión de Red.
El sistema deberá conservar resultados de pruebas de hardware y software realizadas
durante la operación normal y reportar las pruebas fallidas al Sistema de Gestión. La
limpieza de una indicación de alarma no precisará de un reset de la OLT.
El modelo de alarmas del sistema deberá ser lo suficientemente detallado como para
permitir identificar el componente discreto del sistema en situación de alarma (tarjetas OLT
individuales, ONTs).
El Nodo de Red deberá ser capaz de suprimir los informes de alarmas por elección del
operador.
El Nodo de Red deberá reportar al interfaz del craft local y al Sistema de Gestión aquellos
fallos en las unidades de alimentación, circuitos, o fusibles.
El Nodo de Red deberá suprimir todo informe de alamas que sea redundante.
El sistema deberá proporcionar alarmas por severidad (crítica, mayor o menor) así como
alertas informativas.
El sistema GPON deberá soportar la transmisión de los datos de gestión al Sistema de
Gestión tanto mediante comunicaciones de datos fuera de banda (TCP/IP/Ethernet) o dentro
de banda (una VLAN en el interfaz Gigabit Ethernet). La elección será configurable en el
momento de la instalación.
El sistema GPON deberá proporcionar datos de configuración de todos los interfaces físicos
incluyendo el inventario de tarjetas, interfaces virtuales, protocolos de nivel 3 y superiores
sobre los que se tenga visibilidad (por ejemplo IGMP snooping/proxy, DHCP opción 82 (RFC
3046), y EAP sobre RADIUS.
El sistema GPON deberá soportar la recogida del estado del puerto físico y el puerto lógico.
El sistema GPON deberá soportar la monitorización del nivel físico incluyendo cambios en el
status del puerto, fallos, pérdidas de señal, niveles de recepción óptica/eléctrica, niveles de
transmisión óptica/eléctrica, y bit error rates.
El sistema GPON deberá soportar la observación no intrusiva de las conexiones y puertos
virtuales para el acceso desde sistemas de diagnóstico remotos.
Página 109 de 124
La OLT o el Sistema de Gestión deberán ser capaces de identificar que la ONT necesita una
actualización de software. Deberá generarse una indicación (trap) que identifique que la
ONT se encuentra actualmente con la versión de arranque.
El proceso de software upgrade/transferencia deberá ser controlado por el EMS. Esto se
traduce en que el operador deberá ser capaz de identificar que la transferencia ha sido
iniciada, y que la transferencia se ha completado. Cuando se detecte la existencia de la
versión de arranque y comience la transferencia de la actualización será necesario el envío
de una trap informativa. Asimismo el interfaz GUI deberá proporcionar también información
de que la actualización de una ONT se encuentra en proceso.
Deberá ser posible identificar el tipo y versión de ONTs en el sistema.
Una vez que la transferencia haya sido completada con éxito, deberá enviarse una
indicación positiva al Sistema de Gestión con la versión de software presente en la ONT
(trap “Auto ONT Upgrade Successfully Complete”).
Durante el proceso de “ranging”, puede ocurrir que una ONT no sea descubierta
adecuadamente provocando un fallo en la comunicación. En este caso la OLT deberá
“eliminar” la ONT del PON. El sistema de gestión deberá ser alertado de esta situación.
La ONT deberá disponer de un watchdog timer y su actividad deberá ser vigilada para
garantizar que puede deshabilitarse el láser si, por ejemplo, la ONT comienza a transmitir
tráfico ilegal de datos o ha entrado en un estado ilegítimo. Describir otras funcionalidades de
la ONT para monitorizar sus prestaciones y la función de autocontrol.
Deberá proporcionarse en el sistema de gestión o en la OLT la capacidad de identificar una
potencial ONT ilegal (por ejemplo mediante un agente en el sistema de gestión que examina
alarmas fuera de secuencia) y determinar con un cierto nivel de confianza cuándo un
interfaz PON tiene problemas. Describir cómo funcionará este proceso.
La plataforma de gestión soportará opcionalmente redundancia para evitar que un único fallo
de software o hardware interrumpa las operaciones de gestión.
Un fallo en el Sistema de Gestión no deberá impactar en los servicios existentes.
6.6 Especificaciones técnicas sistema de agregación Ethernet
El objetivo de la red de transporte y agregación de datos es la de dotar de conectividad IP a
todos los elementos de la nueva red de telecomunicaciones en cada una de las áreas
descritas en este proyecto:
Página 110 de 124
Esta red estará conformada por un router IP/MPLS de altas prestaciones con funciones de
BNG/BRAS para servicios Triple Play.
Se define la tecnología IP/MPLS como la más adecuada para el desarrollo está la red
troncal de comunicaciones por su madurez tecnológica, por sus capacidades de
virtualización de red, ingeniería de tráfico y adaptación a futuras necesidades.
A continuación se definen los siguientes requisitos de obligado cumplimiento para los
equipos que han de conformar la red de transporte de datos;
No se considerarán propuestas que dejen de cumplir algunos de los siguientes estándares.
Así mismo, se deberán incluir todas las licencias (u otros elementos SW) que posibiliten
trabajar con la siguiente lista de protocolos.
6.6.1 Estándares IEEE 802.1d Bridging
IEEE 802.1p/Q VLAN Tagging
IEEE 802.1s Multiple Spanning Tree
IEEE 802.1w Rapid Spanning Tree Protocol
IEEE 802.1x Port Based Network Access Control
IEEE 802.3 10BaseT
IEEE 802.3ad Link Aggregation
IEEE 802.3ae 10Gbps Ethernet
IEEE 802.1ad Provider Bridges
IEEE 802.1ah Provider Backbone Bridges
IEEE 802.1ag Service Layer OAM
IEEE 802.3ah Ethernet OAM
IEEE 802.3ah Ethernet in the First Mile
IEEE 802.1ak Multiple MAC Registration Protocol
IEEE 802.3u 100BaseTX
IEEE 802.3x Flow Control
IEEE 802.3z 1000BaseSX/LX
ITU-T Y.1731 OAM functions and mechanisms for Ethernet based networks
6.6.2 Synchronous Ethernet ITU-T G.8261 – g.pactiming – Timing and synchronization aspects of packet
networks
ITU-T G.8262 – g.paclock – Timing characteristics of Ethernet equipment slave clock
(EEC)
Página 111 de 124
ITU-T G.8264 – g.pacmod – Distribution of timing through packet networks and
Ethernet Sync Status Message (ESSM)
6.6.3 Soporte de Protocolos OSPF
RFC 1765 OSPF Database Overflow
RFC 2328 OSPF Version 2
RFC 2370 Opaque LSA Support
RFC 2740 OSPF for IPv6 (OSPFv3) draft-ietf-ospf-ospfv3-update-14.txt
RFC 3101 OSPF NSSA Option
RFC 3137 OSPF Stub Router Advertisement
RFC 3623 Graceful OSPF Restart – GR helper
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 4203 For Shared Risk Link Group (SRLG) sub-TLV
BGP
RFC 1397 BGP Default Route Advertisement
RFC 1772 Application of BGP in the Internet
RFC 1965 Confederations for BGP
RFC 1997 BGP Communities Attribute
RFC 2385 Protection of BGP Sessions via MD5
RFC 2439 BGP Route Flap Dampening
RFC 2547bis BGP/MPLS VPNs
RFC 2796 BGP Route Reflection: Alternative to Full-mesh IBGP (previously RFC
1966)
draft-ietf-idr-rfc2796bis-02.txt.
draft-ietf-idr-rfc2858bis-09.txt.
RFC 2918 Route Refresh Capability for BGP-4
RFC 3065 Confederations for BGP
draft-ietf-idr-rfc3065bis-05.txt.
RFC 3392 Capabilities Advertisement with BGP4
RFC 4271 BGP-4 (previously RFC 1771)
RFC 4360 BGP Extended Communities Attribute
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)(previously RFC 2547bis
BGP/MPLS VPNs)
RFC 4724 Graceful Restart Mechanism for BGP – GR helper
Página 112 de 124
RFC 4760 Multi-protocol Extensions for BGP (previously RFC 2858)
RFC 4893 BGP Support for Four-octet AS Number Space
RFC 5065 Confederations for BGP (obsoletes 3065)
IS-IS
RFC 1142 OSI IS-IS Intra-domain Routing Protocol (ISO 10589)
RFC 1195 Use of OSI IS-IS for routing in TCP/IP & dual environments
RFC 2763 Dynamic Hostname Exchange for IS-IS
RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS
RFC 2973 IS-IS Mesh Groups
RFC 3373 Three-Way Handshake for Intermediate System to Intermediate System
(IS-IS) Point-to-Point Adjacencies
RFC 3567 Interfmediate System to Intermediate System (ISIS) Cryptographic
Authentication
RFC 3719 Recommendations for Interoperable Networks using IS-IS
RFC 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)
RFC 3787 Recommendations for Interoperable IP Networks
RFC 3847 Restart Signaling for IS-IS – GR helper
RFC 4205 for Shared Risk Link Group (SRLG) TLV
draft-ietf-isis-igp-p2p-over-lan-05.txt
LDP
RFC 3036 LDP Specification
RFC 3037 LDP Applicability
RFC 3478 Graceful Restart Mechanism for LDP – GR helper
RFC 5283 LDP extension for Inter-Area LSP
draft-jork-ldp-igp-sync-03
IPv6
RFC 1981 Path MTU Discovery for IPv6
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
RFC 2461 Neighbor Discovery for IPv6
Página 113 de 124
RFC 2462 IPv6 Stateless Address Auto configuration
RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 Specification
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
RFC 2545 Use of BGP-4 Multiprotocol Extension for IPv6 Inter-Domain Routing
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
RFC 2740 OSPF for IPv6
RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses
RFC 3315 Dynamic Host Configuration Protocol for IPv6
RFC 3587 IPv6 Global Unicast Address Format
RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD)
Protocol
RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
RFC 4007 IPv6 Scoped Address Architecture
RFC 4193 Unique Local IPv6 Unicast Addresses
RFC 4291 IPv6 Addressing Architecture
RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
RFC 5072 IP Version 6 over PPP
draft-ietf-isis-ipv6-05
draft-ietf-isis-wg-multi-topology-xx.txt
6PE
6VPE
Multicast
RFC 1112 Host Extensions for IP Multicasting (Snooping)
RFC 2236 Internet Group Management Protocol, (Snooping)
RFC 3376 Internet Group Management Protocol, Version 3 (Snooping)
RFC 2362 Protocol Independent Multicast-Sparse Mode (PIMSM)
RFC 3618 Multicast Source Discovery Protocol (MSDP)
RFC 3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
RFC 4601 Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol
Specification (Revised)
RFC 4604 Using IGMPv3 and MLDv2 for Source-Specific Multicast
Página 114 de 124
RFC 4607 Source-Specific Multicast for IP
RFC 4608 Source-Specific Protocol Independent Multicast in 232/8
RFC 4610 Anycast-RP Using Protocol Independent Multicast (PIM)
draft-ietf-pim-sm-bsr-06.txt
draft-rosen-vpn-mcast-08.txt
draft-ietf-mboned-msdp-mib-01.txt
draft-ietf-l3vpn-2547bis-mcast-07: Multicast in MPLS/BGP IP VPNs
draft-ietf-l3vpn-2547bis-mcast-bgp-05: BGP Encodings and Procedures for Multicast
in MPLS/BGP IP VPNs
RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address
MPLS
RFC 2702 Requirements for Traffic Engineering over MPLS
RFC 3031 MPLS Architecture
RFC 3032 MPLS Label Stack Encoding (REV3443))
RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
RFC 4182 Removing a Restriction on the use of MPLS Explicit NULL
RFC 5332 MPLS Multicast Encapsulations
RIP
RFC 1058 RIP Version 1
RFC 2082 RIP-2 MD5 Authentication
RFC 2453 RIP Version 2
RSVP-TE
RFC 2430 A Provider Architecture DiffServ & TE
RFC 2702 Requirements for Traffic Engineering over MPLS
RFC2747 RSVP Cryptographic Authentication
RFC3097 RSVP Cryptographic Authentication
RFC 3209 Extensions to RSVP for Tunnels
RFC 3564 Requirements for Diff-Serv-aware TE
RFC 4090 Fast reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic
Engineering
Página 115 de 124
RFC 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware
MPLS Traffic Engineering
RFC 4875 Extensions to Resource Reservation Protocol – Traffic Engineering
(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
draft-ietf-mpls-soft-preemption-14 MPLS Traffic Engineering Soft Preemption
draft-ietf-ccamp-mpls-graceful-shutdown-06
Graceful Shutdown in GMPLS Traffic Engineering Networks
draft-ietf-mpls-p2mp-lsp-ping-06 Graceful Shutdown in GMPLS Traffic Engineering
Networks
DIFFERENTIATED SERVICES
RFC 2474 Definition of the DS Field the IPv4 and IPv6 Headers (Rev)
RFC 2597 Assured Forwarding PHB Group (rev3260)
RFC 2598 An Expedited Forwarding PHB
RFC 3140 Per-Hop Behavior Identification Codes
TCP/IP
RFC 768 UDP
RFC 1350 TFTP
RFC 791 IP
RFC 792 ICMP
RFC 793 TCP
RFC 826 ARP
RFC 854 Telnet
RFC 951 BootP (rev)
RFC 1519 CIDR
RFC 1542 Clarifications and Extensions for the Bootstrap Protocol
RFC 1812 Requirements for IPv4 Routers
RFC 2347 TFTP option Extension
RFC 2328 TFTP Blocksize Option
RFC 2349 TFTP Timeout Interval and Transfer Size option
RFC 2401 Security Architecture for Internet Protocol
draft-ietf-bfd-mib-00.txtBidirectional Forwarding Detection Management Information
Base
Página 116 de 124
draft-ietf-bfd-base-02.txtBidirectional Forwarding Detection
draft-ietf-bfd-v4v6-1hop-02.txtBFD IPv4 and IPv6 (Single Hop)
VRRP
RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy
Protocol
RFC 3768 Virtual Router Redundancy Protocol
draft-ietf-vrrp-unified-spec-02: Virtual Router
Redundancy Protocol Version 3 for IPv4 and IPv6
PPP
RFC 1332 PPP IPCP
RFC 1377 PPP OSINLCP
RFC 1638/2878PPP BCP
RFC 1661 PPP (rev RFC2151)
RFC 1662 PPP in HDLC-like Framing
RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server
Addresses
RFC 1989 PPP Link Quality Monitoring
RFC 1990 The PPP Multilink Protocol (MP)
RFC 1994 “PPP Challenge Handshake Authentication Protocol (CHAP)
RFC 2516 A Method for Transmitting PPP Over Ethernet
RFC 2615 PPP over SONET/SDH
RFC 2686 The Multi-Class Extension to Multi-Link PPP
FRAME RELAY
FRF.1.2 – PVC User-to-Network Interface (UNI) Implementation Agreement
FRF.5 – Frame Relay/ATM PVC Network Interworking Implementation
ANSI T1.617 Annex D, DSS1 – Signalling Specification For Frame Relay Bearer
Service
FRF2.2 – PVC Network-to- Network Interface (NNI) Implementation Agreement
FRF.12 – Frame Relay Fragmentation Implementation Agreement
FRF.16.1 – Multilink Frame Relay UNI/NNI Implementation Agreement
Página 117 de 124
ITU-T Q.933 Annex A – Additional procedures for Permanent Virtual Connection
(PVC) status management
ATM
RFC 1626 Default IP MTU for use over ATM AAL5
RFC 2514 Definitions of Textual Conventions and OBJECT_IDENTITIES for ATM
Management
RFC 2515 Definition of Managed Objects for ATM Management RFC 2684
Multiprotocol Encapsulation over ATM Adaptation Layer 5
AF-TM-0121.000 Traffic Management Specification Version 4.1
ITU-T Recommendation I.610 - B-ISDN Operation and Maintenance Principles and
Functions version 11/95
ITU-T Recommendation I.432.1 – BISDN user-network interface – Physical layer
specification: General characteristics
GR-1248-CORE - Generic Requirements for Operations of ATM Network Elements
(NEs). Issue 3
GR-1113-CORE - Bellcore, Asynchronous Transfer Mode (ATM) and ATM Adaptation
Layer (AAL) Protocols Generic Requirements, Issue 1
AF-ILMI-0065.000 Integrated Local Management Interface (ILMI) Version 4.0
AF-TM-0150.00 Addendum to Traffic Management v4.1 optional minimum desired
cell rate indication for UBR
AF-PHY-0086.001, Inverse Multiplexing for ATM (IMA) Specification Version 1.1
DHCP
RFC 2131 Dynamic HostConfiguration Protocol (REV)
RFC 3046 DHCP Relay Agent Information Option (Option 82)
RFC 1534 Interoperation between DHCP and BOOTP
VPLS
RFC 4762 Virtual Private LAN Services Using LDP (previously draft-ietf-l2vpn-vpls-
ldp-08.txt)
draft-ietf-l2vpn-vpls-mcast-reqts-04.txt
IEEE 802.1ah (PBB) sobre VPLS y H-VPLS.
Página 118 de 124
PSEUDO-WIRE
RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3)
RFC 4385 Pseudo Wire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN
RFC 3916 Requirements for Pseudo- Wire Emulation Edge-to-Edge (PWE3)
RFC 4717 Encapsulation Methods for Transport ATM over MPLS Networks (draft-ietf-
pwe3-atm-encap-10.txt)
RFC 4816 PWE3 ATM Transparent Cell Transport Service (draft-ietf-pwe3-cell-
transport-04.txt)
RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks
(draft-ietf-pwe3-ethernet-encap-11.txt)
RFC 4619 Encapsulation Methods for Transport of Frame Relay over MPLS
Networks (draft-ietf-pwe3-frame-relay-07.txt)
RFC 4446 IANA Allocations for PWE3
RFC 4447 Pseudowire Setup and Maintenance Using LDP (draft-ietf-pwe3-control-
protocol-17.txt)
RFC 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires
draft-ietf-l2vpn-vpws-iw-oam-02.txt
draft-ietf-pwe3-oam-msg-map-05-txt
draft-ietf-l2vpn-arp-mediation-04.txt
draft-ietf-pwe3-ms-pw-arch-02.txt
draft-ietf-pwe3-segmented-pw-05.txt
draft-hart-pwe3-segmented-pw-vccv-02.txt
draft-muley-dutta-pwe3-redundancy-bit-02.txt
draft-muley-pwe3-redundancy-02.txt
MFA Forum 9.0.0 The Use of Virtual trunks for ATM/MPLS Control Plane Interworking
MFA Forum 12.0.0 Multiservice Interworking - Ethernet over MPLS
MFA forum 13.0.0 - Fault Management for Multiservice Interworking v1.0
MFA Forum 16.0.0 – Multiservice Interworking - IP over MPLS
ANCP/L2CP
draft-ietf-ancp-framework-01.txt
draft-ietf-ancp-protocol-00.txt
Página 119 de 124
CIRCUIT EMULATION
RFC 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)
RFC 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN)
MEF-8 Implementation Agreement for the Emulation of PDH Circuits over Metro
Ethernet Networks, October 2004
RFC 5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing
(TDM) Pseudowires in MPLS Networks
SONET/SDH
GR-253-CORE SONET Transport Systems: Common Generic Criteria. Issue 3,
September 2000
ITU-G.841 Telecommunication Standardization Section of ITU, Types and
Characteristics of
SDH Networks Protection Architecture, issued in October 1998 and as augmented by
Corrigendum1 issued in July 2002
GR-253-CORE - SONET Transport Systems: Common Generic Criteria. Issue 3,
September 2000
RADIUS
RFC 2865 Remote Authentication Dial In User Service
RFC 2866 RADIUS Accounting
SSH
draft-ietf-secsh-architecture.txtSSH Protocol Architecture
draft-ietf-secsh-userauth.txt SSH Authentication Protocol
draft-ietf-secsh-transport.txt SSH Transport Layer Protocol
draft-ietf-secsh-connection.txt SSH Connection Protocol
draft-ietf-secsh- newmodes.txt SSH Transport Layer Encryption Modes
TACACS+
draft-grant-tacacs-02.txt
OAM
BFD
802.3ah
802.1ag
Página 120 de 124
NETWORK MANAGEMENT
ITU-T X.721: Information technology-OSI-Structure of Management Information
ITU-T X.734: Information technology-OSI-Systems Management: Event Report
Management Function
M.3100/3120 Equipment and Connection Models
TMF 509/613 Network Connectivity Model
RFC 1157 SNMPv1
RFC 1215 A Convention for Defining Traps for use with the SNMP
RFC 1657 BGP4-MIB
RFC 1724 RIPv2-MIB
RFC 1850 OSPF-MIB
RFC 1907 SNMPv2-MIB
RFC 2011 IP-MIB
RFC 2012 TCP-MIB
RFC 2013 UDP-MIB
RFC 2096 IP-FORWARD-MIB
RFC 2138 RADIUS
RFC 2206 RSVP-MIB
RFC 2452 IPv6 Management Information Base for the Transmission Control Protocol
RFC 2454 IPv6 Management Information Base for the User Datagram Protocol
RFC 2465 Management Information Base for IPv6: Textual Conventions and General
Group
RFC 2558 SONET-MIB
RFC 2571 SNMP-FRAMEWORKMIB
RFC 2572 SNMP-MPD-MIB
RFC 2573 SNMP-TARGET-&-
NOTIFICATION-MIB
RFC 2574 SNMP-USER-BASED-SMMIB
RFC 2575 SNMP-VIEW-BASEDACM-MIB
RFC 2576 SNMP-COMMUNITY-MIB
RFC 2665 EtherLike-MIB
RFC 2819 RMON-MIB
RFC 2863 IF-MIB
RFC 2864 INVERTED-STACK-MIB
RFC 2987 VRRP-MIB
Página 121 de 124
RFC 3014 NOTIFICATION-LOGMIB
RFC 3164 Syslog
RFC 3273 HCRMON-MIB
draft-ietf-disman-alarm-mib-04.txt
draft-ietf-ospf-mib-update-04.txt
draft-ietf-mpls-lsr-mib-06.txt
draft-ietf-mpls-te-mib-04.txt
draft-ietf-mpls-ldp-mib-07.txt
draft-ietf-isis-wg-mib-05.txt
IANA-IFType-MIB
IEEE8023-LAG-MIB
Capacidades BNG/BRAS:
Capacidad de gestionar hasta 7000 usuarios simultáneos mono-servicio en modo
IPoE (DHCP)
Capacidad de gestionar hasta 3500 usuarios simultáneos dual-play en modo IPoE
Capacidad de gestionar hasta 1000 usuarios simultáneos mono-servicio en modo
PPPoE
Capacidad de servidor DHCP en el propio router
Routed-subscriber host provisioning:
Capacidad de “PPPoE based subscriber-host” basada en Radius
Capacidad de “IPoE / DHCP-based subscriber host” basada en Radius
Capacidades de emulación de circuitos CES
Los routers deberán tener la posiblidad de incorporar interfaces STM‐1 canalizados para emulación de circuitos E1 según la norma MEF‐8.
El router deberá soportar las siguientes modalidades de sincronismo para la emulación de
circuitos:
Sincronismo adaptativo.
Interfaces ethernet con capacidad de ethernet síncrona Capacidad de incorporar la norma IEEE-1588v2 una vez quede estandarizada.
6.6.4 Interfaces disponibles en los routers
Los equipos objeto de esta licitación deben disponer de los siguientes interfaces:
Página 122 de 124
Interfaces Ethernet (10/100/1000 Base T y 1000BaseX), con capacidades tanto de acceso
como de red. Una interfaz deberá ser configurable por software en todas estas capacidades.
No se admitirán propuestas que requieran HW diferenciado en función de si se va a soportar
o no MPLS sobre ellos.
Interfaces 1000BaseX, con opciones de conexión de SFPs de tipo SX, LX (hasta 10km de
alcance), BX (monofibra hasta 10km), EX (hasta 40 km de alcance), ZX (hasta 70 km de
alcance), y EZX (hasta 120km de alcance).
Se valorará el soporte de interfaces 10GE con opciones de conexión de XFPs de tipo SR,
LR (hasta 10 km), ER (hasta 40 km), ZR (hasta 70 km) y EZR (hasta 120 km).
Interfaces E1, E3, STM-1 y STM-4 (todas estos canalizables hasta nx64), con capacidades
tanto de acceso como de red. Una interfaz deberá ser configurable por software en todas
estas capacidades. No se admitirán propuestas que requieran HW diferenciado en función
de si se va a soportar o no MPLS sobre ellos.
Estas interfaces deberán soportar indistintamente como protocolos de acceso PPP (IPCP y
BCP), HDLC, ATM y Frame Relay. Se considera el protocolo PPP como el necesario para el
soporte de red MPLS sobre este tipo de interfaces.
6.6.5 Otros requisitos mecánicos
Los equipos deberán estar dotados de redundancia de alimentación, con capacidad de
extracción de estos elementos sin cambio de chasis.
Así mismo, los módulos de control/conmutación/ventilación deberán ser también
independientes del chasis, pudiendo ser reemplazados con independencia de éste.
La alimentación deberá ser –48v DC, pero ante la necesidad de alimentación en AC, este
cambio deberá ser posible únicamente mediante reemplazo de fuentes de alimentación, sin
necesidad de cambio de chasis.
Página 124 de 124