Anda di halaman 1dari 74

DEPARTAMENTO DE TELEMATICA

UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITECNICA SUPERIOR INGENIER IA SUPERIOR DE TELECOMUNICACIONES

PROYECTO FINAL DE CARRERA

E IMPLEMENTACION DISENO DE UN ENTORNO DE PRUEBAS PARA IPTV

MAR AUTOR: JOSE IA ZAPARDIEL GONZALO TUTOR: JAIME GARC IA REINOSO

27 de enero de 2011

T tulo:

E IMPLEMENTACION DE UN ENDISENO TORNO DE PRUEBAS PARA IPTV MARIA ZAPARDIEL GONZALO JOSE REINOSO JAIME GARCIA

Autor: Tutor:

La defensa del presente Proyecto Fin de Carrera se realiz o el d a 27 de Enero de 2011; siendo calicada por el siguiente tribunal:

Presidente:

Francisco Valera Pintor

Secretario

Julio Villena Rom an

Vocal

Angel M. Bravo Santos

Habiendo obtenido la siguiente calicaci on:

n: Calificacio

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 dicultades que nos hemos ido encontrando por el camino. Tambi en quiero agradecer al resto de miembros de la Universidad que con su trabajo han hecho posible la realizaci on 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 nal de esta que termina con este Proyecto, y lo que a un 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 e Mar a y Maribel, por hacerme como soy y por haberme dado la oportunidad con su sacricio de tener el futuro que he elegido. A los titos, por todo lo que me han ense nado y me han dado. Siempre han pensado en m antes que en ellos. A los abuelos, porque tambi en de ellos he aprendido mucho. Espero que la abuela est e 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 as que desde que no levant abamos dos palmos del suelo han estado ah para lo que necesitase. Y a todos mis compa neros de universidad por todas las horas de sufrimiento y de placer que hemos pasado durante estos a nos. Y por u 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.

Al carro de la cultura espa nola le falta la rueda de la ciencia. Santiago Ram on y Cajal El que controla el pasado, controla tambi en el futuro. El que controla el presente, controla el pasado. 1984 (George Orwell)

vii

Resumen
Actualmente en Internet existen servicios de transmisi on 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 ametros similares a la televisi on convencional. Por ello han surgido algunas iniciativas para la transmisi on de televisi on sobre ADSL, donde esta se nal no compite con el resto de las aplicaciones de Internet. En este proyecto se pretende desplegar un escenario de IPTV que d e 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

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 dont oer 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 Internets 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.

Indice

1. INTRODUCCION 1.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Motivaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. ESTADO DEL ARTE 2.1. Tecnolog as xDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. El protocolo ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Routed Ethernet (ETHoA, RFC1483 y MER) . . . . . . . . . . . . . . . . 2.3.1. Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 2 5 5 8 9 9

2.3.2. Servicio de conexi on . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Conguraciones 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 DE RED PARA IPTV 3. DISENO 15

3.1. Criterios de dise no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 xi

3.3. Calidad de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Dise no propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Y PRUEBAS DE LA RED IPTV 4. IMPLEMENTACION 21

4.1. Maqueta de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Conguraci on de los equipos . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Conguraci on del DSLAM . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.2. Conguraci on del servidor de v deo . . . . . . . . . . . . . . . . . . 35 4.2.3. Conguraci on del router ADSL . . . . . . . . . . . . . . . . . . . . 36 4.3. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5. CONCLUSIONES 41

5.1. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 ANEXO 45

Indice de guras
2.1. S mil de un circuito DSL para un usuario . . . . . . . . . . . . . . . . . . . 2.2. Espectro de frecuencias general de una l nea DSL . . . . . . . . . . . . . . 6 7

2.3. Encapsulado de IP sobre ATM seg un 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. Conguraci on del tipo de conexi on del router . . . . . . . . . . . . . . . . . 38 4.6. Conguraci on IP del router . . . . . . . . . . . . . . . . . . . . . . . . . . 39

xiii

Indice de tablas
2.1. Datos de conguraci on ADSL de los Diferentes ISP. . . . . . . . . . . . . . 13 3.1. Comparaci on de red con servidores de v deo propios y externos . . . . . . . 16

xv

Cap tulo 1 INTRODUCCION


1.1. Introducci on

Las siglas IPTV (Internet Protocol Television ) hacen referencia a un sistema de distribuci on de televisi on digital que utiliza el protocolo IP (Internet Protocol ) como base para su transporte. Este servicio se ha hecho muy popular en los u ltimos a nos al ofrecerse conjuntamente con el servicio de conexi on a Internet. En Espa na tenemos varios ejemplos: Imagenio (Telef onica), Jazztelia (Jazztel), Orange TV (Orange), etc. La principal diferencia con la televisi on tradicional es el cambio de paradigma en la forma de interactuar con el cliente nal, 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 un 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 aco residencial total y se espera que para nales de 2010 haya aumentado hasta cerca del 40 %, llegando al 57 % en el a no 2014. Y estos datos se reeren tan solo a v deos de Internet (como los de las p aginas YouTube, Hulu, etc) pues si tenemos en cuenta todos los formatos de v deo (televisi on, v deo bajo demanda, v deo de Internet y v deos intercambiados en redes P2P) tenemos que para el a no 2014 la previsi on sea del 91 % del tr aco global. Adem as, los nuevos formatos de v deo en HD (alta denici on) y en 3D (tres dimensiones) son cada vez m as populares, por lo que aumentar an unas 23 veces hasta el 2014, llegando a suponer el 46 % de los v deos vistos en Internet. Centr andonos en lo que respecta al v deo en tiempo real, este tiene una importancia cada vez mayor. Por ejemplo, se espera que la televisi on por Internet llegue a suponer el 8 % del tr aco en 2014. Las retransmisiones en directo por Internet han crecido mucho en los u ltimos a nos, como se puede observar en el hecho de que la televisi on P2P (P2P TV) supone la transferencia de m as de 280 petabytes al mes. Adem as se prev e que el tr aco 1

CAP ITULO 1. INTRODUCCION

de v deo bajo demanda se cuadruplique hasta el a no 2014. Si nos referimos a datos econ omicos, seg un este mismo informe de Cisco[4], las previsiones son que la la tasa de crecimiento anual compuesto (TCAC o tambi en CAGR en ingl es) de la IPTV crezca a un ritmo del 33 % anual hasta el 2014.

1.2.

Motivaci on

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 on de los proveedores de acceso, de los proveedores de servicios. Sin embargo, la oferta conjunta del acceso a Internet y del servicio de IPTV dicultan esta separaci on, pues para el proveedor de acceso a Internet existen una serie de ventajas t ecnicas si el mismo provee los contenidos. Por ejemplo, al ser una red cerrada es m as sencilla de monitorizar, lo que permite una mayor seguridad y hace m as f acil 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 decodicador el encargado de ltrar que canales puede ver cada uno. Adem as los canales disponibles son una lista cerrada que el proveedor se encarga de actualizar, sin que el usuario pueda elegir ning un canal que no se encuentre dentro de la oferta. La r apida evoluci on 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 andonos en la tecnolog a actual, este cambio es posible y seguramente beneciar a 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 an en el futuro, en este Proyecto se busca denir y validar un modelo de sistema de IPTV exible que permita disponer de proveedores de servicios, independientes del proveedor de acceso, que diversiquen la oferta de contenidos. Se evaluar an las ventajas e inconvenientes de este modelo, tanto desde el punto de vista t ecnico como comercial, a partir de los siguientes criterios:

1.3. OBJETIVOS

Estandarizaci on: se busca que la propuesta siga todos los est andares actuales con el n de maximizar las posibilidades de despliegue en entornos reales de producci on Seguridad: se intenta que la soluci on sea lo m as 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 a la compatibilidad actual y futura con diferentes tecnolog as. Escalabilidad: se intentar a que el crecimiento del sistema sea lo m as sencillo posible. Gesti on de red: el sistema de gesti on de la red debe ser sencillo, completo y a poder, ser unicado en un u nico equipo. Provisi on de servicios: los nuevos servicios deben poder ser aprovisionados de la forma m as r apida y limpia posible. Perdurabilidad: El tiempo de vida del sistema debe ser lo m as amplio posible. Costes de mantenimiento (OPEX): se buscar a que los costes de mantenimiento sean lo m as reducidos posible. Costes de inversi on (CAPEX): los costes de inversi on no deben ser tan elevados como para que el sistema no sea viable econ omicamente. Para la validaci on de este modelo ser a necesario crear una maqueta de pruebas compuesta por diversos dispositivos, entre los que destaca el DSLAM (Digital Subscriber Line Access Multiplexer ), que ser a el encargado de conectar a los servidores de contenido con los usuarios nales. La conguraci on y puesta en marcha del DSLAM supone uno de los objetivos b asicos de este Proyecto.

CAP ITULO 1. INTRODUCCION

Cap tulo 2 ESTADO DEL ARTE


2.1. Tecnolog as xDSL

El t ermino xDSL o DSL (Digital Subscriber Line ) hace referencia a una familia de tecnolog as que permiten la transmisi on digital de datos sobre las l neas telef onicas 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 onicas convencionales, tales como el l mite del ancho de banda de aproximadamente 4 KHz, que no permite transmitir a una tasa de transmisi on suciente para las nuevas aplicaciones que son cada vez m as 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 on de frecuencias se consigue mediante el uso de ltros, permitiendo el uso simult aneo de voz y datos. Estos ltros pueden estar colocados a la entrada de la vivienda (denominados Splitters) separando en dos cables voz y datos; o bien se puede colocar un ltro paso bajo en cada tel efono (microltros). Al contrario de lo que su nombre podr a hacer pensar, la se nal base transmitida en un circuito DSL es anal ogica y no digital. Se utiliza una modulaci on con una portadora sinusoidal de alta frecuencia. Un circuito DSL tiene en ambos extremos una pareja de modems. Para la transmisi on se modulan los patrones de bits, enviando estas se nales anal ogicas 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 asico de telefon a. Sin embargo, con los avances en el procesado de se nales y la aparici on de nuevas t ecnicas de modulaci on se empez o a contemplar la posibilidad de utilizar frecuencias 5

CAP ITULO 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 conguraci on 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 on de los canales se realiza continuamente de una forma similar a como lo realizaban los modems m as antiguos sobre la banda de voz, a nadiendo y quitando canales seg un sean aptos para su uso. Cuantos m as canales se creen, mayor ancho de banda estar a 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 as atenuaci on se sufre y por lo tanto menor alcance se tiene.[18] En cada circuito ADSL se realiza esta multiplexaci on en frecuencia. Podemos asimilarla a un conjunto de modems anal ogicos transmitiendo en paralelo a distintas frecuencias por el mismo cable (v ease la gura 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 ogicos, quedando al otro extremo del par de cobre un equipo llamado DSLAM. Este equipo conecta con varias l neas de usuario, utilizando la multiplexaci on en frecuencia en cada una de ellas. En el otro extremo, el DSLAM conecta con una salida WAN y con una central telef onica. Trataremos este dispositivo m as en detalle en el apartado 2.4.1. El conjunto de canales creados se divide en dos grupos seg un se vayan a utilizar en sentido ascendente (subida de datos) o descendente (descarga de datos), como se puede ver en la gura 2.2. Esta divisi on puede ser sim etrica (SDSL, por ejemplo) o asim etrica (ADSL, entre otras). El utilizar una relaci on de varios canales de bajada por cada uno

2.1. TECNOLOG IAS XDSL

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 on de tecnolog as como el anexo M, que aumentan la subida de las l neas ADSL2 y ADSL2+. La historia del exito de las tecnolog as DSL[18], y en especial del ADSL, reeja los avances realizados en la electr onica y la teor a del procesado de se nales, 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 bra optica. Varios factores contribuyeron a la expansi on de las tecnolog as DSL: Hasta el nal de los a nos 90 el coste de los procesadores de se nales 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 (DSLAMs en el lado del operador de red y modems DSL en el lado del cliente) se vio signicativamente disminuido. El que la conexi on DSL se pueda desplegar sobre un cable ya existente resulta mucho m as barato que tender un cable de bra o ptica nuevo. La presi on realizada por las compa n as de cable, que ofrec an un ancho de banda muy superior al de los modems anal ogicos, hizo que las compa n as telef onicas apoyasen el despliegue del ADSL.

CAP ITULO 2. ESTADO DEL ARTE

2.2.

El protocolo ATM

ATM (Asynchronous Transfer Mode o Modo de Transferencia As ncrona) es una t ecnica de transferencia de datos en la que la informaci on se organiza en PDUs (Protocol Data Units) de 53 bytes denominadas celdas. Es as ncrono porque las celdas que contienen la informaci on de un usuario concreto no son transmitidas de forma peri odica, es decir, a diferencia de las redes s ncronas en las que no se transmite nada si el usuario no tiene informaci on que transmitir, una red ATM usar a 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 on de circuitos como de paquetes; cada celda tiene una cabecera, al igual que los paquetes, pero a diferencia de estos, su longitud es ja, 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 aco constante de celdas. Es decir, se basa en un modelo orientado a conexi on en la que la informaci on 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 ja 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 on: AAL1: utilizado para la emulaci on de circuitos, por lo que es s ncrono, orientado a conexi on y soporta CBR (Constant Bit Rate). Tiene alta prioridad y est a garantizado. AAL2: utilizado para voz a tasa variable, VBR (Variable Bit Rate), tambi en es s ncrono y orientado a conexi on. El servicio es de baja prioridad, pero garantizado. AAL3/4: presta un servicio de datos orientado a conexi on utilizado b asicamente para la transmisi on de datos en l neas ATM con altos niveles de interferencias. En un principio se denieron dos protocolos para esta clase de servicio, pero m as tarde se unieron en uno solo. Tiene alta prioridad, aunque no est a 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 simplicada, 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 on de circuitos; AAL2 para servicios VBR y AAL5 para la transmisi on de datos. Las caracter sticas b asicas de ATM son:

2.3. ROUTED ETHERNET (ETHOA, RFC1483 Y MER)

La informaci on se divide en celdas que son enrutadas individualmente utilizando canales virtuales (VC, Virtual Channel) y caminos virtuales (VP, Virtual Path). Se utiliza multiplexaci on temporal as ncrona. Est a orientado a conexi on. La se nalizaci on va fuera de banda. Se garantiza la entrega ordenada de las celdas transmitidas por el mismo canal virtual. La protecci on contra errores y el control de ujo 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 on de la comunicaci on 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 a jo durante toda la comunicaci on, del tal forma que si se cae uno de los nodos por los que transcurre el camino, la comunicaci on se pierde. El circuito virtual en el que se transporta una celda viene reejado en la cabecera de la misma mediante los campos VPI (Virtual Path Identier) y VCI (Virtual Channel Identier). Estos valores no tienen por qu e ser constantes de extremo a extremo, sino que pueden ser cambiados en cada nodo enrutador seg un la tabla que este posea. Una de las ventajas de utilizar estos circuitos virtuales es la posibilidad de multiplexar distintos servicios en cada uno de ellos. Para m as informaci on se puede consultar [3].

2.3.

Routed Ethernet (ETHoA, RFC1483 y MER)

El modo de Routed Ethernet (Ethernet enrutado), tambi en conocido como MAC Encapsulated Routing (o ETHoA) funciona sobre el enrutamiento IP est andar. 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:

10

CAP ITULO 2. ESTADO DEL ARTE Es f acilmente reemplazable por un Bridge transparente. Permite una conexi on r apida, sin necesidad de esperar a una negociaci on de la conexi on o a una autenticaci on. Es autocongurable si est a activado el protocolo DHCP. Varios usuarios pueden compartir una u nica direcci on IP si se hace NAPT (Network Address Port Translation ).

2.3.2.

Servicio de conexi on

El servicio de Routed Ethernet depende del servicio de conexi on basado en AAL5 / RFC1483[14] / Bridged1 para proporcionar conectividad (v ease la gura 2.3).

Figura 2.3: Encapsulado de IP sobre ATM seg un la RFC1483 modo routing Esto equivale a utilizar Ethernet sobre ATM (ETHoA) como tipo de servicio de conexi on. En este tipo de servicio de conexi on se encapsulan las tramas Ethernet (tambi en conocidas como IEEE802.3, tramas MAC o Bridging frames ) en AAL5/ATM.
1

La RFC1483 ha sido actualizada a la RFC2684[13]. A un as el uso de la primera est a 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.

Conguraciones TCP/IP

Se pueden utilizar dos escenarios distintos en la implementaci on de Routed Ethernet : El proveedor de servicios requiere el uso de DHCP. El cliente recibir a su conguraci on IP de un servidor DHCP remoto a trav es de la l nea DSL. El proveedor de servicios reserva una IP p ublica al cliente, quien debe congurarla de forma manual en su router. Activando NAPT en el router del cliente se hace posible la comunicaci on de varios ordenadores del cliente con una sola direcci on p ublica.

2.4.
2.4.1.

Dispositivos de acceso
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 ecnicas de multiplexi on. 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 este (ATU-R, ADSL Transceiver Unit - Remote) y otro en las instalaciones del proveedor de acceso (ATU-C, ADSL Termination Unit - Central Oce) a donde llega el bucle de abonado y donde se encuentra la central local. Esta conguraci on 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 as concentra el tr aco de todos los enlaces ADSL hacia una red WAN (v ease gura 2.4). Esta integraci on 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 dicultad de desplegar un sinf n de modems ADSL. En funci on de la tecnolog a, los DSLAMs conectan las l neas ADSL con alguna combinaci on de los protocolos ATM, frame relay o IP. Desde el punto de vista de la torre

12

CAP ITULO 2. ESTADO DEL ARTE

Figura 2.4: Arquitectura de un DSLAM de protocolos OSI, un DSLAM no es m as 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 u ltimos los que extra an el tr aco IP y lo introduc an en la red. Puesto que la mayor a del tr aco de los usuarios es IP, se evolucionaron los DSLAM para que fueran ellos mismos los que extrajesen el tr aco 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 as de la inclusi on de mayores funcionalidades.

2.4.2.

Modems DSL

Un m odem DSL es un dispositivo que modula y desmodula las se nales 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 en se le llama ATU-R. A este m odem se le suele conectar un ordenador o un router, aunque hoy en d a es com un integrar el modem DSL y el router en un u nico dispositivo. Ser a este dispositivo el que realice las tareas, tanto de composici on de las tramas ATM a enviar, como del enrutamiento IP o del bridging. Adem as, estos dispositivos permiten el establecimiento

2.5. TOPOLOG IAS 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 aco a enviar por cada circuito virtual. Tambi en 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 na podemos distinguir entre dos tipos de conguraciones ADSL. Por un lado tenemos conexiones punto a punto si el cliente obtiene una IP din amica. En el caso de que se asigne una IP ja, los proveedores utilizan Routed Ethernet como se ha explicado en el apartado 2.3. Los datos de conexi on de los distintos ISPs de Espa na se puede observar en la tabla 2.1 .
2

Proveedor Jazztel Jazztel ADSL2+ Tele2 Telef onica Telef onica Orange Orange 20 Megas Orange Ya.com Ya.com

Tipo de IP Protocolo Din amica PPPoA Din amica PPPoE Din amica PPPoA Din amica PPPoE Fija RFC 1483 Din amica PPPoA Din amica PPPoE Fija RFC 1483 Din amica PPPoE Fija RFC 1483

VPI/VCI Encapsulation Mode 8/35 VC-MUX 8/35 LLC-BRIDGING 8/35 VC-MUX 8/32 LLC/SNAP 8/32 LLC/SNAP 8/35 VC-MUX 8/35 LLC-BRIDGING 8/32 LLC/SNAP 8/32 LLC/SNAP 8/32 LLC/SNAP

Tabla 2.1: Datos de conguraci on ADSL de los Diferentes ISP. Al dise nar una red para IPTV se debe plantear la localizaci on 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 gura 2.5. Con esta conguraci on 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 on en la oferta de contenidos, pues el ISP debe dar cabida a cada nuevo canal dentro de sus servidores.

Fuente: www.adslzone.net

14

CAP ITULO 2. ESTADO DEL ARTE

Figura 2.5: Red con servidor de contenidos propio

Cap tulo 3 DE RED PARA IPTV DISENO


Uno de los objetivos de este proyecto es evaluar la conguraci on utilizada actualmente (que denominaremos de ahora en adelante Red con servidor propio o walled-garden en ingl es) 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 on por IP, y en funci on de unos criterios que permitan comparar las virtudes y desventajas de ambas.

3.1.

Criterios de dise no

Los criterios seleccionados son los siguientes: Estandarizaci on La utilizaci on de est andares en la red reduce la posibilidad de errores por incompatibilidades, facilita la conguraci on 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 on a la red de terceras personas. Robustez El sistema debe ser lo m as 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 acil, sin que existan problemas tales como cuellos de botella. Gesti on de red La gesti on de los distintos elementos de la red debe ser lo m as simple posible, y preferentemente estar unicada en un equipo. 15

16

DE RED PARA IPTV CAP ITULO 3. DISENO Red con servidor propio Red con servidor externo Baja Alta Alta Baja Baja Media Baja Alta Baja Alta Alta Baja Alta Baja Media Media Alta Baja Alta Baja

Estandarizaci on Seguridad Robustez Compatibilidad Escalabilidad Gesti on de red Provisi on de servicios Perdurabilidad OPEX CAPEX

Tabla 3.1: Comparaci on de red con servidores de v deo propios y externos Provisi on de servicios Los nuevos servicios deben poder ser aprovisionados de la forma m as r apida y limpia posible. Perdurabilidad El tiempo de vida del sistema debe ser sucientemente amplio y a ser posible debe aceptar los nuevos cambios tecnol ogicos. Costes de mantenimiento (OPEX) Los costes de mantenimiento deben ser lo m as reducidos posible. Costes de inversi on (CAPEX) El sistema debe tener unos costes de inversi on contenidos para que sea viable econ omicamente. La tabla 3.1 muestra la comparaci on de las dos alternativas planteadas en funci on de los anteriores criterios. Podemos detallar m as a fondo cada uno de estos criterios para ambas alternativas: Estandarizaci on En la red con un servidor propio la estandarizaci on no es un requisito indispensable, pues todos los componentes son propios y la u nica interacci on con el mundo exterior se limita a la conexi on de datos hacia Internet. Sin embargo, en el caso de contar con servidores externos, es extremadamente recomendable que todos los equipos est en estandarizados, pues as se facilita la conexi on con los equipos de los proveedores de servicios, adem as de reducir los posibles problemas debidos a incompatibilidades. Seguridad La red con un servidor propio es, por denici on m as segura que otras alternativas, puesto que no es imprescindible permitir el paso de ning un operador externo a la red. Sin embargo, la propia conexi on hacia Internet es un problema de seguridad a tener en cuenta. Por este motivo, aunque sea m as sencillo gestionar la seguridad,

3.1. CRITERIOS DE DISENO

17

no se puede armar que sea un sistema completamente seguro. En el caso de tener que permitir servidores externos, habr a 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 a m as robusto que otro con servidores propios, pues la ca da de uno de estos servidores, s olo 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, este debe ser redundante, as como las posibles conexiones troncales hacia el. Compatibilidad La compatibilidad es m as f acil 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 losof as. Escalabilidad Es m as sencillo ampliar un sistema con servidores externos que uno con servidores propios, pues en el primer caso lo que habr a que gestionar es la conexi on de un nuevo servidor a la red, pero no habr a que realizar toda la conguraci on, puesta en marcha y mantenimiento del mismo. Gesti on de red Ser a m as f acil gestionar una red con servidor propio que una con servidores externos, porque aunque se tengan que gestionar m as elementos, al tener acceso directo a los mismos es m as f acil detectar los posibles fallos. En la red con servidores externos, aunque el n umero 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 u nicamente con esa informaci on la gesti on se hace m as complicada. Adem as se hace necesaria la coordinaci on entre el proveedor de acceso y el de servicios cuando se encuentra alguna incidencia en la red. Provisi on de servicios En el caso de la red con servidores externos, la provisi on de un nuevo servicio implica crear una nueva conexi on hacia el servidor de contenidos. En principio, se puede crear un procedimiento para que sea lo m as sencillo posible. Si el servidor es interno, adem as de las conexiones, hay que poner en marcha y congurar el servidor de v deo en si, lo cual es una tarea m as 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 as forzada a adaptarse a los cambios tecnol ogicos, 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.

18

DE RED PARA IPTV CAP ITULO 3. DISENO

Costes de inversi on (CAPEX) El CAPEX es tambi en menor en la red con servidores externos, pues el numero de equipos a adquirir es menor. Adem as, 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 on entre ambos tipos de proveedores nos abre un abanico de contenidos mucho mayor sin un sacricio excesivo en ninguna de las a 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 on hacia los usuarios; y en conexi on y volumen de tr aco 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 on, que podr a ser en un u nico pago como alta en el servicio, una cuota mensual, o incluso gratuito o promocionado, seg un c omo responda el mercado. Hacia los proveedores de contenidos, el proveedor de acceso cobrar a un jo por la conexi on a la plataforma de televisi on y adem as una cantidad variable seg un el tr aco cursado hacia sus servidores. De esta forma se asegura una viabilidad econ omica para mantener los est andares 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 aco. Desde el punto de vista del proveedor de contenidos, su modelo de negocio estar a basado en suscripci on, cobrando a los usuarios una cuota por el acceso a sus contenidos. Otra opci on ser a que el proveedor de acceso obtuviera un porcentaje de esa suscripci on del usuario en lugar de cobrar por el volumen de tr aco.

3.3.

Calidad de servicio

La calidad de servicio extremo a extremo la podemos asegurar bas andonos en la separaci on de tr aco en VLANs y dando diferentes prioridades sirvi endonos de los mecanismos que nos ofrecen los est andares 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 jar la prioridad seg un el tipo de tr aco (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 no supone una red ethernet en el core (metroethernet ). Este tipo

PROPUESTO 3.4. DISENO

19

de red nos permite separar los ujos de tr aco y poder supervisarlos f acilmente, teniendo acceso al origen y destino de los datos para poder realizar una taricaci on correcta. Adem as, con esta conguraci on de red podemos utilizar multicast[10, 12, 9, 15] para la distribuci on de los canales. Para estimar el ancho de banda necesario para un canal de v deo se ha supuesto que la transmisi on es en alta denici on (HDTV), y se ha utilizado el c odec H.264[16] para el v deo. Estos dos supuestos tienen su base en que hoy en d a las retransmisiones en alta denici on se han convertido en un est andar, y el c odec m as utilizado es el H.264. Utilizando esta conguraci on, y gui andonos por lo publicado en [17], podr amos tener una buena calidad con una tasa de datos de 8 Mbps. Por supuesto, existen otros c odecs 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 on de contenidos (CDN de las siglas de su nombre en ingl es, content delivery network ), nos hace falta denir la forma de acceso y subscripci on 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 on desde el propio PC, o estar instalado en el descodicador que se conecte a la televisi on. Como ya se ha mencionado anteriormente, con esta arquitectura se podr a utilizar multicast para la distribuci on de canales. Para ello, el protocolo que m as se ajusta es PIM-SM (Protocol Independent Multicast - Sparse-Mode )[11, 8, 7].

3.4.

Dise no propuesto

Como alternativa a la conguraci on tradicional, en la que los servidores de v deo se encuentran en la red del proveedor de servicios, podemos plantearnos el dise no de la red de tal forma que estos servidores sean servidores externos gestionados por proveedores de contenidos ajenos al ISP. Un esquema de esta conguraci on de red ser a el que se puede observar en la gura 3.1. Cada cliente tendr a en su domicilio un m odem-router xDSL y un descodicador de v deo, que adaptar a la se nal de v deo proveniente del proveedor de servicios a un televisor. El m odem-router conectar a al DSLAM y utilizando los mecanismos de ATM, separar a el tr aco entre ambos seg un sea un tr aco de datos, voz o v deo. El DSLAM ser a el encargado de adaptar estos tr acos a la red metroethernet, encapsul andolos en distintas VLANs y entreg andoselos a un router de frontera de la red metroethernet. Todo este proceso se detalla en el cap tulo 4. Este router de frontera ser a el encargado adem as, de ltrar el tr aco multicast seg un las suscripciones de cada cliente conectado con el. La red metroethernet transportar a los ujos de datos hasta los servidores de v deo, los

20

DE RED PARA IPTV CAP ITULO 3. DISENO

Figura 3.1: Red con proveedores de contenidos externos cuales pueden encontrarse en cualquier red de otro proveedor de servicios. Una vez tenemos denido este modelo, debemos realizar un estudio de viabilidad t ecnica 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 abilidad 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 ogicamente.

Cap tulo 4 Y PRUEBAS IMPLEMENTACION 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 gura 4.1. Al DSLAM se le conectar an dos routers ADSL que simular an ser dos clientes residenciales. La salida WAN del DSLAM se conectar a al servidor de v deo, el cual, gracias al sistema GNU/Linux incorporado, har a las veces de router de salida hacia Internet y del propio servidor de v deo. Esta doble funci on del servidor de v deo es compatible con la simulaci on de una red con servidores de contenido externos pues, como se explica m as adelante, la conexi on del v deo se realiza a trav es de una VLAN independiente. De esta forma, se podr an conectar otros servidores de v deo desde Internet, haciendo llegar su tr aco al servidor de v deo y redirigi endolo internamente a la VLAN de v deo. Por lo tanto, tenemos en la maqueta tres ujos de datos independientes: voz, datos y v deo, como se puede observar en la gura 4.2. N otese que el ujo de voz es independiente del servicio de telefon a RTB que viaja en la parte baja de las frecuencias del ADSL. Este ujo se ha a nadido en la maqueta para simular telefon a IP en el caso de que se quisiera extender la losof 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 identicadores ser an 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 congura en los routers MER (v ease 2.3, con una IP u nica para cada VC, con encapsulado LLC/SNAP-BRIDGING. Por el interfaz WAN el DSLAM tiene conguradas tres VLANs por abonado, una para cada uno de los ujos de datos, v deo y voz. Estas VLANs est an tambi en conguradas 21

22

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

Figura 4.1: Maqueta de pruebas en el servidor de v deo, pues recordemos que act ua como router. El DSLAM act ua 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 conguran las IPs para conectar con los routers de los clientes. La losof a que seguimos para poner nombres a las VLANs se basa en el n umero 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 a automatizar algunas tareas repetitivas de conguraci on en scripts. Se puede observar un ejemplo para la l nea 30 en la gura 4.2. De esta forma, el diagrama de red completo se puede observar en la gura 4.3. Obs ervese en este diagrama que existe una VLAN m as para la gesti on del DSLAM, pues al estar funcionando como un switch necesita una IP para gesti on. Por motivos de seguridad, solo se puede acceder a dicha gesti on desde el interfaz WAN y a trav es de una VLAN espec ca.

4.2.
4.2.1.

Conguraci on de los equipos


Conguraci on del DSLAM

El DSLAM utilizado en la maqueta es el Alcatel-Lucent 7330 ISAM FTTN ANSI. Es un IP DSLAM dise nado para hacer frente a la creciente necesidad de soluciones de

DE LOS EQUIPOS 4.2. CONFIGURACION

23

Figura 4.2: Flujos de datos de la maqueta de pruebas acceso basadas en bra. 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 odulos de expansi on 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 on Gigabit Ethernet.

24

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

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 benecios que se obtienen de un DSLAM con estas caracter sticas son: Permite una alta penetraci on del acceso de bra, 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 on del servicio, por lo que se reducen los costes de transporte. Administraci on remota y en tiempo real. Todas estas caracter sticas, as como informaci on adicional del DSLAM, se encuentran en el manual de descripci on 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 conguraci on del DSLAM es fundamental para este proyecto, a continuaci on se detallan los comandos necesarios para realizarla.

DE LOS EQUIPOS 4.2. CONFIGURACION Conguraci on inicial

25

De todos los equipos de la maqueta, el DSLAM es sin duda el m as complicado de congurar. Lo primero que hay que hacer en el DSLAM es conectarse a trav es del puerto serie y congurar la gesti on por IP, para poder conectarnos posteriormente mediante Telnet. Para la conguraci on se utilizan los comandos CLI (Command Line Interface ) que se pueden encontrar en el manual de referencia del DSLAM[5]. La comunicaci on inicial se realiza a trav es de una sesi on de hyperterminal con una conguraci on 9600-N-8-1-N. Tras pulsar ENTER el sistema nos preguntar a: Would you like a CLI(C) or a TL1 login(T) or TL1 normal session(N)?[N]: a lo que responderemos C. A continuaci on debemos introducir el usuario y contrase na del equipo. La primera vez que se accede al equipo esta informaci on es: login:isadmin password:i$@mad- (no aparece al escribirlo) Despu es del primer acceso se nos pedir a que cambiemos la contrase na, por lo que introduciremos como nueva contrase na ANS#150. Lo que veremos por pantalla ser a: 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 u ltima l nea es el prompt, que nos indica que ya tenemos abierta una sesi on. El siguiente paso es habilitar y congurar 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.

26

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

A continuaci on se dene la VLAN de gesti on, asign andole una identidad e indicando cual de los puertos es el que va a utilizar como gesti on: configure system configure system configure system configure system context shub mgnt-vlan-id 1605 single-public-ip security snmp community public host-address 0.0.0.0/0 security snmp community NETMAN host-address 0.0.0.0/0

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 on IP de gesti on 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 dene 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 congurados estos datos los grabamos para que no se pierdan en caso de un reinicio del sistema: admin software-mngt shub databse save

Conguraci on 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 congurar 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 conguraci on. Lo primero que podemos hacer, es establecer la fecha y hora en el DSLAM para tener m as tarde una referencia en los logs del equipo. Para ello ejecutamos el comando:

DE LOS EQUIPOS 4.2. CONFIGURACION admin sntp system-time yyyy-mm-dd:hour:minutes:secs

27

Para saber las tarjetas que est an instaladas f sicamente en el DSLAM y que debemos declarar, utilizamos los siguientes comandos:
Visualizaci on 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 on 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 1/3 no no-error not-installed 2/1 no no-error not-installed 2/2 no no-error not-installed 2/3 no no-error not-installed 3/1 no no-error not-installed 3/2 no no-error not-installed 3/3 no no-error not-installed --------------------------------------------------------------------------shelf count : 9 ===========================================================================
Visualizaci on de las tarjetas:

28

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

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 1/1/5 empty no no-error not-installed 1/1/6 empty no no-error not-installed 1/1/7 empty no no-error not-installed --------------------------------------------------------------------------slot count : 7 ===========================================================================

Visualizaci on 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 1/1/6 empty no no-error dependency 1/1/7 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 en 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

DE LOS EQUIPOS 4.2. CONFIGURACION isadmin># isadmin># isadmin># isadmin># configure configure configure configure equipment equipment equipment equipment slot 1/1/2 planned-type ecnt-a unlock slot 1/1/4 planned-type eblt-c unlock applique 1/1/2 planned-type pwio-b applique 1/1/4 planned-type rpsp-a

29

Cada uno de estos comandos declara y desbloquea una pieza de equipamiento. Se pueden lanzar de forma autom atica 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 en est a incluido en el script 1.

Conguraci on de los abonados En este punto debemos empezar con la declaraci on 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 parles que ser an posteriormente aplicados a las l neas de los abonados. Es en estos perles en los que se denen las tasas de sincronizaci on, tanto de subida como de bajada, as como el est andar de la familia DSL que se utilizar a. En nuestra maqueta hemos denido un perl 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 perl de servicios y le da nombre (en nuestro caso lo hemos llamado pr acticas). El segundo comando declara que las tasas de subida y bajada ser an

30

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

controladas manualmente por el operador. El tercer comando establece estas tasas de subida y bajada y activa el perl. Con el cuarto comando creamos un perl de espectro y le damos un nombre, en este caso el mismo que el perl de servicios, aunque no tiene por qu e ser as . En el quinto comando activamos el perl y lo establecemos como ADSL2+ (ITU G.992.5). Por u ltimo el sexto comando aplica los perles de servicio y de espectro a las 48 l neas de abonado. Todos estos comandos tambi en est an recogidos en el script 1. Si queremos comprobar que los perles est an bien congurados, 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

DE LOS EQUIPOS 4.2. CONFIGURACION

31

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: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: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 ---------------------------------------------------------------------------

32

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

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 an 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 on, por lo que podemos reconocer la alarma y congurarla para que no vuelva a activarse. Eso se realiza con los siguientes dos comandos, que tambi en est an incluidos en el script 1: isadmin># admin alarm clr-persist-loss 70/01/01 17:24:30 critical alarm cleared for System and backup memory reset (service affecting) :

isadmin># configure alarm entry loss-over-cap no reporting no logging 70/01/01 17:26:42 major alarm cleared for capability : Loss of protection switching

Con esto el LED de alarma se habr a 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 ---------------------------------------------------------------------------

DE LOS EQUIPOS 4.2. CONFIGURACION

33

--------------------------------------------------------------------------table count : 0 =========================================================================== Conguraci on de los PVCs Por u ltimo, debemos congurar los PVCs de cada l nea. Adem as aplicaremos unas pol ticas de QoS para limitar el tr aco de cada uno de ellos en el bucle de abonado y garantizar que as no intereran unos servicios con otros. Lo primero que debemos denir son unas sesiones (session en los comandos del DSLAM) compuestas por un policer de subida y otro de bajada. Este policer ser a el encargado de restringir la tasa de tr aco al l mite establecido por el par ametro committed-info-rate en kbps, permitiendo un exceso de tr aco 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 policer 3M committed-info-rate 3072 committed-burst-size 3072 configure qos profiles policer 6M committed-info-rate 6144 committed-burst-size 6144 configure qos profiles policer 8M committed-info-rate 8192 committed-burst-size 8192 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 down-policer name:6M logical-flow-type pvc configure qos profiles session v deo up-policer name:1M down-policer name:8M logical-flow-type pvc Los cuatro primeros comandos denen los policers para unas tasas de 1, 3, 6 y 8 Mbps respectivamente. Los siguientes tres comandos crean las sesiones para los perles de datos, voz y v deo. Los tres tienen asignado el policer de 1 Mbps para la subida. La bajada est a limitada a 3, 6 y 8 Mbps respectivamente. Esto hace un total de 17 Mbps, frente a los 18 Mbps que tiene congurada la l nea ADSL, por lo que tenemos 1 Mbps extra para los excesos de tr aco.

34

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

Una vez tenemos listas las sesiones de QoS podemos crear los PVCs de cada una de las 48 l neas. Para ello, hay que denir primero las VLANs para cada PVC y despu es establecer el PVC y asignarle la VLAN con su sesi on de QoS correspondiente. Por ejemplo, para crear el PVC de datos de la l nea 30 har a falta ejecutar los siguientes comandos: configure configure configure configure configure configure configure configure configure configure configure configure vlan id 301 name datos30 mode qos-aware vlan id 301 dhcp-opt-82 circuit-id customer-id vlan shub id 301 name datos30 mode cross-connect vlan shub id 301 egress-port network:1 vlan shub id 301 egress-port lt:1/1/4 interface port xdsl-line:1/1/4/30 user linea30 admin-up atm pvc 1/1/4/30:8:32 aal5-encap-type llc-snap interface atm-pvc 1/1/4/30:8:32 customer-id datos30 bridge port 1/1/4/30:8:32 bridge port 1/1/4/30:8:32 vlan-id 301 bridge port 1/1/4/30:8:32 pvid 301 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 on de la l nea 30 y el 1 porque es una VLAN de datos) y se le establece la opci on de QoS. Con los tres siguientes comandos se declara la VLAN en el shub, es decir, en el switch Ethernet del DSLAM, deniendo el puerto de red y el puerto local por el que circular a 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 denido anteriormente. Por u ltimo le asignamos el perl 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 on ser a mucho m as 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 conguraciones y reinicio En el caso de querer borrar algunas de las conguraciones anteriores se usar a 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 eramos desasociar el perl de QoS asociado a dicho PVC escribir amos:

DE LOS EQUIPOS 4.2. CONFIGURACION configure bridge port 1/1/4/30:8:32 no qos-profile

35

Para facilitar la tarea de desasociar los perles de QoS y borrar las interfaces de cliente, junto con las VLANs correspondientes se han creado los scripts ?? y ?? respectivamente. Por u ltimo si lo que queremos es un borrado completo del DSLAM y restaurarlo a su estado de f abrica 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 conguraci on, si lo ejecutamos sin la u ltima parte del comando, es decir: admin equipment reboot-isam

4.2.2.

Conguraci on del servidor de v deo

La conguraci on del servidor de v deo que a continuaci on se detalla es la referente a la parte de enrutamiento, es decir, la conguraci on 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 congurar interfaces Internet bridge que conecten varios interfaces ethernet. Puesto que tenemos tres VLANs por cada abonado (datos, voz y v deo), esta conguraci on nos permitir a 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 conguraci on se ha realizado el script 3, que se puede encontrar en los anexos. Los comandos b asicos 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

36

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

Los dos primeros comandos crean una interfaz con la VLAN correspondiente ligada a la interfaz eth2. Esta es la interfaz f sica Ethernet del servidor de v deo que conecta con la interfaz WAN del DSLAM. El identicador 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 en 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 u ltimo, con estos tres comandos les asignamos una direcci on IP a las tres interfaces Internet bridge que hemos creado. Esta direcci on IP la comparten cada una las VLANs de datos, voz y v deo respectivamente. De esta forma, el servidor de v deo tiene una u nica direcci on IP por cada VLAN para todos los clientes.

4.2.3.

Conguraci on del router ADSL

El router utilizado para las pruebas ha sido el Linksys WAG54GS Router ADSL. Este router dispone de un m odem ADSL2+, 4 puertos Ethernet 10/100 e incorpora un punto de acceso Wireless-G (802.11g). En el apartado de conguraci on permite todas las conguraciones m as 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 on para realizar las pruebas necesarias en la maqueta. La conguraci on del router ADSL es muy simple, pues debe ser capaz de realizarla un cliente en su domicilio. Aunque tambi en ser a posible enviar el router ya congurado. En la maqueta de pruebas hemos decidido asignar una IP ja para cada una de las VLANs de cada cliente. De esta forma nos es m as simple supervisar el tr aco para las pruebas. Sin embargo, se podr a asignar esta IP autom aticamente utilizando DHCP. Lo u nico que debemos congurar 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 conguraci on hay que escoger el tipo de conexi on 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 a LLC/SNAP-BRIDGING. Podemos ver un ejemplo de conguraci on en la gura 4.5. Asimismo, podemos observar una captura de la p agina de conguraci on de IP del router en la gura 4.6. Con esto ya tendr amos todos los elementos de la maqueta congurados 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 ecnica de poder disponer de un enlance seguro, able e independiente desde servidores externos a la red hasta los usuarios nales 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 on 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

38

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

Figura 4.5: Conguraci on del tipo de conexi on 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 congurados. En primer lugar conectamos un PC a unos de los puertos Ethernet del router del cliente 1 y lo conguramos con la IP 10.0.0.128 (v ease la gura 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: Conguraci on 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 este 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 estas sean correctas, podemos pasar a comprobar la conexi on entre los dos clientes. Por seguridad, y para evitar que haya tr aco sin supervisar y sin taricar, si ello es necesario, el DSLAM no permite la interconexi on 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 a el servidor de v deo. Primero probaremos que con toda la maqueta correctamente conectada y congurada, podemos hacer un ping desde un router de cliente a otro. Una vez realizada esta comprobaci on, desconectamos el interfaz que conecta al DSLAM con el servidor de v deo y comprobamos que, como es de esperar, se pierde la conexi on entre los clientes, pues el DSLAM no est a realizando ning un tipo de conexi on 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 as 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 eramos llegar a un PC

40

Y PRUEBAS DE LA RED IPTV CAP ITULO 4. IMPLEMENTACION

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 an los clientes los que empiecen las conexiones hacia los servidores de v deo, y no al rev es. En el switch que conecta el servidor de v deo con el DSLAM realizamos una captura de tr aco para comprobar que, efectivamente, los paquetes que viajan entre los dos dispositivos est an etiquetados con la VLAN correspondiente. Con esto nos aseguramos de que tenemos separados los tres ujos de tr aco. Por u 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 conguramos el enrutado para que se permita todo el tr aco con los siguientes comandos: echo "1" > /proc/sys/net/ipv4/ip_forward iptables -A FORWARD -j ACCEPT De esta forma comprobamos que tambi en se puede acceder a los clientes desde el exterior de la red, y que cada tipo de tr aco viaja por su VLAN correspondiente. Por este motivo nos resulta muy simple ltrar el tr aco y por ejemplo, dejar pasar el tr aco desde una IP origen a un u 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 exible, que permitiera disponer de proveedores de servicios independientes del proveedor de acceso, que diversiquen la oferta de contenidos. Hemos analizado las ventajas e inconvenientes de este modelo, comparado con el modelo actual, tomando los siguientes criterios: Estandarizaci on Seguridad Robustez Compatibilidad Escalabilidad Gesti on de red Provisi on de servicios Perdurabilidad Costes de mantenimiento (OPEX) Costes de inversi on (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 ecnica y econ omicamente. Adem as de abrir grandes oportunidades para introducir variedad en los contenidos, e incluso contenidos espec cos para cada cliente. Para reforzar la armaci on de que el modelo era viable t ecnicamente, se dise no y mont o una maqueta de pruebas en la que poder simular una red como la propuesta a 41

42

CAP ITULO 5. CONCLUSIONES

peque na escala. Tras el montaje y las pruebas pertinentes, se concluy o que es posible diferenciar y separar el tr aco en funci on de los servicios que se quieran ofrecer y del cliente nal. De esta forma, podemos alcanzar las premisas de partida de una red IPTV exible, en la que la oferta de contenidos no est e limitada a la que ofrece el proveedor de acceso. Adem as, durante el montaje de la maqueta se ha generado una pauta de conguraci on 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 denen 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 omo se adapta y que nivel de eciencia se alcanza con la estructura propuesta. Tambi en se podr a analizar y denir una red metroethernet que sea o ptima para el transporte de los distintos ujos de datos y para la conexi on con los proveedores de contenidos. Adem as se podr a proponer un modelo alternativo de calidad de servicio que se adapte mejor a esta red. Por u ltimo, habr a que dise nar una plataforma de software que sirva de portal para la suscripci on a los distintos proveedores de contenidos y permita a los usuarios gestionar estas suscripciones. Asimismo, ser a muy u til poder integrar este software en el descodicador conectado a la televisi on para poder realizar este proceso de la forma m as intuitiva posible.

ANEXO

43

ANEXO
Scripts de conguraci on
Script 1: Inicializaci on del DSLAM
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

#! / b i n / b a s h echo I n i c i a l i z a n d o DSLAM ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 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 t y p e aramd unlock sleep 1 echo c o n f i g u r e equipment s l o t 1/1/1 planned t y p e genc e u n l o c k sleep 1 echo c o n f i g u r e equipment s l o t 1/1/2 planned t y p e e c n t a u n l o c k sleep 1 echo c o n f i g u r e equipment s l o t 1/1/4 planned t y p e e b l t c u n l o c k sleep 1 echo c o n f i g u r e equipment a p p l i q u e 1/1/2 planned t y p e pwiob sleep 1 echo c o n f i g u r e equipment a p p l i q u e 1/1/4 planned t y p e rpsp a sleep 1 echo c o n f i g u r e system i d DSLAM1 sleep 1 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 sleep 1 echo ra modeup o p e r a t o r c t r l d ra modedown o p e r a t o r c t r l d sleep 1 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 sleep 1 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 sleep 1 echo g992 5a a c t i v e sleep 1 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 adminup sleep 30 echo admin alarm c l r p e r s i s t l o s s sleep 1 echo c o n f i g u r e alarm e n t r y l o s s over cap no r e p o r t i n g no l o g g i n g sleep 1

45

46
42 43 44

echo l o g o u t ) | telnet >> salida . txt echo DSLAM i n i c i a l i z a d o

Script 2: Creaci on de los abonados


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

#! / b i n / b a s h linea10 =0 ident =0 echo Creando l o s p e r f i l e s de QoS

( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e q o s 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 b u r s t s i z e 1024 sleep 1 echo c o n f i g u r e q o s p r o f i l e s p o l i c e r 3M committed i n f o r a t e 3072 committed b u r s t s i z e 3072 sleep 1 echo c o n f i g u r e q o s p r o f i l e s p o l i c e r 6M committed i n f o r a t e 6144 committed b u r s t s i z e 6144 sleep 1 echo c o n f i g u r e q o s p r o f i l e s p o l i c e r 8M committed i n f o r a t e 8192 committed b u r s t s i z e 8192 sleep 1 echo c o n f i g u r e q o s p r o f i l e s s e s s i o n d a t o s 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 f l o w t y p e pvc sleep 1 echo c o n f i g u r e q o s 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 l o g i c a l f l o w t y p e pvc sleep 1 echo c o n f i g u r e q o s p r o f i l e s s e s s i o n v d e o up p o l i c e r name : 1M down p o l i c e r name : 8M l o g i c a l f l o w t y p e pvc sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Creados l o s p e r f i l e s de QoS

f o r ( ( linea =29; linea ' < = ' 29; linea ++)) do ( ( linea10 = $ linea * 1 0 ) ) f o r ( ( vc =1; vc ' < = ' 3; vc ++)) do ( ( ident =$ linea10 + $ vc ) ) case $ vc in 1) echo Creando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150

47
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

sleep 1 echo c o n f i g u r e v l a n i d $ i d e n t name d a t o s $ l i n e a mode qos aware sleep 1 echo dhcpopt 82 c i r c u i t i d customer i d sleep 1 echo c o n f i g u r e v l a n 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 c o n n e c t sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t network : 1 sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t l t : 1 / 1 / 4 sleep 1 echo c o n f i g u r e i n t e r f a c e p o r t x d s l 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 sleep 1 echo c o n f i g u r e atm pvc 1/1/4/ $ l i n e a : 8 : 3 2 a a l 5 encap t y p e l l c snap sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 2 customer i d d a t o s $ l i n e a sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 2 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 2 vlan i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 2 p v i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 2 qos p r o f i l e name : d a t o s sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Creada l a v l a n $ i d e n t ;; 2) echo Creando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e v l a n i d $ i d e n t name v o z $ l i n e a mode qos aware sleep 1 echo dhcpopt 82 c i r c u i t i d customer i d sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t name v o z $ l i n e a mode c r o s s c o n n e c t sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t network : 1 sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t l t : 1 / 1 / 4 sleep 1 echo c o n f i g u r e atm pvc 1/1/4/ $ l i n e a : 8 : 3 3 a a l 5 encap t y p e l l c snap sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 3 customer i d v o z $ l i n e a sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 vlan i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 p v i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 qos p r o f i l e name : voz sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Creada l a v l a n $ i d e n t

48
118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158

;; 3) echo Creando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e v l a n i d $ i d e n t name v d e o $ l i n e a mode qos aware sleep 1 echo dhcpopt 82 c i r c u i t i d customer i d sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t name v d e o $ l i n e a mode c r o s s c o n n e c t sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t network : 1 sleep 1 echo c o n f i g u r e v l a n shub i d $ i d e n t e g r e s s p o r t l t : 1 / 1 / 4 sleep 1 echo c o n f i g u r e atm pvc 1/1/4/ $ l i n e a : 8 : 3 4 a a l 5 encap t y p e l l c snap sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 4 customer i d v deo$linea sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 4 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 4 vlan i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 4 p v i d $ i d e n t sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 qos p r o f i l e name : v deo sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Creada l a v l a n $ i d e n t ;; esac done done

Script 3: Creaci on de las interfaces en el servidor de v deo


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#! / b i n / b a s h linea10 =0 ident =0 brctl addbr datos brctl addbr voz brctl addbr v deo f o r ( ( linea =1; linea ' < = ' 48; linea ++)) do ( ( linea10 = $ linea * 1 0 ) ) f o r ( ( vc =1; vc ' < = ' 3; vc ++)) do ( ( ident =$ linea10 + $ vc ) ) vconfig add eth2 $ ident ifconfig eth2 . $ ident up

49
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

echo Creado e l i n t e r f a z e t h 2 . $ i d e n t case $ vc in 1) brctl addif datos eth2 . $ ident echo A n adido a l b r i d g e de d a t o s ;; 2) brctl addif voz eth2 . $ ident echo A n adido a l b r i d g e de voz ;; 3) brctl addif v deo eth2 . $ ident echo A n adido a l b r i d g e de v deo ;; esac done done ifconfig datos 1 9 2 . 1 6 8 . 1 . 1 ifconfig voz 1 9 2 . 1 6 8 . 2 . 1 ifconfig v deo 1 9 2 . 1 6 8 . 3 . 1

Script 4: Desasociaci on de los perles de QoS


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

#! / b i n / b a s h linea10 =0 ident =0 f o r ( ( linea =1; linea ' < = ' 48; linea ++)) do ( ( linea10 = $ linea * 1 0 ) ) f o r ( ( vc =1; vc ' < = ' 3; vc ++)) do ( ( ident =$ linea10 + $ vc ) ) case $ vc in 1) echo D e s a s o c i a n d o a l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 2 no qos p r o f i l e sleep 1 echo l o g o u t ) | telnet >> salida . txt echo D e s a s o c i a d o l a v l a n $ i d e n t ;; 2) echo D e s a s o c i a n d o l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n

50
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 3 no qos p r o f i l e sleep 1 echo l o g o u t ) | telnet >> salida . txt echo D e s a s o c i a d a a l a v l a n $ i d e n t ;; 3) echo D e s a s o c i a n d o a l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e p o r t 1/1/4/ $ l i n e a : 8 : 3 4 no qos p r o f i l e sleep 1 echo l o g o u t ) | telnet >> salida . txt echo D e s a s o c i a d a a l a v l a n $ i d e n t ;; esac done done

Script 5: Borrado de l neas y VLANs


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#! / b i n / b a s h linea10 =0 ident =0 f o r ( ( linea =29; linea ' < = ' 29; linea ++)) do ( ( linea10 = $ linea * 1 0 ) ) f o r ( ( vc =1; vc ' < = ' 3; vc ++)) do ( ( ident =$ linea10 + $ vc ) ) case $ vc in 1) echo Borrando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e no p o r t 1/1/4/ $ l i n e a : 8 : 3 2 sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 2 no customer i d sleep 1 echo c o n f i g u r e atm no pvc 1/1/4/ $ l i n e a : 8 : 3 2 sleep 1

51
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

echo c o n f i g u r e sleep 1 echo c o n f i g u r e sleep 1 echo c o n f i g u r e sleep 1 echo l o g o u t )

i n t e r f a c e p o r t x d s l l i n e : 1 / 1 / 4 / $ l i n e a no u s e r no adminup v l a n shub no i d $ i d e n t v l a n no i d $ i d e n t | telnet >> salida . txt

echo Borrada l a v l a n $ i d e n t ;; 2) echo Borrando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e no p o r t 1/1/4/ $ l i n e a : 8 : 3 3 sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 3 no customer i d sleep 1 echo c o n f i g u r e atm no pvc 1/1/4/ $ l i n e a : 8 : 3 3 sleep 1 echo c o n f i g u r e v l a n shub no i d $ i d e n t sleep 1 echo c o n f i g u r e v l a n no i d $ i d e n t sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Borrada l a v l a n $ i d e n t ;; 3) echo Borrando l a v l a n $ i d e n t ( echo open 1 9 2 . 1 6 8 . 0 . 1 0 sleep 1 echo i s a d m i n sleep 1 echo ANS#150 sleep 1 echo c o n f i g u r e b r i d g e no p o r t 1/1/4/ $ l i n e a : 8 : 3 4 sleep 1 echo c o n f i g u r e i n t e r f a c e atmpvc 1/1/4/ $ l i n e a : 8 : 3 4 no customer i d sleep 1 echo c o n f i g u r e atm no pvc 1/1/4/ $ l i n e a : 8 : 3 4 sleep 1 echo c o n f i g u r e v l a n shub no i d $ i d e n t sleep 1 echo c o n f i g u r e v l a n no i d $ i d e n t sleep 1 echo l o g o u t ) | telnet >> salida . txt echo Borrada l a v l a n $ i d e n t ;; esac done done

52

Presupuesto
A continuaci on 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 on en horas seg un su complejidad y duraci on. En la gura 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 as importantes y que han llevado m as tiempo, han sido la conguraci on del DSLAM, el dise no de la red y la documentaci on.

Costes laborales
Para el presente proyecto se cuenta con un Ingeniero Senior y un Ingeniero Junior, el primero centrado en tareas de dise no y el segundo en tareas de implementaci on. Las retribuciones de ambos se pueden observar en la tabla 1

53 Personal Categor a Coste hombre mes Ingeniero Senior 4.289,54 Ingeniero Junior 2.694,39 Tabla 1: Retribuci on seg un la categor a
Descripci on Coste (Euros) DSLAM 14.043,96 Servidor de v deo 1.500,00 Routers ADSL 150,00 Ordenador port atil 699,00 % Uso dedicado proyecto Dedicaci on (meses) Per odo de depreciaci on Coste imputable 100 3 60 702,20 100 3 60 75,00 100 3 60 7,50 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 aximo anual de dedicaci on de 12 hombres mes hacen 1575 horas al a no. Aplicando estos valores a las horas dedicadas a cada tarea obtenemos el coste de personal. Este c alculo se encuentra en la gura 2.

Figura 2: Costes laborales

Coste de los equipos


A continuaci on se detalla el coste de los equipos utilizados en la maqueta, y para las tareas de recopilaci on de informaci on y documentaci on. Para calcular la depreciaci on suponemos los tres meses que obtenemos en el diagrama de Gantt. Los costes est an reejados en la tabla 2.

54 Descripci on Cantidad Coste unitario Coste imputable CD 2 0,50 1,00 Memoria USB 1 45,00 45,00 Material de ocina 1 30,00 30,00 Total 76,00 Tabla 3: Costes del material fungible Precio por km 0,17 km Coste imputable 2400 408,00

Tabla 4: Coste del transporte

Otros costes directos


En este apartado incluiremos todos los gastos no contemplados anteriormente como costes fungibles (tabla 3) y coste del transporte (tabla 4). Para este u 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 on del proyecto.

Costes indirectos
Aqu se incluyen todos aqu ellos gastos que aunque no est an vinculados directamente al Proyecto son necesarios para que este 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 nal
A nadiendo a lo anterior los m argenes por riesgo y el benecio que se desea obtener, as como el I.V.A. obtenemos que el presupuesto total de este proyecto es de CUARENTA Y CUATRO MIL OCHOCIENTOS CINCUENTA Y UNO CON DIE euros. CISEIS

55 Concepto Personal Amortizaci on Costes de funcionamiento Costes indirectos Total Cantidad 21.338,51 802,17 484,00 4.525,94 27.149,62

Tabla 5: Resumen de costes Concepto Coste total Riesgo (20 %) Benecio (20 %) Total sin I.V.A. I.V.A. (18 %) Total Cantidad 27.149,62 5.429,92 5.429,92 38.009,46 6.841,70 44.851,16

Tabla 6: Presupuesto del Proyecto Legan es, a 27 de enero de 2011 El ingeniero proyectista

Jos e Mar a Zapardiel Gonzalo

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 Condentiality 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 Specication (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 IA

[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-Specic 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.

Anda mungkin juga menyukai