PFC - Jose Maria Zapardiel Gonzalo.pdf - E-Archivo UC3M ...

DEPARTAMENTO DE TELEMÁTICA 

UNIVERSIDAD CARLOS III DE MADRID 

ESCUELA POLITÉCNICA SUPERIOR 

INGENIERÍA SUPERIOR DE TELECOMUNICACIONES 

PROYECTO FINAL DE CARRERA 

DISEÑO E IMPLEMENTACIÓN 

DE UN ENTORNO 

DE PRUEBAS PARA IPTV 

AUTOR: JOSÉ MARÍA ZAPARDIEL GONZALO 

TUTOR: JAIME GARCÍA REINOSO 

27 de enero de 2011

Título: DISEÑO E IMPLEMENTACIÓN DE UN EN- 

TORNO DE PRUEBAS PARA IPTV 

Autor: JOSÉ MARÍA ZAPARDIEL GONZALO 

Tutor: JAIME GARCÍA REINOSO 

La defensa del presente Proyecto Fin de Carrera se realizó el día 27 de Enero de 2011; 

siendo calificada por el siguiente tribunal: 

Presidente: Francisco Valera Pintor 

Secretario Julio Villena Román 

Vocal Ángel M. Bravo Santos 

Habiendo obtenido la siguiente calificación: 

Calificación: 

Presidente Secretario Vocal 

iii

Agradecimientos 

En primer lugar quiero agradecer a mi tutor Jaime por todo el apoyo que he recibido 

y por la paciencia que ha tenido ante las dificultades que nos hemos ido encontrando por 

el camino. También quiero agradecer al resto de miembros de la Universidad que con su 

trabajo han hecho posible la realización de este Proyecto. 

A Teresa, por. . . bueno, por todo, porque eres mi constante, y cuando me han faltado 

las fuerzas, siempre has estado ahí. Desde el principio de mi vida de universitario, hasta 

el final de ésta que termina con este Proyecto, y lo que aún queda, que ahora viene lo 

mejor. 

A Laura, por aguantarme y por hacer que me esfuerce para poder dar el mejor ejemplo 

posible. Bueno, lo de aguantarme realmente va por todos. 

A mis padres, José María y Maribel, por hacerme como soy y por haberme dado la 

oportunidad con su sacrificio de tener el futuro que he elegido. 

A los titos, por todo lo que me han enseñado y me han dado. Siempre han pensado 

en mí antes que en ellos. 

A los abuelos, porque también de ellos he aprendido mucho. Espero que la abuela 

esté orgullosa allí arriba. Y al resto de mi familia por su apoyo. 

A todos mis amigos, Borja, Pablo, Patxi, Sabino, Alex, Jaime y todos los demás que 

desde que no levantábamos dos palmos del suelo han estado ahí para lo que necesitase. 

Y a todos mis compañeros de universidad por todas las horas de sufrimiento y de placer 

que hemos pasado durante estos años. 

Y por último, pero no por ello menos importante, a todos los que se me olvida mencionar, 

que con la cabeza que tengo son muchos, por cada granito de arena (o saco de 

arena) que ha puesto cada uno durante este tiempo. 

v

Al carro de la cultura española le falta la rueda de la ciencia. 

Santiago Ramón y Cajal 

El que controla el pasado, controla también el futuro. El que controla el presente, 

controla el pasado. 

1984 (George Orwell) 

vii

Resumen 

Actualmente en Internet existen servicios de transmisión de vídeo en tiempo real, bien 

de acontecimientos en directo o en diferido. Estos servicios pueden ser gratuitos o de 

pago, pero lo que no ofrecen es una calidad de servicio que nos garantice unos parámetros 

similares a la televisión convencional. Por ello han surgido algunas iniciativas para la 

transmisión de televisión sobre ADSL, donde esta señal no compite con el resto de las 

aplicaciones de Internet. En este proyecto se pretende desplegar un escenario de IPTV 

que dé acceso a la creciente oferta de proveedores de contenidos de Internet, de una forma 

en la que se garantice una cierta calidad de servicio, utilizando los medios dados por esta 

arquitectura. 

ix

x 

Abstract 

Nowadays in the Internet exists real-time transmission services, either broadcasting 

live or prerecorded. These services can be free or have a price, but what they don’t offer is 

a quality of service that guarantees similar parameters than conventional television. For 

this reason, there have arisen some initiatives for the transmission of television over ADSL 

where this signal does not compete with the rest of Internet’s applications. This project 

aims to develop an IPTV scenario which gives us access to the increasing availability of 

content providers in the Internet in a way that can guarantee a certain quality of service, 

using the resources given by this architecture.

Índice 

1. INTRODUCCIÓN 1 

1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2. ESTADO DEL ARTE 5 

2.1. Tecnologías xDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.2. El protocolo ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.3. Routed Ethernet (ETHoA, RFC1483 y MER) . . . . . . . . . . . . . . . . 9 

2.3.1. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.3.2. Servicio de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.3.3. Configuraciones TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.4. Dispositivos de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.4.1. DSLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.4.2. Modems DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.5. Topologías utilizadas por los proveedores de acceso . . . . . . . . . . . . . 13 

3. DISEÑO DE RED PARA IPTV 15 

3.1. Criterios de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2. Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

xi

3.3. Calidad de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

3.4. Diseño propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

4. IMPLEMENTACIÓN Y PRUEBAS DE LA RED IPTV 21 

4.1. Maqueta de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

4.2. Configuración de los equipos . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

4.2.1. Configuración del DSLAM . . . . . . . . . . . . . . . . . . . . . . . 22 

4.2.2. Configuración del servidor de vídeo . . . . . . . . . . . . . . . . . . 35 

4.2.3. Configuración del router ADSL . . . . . . . . . . . . . . . . . . . . 36 

4.3. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5. CONCLUSIONES 41 

5.1. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

ANEXO 45

Índice de figuras 

2.1. Símil de un circuito DSL para un usuario . . . . . . . . . . . . . . . . . . . 6 

2.2. Espectro de frecuencias general de una línea DSL . . . . . . . . . . . . . . 7 

2.3. Encapsulado de IP sobre ATM según la RFC1483 modo routing . . . . . . 10 

2.4. Arquitectura de un DSLAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.5. Red con servidor de contenidos propio . . . . . . . . . . . . . . . . . . . . 14 

3.1. Red con proveedores de contenidos externos . . . . . . . . . . . . . . . . . 20 

4.1. Maqueta de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

4.2. Flujos de datos de la maqueta de pruebas . . . . . . . . . . . . . . . . . . 23 

4.3. Diagrama de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

4.4. Linksys WAG54GS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

4.5. Configuración del tipo de conexión del router . . . . . . . . . . . . . . . . . 38 

4.6. Configuración IP del router . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

xiii

Índice de tablas 

2.1. Datos de configuración ADSL de los Diferentes ISP. . . . . . . . . . . . . . 13 

3.1. Comparación de red con servidores de vídeo propios y externos . . . . . . . 16 

xv

Capítulo 1 

INTRODUCCIÓN 

1.1. Introducción 

Las siglas IPTV (Internet Protocol Television) hacen referencia a un sistema de distribución 

de televisión digital que utiliza el protocolo IP (Internet Protocol) como base 

para su transporte. Este servicio se ha hecho muy popular en los últimos años al ofrecerse 

conjuntamente con el servicio de conexión a Internet. En España tenemos varios ejemplos: 

Imagenio (Telefónica), Jazztelia (Jazztel), Orange TV (Orange), etc. 

La principal diferencia con la televisión tradicional es el cambio de paradigma en la 

forma de interactuar con el cliente final, pues en lugar de enviar el mismo contenido a 

todos los clientes y esperar a que sean estos los que se conecten, es el cliente el que solicita 

el contenido que desea ver en cada momento. 

Según los datos del informe “Cisco Visual Networking Index: Forecast and Methodology, 

2009-2014”[4], en 2009 el transporte de vídeo por Internet supuso un tercio del 

tráfico residencial total y se espera que para finales de 2010 haya aumentado hasta cerca 

del 40 %, llegando al 57 % en el año 2014. Y estos datos se refieren tan solo a vídeos de 

Internet (como los de las páginas YouTube, Hulu, etc) pues si tenemos en cuenta todos 

los formatos de vídeo (televisión, vídeo bajo demanda, vídeo de Internet y vídeos intercambiados 

en redes P2P) tenemos que para el año 2014 la previsión sea del 91 % del 

tráfico global. Además, los nuevos formatos de vídeo en HD (alta definición) y en 3D (tres 

dimensiones) son cada vez más populares, por lo que aumentarán unas 23 veces hasta el 

2014, llegando a suponer el 46 % de los vídeos vistos en Internet. 

Centrándonos en lo que respecta al vídeo en tiempo real, éste tiene una importancia 

cada vez mayor. Por ejemplo, se espera que la televisión por Internet llegue a suponer el 

8 % del tráfico en 2014. Las retransmisiones en directo por Internet han crecido mucho en 

los últimos años, como se puede observar en el hecho de que la televisión P2P (P2P TV) 

supone la transferencia de más de 280 petabytes al mes. Además se prevé que el tráfico 

1

2 CAPÍTULO 1. INTRODUCCIÓN 

de vídeo bajo demanda se cuadruplique hasta el año 2014. 

Si nos referimos a datos económicos, según este mismo informe de Cisco[4], las previsiones 

son que la la tasa de crecimiento anual compuesto (TCAC o también CAGR en 

inglés) de la IPTV crezca a un ritmo del 33 % anual hasta el 2014. 

1.2. Motivación 

La importancia cada vez mayor de la transferencia de vídeos en Internet conlleva una 

serie de consecuencias que deben ser analizadas. Se abre un nuevo abanico de posibilidades 

que pueden ser aprovechadas y para ello resulta altamente recomendable tener una estructura 

de red que permita la separación de los proveedores de acceso, de los proveedores 

de servicios. 

Sin embargo, la oferta conjunta del acceso a Internet y del servicio de IPTV dificultan 

esta separación, pues para el proveedor de acceso a Internet existen una serie de ventajas 

técnicas si él mismo provee los contenidos. Por ejemplo, al ser una red cerrada es más 

sencilla de monitorizar, lo que permite una mayor seguridad y hace más fácil mantener 

una calidad de servicio de extremo a extremo. 

Lo que hoy en día hacen los proveedores es enviar todo el contenido de todos los canales 

desde los servidores de vídeo hasta todos los clientes por igual, siendo el decodificador el 

encargado de filtrar que canales puede ver cada uno. Además los canales disponibles son 

una lista cerrada que el proveedor se encarga de actualizar, sin que el usuario pueda elegir 

ningún canal que no se encuentre dentro de la oferta. 

La rápida evolución del vídeo dentro de los servicios que se ofrecen en Internet permite 

la posibilidad de ampliar la oferta de estos proveedores de acceso si son capaces de aprovechar 

la oportunidad y abrir sus redes a nuevos proveedores de contenidos. Apoyándonos 

en la tecnología actual, este cambio es posible y seguramente beneficiará a aquellos proveedores 

de acceso que sean capaces de asumir los riesgos que todo cambio supone. 

1.3. Objetivos 

A la vista de las oportunidades que empiezan a presentarse y que presumiblemente 

se ampliarán en el futuro, en este Proyecto se busca definir y validar un modelo 

de sistema de IPTV flexible que permita disponer de proveedores de servicios, 

independientes del proveedor de acceso, que diversifiquen la oferta de 

contenidos. 

Se evaluarán las ventajas e inconvenientes de este modelo, tanto desde el punto de 

vista técnico como comercial, a partir de los siguientes criterios:

1.3. OBJETIVOS 3 

Estandarización: se busca que la propuesta siga todos los estándares actuales con el 

fin de maximizar las posibilidades de despliegue en entornos reales de producción 

Seguridad: se intenta que la solución sea lo más segura posible frente a posibles 

ataques, tanto internos como externos. 

Robustez: el sistema debe soportar de la mejor manera posible el fallo de alguno de 

sus componentes. 

Compatibilidad: se maximizará la compatibilidad actual y futura con diferentes 

tecnologías. 

Escalabilidad: se intentará que el crecimiento del sistema sea lo más sencillo posible. 

Gestión de red: el sistema de gestión de la red debe ser sencillo, completo y a poder, 

ser unificado en un único equipo. 

Provisión de servicios: los nuevos servicios deben poder ser aprovisionados de la 

forma más rápida y limpia posible. 

Perdurabilidad: El tiempo de vida del sistema debe ser lo más amplio posible. 

Costes de mantenimiento (OPEX): se buscará que los costes de mantenimiento sean 

lo más reducidos posible. 

Costes de inversión (CAPEX): los costes de inversión no deben ser tan elevados 

como para que el sistema no sea viable económicamente. 

Para la validación de este modelo será necesario crear una maqueta de pruebas compuesta 

por diversos dispositivos, entre los que destaca el DSLAM (Digital Subscriber Line 

Access Multiplexer), que será el encargado de conectar a los servidores de contenido con 

los usuarios finales. La configuración y puesta en marcha del DSLAM supone 

uno de los objetivos básicos de este Proyecto.

4 CAPÍTULO 1. INTRODUCCIÓN

Capítulo 2 

ESTADO DEL ARTE 

2.1. Tecnologías xDSL 

El término xDSL o DSL (Digital Subscriber Line) hace referencia a una familia de tecnologías 

que permiten la transmisión digital de datos sobre las líneas telefónicas convencionales: 

ADSL, ADSL2, ADSL2+, SDSL, IDSL, HDSL, HDSL2, SHDSL, VDSL, VDSL2, 

MSDSL, PDSL, RADSL y UDSL. 

Esta tecnología nace a raíz de las limitaciones presentes en las líneas telefónicas convencionales, 

tales como el límite del ancho de banda de aproximadamente 4 KHz, que no 

permite transmitir a una tasa de transmisión suficiente para las nuevas aplicaciones que 

son cada vez más exigentes en este sentido. Este aumento de ancho de banda se consigue 

transportando los datos en una banda de alta frecuencia mientras que se deja la voz en las 

frecuencias bajas que venía ocupando. Esta separación de frecuencias se consigue mediante 

el uso de filtros, permitiendo el uso simultáneo de voz y datos. Estos filtros pueden estar 

colocados a la entrada de la vivienda (denominados Splitters) separando en dos cables 

voz y datos; o bien se puede colocar un filtro paso bajo en cada teléfono (microfiltros). 

Al contrario de lo que su nombre podría hacer pensar, la señal base transmitida en 

un circuito DSL es analógica y no digital. Se utiliza una modulación con una portadora 

sinusoidal de alta frecuencia. Un circuito DSL tiene en ambos extremos una pareja de 

modems. Para la transmisión se modulan los patrones de bits, enviando estas señales 

analógicas de alta frecuencia por el circuito, que son recibidas y demoduladas en el otro 

extremo por el otro modem, entregando los bits originales. 

En un principio el par de cobre que llegaba al cliente, conocido como bucle de abonado, 

era utilizado entre los 300 y los 3400 Hz (banda de frecuencias necesaria para que el 

oído humano comprenda el habla) pues se transmitía exclusivamente el servicio básico de 

telefonía. Sin embargo, con los avances en el procesado de señales y la aparición de nuevas 

técnicas de modulación se empezó a contemplar la posibilidad de utilizar frecuencias 

5

6 CAPÍTULO 2. ESTADO DEL ARTE 

Figura 2.1: Símil de un circuito DSL para un usuario 

mayores a las utilizadas por la voz. Dependiendo de la longitud y de la calidad del bucle 

local se puede llegar a frecuencias de varias decenas de Megahercios. Las tecnologías 

DSL utilizan este exceso de ancho de banda para crear canales de 4312,5 Hz de ancho 

empezando entre los 10 y los 100 KHz dependiendo de la configuración del sistema. Estos 

canales se siguen creando a frecuencias cada vez mayores hasta que se encuentra el límite 

superior en el que los nuevos canales creados no son utilizables. Esta evaluación de los 

canales se realiza continuamente de una forma similar a como lo realizaban los modems 

más antiguos sobre la banda de voz, añadiendo y quitando canales según sean aptos para 

su uso. Cuantos más canales se creen, mayor ancho de banda estará disponible. Es por 

esto que la distancia y la calidad de la línea tienen tanta incidencia en las tecnologías 

DSL; cuanto mayor sea la frecuencia utilizada, más atenuación se sufre y por lo tanto 

menor alcance se tiene.[18] 

En cada circuito ADSL se realiza esta multiplexación en frecuencia. Podemos asimilarla 

a un conjunto de modems analógicos transmitiendo en paralelo a distintas frecuencias por 

el mismo cable (véase la figura 2.1). Cada modem DSL de usuario (cuyo funcionamiento 

se detalla en el apartado 2.4.2) se podría asimilar a este conjunto de modems analógicos, 

quedando al otro extremo del par de cobre un equipo llamado DSLAM. Este equipo 

conecta con varias líneas de usuario, utilizando la multiplexación en frecuencia en cada 

una de ellas. En el otro extremo, el DSLAM conecta con una salida WAN y con una 

central telefónica. Trataremos este dispositivo más en detalle en el apartado 2.4.1. 

El conjunto de canales creados se divide en dos grupos según se vayan a utilizar en 

sentido ascendente (subida de datos) o descendente (descarga de datos), como se puede 

ver en la figura 2.2. Esta división puede ser simétrica (SDSL, por ejemplo) o asimétrica 

(ADSL, entre otras). El utilizar una relación de varios canales de bajada por cada uno

2.1. TECNOLOGÍAS XDSL 7 

Figura 2.2: Espectro de frecuencias general de una línea DSL 

de subida tiene su origen en la idea de que los clientes residenciales se descargan grandes 

cantidades de datos, mientras que raramente necesitan enviar muchos datos. Sin embargo, 

el nacimiento de las redes P2P (peer to peer) ha dado lugar a una mayor demanda de 

ancho de banda de subida, lo que ha llevado a la implementación de tecnologías como el 

anexo M, que aumentan la subida de las líneas ADSL2 y ADSL2+. 

La historia del éxito de las tecnologías DSL[18], y en especial del ADSL, refleja los 

avances realizados en la electrónica y la teoría del procesado de señales, los cuales fueron 

mejorando las prestaciones y bajando su coste frente a la alternativa de crear zanjas para 

introducir nuevos cables de cobre o de fibra óptica. Varios factores contribuyeron a la 

expansión de las tecnologías DSL: 

Hasta el final de los años 90 el coste de los procesadores de señales digitales era 

prohibitivo. Gracias al avance de la tecnología VLSI (Very-Large-Scale-Integration) 

el coste de los equipos necesarios para el despliegue de las tecnologías DSL (DS- 

LAMs en el lado del operador de red y modems DSL en el lado del cliente) se vio 

significativamente disminuido. 

El que la conexión DSL se pueda desplegar sobre un cable ya existente resulta mucho 

más barato que tender un cable de fibra óptica nuevo. 

La presión realizada por las compañías de cable, que ofrecían un ancho de banda muy 

superior al de los modems analógicos, hizo que las compañías telefónicas apoyasen 

el despliegue del ADSL.


2.2. El protocolo ATM 

ATM (Asynchronous Transfer Mode o Modo de Transferencia Asíncrona) es una técnica 

de transferencia de datos en la que la información se organiza en PDUs (Protocol Data 

Units) de 53 bytes denominadas celdas. Es asíncrono porque las celdas que contienen la 

información de un usuario concreto no son transmitidas de forma periódica, es decir, a 

diferencia de las redes síncronas en las que no se transmite nada si el usuario no tiene 

información que transmitir, una red ATM usará estos vacíos para transmitir otros datos. 

ATM provee servicios al nivel de enlace de datos sobre enlaces físicos de nivel 1 del 

modelo OSI. Presenta propiedades tanto de conmutación de circuitos como de paquetes; 

cada celda tiene una cabecera, al igual que los paquetes, pero a diferencia de éstos, su 

longitud es fija, como los slots de tiempo, aunque mucho mayor. Por este motivo es apto 

tanto para la transferencia de grandes cantidades de datos, como para comunicaciones en 

tiempo real. 

Una red ATM consta de nodos y enlaces. Por cada uno de estos enlaces se transmite 

un tráfico constante de celdas. Es decir, se basa en un modelo orientado a conexión en 

la que la información es transmitida utilizando las celdas de 53 bytes, que pueden ser 

enrutadas individualmente mediante el uso de los denominados canales virtuales (VC) y 

caminos virtuales (VP). 

Debido a la longitud fija de las celdas ATM, las PDUs de los niveles superiores que se 

quieren transportar mediante ATM necesitan ser adaptadas utilizando uno de los niveles 

de adaptación: 

AAL1: utilizado para la emulación de circuitos, por lo que es síncrono, orientado a 

conexión y soporta CBR (Constant Bit Rate). Tiene alta prioridad y está garantizado. 

AAL2: utilizado para voz a tasa variable, VBR (Variable Bit Rate), también es 

síncrono y orientado a conexión. El servicio es de baja prioridad, pero garantizado. 

AAL3/4: presta un servicio de datos orientado a conexión utilizado básicamente 

para la transmisión de datos en líneas ATM con altos niveles de interferencias. En 

un principio se definieron dos protocolos para esta clase de servicio, pero más tarde 

se unieron en uno solo. Tiene alta prioridad, aunque no está garantizado. Debido a 

su alta complejidad, se suele utilizar normalmente AAL5 para esta clase de servicio. 

AAL5: Es similar al AAL3/4, pero con una cabecera simplificada, lo que introduce 

menos overhead a cambio de prestar un servicio de baja prioridad y no garantizado. 

En resumen, normalmente se utiliza AAL1 para servicios que necesitan CBR o para la 

emulación de circuitos; AAL2 para servicios VBR y AAL5 para la transmisión de datos. 

Las características básicas de ATM son:

2.3. ROUTED ETHERNET (ETHOA, RFC1483 Y MER) 9 

La información se divide en celdas que son enrutadas individualmente utilizando 

canales virtuales (VC, Virtual Channel) y caminos virtuales (VP, Virtual Path). 

Se utiliza multiplexación temporal asíncrona. 

Está orientado a conexión. 

La señalización va fuera de banda. 

Se garantiza la entrega ordenada de las celdas transmitidas por el mismo canal 

virtual. 

La protección contra errores y el control de flujo se realizan de extremo a extremo. 

ATM ofrece una capa de transporte en la que se utilizan circuitos virtuales apoyados en 

los conceptos de camino virtual (VP, Virtual Path) y canal virtual (VC, Virtual Channel). 

Un VP es el camino que debe seguir una celda entre dos enrutadores ATM, y puede 

tener varios VC. Durante la conexión de la comunicación se establece para el destino 

seleccionado una calidad de servicio deseada, se busca el camino virtual que van a seguir 

todas las celdas y se reservan los recursos necesarios para garantizar dicha calidad de 

servicio. Este camino será fijo durante toda la comunicación, del tal forma que si se cae 

uno de los nodos por los que transcurre el camino, la comunicación se pierde. 

El circuito virtual en el que se transporta una celda viene reflejado en la cabecera 

de la misma mediante los campos VPI (Virtual Path Identifier) y VCI (Virtual Channel 

Identifier). Estos valores no tienen por qué ser constantes de extremo a extremo, sino que 

pueden ser cambiados en cada nodo enrutador según la tabla que éste posea. 

Una de las ventajas de utilizar estos circuitos virtuales es la posibilidad de multiplexar 

distintos servicios en cada uno de ellos. 

Para más información se puede consultar [3]. 

2.3. Routed Ethernet (ETHoA, RFC1483 y MER) 

El modo de Routed Ethernet (Ethernet enrutado), también conocido como MAC Encapsulated 

Routing (o ETHoA) funciona sobre el enrutamiento IP estándar. Los paquetes 

IP se encapsulan en tramas Ethernet antes de ser enviadas por la línea DSL. De este modo 

no existen diferencias aparentes para el servidor remoto entre las tramas provenientes de 

un bridge y las tramas provenientes de un cliente con línea DSL. 

2.3.1. Características 

Routed Ethernet tiene las siguientes características:


Es fácilmente reemplazable por un Bridge transparente. 

Permite una conexión rápida, sin necesidad de esperar a una negociación de la 

conexión o a una autenticación. 

Es autoconfigurable si está activado el protocolo DHCP. 

Varios usuarios pueden compartir una única dirección IP si se hace NAPT (Network 

Address Port Translation). 

2.3.2. Servicio de conexión 

El servicio de Routed Ethernet depende del servicio de conexión basado en 

AAL5 / RFC1483[14] / Bridged 1 para proporcionar conectividad (véase la figura 2.3). 

Figura 2.3: Encapsulado de IP sobre ATM según la RFC1483 modo routing 

Esto equivale a utilizar Ethernet sobre ATM (ETHoA) como tipo de servicio de conexión. 

En este tipo de servicio de conexión se encapsulan las tramas Ethernet (también 

conocidas como IEEE802.3, tramas MAC o Bridging frames) en AAL5/ATM. 

1 La RFC1483 ha sido actualizada a la RFC2684[13]. Aún así el uso de la primera está muy extendido.

2.4. DISPOSITIVOS DE ACCESO 11 

Los elementos de red utilizados deben cumplir con la RFC1483 “Multiprotocol Encapsulation 

over ATM Adaption Layer 5” y soportar los modos LLC/SNAP o VC-MUX para 

las PDUs (Protocol Data Units) del protocolo IEEE802.3. 

2.3.3. Configuraciones TCP/IP 

Se pueden utilizar dos escenarios distintos en la implementación de Routed Ethernet: 

El proveedor de servicios requiere el uso de DHCP. El cliente recibirá su configuración 

IP de un servidor DHCP remoto a través de la línea DSL. 

El proveedor de servicios reserva una IP pública al cliente, quien debe configurarla 

de forma manual en su router. 

Activando NAPT en el router del cliente se hace posible la comunicación de varios 

ordenadores del cliente con una sola dirección pública. 

2.4. Dispositivos de acceso 

2.4.1. DSLAM 

Es un elemento de red que se encuentra cerca del cliente y conecta varias líneas digitales 

(DSLs) a una red del operador de alta velocidad utilizando técnicas de multiplexión. El 

dispositivo separa la voz y los datos de las líneas de abonado, como se ha visto en la teoría 

desarrollada en el apartado 2.1. 

Y haciendo referencia a ese mismo apartado, la tecnología ADSL se basa en una 

pareja de modems por cada línea de usuario: uno en el domicilio de éste (ATU-R, ADSL 

Transceiver Unit - Remote) y otro en las instalaciones del proveedor de acceso (ATU-C, 

ADSL Termination Unit - Central Office) a donde llega el bucle de abonado y donde se 

encuentra la central local. Esta configuración complicaría el despliegue de esta tecnología 

en las centrales si no existiera el DSLAM, el cual consta de un chasis que agrupa muchas 

tarjetas, cada una de las cuales consta de varios modems ATU-C, y que además concentra 

el tráfico de todos los enlaces ADSL hacia una red WAN (véase figura 2.4). 

Esta integración de varios ATU-Cs en un equipo, el DSLAM, ha sido fundamental 

para que el ADSL no se haya quedado en un simple prototipo debido a la dificultad de 

desplegar un sinfín de modems ADSL. 

En función de la tecnología, los DSLAMs conectan las líneas ADSL con alguna combinación 

de los protocolos ATM, frame relay o IP. Desde el punto de vista de la torre


Figura 2.4: Arquitectura de un DSLAM 

de protocolos OSI, un DSLAM no es más que un elemento de nivel 2 (nivel de enlace). 

El DSLAM, como switch que es, recoge los datos provenientes de los modems ADSL y 

multiplexa estos datos por el enlace que le une al backbone de Internet. 

Tradicionalmente los DSLAMs han utilizado ATM para conectarse a los routers y los 

switches. Eran estos últimos los que extraían el tráfico IP y lo introducían en la red. 

Puesto que la mayoría del tráfico de los usuarios es IP, se evolucionaron los DSLAM para 

que fueran ellos mismos los que extrajesen el tráfico IP, creando así los IP DSLAMs. Las 

ventajas frente a los DSLAM que utilizan ATM son un menor gasto en inversiones y en 

mantenimiento (pues se necesitan menos equipos), además de la inclusión de mayores 

funcionalidades. 

2.4.2. Modems DSL 

Un módem DSL es un dispositivo que modula y desmodula las señales de la parte de 

datos de una línea DSL. Es por lo tanto un tipo de transductor, al que como hemos visto 

anteriormente, también se le llama ATU-R. 

A este módem se le suele conectar un ordenador o un router, aunque hoy en día es 

común integrar el modem DSL y el router en un único dispositivo. Será este dispositivo 

el que realice las tareas, tanto de composición de las tramas ATM a enviar, como del 

enrutamiento IP o del bridging. Además, estos dispositivos permiten el establecimiento

2.5. TOPOLOGÍAS UTILIZADAS POR LOS PROVEEDORES DE ACCESO 13 

de varios circuitos virtuales con diferentes VPI/VCI, lo que nos facilita de esta manera 

diferenciar distintos tipos de tráfico a enviar por cada circuito virtual. También es típico 

que estos routers DSL soporten QoS (Calidad de servicio) y sean capaces de priorizar y 

marcar paquetes con distintos niveles de precedencia dentro de un mismo circuito virtual. 

2.5. Topologías utilizadas por los proveedores de acceso 

En España podemos distinguir entre dos tipos de configuraciones ADSL. Por un lado 

tenemos conexiones punto a punto si el cliente obtiene una IP dinámica. En el caso de 

que se asigne una IP fija, los proveedores utilizan Routed Ethernet como se ha explicado 

en el apartado 2.3. 

Los datos de conexión de los distintos ISPs de España se puede observar en la tabla 

2.1 2 . 

Proveedor Tipo de IP Protocolo VPI/VCI Encapsulation Mode 

Jazztel Dinámica PPPoA 8/35 VC-MUX 

Jazztel ADSL2+ Dinámica PPPoE 8/35 LLC-BRIDGING 

Tele2 Dinámica PPPoA 8/35 VC-MUX 

Telefónica Dinámica PPPoE 8/32 LLC/SNAP 

Telefónica Fija RFC 1483 8/32 LLC/SNAP 

Orange Dinámica PPPoA 8/35 VC-MUX 

Orange 20 Megas Dinámica PPPoE 8/35 LLC-BRIDGING 

Orange Fija RFC 1483 8/32 LLC/SNAP 

Ya.com Dinámica PPPoE 8/32 LLC/SNAP 

Ya.com Fija RFC 1483 8/32 LLC/SNAP 

Tabla 2.1: Datos de configuración ADSL de los Diferentes ISP. 

Al diseñar una red para IPTV se debe plantear la localización de los servidores de 

vídeo. Tradicionalmente las empresas que ofrecen IPTV disponen los servidores de vídeo 

dentro de su propia red. El esquema sería el que se puede ver en la figura 2.5. 

Con esta configuración el ISP debe hacerse cargo del mantenimiento, así como de los 

contenidos de los servidores de vídeo. Esto representa, aparte de un aumento de costes, 

una disminución en la oferta de contenidos, pues el ISP debe dar cabida a cada nuevo 

canal dentro de sus servidores. 

2 Fuente: www.adslzone.net


Figura 2.5: Red con servidor de contenidos propio

Capítulo 3 

DISEÑO DE RED PARA IPTV 

Uno de los objetivos de este proyecto es evaluar la configuración utilizada actualmente 

(que denominaremos de ahora en adelante Red con servidor propio o walled-garden en 

inglés) y una propuesta alternativa (que llamaremos Red con servidor externo) desde 

el punto de vista de un proveedor de acceso que quiere introducirse en el negocio de la 

televisión por IP, y en función de unos criterios que permitan comparar las virtudes y 

desventajas de ambas. 

3.1. Criterios de diseño 

Los criterios seleccionados son los siguientes: 

Estandarización La utilización de estándares en la red reduce la posibilidad de errores 

por incompatibilidades, facilita la configuración y permite elegir entre varios 

fabricantes, reduciendo así los costes. 

Seguridad Se debe tener en cuenta la seguridad del sistema, sobre todo si se va a permitir 

la conexión a la red de terceras personas. 

Robustez El sistema debe ser lo más robusto posible frente a fallos de uno de sus componentes. 

Compatibilidad Se debe buscar un entorno que permita maximizar la compatibilidad 

actual y futura con diferentes tecnologías. 

Escalabilidad La red debe poder crecer de una forma fácil, sin que existan problemas 

tales como cuellos de botella. 

Gestión de red La gestión de los distintos elementos de la red debe ser lo más simple 

posible, y preferentemente estar unificada en un equipo. 

15

16 CAPÍTULO 3. DISEÑO DE RED PARA IPTV 

Red con servidor propio Red con servidor externo 

Estandarización Baja Alta 

Seguridad Alta Baja 

Robustez Baja Media 

Compatibilidad Baja Alta 

Escalabilidad Baja Alta 

Gestión de red Alta Baja 

Provisión de servicios Alta Baja 

Perdurabilidad Media Media 

OPEX Alta Baja 

CAPEX Alta Baja 

Tabla 3.1: Comparación de red con servidores de vídeo propios y externos 

Provisión de servicios Los nuevos servicios deben poder ser aprovisionados de la forma 

más rápida y limpia posible. 

Perdurabilidad El tiempo de vida del sistema debe ser suficientemente amplio y a ser 

posible debe aceptar los nuevos cambios tecnológicos. 

Costes de mantenimiento (OPEX) Los costes de mantenimiento deben ser lo más 

reducidos posible. 

Costes de inversión (CAPEX) El sistema debe tener unos costes de inversión contenidos 

para que sea viable económicamente. 

La tabla 3.1 muestra la comparación de las dos alternativas planteadas en función de 

los anteriores criterios. 

Podemos detallar más a fondo cada uno de estos criterios para ambas alternativas: 

Estandarización En la red con un servidor propio la estandarización no es un requisito 

indispensable, pues todos los componentes son propios y la única interacción con el 

mundo exterior se limita a la conexión de datos hacia Internet. Sin embargo, en el 

caso de contar con servidores externos, es extremadamente recomendable que todos 

los equipos estén estandarizados, pues así se facilita la conexión con los equipos de 

los proveedores de servicios, además de reducir los posibles problemas debidos a 

incompatibilidades. 

Seguridad La red con un servidor propio es, por definición más segura que otras alternativas, 

puesto que no es imprescindible permitir el paso de ningún operador externo a 

la red. Sin embargo, la propia conexión hacia Internet es un problema de seguridad 

a tener en cuenta. Por este motivo, aunque sea más sencillo gestionar la seguridad,

3.1. CRITERIOS DE DISEÑO 17 

no se puede afirmar que sea un sistema completamente seguro. En el caso de tener 

que permitir servidores externos, habrá que pensar detenidamente un sistema de 

seguridad que aisle los contenidos de vídeo del resto de servicios, de tal forma que 

no existan riesgos para la integridad del sistema. 

Robustez Un sistema con servidores externos, a priori, será más robusto que otro con 

servidores propios, pues la caída de uno de estos servidores, sólo afecta a sus propios 

contenidos. Sin embargo, hay que tener en cuenta los equipos que conectan con estos 

servidores externos, que deben ser redundantes, pues en caso de fallo de uno de ellos, 

las consecuencias pueden ser las mismas, o superiores, que en caso de caída de un 

servidor propio. En el supuesto de tener un servidor propio, éste debe ser redundante, 

así como las posibles conexiones troncales hacia él. 

Compatibilidad La compatibilidad es más fácil de conseguir cuando todos los equipos 

pertenecen a un solo propietario. Por lo tanto, si se opta por una red con servidores 

externos, siempre se debe tener en cuenta las posibles incompatibilidades al conectar 

equipos de distintas tecnologías, e incluso, es posible, con distintas filosofías. 

Escalabilidad Es más sencillo ampliar un sistema con servidores externos que uno con 

servidores propios, pues en el primer caso lo que habrá que gestionar es la conexión 

de un nuevo servidor a la red, pero no habrá que realizar toda la configuración, 

puesta en marcha y mantenimiento del mismo. 

Gestión de red Será más fácil gestionar una red con servidor propio que una con servidores 

externos, porque aunque se tengan que gestionar más elementos, al tener 

acceso directo a los mismos es más fácil detectar los posibles fallos. En la red con servidores 

externos, aunque el número de elementos a gestionar es menor (los servidores 

de contenidos externos no se gestionan), sí que se deben supervisar las conexiones 

con estos servidores externos. Y contando únicamente con esa información la gestión 

se hace más complicada. Además se hace necesaria la coordinación entre el 

proveedor de acceso y el de servicios cuando se encuentra alguna incidencia en la 

red. 

Provisión de servicios En el caso de la red con servidores externos, la provisión de un 

nuevo servicio implica crear una nueva conexión hacia el servidor de contenidos. En 

principio, se puede crear un procedimiento para que sea lo más sencillo posible. Si el 

servidor es interno, además de las conexiones, hay que poner en marcha y configurar 

el servidor de vídeo en si, lo cual es una tarea más a realizar. 

Perdurabilidad En principio, no debería haber grandes diferencias en el tiempo de vida 

de ambas redes. En todo caso, la red con servidores externos se vería algo más 

forzada a adaptarse a los cambios tecnológicos, aunque esto depende de que las 

empresas propietarias de los servidores externos actualicen los mismos y arrastren 

con este cambio al proveedor de servicios. 

Costes de mantenimiento (OPEX) El OPEX es menor en la red con servidores externos 

puesto que el numero de elementos a mantener es menor.


Costes de inversión (CAPEX) El CAPEX es también menor en la red con servidores 

externos, pues el numero de equipos a adquirir es menor. Además, el proveedor de 

servicios, al ser un mero intermediario entre el usuario y el proveedor de contenidos, 

no tendría que invertir en las licencias de los contenidos. 

Como se puede comprobar, la separación entre ambos tipos de proveedores nos abre 

un abanico de contenidos mucho mayor sin un sacrificio excesivo en ninguna de las áreas 

analizadas. 

3.2. Modelo de negocio 

Desde el punto de vista del proveedor de acceso, el modelo de negocio del escenario 

propuesto con servidores externos estaría basado en suscripción hacia los usuarios; y 

en conexión y volumen de tráfico hacia los proveedores de contenidos. Al usuario se le 

cobraría la cuota correspondiente para el acceso a Internet, como se hace actualmente. 

Adicionalmente se cobraría el acceso a la plataforma de televisión, que podría ser en un 

único pago como alta en el servicio, una cuota mensual, o incluso gratuito o promocionado, 

según cómo responda el mercado. 

Hacia los proveedores de contenidos, el proveedor de acceso cobraría un fijo por la 

conexión a la plataforma de televisión y además una cantidad variable según el tráfico 

cursado hacia sus servidores. De esta forma se asegura una viabilidad económica para 

mantener los estándares de calidad de servicio para todos los proveedores de contenidos, 

aunque la plataforma crezca y acaben unos pocos proveedores de contenidos recibiendo 

la mayoría del tráfico. 

Desde el punto de vista del proveedor de contenidos, su modelo de negocio estaría 

basado en suscripción, cobrando a los usuarios una cuota por el acceso a sus contenidos. 

Otra opción sería que el proveedor de acceso obtuviera un porcentaje de esa suscripción 

del usuario en lugar de cobrar por el volumen de tráfico. 

3.3. Calidad de servicio 

La calidad de servicio extremo a extremo la podemos asegurar basándonos en la separación 

de tráfico en VLANs y dando diferentes prioridades sirviéndonos de los mecanismos 

que nos ofrecen los estándares IEEE 802.1q[2] y IEEE 802.1p[1, 2]. Se podría utilizar el 

campo PCP (Priority Code Point) de la cabecera de las VLANs para fijar la prioridad 

según el tipo de tráfico (datos, voz o vídeo) que se transporte en su interior. Este marcado 

lo realizarían los equipos del core del proveedor de acceso. 

Es por ello que el diseño supone una red ethernet en el core (metroethernet). Este tipo

3.4. DISEÑO PROPUESTO 19 

de red nos permite separar los flujos de tráfico y poder supervisarlos fácilmente, teniendo 

acceso al origen y destino de los datos para poder realizar una tarificación correcta. 

Además, con esta configuración de red podemos utilizar multicast[10, 12, 9, 15] para la 

distribución de los canales. 

Para estimar el ancho de banda necesario para un canal de vídeo se ha supuesto que 

la transmisión es en alta definición (HDTV), y se ha utilizado el códec H.264[16] para 

el vídeo. Estos dos supuestos tienen su base en que hoy en día las retransmisiones en 

alta definición se han convertido en un estándar, y el códec más utilizado es el H.264. 

Utilizando ésta configuración, y guiándonos por lo publicado en [17], podríamos tener 

una buena calidad con una tasa de datos de 8 Mbps. Por supuesto, existen otros códecs 

que pueden reducir esta tasa a cambio de reducir la calidad, lo cual no resulta necesario 

al no ser esta tasa excesivamente alta. 

Teniendo en cuenta lo anterior, y para completar nuestro sistema de distribución de 

contenidos (CDN de las siglas de su nombre en inglés, content delivery network), nos 

hace falta definir la forma de acceso y subscripción de los clientes a los distintos canales 

ofertados. Para ello, se propone un portal de acceso que aglutine la oferta de todos los 

proveedores de contenidos. Este portal podría ser un software a instalar en un PC, lo que 

permitiría visionar la televisión desde el propio PC, o estar instalado en el descodificador 

que se conecte a la televisión. 

Como ya se ha mencionado anteriormente, con esta arquitectura se podría utilizar 

multicast para la distribución de canales. Para ello, el protocolo que más se ajusta es 

PIM-SM (Protocol Independent Multicast - Sparse-Mode)[11, 8, 7]. 

3.4. Diseño propuesto 

Como alternativa a la configuración tradicional, en la que los servidores de vídeo se 

encuentran en la red del proveedor de servicios, podemos plantearnos el diseño de la red 

de tal forma que estos servidores sean servidores externos gestionados por proveedores de 

contenidos ajenos al ISP. Un esquema de esta configuración de red sería el que se puede 

observar en la figura 3.1. 

Cada cliente tendrá en su domicilio un módem-router xDSL y un descodificador de 

vídeo, que adaptará la señal de vídeo proveniente del proveedor de servicios a un televisor. 

El módem-router conectará al DSLAM y utilizando los mecanismos de ATM, separará el 

tráfico entre ambos según sea un tráfico de datos, voz o vídeo. El DSLAM será el encargado 

de adaptar estos tráficos a la red metroethernet, encapsulándolos en distintas VLANs y 

entregándoselos a un router de frontera de la red metroethernet. Todo este proceso se 

detalla en el capítulo 4. Este router de frontera será el encargado además, de filtrar el 

tráfico multicast según las suscripciones de cada cliente conectado con él. 

La red metroethernet transportará los flujos de datos hasta los servidores de vídeo, los


Figura 3.1: Red con proveedores de contenidos externos 

cuales pueden encontrarse en cualquier red de otro proveedor de servicios. 

Una vez tenemos definido este modelo, debemos realizar un estudio de viabilidad técnica 

de una red en la que, con las infraestructuras típicas de las que dispone un proveedor 

de acceso hoy en día, se puede garantizar la seguridad y la fiabilidad del acceso a estos 

servidores de contenido externos. 

Para ello, en el siguiente capítulo se detalla la red que se ha construido en el laboratorio, 

y sobre la que se han realizado las pruebas necesarias para comprobar que esta propuesta 

puede ser viable tecnológicamente.

Capítulo 4 

IMPLEMENTACIÓN Y PRUEBAS 

DE LA RED IPTV 

4.1. Maqueta de pruebas 

Para simular una red en la que poder dar los servicios de voz, datos y vídeo, se 

utilizaron los elementos y conexiones que se pueden apreciar en la figura 4.1. Al DSLAM 

se le conectarán dos routers ADSL que simularán ser dos clientes residenciales. La salida 

WAN del DSLAM se conectará al servidor de vídeo, el cual, gracias al sistema GNU/Linux 

incorporado, hará las veces de router de salida hacia Internet y del propio servidor de 

vídeo. Esta doble función del servidor de vídeo es compatible con la simulación de una 

red con servidores de contenido externos pues, como se explica más adelante, la conexión 

del vídeo se realiza a través de una VLAN independiente. De esta forma, se podrían 

conectar otros servidores de vídeo desde Internet, haciendo llegar su tráfico al servidor de 

vídeo y redirigiéndolo internamente a la VLAN de vídeo. 

Por lo tanto, tenemos en la maqueta tres flujos de datos independientes: voz, datos y 

vídeo, como se puede observar en la figura 4.2. Nótese que el flujo de voz es independiente 

del servicio de telefonía RTB que viaja en la parte baja de las frecuencias del ADSL. Este 

flujo se ha añadido en la maqueta para simular telefonía IP en el caso de que se quisiera 

extender la filosofía de servidores externos de vídeo a la voz. 

Entre cada uno de los dos routers ADSL y el DSLAM se crean tres VCs con sus 

correspondientes VPI y VCI. Estos identificadores serán los mismos para todos los clientes, 

pues hay independencia para cada bucle de abonado: 8/32 para datos, 8/33 para voz y 

8/34 para vídeo. Para la capa superior, se configura en los routers MER (véase 2.3, con 

una IP única para cada VC, con encapsulado LLC/SNAP-BRIDGING. 

Por el interfaz WAN el DSLAM tiene configuradas tres VLANs por abonado, una para 

cada uno de los flujos de datos, vídeo y voz. Estas VLANs están también configuradas 

21

22 CAPÍTULO 4. IMPLEMENTACIÓN Y PRUEBAS DE LA RED IPTV 

Figura 4.1: Maqueta de pruebas 

en el servidor de vídeo, pues recordemos que actúa como router. El DSLAM actúa como 

un switch, transparente a nivel IP, interconectando los VCs de la parte cliente con las 

VLANs de la parte WAN. Por lo tanto, en el extremo del servidor de vídeo de las VLANs 

es donde se configuran las IPs para conectar con los routers de los clientes. 

La filosofía que seguimos para poner nombres a las VLANs se basa en el número de la 

línea de abonado (del 1 al 48) concatenado un 1 si es una VLAN de datos, un 2 si es de 

voz o un 3 si es de vídeo. Este procedimiento nos permitirá automatizar algunas tareas 

repetitivas de configuración en scripts. Se puede observar un ejemplo para la línea 30 en 

la figura 4.2. 

De esta forma, el diagrama de red completo se puede observar en la figura 4.3. Obsérvese 

en este diagrama que existe una VLAN más para la gestión del DSLAM, pues al estar 

funcionando como un switch necesita una IP para gestión. Por motivos de seguridad, solo 

se puede acceder a dicha gestión desde el interfaz WAN y a través de una VLAN específica. 

4.2. Configuración de los equipos 

4.2.1. Configuración del DSLAM 

El DSLAM utilizado en la maqueta es el Alcatel-Lucent 7330 ISAM FTTN ANSI. 

Es un IP DSLAM diseñado para hacer frente a la creciente necesidad de soluciones de

4.2. CONFIGURACIÓN DE LOS EQUIPOS 23 

Figura 4.2: Flujos de datos de la maqueta de pruebas 

acceso basadas en fibra. El 7330 permite a los proveedores de servicios ofrecer IPTV y 

otras aplicaciones que demanden gran ancho de banda, aprovechando el par de cobre ya 

existente en el bucle de abonado. 

El 7330 soporta de 24 a 500 suscriptores por nodo, incluyendo módulos de expansión 

de bajo coste para localizaciones difíciles de alcanzar o de baja densidad de abonados. 

Este DSLAM permite a los proveedores de acceso sacar provecho de los avances en la 

tecnología del cobre para ofrecer el triple play sin renunciar a su infraestructura existente. 

Las características de este DSLAM son: 

Switch Ethernet de 24 Gbps. 

Soporte completo de IGMP para multicast. 

Siete enlaces Gigabit Ethernet. 

Doce enlaces de expansión Gigabit Ethernet.


Figura 4.3: Diagrama de la red 

Tarjetas de línea de 48 puertos ADSL2+. 

Tarjetas de línea de 24 puertos VDSL, actualizables por software a VDSL2. 

Los beneficios que se obtienen de un DSLAM con estas características son: 

Permite una alta penetración del acceso de fibra, disminuyendo los enlaces de cobre 

y aumentando el ancho de banda disponible para servicios de IPTV no bloqueantes. 

Soporta todas las tasas de transferencia sin degradación del servicio, por lo que se 

reducen los costes de transporte. 

Administración remota y en tiempo real. 

Todas estas características, así como información adicional del DSLAM, se encuentran 

en el manual de descripción del sistema[6]. 

Aparte del DSLAM que se ha utilizado, existen otros en el mercado de fabricantes 

como CISCO, Lucent, Huawei o Zyxel. 

Debido a que la configuración del DSLAM es fundamental para este proyecto, a continuación 

se detallan los comandos necesarios para realizarla.


Configuración inicial 

De todos los equipos de la maqueta, el DSLAM es sin duda el más complicado de 

configurar. Lo primero que hay que hacer en el DSLAM es conectarse a través del puerto 

serie y configurar la gestión por IP, para poder conectarnos posteriormente mediante 

Telnet. 

Para la configuración se utilizan los comandos CLI (Command Line Interface) que se 

pueden encontrar en el manual de referencia del DSLAM[5]. 

La comunicación inicial se realiza a través de una sesión de hyperterminal con una 

configuración 9600-N-8-1-N. Tras pulsar ENTER el sistema nos preguntará: 

Would you like a CLI(C) or a TL1 login(T) or TL1 normal session(N)?[N]: 

a lo que responderemos C. 

A continuación debemos introducir el usuario y contraseña del equipo. La primera vez 

que se accede al equipo esta información es: 

login:isadmin 

password:i@mad- (no aparece al escribirlo) 

Después del primer acceso se nos pedirá que cambiemos la contraseña, por lo que 

introduciremos como nueva contraseña ANS#150. 

Lo que veremos por pantalla será: 

Would you like a CLI(C) or a TL1 login(T) or TL1 normal session(N)?[N]: C 

login:isadmin 

password:i\$@mad- (no aparece al escribirlo) 

Your password is expired ! 

enter new password: ANS#150 (no aparece al escribirlo) 

re-enter password: ANS#150 (no aparece al escribirlo) 

isadmin># 

La última línea es el prompt, que nos indica que ya tenemos abierta una sesión. 

El siguiente paso es habilitar y configurar el puerto WAN del equipo. Para ello se 

ejecuta el comando: 

configure interface shub port 1 port-type network admin-status up 

Este comando levanta el puerto 1 del interfaz shub (el switch Ethernet del DSLAM). 

El poner el tipo network es equivalente a declararlo puerto WAN, es decir, el puerto de 

salida.


A continuación se define la VLAN de gestión, asignándole una identidad e indicando 

cual de los puertos es el que va a utilizar como gestión: 

configure system mgnt-vlan-id 1605 

configure system single-public-ip 

configure system security snmp community public host-address 0.0.0.0/0 

configure system security snmp community NETMAN host-address 0.0.0.0/0 

context shub 

configure vlan shub id 1605 mode residential-bridge 

configure vlan shub id 1605 egress-port network:1 

configure vlan shub id 1605 egress-port nt 

Ahora ya podemos asignarle la dirección IP de gestión al DSLAM con los siguientes 

comandos: 

configure system management host-ip-address manual: 192.168.0.10/24 

configure system management default-route 192.168.0.1 

El primer comando define la IP del DSLAM y el segundo la IP del Gateway. Con esto 

ya podemos comprobar la conectividad lanzando un ping desde el DSLAM al servidor de 

vídeo: 

ping 192.168.0.1 

Una vez configurados estos datos los grabamos para que no se pierdan en caso de un 

reinicio del sistema: 

admin software-mngt shub databse save 

Configuración del equipamiento 

A partir de este punto ya somos capaces de acceder al DSLAM mediante Telnet, por 

lo que se han creado una serie de scripts en bash para configurar el equipamiento, los 

abonados y la calidad de servicio en el DSLAM. Estos scripts se pueden encontrar en el 

anexo. Aquí explicaremos los comandos que se lanzan al DSLAM para la configuración. 

Lo primero que podemos hacer, es establecer la fecha y hora en el DSLAM para tener 

más tarde una referencia en los logs del equipo. Para ello ejecutamos el comando:


admin sntp system-time yyyy-mm-dd:hour:minutes:secs 

Para saber las tarjetas que están instaladas físicamente en el DSLAM y que debemos 

declarar, utilizamos los siguientes comandos: 

Visualización del rack: 

isadmin>configure>equipment>applique>1/1/4# show equipment rack 

=========================================================================== 

rack table 

=========================================================================== 

rack actual-type 

--------------------------------------------------------------------------- 

1 altr-a 

2 empty 

3 empty 

--------------------------------------------------------------------------rack 

count : 3 

=========================================================================== 

Visualización del subrack: 

isadmin># show equipment shelf 

=========================================================================== 

shelf table 

=========================================================================== 

shelf actual-type enabled error-status availability 

--------------------------------------------------------------------------- 

1/1 aram-d yes no-error available 

1/2 no no-error not-installed 








--------------------------------------------------------------------------shelf 

count : 9 

=========================================================================== 

Visualización de las tarjetas:


isadmin>configure>equipment>shelf>1/1# show equipment slot 

=========================================================================== 

slot table 

=========================================================================== 

slot actual-type enabled error-status availability 

--------------------------------------------------------------------------- 

1/1/1 genc-e no no-planned-board available 

1/1/2 ecnt-a yes no-error available 

1/1/3 empty no no-error not-installed 

1/1/4 eblt-c no no-planned-board available 




--------------------------------------------------------------------------slot 

count : 7 

=========================================================================== 

Visualización de los applique: 

isadmin>configure>equipment>slot>1/1/4# show equipment applique 

=========================================================================== 

applique table 

=========================================================================== 

applique actual-type enabled error-status availability 

--------------------------------------------------------------------------- 

1/1/2 pwio-b no no-planned-board available 

1/1/3 unknown no no-planned-board available 

1/1/4 rpsp-a no no-planned-board available 

1/1/5 empty no no-error dependency 



--------------------------------------------------------------------------applique 

count : 6 

=========================================================================== 

Podemos observar como algunas tarjetas aparecen como no-planned-board. Para que 

el DSLAM las reconozca y estén operativas debemos ejecutar los siguientes comandos: 

isadmin># configure equipment shelf 1/1 class main-ethernet 

planned-type aram-d unlock 

isadmin># configure equipment slot 1/1/1 planned-type genc-e unlock


isadmin># configure equipment slot 1/1/2 planned-type ecnt-a unlock 

isadmin># configure equipment slot 1/1/4 planned-type eblt-c unlock 

isadmin># configure equipment applique 1/1/2 planned-type pwio-b 

isadmin># configure equipment applique 1/1/4 planned-type rpsp-a 

Cada uno de estos comandos declara y desbloquea una pieza de equipamiento. Se 

pueden lanzar de forma automática utilizando el script 1 que se puede encontrar en los 

anexos. 

Una vez ejecutados estos comandos, si volvemos a visualizar las tarjetas observaremos 

que el error-status de los elementos ha cambiado de no-planned-board a no-error. 

Ahora ya podemos nombrar al DSLAM para diferenciarlo de otros mediante el comando: 

configure system id DSLAM1 

Este comando también está incluido en el script 1. 

Configuración de los abonados 

En este punto debemos empezar con la declaración de los abonados de ADSL. La 

tarjeta de línea eblt-c da servicio a 48 abonados. Lo primero que debemos hacer, es crear 

uno o varios parfiles que serán posteriormente aplicados a las líneas de los abonados. Es 

en estos perfiles en los que se definen las tasas de sincronización, tanto de subida como 

de bajada, así como el estándar de la familia DSL que se utilizará. En nuestra maqueta 

hemos definido un perfil ADSL2+ (ITU G.992.5) con una tasa de bajada de 18 Mb/s y 

una tasa de subida de 1 Mb/s. Para ello es necesario ejecutar los siguientes comandos: 

isadmin># configure xdsl service-profile 1 name practicas 

isadmin>configure>xdsl>service-profile>1$ ra-mode-up operator-ctrld 

ra-mode-down operator-ctrld 

isadmin>configure>xdsl>service-profile>1$ plan-bitrate-up 1024 

plan-bitrate-down 18432 active 

isadmin>configure>xdsl>service-profile>1$ configure xdsl 

spectrum-profile 1 name practicas 

isadmin>configure>xdsl>spectrum-profile>1$ g992-5-a active 

isadmin>configure>xdsl>spectrum-profile>1# configure xdsl line 1/1/4/[1...48] 

service-profile 1 spectrum-profile 1 admin-up 

El primer comando crea un perfil de servicios y le da nombre (en nuestro caso lo hemos 

llamado prácticas). El segundo comando declara que las tasas de subida y bajada serán


controladas manualmente por el operador. El tercer comando establece estas tasas de 

subida y bajada y activa el perfil. Con el cuarto comando creamos un perfil de espectro y 

le damos un nombre, en este caso el mismo que el perfil de servicios, aunque no tiene por 

qué ser así. En el quinto comando activamos el perfil y lo establecemos como ADSL2+ 

(ITU G.992.5). Por último el sexto comando aplica los perfiles de servicio y de espectro a 

las 48 líneas de abonado. 

Todos estos comandos también están recogidos en el script 1. 

Si queremos comprobar que los perfiles están bien configurados, podemos ver sus 

propiedades con los siguientes comandos: 

isadmin>configure>xdsl>service-profile>1# info 

configure xdsl 

#-------------------------------------------------------------------------echo 

"xdsl" 

#-------------------------------------------------------------------------service-profile 

1 name practicas 

local-profile 

version 1 

ra-mode-down operator-ctrld 

ra-mode-up operator-ctrld 

plan-bitrate-down 18432 

plan-bitrate-up 1024 

active 

exit 

#-------------------------------------------------------------------------isadmin>configure>xdsl>service-profile>1# 

configure xdsl spectrum-profile 1 

isadmin>configure>xdsl>spectrum-profile>1# info 

configure xdsl 

#-------------------------------------------------------------------------echo 

"xdsl" 

#-------------------------------------------------------------------------spectrum-profile 

1 name practicas 

local-profile 

version 1 

g992-5-a 

power_mgnt_mode none 

vdsl 

max-band unrestricted 

max-freq ulimited 

m-psd-level-down no-constraint 

m-psd-level-up no-constraint 

psd-pbo-par-a-up 0f:a0:12:7a:15:18:15:18:15:18


psd-pbo-par-b-up 00:00:07:b9:06:29:04:35:03:af 

exit 

vdsl2 

psd-pbo-e-len-up estimated 

m-psd-level-down no-constraint 

m-psd-level-up no-constraint 

psd-pbo-par-a-up 0f:a0:12:7a:15:18:15:18:15:18 

psd-pbo-par-b-up 00:00:07:b9:06:29:04:35:03:af 

v-noise-psd-down 00:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00: 

00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00: 



00:ff:00:00:ff:00:00:ff 

v-noise-psd-up 00:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00:00:ff:00: 


00:ff:00:00:ff:00:00:ff 

exit 

active 

exit 

#-------------------------------------------------------------------------- 

En este punto, si observamos los LEDs del equipo, veremos que tiene encendido el 

LED de alarma. Si pedimos la lista de alarmas al equipo vemos: 

isadmin># show alarm current table 

=========================================================================== 

table table 

=========================================================================== 

index type last-updated-on 

--------------------------------------------------------------------------- 

1 equipment 1970-01-01:00:02:40 

2 redundancy 1970-01-01:00:04:06 

--------------------------------------------------------------------------table 

count : 2 

=========================================================================== 

isadmin># show alarm current equipment 

=========================================================================== 

equipment table (detailed) 

=========================================================================== 

--------------------------------------------------------------------------equipment---------------------------------------------------------------------------


index : 1 persist-data : lost 

sntp-comm : not-lost 

nt-disk : less-than-ninty-perc 

preferred-mode : available timing-reference : available 

connection-lost : not-lost 

=========================================================================== 

isadmin># show alarm current redundancy 

=========================================================================== 

redundancy table (detailed) 

=========================================================================== 

--------------------------------------------------------------------------redundancy--------------------------------------------------------------------------index 

: 2 loss-swo-cap : loss 

=========================================================================== 

Estas dos alarmas están provocadas porque el equipo detecta que no tiene redundada 

la controladora y por lo tanto no tiene capacidad de switch over en caso de fallo de la 

misma. Nosotros somos conscientes de dicha limitación, por lo que podemos reconocer la 

alarma y configurarla para que no vuelva a activarse. Eso se realiza con los siguientes dos 

comandos, que también están incluidos en el script 1: 

isadmin># admin alarm clr-persist-loss 

70/01/01 17:24:30 critical alarm cleared for (service affecting) : 

System and backup memory reset 

isadmin># configure alarm entry loss-over-cap no reporting no logging 

70/01/01 17:26:42 major alarm cleared for : Loss of protection switching 

capability 

Con esto el LED de alarma se habrá apagado y si volvemos a pedir las alarmas al 

equipo veremos que no hay ninguna activa: 

isadmin># show alarm current table 

=========================================================================== 

table table 

=========================================================================== 

index type last-updated-on 

---------------------------------------------------------------------------


--------------------------------------------------------------------------table 

count : 0 

=========================================================================== 

Configuración de los PVCs 

Por último, debemos configurar los PVCs de cada línea. Además aplicaremos unas 

políticas de QoS para limitar el tráfico de cada uno de ellos en el bucle de abonado y 

garantizar que así no interfieran unos servicios con otros. Lo primero que debemos definir 

son unas sesiones (session en los comandos del DSLAM) compuestas por un policer de 

subida y otro de bajada. Este policer será el encargado de restringir la tasa de tráfico al 

límite establecido por el parámetro committed-info-rate en kbps, permitiendo un exceso 

de tráfico de committed-burst-size bytes. 

Los comandos utilizados son: 

configure qos profiles policer 1M committed-info-rate 1024 

committed-burst-size 1024 







configure qos profiles session datos up-policer name:1M 

down-policer name:3M logical-flow-type pvc 

configure qos profiles session voz up-policer name:1M 


configure qos profiles session vídeo up-policer name:1M 


Los cuatro primeros comandos definen los policers para unas tasas de 1, 3, 6 y 8 

Mbps respectivamente. Los siguientes tres comandos crean las sesiones para los perfiles 

de datos, voz y vídeo. Los tres tienen asignado el policer de 1 Mbps para la subida. La 

bajada está limitada a 3, 6 y 8 Mbps respectivamente. Esto hace un total de 17 Mbps, 

frente a los 18 Mbps que tiene configurada la línea ADSL, por lo que tenemos 1 Mbps 

extra para los excesos de tráfico.


Una vez tenemos listas las sesiones de QoS podemos crear los PVCs de cada una 

de las 48 líneas. Para ello, hay que definir primero las VLANs para cada PVC y después 

establecer el PVC y asignarle la VLAN con su sesión de QoS correspondiente. Por ejemplo, 

para crear el PVC de datos de la línea 30 haría falta ejecutar los siguientes comandos: 

configure vlan id 301 name datos30 mode qos-aware 

configure vlan id 301 dhcp-opt-82 circuit-id customer-id 

configure vlan shub id 301 name datos30 mode cross-connect 

configure vlan shub id 301 egress-port network:1 

configure vlan shub id 301 egress-port lt:1/1/4 

configure interface port xdsl-line:1/1/4/30 user linea30 admin-up 

configure atm pvc 1/1/4/30:8:32 aal5-encap-type llc-snap 

configure interface atm-pvc 1/1/4/30:8:32 customer-id datos30 

configure bridge port 1/1/4/30:8:32 

configure bridge port 1/1/4/30:8:32 vlan-id 301 

configure bridge port 1/1/4/30:8:32 pvid 301 

configure bridge port 1/1/4/30:8:32 qos-profile name:datos 

En los dos primeros comandos se crea una VLAN con id 301 (concatenación de la línea 

30 y el 1 porque es una VLAN de datos) y se le establece la opción de QoS. Con los tres 

siguientes comandos se declara la VLAN en el shub, es decir, en el switch Ethernet del 

DSLAM, definiendo el puerto de red y el puerto local por el que circulará dicha VLAN. 

Una vez creada la VLAN procedemos con los siguientes comandos a activar el PVC 

con VPI=8 y VCI=32 en la línea 30. Y una vez creado le asignamos la VLAN que hemos 

definido anteriormente. Por último le asignamos el perfil de QoS de datos. 

Estos pasos hay que realizarlos para cada PVC de cada línea. En caso de disponer de 

un gestor central, la provisión sería mucho más simple. Sin embargo, al no tener uno en 

el entorno de pruebas, se ha creado el script 2 que se puede encontrar en los anexos para 

automatizar esta tarea. 

Borrado de configuraciones y reinicio 

En el caso de querer borrar algunas de las configuraciones anteriores se usará la partícula 

no en el comando correspondiente. Por ejemplo, si queremos borrar el PVC 8/32 de la 

línea 30 ejecutaríamos el siguiente comando: 

configure atm no pvc 1/1/4/30:8:32 

O si quisiéramos desasociar el perfil de QoS asociado a dicho PVC escribiríamos:


configure bridge port 1/1/4/30:8:32 no qos-profile 

Para facilitar la tarea de desasociar los perfiles de QoS y borrar las interfaces de cliente, 

junto con las VLANs correspondientes se han creado los scripts ?? y ?? respectivamente. 

Por último si lo que queremos es un borrado completo del DSLAM y restaurarlo a su 

estado de fábrica el comando a ejecutar es: 

admin equipment reboot-isam default-no-data 

Este mismo comando se usa para reiniciar el DSLAM, sin necesidad de borrar la 

configuración, si lo ejecutamos sin la última parte del comando, es decir: 

admin equipment reboot-isam 

4.2.2. Configuración del servidor de vídeo 

La configuración del servidor de vídeo que a continuación se detalla es la referente 

a la parte de enrutamiento, es decir, la configuración del sistema Linux instalado en el 

servidor de vídeo que utilizamos para conectar el DSLAM hacia el exterior y separar las 

diferentes VLANs. 

Con este objetivo creamos tres interfaces (llamadas datos, voz y vídeo) utilizando el 

comando brtcl. Este comando se utiliza para crear y configurar interfaces Internet bridge 

que conecten varios interfaces ethernet. Puesto que tenemos tres VLANs por cada abonado 

(datos, voz y vídeo), esta configuración nos permitirá conectar todas las VLANs de datos 

de los diferentes clientes y mantenerlas separadas de las otras VLANs. Lo mismo se aplica 

a las VLANs de voz y vídeo. 

Para facilitar la configuración se ha realizado el script 3, que se puede encontrar en 

los anexos. Los comandos básicos de dicho script son: 

brctl addbr datos 

brctl addbr voz 

brctl addbr vídeo 

Estos tres comandos crean los tres interfaces de bridge para los datos, voz y vídeo. 

vconfig add eth2 301 

ifconfig eth2.301 up 

brctl addif datos eth2.301


Los dos primeros comandos crean una interfaz con la VLAN correspondiente ligada a 

la interfaz eth2. Ésta es la interfaz física Ethernet del servidor de vídeo que conecta con 

la interfaz WAN del DSLAM. El identificador 301 se corresponde, como ya explicamos 

anteriormente, a la VLAN de datos de la línea 30. El segundo comando, por su parte, 

conecta esta interfaz recién creada a la interfaz de bridge de datos. 

ifconfig datos 192.168.1.1 

ifconfig voz 192.168.2.1 

ifconfig vídeo 192.168.3.1 

Por último, con estos tres comandos les asignamos una dirección IP a las tres interfaces 

Internet bridge que hemos creado. Esta dirección IP la comparten cada una las VLANs 

de datos, voz y vídeo respectivamente. De esta forma, el servidor de vídeo tiene una única 

dirección IP por cada VLAN para todos los clientes. 

4.2.3. Configuración del router ADSL 

El router utilizado para las pruebas ha sido el Linksys WAG54GS Router ADSL. 

Este router dispone de un módem ADSL2+, 4 puertos Ethernet 10/100 e incorpora un 

punto de acceso Wireless-G (802.11g). En el apartado de configuración permite todas 

las configuraciones más comunes, incluida MER/RFC1483, y es similar a la mayoría de 

los routers que utilizan los proveedores de acceso, por lo que es una buena opción para 

realizar las pruebas necesarias en la maqueta. 

La configuración del router ADSL es muy simple, pues debe ser capaz de realizarla un 

cliente en su domicilio. Aunque también sería posible enviar el router ya configurado. 

En la maqueta de pruebas hemos decidido asignar una IP fija para cada una de las 

VLANs de cada cliente. De esta forma nos es más simple supervisar el tráfico para las 

pruebas. Sin embargo, se podría asignar esta IP automáticamente utilizando DHCP. 

Lo único que debemos configurar en cada router son tres PVCs con los siguientes 

VPI/VCI: 8/32 para datos, 8/33 para voz y 8/34 para vídeo. En la configuración hay que 

escoger el tipo de conexión RFC1483, que dependiendo del fabricante del router puede 

ser llamada de diversas formas: 

RFC 1483 Bridged 

Dinamic/Fixed IP in 1483 Bridge Mode 

MAC Encapsulation Routing (o M.E.R.) 

ENET ENCAP

4.3. PRUEBAS REALIZADAS 37 

Figura 4.4: Linksys WAG54GS 

El tipo de encapsulado será LLC/SNAP-BRIDGING. Podemos ver un ejemplo de 

configuración en la figura 4.5. 

Asimismo, podemos observar una captura de la página de configuración de IP del 

router en la figura 4.6. 

Con esto ya tendríamos todos los elementos de la maqueta configurados y podemos 

pasar a probar su correcta conectividad. 

4.3. Pruebas realizadas 

Las pruebas realizadas utilizando la maqueta se han centrado en demostrar la viabilidad 

técnica de poder disponer de un enlance seguro, fiable e independiente desde 

servidores externos a la red hasta los usuarios finales de la misma. 

Lo primero de todo es comprobar la conectividad de la parte ADSL. Puesto que el 

DSLAM es un elemento de nivel 2, debemos analizar los logs del router para comprobar 

que se ha establecido la conexión correctamente: 

Fri, 1999-12-31 12:00:19 - br0: topology change detected, propagating 

Fri, 1999-12-31 12:00:19 - br0: port 1(eth0) entering forwarding state


Figura 4.5: Configuración del tipo de conexión del router 

Fri, 1999-12-31 12:00:34 - ADSL G.992 started 

Fri, 1999-12-31 12:00:36 - ADSL link down 

Fri, 1999-12-31 12:00:48 - ADSL G.994 training 

Fri, 1999-12-31 12:01:22 - ADSL G.992 started 

Fri, 1999-12-31 12:01:25 - ADSL G.992 channel analysis 

Fri, 1999-12-31 12:01:29 - ADSL G.992 message exchange 

Fri, 1999-12-31 12:01:29 - ADSL link up, interleaved, us=1024, ds=18432 

Fri, 1999-12-31 12:01:30 - apps set the adsl with value 1 

Fri, 1999-12-31 12:01:30 - , the count is 2 

Como podemos observar en los mensajes del router, se ha establecido correctamente 

el enlace del ADSL a una tasa de 1 Mbps de subida (us es decir upstream) y 18 Mbps de 

bajada (ds o downstream). 

Habiendo comprobado el nivel ADSL, lo siguiente es probar la conectividad a nivel 

3, es decir, realizar pings desde y hacia el servidor de vídeo para cada uno de los PVCs 

configurados. En primer lugar conectamos un PC a unos de los puertos Ethernet del router 

del cliente 1 y lo configuramos con la IP 10.0.0.128 (véase la figura 4.3. Desde este PC 

realizamos un Telnet a la IP local del router, 10.0.0.1.

4.3. PRUEBAS REALIZADAS 39 

Figura 4.6: Configuración IP del router 

Desde aquí probaremos que la conectividad desde el router hasta el servidor de vídeo 

es correcta. Para ello realizamos un ping a cada una de las tres IPs del servidor de vídeo: 

192.168.1.1, 192.168.2.1 y 192.168.3.1. Una vez comprobado que esto funciona correctamente 

repetimos los pings desde el PC conectado al router. De esta forma, probaremos 

que la tabla de rutas del router es correcta y éste es capaz de enrutar hacia cualquiera de 

las subredes de datos, voz y vídeo. 

Tras estas pruebas conectamos un segundo router a otra línea y repetimos las comprobaciones 

anteriores. Una vez éstas sean correctas, podemos pasar a comprobar la conexión 

entre los dos clientes. 

Por seguridad, y para evitar que haya tráfico sin supervisar y sin tarificar, si ello 

es necesario, el DSLAM no permite la interconexión directa entre los clientes que tenga 

conectado. Por ello, para que estos clientes puedan verse, debe haber un elemento en la 

parte WAN que realice las interconexiones y el enrutado entre ellos. En nuestro caso, este 

elemento será el servidor de vídeo. 

Primero probaremos que con toda la maqueta correctamente conectada y configurada, 

podemos hacer un ping desde un router de cliente a otro. Una vez realizada esta comprobación, 

desconectamos el interfaz que conecta al DSLAM con el servidor de vídeo y 

comprobamos que, como es de esperar, se pierde la conexión entre los clientes, pues el 

DSLAM no está realizando ningún tipo de conexión entre ellos. 

Una vez realizadas estas pruebas desde los clientes, pasamos al servidor de vídeo. Lo 

primero que podemos hacer es comprobar la conectividad desde el servidor de vídeo a los 

routers de los clientes. En principio, no podemos alcanzar los PCs de los clientes puesto 

se encuentran detrás de los routers, y de cara al exterior toda la red local de cliente 

comparte las IPs de las interfaces externas de los routers. Si quisiéramos llegar a un PC


en particular de la red privada de uno de los clientes habría que utilizar NAT (Network 

Address Translation) en los routers. Esto no va a ser necesario en el escenario propuesto, 

pues serán los clientes los que empiecen las conexiones hacia los servidores de vídeo, y no 

al revés. 

En el switch que conecta el servidor de vídeo con el DSLAM realizamos una captura 

de tráfico para comprobar que, efectivamente, los paquetes que viajan entre los dos dispositivos 

están etiquetados con la VLAN correspondiente. Con esto nos aseguramos de 

que tenemos separados los tres flujos de tráfico. 

Por último, nos queda simular un servidor externo a la red. Para ello, conectamos un 

PC al otro interfaz Ethernet (eth1 ) del servidor de vídeo, y configuramos el enrutado para 

que se permita todo el tráfico con los siguientes comandos: 

echo "1" > /proc/sys/net/ipv4/ip_forward 

iptables -A FORWARD -j ACCEPT 

De esta forma comprobamos que también se puede acceder a los clientes desde el 

exterior de la red, y que cada tipo de tráfico viaja por su VLAN correspondiente. Por este 

motivo nos resulta muy simple filtrar el tráfico y por ejemplo, dejar pasar el tráfico desde 

una IP origen a un único rango de destino, que puede ser bien un conjunto de clientes, o 

las VLANs de unos servicios determinados.

Capítulo 5 

CONCLUSIONES 

Nuestro punto de partida era proponer un modelo de sistema de IPTV flexible, que 

permitiera disponer de proveedores de servicios independientes del proveedor de acceso, 

que diversifiquen la oferta de contenidos. Hemos analizado las ventajas e inconvenientes 

de este modelo, comparado con el modelo actual, tomando los siguientes criterios: 

Estandarización 

Seguridad 

Robustez 

Compatibilidad 

Escalabilidad 

Gestión de red 

Provisión de servicios 

Perdurabilidad 

Costes de mantenimiento (OPEX) 

Costes de inversión (CAPEX) 

Se ha concluido que, si bien no se va a mejorar en todos ellos, sí que el modelo propuesto 

podría ser viable técnica y económicamente. Además de abrir grandes oportunidades para 

introducir variedad en los contenidos, e incluso contenidos específicos para cada cliente. 

Para reforzar la afirmación de que el modelo era viable técnicamente, se diseñó y 

montó una maqueta de pruebas en la que poder simular una red como la propuesta a 

41

42 CAPÍTULO 5. CONCLUSIONES 

pequeña escala. Tras el montaje y las pruebas pertinentes, se concluyó que es posible 

diferenciar y separar el tráfico en función de los servicios que se quieran ofrecer y del 

cliente final. De esta forma, podemos alcanzar las premisas de partida de una red IPTV 

flexible, en la que la oferta de contenidos no esté limitada a la que ofrece el proveedor de 

acceso. 

Además, durante el montaje de la maqueta se ha generado una pauta de configuración 

del DSLAM, el cual era otro de los objetivos principales de este Proyecto. 

5.1. Trabajos futuros 

En este Proyecto se han establecido las bases que definen un nuevo modelo de IPTV. 

A partir de aquí, se abre un abanico de posibilidades para perfeccionar y ampliar este 

modelo en el futuro. 

Se podría realizar un estudio exhaustivo sobre el uso de multicast y las pruebas correspondientes 

para ver cómo se adapta y que nivel de eficiencia se alcanza con la estructura 

propuesta. 

También se podría analizar y definir una red metroethernet que sea óptima para el 

transporte de los distintos flujos de datos y para la conexión con los proveedores de 

contenidos. Además se podría proponer un modelo alternativo de calidad de servicio que 

se adapte mejor a esta red. 

Por último, habría que diseñar una plataforma de software que sirva de portal para 

la suscripción a los distintos proveedores de contenidos y permita a los usuarios gestionar 

estas suscripciones. Asimismo, sería muy útil poder integrar este software en el descodificador 

conectado a la televisión para poder realizar este proceso de la forma más intuitiva 

posible.

ANEXO 

43

1 

ANEXO 

Scripts de configuración 

2 #! / bin / bash 

3 

4 echo ” I n i c i a l i z a n d o DSLAM” 

5 

Script 1: Inicialización del DSLAM 

6 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

7 sleep 1 

8 echo ” isadmin ” 

9 sleep 1 

10 echo ”ANS#150” 

11 sleep 1 

12 echo ” c o n f i g u r e equipment s h e l f 1/1 c l a s s main−e t h e r n e t planned−type aram−d ←↪ 

unlock ” 

13 sleep 1 

14 echo ” c o n f i g u r e equipment s l o t 1/1/1 planned−type genc−e unlock ” 

15 sleep 1 

16 echo ” c o n f i g u r e equipment s l o t 1/1/2 planned−type ecnt−a unlock ” 

17 sleep 1 

18 echo ” c o n f i g u r e equipment s l o t 1/1/4 planned−type e b l t −c unlock ” 

19 sleep 1 

20 echo ” c o n f i g u r e equipment a p p l i q u e 1/1/2 planned−type pwio−b” 

21 sleep 1 

22 echo ” c o n f i g u r e equipment a p p l i q u e 1/1/4 planned−type rpsp−a” 

23 sleep 1 

24 echo ” c o n f i g u r e system i d DSLAM1” 

25 sleep 1 

26 echo ” c o n f i g u r e x d s l s e r v i c e −p r o f i l e 1 name p r a c t i c a s ” 

27 sleep 1 

28 echo ” ra−mode−up operator −c t r l d ra−mode−down operator −c t r l d ” 

29 sleep 1 

30 echo ” plan−b i t r a t e −up 1024 plan−b i t r a t e −down 18432 a c t i v e ” 

31 sleep 1 

32 echo ” c o n f i g u r e x d s l spectrum−p r o f i l e 1 name p r a c t i c a s ” 

33 sleep 1 

34 echo ”g992−5−a a c t i v e ” 

35 sleep 1 

36 echo ” c o n f i g u r e x d s l l i n e 1 / 1 / 4 / [ 1 . . . 4 8 ] s e r v i c e −p r o f i l e 1 spectrum−p r o f i l e 1←↪ 

admin−up” 

37 sleep 30 

38 echo ”admin alarm c l r −p e r s i s t −l o s s ” 

39 sleep 1 

40 echo ” c o n f i g u r e alarm entry l o s s −over−cap no r e p o r t i n g no l o g g i n g ” 

41 sleep 1 

45

46 

42 echo ” l o g o u t ” ) | telnet >> salida . txt 

43 

44 echo ”DSLAM i n i c i a l i z a d o ” 

1 

2 #! / bin / bash 

3 

4 linea10=0 

5 ident=0 

6 

7 echo ”Creando l o s p e r f i l e s de QoS” 

8 

Script 2: Creación de los abonados 

9 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

10 sleep 1 


12 sleep 1 

13 echo ”ANS#150” 

14 sleep 1 

15 echo ” c o n f i g u r e qos p r o f i l e s p o l i c e r 1M committed−i n f o −r a t e 1024 committed−burst−s i z e ←↪ 

1024 ” 

16 sleep 1 


3072 ” 

18 sleep 1 


6144 ” 

20 sleep 1 


8192 ” 

22 sleep 1 

23 echo ” c o n f i g u r e qos p r o f i l e s s e s s i o n datos up−p o l i c e r name : 1M down−p o l i c e r name : 3M ←↪ 

l o g i c a l −flow−type pvc ” 

24 sleep 1 

25 echo ” c o n f i g u r e qos p r o f i l e s s e s s i o n voz up−p o l i c e r name : 1M down−p o l i c e r name : 6M ←↪ 


26 sleep 1 

27 echo ” c o n f i g u r e qos p r o f i l e s s e s s i o n vídeo up−p o l i c e r name : 1M down−p o l i c e r name : 8M ←↪ 


28 sleep 1 


30 

31 echo ” Creados l o s p e r f i l e s de QoS” 

32 

33 

34 for ( ( linea =29; linea

52 sleep 1 

53 echo ” c o n f i g u r e vlan i d i d e n t name d a t o s l i n e a mode qos−aware ” 

54 sleep 1 

55 echo ”dhcp−opt −82 c i r c u i t −i d customer−i d ” 

56 sleep 1 

57 echo ” c o n f i g u r e vlan shub i d i d e n t name d a t o s l i n e a mode c r o s s −connect ” 

58 sleep 1 

59 echo ” c o n f i g u r e vlan shub i d i d e n t e g r e s s −port network : 1 ” 

60 sleep 1 

61 echo ” c o n f i g u r e vlan shub i d i d e n t e g r e s s −port l t : 1 /1/4 ” 

62 sleep 1 

63 echo ” c o n f i g u r e i n t e r f a c e port xdsl −l i n e :1/1/4/ l i n e a u s e r l i n e a l i n e a admin−←↪ 

up” 

64 sleep 1 

65 echo ” c o n f i g u r e atm pvc 1/1/4/ l i n e a : 8 : 3 2 aal5 −encap−type l l c −snap ” 

66 sleep 1 

67 echo ” c o n f i g u r e i n t e r f a c e atm−pvc 1/1/4/ l i n e a : 8 : 3 2 customer−i d d a t o s l i n e a ” 

68 sleep 1 

69 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 2 ” 

70 sleep 1 

71 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 2 vlan−i d i d e n t ” 

72 sleep 1 

73 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 2 pvid i d e n t ” 

74 sleep 1 

75 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 2 qos−p r o f i l e name : datos ” 

76 sleep 1 


78 

79 echo ” Creada l a vlan i d e n t ” 

80 

81 ; ; 

82 2) 

83 

84 echo ”Creando l a vlan i d e n t ” 

85 

86 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

87 sleep 1 


89 sleep 1 

90 echo ”ANS#150” 

91 sleep 1 

92 echo ” c o n f i g u r e vlan i d i d e n t name v o z l i n e a mode qos−aware ” 

93 sleep 1 


95 sleep 1 

96 echo ” c o n f i g u r e vlan shub i d i d e n t name v o z l i n e a mode c r o s s −connect ” 

97 sleep 1 


99 sleep 1 


101 sleep 1 


103 sleep 1 

104 echo ” c o n f i g u r e i n t e r f a c e atm−pvc 1/1/4/ l i n e a : 8 : 3 3 customer−i d v o z l i n e a ” 

105 sleep 1 


107 sleep 1 


109 sleep 1 


111 sleep 1 

112 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 3 qos−p r o f i l e name : voz ” 

113 sleep 1 


115 


117 

47

48 

118 ; ; 

119 3) 

120 

121 echo ”Creando l a vlan i d e n t ” 

122 

123 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

124 sleep 1 


126 sleep 1 

127 echo ”ANS#150” 

128 sleep 1 

129 echo ” c o n f i g u r e vlan i d i d e n t name v í d e o l i n e a mode qos−aware ” 

130 sleep 1 


132 sleep 1 

133 echo ” c o n f i g u r e vlan shub i d i d e n t name v í d e o l i n e a mode c r o s s −connect ” 

134 sleep 1 


136 sleep 1 


138 sleep 1 


140 sleep 1 

141 echo ” c o n f i g u r e i n t e r f a c e atm−pvc 1/1/4/ l i n e a : 8 : 3 4 customer−i d v í d e o l i n e a ” 

142 sleep 1 


144 sleep 1 


146 sleep 1 


148 sleep 1 

149 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 3 qos−p r o f i l e name : vídeo ” 

150 sleep 1 


152 


154 

155 ; ; 

156 esac 

157 done 

158 done 

1 

2 #! / bin / bash 

3 

4 linea10=0 

5 ident=0 

6 

7 brctl addbr datos 

8 brctl addbr voz 

9 brctl addbr vídeo 

10 

Script 3: Creación de las interfaces en el servidor de vídeo 


21 echo ” Creado e l i n t e r f a z eth2 . i d e n t ” 

22 

23 case vc in 

24 1) 

25 brctl addif datos eth2 . ident 

26 echo ”Añadido a l b r i d g e de datos ” 

27 ; ; 

28 2) 

29 brctl addif voz eth2 . ident 

30 echo ”Añadido a l b r i d g e de voz ” 

31 ; ; 

32 3) 

33 brctl addif vídeo eth2 . ident 

34 echo ”Añadido a l b r i d g e de vídeo ” 

35 ; ; 

36 esac 

37 done 

38 done 

39 

40 ifconfig datos 1 9 2 . 1 6 8 . 1 . 1 

41 ifconfig voz 1 9 2 . 1 6 8 . 2 . 1 

42 ifconfig vídeo 1 9 2 . 1 6 8 . 3 . 1 

1 

2 #! / bin / bash 

3 

4 linea10=0 

5 ident=0 

6 

7 for ( ( linea =1; linea salida . txt 

29 

30 echo ” Desasociado l a vlan i d e n t ” 

31 

32 ; ; 

33 2) 

34 

35 echo ” Desasociando l a vlan i d e n t ” 

36 

37 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

38 sleep 1 


49

50 

40 sleep 1 

41 echo ”ANS#150” 

42 sleep 1 

43 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 3 no qos−p r o f i l e ” 

44 sleep 1 


46 

47 echo ” Desasociada a l a vlan i d e n t ” 

48 

49 ; ; 

50 3) 

51 

52 echo ” Desasociando a l a vlan i d e n t ” 

53 

54 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

55 sleep 1 


57 sleep 1 

58 echo ”ANS#150” 

59 sleep 1 

60 echo ” c o n f i g u r e b r i d g e port 1/1/4/ l i n e a : 8 : 3 4 no qos−p r o f i l e ” 

61 sleep 1 


63 

64 echo ” Desasociada a l a vlan i d e n t ” 

65 

66 ; ; 

67 esac 

68 done 

69 done 

1 

2 #! / bin / bash 

3 

4 linea10=0 

5 ident=0 

6 


32 echo ” c o n f i g u r e i n t e r f a c e port xdsl −l i n e :1/1/4/ l i n e a no u s e r no admin−up” 

33 sleep 1 

34 echo ” c o n f i g u r e vlan shub no i d i d e n t ” 

35 sleep 1 

36 echo ” c o n f i g u r e vlan no i d i d e n t ” 

37 sleep 1 


39 

40 echo ” Borrada l a vlan i d e n t ” 

41 

42 ; ; 

43 2) 

44 

45 echo ” Borrando l a vlan i d e n t ” 

46 

47 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

48 sleep 1 


50 sleep 1 

51 echo ”ANS#150” 

52 sleep 1 

53 echo ” c o n f i g u r e b r i d g e no port 1/1/4/ l i n e a : 8 : 3 3 ” 

54 sleep 1 

55 echo ” c o n f i g u r e i n t e r f a c e atm−pvc 1/1/4/ l i n e a : 8 : 3 3 no customer−i d ” 

56 sleep 1 

57 echo ” c o n f i g u r e atm no pvc 1/1/4/ l i n e a : 8 : 3 3 ” 

58 sleep 1 


60 sleep 1 


62 sleep 1 


64 


66 

67 ; ; 

68 3) 

69 

70 echo ” Borrando l a vlan i d e n t ” 

71 

72 ( echo ” open 1 9 2 . 1 6 8 . 0 . 1 0 ” 

73 sleep 1 


75 sleep 1 

76 echo ”ANS#150” 

77 sleep 1 

78 echo ” c o n f i g u r e b r i d g e no port 1/1/4/ l i n e a : 8 : 3 4 ” 

79 sleep 1 

80 echo ” c o n f i g u r e i n t e r f a c e atm−pvc 1/1/4/ l i n e a : 8 : 3 4 no customer−i d ” 

81 sleep 1 

82 echo ” c o n f i g u r e atm no pvc 1/1/4/ l i n e a : 8 : 3 4 ” 

83 sleep 1 


85 sleep 1 


87 sleep 1 


89 


91 

92 ; ; 

93 esac 

94 done 

95 done 

51

52 

Presupuesto 

A continuación se detalla un presupuesto para el presente Proyecto, desglosando tanto 

el coste del tiempo invertido por el personal, como los costes directos e indirectos asociados 

al mismo. 

Tareas 

Se ha dividido el Proyecto en una serie de tareas a las que se les ha estimado una duración 

en horas según su complejidad y duración. En la figura 1 podemos ver un diagrama 

de Gantt con dichas tareas a lo largo del tiempo, suponiendo que se trabajan 8 horas al 

día de lunes a viernes. 

Figura 1: Diagrama de Gantt con las tareas del proyecto 

Como se puede observar, las tareas más importantes y que han llevado más tiempo, 

han sido la configuración del DSLAM, el diseño de la red y la documentación. 

Costes laborales 

Para el presente proyecto se cuenta con un Ingeniero Senior y un Ingeniero Junior, 

el primero centrado en tareas de diseño y el segundo en tareas de implementación. Las 

retribuciones de ambos se pueden observar en la tabla 1

Personal 

Categoría Coste hombre mes 

Ingeniero Senior 4.289,54 

Ingeniero Junior 2.694,39 

Tabla 1: Retribución según la categoría 

Descripción Coste (Euros) % Uso dedicado proyecto Dedicación (meses) Período de depreciación Coste imputable 

DSLAM 14.043,96 100 3 60 702,20 

Servidor de vídeo 1.500,00 100 3 60 75,00 

Routers ADSL 150,00 100 3 60 7,50 

Ordenador portátil 699,00 50 3 60 17,48 

Total 802,17 

Tabla 2: Coste de los equipos 

1 hombre mes son 131,25 horas, que con un máximo anual de dedicación de 12 hombres 

mes hacen 1575 horas al año. 

Aplicando estos valores a las horas dedicadas a cada tarea obtenemos el coste de 

personal. Este cálculo se encuentra en la figura 2. 

Coste de los equipos 

Figura 2: Costes laborales 

A continuación se detalla el coste de los equipos utilizados en la maqueta, y para las 

tareas de recopilación de información y documentación. Para calcular la depreciación suponemos 

los tres meses que obtenemos en el diagrama de Gantt. Los costes están reflejados 

en la tabla 2. 

53

54 

Descripción Cantidad Coste unitario Coste imputable 

CD 2 0,50 1,00 

Memoria USB 1 45,00 45,00 

Material de oficina 1 30,00 30,00 

Total 76,00 

Otros costes directos 

Tabla 3: Costes del material fungible 

Precio por km km Coste imputable 

0,17 2400 408,00 

Tabla 4: Coste del transporte 

En este apartado incluiremos todos los gastos no contemplados anteriormente como 

costes fungibles (tabla 3) y coste del transporte (tabla 4). Para éste último se ha calculado 

el coste de uso del coche privado para el desplazamiento, con una distancia diaria de 40 

km, lo cual son 800 km al mes y 2400 km durante los 3 meses de duración del proyecto. 

Costes indirectos 

Aquí se incluyen todos aquéllos gastos que aunque no están vinculados directamente al 

Proyecto son necesarios para que éste de desarrolle. Ejemplos de estos costes son luz, agua, 

limpieza, etc. Puesto que son muy difíciles de determinar exactamente, supondremos una 

tasa del 20 % sobre el resto de costes. 

Resumen de costes 

El resumen de los costes se puede ver en la tabla 5. 

Presupuesto final 

Añadiendo a lo anterior los márgenes por riesgo y el beneficio que se desea obtener, 

así como el I.V.A. obtenemos que el presupuesto total de este proyecto es de CUAREN- 

TA Y CUATRO MIL OCHOCIENTOS CINCUENTA Y UNO CON DIE- 

CISÉIS euros.

Concepto Cantidad 

Personal 21.338,51 

Amortización 802,17 

Costes de funcionamiento 484,00 

Costes indirectos 4.525,94 

Total 27.149,62 

Tabla 5: Resumen de costes 

Concepto Cantidad 

Coste total 27.149,62 

Riesgo (20 %) 5.429,92 

Beneficio (20 %) 5.429,92 

Total sin I.V.A. 38.009,46 

I.V.A. (18 %) 6.841,70 

Total 44.851,16 

Tabla 6: Presupuesto del Proyecto 

Leganés, a 27 de enero de 2011 

El ingeniero proyectista 

José María Zapardiel Gonzalo 

55

Bibliografía 

[1] Media access control (mac) bridges. IEEE 802.1d, 2004. 

[2] Virtual bridged local area networks. IEEE 802.1q, 2005. 

[3] Asynchronous transfer mode switching, Dec. 2009. 

[4] Cisco visual networking index: Forecast and methodology, 2009-2014, June 2010. 

[5] Alcatel. Alcatel 7330 ISAM FTTN ISAM Fiber to the Node — Release 2.1 CLI 

Command Guide, 3HH-01205-AAAA-TCZZA Edition 03 Released, 2004. 

[6] Alcatel. Alcatel 7330 ISAM FTTN Fiber to the Node — Feature Group 2.1 System 

Description, 3HH-01198-AAAA-TQZZA Edition 02 Released, 2005. 

[7] W. Atwood, S. Islam, and M. Siami. Authentication and Confidentiality in Protocol 

Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages. RFC 5796 

(Proposed Standard), Mar. 2010. 

[8] N. Bhaskar, A. Gall, J. Lingard, and S. Venaas. Bootstrap Router (BSR) Mechanism 

for Protocol Independent Multicast (PIM). RFC 5059 (Proposed Standard), Jan. 

2008. 

[9] B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan. Internet Group Management 

Protocol, Version 3. RFC 3376 (Proposed Standard), Oct. 2002. Updated 

by RFC 4604. 

[10] S. Deering. Host extensions for IP multicasting. RFC 1112 (Standard), Aug. 1989. 

Updated by RFC 2236. 

[11] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas. Protocol Independent Multicast 

- Sparse Mode (PIM-SM): Protocol Specification (Revised). RFC 4601 (Proposed 

Standard), Aug. 2006. Updated by RFCs 5059, 5796. 

[12] W. Fenner. Internet Group Management Protocol, Version 2. RFC 2236 (Proposed 

Standard), Nov. 1997. Obsoleted by RFC 3376. 

[13] D. Grossman and J. Heinanen. Multiprotocol Encapsulation over ATM Adaptation 

Layer 5. RFC 2684 (Proposed Standard), Sept. 1999. 

57

58 BIBLIOGRAF ÍA 

[14] J. Heinanen. Multiprotocol Encapsulation over ATM Adaptation Layer 5. RFC 1483 

(Proposed Standard), July 1993. Obsoleted by RFC 2684. 

[15] H. Holbrook, B. Cain, and B. Haberman. Using Internet Group Management Protocol 

Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) 

for Source-Specific Multicast. RFC 4604 (Proposed Standard), Aug. 2006. 

[16] ITU-T. Advanced vídeo coding for generic audiovisual services. Recommendation 

H.264, International Telecommunication Union, Ginebra, Mar. 2010. 

[17] M. H. Pinson, S. Wolf, and G. Cermak. HDTV subjective quality of h.264 vs. mpeg-2, 

with and without packet loss. IEEE Transactions on Broadcasting, 56, Mar. 2010. 

[18] Wikipedia. Digital subscriber line — wikipedia, the free encyclopedia, 2010.

PFC - Jose Maria Zapardiel Gonzalo.pdf - E-Archivo UC3M ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?