PFC_Diseno_y_configuracion_de_una_red_IP_para_distribucion_de_TDT

•

Outros

Mari Castro

15/3/2024

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Fundamentos de Redes de Datos y Comunicación

1537 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

Proyecto Final de Carrera

JORGE ESCUDERO EMBID

Abertis Telecom
E.T.S. de Ingeniería de Telecomunicaciones de Barcelona (ETSETB)
Universitat Politècnica de Catalunya (UPC)
DISEÑO Y CONFIGURACIÓN DE UNA RED IP
PARA DISTRIBUCIÓN DE SEÑAL DE TDT

Resumen
La finalidad de este proyecto es implementar una red de
transporte terrena, basada en la tecnología Multicast,
diseñada para distribuir una señal de Televisión Digital
Terrestre (TDT) hacia diferentes centros emisores.

El diseño de la red se apoyará en la infraestructura que ya
tiene desplegada la empresa para distribuir servicios IP de
otros operadores y así poder optimizar mejor los recursos
de la red.

Se tratará tanto el funcionamiento de la tecnología
Multicast como la función que realiza cada uno de los
elementos de la red, sus requerimientos, el modo en el
que deben ser configurados y la manera en que
interactuaremos remotamente con ellos a nivel de
supervisión. También se abarcará la infraestructura
necesaria de los equipos en los centros.

Índice

1. Introducción................................................................................................................. 9
1.1 Antecedentes ...................................................................................................................... 9
1.2 Motivación ........................................................................................................................ 10
1.3 Objetivos ........................................................................................................................... 11
2. Arquitectura y funcionamiento de la TDT .................................................................... 13
2.1 Cabecera ............................................................................................................................ 14
2.2 Transporte ......................................................................................................................... 15
2.2.1 Transporte vía Terrena ............................................................................................... 15
2.2.2 Transporte Satélite ..................................................................................................... 16
2.3 Difusión ............................................................................................................................. 17
2.3.1 Redes MFN ................................................................................................................. 20
2.3.2 Redes SFN ................................................................................................................... 20
3. Diseño de la red ......................................................................................................... 23
3.1 Estructura física ................................................................................................................. 23
3.2 Estructura Lógica ............................................................................................................... 25
3.3 Gestión .............................................................................................................................. 28
3.4 Valores importantes para el diseño .................................................................................. 29
4. Multicast.................................................................................................................... 31
4.1 Descripción ........................................................................................................................ 31
4.2 Elección del método de transmisión ................................................................................. 31
4.3 Funcionamiento ................................................................................................................ 32
4.4 Ventajas y desventajas del Multicast ................................................................................ 33
4.5 Tipos de aplicaciones ........................................................................................................ 34
4.6 Modelo básico de servicio ................................................................................................. 35
4.6.1 Direccionamiento Multicast ....................................................................................... 35
4.6.1.1 Direccionamiento Multicast en capa 3 ................................................................ 35
4.6.1.2 Direccionamiento Multicast en capa 2 ................................................................ 36
4.6.2 Transmisores y receptores ......................................................................................... 38
4.6.2.1 IGMP versión 1 .................................................................................................... 38
4.6.2.2 IGMP versión 2 .................................................................................................... 40
4.6.2.3 IGMP versión 3 .................................................................................................... 41
4.6.3 IGMP Snooping ........................................................................................................... 43
6

4.6.3.1 Funcionamiento .................................................................................................. 43
4.6.3.2 Equipos ................................................................................................................ 45
4.6.4 Funciones de la red .................................................................................................... 49
4.6.4.1 Reverse Path Forwarding .................................................................................... 49
4.6.4.2 TTL Scoping .......................................................................................................... 51
4.6.4.3 Administrative Scoping ........................................................................................ 52
4.6.5 Árboles de distribución .............................................................................................. 53
4.6.5.1 Source Distribution Tree ..................................................................................... 53
4.6.5.2 Shared Distribution Tree ..................................................................................... 55
4.6.6 Protocolos de conmutación Multicast ....................................................................... 57
4.6.6.1 DVMRP ................................................................................................................ 58
4.6.6.2 MOSPF ................................................................................................................. 59
4.6.6.3 PIM DM ................................................................................................................ 59
4.6.6.4 PIM SM ................................................................................................................ 62
4.6.6.5 Elección del método de conmutación ................................................................. 65
5. Red de transporte ...................................................................................................... 67
5.1 Introducción ...................................................................................................................... 67
5.2 Descripción de un radioenlace .......................................................................................... 67
5.2.1 Diseño de los radioenlaces ......................................................................................... 68
5.2.2 Elección del fabricante ............................................................................................... 73
5.3 Equipamiento del radioenlace ..........................................................................................74
5.3.1 IDU .............................................................................................................................. 74
5.3.2 ODU ............................................................................................................................ 77
5.4 Supervisión y mantenimiento ........................................................................................... 78
5.4.1 Supervisión ................................................................................................................. 79
5.4.2 Mantenimiento .......................................................................................................... 81
6. Codificación y decodificación de la señal ..................................................................... 83
6.1 Elección de codificadores y decodificadores ..................................................................... 83
6.2 Codificador D9435 ............................................................................................................. 83
6.2.1 Características ............................................................................................................ 83
6.2.2 Supervisión ................................................................................................................. 84
6.2.3 Mantenimiento .......................................................................................................... 87
6.3 Decodificador D9402 ......................................................................................................... 87
6.3.1 Características ............................................................................................................ 87
6.3.2 Supervisión ................................................................................................................. 88
6.3.3 Mantenimiento .......................................................................................................... 90
7. Equipamiento IP y configuración ................................................................................. 91
7.1 Elección del equipamiento IP ............................................................................................ 91
7

7.2 Equipamiento IP ................................................................................................................ 92
7.2.1 Características del ME 3400-24TS-DC ....................................................................... 92
7.2.2 Sistemas Operativos de interconexión de redes ........................................................ 94
7.1.3 Elección de la versión IOS para nuestra red ............................................................... 95
7.2.4 Supervisión y mantenimiento .................................................................................... 97
7.3Configuración de los ME3400 ............................................................................................ 99
7.3.1 Configuración de equipos de capa 2 ........................................................................ 100
7.3.2 Configuración de equipos de capa 3 ........................................................................ 103
7.3.3 Funcionamiento a nivel IP ........................................................................................ 103
8. Infraestructuras y alimentación ................................................................................ 107
8.1 Infraestructuras ............................................................................................................... 107
8.2 Alimentación ................................................................................................................... 107
8.2.1 Diseño y equipamiento del sistema de alimentación .............................................. 108
8.2.1.1 Módulo MCU 1000 ............................................................................................ 109
8.2.1.2 Rectificadores .................................................................................................... 110
8.2.1.3 Baterías .............................................................................................................. 111
8.2.2 Mantenimiento de los equipos de alimentación ..................................................... 112
8.2.3 Supervisión de los equipos de alimentación ............................................................ 112
9. Conclusiones y líneas de futuro ................................................................................. 115
10. Bibliografía .............................................................................................................. 119
11. Anexos ..................................................................................................................... 121
11.1 Índice de ilustraciones ................................................................................................... 121
11.2 Índice de referencias ..................................................................................................... 123
11.3 Red PDH / SDH .............................................................................................................. 125

1. Introducción

1.1 Antecedentes
Desde 2010 la televisión terrestre analógica ha dado paso a la TDT (televisión digital terrestre),
la cual utiliza el estándar DVB-T, lo que supone una mejora de calidad de imagen y sonido,
mejor optimización en frecuencias, posibilidad de diferentes formatos de video y audio,
acceso a aplicaciones interactivas, etc.
Abertis Telecom es la empresa que se encarga de gestionar, mantener y explotar la
distribución y difusión de la Televisión y Radio en una gran parte del territorio nacional. La
introducción de la TDT en España y el apagón analógico han modificado el equipamiento que
interviene en la emisión, distribución y supervisión de las señales para ofrecer al usuario el
mejor servicio disponible.
La implantación de la TDT en España ha sido realizada por todo el personal que trabaja en la
empresa. El mapa de procesos y como consecuencia, muchos departamentos, desde negocio,
tecnología hasta explotación, se han visto obligados a adaptar el contenido de las ofertas y
servicios prestados en el nuevo marco que ha aportado la digitalización.

Ilustración 1 - Mapa de procesos de la empresa

Desde el apagón analógico, la red de distribución que mantiene Abertis Telecom ha ido
sufriendo variaciones, originalmente era un red basada principalmente en la tecnología
PDH/SDH, en la cual se apoyaba para poder distribuir la señal de TDT y otros operadores.
Debido al incremento de la demanda de nuevos servicios IP por operadores y el aumento de
nuevos protocolos basados en la tecnología IP hace necesario adaptar la red a esta tecnología
con nuevos equipos y modelos ya que la previsión es que la tecnología PDH/SDH vaya en
desuso a lo largo de los años.

1.2 Motivación
Actualmente en España existen diferentes canales en función de la zona geográfica en la que
vivas, podemos encontrar canales nacionales, autonómicos y locales, evidentemente la
distribución de una cadena local que quiere abarcar una zona geográfica muy limitada y
acotada no tiene sentido realizarlo a través de satélite, ya que los costes tan elevados del
ancho de banda del satélite no lo harían viable. El mismo caso pasaría para algunas
autonómicas, y para todas ellas es más económico distribuir su señal a través de una red de
transporte terrena que distribuya la difusión hasta cada centro emisor. Adicionalmente,
también es interesante la distribución terrena para canales nacionales, ya que en centros
emisores troncales que dan cobertura a capitales de provincia, es necesario tener señales
auxiliares para poder garantizar el servicio en caso que falle algún componente de la
distribución satélite.
Durante estos años, esta distribuciónterrena de la TDT y otros servicios de operadores se ha
hecho mediante la tecnología PDH y SDH, pero teniendo en cuenta que se viene produciendo
en los últimos años una renovación tecnológica en el campo de los operadores de servicios de
red, hace que la evolución hacia las redes de transporte IP sea una de las mejores soluciones
para la empresa para ser más competitivo y, a largo plazo, conseguir aumentar la cuota de
mercado.
Pretendemos ver como esta actualización tecnológica nos abre un abanico nuevo de
posibilidades. Pretendemos estudiar con ello, cómo aprovecharnos de las ventajas que se
ofrecen y cómo buscar soluciones a diferentes entornos que nos podemos encontrar con este
cambio.
De esta forma, a través de los objetivos del próximo apartado, veremos como distribuir una
señal de TDT a través de una red IP, implicará el aprovechamiento de gran cantidad de
recursos aportando un paso adelante a nivel de empresa hacia este tipo de redes. Compartir
elementos de red nos obligará a recurrir a un abanico de sistemas de seguridad que iremos
necesitando.
Va a ser la unión de todos estos elementos de diseño y los estudios tecnológicos referentes a
retos los que nos permitirán definir la red completa de emisión y distribución de la TDT. Nos
motivará el hecho que esta tecnología no sólo optimizará recursos, sinó que permitirá la
coexistencia de diferentes servicios ala vez que nos ofrecerá nuevas formas de gestión y
operación a las cuales no eran viables con la tecnología PDH/SDH existente.
Desde mi puesto de trabajo en el Centro de Control de mantenimiento, operación y
supervisión dentro de la empresa Abertis Telecom me motiva el hecho de descubrir todas las
ventajas que se ofrecen con la tecnología IP a la vez que se me permite colaborar en el diseño
y confección de esta nueva red para el transporte y emisión de la TDT.
Además, para el tipo de servicio de transporte de la TDT, la utilización de la tecnología
Multicast ofrece una serie de características ideales en cuanto a flexibilidad y escalabilidad y
consigue cumplir las especificaciones de servicio iniciales del cliente. El diseño de la red y la
elección de los elementos principales se han realizado con la idea de aprovechar los recursos
ya existentes en la empresa.

1.3 Objetivos

Debido a la necesidad de adaptarse a las nuevas tecnologías del mercado y poder optimizar
mejor la infraestructura de la empresa, se pretende diseñar y configurar una solución para
poder distribuir la señal de TDT a través de una red IP existente. La red de transporte que se
desplegará tiene que garantizar un servicio de calidad y eficacia desde el origen hasta los
múltiples centros emisores.

Se analizará la estructura de red actual y las evoluciones que están surgiendo en la actualidad.
A partir de aquí, buscaremos el compromiso de la creación de una red y estructuras
funcionales, asequibles, viables, estables y económicas que nos permitan adaptar la tecnología
actual con la existente buscando el máximo de compatibilidades. Será preciso mantener los
servicios actuales así como permitir la escalabilidad con los futuros crecimientos.

Uno de los requisitos en este diseño es utilizar la infraestructura IP ya desplegada con la que
cuenta la empresa para ofrecer otros servicios a diferentes operadores. De esta forma, se
podrá aprovechar al máximo los recursos con los que contamos y podremos reducir el coste
del proyecto. Evidentemente, en los casos en los que no se pueda aprovechar y no cuenten
con equipamiento IP instalado, actualizaremos la tecnología para ampliar la infraestructura
existente.

La instalación de una nueva tecnología nos aporta un escenario distinto al que teníamos
previamente, pasamos de tener una estructura dedicada para cada cliente en la que cada
instalación cuenta con su equipamiento propio, a una tecnología IP que se basa en minimizar
la cantidad de equipos existentes para compartirlos con todos los servicios que deben coexistir
en todo momento con la misma calidad.

El hecho de compartir la misma infraestructura IP con diferentes servicios y clientes provoca
una problemática en seguridad y en el funcionamiento de los servicios. Para solucionar este
problema se propondrá un diseño en la configuración IP en el cual se aislarán los servicios a
nivel lógico en nuestro equipamiento IP para evitar problemas.

Una vez definida la tecnología y la infraestructura, se nos han presentado unos problemas o
retos de este nuevo entorno, veremos cómo se resuelven y cómo se aplican estas soluciones
permitiendo la escalabilidad necesaria y todos los requisitos que se planteen. Posteriormente
deberemos analizar y estudiar los procesos adecuados para que la distribución de la TDT pueda
realizarse de la forma más óptima y adecuada según las especificaciones técnicas de la red y
los condicionantes propios de cada cliente o servicio.

Para la distribución de la señal de TDT nos apoyaremos en la tecnología Multicast. Se calculará
la capacidad y características de la señal de un canal TDT y se estudiarán las ventajas que nos
proporciona esta tecnología respecto a otros modos de transmisión. La Multicast nos permitirá
optimizar el rendimiento de la red al enviar una copia de datos en todos los puntos de la
distribución, eliminando una gran cantidad de tráfico redundante que ocuparía
innecesariamente ancho banda de nuestra red de transporte, además de reducir la carga de
trabajo de las CPUs de los diferentes equipos que forman parte de la transmisión.

Se analizarán los diferentes protocolos de conmutación Multicast, se valorará la escalabilidad y
modo de funcionamiento. Se estudiarán las características de cada uno y se elegirá el
protocolo que mejor se adapte a nuestra red valorándose para nuestra elección el protocolo
más adecuado para subsanar ciertas limitaciones físicas existentes que permitan la estabilidad
de la red, como podrían ser los factores de limitación de capacidad, saturación y pérdida de
paquetes

El servicio de video a tiempo real tiene unas particularidades que deberán estudiarse con
detalle. Se necesita pues, que se cumplan todas y cada una de ellas para que la señal de TDT
no se vea perjudicada. De esta forma, para evitar congelaciones o pixelaciones y ofrecer un
servicio de calidad, la red debe dimensionarse y configurarse acorde a ello. Se trabajará con
equipos que puedan soportar este flujo constante de tráfico, que a su vez no degraden su
calidad con lo que deberemos luchar con prioridades para evitar descarte de paquetes.

Se justificará la elección de todos los elementos necesarios que intervienen en el proceso del
transporte de la señal, desde el equipo donde se genera la señal hasta que se entrega a la
emisora. Para ello se valoraran los factores económicos, de calidad y escalabilidad. En el caso
de los switch también se analizaran las diferentes versiones de sistemas operativos y se
escogerá la más adecuada teniendo en cuenta la función que haga cada uno de ellos.

Se explicará la forma de interactuar con los equipos implicados así como su mantenimiento y
supervisión desde un centro de control. Se analizará la función que realizada cada uno de estos
elementos de la red, sus requerimientos y el modo en el que deben ser configurados. También
se abarcará la infraestructura necesaria a nivel energético en los centros para la instalación del
equipamiento IP.

Objetivos
Funcionamiento TDT Estudio de los requisitos técnicos de la TDT para el diseño y
dimensionado de la red.
Diseño de red Análisis de la situación actual para buscar soluciones y
adaptabilidades al cambio de la red PDH / SDH a la tecnología IP.
Tecnología de
transmisión
Elección de aquella tecnología sobre IP que permita la optimización
de recursos con el funcionamiento de calidad y transmisión ideales.
Red de transporte Diseño y estructura necesaria para el transporte correcto de la señal
IP a todos los puntos requeridos sinperder calidad en el servicio.
Equipamiento y
configuración
Decisión de los equipos más adecuados a los requisitos previos.
Análisis de configuración para subsanar cualquier reto que pueda
ocurrir con la coexistencia de múltiples servicios y clientes.

2. Arquitectura y funcionamiento de la TDT
En el 1992 se creó el Digital Video Broadcasting (DVB) para solucionar los problemas de
recepción de la señal de televisión y las limitaciones en imagen, sonido y los datos que estaban
sujetos a la televisión analógica. Los rebotes de la señal recibida y la falta de visión directa
entre el transmisor y el receptor provocaban dobles imágenes e interferencias, además de
limitar el formato de imagen y sonido a 4:3 y dual/estéreo respectivamente, este estándar se
utiliza en Europa y está basado en el sistema analógico PAL.
Para que la señal de TDT llegue a toda la población prevista, ha sido necesario el diseño de una
red de difusión que permita la transmisión de forma eficiente. El hecho de utilizar
modulaciones OFDM robustas a interferencias y con capacidad de corrección de errores, ha
hecho posible un cambio en las redes de difusión multifrecuencia analógicas, consiguiendo así
una utilización más eficiente del espectro y una reducción notable de potencia de transmisión.
Como se observa en la siguiente figura se pueden observar tres partes importantes en la
arquitectura de la red: Cabecera, transporte y difusión.

Ilustración 2 - Arquitectura de la TDT

2.1 Cabecera
Para transformar la señal hasta los centros emisores primero hay que empaquetarla e
identificarla, como se ha comentado con anterioridad cada canal de TDT agrupa varios
programas, por lo que será necesario un equipo multiplexor que una todos los canales en un
misma trama. En el caso de la TDT se utilizan los métodos de MPEG-2 TS (Transport Stream).
El grupo de estandarización MPEG define los formatos para comprimir la señal de audio y
video. La compresión video consiste en eliminar la información no visible para el ojo humano,
además de no enviar la información redundante de la señal.
Cada canal (MUX) se separa en flujos de programa (Program Stream-PS).

Ilustración 3 - Generación del transport Stream
Normalmente en estudios hay un codificador que codifica el video, audio y datos, a los cuales
les añade un identificador (Program ID, PID), también se insertan tablas de señalización (PMT)
que identifican los diferentes PES (Packetised Elementary Stream) que pertenecen a un mismo
programa.
La información de estudios se transporta hasta un centro importante, que es donde están los
multiplexores, aquí es donde se inserta cada flujo de programa (PS), los cuales contiene uno o
más PES. El multiplexado de varios programas forma el flujo de datos denominado Transport
Stream, también conocido como trama ASI (Asynchronous Serial Interface). Los diferentes
programas que se multiplexan se les añade información de señalización para sincronizar y
facilitar la decodificación de los programas en recepción. Esta información esta insertada en las
Tablas de Información de Servicio (PSI).
La multiplexación del transport stream consiste en pequeños paquetes de longitud constante.
Un paquete de transporte es siempre de 188 bytes, de los cuales 4 se destinan a una cabecera
de inclusión obligatoria tras la que podemos encontrar un campo de adaptación opcional. El
resto de bytes, hasta completar los 188 bytes, son de información (payload).
15

Ilustración 4 - Esquema de un paquete TS

2.2 Transporte
Es necesario disponer de una red transporte para distribuir la señal ASI que se genera en el
multiplexor hasta que llega a los centros emisores, esta señal puede ser transportada de dos
formas, vía terrena o vía satélite:

2.2.1 Transporte vía Terrena
Cuando la trama ASI se genera en el multiplexor se introduce en un adaptador de red, que
codifica la señal a una trama de 34Mbps (E3) para poder ser transportada a través de la red
troncal hasta los centros emisores, el esquema de distribución tiene forma de árbol.
16

Ilustración 5 - Esquema de distribución terrena a través de SDH/PDH

Los protocolos de transporte que se utilizan en los radioenlaces pueden ser:
PDH (jerarquía digital plesiócrona): utiliza técnicas de multiplexación por división de tiempo.
Los niveles de multiplexación son:
E1: 2 Mbps
E2: 8 Mbps
E3: 34 Mbps
E4: 140 Mbps
SDH (jerarquía digital síncrona): las tramas se encapsulan en contenedores y se añaden
cabeceras de control. Pueden enviarse sobre fibra óptica. Los niveles de transmisión son:
STM.1: 155Mbps
STM.4: 4 x STM.1 = 622 Mbps
STM.16: 16 x STM.1 = 2,5 Gbps
STM.64: 64 x STM.1 = 10 Gbps
2.2.2 Transporte Satélite
Hay múltiplex que transmiten el mismo contenido a la misma frecuencia para todo el territorio
español. Existen varios canales (67, 68, 69, etc.…). Su transporte se simplifica utilizando la
transmisión vía satélite de órbita geoestacionaria, ya que realizar toda la distribución por vía
terrena supondría unos costes muy elevados.
17

Ilustración 6 - Esquema de distribución satélite

La parábola que se utiliza en los centros receptores es de 1,2 metros de diámetro, y el satélite
que transmite los servicios es el Hispasat (en algunas partes de España también se utiliza el
Eutelsat). La información está modulada en 8PSK (según el estándar DVB.S2), en la banda de
12 GHz, en cada centro se dispone de un decodificar que genera las tramas ASI para ser
insertadas en las emisoras. Televisión Española también distribuye vía satélite sus
desconexiones territoriales.

2.3 Difusión
Para que la señal de TDT llegue a toda la población prevista, es necesario el diseño de redes de
difusión que permitan la transmisión de forma eficiente. El hecho de utilizar modulaciones
OFDM robustas a interferencias y con capacidad de corrección de errores, ha hecho posible un
cambio en las redes de difusión multifrecuencia analógicas, consiguiendo así una utilización
más eficiente del espectro y una reducción notable de potencia de transmisión.

Ilustración 7 - Espectro OFDM
18

La modulación OFDM permite aprovechar al máximo el limitado espectro de frecuencias
disponible. Esto se consigue espaciando las portadoras exactamente a fu =1/Tu , donde Tu es
el periodo de símbolo. Por lo que coinciden los ceros del espectro con los máximos de cada
portadora, eliminando la interferencia entre símbolos (ISI).

Ilustración 8 - Constelación de TDT

Ilustración 9 - Ejemplo de ortogonalidad en OFDM

La tasa de símbolo baja de las portadoras, proporciona un mejor comportamiento al
multicamino (rebotes de señales en la misma frecuencia). Para hacer todavía más robusta la
señal, se añade un intervalo de guarda. Se considera que el tiempo de guarda debe ser
superior al tiempo que tarda la señal en recorrer la distancia entre transmisores.

Ilustración 10 - Duración de los intervalos de guarda

Si un receptor recibe dos señales, la principal y un eco, la condición para que la interferencia
sea constructiva es que la diferencia de retardos no supere el tiempo de guarda. Otra ventaja
de utilizar una modulación robusta como OFDM es la no necesidad de tener visión directa con
el transmisor, pudiendo demodular la señal principal con ecos dentro del intervalo de guarda,
y también demodular directamente un eco sin visión directa de la señal original.
La elección de los diferentes parámetros que ofrece el estándar DVB.T afectará al bitrate neto
transmitido. Éste se puede calcular mediante la siguiente fórmula:
�� � �� � � � ���
� �����
� ����
Donde:
Ru : Bitrate útil
Rs: velocidad de símbolo bruta (siempre 6.75 Mbps)
b: bit por subportadora
CR(I): Codificación interior
CR(RS): Codificación exterior (Reed-Solomon)
Tu: duración útil del símbolo
Ts: duración total del símbolo

Ilustración 11 - Tabla resumen de tasas de bitsdisponibles

En España actualmente se utiliza la modulación no jerárquica por portadora 64QAM (6 bits por
símbolo). Con codificación convolucional 2/3 e intervalo de guarda de ¼ La codificación
exterior Reed Solomon es de 204 en lugar de 188 bytes. El modo es el 8k. Por tanto la
velocidad binaria será:

�� � 6,75���� � 6 � 23 �
188
204 �
896��
�896�� � 224��
� ��, �� !!"#$%
2.3.1 Redes MFN
Son las redes de la televisión analógica. Cada centro emisor utiliza una frecuencia de salida
diferente a la de entrada, de esta forma se evitan interferencias, además de desaparecer el
problema de aislamiento entre antenas para los reemisores. Para cubrir una zona extensa se
necesitan varias frecuencias diferentes, estando permitido el reuso de éstas.
La planificación de la difusión analógica se ha tenido que enfrentar al problema de las
interferencias cocanal, imposibilitando la reutilización del mismo canal en transmisores
cercanos.
2.3.2 Redes SFN
Utilizando OFDM, es posible emitir con varios transmisores en el mismo canal si la señal
moduladora es idéntica y esta sincronizada. Además, gracias a la inserción del intervalo de
guarda el receptor podrá beneficiarse de los ecos recibidos.
Para que los receptores puedan demodular señales en SFN, es obligatorio que éstas estén
sincronizadas, por ello cuando el multiplexor genera la trama ASI, ésta se inserta en un
adaptador SFN, este equipo está sincronizado con la misma señal GPS que reciben todos los
centros emisores y su función es introducir una tabla MIP en la trama ASI que permitirá
calcular el retardo de red de la señal, en esta tabla MIP también se incluye el retardo máximo
de la red permitido, en España se utilizan 750 milisegundos, así todos los centros emisores de
la misma zona podrán sincronizarse. Las sincronizaciones necesarias son:

- Sincronización de bit. Una portadora tiene que estar modulada exactamente por los
mismos bits en cada estación. La tolerancia a fallo es cero.

- Sincronización de frecuencia. Los transmisores han de transmitir exactamente a la
misma frecuencia. También tiene que ser idéntico la frecuencia de muestreo del
modulador y la velocidad de datos del “Transport Stream”. Todo esto se consigue con
osciladores de precisión y usando una referencia externa común.

- Sincronización de tiempo. Los transmisores tienen que emitir el mismo símbolo en el
mismo instante con una tolerancia de ± 1 µs. Es posible que para evitar ecos fuera del
intervalo de guarda en zonas de solapamiento, se introduzca un “offset” temporal.

Ilustración 12 - Ejemplo de recepción a diferentes instantes

Es decir, todos emiten lo mismo a la vez y en la misma frecuencia. Para conseguir todas estas
sincronizaciones se utilizan referencias frecuenciales y temporales procedentes de un receptor
GPS (10 MHz y 1 pulso por segundo).
Una vez la señal llega a los centros transmisores, los moduladores de los equipos son capaces
de extraer la información de los MIP y calcular el retardo introducido por la red de transporte y
distribución y así sincronizarse, el intervalo de guarda que permite demodular correctamente
la señal es de Δ=224 µs, lo cual implica una distancia máxima entre transmisores de 67,2 Km

A continuación se muestra un ejemplo donde se
1- La primera marca temporal la pone el Adaptador SFN que está justo después del
multiplexor, tanto el adaptador SFN como la emisora van sincronizadas con la misma
señal de GPS.
2- Después la señal se
retardo de red, el cual es diferente para cada centro emisor. Gracias a la marca que le
ha puesto el adaptador SFN la emisora es capaz de calcular el retardo de red
3- La emisora resta el retardo máximo (750ms) al retardo de red y obtiene el tiempo de
espera para conseguir que todos los centros salgan sincronizados al mismo tiempo.

Ilustración

La conclusión que se obtiene es que el retardo máximo de red que tiene que haber hasta la
emisora tiene que ser inferior a 750ms independientemente de la tecnología y ruta que se
utilice para transportar la señal de TDT

un ejemplo donde se calcula el Tiempo de Espera:
La primera marca temporal la pone el Adaptador SFN que está justo después del
multiplexor, tanto el adaptador SFN como la emisora van sincronizadas con la misma
se transporta hasta la emisora, donde ha acumulado un cierto
retardo de red, el cual es diferente para cada centro emisor. Gracias a la marca que le
ha puesto el adaptador SFN la emisora es capaz de calcular el retardo de red
ora resta el retardo máximo (750ms) al retardo de red y obtiene el tiempo de
espera para conseguir que todos los centros salgan sincronizados al mismo tiempo.
Ilustración 13 - Ejemplo para calcular el tiempo de espera
conclusión que se obtiene es que el retardo máximo de red que tiene que haber hasta la
emisora tiene que ser inferior a 750ms independientemente de la tecnología y ruta que se
utilice para transportar la señal de TDT.

La primera marca temporal la pone el Adaptador SFN que está justo después del
multiplexor, tanto el adaptador SFN como la emisora van sincronizadas con la misma
transporta hasta la emisora, donde ha acumulado un cierto
retardo de red, el cual es diferente para cada centro emisor. Gracias a la marca que le
ha puesto el adaptador SFN la emisora es capaz de calcular el retardo de red
ora resta el retardo máximo (750ms) al retardo de red y obtiene el tiempo de
espera para conseguir que todos los centros salgan sincronizados al mismo tiempo.

conclusión que se obtiene es que el retardo máximo de red que tiene que haber hasta la
emisora tiene que ser inferior a 750ms independientemente de la tecnología y ruta que se
23

3. Diseño de la red

Lo que se pretende en el diseño es adaptar y optimizar al máximo todos los recursos que
actualmente se están explotando por la empresa para conseguir distribuir la señal de TDT y
tener gestión de toda la red para atender posibles incidencias.

Para llevar a cabo la distribución de la señal del MUX de TDT utilizaremos la tecnología IP
Multicast, ya que nos proporciona varias ventajas respecto a otras formas de transmisión
como podría ser el unicast. Optimiza el rendimiento de la red al enviar una única copia de la
información para todo un grupo de centros emisores, en lugar de enviar una copia de la
información para cada uno de ellos, además de que la recepción del tráfico Multicast en los
diferentes centros emisores es prácticamente simultánea.

Para ello son necesarios varios elementos.

3.1 Estructura física

En primer lugar, necesitamos transformar la señal que entrega el mutiplexor a una señal IP,
para proceder a continuación a su posterior distribución. Para ello utilizaremos un equipo
codificador. Al equipo codificador le introducimos la señal de TDT en formato ASI y éste
realizará la conversión a formato IP.

Una vez transformada la señal a IP, queremos distribuirla hacia una serie de centros
determinados, donde están ubicadas las emisoras de TDT, para proceder a la difusión del MUX
de TDT del cliente. Para conseguir esta distribución de la señal de TDT necesitaremos
principalmente dos elementos, switches/routers y radioenlaces IP.

Como vemos en siguiente figura, el codificador está conectado a un equipo de capa 3, este
router será el que reciba la trama Multicast y realizará la distribución de la señal según el
protocolo de conmutación que tenga configurado, no es obligatorio tener un router, también
se podría instalar un switch que admitiera comandos Multicast de capa 3, lo cual permitiría
aún más optimizar nuestros recursos. En nuestro caso utilizaremos switches elevados a capa 3.

A nivel físico, el transporte de la señal desde el origen hasta los diferentes centros emisores se
realiza mediante la utilización de radioenlaces IP. Los radioenlaces IP nos permiten transportar
la información sin alterar los datos que transporta. Se puede decir que a nivel de datosy a
nivel lógico, los radioenlaces son transparentes. Este dato es importante para el correcto
funcionamiento de la tecnología Multicast.

Ilustración 14 - Esquema físico de distribución del transmisor Multicast

Cuando la señal llega hasta el centro emisor, debemos transformar la información para poder
introducirla en la emisora de TDT. Para ello instalaremos equipos decodificadores en cada uno
de los centros emisores. En la entrada de estos equipos se introduce la señal IP que
transportan los radioenlaces. La salida de estos equipos, en formato ASI, se entregará a la
emisora para su posterior difusión.

Ilustración 15 - Esquema físico de distribución de los receptores Multicast
25

Para poder utilizar la tecnología Multicast debemos instalar un último elemento, una serie de
switches repartidos a lo largo de todos los nodos intermedios, tanto si hay difusión como si no
la hay, ya que estos switches nos permitirán distribuir la señal hacia todos los centros que
estén enviando las peticiones de tráfico Multicast.

Si ampliamos con más detalle uno de los centros, observamos que tenemos dos tipos de
conexiones con el switch, conexiones de gestión y conexiones de servicio. Las conexiones de
gestión se utilizarán para gestionar/acceder a los equipos y las conexiones de servicio será por
donde pase todo el tráfico de servicio multiplexado (Servicio Multicast, servicio de operadores,
gestión para poder acceder hasta el centro, etc...). Para realizar todas estas funciones
utilizaremos el mismo switch.

Ilustración 16 - Esquema ampliado de uno de los centros receptores

3.2 Estructura Lógica

Como se han comentado al principio, la distribución de la señal de TDT se pretende hacer
optimizando al máximo los recursos ya existentes en la empresa, por lo que se compartirán
todo el equipamiento que interviene en la distribución IP de la empresa para llevar la
distribución de TDT, servicios para operadores, gestión de centros, etc.…

Todos estos servicios o gestiones de centros tienen rutas y rangos de IP diferentes y no pueden
compartir la misma red, ya que esto podría provocar problemas inesperados entre operadores
y nuestra red.

Para evitar problemas y poder utilizar todos los recursos de nuestra red separaremos cada
servicio o gestión de centros por una Virtual Lan (VLAN), esto nos permitirá separar redes de
forma que sean totalmente independientes aun compartiendo los mismos equipos físicos,
26

aparte nos permitirá distinguir el tráfico y poder trabajar con él con mayor facilidad sin afectar
a otros servicios.

Ilustración 17 - Esquema físico/lógico de VLAN

En esta figura observamos una posible configuración de nuestra red, donde tenemos la gestión
de los centros, servicio de datos de operadores y servicio Multicast. La finalidad es poder
aprovechar los mismos switches para conectar equipos con rangos de IP de subredes
diferentes. A continuación mostramos algunos ejemplos.

Ilustración 18 - Ejemplo esquema lógico de VLAN 800
27

Para la gestión de todos los equipos del centro Y utilizaremos la VLAN 800, según la
configuración mostrada en la figura 3.4 el esquema lógico a nivel 2 sería el siguiente, es decir,
si hiciéramos un ping desde el switch Y (VLAN 800) al switch Z (VLAN 900) la ruta que haría
sería la siguiente.

Ida Y ->X -> S -> H -> S-> X -> Z
Vuelta Z -> X -> S -> H -> S -> X -> Y

Observamos que el ping viaja hasta el router para que enrute el paquete hacia la subred de
gestión del centro Z. Si la VLAN de gestión del switch Z fuera la misma (VLAN 800), la ruta sería
la siguiente, ya que estarían en la misma subred:

Ida Y -> X -> Z
Vuelta Z -> X -> Y

A continuación mostramos el ejemplo de la VLAN 200 por dónde va el servicio Multicast, notar
que esta subred no está conectada al router, esto es así porque no necesitamos llegar a ping a
las IP’s de producción, son IP’s que no se reenrutan a nivel de OSPF ya que no hace falta para
el funcionamiento Multicast. Las IP que nos interesan llegar a ping son las IP’s de gestión, y son
en los puertos dónde estén conectados la interfaz de gestión donde tendremos que configurar
la VLAN apropiada.

Ilustración 19 - Ejemplo esquema lógico de VLAN 200

3.3 Gestión

Como se puede observar en los esquemas, para supervisar los equipos de la red nos
ayudaremos de toda la red de transporte que disponemos. Esta red de gestión aparece
representada en el esquema mediante una nube que se conecta al router del centro A. De esta
manera indicamos que la gestión de todos los equipos de los centros que cuelga del centro A,
es decir, centro B, C, D, E Y F viajará a través de los mismos radioenlaces que va el tráfico
Multicast para aprovechar la infraestructura ya desplegada, evidentemente para que no haya
conflictos con los servicios se configurarán los equipos de capa 2 con diferentes VLAN para que
no compartan la misma subred.

Ilustración 20 - Esquema de gestión

Existen dos maneras de supervisar los equipos de una estación: se puede utilizar el sistema de
gestión en banda o el de gestión fuera de banda.

El sistema de gestión en banda es aquel en el que la gestión de los equipos se transporta junto
con el resto de flujo de datos. En estos casos, si se corta un radioenlace, se pierde la
comunicación con los equipos que se encuentran al otro lado del radioenlace. Utilizamos este
sistema para gestionar la mayoría de centros de nuestra red.

El sistema de gestión fuera de banda es aquel en el que se utiliza un camino diferente para
transportar la gestión de los equipos respecto del flujo de datos. Utilizando este sistema, un
29

radioenlace se puede cortar pero aun así nosotros seguimos teniendo gestión de los equipos
que cuelgan del otro extremo del radioenlace.

En la medida de lo posible, utilizaremos siempre este último sistema. La decisión de utilizar
uno u otro, únicamente dependerá de la existencia previa de los equipo de la red de gestión de
la empresa en ese centro donde se quiere instalar el nuevo radioenlace. Como ya hemos
comentado, se aprovecharán para este proyecto los recursos que la empresa ya dispone
instalados en diferentes centros.

3.4 Valores importantes para el diseño

En el segundo apartado donde se hacía una pequeña introducción a la TDT, se han
mencionado diferentes aspectos que hay que tener en cuenta a la hora de diseñar la red.
Capacidad: El transporte de un MUX (Canal) son 19.9Mbps, esto habrá que tenerlo en cuenta a
la hora de hacer la distribución y escoger los equipos, ya que en caso de ir algún tramo algo
saturado de tráfico debido a la capacidad de las radios, podrían producirse descartes de
paquetes, lo que produciría cortes más grandes a nivel de difusión, en estos casos habría que
aplicar QoS en los switches para garantizar el tráfico de video y que hiciera drops de otros
servicios de datos como puede ser la gestión de los centros.
Retardo de red: Hay que calcular que el retardo de red a nivel IP no supere los 750ms, ya que
si llegase más tarde las emisoras no aceptarían el Transport Stream y se pararían o habría
problema de solape entre los centros emisores. Si no hay ningún problema en los equipos por
los que se transporta la señal no debería llegar en ningún caso a ese valor.
Tamaño de los paquetes ASI: A la hora de configurar todos los codificadores y decodificadores
hay que tener en cuenta que el tamaño del paquete ASI es de 188bytes.

4. Multicast

4.1 Descripción

El Multicast es un método de transporte para enviar información desde un equipo transmisor
(conocido como fuente u origen), a un grupo determinado de equipos receptores. Se conoce
como dirección IP Multicast a la dirección IP que representa a un grupo de equipos receptores,
y no a un equipo receptor individual.

4.2 Elección del método de transmisión

Tradicionalmente, cuandose ha querido transmitir una información a través de una red, se
han utilizado dos modos de funcionamiento. El Unicast y el Broadcast.

Utilizando Unicast, un único equipo transmisor es capaz de enviar una información a otro
equipo receptor. Para ello es preciso que el equipo transmisor conozca la dirección del equipo
receptor.

Por otro lado, utilizando Broadcast, somos capaces de hacer que un único equipo transmisor
envíe la misma información a todos los equipos de una misma red. Para ello utilizamos como
dirección de destino la dirección de Broadcast que poseen todas las redes.

Ahora bien, supongamos que quiero enviar una información a un número determinado de los
potenciales receptores de la red, sin que esa información llegue a los otros equipos receptores
no interesados. ¿Cómo lo hacemos? Hasta este punto, dado que para este caso no podemos
utilizar Broadcast, la única solución posible era enviar esa información mediante Unicast a cada
uno de los receptores interesados. De esta manera, estamos enviando la misma información
una y otra vez por nuestra red a cada uno de los receptores, enviando paquetes con las
diferentes direcciones de destino de los diferentes receptores, y provocando que el tráfico de
datos en nuestra red aumente de manera considerable. ¿Es ésta la única solución posible? Es
aquí donde entra en juego el Multicast.

Mediante la utilización del Multicast lograremos que el equipo transmisor envíe los datos
únicamente una vez, y que a cada equipo receptor le llegue su copia de la información,
optimizando al máximo la capacidad de nuestra red.

El actual estándar que regula la implementación del Multicast sobre IPv4 está descrito en el
documento RFC 1112 (Request For Comments), que data del año 1989. Se han realizado varias
actualizaciones del memorando, pero ninguna ha conseguido hasta el momento la
consideración de nuevo estándar. El último memorando propuesto como estándar, y que
actualmente aún está en estudio por parte de la IETF (Internet Engineering Task Force), es el
RFC 4604.

4.3 Funcionamiento

Para lograr que el equipo transmisor envíe los datos únicamente una vez, y que a cada equipo
receptor le llegue su copia de la información, necesitaremos que nuestra red funcione de una
manera particular:

• El transmisor enviará una única copia de cada paquete IP poniendo en la dirección
IP de destino la dirección del grupo Multicast. Más adelante analizaremos cómo
funcionan estas direcciones de grupo Multicast.

• Los diferentes routers de la red se encargarán de replicar la información cuantas
veces sea necesario para hacerla llegar a todas las ramas de la red donde puedan
haber receptores esperando la información.

• Los equipos receptores deben expresar a los routers su interés en recibir el tráfico
Multicast, mediante el envío de mensajes de control. Gracias a estos mensajes de
control, los routers tendrán localizados a los equipos receptores que esperan
recibir la información, y podrán decidir si deben replicar el tráfico hacia una rama u
otra de la red.

Ilustración 21 - Unicast contra Multicast

4.4 Ventajas y desventajas del Multicast

El modelo de tráfico Multicast ofrece una serie de ventajas y desventajas respecto a la
utilización del modelo de tráfico Unicast. Vamos a ver algunos de los puntos más destacados.

Ventajas:

• Optimiza el rendimiento de la red al enviar una única copia de la información para
todo un grupo de receptores, en lugar de enviar una copia de la información para
cada uno de ellos. Eliminamos una gran cantidad de tráfico redundante.

• Mejora la eficiencia de la red: al reducirse la carga de tráfico en la red, se libera la
carga de trabajo que deben realizar las CPUs (Unidad Central de Procesamiento)
de los diferentes equipos intermedios entre el origen y los diferentes equipos de
destino.

• El momento de la recepción del tráfico Multicast, por parte de los diferentes
equipos receptores del grupo Multicast, es prácticamente simultáneo.

• Se abre un nuevo abanico de aplicaciones imposibles de implementar en el
pasado.

Ilustración 22 - Comparativa de volumen de tráfico Unicast vs Multicast

Desventajas:

• La principal es que está basado en el protocolo de transporte UDP (User Datagram
Protocol), y no en TCP (Transmission Control Protocol). Recordemos que el UDP no
está orientado a conexión y no es fiable, por tanto, no se garantiza la entrega de
los paquetes.

• Debemos esperar drops (pérdidas de paquetes). Al estar basado en UDP, no
debemos esperar que se entreguen a los receptores todos los paquetes enviados.

• No se evita la congestión: al carecer de la ventana de inicio lento del TCP se
pueden provocar congestiones en la red.

• Entregas fuera de la secuencia: cambios en la topología de la red pueden afectar al
orden de entrega de los paquetes en el receptor.

Para evitar que puedan haber pérdidas de paquetes se diseñará una red con capacidad
suficiente para que el switch no tenga que descartar.
4.5 Tipos de aplicaciones

Se define como una aplicación Multicast a cualquier aplicación que transmite y/o recibe de una
dirección IP Multicast. Estas aplicaciones pueden o no utilizar, además, el direccionamiento IP
Unicast.

Lo que diferencia las aplicaciones IP Multicast, son las relaciones que se establecen entre los
transmisores y receptores Multicast. Existen tres categorías generales:

• One-to-Many: en las que un único equipo transmite hacia dos o más equipos
receptores. Estos equipos receptores no tienen por qué ser conocidos por el
transmisor. Típicamente nos vienen a la mente aplicaciones para transmitir audio y
vídeo (como en el caso de la red de transporte que nos ocupa), pero existen
multitud de aplicaciones de este tipo. Desde aquellas que tratan información
dinámica (cabeceras de noticias, actualizaciones meteorológicas, etc.), o
distribución de archivos, hasta aquellas que anuncian actualizaciones de claves o
de software.

• Many-to-Many: en las que varios equipos transmiten hacia la misma dirección IP
Multicast, a la vez que también reciben de ella. En este tipo de aplicaciones, los
receptores son conocidos por los transmisores. Se produce en estos casos una
comunicación bidireccional. Pertenecen a este grupo aplicaciones como las
conferencias multimedia, o los modos multi-jugador disponibles en muchos
videojuegos que permiten jugar en red con aficionados de cualquier parte del
mundo.

• Many-to-One: en las que varios equipos receptores envían información de vuelta
al transmisor mediante tráfico Unicast o Multicast. No existen estándares todavía
para el diseño de este tipo de aplicaciones.

Existe un memorando de la IETF (RFC 3170), que es meramente informativo, y que analiza los
retos y soluciones de las aplicaciones IP Multicast.
4.6 Modelo básico de servicio

El modelo básico de servicio de un grupo IP Multicast se define en el estándar RFC 1112 de la
IETF.

• Cada grupo Multicast se identifica por la dirección IP de clase D que utiliza.

• Los miembros pueden abandonar un grupo o incorporarse a él, indicándoselo al
router más cercano.

• Los routers deben escuchar todas las direcciones IP Multicast, y deben utilizar
protocolos de conmutación para administrar estos grupos.

• Las fuentes o transmisores simplemente comienzan a enviar información sin
ninguna indicación previa.

• El router más cercano a la fuente u origen, es conocido como el first-hop router.
Éste se encargará de reenviar la información entrante hacia el resto de la red. No
existe ningún protocolo de control para regular la comunicación entre el equipo
transmisor y el first-hop router.

• Los receptores comunicarán su pertenencia al grupo IP Multicast al router más
cercano, conocido como el last-hop router. Para llevar a cabo esta tarea, se utiliza
el protocolo IGMP, que analizaremosmás adelante.

• El last-hop router comunicará al resto de la red la existencia de un miembro de ese
grupo IP Multicast.

4.6.1 Direccionamiento Multicast

Podemos analizar el direccionamiento Multicast tanto a nivel de capa 2 de la torre OSI (Open
System Interconnection) como a nivel de capa 3.

4.6.1.1 Direccionamiento Multicast en capa 3

Para identificar a un grupo de trabajo Multicast en capa 3 se utiliza una dirección IP Multicast.
La IANA (Internet Assigned Numbers Authotity) es la agencia de asignación de números de
Internet. Junto con la IETF estableció en su momento que las direcciones de grupo Multicast se
identificarían mediante la utilización de direcciones IP de clase D. El estándar de la IETF que
recoge estas especificaciones viene descrito en la RFC 1112.

Las direcciones IP de clase D son aquellas que están comprendidas en el rango de la dirección
224.0.0.0 hasta la dirección 239.255.255.255. A nivel de bit, todas ellas tienen en común que
los 4 bits de mayor rango (los primeros 4 bits empezando por la izquierda) son 1110:

224.0.0.0 1110 0000.00000000.00000000.00000000
239.255.255.255 1110 1111.11111111.11111111.11111111

Ilustración 23 - Direcciones IP a nivel de bit

Dentro de este rango, existen varios grupos de direcciones reservados para otros usos, que no
se deben utilizar para asignar grupos IP Multicast. Actualmente, estas direcciones reservadas
están debidamente recogidas y reguladas en la RFC 5771. Algunos rangos reservados son:

Rango de direcciones Tamaño Uso
224.0.0.0 - 224.0.0.255 /24 Control para red local
232.0.0.0 -
232.255.255.255
/8 Source-Specific Multicast
233.0.0.0 -
233.255.255.255
/8 GLOP
239.0.0.0 -
239.255.255.255
/8 Administratively Scoped

Ilustración 24 - Rangos de direcciones reservadas

Por poner algún ejemplo, las direcciones 224.0.0.5 y 224.0.0.6 se utilizan en el protocolo de
conmutación Unicast OSPF (Open Shortest Path First). Si utilizáramos estas direcciones para
definir un grupo Multicast, entrarían en conflicto con el protocolo de conmutación Unicast y
seguramente no funcionaría correctamente ninguno de los dos procesos.

4.6.1.2 Direccionamiento Multicast en capa 2

A nivel de capa 2, en una trama Ethernet, se deben especificar las direcciones MAC (Media
Access Control) origen y destino. Si hablamos de direccionamiento Unicast, cada equipo posee
una dirección MAC única. Pero cuando tratamos con direccionamiento Multicast, no existe una
dirección física a la que enviar la trama. ¿Cómo hacerlo?

Un problema similar se tiene cuando se habla de direccionamiento Broadcast. La trama se
envía a todos los elementos de la red, pero en el campo de dirección MAC de destino no
colocamos las direcciones MAC físicas de cada uno de los equipos. En esta situación, se optó
por colocar todos los bits a uno. De esta manera, una dirección MAC FF-FF-FF-FF-FF-FF
representa una dirección de Broadcast.
37

Para resolver el problema del direccionamiento Multicast en una trama Ethernet, se decidió
que todas las direcciones MAC Multicast deben comenzar por 01-00-5E. De esta manera
sabemos que cualquier dirección MAC que sea del tipo 01-00-5E-XX-XX-XX representa una
dirección Multicast.

Para rellenar el resto de la dirección MAC se decidió que la mejor solución era mapear la
dirección Multicast IP de capa 3 y copiarla en la dirección MAC de capa 2. Así pues, se copian
los 23 bits de menor rango de la dirección IP (los primeros 23 bits empezando a contar por la
derecha) en los últimos 23 bits de la dirección MAC.

Ilustración 25 - Mapeo de dirección IP a dirección MAC

De esta manera, la dirección MAC de destino Multicast siempre comenzará por 01-00-5E, se le
añade un bit a cero y luego los 23 últimos bits de la dirección del grupo IP de Multicast.

Si observamos esta fórmula atentamente observaremos un problema. Como hemos obviado
los 9 bits de mayor rango de la dirección IP de Multicast, se puede dar el caso de que
diferentes grupos Multicast con diferentes direcciones IP resulten tener la misma dirección
MAC de Multicast. Esto pasará siempre que coincidan los 23 últimos bits de la dirección IP
Multicast.

Ilustración 26 - Problema con el mapeo de direcciones Multicast
38

Aunque se pierden 9 bits en el proceso de mapeo, sabemos que los 4 primeros bits son
siempre los mismos (1110). Con lo cual, realmente son 5 bits de información los que se están
perdiendo. De estos 5 bits se extraen las 32 posibles direcciones IP Multicast que se mapearán
en una única dirección MAC Multicast.

4.6.2 Transmisores y receptores

La labor del transmisor en nuestra red será únicamente la de originar el flujo de paquetes IP
Multicast y enviarlo hacia el grupo Multicast.

En otros casos es posible configurar el equipo transmisor para que anuncie que va a comenzar
a transmitir o para que tome las acciones pertinentes en función de la información de
feedback que reciba, pero en nuestra red no utilizaremos estas opciones por no considerarlas
necesarias.

No existe ningún protocolo de control en el segmento entre el equipo transmisor y el primer
router de la red, conocido como el first-hop router.

La primera tarea de los equipos receptores es la de mostrar su interés de pertenecer a un
grupo Multicast mediante el envío de paquetes al router más cercano. Una vez que comienzan
a recibir el flujo de datos, han de seguir manteniendo contacto con el router, ya sea para
indicarle que siguen estando interesados en continuar recibiendo el flujo de datos de ese
grupo Multicast, como para comunicarle que han decidido abandonar el grupo.

En el momento en que un equipo receptor comunica a un router que desea abandonar el
grupo Multicast, el router borrará de su lista de distribución al equipo en cuestión y dejará de
reenviar el flujo de datos hacia la dirección del receptor. Esta acción es tan importante o más
que la de incorporarse al grupo, ya que si el equipo no comunica al router su intención de
abandonar el grupo, el router continuará enviando el flujo de datos hacia el receptor.

Imaginemos un momento que el equipo receptor se da de alta consecutivamente en tres o
cuatro grupos Multicast sin indicarle al router que los abandona. El ancho de banda de la
interconexión entre el receptor y el router podría llegar a colapsarse.

Para gestionar la comunicación entre el equipo receptor y su router más cercano, conocido
como last-hop router, se utiliza el protocolo IGMP. Mediante la utilización de este protocolo, el
receptor comunicará al last-hop router su intención de incorporarse o abandonar un grupo
Multicast. Pasemos a analizar el funcionamiento de este protocolo.

4.6.2.1 IGMP versión 1

El protocolo IGMP (Internet Group Management Protocol) es el que utilizan los equipos
receptores Multicast para indicarle a su router más cercano su interés en unirse a un grupo
Multicast determinado.

Este interés se comunica a los routers Multicast, que utilizarán la información para construir o
podar árboles de distribución Multicast y usarlos en algún algoritmo de conmutación
Multicast.

Existen varias versiones de este protocolo. Su primera versión de trabajo, el IGMP versión 1,
viene definido en la RFC 1112 de la IETF. Esta es la estructura de sus paquetes:

Ilustración 27 - Estructura de paquete IGMP v1

En esta primera versión los routers y los equipos receptores intercambian únicamente dos
tipos diferentes de paquetes IGMP: Queries y Reports.

El valor del campo versión es uno. La dirección de grupo es cero cuando el mensaje es del tipo
Query, y contiene la dirección del grupo Multicast correspondiente cuando el mensaje es del
tipo Report.

Los paquetes del tipo Query son los que lanza el router para preguntar a los posibles equipos
receptores de la red si alguno está interesado en recibir el tráfico Multicast. Estos paquetes se
lanzan a la dirección 224.0.0.1 conun tiempo de vida (Time To Live, TTL) igual a 1. En caso de
que hubiera dos o más routers en una misma LAN, sólo uno de ellos será escogido para lanzar
los Queries. Estos mensajes se lanzan periódicamente a intervalos de entre 60 a 120 segundos.

Los paquetes del tipo Report son los que lanzan los equipos receptores Multicast para indicar
que están interesados en recibir el tráfico Multicast de algún grupo en concreto. Este tipo de
paquete suele responder a una petición anterior de un Query por parte del router. Sin
embargo, en el caso de que conectemos un nuevo equipo receptor a la red, inmediatamente
enviará un paquete de Report de manera espontánea, sin esperar a recibir previamente el
paquete tipo Query del router. Este tipo de paquetes se lanzan a la dirección IP Multicast del
grupo en cuestión.

En el caso de que haya más de un equipo receptor en una LAN, sólo un equipo contestará a la
petición del Query. Los demás equipos receptores, al oír que otro equipo ya ha contestado,
cancelarán sus paquetes de Report. Esto se hace así porque al router le basta con saber que
hay un equipo receptor para reenviar el tráfico Multicast hacia la red. No necesita saber el
número exacto de equipos receptores activos dentro del grupo Multicast.

Cuando un equipo receptor quiere abandonar un grupo, lo hace sin ninguna indicación
especial. Simplemente deja de procesar el tráfico Multicast, y deja de contestar a los paquetes
tipo Query de los routers.

Los routers esperan hasta un máximo de tres minutos sin recibir respuesta por parte de algún
equipo receptor antes de cesar en el reenvío del tráfico Multicast. Este sistema para
abandonar un grupo Multicast es muy poco eficiente.

4.6.2.2 IGMP versión 2

La segunda versión del protocolo IGMP es la más utilizada. Viene definida en la RFC 2236 de la
IETF.

Presenta algunas mejoras con respecto a la primera versión del IGMP. La más destacable es
que ahora los equipos receptores, a la hora de abandonar un grupo, avisan al router mediante
el envío de un mensaje específico.

Otra diferencia es que ahora el router es capaz de lanzar mensajes tipo Query para una
dirección de grupo Multicast específica. En la primera versión del IGMP, los Queries se
lanzaban para cualquier dirección IP Multicast.

Además, esta nueva versión de IGMP es compatible con la primera. El formato de sus mensajes
es el siguiente:

Ilustración 28 - Estructura de paquete IGMP v2

Los diferentes valores que puede adquirir el campo Tipo son:

• 0x11 para mensajes Query, ya sean generales o específicos de un grupo.

• 0x12 para mensajes Report versión 1.

• 0x16 para mensajes Report versión 2.

• 0x17 para mensajes Leave Group, para abandonar un grupo.

El campo denominado Tiempo Máximo de Respuesta se utiliza solamente en los mensajes tipo
Query. Especifica el valor, en décimas de segundo, que un equipo receptor debe esperar como
máximo para contestar al mensaje tipo Query. Por defecto su valor es igual a 100 décimas de
segundo.

El campo Dirección de Grupo contiene la dirección del grupo Multicast en los mensajes tipo
Report, Leave Group o en los tipoQuery que se lancen específicamente para un grupo
Multicast. Para los mensajes tipo Query de carácter general su valor es de cero.

El funcionamiento de los Reports espontáneos y de los procesos de Queries y Reports de
carácter general, es igual que en el IGMP versión 1.

En redes con varios routers conectados, el equipo que realizará las peticiones IGMP será el que
tenga la dirección IP más baja. El router guardará información relacionada con la interfaz por
donde le ha llegado la petición, el grupo Multicast al que hace referencia la petición, y la
dirección IP del último equipo que se ha mostrado interesado en unirse a ese grupo Multicast.

Si el router recibe un mensaje de aviso para abandonar un grupo Multicast, compara la IP del
equipo con la que tiene en su lista. Si el equipo es diferente, no hace nada y sigue reenviando
el tráfico Multicast. Si el equipo que abandona el grupo es el que el router tiene en su lista,
lanzará un mensaje tipo Query específico para ese mismo grupo Multicast. Si algún otro equipo
contesta con un Report, el router se apunta su dirección y continúa enviando el tráfico
Multicast. Si ningún equipo responde al router en un tiempo dado, se considera que el equipo
receptor que ha abandonado el grupo Multicast era el último del grupo y el router lo elimina.

Aunque ya hemos comentado que son compatibles, analicemos más a fondo la compatibilidad
entre las dos versiones IGMP:

• Si tenemos equipos receptores con IGMP v2 y routers con IGMP v1.

o Los mensajes tipo Report de versión 2 son ignorados por los routers.

o Los equipos receptores deben enviar Reports versión 1 en respuesta a las
Queries de los routers.

• Si tenemos equipos receptores con IGMP v1 y routers con IGMP v2.

o Los equipos receptores responden igual a Queries versión 1 y 2

o El proceso de abandono se suspende, puesto que los equipos receptores de
versión 1 no realizan esta acción y el router la requiere.

• Si tenemos routers con IGMP v1 y routers con IGMP v2.

o Detección automática de routers versión 1, si existen es necesario configurar
la versión 1 en todos los routers de la subred.

4.6.2.3 IGMP versión 3

Y por el momento, la última versión que existe del IGMP es la versión 3, definida en la RFC
3376 de la IETF. Esta versión permite las mismas acciones que ya aparecían en las versiones 1 y
2 anteriores.

La principal novedad que aporta esta versión respecto a las anteriores es la posibilidad de
unirse a un grupo Multicast especificando la fuente a la que quiere unirse dentro del grupo.
También se define un mensaje de abandono en el que se puede especificar que se quiere dejar
de recibir una fuente de un grupo. Esto permite aislar a saboteadores. Evita que se puedan
producir ataques de denegación de servicio en emisiones Multicast.

De la misma manera, permite lanzar Queries específicas para fuentes dentro de un grupo,
además de las Queries específicas para grupo y de las genéricas. Los mensajes del tipo Report
versión 3 se envían a la dirección 224.0.0.22, donde todos los routers con IGMP v3 están
escuchando.

La elección del router Querier, en caso de que haya más de uno, se realiza igual que en la
versión 2.
42

La estructura de los paquetes es la siguiente:

Ilustración 29 - Estructura de paquete IGMP v3

Al igual que en la versión 2, en la 3 se tienen los mismos tipos de mensajes, sólo que
añadiéndole uno nuevo que es Group and Source Especific Query. Este paquete también posee
los campos de Tiempo de Respuesta Máxima, el Checksum y la dirección del grupo. Los nuevos
campos son Resv (espacio reservado), S (si está activo, actualiza los temporizadores de los
routers), QRV (Querier Robustness Variable) y QQIC (Querier’s Robustness Code). El primero es
para la robustez, el último campo es para especificar los intervalos para mandar solicitudes.
Por último está el número de fuentes y sus respectivas direcciones.

4.6.3 IGMP Snooping

Hasta el momento hemos estado hablando en todo momento de la relación que se establece
entre un equipo receptor Multicast y el router más cercano, el last-hop router. Hemos
analizado el protocolo IGMP que utilizan para comunicarse y el tipo de mensajes que utilizan
para llevar a cabo esa comunicación, incorporarse o abandonar los grupos IP Multicast. Sin
embargo, hemos pasado por alto que en muy pocas ocasiones el equipo receptor estará
directamente conectado al last-hop router. La situación más frecuente que nos vamos a
encontrar es que tengamos algún dispositivo de capa 2, un switch, conectado entre el equipo
receptor Multicast y el last-hop router.

Vamos a estudiar el comportamiento del switch frente al tráfico de tipo Multicast, y
analizaremos si se ajusta al modelo deseado.

El comportamientohabitual de un switch ante el tráfico de tipo Unicast o el de tipo Broadcast
es bastante sencillo. Si conoce la posición de salida de la dirección MAC del equipo
destinatario, reenvía el tráfico hacia el puerto en el que está conectado dicho equipo.

Si no conoce la posición del destinatario, o se trata de una dirección de Broadcast (con todos
los bits a 1), reenvía el tráfico hacia todos los puertos exceptuando el puerto por el que ha
llegado el tráfico.

En un paquete Multicast ya hemos comentado que la dirección MAC del campo del
destinatario no se corresponde con la dirección física de ningún equipo. Por lo tanto, al no
conocer la posición del destinatario, el switch reenviará el tráfico Multicast hacia todos los
puertos de salida.

Este comportamiento que nos funciona tan bien para el tráfico Broadcast, conocido como
flooding o inundación, nos causa una utilización muy ineficiente del ancho de banda de la red.
El tráfico Multicast se está reenviando a segmentos de la red donde ningún equipo receptor se
ha mostrado interesado en recibir ese tráfico Multicast.

Una manera de solucionar este problema sería configurar el switch manualmente, asociando la
dirección MAC Multicast a unas interfaces determinadas, a través de las cuales nos interese
reenviar el tráfico. Esta solución funcionaría correctamente. Sin embargo, todo el tráfico
Multicast está basado en una serie de protocolos de conmutación que nos aseguran una gran
escalabilidad en el diseño de la red. Si empleamos una solución de configuración estática para
todos los switches de la red estamos destrozando la filosofía básica de trabajo de nuestro
diseño. Necesitamos una solución dinámica, que se adapte automáticamente a los cambios
que se produzcan en la red.

La solución que vamos a utilizar en nuestra red, es el IGMP Snooping.

4.6.3.1 Funcionamiento

En líneas generales, el IGMP Snooping es una optimización que permite a un equipo de capa 2,
como es un switch, escuchar las comunicaciones IGMP que circulan por la red, y crearse una
tabla de conmutación para cada grupo Multicast. El IGMP Snooping se realiza internamente en
el switch, y no es un protocolo.
44

Podemos encontrar una descripción completa del IGMP Snooping en el memorando
informativo RFC 4541 de la IETF. Como esta RFC es informativa, podemos encontrar una gran
variedad de equipos switch de diferentes fabricantes, cuyo comportamiento puede variar
significativamente.

Vamos a diferenciar la manera en que el switch procesa el tráfico de paquetes IGMP a la
manera en que trata al tráfico Multicast.

Comencemos por los mensajes de tipo Query del protocolo IGMP, aquellos que lanza el router
para preguntar si algún equipo receptor está interesado en unirse a algún grupo Multicast.
Cuando un Snooping switch recibe este tipo de mensaje, reacciona reenviándolo a través de
todos sus puertos, hacia todos los segmentos de la red donde pueda haber equipos
receptores.

Cuando un Snooping switch recibe por una de sus interfaces un mensaje del tipo Report del
protocolo IGMP, este sólo se reenvía hacia el puerto donde está conectado el router.
Recordemos que este tipo de mensaje es el que utiliza un equipo receptor para indicarle al
router que quiere incorporarse a un determinado grupo Multicast.

Tras procesar el mensaje, el Snooping switch creará una entrada en su tabla de conmutación
CAM (Content Adressable Memory) donde indicará que el equipo que está conectado en una
interfaz concreta, pertenece a un grupo Multicast determinado. De la misma manera, si el
switch detecta un mensaje del tipo Leave Group por parte de un equipo receptor que tiene
intención de abandonar un grupo, borrará la interfaz correspondiente al equipo que abandona
el grupo Multicast de su tabla de conmutación.

También borrará esa misma interfaz de su tabla de conmutación si durante un tiempo
determinado no recibe ningún mensaje de estado tipo Report por parte del equipo receptor
Multicast, aunque este equipo no haya comunicado explícitamente su deseo de abandonar el
grupo Multicast.

A partir del momento en el que un grupo Multicast queda registrado en la tabla de
conmutación CAM, todo el tráfico Multicast perteneciente a ese grupo IP que llegue al
Snooping switch será reenviado solamente hacia las interfaces que tenga incorporadas a su
tabla. Así evitamos que se realice flooding de tráfico Multicast hacia segmentos de la red
donde ningún equipo receptor se ha mostrado interesado en incorporarse al grupo Multicast.

Si al Snooping switch le llega tráfico Multicast perteneciente a un grupo Multicast que aún no
tiene registrado en su tabla de conmutación, al no conocer a los equipos receptores, lo tratará
como si se tratase de tráfico Broadcast y lo reenviará por todos las interfaces excepto aquella
por la cual ha recibido el tráfico.

La RFC 4541 estipula que la tabla de conmutación puede crearse indistintamente utilizando las
direcciones MAC Multicast o las direcciones IP Multicast. Aun así, también aconseja que
siempre que sea posible se deberían utilizar las direcciones IP Multicast. Esto es debido a que
en el proceso de mapeado de las direcciones IP Multicast a las direcciones MAC Multicast, se
pueden crear direcciones de grupo MAC Multicast ambiguas. Recordemos que hasta 32
direcciones IP Multicast diferentes nos darán una misma dirección MAC Multicast.

4.6.3.2 Equipos

No todos los switch pueden trabajar con el IGMP Snooping. Los equipos que trabajan con esta
modalidad están diseñados específicamente para ello. Vamos a intentar explicar el motivo.

La mayoría de los equipos switch que trabajan en capa 2 se componen de los siguientes
componentes:

• Switching engine que realiza la conmutación de paquetes desde la interfaz de entrada
hacia la interfaz de salida, bajo el control de la tabla CAM. Si en la tabla CAM no hay
ninguna entrada que coincida con la dirección MAC de salida, el switching engine
redirige todos los paquetes hacia todas las interfaces del equipo para asegurarse de
que alcanza su destino.

• Tabla CAM (Content Adressable Memory): Cada entrada de la tabla contiene una
dirección MAC de destino y la interfaz del switch a través de la cual los paquetes
alcanzarán dicho destino.

• La CPU se encarga de introducir las entradas en la tabla CAM. Realiza las asociaciones
de las direcciones MAC con las interfaces mediante la observación del tráfico que llega
al switch a través de cada interfaz.

Vamos a ver cómo funcionaría este equipo si realizase el IGMP Snooping. En el ejemplo
siguiente la CPU debe escuchar el tráfico IGMP y realizar las entradas correspondientes en la
tabla CAM.

Cuando el primer equipo (receptor1) lanza un mensaje IGMP Report para unirse al grupo
Multicast 224.1.2.3, el switching engine mira la tabla CAM y ve que no tiene ninguna entrada
para la dirección MAC Multicast de destino equivalente (0100.5e01.0203). Así que redirige el
mensaje hacia todas las interfaces de salida. Entonces la CPU creará una nueva entrada en la
tabla CAM indicando que los futuros paquetes que lleguen al switch apuntando a esa dirección
MAC Multicast, se deben reenviar hacia las interfaces correspondientes al receptor 1, al router
y a la propia CPU, ya que la CPU debe seguir observando si se producen nuevas altas o bajas en
el grupo Multicast.

Ilustración 30 - Procesado del primer mensaje IGMP Report

Cuando un segundo equipo (receptor 4) lanza un mensaje IGMP Report para unirse al grupo
Multicast 224.1.2.3, el switching engine mira la tabla CAM y, de acuerdo con la entrada
anotada para la dirección MAC Multicast de destino equivalente (0100.5e01.0203), reenvía el
mensaje hacia las interfaces 0, 1 y 2. Entonces la CPU añadirá a la entrada de la tabla CAM una
nueva interfaz de salida.

Ilustración 31 - Procesado del segundo mensaje IGMP Report
47

Imaginemos ahora que el Snooping switch comienza a recibir, proveniente del