Embed Size (px)
Citation preview
Universidad Central “Marta Abreu” de Las Villas
Facultad de Ingeniería Eléctrica
Departamento de Telecomunicaciones y Electrónica
TRABAJO DE DIPLOMA
“Voz sobre el Protocolo de Internet en entornos de
transición hacia IPv6”.
Autor: Adriana Gómez Mutis
Tutor: Msc. Adolfo Luis Marín Abreu
Santa Clara
2012
"Año 54 de la Revolución"
Universidad Central “Marta Abreu” de Las Villas
Facultad de Ingeniería Eléctrica
Departamento de Telecomunicaciones y Electrónica
TRABAJO DE DIPLOMA
“Voz sobre el Protocolo de Internet en entornos de
transición hacia IPv6”.
Autor: Adriana Gómez Mutis
Tutor: Msc. Adolfo Luis Marín Abreu [email protected]
Santa Clara
2012
"Año 54 de la Revolución"
Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central
“Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad
de Ingeniería en Automática, autorizando a que el mismo sea utilizado por la Institución,
para los fines que estime conveniente, tanto de forma parcial como total y que además no
podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.
Firma del Autor
Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de
la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un
trabajo de esta envergadura referido a la temática señalada.
Firma del Autor Firma del Jefe de Departamento
donde se defiende el trabajo
Firma del Responsable de
Información Científico-Técnica
i
PENSAMIENTO
“Quien no tenga el valor para sacrificarse. Que al menos tenga el pudor de callarse ante el sacrificio de los demás.” José Martí.
ii
DEDICATORIA
A mis padres por alumbrar mi camino y guiar mis primeros pasos. A mi hermana por incentivarme a continuar el camino. A la revolución por la educación que permitió mi desarrollo profesional.
iii
AGRADECIMIENTOS
A mi novio por estar siempre a mi lado en los días y las
noches de intenso trabajo, por la ayuda incondicional, por la
perseverancia.
A mi tutor por el consejo oportuno, por abrirme las puertas
de sus amplios conocimientos y amabilidad infinita.
A mis compañeras de trabajo pues sin su apoyo no hubiera
podido llegar hasta este punto.
A mis compañeros de aula porque gracias a los lazos que nos
han unido hasta el momento he recorrido este período en el
menor tiempo posible.
A todas aquellas personas que de una forma u otra tuvieron
que ver con mi vida durante estos 6 años.
A todos, Muchas Gracias.
iv
TAREA TÉCNICA
▪ Recopilación y búsqueda exhaustiva de bibliografía; tanto en las bibliotecas, en artículos,
e informaciones disponibles en Internet con el fin de crear una base teórica como punto de
partida para el desarrollo del informe final.
▪ Elaboración de un diagnóstico para conocer la situación real de las infraestructuras de
transporte empleadas en Cuba teniendo en cuenta los niveles 2 y 3 del modelo OSI.
▪ Análisis de los probables escenarios que pueden presentarse en el período de tránsito
hacia IPv6.
▪ Análisis de la VoIP, desde el punto de vista de la QoS; tanto con IPv4 como con IPv6.
Empleo del Protocolo de tiempo real, y de los protocolos de señalización y control de las
llamadas.
▪ Elaboración de un diagnóstico de las arquitecturas empleadas por el proveedor de
servicios públicos para desplegar VoIP. NGN con IPv6.
▪ Selección del modelo de transición que mejor satisfaga los escenarios probables de
migración hacia IPv6 para el soporte de la VoIP con garantías de QoS.
▪ Elaboración del documento de Tesis donde se recogen todos los análisis efectuados y los
resultados que minimicen los impactos sobre la VoIP durante las etapas de transición hacia
IPv6.
Firma del Autor Firma del Tutor
v
RESUMEN
En este trabajo se propone la realización de un escenario de prueba para la transición hacia
IPv6 a partir de las condiciones de Cuba y de ETECSA, para garantizar la QoS de la VoIP.
Se analizan los conceptos y estructura general de la tecnología que por estos días es
utilizada.
Realizamos un diagnóstico de las infraestructuras de nivel de red y de nivel de enlace,
teniendo en cuenta el soporte de IPv6 y los escenarios de tránsito. Se demuestra que
también en Cuba, es una necesidad la transición de IPv4 hacia IPv6.
Se analizan los conceptos, la QoS tanto para las redes IP tradicionales como para la VoIP,
el impacto de transición hacia IPv6 sobre la VoIP y se hace un pequeño análisis del
funcionamiento de la VoIPv6.
Como resultados final de la investigación, se analiza la topología NGN en Cuba, de igual
forma se incluye la relación que existe entre los protocolos NGN y los Codecs con la QoS.
Además efectuamos una propuesta de la NGN cubana con IPv6 teniendo en cuanta las
consideraciones de seguridad.
vi
TABLA DE CONTENIDOS
PENSAMIENTO .....................................................................................................................i
DEDICATORIA .................................................................................................................... ii
AGRADECIMIENTOS........................................................................................................ iii
TAREA TÉCNICA................................................................................................................iv
RESUMEN .............................................................................................................................v
INTRODUCCIÓN..................................................................................................................1
Organización del informe ...................................................................................................5
CAPÍTULO 1. Transición hacia IPv6 .................................................................................6
1.1 Principales tecnologías de nivel 2 desplegadas en ETECSA .................................6
1.1.1 Backbone ATM para el soporte de la Red......................................................6
1.1.2 Backbone MPLS para el soporte de la Red ....................................................8
1.2 IPv4 como protocolo de Nivel de Red empleado en la actualidad .......................10
1.2.1 Nivel de Red de la Arquitectura TCP/IP ......................................................11
1.2.2 Descripción de Funciones.............................................................................11
1.2.3 Formato de cabecera de IPv4........................................................................12
1.2.4 Aspectos negativos del empleo del NAT......................................................13
1.3 Necesidad de transición hacia IPv6 ......................................................................14
1.4 IPv6 como protocolo del Nivel de Red empleado en la actualidad ......................15
1.4.1 Principales mecanismos de transición hacia IPv6 ........................................16
1.4.2 Despliegue de IPv6 sobre enlaces de datos dedicados .................................19
1.4.3 Despliegue de IPv6 sobre un backbone MPLS.............................................20
vii
1.4.4 Despliegue de IPv6 utilizando backbone Dual Stack ...................................26
1.5 Conclusiones del capítulo .....................................................................................26
CAPÍTULO 2. Voz sobre IPv6..........................................................................................28
2.1 Definición de la Voz sobre el Protocolo de Internet.............................................28
2.1.1 Surgimiento de la VoIP.................................................................................28
2.1.2 Motivaciones del empleo de la VoIP............................................................29
2.2 Principales dificultades de IPv4 como soporte de los servicios de voz................30
2.3 Visión general de la QoS en Redes de Telecomunicaciones ................................31
2.3.1 QoS en Redes IP tradicionales......................................................................32
2.4 Nuevos requerimiento de QoS para nuevas aplicaciones .....................................33
2.4.1 QoS para la VoIP ..........................................................................................34
2.4.2 Modelos de Servicio de QoS ........................................................................37
2.4.3 Métodos para controlar la QoS en entornos de VoIP ...................................40
2.4.4 Señalización ..................................................................................................41
2.4.5 Protocolo de Tiempo Real ............................................................................42
2.4.6 Protocolo de Transporte de Tiempo Real .....................................................44
2.4.7 SIP.................................................................................................................45
2.4.8 Megaco / H.248.............................................................................................46
2.4.9 Soporte de IPv6 a la QoS..............................................................................47
2.4.10 Impacto de la Transición hacia IPv6 sobre la VoIP......................................48
2.4.11 Funcionamiento de la VoIPv6 ......................................................................49
2.5 Conclusiones del capítulo .....................................................................................50
CAPÍTULO 3. Voz sobre IPv6..........................................................................................51
3.1 Topología de NGN en Cuba .................................................................................51
viii
3.1.1 Señalización empleada en el caso de la NGN cubana ..................................55
3.2 Relación de los Protocolos NGN y la QoS ...........................................................57
3.3 Codificadores (CODECS).....................................................................................59
3.4 Establecimiento de una llamada VoIP en el caso de la NGN cubana...................60
3.5 Propuesta de arquitectura de NGN con IPv6 ........................................................61
3.6 Consideraciones de Seguridad ..............................................................................63
3.7 Conclusiones del capitulo .....................................................................................64
CONCLUSIONES Y RECOMENDACIONES ...................................................................65
Conclusiones.....................................................................................................................65
Recomendaciones .............................................................................................................66
REFERENCIAS BIBLIOGRÁFICAS .................................................................................67
ACRONIMOS ......................................................................................................................72
GLOSARIOS........................................................................................................................77
ANEXOS ..............................................................................................................................81
TABLA DE ILUSTRACIONES ........................................................................................106
INTRODUCCIÓN 1
INTRODUCCIÓN
En la actualidad no se abordan con profundidad; como parte de los programas de estudio de
la carrera de Ingeniería en Telecomunicaciones y Electrónica, el protocolo IPv6 (Versión 6
del Protocolo de Internet, por sus siglas en inglés). , y su impacto sobre las principales
aplicaciones y servicios de telecomunicaciones.
Sin lugar a dudas IP (Protocolo de Internet, por sus siglas en inglés) es la base de las
comunicaciones en la actualidad; a partir de las opciones de convergencia de servicios de
diferentes naturalezas (voz, vídeo y datos) en una misma red, así como la posibilidad de
interconectar equipos disímiles en forma transparente. [1]
Este escenario implica que la tasa de crecimiento actual en Internet, esté sobrepasando con
creces, las expectativas y propósitos con que se diseñó originalmente ARPANET (Red de
Agencia de Proyectos de Investigación Avanzada, por sus siglas en inglés) entre los años
60s y 70s, que luego de sucesivas evoluciones, derivaron en la Internet actual. [1] Su
principal objetivo teórico era crear una arquitectura de red sólida y robusta que incluso en
caso de falla de alguna estación, pudiera trabajar con las computadoras y enlaces restantes.
[2]
Durante la primera década de operación de la Internet basada en TCP/IP (Protocolo de
Control de Transmisión sobre el Protocolo de Internet, por sus siglas en inglés), a fines de
los 80s, se evidenció la necesidad de desarrollar métodos para emplear racionalmente el
espacio de direcciones, y de esta manera alargar la vida de IPv4 (Versión 4 del Protocolo de
Internet, por sus siglas en inglés). [1]
La IETF (Grupo Especial sobre Ingeniería de Internet, por sus siglas en inglés) a principio
de los 90, comenzó a debatir estrategias para resolver el tema del agotamiento de las
direcciones IP y el problema del crecimiento de la tabla de enrutamiento. [2]
Para ello, en noviembre de 1991 se formó el grupo de trabajo ROAD (Enrutamiento y
Direccionamiento, por sus siglas en ingles), que propuso la utilización de varios
INTRODUCCIÓN 2
mecanismos como por ejemplo: CIDR (Classless Inter-domain Routing, por sus siglas en
inglés), y NAT (Network Address Translation, por sus siglas en inglés). [2] Aunque estas
soluciones han disminuido la demanda de direcciones IPv4, no han sido suficientes para
resolver los problemas derivados del crecimiento de Internet. Estos mecanismos
permitieron que hubiera más tiempo para desarrollar una nueva versión del protocolo IP,
una versión que se basara en los principios que contribuyeron al éxito de IPv4 pero que
también fuese capaz de superar las fallas que se detectaron. Fue así que en diciembre de
1993, la IETF formalizó las investigaciones sobre la nueva versión del protocolo IP, entre
los aspectos que debían ser abordados al elaborar la nueva versión del protocolo IP estaban:
escalabilidad; seguridad; configuración y administración de redes; soporte para QoS
(Calidad de Servicio, por sus siglas en inglés); movilidad y políticas de enrutamiento y
transición. [2]
Después de varios estudios e investigaciones realizados se determinó que la nueva versión
del Protocolo de Internet pasaría oficialmente a llamarse IPv6. [2]
Las especificaciones de IPv6 fueron presentadas inicialmente en diciembre de 1995, pero
en diciembre de 1998 estas fueron reemplazadas y entre los principales cambios con
respecto a IPv4 se destacan: mayor capacidad de direccionamiento; simplificación del
formato del encabezado; soporte para encabezados de extensión; capacidad de identificar
flujos de datos y soporte para autenticación y privacidad. Además, IPv6 también modificó
el tratamiento de la fragmentación de los paquetes que pasó a ser realizada solo en el
origen; permitió el uso de conexiones extremo-extremo, principio que se había roto con
IPv4 debido al uso generalizado de las NAT; aportó recursos que facilitan la configuración
de redes, entre otros aspectos que fueron mejorados en relación con IPv4. [2]
Debido al crecimiento de los dispositivos que emplean la arquitectura TCP/IP se ha hecho
inaplazable la transición hacia IPv6. Los operadores de telecomunicaciones tradicionales
han ofertado servicios de voz con QoS garantizada; sin embargo al incorporar la VoIP (Voz
sobre el Protocolo de Internet, por sus siglas en inglés) en los actuales escenarios de
comunicaciones unificadas, han concentrado sus mayores esfuerzos en el tratamiento de la
QoS, debido al impacto que tiene la esta sobre las aplicaciones de “tiempo real”. En la
actualidad existe una tendencia marcada al empleo de las comunicaciones basadas en el
INTRODUCCIÓN 3
protocolo IP, que se pone de manifiesto en los proveedores públicos por el acercamiento
hacia las arquitecturas NGN (Redes de Nueva Generación, por sus siglas en inglés) para
implementar los servicios de voz basados en VoIP. IP enfrenta el problema de que no
garantiza la QoS de manera intrínseca; sumado a ello la VoIP implementada en el diseño
NGN de Cuba está soportada por IPv4; protocolo que sufre un agotamiento inminente de
sus reservas de direcciones, y por tanto se hace inaplazable para el mundo, y para Cuba
transitar hacia IPv6; previéndose además, un período de coexistencia de ambas versiones.
Todos estos aspectos en que se introduce la VoIP en el sector público deben ser
cuidadosamente analizados desde el punto de vista de la QoS; por lo que debemos
preguntarnos como disminuir el impacto sobre la QoS, y el comportamiento general de la
VoIP en los probables escenarios de despliegue de IPv6.
Cuba no es una excepción respecto a la necesidad de introducir IPv6. En este sentido en el
2003, se comienzan a realizar acciones con vistas a llamar la atención de las autoridades
correspondientes en el país, acerca de la importancia del protocolo IPv6 para el futuro
desarrollo de las comunicaciones. [1]
Para enfrentar esta tarea se constituye en diciembre del 2004 la Fuerza de Trabajo IPv6,
encabezada por el ing. Jesús Martínez Alonso y un grupo de destacados investigadores
cubanos. [3]
Es importante señalar, que Cuba cuenta con varios bloques de direcciones IPv6, en manos
de los proveedores públicos de Internet y de algunos proveedores privados (según la
estructuración de estos servicios en el país). [1]
También se constituyó en el 2006 el Grupo de Trabajo de IPv6 para América Latina y el
Caribe cuyo objetivo principal es fomentar la adopción de IPv6 en la región. [3]
Aunque la mayor parte del diseño de IPv6, así como de las implementaciones de los
fabricantes, se han llevado a cabo en Estados Unidos, no solía darse en este país a IPv6 la
misma importancia comercial que en otras partes del mundo, sin embargo, en diciembre de
2001 se puso en marcha la iniciativa industrial en favor del establecimiento de un Grupo de
Trabajo IPv6 para América del Norte, lo cual demuestra que existe una presión creciente
para mejorar Internet; y ya para 2006 reconoció como elemento vital para recuperar el
liderazgo científico y económico efectuar una transición a mediano plazo hacia IPv6. [3]
INTRODUCCIÓN 4
El mundo hoy se enfrenta a la inminente transición de IPv4 a IPv6, debido al agotamiento
de los recursos de direcciones IPv4. [4] Además los operadores de telecomunicaciones que
tradicionalmente han ofertado el servicio de voz empleando Multiplexación por División de
Tiempo (TDM, por sus siglas en inglés) [5], han adoptado arquitecturas de Redes de Nueva
Generación (NGN, por sus siglas en inglés) [6], para el soporte de la VoIP [7] en actuales
escenarios de redes de datos basados en el conjunto de protocolos TCP/IP. [8] La industria
ha estado retirando el soporte a las tecnologías basadas en TDM [9] asumiendo la VoIP con
sus ventajas de ahorro de recursos [10]; y con los impactos que genera el tratamiento de la
QoS [11] en las redes IP (Protocolo de Internet, por sus siglas en inglés).[12] Las
proyecciones de crecimiento del tráfico de VoIP en el mundo hasta el 2015 van desde un
2% hasta un 46%.[13] Sumado a todos estos factores la QoS está enfrentando la transición
hacia IPv6 y por ello se justifica efectuando un análisis de los probables escenarios de
transición con el presente trabajo.
ETECSA necesita efectuar la transición hacia IPv6, para integrarse a las nuevas
aplicaciones y servicios que integra este nuevo protocolo, garantizando de esta forma el
desarrollo futuro de las redes de datos, y del país en general; sin embargo el personal
especializado no cuenta con las políticas; ni con estrategias bien definidas para disminuir
los riesgos de realizar inversiones en equipamientos no escalables, o no compatibles con
IPv6. [3] Es por ello que con el presente trabajo nos hemos trazado como objetivo general
proponer un escenario de transición hacia IPv6 a partir de las condiciones técnicas de Cuba,
para garantizar un comportamiento adecuado en cuanto a QoS de la VoIP; dentro de los
objetivos específicos tenemos:
1. Diagnosticar las infraestructuras del nivel de red y del nivel de enlace que se
encuentran en funcionamiento en Cuba, teniendo en cuenta el soporte de IPv6; y los
probables escenarios de tránsito.
2. Analizar los impactos de la transición hacia IPv6 y la QoS sobre la VoIPv6 (Voz
sobre la IPv6, por sus siglas en inglés).
3. Proponer un escenario de transición de IPv6 que provee un adecuado tratamiento de
la QoS a los servicios públicos enfocados en la NGN cubana.
INTRODUCCIÓN 5
Con este proyecto pretendemos contribuir a la implementación de la VoIP, desde el punto
de vista de un proveedor público de telecomunicaciones, con los estándares actuales de
NGN; y teniendo en cuenta los impactos sobre la QoS que implica la transición hacia IPv6,
y su coexistencia con IPv4.
Organización del informe
El informe está estructurado por tres capítulos que abordan las tareas de investigación
definidas. Además se reflejan las conclusiones fundamentales, los acrónimos, el glosario,
las referencias bibliográficas y los anexos.
El primer capítulo estará basado en una amplia revisión bibliográfica del estado del arte de
las comunicaciones unificadas, en el mundo, en Cuba, y en ETECSA. Además se realizarán
diagnósticos de la situación real de las infraestructuras del nivel de red y de enlace; que se
encuentran en funcionamiento. Y por último se discutirán los probables escenarios de
transición de IPv4 hacia IPv6.
En el segundo capítulo caracterizaremos la VoIP, y analizaremos los aspectos más
relevantes de QoS tanto para IPv4, como para IPV6. Además abordaremos los principales
protocolos de control, señalización, y establecimiento de las llamadas, así como su relación
con la QoS.
En el tercer capítulo se analizarán los escenarios de NGN, empleando IPv6, a partir de las
principales recomendaciones internacionales, y los estándares existentes; para diseñar un
modelo que responda a la arquitectura adoptada en Cuba para el despliegue de VoIP sobre
IPv6 con garantías de QoS.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 6
CAPÍTULO 1. Transición hacia IPv6
En el presente capítulo trataremos la necesidad de transitar hacia IPv6; se analizarán los
principales mecanismos de transición; y realizaremos un diagnóstico sobre las principales
infraestructuras de nivel 2, desplegadas en el Proveedor de Servicio (PS); enfocándonos en
el futuro de estos backbones, de cara al soporte que necesariamente deben ofrecerle al nivel
de red implementado con IPv6.
1.1 Principales tecnologías de nivel 2 desplegadas en ETECSA
Existen varias tecnologías desplegadas en Cuba en el nivel 2 de la Arquitectura TCP/IP.
Entre ellas podemos citar a X.25 [14] como una de las más antiguas de todas, cuya
tendencia es a concentrarse en diferentes puntos de país, para concentrar a los clientes que
no han sido capaces de transitar hacia tecnologías con mejores soportes de ancho de banda;
y mejores adaptaciones a las aplicaciones modernas de redes. La tendencia de esta red es a
desaparecer de las redes cubanas; en primer lugar por el poco soporte que ofrecen a las
aplicaciones y servicios de la actualidad; y en segundo lugar debido a que la industria
mundial retiró todo el soporte técnico, y logístico a este tipo de redes. [9]. Además en el
nivel 2 existe una arquitectura ATM/FR que soporta una buena parte de los servicios
actuales, sin embargo las puertas de esta red están prácticamente agotadas; y la industria
también provee una atención y crecimientos limitados a corto plazo [9]; debido a esto el
backbone IP/MPLS instalado en Cuba desde el 2007, debe asumir el rol principal dentro de
las tecnologías de nivel 2; destinadas a trasportar el resto de los protocolos de capas
superiores.
1.1.1 Backbone ATM para el soporte de la Red
El modo de transferencia asincrónica, es una tecnología que ofrece un servicio orientado a
conexión y trabaja en el Nivel 2 del Modelo OSI (Open System Interconection, por sus
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 7
siglas en inglés), esta tecnología emplea la conmutación de celdas (paquetes) de longitud
fija y circuitos virtuales (VC, por sus siglas en inglés) para el transporte de datos, voz y
vídeo de manera rápida, como podemos apreciar en la figura #1. ATM combina los
beneficios de la conmutación de circuitos (retardo constante de transmisión y capacidad
garantizada) con los beneficios de la conmutación de paquetes (flexibilidad y eficiencia en
el uso del ancho de banda). [15]
Figura #1 ATM en el transporte de voz, datos y vídeo. [15]
ATM fue diseñada como una red de banda ancha para redes publicas, capaz de soportar
varias clases de tráfico sobre una misma conexión física, basado en los estándares de la
ITU-T [16] para la Red Digital de Servicios de Banda Ancha (B-ISDN, por sus siglas en
inglés) [17], originalmente concebida como una tecnología para la transferencia rápida de
servicios multimedia sobre redes públicas. [15]
Cuba cuenta con un backbone ATM que está compuesto por conmutadores Alcatel; que
usan como soporte enlaces de FO (Fibra Óptica, por sus siglas en inglés). En la Ciudad de
la Habana existe un anillo a 622 Mbps soportando por la plataforma de conmutación y
enrutamiento formada por los equipos 7670 y 7470, este anillo tiene conexiones a 155
Mbps con las principales provincias del país que cuentan con conmutadores 7470 y
conexiones a 34 Mbps con el resto de las provincias que tienen conmutadores 7270. La red
de acceso al backbone esta formada por multiplexores 3600 y 3630, también de tecnología
Alcatel; que posibilitan una gestión integrada y centralizada de toda la red, en algunos de
los cuales se incluyen tarjetas que proporcionan capacidad de conmutación FR (Frame
Relay, por sus siglas en inglés). [3]
Los servicios que se ofrecen están fundamentalmente relacionados con la interconexión de
redes corporativas, para formar redes privadas virtuales sobre FR, y acceso a los ISP, a
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 8
velocidades que van desde los 64Kbps hasta los 2 Mbps utilizando técnicas xDSL (x-Líneas
de Subscriptor Digital, por sus siglas en inglés) para el acceso.[3]
Los ISP utilizan también FR para interconectar sus puntos de presencia a los largo del país
para lograr el acceso al NAP (Network Access Point, pro sus siglas en inglés) que se
encuentra en Ciudad de la Habana.[3]
El desarrollo de ATM se inclinó hacia la necesidad de una tecnología capaz de transportar
múltiples protocolos; que aprovechara las principales ventajas logradas hasta la fecha.
ATM es capaz de transportar IPv6, sin embargo introduce dificultades a algunas de las
nuevas funcionalidades que hacen de IPv6 un protocolo versátil de cara al futuro; por
ejemplo ATM impone dificultades al soporte nativo de la autoconfiguración de IPv6. [18]
Además existen problemas de escalabilidad en una red IP sobre ATM [15]; que desviaron
el centro de atención hacia el desarrollo de una nueva visión de red.
1.1.2 Backbone MPLS para el soporte de la Red
La conmutación de etiquetas de múltiples protocolos (MPLS, por sus siglas en inglés) es
una tecnología relativamente nueva que está siendo utilizada en las redes de núcleo,
soportando la convergencia de redes de datos y de voz. El backbone MPLS es capaz de
manejar interfaces que soportan altas velocidades; y por tanto son capaces de evacuar
volúmenes de tráfico muy elevados.
MPLS mejora los servicios que pueden ser proporcionados por las redes IP, ofreciendo
Ingeniería de Tráfico (TE, por sus siglas en inglés), garantizando QoS, y garantizando
servicios VPN. [14]
Cuba cuenta en la actualidad con un backbone MPLS soportado por la SDH (Synchronous
Digital Hierarchy, por sus siglas en inglés) Nacional; y la Fibra Óptica Nacional. Este
backbone forma parte del desarrollo creciente de las redes de telecomunicaciones de
nuestro país; y está llamado a ser el principal soporte de datos del país, para afrontar los
proyectos de conectividad social, e informatización de nuestra sociedad. Además tiene la
responsabilidad de ser el soporte para la introducción masiva de las redes de nueva
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 9
generación, en Cuba, y todos los servicios de valor agregado que introduce esta visión de
red.
La arquitectura general del backbone IP/MPLS puede apreciarse en la figura #17 del
Anexo #1; donde existen varios enrutadores de núcleo a lo largo de todo el país, con la
redundancia adecuada tanto física, como lógica; enlazados a enrutadores de bordes
ubicados en cada provincia, a los cuales se conectan los equipos de acceso mediante
diferentes interfaces. Debe notarse que toda la configuración, y explotación de este nuevo
backbone, se basa en el protocolo IPv4; y todos los servicios que se han comercializado
hasta el presente también están soportados con IPv4; sin embargo durante la investigación
pudimos comprobar que los enrutadores de borde manejan tanto IPv4, como IPv6; lo cual
constituye un elemento de suma importancia a tener en cuenta en la propuesta de las
estrategias de transición.
Esta red MPLS tiene alcance nacional, y se integrara en la primera fase con el backbone
ATM que fue descrito en el epígrafe anterior; para ellos se crearan pasarelas entre los
diferentes diseños de red, y la red MPLS. Para el acceso a esta red se emplean los métodos
tradicionales, y las pasarelas entre redes; y los DSLAM de acceso; con la utilización de
CPE (Costumer Premise Equipment, por sus siglas en inglés), ADSL (Asymetric Digital
Subscriber Line, por sus siglas en inglés), o SHDSL (Symmetric High Speed Digital
Subscriber Line, por sus siglas en inglés). En la figura siguiente podemos apreciar un
escenario típico de integración entre clientes de la Red ATM, y clientes de la Red
MPLS.[3]
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 10
Figura #2 Integración entre la Red ATM/FR y la Red IP/MPLS. [3]
El futuro del backbone cubano es continuar con la tendencia hacia IP/MPLS que brinda
capacidades de banda ancho, QoS, soporta la totalidad de protocolos, incluyendo IPv6, la
ingeniería de tráfico, además es un escenario ideal para las redes multiservicios; donde las
nuevas aplicaciones como IPTv, videoconferencia, VoIP, vídeo bajo demanda, e-learning,
aplicaciones de gobierno y salud en línea, encuentran un ambiente natural. [14]
1.2 IPv4 como protocolo de Nivel de Red empleado en la actualidad
Protocolo de Internet versión 4 (IPv4): No es más que la cuarta versión en el desarrollo del
Protocolo de Internet (IP) y la primera versión del protocolo que fue ampliamente
desplegada. IPv4 sigue siendo el protocolo de Internet de capa de red más
generalizado.[19] Este protocolo se describe en la RFC 791. [20]
IPv4 es un protocolo no orientado a conexión, diseñado para su uso sobre redes de
paquetes conmutados de capa de enlace (por ejemplo Ethernet [21]). Funciona en un
modelo de entrega según el “mejor esfuerzo”, ya que no garantiza la entrega, ni asegura la
secuencia adecuada ni evita las entregas duplicadas. Estos aspectos, incluyendo la
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 11
integridad de los datos, son tratados por un protocolo de capa superior denominado TCP
(Transmission Control Protocol, por sus siglas en inglés). [19]
1.2.1 Nivel de Red de la Arquitectura TCP/IP
La Arquitectura TCP/IP está compuesta por 5 niveles bien definidos que tienen su analogía
con el modelo OSI, de 7 capas o niveles. En la figura #18 del Anexo #2 se ilustran ambas
arquitecturas.
De abajo hacia arriba aparece la primera capa que contiene los niveles 1 y 2, se refiere a las
Interfaces de red, y en la capa que le sigue correspondiente al nivel 3, se encuentra IP. La
capa 4 se encarga del transporte, y el resto de las capas son resumidas por la capa de
aplicación.
El nivel de red es el encargado del enrutamiento de los paquetes dentro de la red. En esta
capa la unidad de información ya no es la trama propia del nivel de enlace de datos, sino el
paquete o en su caso el datagrama. Es empleado por su diseño y funcionalidades por
servicios “no orientados a conexión”. Se lleva a cabo el enrutamiento de los paquetes o
datagramas. Es decir, el direccionamiento de las aplicaciones, y dispositivos; también
conocido como direccionamiento lógico.
Protocolos como IP, X.25, y dispositivos como enrutadores, conmutadores X.25, PAD se
asocian a este nivel.[8]
1.2.2 Descripción de Funciones
La función o propósito del Protocolo de Internet consiste en enrrutar, y enviar datagramas a
través de un conjunto de redes interconectadas. Esto se consigue pasando los datagramas
desde un módulo de Internet a otro hasta que se alcanza el destino deseado. Los módulos
de Internet residen en los hosts y las pasarelas en los enrutadores de paquetes IP. Los
datagramas son encaminados desde un módulo de Internet a otro a través de redes
individuales basándose en la interpretación de las direcciones IP.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 12
En el enrutamiento de mensajes desde un módulo de Internet a otro, los datagramas pueden
necesitar atravesar una red cuyo tamaño máximo de paquete es menor que el tamaño del
datagrama. Para salvar esta dificultad se proporciona un mecanismo de fragmentación en el
Protocolo de Internet.[20]
1.2.3 Formato de cabecera de IPv4
En una red IP absolutamente toda la información viaja en datagramas IP. Esto incluye
tanto la intercambiada a nivel de transporte por TCP (Transmission Control Protocol, por
sus siglas en inglés) y UDP (User Datagram Protocol, por sus siglas en inglés) como
cualquier información de control que tenga que intercambiarse, por ejemplo para
enrutamiento dinámico, mensajes de error, etc.
El datagrama IP tiene dos partes: cabecera y texto; la cabecera tiene una parte fija de 20
bytes y una opcional de entre 0 y 40 bytes. La longitud total de la cabecera siempre es
múltiplo de 4; esto garantiza un proceso eficiente por parte de equipos (host o enrutadores)
cuya arquitectura optimiza el acceso a direcciones de memoria que estén en frontera de 32
bits. En la figura #19 del Anexo #3 se muestran los principales campos del datagrama. [22]
IPv4 ha resuelto la mayoría de los retos del nivel de red, incluyendo el agotamiento de
direcciones del protocolo, la seguridad, la movilidad entre otros. No obstante IPv6 se ha
venido desarrollando desde hace algunas décadas, y en la actualidad ya es un protocolo
maduro, que ha pasado por varias fases de experimentación, y se encuentra en
funcionamiento junto a su homólogo IPv4. Esto no quiere decir que IPv4 va a desaparecer
de un día para otro, sino que pronostica una convivencia medianamente larga para ambos
protocolos; entre los cuales deben implementarse diversos mecanismos de interoperabilidad
con el objetivo de que el período de transición no constituya un obstáculo ni para los
usuarios, ni para los esquemas de servicios, y negocios que en la actualidad no pueden
prescindir del funcionamiento de las redes de telecomunicaciones.
El agotamiento de las direcciones IPv4 es uno de los problemas actuales que estamos
enfrentando, esto compromete el crecimiento, y el desempeño de Internet, y por tanto el
soporte a las nuevas aplicaciones, y servicios que exige una sociedad ubicua. El proceso de
transición afecta tanto los elementos que componen la NGN, como todos los equipos de
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 13
acceso, la lógica, y el software de aplicación. La introducción, y despliegue de IPv6
solucionará la escasez de direcciones, y garantizará el crecimiento de Internet. [23]
1.2.4 Aspectos negativos del empleo del NAT
Desafortunadamente, los métodos empleados para la conservación de las direcciones IPv4
introducen efectos indeseados que perjudican el desempeño, e incrementan los costos de
operación. Existe una tendencia muy marcada en las redes cubanas al empleo del NAT;
esto se debe fundamentalmente a que el NAT resuelve la escasez de direcciones de una
manera sencilla para los clientes; y también provee una seguridad satisfactoria, para las
redes que operan en el entorno cliente-servidor; sin embargo los inconvenientes que el
NAT trae consigo deben ser seriamente considerados.
A continuación se detallan algunos elementos que corroboran los efectos negativos del
NAT [24]:
• Configurar NAT para que sea capaz de soportar la administración remota trae consigo
altos costos de operación.
• La falta de transparencia que por naturaleza introduce el NAT, dificulta enormemente
efectuar diagnósticos fiables de los problemas que a menudo se presentan.
• Cuando se emplea NAT, la manipulación dinámica que se efectúa sobre la cabecera de los
paquetes IP, necesaria para establecer el enlace entre la red privada, y la red pública;
dificulta enormemente la seguridad IPSec (Internet Protocol Security, por sus siglas en
inglés) extremo-extremo. Esto se debe, principalmente; a que la modificación que NAT le
hace a la cabecera del paquete, induce a rechazar los paquetes durante los controles que
establece IPSec.
• NAT degrada el desempeño de la red, lo cual es especialmente importante para las
aplicaciones sensibles a los tiempos de tránsito.
• NAT es un obstáculo para las aplicaciones “peer to peer”, para las cuales fue diseñado
Internet desde sus inicios; y en la actualidad reaparecen como aplicaciones claves, tanto
para los usuarios finales, como para los negocios. Para estas aplicaciones es necesario
conocer las direcciones de los hosts implicados en las redes privadas, lo cual implica
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 14
mecanismos complejos relacionados con la aplicación, para localizar la dirección del host
final.
• El comportamiento de los NATs varía dramáticamente desde una implementación a otra.
Consecuentemente, resulta muy difícil para las aplicaciones predecir o descubrir el
comportamiento preciso de uno o varios NATs que pueden existir en la trayectoria de los
datos de una aplicación.[25]
• Los NATs no tienen recuperación ante fallos de manera inherente. Cuando el NAT falla;
todo el tráfico que pasa a través de este se detiene.[25]
• Los NATs se encuentran en la trayectoria de los datos, y por tanto intentan procesar cada
paquete. Obviamente para aumentar el ancho de banda, es necesario mejorar la capacidad
de procesamiento del NAT.[25]
• Las aplicaciones que trabajan con dispositivos identificados o que identifican dispositivos
como el SNMP (Simple Network Management Protocol, por sus siglas en inglés) y los DNS
(Domain Name System, por sus siglas en inglés) requieren de una cuidadosa configuración
cuando operan a través de un NAT.[25]
1.3 Necesidad de transición hacia IPv6
El crecimiento exponencial de Internet, y la convergencia generalizada hacia la arquitectura
TCP/IP, han provocado el agotamiento de la reserva de direcciones IPv4. Esta situación
compromete el crecimiento, y el desempeño de Internet, y por tanto el soporte a las nuevas
aplicaciones, y servicios que exige una sociedad ubicua. Las técnicas actuales para extender
la vida de IPv4, disminuyen el desempeño de las redes; y hacen más compleja la aplicación
de medidas de seguridad extremo-extremo; así como la seguridad cuando un dispositivo se
traslada de su red original a otra red desconocida. La introducción, y despliegue de IPv6
solucionará la escasez de direcciones, y garantizará el crecimiento de Internet. Además este
nuevo protocolo se ha diseñado conscientemente para que sea más seguro, y para que
soporte de manera natural la movilidad, y la capacidad de gestionar nuevas direcciones
donde quiera que un dispositivo lo solicite. (Stateless Autoconfiguration). [26] La
transición hacia IPv6 ha superado la etapa de pruebas, y se hace impostergable su adopción;
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 15
sin embargo la falta de compatibilidad de los dispositivos, y de la generalidad de las
aplicaciones actuales, unido a la falta de contenido en Internet con IPv6; han retrasado la
adopción de IPv6.[27] Resulta evidente que existirá un período de coexistencia de IPv4, e
IPv6; que será más extenso de lo que realmente conviene a Internet, y a sus usuarios. En
este complejo escenario de coexistencia estará envuelta la QoS en la implementación de
VoIP.
IPv6 ofrece el potencial de la estabilidad, y accesibilidad para la interconexión extremo-
extremo de redes telemáticas; además mejora las principales dificultades de su predecesor
IPv4, extiende sus funcionalidades con nuevas capacidades; y viene a solucionar la
principal limitación incrementando el espacio de direcciones IP en aproximadamente 79
octillones (79x10^27). [23]
1.4 IPv6 como protocolo del Nivel de Red empleado en la actualidad
IP versión 6 (IPv6) es la nueva versión del Protocolo de Internet, está diseñada como
sucesora de IPv4 [20]. Los principales cambios del nuevo protocolo recaen sobre las
siguientes características: [28]
• Expansión de las capacidades del direccionamiento. (De 32 a 128 bits , lo que permite
el manejo de un número mayor de jerarquías en el direccionamiento, permite una auto-
configuración más simple [10])
• Formato de la cabecera más simple, ver Figura #20 del Anexo #4. (Se reducen los
costos del procesamiento de los paquetes, y se optimiza el ancho de banda debido a que
la cabecera es más simple [10])
• Soporte mejorado para manejar las extensiones, y las opciones. (Las opciones son
manejadas fuera de la cabecera, lo que optimiza el proceso de envío [10])
• Capacidad de manejar flujos de datos etiquetados. (Permite etiquetar paquetes
pertenecientes al mismo flujo de tráfico, que necesitan a petición del emisor un
tratamiento diferenciado en cuanto a QoS [10])
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 16
• Capacidad de manejar seguridad en el nivel de red. (La seguridad es manejada como
una extensión de la cabecera [10])
1.4.1 Principales mecanismos de transición hacia IPv6
Los principales mecanismos diseñados para llevar a cabo la transición proponen comenzar
desde los bordes de la red hacia el núcleo, lo que implica transportar trafico IPv6 a través
de la red IPv4, permitiendo que los dominios aislados que funcionan como IPv6 se
comuniquen entre sí, sin tener que efectuar una transición completa hacia IPv6 nativo. En
este contexto es posible emplear IPv4 e IPv6 a lo largo de toda la red, desde todos los
bordes a través del núcleo, o emplear la traducción entre IPv4 e IPv6 para permitirle a los
hosts que se comunican con un protocolo, que se comuniquen de manera transparente con
hosts que se comunican con el otro.[29]
Los cuatro mecanismos básicos se muestran a continuación [29]:
• Desplegar IPv6 sobre túneles IPv4: Este túnel encapsula el tráfico IPv6 dentro de los
paquetes IPv4, y se usan principalmente para la comunicación entre sitios IPv6
aislados, o para realizar conexiones con redes IPv6 remotas, utilizando el backbone
IPv4. Esta técnica incluye el uso de túneles configurados manualmente,
encapsulación de rutas genéricas (GRE), mecanismos de túneles semiautomáticos
como los servicios tunnel broker, y los mecanismos de túneles completamente
automáticos, tales como, 6to4.
• Desplegar IPv6 sobre enlaces de datos dedicados: Esta técnica permite que dominios
IPv6 aislados se comuniquen mediante el uso de la misma infraestructura de red de
nivel 2 que emplea IPv4, pero con IPv6 utilizando PVC (Circuitos Virtuales
Privados, por sus siglas en inglés), FR (Frame Relay, por sus siglas en inglés), o
ATM separados; o enlaces ópticos separados; etc.
• Desplegar IPv6 sobre un backbone MPLS: Esta técnica le permite a dominios IPv6
aislados comunicarse mutuamente, pero sobre un backbone MPLS con IPv4.
Existen múltiples técnicas disponibles en los diferentes puntos de la red. Los
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 17
cambios necesarios en la infraestructura de la red son mínimos, debido a que el
encaminamiento está basado en etiquetas en lugar de utilizar la cabecera IP.
• Desplegar IPv6 utilizando backbones que soporten el modo dual stack: Esta técnica
le permite a las aplicaciones IPv4 e IPv6 coexistir en una capa IP dual. Todos los
enrutadores de la red necesitan ser actualizados para que soporten la dualidad de
protocolos.
Además de las estrategias para desplegar IPv6 dentro del entorno IPv4, también se
necesitaran mecanismos de traducción de protocolos o servidores dual stack para permitir
comunicaciones entre aplicaciones que usan IPv4 y aplicaciones que usan IPv6.
Estos mecanismos adquieren trascendental importancia cuando el despliegue de IPv6 pase
de la fase de prueba a la etapa de uso normal, y más relevante cuando los desarrolladores de
aplicaciones decidan detener el soporte de aplicaciones IPv4. [29]
Despliegue de Túneles IPv6 sobre IPv4
Realizar un túnel consiste en la encapsulación de tráfico IPv6 dentro de los paquetes IPv4,
de manera que los paquetes puedan ser enviados sobre el backbone IPv4; permitiendo a los
sistemas IPv6 aislados comunicarse entre ellos, sin tener que actualizar la infraestructura
IPv4 existente. Los túneles constituyen una de las estrategias claves durante el periodo de
coexistencia de ambos protocolos, tanto para los PS, como para las Empresa. En la figura
#3 se aprecia como los túneles le sirven a los PS para ofertar servicios IPv6 de extremo a
extremo sin necesidad de efectuar grandes modificaciones la infraestructura IPv4 existente,
y sin impactar los servicios IPv4 existentes. Es posible interconectar dominios IPv6
aislados, y efectuar conexiones con redes IPv6 remotas como la 6bone. [29]
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 18
Figura #3 IPv6 sobre Túneles IPv4.[3]
Existen varios mecanismos para realizar los túneles. Entre ellos podemos encontrar la
configuración manual de túneles IPv6 (RFC 2893 [30]); los túneles IPv6 sobre IPv4
denominados túneles GRE (Generic Routing Encapsulation, por sus siglas en inglés); los
túneles semiautomáticos como los que emplean los servicios Tunnel Broker (RFC 3053
[31]); y los túneles automáticos como los compatibles con IPv4 y 6to4. Los túneles
manuales, y los túneles GRE son empleados entre dos puntos, y requieren configuración
tanto en la fuente del paquete como en el destino final del túnel; mientras que los túneles
automáticos solamente necesitan ser habilitados, y duran el tiempo que dura la
comunicación. En el Anexo #5 podemos apreciar claramente la caracterización de los
diferentes mecanismos de tunelización que se encuentran disponibles para poder realizar la
selección más adecuada a nuestro entorno de transición.
Todos los mecanismos de tunelización requieren que los puntos finales del túnel trabajen en
modo dual stack.
Existen otras técnicas para establecer los túneles, como ISATAP (Intrasite Automatic
Tunnel Addressing Protocol, por sus siglas en inglés) y 6over4, los cuales se emplean sobre
redes de áreas universitarias, o para realizar la transición de las redes locales. Pero este
tema no será analizado en profundidad en el presente trabajo.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 19
1.4.2 Despliegue de IPv6 sobre enlaces de datos dedicados
La mayoría de las redes del mundo, y también de las redes cubanas están compuestas por
enlaces dedicados con diferentes tecnologías de nivel 2. Esto es válido tanto para el
backbone, como para las redes de los clientes. En el backbone del PS se emplean
protocolos de alta velocidad, tales como ATM, MPLS, FR; donde uno puede servirle de
transporte a otro protocolo. Las redes de los clientes frecuentemente emplean redes WAN
(Wide Area Network, por sus siglas en inglés) con ATM, FR; y en la red de acceso emplean
SHDSL, ADSL; y en las LAN emplean Ethernet, etc. Cada una de estas tecnologías,
presentan requerimientos para interactuar con las capas del nivel superior, y es por esto que
se necesitan especificaciones para el transporte de IPv6 por los protocolos de nivel 2. [32]
En la figura #4 podemos apreciar a IPv6 sobre enlaces dedicados.
Figura #4 IPv6 sobre enlaces de datos dedicados. [3]
Los enrutadores conectados a los ISP mediante WANs o MANs (Metropolitan Area
Network, por sus siglas en inglés), que pretenden usar IPv6, pueden configurarse para que
empleen la misma infraestructura de nivel 2 que emplea IPv4; por ejemplo, emplear PVC,
ATM o FR separados que empleen IPv6. Este tipo de implementación tiene la ventaja para
el PS que no se afectan los servicios desplegados con IPv4. [29]
Existen dos tecnologías básicas, Ethernet, y ATM. La tecnología Ethernet es casi
omnipresente, tanto en las LAN (Local Area Network, por sus siglas en inglés), como en
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 20
los enlaces PPP (Point to Point, por sus siglas en inglés) empleados para conectar los
enrutadores. El mapeo de las direcciones IPv6 en la capa de Ethernet puede apreciarse en
la RFC 2464. [33] Como la resolución de direcciones es una responsabilidad de la capa 3,
Ethernet, y las tecnologías derivadas de Ethernet, son transparentes a las comunicaciones
IPv6 [32], la segunda tecnología es ATM, es un método de nivel 2 para la transmisión de
paquetes WAN para transmitir datos y vídeos. La transmisión de paquetes IPv6 a través de
una red ATM se describe en la RFC 2492. [34] La diferencia mas notable con respecto a
otros protocolos de enlaces es que los enlaces PVC (Private Virtual Circuit, por sus siglas
en inglés) no usan direccionamiento en esta capa. [32]
1.4.3 Despliegue de IPv6 sobre un backbone MPLS
Un modelo de red que funciona tanto para IPv4, como para IPv6 es el etiquetado del
datagrama IP, denominado MPLS. En una red basada en MPLS [35], el nodo de ingreso va
a enviar un protocolo de señalización por todos los nodos que conforman esta red hasta
llegar al extremo y a continuación va a asignar etiquetas a cada uno de los enrutadores; una
vez asignada, cada nodo sabe que etiqueta se le va a asignar, y a continuación viene los
datos clásicos, cabecera IP y datos IP, con 12 campos más los campos si es versión 4, o los
8 campos más los datos si es versión 6. Lo que hace el nodo, como ha sido avisado y han
sido colocadas etiquetas, es asignar a uno de ellos una determinada etiqueta, y en función
de ésta se va a encaminar hacia un punto determinado hasta llegar hasta el extremo final,
pero el análisis que hace cada nodo para poder conmutar un datagrama IP está basado en la
etiqueta, y no en el análisis de la cabecera IP, y con esto conseguimos rapidez; luego el
nodo de regreso va a tener como función básica eliminar el campo de etiqueta para luego
enviarlo a la red, podría haber una red basada en prioridades, en flujos o mixta, lo que se
consigue es que tengamos un envío de información bastante ágil. Con la red MPLS
podemos construir túneles para enviar diferentes tipos de tráfico sin afectar los
requerimientos establecidos con anterioridad. [36]
Visión del Proveedor de Servicios (PS) ante la introducción de IPv6.
El Multiprotocolo de Conmutación de Etiquetas (MPLS) [35] es ampliamente aceptado
como tecnología de núcleo para las redes de próxima generación. Los PS que ofrecen
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 21
servicios MPLS/VPN [37] a sus clientes; en breve tiempo ampliarán la carpeta de servicios
introduciendo VPN (Redes Privadas Virtuales, por sus siglas en inglés) con IPv6. [38] Los
PS que pretenden soportar IPv6 en modo tradicional tendrán escasas opciones, como son:
Métodos de Tunelización (por ejemplo, manual, Tunnel Broker [31], Generic Routing
Encapsulation [GRE] [39] o Intrasite Automatic Tunnel Addressing Protocol [ISATAP],
los cuales presentan problemas de escalabilidad [12]). Por otra parte implementar IPv6
nativo inmediatamente, con núcleo MPLS dual-stack; introduce riesgos de inestabilidad, y
mayores costo de actualización de hardware y software y mayores costos de operación. [12]
Factores críticos que deben ser afrontados por el proveedor de servicios PS antes de
decidir la transición hacia IPv6 sobre MPLS.
1. Los proveedores de servicios, ejecutan inversiones significativas para construir un
backbone MPLS configurado para IPv4; y entre los primeros objetivos se encuentra
recuperar la inversión ejecutada; en este sentido ETECSA ha realizado la inversión
principal; y se encuentra en el proceso de configuración y refinamiento del
backbone utilizando IPv4.
2. La estabilidad del backbone es otro de los factores críticos. El PS tiene que ofrecer
servicios confiables, especialmente cuando existe voz sobre MPLS. Los mayores
esfuerzos en la primera etapa se centran en estabilizar la infraestructura IPv4, y por
tanto no se tomarán iniciativas precipitadas, y no se harán movimientos hacia IPv6 a
menos que la integración ocurra de manera suave y planificada. [12]
3. Algunas características avanzadas pueden ser desplegadas en el núcleo; por
ejemplo: la ingeniería de tráfico, re-enrutamiento rápido, y MPLS QoS. La
estrategia de migración no debe perturbar la operación de estas características para
el tráfico de IPv4, y al mismo tiempo debe permitir que el tráfico IPv6 se beneficie
de estas características. [40]
IPv6 sobre MPLS. Escenarios de Despliegue.
Existen muchas maneras para entregar servicios IPv6 a los usuarios finales. [41] La más
utilizada es el envío de tráfico IPv6 de extremo a extremo.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 22
IPv6 sobre MPLS le permite a los dominios IPv6 aislados comunicarse con otros dominios
similares empleando el backbone IPv4 MPLS.
Los mecanismos más importantes para desplegar IPv6 sobre MPLS se describen
brevemente a continuación:
• Soporte nativo de IPv6 sobre MPLS. [42] La infraestructura del núcleo requiere
actualizar completamente el Plano de Control hacia IPv6.
• Requiere enrutamiento IPv6 en el núcleo.
• Requiere IPv6 LDP (Label Distribution Protocol, por sus siglas en inglés) en el
núcleo.
• Una transición brusca introduce riesgos y costos adicionales para el PS. [40]
IPv6 sobre Túneles IPv4. “CE-hacia-CE”. [41]
Esta estrategia no requiere cambios en los enrutadores P, ni en los PE, porque se emplean
túneles IPv4 para encapsular el tráfico IPv6; de tal manera que aparecería como tráfico
IPv4 dentro de la red.[40] Sin embargo este método adolece de los constantes retos de
escalabilidad que presentan las técnicas de tunelización (la creación y el manejo de túneles,
así como el enrutamiento de cada enrutador CE [Custumer Edge, por sus siglas en inglés]
hacia otro enrutador CE) [40]
IPv6 empleando “Circuitos sobre MPLS”. [42]
Permiten que sean emulados:
• Circuitos ATM, FR, puerto a puerto sobre Ethernet, VLANs entre otros.
• Es necesario que los enrutadores PE soporten “Circuit_over_MPLS”. Soportado
por los enrutadores de Internet Cisco 12000 y 7600. [29]
• Esta técnica evita cualquier actualización IPv6 en el núcleo, pero también acarrea
retos de escalabilidad.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 23
IPv6 Provider Edge Router (6PE), e IPv6 VPN Provider Edges (6VPE)
Soportan el servicio de alcance global con IPv6, y servicios VPN con IPv6 sobre un
backbone IPv4 MPLS. Estas estrategias han probado ser muy atractivas para los
proveedores que tienen en operación IPv4 debido a las siguientes razones [40]:
1. No se requieren actualizaciones para los enrutadores P, por lo tanto se preserva la
estabilidad del backbone, y se minimizan los costos de la operación.
2 Permiten un despliegue gradual, actualizando solamente los enrutadores PE para
que ofrezcan servicios IPv6 (y donde se empleen RR [Reflectores de Rutas, por sus
siglas en inglés] se actualizaran estos, o en su lugar se desplegará una malla
separada de RR para IPv6).
3 Son muy escalables porque se apoyan en un solo lado del modelo de provisión
como en la arquitectura MPLS VPN, por lo cual la adición de un nuevo sitio
involucra solamente la configuración del puerto en cuestión para este sitio
particular.
4 Toma las ventajas de MPLS forwarding en el núcleo, y su alto rendimiento.
5 Garantizan que el tráfico IPv6 se beneficie automáticamente de las características
avanzadas de MPLS que pueden ser desplegadas en el núcleo, tales como FRR
(Fast Reroute Techniques, por sus siglas en inglés; in RSVP-TE), TE, y MPLS
QoS.
IPv6 Provider Edge (6PE)
La solución 6PE [43] utiliza el mismo paradigma transparente de enrutamiento y transporte
para lograr alcanzabilidad global con IPv6, sobre un backbone IPv4 MPLS que no conoce
de IPv6. La diferencia clave es que la información de alcanzabilidad (reachability) que se
anuncia entre los enrutadores PE (Provider Edge, por sus siglas en inglés) vía MP-BGP
(Multi Protocol-Border Gateway Protocol, por sus siglas en inglés) ya no emplea prefijos
VPN con IPv4; sin que utiliza prefijos IPv6. De manera que los enrutadores PE deben ser
actualizados a dual-stack, y en lo adelante se denominarán 6PE. Ellos soportarán IPv6 (y
típicamente IPv4) en las interfaces de acceso, pero soportarán solamente IPv4, e IPv4
MPLS en las interfaces que apuntan al núcleo. [40]
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 24
Los enrutadores P permanecen ajenos a IPv6, y tienen en funcionamiento el enrutamiento
IPv4, y distribución de etiquetas IPv4. Esta arquitectura se muestra en la figura #5. [40]
Una manera de entender la solución 6PE consiste en considerar que el núcleo IPv4 MPLS
transporta eficazmente el tráfico de una VPN adicional, cuyo tráfico y espacio de
direcciones en este caso es IPv6. Tal como, en el caso de IPv4 VPNs, los enrutadores del
núcleo permanecen ajenos de los enrutadores que pertenecen a esta VPN particular.
Nótese, sin embargo que esta VPN especial no involucra los mecanismos de la RFC
2547bis [44] (tales como las VRF [Virtual Route Forwarding, por sus siglas en inglés], los
RD (Route Distinguishers, por sus siglas en inglés), y RT (Route Targets, por sus siglas en
inglés), porque las tablas de rutas y encaminamientos de IPv6 están naturalmente separadas
de las de IPv4. [40]
Figura #5 Arquitectura 6PE. [3]
IPv6 VPN Provider Edge (6VPE)
Además de los servicios de conectividad global que pueden ser ofertados por la estrategia
6PE, los PS son cuestionados por sus clientes acerca de la posibilidad de ofrecer servicios
IPv6 VPN. Al mecanismo mediante el cual se ofrecen estos servicios de le denomina
6VPE [38]. La estrategia 6VPE combina “el manejo de IPv6” de 6PE con “el manejo de
VPN” de IPv4 MPLS VPNs; para soportar tales servicios IPv6 VPN sobre un backbone
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 25
IPv4/MPLS. [40] En nuestro país el principal servicio de conectividad ofertado a nuestros
clientes, son las VPN capa 3, en el presente se emplea VPN/IPv4.
En la figura siguiente se muestra un ejemplo donde dos clientes que emplean IPv6 nativa,
pretenden establecer una comunicación a través de una arquitectura IPv4/MPLS;
empleando el mecanismo 6VPE. Los enrutadores de borde manejan la dualidad de
protocolos, la información de cómo alcanzar las subredes IPv6 se obtienen en función
IGPv4 quien es informado por MP-BGP sobre las subredes IPv6; IGPv4 intercambia
información con el núcleo de MPLS basado en las IPv4 de loopback de los PE
involucrados; y en función de esta información se actualizan las tablas de etiquetas basadas
en el funcionamiento del Protocolo de distribución de etiquetas (LDP, por sus siglas en
inglés).
Figura #6 Distribución de Rutas y Etiquetas en el núcleo IPv4, para 6VPE
Las nuevas características de 6VPE respecto a 6PE se expresan a continuación:
1. Se emplea una familia de direcciones diferentes para 6VPE en MP-BGP, la cual se
denomina: familia de direcciones diferentes VPN-IPv6 (AFI=2 [Address Family
Identifier, por sus siglas en inglés] para “IPv6”, SAFI=128 [Sub Address Family
Identifier, por sus siglas en inglés] para “VPN etiquetadas”). Una dirección VPN-
IPv6 es una entidad de 24 bytes, que comienza con el RD (Route Distinguisher, por
sus siglas en inglés) de 8 bytes, y termina con la dirección IPv6 de 16 bytes. El
papel y codificación de las RD es exactamente igual que las VPN con IPv4.
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 26
2. Se emplea un concepto de VRF de la arquitectura MPLS /VPN-Capa 3, en la cual
cada VPN tiene un conjunto separado de tablas de rutas y encaminamientos, junto
con los mecanismos asociados al control de la importación y exportación de rutas
hacia adentro, y hacia fuera de las VRFs, incluyendo el etiquetado de las rutas con
los RT (Route Targets, por sus siglas en inglés).
3. La estrategia 6VPE produce los mismos beneficios que 6PE. Por ejemplo, como en
6PE, solamente los enrutadores PE que realmente conectan servicios VPN/IPv6
necesitan ser actualizados para soportar IPv6 y las funcionalidades 6VPE. De esta
manera el PS puede también introducir servicios VPN/IPv6 sin la necesidad de ser
actualizados, ni de cambios de configuración en los enrutadores de núcleo. [40]
1.4.4 Despliegue de IPv6 utilizando backbone Dual Stack
El empleo de backbones en modo dual stack es una estrategia básica para enrutar tanto
IPv4, como IPv6. Para ello todos los enrutadores de la red necesitan ser actualizados con la
funcionalidad dual stack. Los requerimientos principales consisten en que cada sitio posea
un prefijo global de unidifusión (en inglés unicast global prefix); y entradas apropiadas en
el DNS que almacena al mapeo entre los hosts y las direcciones IP de ambos protocolos.
Las aplicaciones seleccionarán si emplearán IPv4, o IPv6; en dependencia de la respuesta
del DNS. Este tipo de estrategia es válido para algunas infraestructuras de red donde
coexisten aplicaciones IPv4 e IPv6. Por otra parte, resulta necesario actualizar todos los
enrutadores de la red para que soporten el modo dual stack, con los consiguientes costos
que esto acarrea; además existen otras limitaciones, por ejemplo: se requiere que se
predefina un esquema de direccionamiento dual; se requiere gestión dual para los
protocolos de enrutamiento; se requieres que los enrutadores tengan suficiente memoria
para soportar tanto las tablas de rutas IPv4, como la IPv6.[29]
1.5 Conclusiones del capítulo
En Cuba se encuentran en funcionamiento varias tecnologías de backbone a un mismo
tiempo, existiendo distintos tipos de pasarelas entre ellas, para garantizar las
CAPÍTULO 1. TRANSICIÓN HACIA IPv6 27
comunicaciones entre clientes de diferentes redes que pertenecen a una misma
organización. Algunas de estas infraestructuras como el backbone IP, X.25 no son
mencionadas en el diagnósticos porque están en proceso de desintegración; quedando
ATM, e IP/MPLS como las principales arquitecturas. ATM está cediendo su protagonismo
al backbone IP/MPLS, activo desde el 2007; y se convertirá dentro de poco en una red de
acceso al backbone principal IP/MPLS; que constituirá el transporte de todos los servicios y
aplicaciones basados en IP. Además arribamos a la conclusión de que constituye, también
en Cuba; una necesidad la transición de IPv4 hacia IPv6, y que es imprescindible
determinar el escenario que mejor responda a las necesidades de los proveedores de
servicios.
CAPÍTULO 2. VOZ SOBRE IPv6 28
CAPÍTULO 2. Voz sobre IPv6
En el presente capítulo pretendemos exponer los principales retos a los que se expone la
Voz sobre IP, desde el punto de vista de la Calidad de Servicio. Además analizaremos el
funcionamiento de la Voz sobre IPv6, así como el soporte que brinda IPv6 a la Calidad de
Servicio. Analizaremos los principales protocolos que hacen posible el funcionamiento de
la VoIPv6; y el soporte de estos a la Calidad de Servicio.
2.1 Definición de la Voz sobre el Protocolo de Internet
Voz sobre el Protocolo de Internet: No es más que la transmisión de voz sobre una red de
paquetes, utilizando el protocolo IP, permitiendo la integración de servicios. [45]
2.1.1 Surgimiento de la VoIP
La voz sobre el protocolo de Internet (VoIP) ha sido estudiada, y probada desde la década
del 1970; sin embargo el propio desarrollo de la industria no propiciaba la transmisión de la
voz sobre redes heterogéneas de paquetes. Los primeros resultados obtenidos con la voz
manejada en forma de dato, han provenido de ambientes pre-almacenados; o de
aplicaciones que no funcionan en “tiempo real”. La adopción de tecnologías de
Procesamiento Digital de Señales para la compresión de la voz y el vídeo, a finales de la
década de 1980, y comienzos de 1990 constituyeron un acelerador para que a principios del
año 2000 hiciera su entrada comercial la VoIP en el mundo de las telecomunicaciones,
formándose la llamada red de primera generación (1G). Con la acelerada convergencia
hacia la arquitectura TCP/IP como red multiservicio; los principales proveedores
tradicionales de voz han enfocado sus esfuerzos hacia el nuevo paradigma de la VoIP, lo
que ha dado como resultado la segunda generación (2G). Hace solamente 6 años se ha
venido formando la tercera generación (3G). [43]
CAPÍTULO 2. VOZ SOBRE IPv6 29
La VoIP ha permitido ahorrar costos de troncalización a través de los operadores
tradicionales que manejan los enlaces multiplexados por división de tiempo (TDM por sus
siglas en inglés).Las compañías más grandes han empleado VoIP principalmente para el
soporte a la movilidad, y otros servicios relacionados como las “funciones relacionadas con
la presencia”, y la mensajería unificada. A pesar de la reciente aceptación de la VoIP, tanto
por la industria, como por la esfera comercial; todavía existen dos factores que constituyen
obstáculos importantes que se oponen a la adopción definitiva de estos estándares. El
primero lo constituye la calidad de servicio, que en IP no está intrínsecamente garantizada;
y el segundo problema está relacionado con la integridad de la señalización extremo-
extremo que se ve afectada por diferentes obstáculos que deben ser atravesados en la
mayoría de las arquitecturas (firewalls, y dispositivos NAT). En el mundo tradicional de
las telecomunicaciones (TDM) es posible efectuar una comunicación de voz, con calidad de
servicio garantizada; a cualquier parte del mundo. Sin embargo VoIP todavía enfrenta
importantes retos, especialmente en cuanto a la calidad de servicio realmente alcanzada por
los usuarios. Tradicionalmente VoIP ha empleado IPv4 para su implementación y
desarrollo, tal es así que en Cuba se ha adoptado una arquitectura NGN basada en la
versión 4 del protocolo IP. [20]
2.1.2 Motivaciones del empleo de la VoIP
Algunas de las principales motivaciones para que la industria y los mercados encuentren la
VoIP como un camino viable son [10]:
1. Las nuevas aplicaciones que se hacen posibles, lo que genera oportunidades para
nuevos servicios, y nuevas ganancias. Entre ellas podemos mencionar la Movilidad,
la mensajería unificada, entrega convergente de cualquier tipo de servicio de
información, aplicaciones de Integración de Telefonía de Computadoras para Centros
de Contactos, lo que incluye centros de contactos virtuales y servicios sin las
limitaciones tradicionales de distancias.
2. Reducción de costos por los siguientes conceptos: disminución de los gastos de
operación debido a la convergencia de las redes, menores inversiones en
CAPÍTULO 2. VOZ SOBRE IPv6 30
equipamientos. Y estos ahorros pueden repercutir en menores precios para los
clientes.
3. La convergencia permite la introducción del “triple play”, lo cual es posible por el
empleo de arquitecturas de paquetes “no orientadas a conexión”.
4. IP se ha convertido en un soporte para la ubicuidad en el área de los datos. Puede ser
empleado para todo, además es lo suficientemente bueno para soportar cualquier
carga útil.
Sin embargo han existido diversos factores que han impedido una rápida penetración de la
VoIP. En primer lugar encontramos las consideraciones de QoS para redes de paquetes,
especialmente para entornos entre proveedores (“carries to carries”); en segundo lugar la
necesidad de una señalización robusta para la interacción, y coexistencia con las PSTN, que
seguramente perduraran por las próximas dos décadas; y por ultimo las consideraciones de
seguridad, especialmente en los entornos de coexistencia. [10]
2.2 Principales dificultades de IPv4 como soporte de los servicios de voz
En los orígenes de las redes IP, la red fue diseñada con el criterio de construirla lo mas
simple posible. El principal objetivo de esta red fue enviar paquetes de un nodo hacia el
próximo nodo conocido. Todos los paquetes eran tratados de la misma manera y
almacenados en un simple buffer del tipo “first-in, first-out”. Esta red dio lugar a una
gigantesca interconexión de dispositivos de red, con un tratamiento sobre el tráfico
denominado “best effort”.
Queda claro que todos los tipos de tráficos, no responden de manera similar ante distintos
eventos que se presentan continuamente en las redes IP de la actualidad. Existen servicios
tales como Protocolo de Transferencia de Ficheros (FTP, por sus siglas en inglés) [46],
Correo electrónico (e-mail, por sus siglas en inglés) [47], Protocolo de transferencia de
hipertexto (http, por sus siglas en inglés) [48]; que pueden coexistir sin dificultad en redes
donde rige el “mejor esfuerzo”; sin embargo otras aplicaciones de tiempo real son sensibles
al comportamiento de diversos parámetros que afectan la calidad de servicio; a estas
CAPÍTULO 2. VOZ SOBRE IPv6 31
aplicaciones (voz, video) deben aplicársele estándares de QoS para que perciban un
comportamiento aceptable desde el punto de vista del cliente final.
Desde el punto de vista de la red, la QoS puede definirse como la capacidad de diferenciar
clases de tráfico, de manera que algunos usuarios puedan percibir diferentes calidades de
servicio. Además de asignar y asegurar recursos en la red; así como crear diferencias en el
servicio que se presta entre distintos tipos de usuarios, según ciertas reglas preestablecidas.
[49]
Dentro de los diferentes retos en cuanto a QoS que afronta la VoIP encontramos [10]:
• Las pérdidas de paquetes. (Packet Loss)
• Las demoras. (Delay)
• Variación de la demora. (Jitter)
• La probabilidad de bloqueo. (Blocking Probability)
• El ruido de cuantificación. (Quantization noise)
• Razón de error de bit. (Bit error ratio)
• La selección del codificador. (The choice of codec)
• El control de eco. (Echo control)
• El diseño de la red.
2.3 Visión general de la QoS en Redes de Telecomunicaciones
La QoS es empleada para evaluar el potencial de los PS para conocer los requerimientos de
los usuarios. En lugar de ofrecer etiquetas precisas, la evaluación de la QoS se concentra en
el análisis del desempeño del servicio, cuestión que sirve de guía en la mejora del
desempeño.
En redes IP, la QoS evalúa la capacidad de transmisión de la red. Debido a que la red
provee distintos tipos de servicios, estos son evaluados desde distintos puntos de vista en
cuanto a QoS. Generalmente la QoS evalúa el comportamiento de la red para conocer los
CAPÍTULO 2. VOZ SOBRE IPv6 32
requerimientos de parámetros como ancho de banda, rendimiento, demoras, variación de las
demoras, relación de pérdida de paquetes, y disponibilidad; durante la transmisión de los
paquetes. [50]
2.3.1 QoS en Redes IP tradicionales
En las redes IP tradicionales, los enrutadores manejan todos los paquetes de la misma
manera; basados en la política de colas “Fisrt In First Out”. Durante la transmisión de los
paquetes, el enrutador asigna los recursos en dependencia del orden en que arriban los
paquetes.
Todos los paquetes comparten los recursos de ancho de banda que proporciona la red. Los
recursos que obtiene un paquete dependen del tiempo en el cual arribó. Este modelo de
servicio recibe el nombre de “mejor esfuerzo”. En este modelo los paquetes son enviados
hacia sus destinos sin garantías de demora, variación de la demora, de relación de pérdidas
de paquetes, ni de confiabilidad. [50]
Para implementar QoS en redes IP, necesitamos aplicar varias tecnologías de QoS,
incluyendo: marcación y clasificación del tráfico, organización y políticas de tráfico, así
como gestionar y evitar la congestión. [51]
Algunas consideraciones que aparecen en las redes modernas
En las redes actuales los paquetes se encuentran con variadas dificultades durante su
travesía hacia sus destinos, algunas de ellas las ponemos a su consideración: [52]
Demoras en las colas.
Congestión.
Demoras por Serialización.
Pérdidas de paquetes, y comportamiento sobre redes de terceros PS.
Sobre venta del ancho de banda.
Alta latencia y (o) Jitter.
CAPÍTULO 2. VOZ SOBRE IPv6 33
2.4 Nuevos requerimiento de QoS para nuevas aplicaciones
Con el rápido desarrollo de las telemáticas, un número creciente de redes son
interconectadas empleando el protocolo IP. El mayor impacto en el crecimiento de estas
redes ha residido en lo referente al tamaño, el área de cobertura, y la cantidad de usuarios.
Además de las aplicaciones comunes, tales como WWW, correo electrónico, FTP, etc; los
usuarios demandan que las redes se adapten al empleo de nuevas aplicaciones. Entre ellas
podemos mencionar las siguientes:
• Tele-educación.
• Tele-medicina.
• Video-telefonía.
• Video-conferencia.
• Video bajo demanda.
• Voz sobre el protocolo de Internet.
En lugar de simplemente transmitir los paquetes hacia sus destinos, las nuevas aplicaciones
demandan mejores comportamientos de las redes IP, en el sentido que se expresa a
continuación:
• Proveer ancho de banda específico según el usuario.
• Reducir la relación de paquetes perdidas.
• Evitar y manejar la congestión.
• Regulación del tráfico de la red.
• Establecimiento de prioridades a los paquetes.
Si la QoS no puede ser garantizada, la NGN basada en paquetes no puede satisfacer las
demandas comerciales, ni puede asumir el rol sucesor de las centrales tradicionales (PSTN)
que brindan los servicios de voz. [50]
CAPÍTULO 2. VOZ SOBRE IPv6 34
2.4.1 QoS para la VoIP
Uno de los aspectos más importantes que debe ser tratado en las soluciones de VoIP es
precisamente la Calidad de Servicio (QoS, por sus siglas en inglés). Sin una configuración
adecuada de la QoS, la calidad de la voz, pudiera ser sacrificada en la competencia de este
sensible tráfico de tiempo real, dentro de la demanda general de tráfico que viaja en la red.
Estas opciones de configuración de la QoS, proveen un canal prioritario, que es empleado
por el tráfico de voz de manera que la calidad puede ser mantenida incluso compartiendo la
red con otros tipos de tráfico. [52]
Ancho de Banda: La cantidad de ancho de banda disponible extreme-extremo,
dicta si una llamada va a trabajar correctamente o no. Con un ancho de banda
ilimitado, una llamada de voz debe trabajar sin mayores problemas; sin embargo;
todos conocemos que el ancho de banda no es ilimitado, y en el mejor de los casos
debe ser compartido en alguno de los niveles de la red. [52] En la siguiente figura se
muestra una trayectoria con diferentes anchos de banda, y podemos apreciar que el
máximo ancho de banda es igual mínimo ancho de banda en el trayecto del enlace
de datos. (BW max = Min (100M, 10M, 256k, 2M, 1G) = 256kbps) [51]
Figura #7 Ancho de Banda
El ancho de banda incide directamente en la QoS, para cada sesión, se supone que el
tráfico de datos está sujeto a un límite global llamado el "ancho de banda de la
sesión" a ser distribuida entre los participantes. Este ancho de banda puede ser
reservado y hacer cumplir el límite por la red, o puede que solo sea una parte
razonable. El ancho de banda de la sesión puede ser elegido en base o algún costo o
un conocimiento a prioridad de la red de ancho de banda disponible para la sesión.
Es algo independiente de la codificación de medios, pero la elección de codificación
CAPÍTULO 2. VOZ SOBRE IPv6 35
puede ser limitada por el ancho de banda de sesión. El parámetro de sesión de ancho
de banda se espera que sea suministrada por una aplicación de gestión de la sesión
cuando se invoca una aplicación de medios de comunicación, pero las aplicaciones
de los medios de comunicación también pueden establecer un valor predeterminado
basado en el único emisor de ancho de banda de datos para la codificación
seleccionada para la sesión. La aplicación también se puede hacer cumplir los
límites de ancho de banda basadas en reglas de ámbito de multidifusión u otros
criterios. [53]
Demora: Una demora elevada puede provocar que una comunicación de voz sea
insoportable en cuanto a la calidad percibida. Típicamente en VoIP, la demora
extreme-extremo, debe estar por debajo de 150ms [52] Dentro de las principales
fuentes de latencia podemos encontrarnos demoras introducidas por los CODECs,
demoras inherentes al procesamiento, demora en las colas, demoras de propagación,
y la variación de las demora. [54] En la siguiente figura se muestran los diferentes
factores que introducen retardo en una trayectoria dada; El retardo extremo a
extremo es la suma del retardo de transmisión, el tiempo de procesamiento y el
retardo en las colas a lo largo del trayecto. [51]
Figura #8 Retardo extremo a extremo (Demora)
Las demoras no afectan directamente la calidad de la voz, sino la calidad de la
conversación. Hasta 100 ms son generalmente tolerados, casi sin percepción de los
interlocutores. Entre 100 y 200 ms las demoras son notadas. Al acercarse a los 300
ms de demora, la conversación se vuelve poco natural. Pasando los 300 ms la
demora se torna crítica, haciendo muy dificultosa la conversación. Un efecto
CAPÍTULO 2. VOZ SOBRE IPv6 36
secundario generado por las demoras elevadas es el eco. La latencia entre el punto
inicial y final de la comunicación debe ser inferior a 150 ms. El oído humano es
capaz de detectar latencias de unos 250 ms y hasta 200 ms en el caso de personas
bastante sensibles. Si se supera ese umbral, la comunicación se vuelve molesta.
Variación de la demora: También conocida como jitter. Es la variación de la
demora en una llamada de voz. Si las demoras sobre conexión de voz, se mantiene
de manera constante con una demora de 100 ms, no ocurren problemas
significativos en cuanto a la QoS. Sin embargo en la primera porción de la llamada,
las demoras son cortas (por debajo de los 5 ms), seguido por un período de demoras
mayores (sobre los 300 ms), y luego ocurre otra porción con demoras cortas; el
dispositivo receptor de voz se enfrentará a problemas de sincronización del flujo de
voz. [52]. La demora por si misma no distorsiona la llamada de voz, sin embargo el
Jitter si. Normalmente las causas de este fenómeno están relacionadas con
problemas de demoras de serialización, paquetes pequeños que deben esperar que
paquetes mayores sean transmitidos, o que comunicaciones pertenecientes al mismo
flujo de tráfico de voz tomen diferentes trayectorias, debido a que algunos paquetes
tomen diferentes trayectorias. [54] En la siguiente figura se ilustra El Jitter es
causado por las diferencias en los retardos extremo a extremo de los paquetes de un
mismo flujo de información. [51]
Figura #9 Variación de la demora (Jitter)
Pérdidas: Obviamente las pérdidas de paquetes de voz provocan pérdidas de audio
durante la comunicación. Pérdidas por debajo del 1% durante el curso de la
comunicación, probablemente no son notificadas; pero si las pérdidas de paquetes
CAPÍTULO 2. VOZ SOBRE IPv6 37
se convierten en un problema, se deteriorará considerablemente la QoS. [52]
Normalmente las causas de este fenómeno están relacionadas con problemas de
limitación del ancho de banda, congestiones en las interfaces, aplicación de políticas
que priorizan otros tráficos diferentes a la voz, dificultades propias del nivel físico
que provocan el deterioro de los paquetes, o la pérdida de los mismos. [54]
El límite máximo admitido para que no se degrade la comunicación deber ser
inferior al 1%, pero es bastante dependiente del CODEC que se utiliza. Cuanto
mayor sea la compresión del CODEC, más pernicioso es el efecto de la pérdida de
paquetes. Por ejemplo, una pérdida del 1% degrada más la comunicación si se usa el
CODEC G.729 en vez del G.711.
En la siguiente figura se ilustra como la pérdida de paquetes puede ocurrir en el
proceso completo de la transmisión de la información. [51]
Figura #10 Pérdida de paquetes
2.4.2 Modelos de Servicio de QoS
Una comunicación que se establece entre dos dispositivos de red, puede pasar a través de
diferentes redes heterogéneas compuestas por enrutadores, y todos los sistemas de capa 2
que los interconectan. Es por ello que los modelos de QoS que se implementen deben
garantizar la calidad de manera global.
Además del modelo conocido como “Best-Effort”, la QoS emplea un modelo basado en
clases de servicio (class-based) y otro modelo basado en el tráfico (traffic-based). El
CAPÍTULO 2. VOZ SOBRE IPv6 38
modelo de “Servicios Diferenciados” (Differentiated Service) corresponde con el primero
que mencionamos, mientras que el modelo “Servicios Integrados”, (Integrated Service)
corresponde al segundo.
Servicios Diferenciados
Las principales características de este modelo se relacionan a continuación:
No requieren señalización. No hay ninguna necesidad de notificar a la red antes de
que la aplicación envíe lo paquetes. La red no requiere almacenar el estado de cada
flujo de tráfico.
Se proveen los servicios de acuerdo a la QoS especificada para cada flujo de
tráfico.
Existen diferentes estándares para dividir los paquetes de acuerdo a las Clases de
servicio (CoS, por sus siglas en inglés). El estándar puede ser la precedencia IP, la
dirección IP origen, o la dirección de destino del paquete. La red clasifica los
paquetes, y realiza tratamientos del tráfico de acuerdo a su contenido, o a políticas
establecidas sobre los paquetes; y teniendo en consideración estos tratamientos
coloca los paquetes en las colas previstas para garantizar la QoS de acuerdo al
modelo de servicio establecido.
Existen diferentes estándares para dividir los paquetes de acuerdo a la CoS.
El modelo de Servicios Diferenciados es empleado para proveer QoS extremo-extremo,
para algunas aplicaciones que son muy susceptibles a ciertos comportamientos negativos de
las redes. Esta es implementada mediante el CAR (Committed Access Rate), y tecnologías
para el manejo de las colas.
CAR: Clasifica los paquetes de acuerdo reglas predefinidas. Además efectúa mediciones de
tráfico, y establece políticas al mismo.
Las tecnologías de las colas incluyen PQ (Prioridad de Colas, por sus siglas en inglés), CQ
(Colas Personalizadas, por sus siglas en inglés), WFQ (Detección Temprana de pesos
tomados al azar, por sus siglas en inglés), CBQ (Class-based Queue, por sus siglas en
inglés), y RTPQ (Real-time Transport Protocol Queue, por sus siglas en inglés).
CAPÍTULO 2. VOZ SOBRE IPv6 39
Cuando se emplea el modelo Servicio Diferenciado, un enrutador de borde puede clasificar,
de forma flexible; los paquetes en función de diversas condiciones, tales como el origen y
destino del paquete, la prioridad del tipo de servicio (ToS, por sus siglas en inglés), y el
tipo de protocolo. Además, un enrutador de borde puede establecer diferentes campos en la
etiqueta paquetes diferentes, mientras que otros enrutadores necesitan para clasificar los
paquetes únicamente de acuerdo al contenido del campo de etiqueta. El modelo Servicio
Diferenciado es ampliamente empleado en una red de backbone IP. [50]
Servicios Integrados
El Modelo de Servicio Integrado puede trabajar con varios de los requerimientos de QoS.
Cuando se emplea este modelo, los servicios especiales pueden ser solicitados a través
señalizaciones que se intercambian antes de la transmisión de los paquetes. El protocolo de
reserva de recursos (RSVP) implementa la señalización que transmite las solicitudes de
QoS. Los programas de aplicación necesitan notificar primero a la red sobre sus parámetros
de tráfico, y sus requerimientos especiales de QoS. Después de recibir el mensaje de
confirmación de que la red ha reservado los recursos para los paquetes de este programa de
aplicación, es que el programa comienza a enviar paquetes. El número de paquetes
enviados por la aplicación debe estar dentro del rango especificado en los parámetros de
tráfico.
Como una señalización de QoS, RSVP provee paquetes a todos los extremos de la red, con
la solicitud que contiene el mensaje de los recursos reservados.
En el proceso de establecimiento de comunicaciones extremo a extremo a través de RSVP,
cada nodo necesita almacenar la información de estado de cada flujo de paquetes. A esto se
le llama “estado de suave” (soft state), proceso que ocupa gran cantidad de recursos del
sistema en un momento determinado. Sin embargo los protocolos comunes de la capa de
enlaces, y las interfaces físicas; no pueden ofrecer un servicio garantizado. Por lo tanto,
RSVP no puede extenderse a todo el backbone de Internet. Esto dificulta la aplicación del
modelo Servicios Integrados a la red.
El modelo Servicios Integrados ofrece dos tipos de servicios:
CAPÍTULO 2. VOZ SOBRE IPv6 40
Servicio garantizado: Provee ancho de banda garantizado, y restricciones en la
demora de acuerdo a los requerimientos de aplicaciones como la VoIP.
Servicio de carga controlada: Provee paquetes con mínima demora y alta razón de
tránsito, a pesar de las sobrecargas que pudiera padecer la red.
2.4.3 Métodos para controlar la QoS en entornos de VoIP
Existen diferentes métodos para controlar la QoS en una comunicación de voz entre los
cuales se incluyen:
Clasificación y Etiquetado: El método más común de Clasificación y Etiquetado
en QoS son los Servicios Diferenciados (DiffServ). El concepto general de DiffServ
consiste en monitorear el tráfico que llega a través de un dispositivo, que recibe una
clasificación de tráfico específica (por ejemplo, tráfico de voz o de datos). Una vez
que este tráfico se clasifica, se marca con uno de métodos empleados para este fin.
Con el tráfico de IP se emplea el campo ToS (Tipo de Servicio, por sus siglas en
inglés), y se clasifica con uno de los códigos de Servicio Diferenciado denominado
Codepoint (DSCP, DiffServ Codepoint). Esta marca es utilizada por los dispositivos
sucesivos donde este tráfico es procesado; y de acuerdo al DSCP recibe una u otra
prioridad, para determinar que tráfico se procesará primero. [52]
Eficiencia del Enlace: Existen diferentes mecanismos de Eficiencia del Enlace. Los
mecanismos más conocidos incluyen cabecera IP y la compresión de carga útil.
Otros mecanismos son la fragmentación y la intercalación de Enlace (LFI, por sus
siglas en inglés). Éstos se utilizan típicamente en los enlaces seriales de menor
velocidad para mejorar las demoras producidas en la fragmentación de paquetes,
permitiendo así que otros paquetes más pequeños sean procesados. Obviamente
mientras más eficiente sea el enlace, menores demoras afectarán las
comunicaciones de voz. [52]
Gestión de la congestión: Mientras más congestionado está un enlace, menores
probabilidades tendrán los paquetes de VoIP de atravesarlo en un tiempo aceptable
para que no se afecte la calidad de la comunicación. Existen diversos mecanismos
CAPÍTULO 2. VOZ SOBRE IPv6 41
para el manejo de la congestión, unos más complejos que otros. Muchos de estos
mecanismos se emplean combinados con DSCP. Los métodos más empleados se
relacionan a continuación: [52]
First In First Out (FIFO, por sus siglas en inglés) (Ver Figura #27, del
Anexo #6)
Prioridad de Cola (PQ, por sus siglas en inglés) (Ver Figura #28, del Anexo
#6)
Colas Personalizadas (CQ, por sus siglas en inglés) (Ver Figura #29, del
Anexo #6)
Detección Temprana de pesos tomados al azar (WFQ, por sus siglas en
inglés) (Ver Figura #30, del Anexo #6)
Cola según su peso justo-basado en clases (CBWFQ, por sus siglas en
inglés) (Ver Figura #31, del Anexo #6)
Manejos de las colas en RTP (Ver Figura #32, del Anexo #7)
Evasión de la Congestión: Este es otro método de QoS, la más común de las
técnicas utilizadas se denomina Weighted Random Early Detection (WRED, por sus
siglas en inglés). Básicamente, los intentos de WRED para predecir la congestión
son a futuro, y cuando estos paquetes aparecen en el futuro, son descartados
selectivamente. [52]
2.4.4 Señalización
Este sub-epígrafe describe brevemente los protocolos de señalización que se emplean para
el establecimiento de las comunicaciones de VoIP. La señalización es un mecanismo crítico
que permite el establecimiento de las llamadas, así como servicios suplementarios
avanzados. En entornos de VoIP es necesario intercambiar señales para la red IP, y con
otras redes que no lo son, como las PSTN. Existen casos en que todos los elementos de red
poseen inteligencia (nodos, y CPEs), y se emplea ITU-T H.323. En otros casos la red
posee inteligencia, pero los extremos no; y se emplea MGCP (Media Gateway Control
CAPÍTULO 2. VOZ SOBRE IPv6 42
Protocol), y MEGACO/H.248 (Media Gateway Controllers), CCSS7 (Common Channel
Signaling System 7). Existe otro caso en que los dispositivos finales poseen inteligencia,
pero la red no; y se emplea SIP (Session Initiation Protocol). [10]
En el caso del PS en Cuba se emplea H.248 para el intercambio de señalización entre el
MGC y las PSTN, durante el establecimiento de la llamada; SIGTRAN para el intercambio
con las PSTN; y SIP para el intercambio de tráfico de dispositivos IP.
En la figura #11 se ilustran algunos de los protocolos mencionados asociados a sus capas
inferiores.
Figura #11 Protocolos que participan en la señalización de VoIP [10]
2.4.5 Protocolo de Tiempo Real
El Protocolo de Transporte de Tiempo Real (RTP, por sus siglas en inglés) funciona sobre
UDP. La carga transportada por RTP viaja dentro de un paquete, por ejemplo: muestras de
audio. Estos paquetes están formados por cabeceras RTP, posibles listas de fuentes de
contribución, y los datos útiles. Típicamente un datagrama UDP contiene un paquete RTP,
pero si el método de encapsulación de UDP es adaptado para RTP, un solo datagrama UDP
pudiera contener varios paquetes RTP. [53] En siguiente figura mostramos la estructura de
un paquete RTP.
CAPÍTULO 2. VOZ SOBRE IPv6 43
Figura #12 Estructura del paquete RTP [55]
Primera Palabra: [56]
• Ver. : campo versión (2 bits)
• P: indica si el paquete se ha rellenado a un múltiplo de 4 bytes. El último byte de relleno
indica cuántos bytes se agregaron. (1 bit)
• X: indica si hay un encabezado de extensión. (1 bit)
• CC: indica cuántos orígenes de contribución están presentes, de 0 a 15 (4 bits)
• M: es un marcador específico de la aplicación, normalmente un marcador de inicio (1 bit)
• Tipo de carga útil: indica cuál es el algoritmo de codificación que se ha utilizado (7 bits)
• Número de secuencia: contador que se incrementa en cada paquete RTP enviado (16 bits)
Segunda Palabra: [56]
• Marca de tiempo: indica cuándo se creó la primera muestra en el paquete. (32 bits)
Tercera Palabra: [56]
• Identificador de la fuente de sincronismo: indica a cuál flujo pertenece el paquete. Es el
método para de multiplexar/demultiplexar varios flujos de datos en un solo flujo de
paquetes UDP. (32 bits)
• Por último, los Identificadores de la fuente de contribución, en caso de que existan, se
utilizan cuando los mezcladores están presentes en el estudio. En ese caso, el mezclador es
el origen de sincronización, y los flujos que se mezclan se listan en esta palabra.
CAPÍTULO 2. VOZ SOBRE IPv6 44
Además, el mismo se complementa con el protocolo RTCP (Real –time Transport Control
Protocol, por sus siglas en inglés), el cual está basado en la transmisión periódica de
paquetes a todos los participantes en una sesión.
En este caso se utilizan para los diferentes medios (voz, video, etc) diferentes sesiones, con
sus propios paquetes RTCP. La función básica de RTP es multiplexar varios flujos de datos
en tiempo real en un solo flujo de paquetes UDP, pudiéndose enviar tanto a un solo destino
(unicast) o múltiples destinos (multicast). Los paquetes son numerados de la siguiente
manera: se le asigna a cada paquete un número mayor que su antecesor. Otra característica
muy importante para las aplicaciones de contenido multimedia en tiempo real es el time-
stamping (marcación del tiempo). La idea es permitir que el origen asocie una marca de
tiempo con la primera muestra de cada paquete. Las marcas de tiempo son relativas al
inicio del flujo, por tanto, solo importa las diferencias entre dichas marcas de tiempo. Con
este planteamiento, el destino es capaz de almacenar un pequeño buffer e ir reproduciendo
cada muestra el número exacto de milisegundos después del inicio del flujo reduciendo los
efectos de la fluctuación y sincronizando múltiples flujos entre sí. [56]
2.4.6 Protocolo de Transporte de Tiempo Real
El protocolo RTCP es complementario a RTP y le brinda a éste un mecanismo de control.
Utiliza UDP por el puerto adyacente siguiente al puerto que se utiliza para RTP. El
protocolo RTCP se basa en la periódica transmisión de paquetes de control a todos los
participantes en sesión ofreciéndole información sobre la calidad de los datos distribuidos
por la fuente. El protocolo subyacente debe proveer de la multiplexación de los datos y de
los paquetes del control. Por tanto, la función primordial de RTCP es la de proveer una
realimentación de la calidad de servicio de voz. Una fuente o emisor, utiliza el protocolo
RTP para generar paquetes de contenido multimedia que serán difundidos para un receptor
(unicast) o varios receptores (multicast). El contenido de “tiempo real” será encapsulado en
un flujo de paquetes UDP que será enviado al receptor o receptores. A su vez éstos generan
paquetes utilizando el protocolo RTCP que mandarán información sobre la calidad de los
datos distribuidos por la fuente y ayudará a elegir el intervalo de tiempo adecuado y a
sincronizar los flujos de audio. [56]
CAPÍTULO 2. VOZ SOBRE IPv6 45
2.4.7 SIP
El Protocolo de Inicialización de Sesiones, (SIP, por sus siglas en inglés) es un protocolo de
señalización estandarizado por el IETF, de nivel de aplicación desarrollado para el
establecimiento, modificación y finalización de sesiones multimedia. Es más compacto que
el H.323 y fue diseñado especialmente para la VoIP. Presenta un formato textual, por tanto,
al igual que otros protocolos de Internet, como SMTP, FTP y HTTP, se caracteriza por
poderse procesar con facilidad y por su ineficiencia en el uso de ancho de banda. [57]
SIP soporta IPv4 e IPv6; y tiene cinco facetas relacionadas con el establecimiento, y la
terminación de las comunicaciones multimedia: [10]
Localización de los usuarios. (Determinación del sistema final que participará en la
comunicación)
Determinación de la disponibilidad de los usuarios. (Determinación de la
disponibilidad de la parte llamada)
Determinación de las capacidades de los usuarios. (Determinación de los medios de
comunicación, y de los parámetros de estos)
Establecimiento de las sesiones. (Ej. “timbre”; establecimiento de los parámetros de
las sesiones en ambas partes, la llamante, y la llamada)
Gestión de las sesiones. (incluye transferencia y terminación de las sesiones,
modificación de los parámetros de las sesiones, y solicitud de servicios)
SIP no es un sistema vertical de comunicaciones, sino un componente que puede emplearse
inter-operando con otros protocolos del IETF, como el RTP (RFC 1889) [53], para el
transporte de datos de “tiempo real”; el RTSP (RFC 2326) [58] para el control de la entrega
de tráfico streaming, MEGACO (RFC 3015) [59] para el control entre los gateways y las
PSTN; y el Protocolo de Descripción de Sesión (SDP, por sus siglas en inglés) (RFC 2327)
[60] para describir las sesiones multimedia. Como se ha visto SIP se usa de conjunto con
varios protocolos con el objetivo de proveer al usuario un servicio completo; sin embargo
el funcionamiento de SIP no depende de ninguno de los protocolos mencionados.
CAPÍTULO 2. VOZ SOBRE IPv6 46
2.4.8 Megaco / H.248
Megaco es la generación siguiente del MGCP (Media Gateway Control Protocol, por sus
siglas en inglés), fue uno entre algunos estándares de señales y control propuestos para
competir con el estándar H.323 [61] para la conversión de señales de audio, transportadas
en los circuitos telefónicos (PSTN), en paquetes de datos transportados por Internet o por
otras redes de conmutación de paquetes.
La razón principal de la necesidad de desarrollo de este estándar fue la creciente
popularidad de VoIP. Los teléfonos tradicionales, ya sean digitales o analógicos, son
relativamente baratos porque no necesitan ser complejos, ellos son fijados a un conmutador
específico de una central de conmutación local. Los primeros dispositivos y teléfonos IP no
son fijados a un conmutador específico, entonces ellos deben poseer procesadores que les
permitan funcionar y ser inteligentes por ellos mismos, independiente de una central de
conmutación local. Esto hace el terminal (teléfono o dispositivo) más complejo, y por lo
tanto más caro.
El MGCP trata de simplificar estándares para esta nueva tecnología eliminando la
necesidad de complejidad y procesamiento intensivo de dispositivos de telefonía IP, de esta
manera se simplifican y se disminuyen los costos de los dispositivos anteriormente
mencionados.
Megaco retoma la posición anterior además de permitir al media gateway comunicarse con
el media gateway controller a través de una red IP. Esto permite a los PS y a las
organizaciones, la flexibilidad de usar las redes IP existentes como el backbone para la
VoIP.
Se espera que Megaco sea uno de los protocolos estándares para controlar teléfonos IP o
dispositivos similares a través de una red pública o privada. Megaco asegura que el extremo
tonto de la red (MG) y el punto central de inteligencia (MGC) se comuniquen
adecuadamente.
Megaco informa al MGC cuando un receptor, de teléfono IP, es descolgado, y el MGC, a
través de Megaco, le dice al MG que le dé tono de discar a ese teléfono IP y que espere por
CAPÍTULO 2. VOZ SOBRE IPv6 47
los tonos duales de multifrecuencia (DTMF). Una vez marcado un número, el MGC
determina la ruta. Todos los cálculos son realizados dentro del MGC, entonces Megaco
inicia los comandos entre los dispositivos: maestro (MGC) y esclavo (MG). Una vez que el
MGC decide que tiene que enrutar la llamada hacia otro MGC, como un PBX o un servidor
de VoIP, entonces usa SIP como el protocolo de señalización entre MGCs.
Por lo tanto Megaco permanece sólo en comunicaciones entre MG y MGC. [57]
2.4.9 Soporte de IPv6 a la QoS
La introducción, y despliegue de IPv6 solucionará la escasez de direcciones, y garantizará
el crecimiento de Internet. Además este nuevo protocolo se ha diseñado conscientemente
para que sea más seguro, y para que soporte de manera natural la movilidad, y la capacidad
de gestionar nuevas direcciones donde quiera que un dispositivo lo solicite. (Stateless
Autoconfiguration). [26] La transición hacia IPv6 ha superado la etapa de pruebas, y se
hace impostergable su adopción; sin embargo la falta de compatibilidad de los dispositivos,
y de la generalidad de las aplicaciones actuales, unido a la falta de contenido en Internet
con IPv6; han retrasado la adopción de IPv6 [27]. Resulta evidente que existirá un período
de coexistencia de IPv4, e IPv6; que será más extenso de lo que realmente conviene a
Internet, y a sus usuarios. En este complejo escenario de coexistencia estará envuelta la
QoS en la implementación de VoIP. [49]
En la cabecera del datagrama IPv6 existe un campo denominado “Etiqueta de Flujo”; que
establece un mecanismo capaz de manejar trayectorias con QoS garantizada. Los valores
definidos para este campo funcionan interrelacionados con MPLS lo cual constituye una
oportunidad en el escenario cubano donde el PS despliega VoIP a través de un backbone
IP/MPLS como transporte base de los paquetes IP. Sin embargo existen escasas
experiencias prácticas en la implementación de esta característica en diversos escenarios.
[10]
Sin embargo debe prestarse especial atención a algunas características de IPv6 para que no
atenten contra la QoS.
CAPÍTULO 2. VOZ SOBRE IPv6 48
IPv6 requiere que cada enlace por donde transitan los paquetes posea un MTU mínimo de
1280 octetos o superior, para evitar la fragmentación de los paquetes; y por consiguiente
disminuir las colas, la pérdida de paquetes, y otros fenómenos que afectan directamente la
QoS. IPv6 puede valerse del Protocolo de Descubrimiento de MTU por trayectoria (Path
MTU Discovery, por sus siglas en inglés) [62] para descubrir trayectorias que tengan MTU
razonables; sin embargo este protocolo debe ser implementado manualmente en cada caso.
[10]
Otro de los campos presentes en la cabecera IPv6 se denomina “Clase de Tráfico”, es
empleada por los nodos de origen, y los enrutadores de tránsito para distinguir entre
diferentes tipos de prioridades. Este campo está estrechamente relacionado con el método
para controlar la QoS en VoIP, denominado “Servicios Diferenciados”.
2.4.10 Impacto de la Transición hacia IPv6 sobre la VoIP
Debido a las dificultades que afronta la VoIP con el protocolo IPv4, y a la inminente
transición de los principales proveedores de VoIP tanto públicos, como sobre redes
abiertas; la transición hacia IPv6 también involucra la forma en que se manejará la voz en
el futuro de las redes.
El escenario de transición a IPv6 es muy complejo puesto que se afrontan varias
migraciones a un mismo tiempo, que impactan directamente sobre la VoIP. La migración
de IPv4, hacia IPv6 impacta sobre el acceso, el control, la seguridad, el transporte, y los
propios protocolos de señalización que hacen funcionar la arquitectura TCP/IP, y por tanto
la VoIP.
La QoS es reforzada por IPv6, sin embargo la coexistencia con IPv4; y la continuidad de la
aplicación de modelos típicos de IPv4, como el NAT, los firewalls, el modelo cliente-
servidor, etc; continuarán impactando negativamente en cuanto a la operación de la VoIP,
fundamentalmente en lo concerniente a la QoS. [49]
CAPÍTULO 2. VOZ SOBRE IPv6 49
2.4.11 Funcionamiento de la VoIPv6
La VoIPv6 funciona de manera similar a como lo hace VoIPv4; en la figura se muestran
varios escenarios de transición hacia IPv6; estos cambios afectan esencialmente el nivel de
red, y en menor medida los niveles adyacentes en el sentido vertical del modelo dividido en
capas o niveles. La VoIPv6 continúa empleando UDP, y TCP en el nivel de transporte;
continúa empleando SIP, RTP/RTCP, y los CODECs necesarios.
Figura #13 Flujo de los paquetes IPv6 en un entorno VoIPv6 [10]
Además de las dificultades introducidas en la interoperatividad de las redes, las
aplicaciones residentes tanto en los elementos de acceso, en los terminales “inteligentes”; y
en todos los equipos que intervienen en el control, asignación de los recursos, y la
seguridad; necesitan ser actualizadas para que manejen IPv6. Es precisamente en la capa de
aplicación que funciona en los dispositivos de los extremos de la comunicación donde se
originan, y hacia donde se dirigen los paquetes que portan tanto información de
señalización, como información de audio; de allí la importancia que reviste la actualización
de las aplicaciones para que manejen correctamente IPv6.
CAPÍTULO 2. VOZ SOBRE IPv6 50
2.5 Conclusiones del capítulo
En este capítulo se han analizado los principales impactos que introduce la transición en el
nivel de red sobre la VoIP. Hemos puesto de manifiesto el especial cuidado que debe
tenerse con el hecho de que IPv4 no es interoperable con IPv6; y la situación de
coexistencia visiblemente prolongada entre un protocolo aunque con dificultades; que es
maduro, probado; y aceptado por la industria (IPv4); con un protocolo nuevo como IPv6
que aparece como sucesor del nivel de red, introduciendo cambios en los paradigmas de
seguridad; actualizaciones en el nivel de aplicación; y complicados mecanismos de
coexistencia con IPv4. Es necesario resolver problemas de enrutamiento, de
direccionamiento, entre otros retos en un ambiente de dualidad en algunos de los
dispositivos. Esta transición en el nivel de red aparece junto con la transición de los
servicios de voz TDM, hacia una tercera generación de VoIPv6, donde aparecen retos
inherentes a la QoS en un entorno de conmutación de paquetes IP; que hasta el momento
no había sido tan exigido en cuanto a garantías de QoS para tráfico de “tiempo real”.
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 51
CAPÍTULO 3. Voz sobre IPv6
En el presente capítulo proponemos una topología, para la transición a IPv6 de los
elementos que componen la NGN cubana, en la propuesta se evalúa la mejor solución en
cuanto a garantías de QoS mediante el empleo de métodos de “Servicios Diferenciados”; y
se aprovecha la tecnología de transporte IPv4/MPLS que se encuentra instalada en Cuba
desde el 2007. Basados en el hecho de que en el backbone IPv4/MPLS se emplea el
servicio VPN capa 3 para la mayoría desplegar las redes privadas de los distintos clientes;
realizamos una propuesta relacionada con VPN/IPv6 denominada 6VPE. La propuesta ha
sido enfocada a la NGN cubana, y por supuesto nos enfocamos en las características
específicas de esta, poniendo de manifiesto los aspectos más sensibles a tener en cuenta en
cuanto a garantías de QoS. Esta propuesta está enfocada en la visión del Proveedor de
Servicios públicos.
3.1 Topología de NGN en Cuba
De manera general, la arquitectura esta definida teniendo en cuenta los elementos
necesarios para la realización de los servicios telefónicos tradicionales, nuevos servicios
multimedia basados en banda ancha y otros servicios que aparecerán en un futuro.
Para NGN, la arquitectura funcional debe incorporar principios fundamentales como [57]:
- Soporte para múltiples tecnologías de acceso: La arquitectura funcional debe ofrecer la
configuración flexible necesaria para soportar múltiples tecnologías de acceso.
- El Control distribuido: Esto permitirá la adaptación a la naturaleza del proceso
distribuido de las redes IP y soportar transparencia de localización para informática
distribuida.
-El Control abierto: Las interfaces de control de red deben ser abiertas para soportar la
creación de servicios y actualización.
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 52
-Aprovisionamiento independiente de servicios: El proceso de aprovisionamiento de
servicios debe estar separado del funcionamiento de la red.
-Soporte para servicios en una red convergente: Esto es necesario para generar
flexibilidad, servicios multimedia fáciles de usar penetrando el potencial técnico de la
convergencia fijo-móvil en la arquitectura funcional de NGN.
-Protección y seguridad reforzadas: Este es el principio básico de una arquitectura
abierta. Es indispensable proteger la infraestructura de la red manteniendo los mecanismos
de seguridad en las capas pertinentes.
Las NGN son redes de alcance global, están divididas en cuatro capas o niveles: Capa de
Acceso, Capa de Transporte, Capa Control y Capa de Aplicación/Servicios, tal y como se
muestra en la figura #14. Estas capas están separadas entre sí e interactúan por medio de
interfaces y protocolos abiertos. El control de llamada y servicios radica en el Softswitch,
quien es el cerebro de esta estructura y el cual está separado lógica y físicamente de los
dispositivos de conmutación y de acceso. Este tipo de redes soporta diferentes QoS, para
diferentes servicios, pues además de transportar voz, datos y multimedia en tiempo real,
también transporta datos en tiempo no real y brinda servicios a una amplia variedad de
dispositivos cableados e inalámbricos. [57]
Figura #14 Arquitectura NGN con IPv4.
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 53
La capa de Servicios/Aplicación.
Es la capa de mayor diferencia entre los distintos operadores. Proporciona los servicios y
aplicaciones disponibles en la red, estos servicios serán ofrecidos por toda la red sin
importar donde esté ubicado el usuario y serán tan independientes como sea posible de la
tecnología de acceso. Se brinda a los abonados todos los tipos de servicios como Redes
Inteligentes, Video en demanda, Correo electrónico, Correo de voz, Servicio Web y otros.
La capa la componen los servidores de aplicaciones y de medios, los que se encargan de
proveer las funciones y características de la red como son el establecimiento de las
conexiones, el encaminamiento, la facturación, los servicios avanzados que son posibles de
implementar por medio de la señalización y la información que se deduce de esta. [63]
La capa de Control.
La capa de control es la más importante dentro de la arquitectura de la NGN. En esta capa
se encuentra los dispositivos que controlan todo el transporte de los datos en la red, así
como el acceso a la misma. Estos dispositivos son los llamados Softswitch, controlador de
pasarelas de medios o Agente de Llamada (Call Agent).
El softswitch es un dispositivo que utiliza estándares abiertos para crear redes integradas de
última generación, en las que la inteligencia asociada a los servicios está desligada de la
infraestructura de red. Se considera la pieza central en las primeras implementaciones de las
NGN. Este dispositivo, es la combinación de hardware y software, que provee control de
llamada y servicios inteligentes para redes de conmutación de paquetes, y puede conmutar
el tráfico de voz, datos y video de una manera eficiente. Los componentes principales del
softswitch se denominan: MG (Media Gateway, por sus siglas en inglés), MGC (Media
Gateway Controller, por sus siglas en inglés) y SG (Signaling Gateway, por sus siglas en
inglés). Aunque muchas veces estos componentes se encuentran integrados pueden estar
separados, lo que requiere el uso de protocolos de comunicación entre los mismos. [63]
El Softswitch debe soportar las siguientes funciones [63]:
Control de llamada
Protocolos de establecimiento de llamadas: H.323, SIP
Protocolos de Control de Media: MGCP, MEGACO H.248
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 54
Control sobre la Clase y Calidad de Servicio.
Protocolo de Control SS7: SIGTRAN (SS7 sobre IP).
Procesamiento SS7 cuando usa SIGTRAN.
Detalle de las llamadas para facturación.
Control de manejo del Ancho de Banda.
Controla la Pasarela Multimedia.
Controla la Pasarela de Señalización.
Registro de Gatekeeper (controlador de acceso)
La capa de Transporte.
Esta capa no es más que el backbone de alta velocidad, de transmisión óptica, el cual
soportará el tráfico de paquetes para todos los servicios, es decir, voz, datos, video y otros,
es uno de los principales responsable de la QoS de extremo a extremo. Mantendrá
conectividad entre todos los componentes y la separación física entre las funciones dentro
de NGN. El equipamiento que lo compone son enrutadores y conmutadores que permitirán
la conmutación de las señales por la red asegurando alta capacidad y confiabilidad. Este
nivel adopta tecnología de conmutación de paquetes IP y se reconoce como la tecnología de
transporte más prometedora para NGN. [57]
En Cuba la tecnología que se emplea es MPLS, donde los paquetes IPv4 entran por el
enrutador de borde (PE, por sus siglas en inglés). El PE de entrada analiza el campo
dirección destino, coloca una etiqueta. El servicio más empleado en Cuba, es VPN capa 3,
por lo que dicho paquete viaja a través de una VPN denominada NGN; en el PE de salida,
se extrae la etiqueta al paquete y se entrega al destino IP en los el dominio del cliente en
cuestión. La información de cómo alcanzar el destino a través de las trayectorias óptimas
es descubierta, distribuida mediante el protocolo MP-BGP. MP-BGP lee la información de
destino y luego que actualiza a todos los enrutadores, lo que contribuye a la QoS. Esta
información la intercambia con un protocolo interior de MPLS que el Protocolo de
Distribución de Etiquetas (LDP, por sus siglas en inglés), quién se encarga de actualizar las
tablas de conmutación de etiquetas.
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 55
La capa de Acceso.
Esta capa incluye una diversidad de tecnologías usadas para llegar al cliente. Está
compuesta por una variedad de dispositivos que permiten a los usuarios finales tener
conectividad con la NGN, estos pueden ser MGs (Media Gateways, por sus siglas en
inglés), AMGs (Access Media Gateways, por sus siglas en inglés), TMGs (Trunk Media
Gateways, por sus siglas en inglés) o SMGs (Signaling Media Gateways, por sus siglas en
inglés), IADs (Integrated Access Devices, por sus siglas en inglés) y puntos de acceso
inalámbrico. Además, existen los dispositivos que realizan las tres funciones de los tres
primeros mencionados, estos son conocidos como UMG (Universal Media Gateways, por
sus siglas en inglés). [63]
En la topología cubana los equipamientos que se utilizan son teléfonos analógicos
tradicionales, que no poseen ningún tipo de inteligencia. El último punto IP va a ser el
elemento de acceso según la figura 8 y los llamamos equipos universales de acceso (UA,
Universal Access, por sus siglas en inglés). En los UA se establecen sesiones como
mecanismos para identificar cada dispositivo telefónico como una entidad única dentro del
sistema NGN; la sesión se establece con un par de números; la dirección IP, y la
identificación del terminal (TID, Terminal ID; por sus siglas en inglés).
3.1.1 Señalización empleada en el caso de la NGN cubana
SIGTRAN es el nombre del grupo de trabajo de la IETF que ha desarrollado una serie de
protocolos que permiten transportar señalización SS7 por redes IP. Por extensión se llama
SIGTRAN (SIGnalling TRANsport, por sus siglas en inglés) a este grupo de protocolos.
Estos protocolos soportan la transmisión de la señalización para la red de conmutación de
circuitos SCN (Switchet Circuit Network, por sus siglas en inglés) sobre redes IP. El mismo
soporta interfaz primitivo del estándar entre-capas definido en el modelo de jerarquías del
protocolo de señalización SCN para asegurar la utilización de las aplicaciones basadas en
SCN sin modificaciones. Esto es también utilizado por el protocolo IP en la capa inferior de
transmisión y cumple con los requerimientos esenciales de la señalización SCN añadiendo
las propias funciones. [63]
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 56
M3UA: MTP3- Capa de Adaptación de Usuario.
M2UA: MTP2- Capa de Adaptación de Usuario.
V5UA: V5.2- Capa de Adaptación de Usuario.
SCTP (Stream Control Transmission Protocol, por sus siglas en inglés): Es un protocolo de
comunicación de capa de transporte que fue definido por el grupo SIGTRAN de IETF en el
año 2000 y especificado en la RFC 2960. SCTP es una alternativa a los protocolos de
transporte TCP y UDP pues provee confiabilidad, control de flujo y secuenciación como
TCP. Sin embargo, SCTP opcionalmente permite el envío de mensajes fuera de orden y a
diferencia de TCP, SCTP es un protocolo orientado al mensaje (similar al envío de
datagramas UDP). [63]
Términos relacionados
Pasarela de medios (MGW): Cuando el flujo de información es transferido desde la SCN
hacia la red de conmutación de paquetes, el MGW lo pone en paquetes de datos (si los
datos no han sido transformados en paquetes), y entonces transfiere la información
paquetizada a la red de paquetes. Cuando el flujo de información es transmitido desde la
red de paquetes hacia la red SCN, se realiza la función inversa.
Controlador de pasarela de medios (MGC): El MGC es utilizado para el registro y control
(administración) de los recursos del MGW. El MGC presenta las siguientes capacidades:
Autorización de recursos a utilizar basados en estrategias locales.
Iniciación y terminación de los protocolos de señalización de SNC, como son No.7-
ISUP y Q.931.
Pasarela de señalización (SG): Puede recibir y transmitir señalización interna SNC en el
borde de la red IP. El SG en la Pasarela No.7-Internet puede pasar, traducir o terminar los
eventos de la SS7. Las funcionalidades de un SG pueden estar integradas en las funciones
de un MGW. [63]
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 57
3.2 Relación de los Protocolos NGN y la QoS
Las NGN necesitan soportar una gran variedad de funciones de red, incluyendo los
tradicionales protocolos orientados a datos y los más recientes protocolos orientados a la
convergencia.
Para el correcto funcionamiento de una red NGN es necesario el uso de normas y
protocolos de señalización estandarizados, que permitan el funcionamiento adecuado de
todos sus componentes en la red. Esos protocolos son la llave para consolidar la
convergencia de las redes.
La pila de protocolos de NGN es bastante amplia, los cuales trabajan en los diversos
niveles de su arquitectura. Estos se pueden clasificar en dependencia de la función que
realizan [63]:
Protocolos de control de transporte: TCP, UDP, SCTP.
Protocolos de control de llamada: ISUP, SIGTRAN, BICC, SIP-T, SIP-I, H.323.
Protocolos de control de media: H.248, MGCP, SIP.
Protocolos de aplicaciones: PARLAY, JAIN, XML, INAP, LDAP, RADIUS.
Protocolos de gestión: SNMP, DHCP, HTTP, TELNET.
Media: RTP, RTCP.
La NGN debe se capaz de soportar una gran variedad de servicios con especificación de
Calidad de Servicios. Para lograrlo podrían emplearse diferentes mecanismos de control de
la QoS, que correspondan a las diferentes tecnologías y modelos comerciales posibles.
Esos mecanismos de soporte de la QoS influyen sobremanera en la arquitectura que puede
se necesaria para proporcionarlos. De hecho existen varias alternativas diferentes que
dependen, por ejemplo, de las capacidades del terminal de usuario o de las necesidades del
servicio. [63]
En el PS cubano se emplean algunos de estos protocolos, los cuales han sido debidamente
homologados. Estos protocolos tienen una estrecha relación con la QoS final percibida por
los clientes.
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 58
TCP
Funciona con todas las garantías de los protocolos que establecen sesiones, posee
excelentes mecanismos de control de ventanas, corrección de errores, y retransmisiones en
los casos de pérdidas de paquetes, sin embargo no es apropiado para comunicaciones de
“tiempo real”, debido a que es un protocolo complejo, y se torna un poco lento, lo que
puede afectar considerablemente el tráfico de voz. [10]
UDP
Es un protocolo de nivel de transporte al igual que TCP, sin embargo es un protocolo más
liviano, “no orientado a conexión”; cede funciones más complejas a protocolos superiores.
Sus características de rapidez son aprovechadas por protocolos de capas superiores, como
el RTP para establecer flujos de tráfico de “tiempo real”. [10]
H.248
A través de este protocolo ocurre la señalización previa al establecimiento de llamadas,
mediante el mismo se determina el portador (Voz, video), y los algoritmos de codificación
más apropiados al tipo de comunicación de “tiempo real”; o los que estén debidamente
autorizados por el administrador del sistema. [10]
SIP
El SIP es un protocolo que puede utilizar otros protocolos del IETF, para construir una
arquitectura completa de sistemas multimedias y proporcionar la regeneración de la QoS.
SIP debe utilizarse conjuntamente con otros protocolos para proporcionar servicios
completos a los usuarios. [10]
RTP
Existen extensiones al tipo de carga RTP y a RTCP para propiciar un mejor manejo de la
QoS. El principal objetivo reside en adaptar RTP a los requerimientos de bajas demoras
para las aplicaciones de “tiempo real”, lo hace que RTP sea más confiable. En cierto
sentido se emula TCP a través de retransmisiones seleccionadas. Para hacer esto posible, la
carga normal de RTP/RTCP debe ser ligeramente modificada. El protocolo de transporte
inferior seleccionado es UDP/IP. Una solución muy simple a las pérdidas de paquetes
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 59
radica en enviar información redundante mediante el envío de múltiples copias de los
paquetes de datos; con el inconveniente del incremento de tráfico en la res. [10]
3.3 Codificadores (CODECS)
Un CODEC es un elemento que convierte una señal analógica en un formato digital para
transmitirla y luego convertirla nuevamente en un formato descomprimido de señal para
poder reproducirla en el receptor. Esta es la esencia de la VoIP, la conversión de señales
entre analógico-digital.
La paquetización de diferentes protocolos introducen demoras diferentes (ver Anexo #8)
esto debe tenerse en cuenta junto a otros parámetros de QoS como el ancho de banda a la
hora de seleccionar los CODECs a emplear en comunicaciones de voz.
Un procedimiento de codificación tendrá mejor rendimiento cuanto más reduzca el tamaño
del archivo, sin degradar en exceso la información, economizando así los recursos de la red.
Para poder transmitir las muestras codificadas de voz sobre redes de datos, es necesario
armar paquetes. Para minimizar la sobrecarga del armado de paquetes y no introducir
demoras inaceptables, se toman ventanas de 10 a 30 ms. Las muestras de voz de cada una
de estas ventanas consecutivas se acumulan y con ellas se forman los paquetes de voz. En
el Anexo #9; se muestra el impacto sobre la QoS del CODEC G.711. Los CODECs tienen
una estrecha relación con la QoS, especialmente sobre el retardo. Existen retardos que se
deben a los algoritmos de compresión: En forma genérica, cuanto mayor es la compresión,
más demora hay en el proceso (los CODEC requieren más tiempo para codificar cada
muestra).
En la tabla #1 se muestran las demoras típicas introducidas por los algoritmos de
Codificaciones más empleados en NGN. [64]
Algoritmo de muestreo/compresión
Demora típica introducida
G.711 (64 Kbps) 125 µs
G.729 (8 Kbps) 10 ms
G.723 (5,3 o 6,4 Kbps) 30 ms
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 60
3.4 Establecimiento de una llamada VoIP en el caso de la NGN cubana
En este sub-epígrafe aportamos los elementos fundamentales sobre un análisis real del
establecimiento de una llamada en la arquitectura NGN que se encuentra trabajando en la
Red Fija de telecomunicaciones de Cuba.
En nuestro caso real, el equipo de acceso (MGW) en que basamos el análisis es un UA5000
(Equipo Universal de acceso, que maneja interfaces con terminaciones POTs, este equipo
solamente responde por una IP, y el resto de las terminaciones “no inteligentes” son
mapeadas mediante un parámetro denominado Tid (Identificación del Terminal, por sus
siglas en inglés). Además participa como MGC un equipamiento denominado Softx 3000.
Para que un equipo de acceso pueda comenzar a efectuar llamadas en NGN, lo primero que
debe ocurrir es el registro de MGW en el MGC. En el caso de ser aceptada la petición de
registro, entonces MGW podrá iniciar, o recibir llamadas. En el Anexo # 10, puede
apreciarse el intercambio de señales en H.248 para que ocurra el registro. Después que el
MGW completa el registro de forma satisfactoria, el MGC modifica las propiedades de
todas las terminaciones semi-permanentes del MGW contenidas en el contexto nulo. Al
mismo tiempo le indica al MGW detectar los eventos de descolgado de los puertos del
equipo de acceso.
Después del registro acertado, el MGC realiza operaciones en la terminación del MGW en
el contexto nulo y modifica las características de la terminación con el comando MODIFY.
Las distintas secuencias basadas en comandos pasados a través de los mensajes puede
apreciarse en el Anexo #11.
En el Anexo #12 pueden apreciarse los diagramas de flujos H.248 con la explicación de los
principales mensajes que se intercambian en el establecimiento de una llamada VoIP, que
se establece entre un abonado perteneciente a un UA5000 de Guantánamo, y uno
perteneciente a un UA5000 de Baracoa. [64]
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 61
3.5 Propuesta de arquitectura de NGN con IPv6
El propósito primario de las soluciones de transición hacia IPv6, consiste en permitir a los
operadores que ofrecen servicios sobre la arquitectura NGN que provean servicios a
clientes que han desplegado IPv6 en sus redes. [7]
Como mencionamos anteriormente, en Cuba la tecnología que se emplea en el transporte es
MPLS, y teniendo en cuenta las mejores garantías de QoS, en nuestra propuesta con la
migración de los principales actores de NGN hacia IPv6; pero manteniendo el núcleo de
MPLS con IPv4, y todas las configuraciones elaboradas en base a IPv4, como la Ingeniería
de tráfico; el manejo de la QoS, la fiabilidad de la red, entre otras. Proponemos actualizar
los PE para que manejen la dualidad de protocolos (IPv4/IPv6); e implementar el
mecanismo 6VPE [38] como se muestra en la figura #15.
Figura #15 Redes Privadas Virtuales, 6VPE. [65]
El mecanismo 6VPE emplea la infraestructura MPLS con IPv4 en el núcleo para proveer
VPN/IPv6, empleando el plano de control con IPv4 (LDPv4, TEv4, IGPv4). Además
emplea características arquitecturales similares a los que emplean las VPNv4 como son: RT
(Route Target), VRF (Virtual Routing and Fowarding) pueden contener rutas VPNv4, y
VPNv6, RD (Route Distinguísh); asociados a IPv6 para formar las direcciones VPNv6. [65]
En la figura #16 mostramos la propuesta de arquitectura NGN durante la transición hacia
IPv6 por parte de los PS cubanos; en el que se implementa una VPNv6 para manejar tanto
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 62
el tráfico de señalización, como el de voz; empleando el mecanismo 6VPE [38]. El MP-
BGP tiene que ser actualizado como mencionamos con anterioridad, para que distribuya
tanto las familias de direcciones IPv4, como IPv6.
La red Metro y demás dispositivos de nivel 2 (Lanswitch) no sufren cambios en cuanto al
manejo de IPv6.; los elementos que participan en el control y cualquier otro enrutador que
exista en la arquitectura NGN deben ser actualizados para que manejen el nuevo protocolo
de red, IPv6.
Los equipos de acceso deben ser actualizados a IPv6, mientras que los dispositivos finales
en la aproximación del PS cubano no sufren ninguna modificación debido a que no poseen
inteligencia embebida. Los paquetes IPv6 atravesarán la red metro para interconectarse a
través de la VPN de NGN, mediante el mecanismo 6VPE; con el resto de los elementos que
forman la arquitectura NGN.
Obteniéndose una propuesta donde los principales actores de la arquitectura NGN de Cuba:
los MGW, los MGC, y todos los actores de NGN que manejan la capa de red deben ser
actualizados para que manejen de manera nativa IPv6; manteniendo la capa de transporte
IP/MPLS con IPv4 en el núcleo; para no alterar el comportamiento del resto de los clientes
que se apoyan en este backbone para extender sus redes privadas por todo el país. Esta
propuesta se aproxima al Escenario D descrito por la ITU-T [7]
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 63
Figura #16 Arquitectura NGN con IPv6 con 6VPE en el núcleo MPLS.
3.6 Consideraciones de Seguridad
En el PS la seguridad en la arquitectura resulta de vital importancia para la continuidad del
servicio, y para el aseguramiento de la facturación de las llamadas. En la propuesta de
transición hacia IPv6 de la arquitectura NGN en Cuba, los elementos de seguridad, que por
supuesto intervienen en la seguridad de nivel de red; deben ser actualizados para que
manejen IPv6; tanto a nivel de red, como a nivel de aplicación.
Además la seguridad en si constituye un aspecto significativo dentro de la QoS. Por
ejemplo si una red aplica diferentes QoS a diferentes paquetes, esto crea un incentivo a los
clientes para tratar de aplicar sin autorización la mejor QoS a sus paquetes. En una red con
el modelo del “mejor esfuerzo”, los clientes no se interesan por diferenciar sus paquetes en
cuanto a QoS, debido a que todos los paquetes son tratados de manera similar. No existen
CAPÍTULO 3. PROPUESTA DE SOLUCIÓN NGN EMPLEANDO VoIPV6 64
mecanismos de seguridad para validar el campo “Tipo de Servicio” del datagrama IP, el
campo “Precedente bits” de la trama Ethernet. Incluso si existieran estos mecanismos
resultaría impráctico su implementación debido al encarecimiento del hardware debido que
se necesitaría, por ejemplo, autenticar cada trama que se encuentra atravesando un enlace
10 GB Ethernet. [66]
La mejor solución para la seguridad reside en el modelo de proveer puntos de seguridad en
los extremos de la red, y efectuar el control en cuanto a QoS empleando Listas de Acceso
(ACL, por sus siglas en inglés). Mediante las ACLs los paquetes que no están debidamente
marcados, así como los que se encuentran marcados erróneamente; pueden marcarse de
acuerdo a las políticas establecidas por el PS. [66] Esta técnica tiene la ventaja de que la
complejidad de la seguridad de la QoS no se distribuye por toda la red, simplificando la
configuración de los nuevos actores dentro de la NGN, incluso en el entorno de transición
hacia IPv6; sin embargo se crean puntos críticos; donde pueden existir fallos, o colas por
diversos motivos que pudieran atentar contra la QoS extremo a extremo.
3.7 Conclusiones del capitulo
En este capítulo se desarrolló una caracterización de la tecnología NGN empleada en Cuba
como punto de partida para efectuar una propuesta al PS para la migración de la NGN hacia
IPv6. Como base de la propuesta sugerimos migrar todos los actores de la NGN excepto el
nivel de transporte, donde se identificó IP/MPLS como la tecnología implementada en
Cuba con mejores perspectivas de soportar el tránsito hacia IPv6, mediante el empleo de
6VPE; que no altera el núcleo de MPLS, mantiene todas las configuraciones funcionales
de IPv4 en cuanto a QoS, Ingeniería de Tráfico, enrutamiento, etc. Además proponemos
emplear el modelo “Servicio Diferenciado” para ofrecer garantías tanto al tráfico de
señalización como al tráfico de voz.
CONCLUSIONES Y RECOMENDACIONES 65
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
1 La transición hacia IPv6 es un hecho inaplazable, y la NGN cubana debe ser migrada
antes que la mayoría de los clientes que emplean el nivel de red, teniendo en cuenta el
hiperciclo de la industria, y el posible retiro del soporte técnico a IPv4.
2 En nuestra propuesta es necesario migrar todos los elementos de NGN, incluyendo
dispositivos, y aplicaciones hacia IPv6, excepto el nivel de transporte; que funcionará
con la dualidad IPv4/IPv6, en tanto no migren el resto de los servicios soportados por
el PS.
3 El análisis efectuado arroja que el PS en Cuba está en condiciones de aprovechar la
arquitectura IP/MPLS con IPv4 en el núcleo, y el servicio 6VPE para afrontar la
migración oportuna de la NGN hacia IPv6; garantizando la QoS aplicada en el núcleo
de MPLS, a la VPN de NGN.
4 El PS cubano se encuentra en un período de tránsito de las PSTN hacia las
arquitecturas NGN, y para garantizar una QoS razonable ha homologado diversos
CODECs, y aplica el método “Servicio Diferenciado” desde el origen del tráfico,
hasta su destino; garantizando un mapeo de las categorías de tráfico, entre todos los
niveles de la red por donde pasan los paquetes de “tiempo real”; incluyendo IP/MPLS
actualizado para manejar VPN con las técnicas 6VPE.
CONCLUSIONES Y RECOMENDACIONES 66
Recomendaciones
1 Recomendamos velar por una adecuada configuración de las interfaces tanto en
dispositivos de nivel 2, como de nivel 3; para que no ocurran fragmentaciones
indebidas, que afecten la QoS del tráfico de voz.
2 Introducir herramientas de gestión y supervisión en la capa de transporte (IP/MPLS),
que sirvan para implementar, y supervisar dinámicamente las medidas de Ingeniería
de tráfico aplicadas a las redes, parámetros de QoS; especialmente del tráfico de voz;
debidamente diferenciado, y priorizado en este backbone compartido, y capaz de
transportar diferentes protocolos, en diferentes configuraciones, de diferentes
clientes.
3 Realizar normas para el estudio, y redimensionamiento del nivel de transporte de
acuerdo al comportamiento del ancho de banda de la red.
4 Recomendamos configurar dos VPN distintas para separar el tráfico de “tiempo real”
(VoIP) del tráfico de señalización de NGN.
5 Realizar mediciones de los parámetros de QoS teniendo en cuenta las clasificaciones
homologadas en el PS según el método Servicios Diferenciados (DiffServ); con el
objetivo de ajustar la cantidad de categorías a un mínimo razonable según las
capacidades de procesamiento de los dispositivos, y la importancia, y
comportamiento de los distintos tipos de tráficos ante la QoS.
REFERENCIAS BIBLIOGRAFICAS 67
REFERENCIAS BIBLIOGRÁFICAS
1. Microsoft, I. Preguntas mas frecuentes sobre el protocolo IPv6 para la familia de Windows Server 2003. 2007 [cited 2012 3 de enero]; Available from: http://www.microsoft.com/spain/windowsserver2003/technologies/ipv6/ipv6faq.mspx.
2. Rodrigo, R.d.S., et al. Curso IPv6 Básico. [PDF] 2010 [cited 2011 19 de Marzo].
3. Marín Abreu, A.L., Estrategias para la Transición hacia IPv6 en ETECSA, como Proveedor de Servicios de Datos., in Telemática. 2007, UCLV: Santa Clara.
4. cidr-report. IPv4 Address Report. [Pág Web] 2011 [cited 2012 13 de enero]; Available from: http://www.potaroo.net/tools/ipv4/.
5. UIT-T. Recomendación UIT-T G.704. [PDF] 1998 [cited 2012 20 de Marzo]; Available from: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.704-199810-I!!PDF-S&type=items.
6. ITU. Y.2001-SERIES GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NGN. [PDF] 2004 [cited 2012 6 de enero]; Available from: http://www.itu.int/itudoc/itu-t/aap/sg13aap/history/y2001/index.html.
7. ITU. Roadmap for IPv6 Migration from NGN Operators’ Perspectives, ITU-T draft Recommendation Y.ipv6migration. [PDF] 2010 [cited 2012 13 de Enero]; Available from: https://datatracker.ietf.org/documents/LIAISON/file961.pdf.
8. Gómez Valdivia, J.R. Arquitectura de Redes (TCP/IP) [PPT] 2010 [cited 2012 6 de Enero].
9. Fransman, M. EVOLUTION OF THE TELECOMMUNICATIONS INDUSTRY INTO THE INTERNET AGE1. [PDF] 2000 [cited 2012 13 de Enero]; Available from: http://www.telecomvisions.com/articles/pdf/FransmanTelecomsHistory.pdf.
10. Minoli, D. Voice over IPv6: Architectures for Next Generation VoIP Networks. [PDF] 2007 [cited 2012 17 de Enero]; Available from: http://www.voiceip.com.ua/lit/Voice%20Over%20IPv6%20-%20075068206X.pdf.
11. Romero, M.d.C.T. Calidad de Servicio (QoS) en redes. [PDF] 2010 [cited 2012 13 de Enero]; Available from: http://www.dte.us.es/personal/mcromero/masredes/docs/SMARD.0910.qos.pdf.
12. Suthar, T. IPv6—A Service Provider View in Advancing MPLS Networks. . [PDF] 2006 [cited 2012 16 de enero]; Available from: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-2/ipv6.html.
13. CISCO. Cisco Visual Networking Index: Forecast and Methodology, 2010-2015. [PDF] 2012 [cited 2012 29 de Febrero]; Available from:
REFERENCIAS BIBLIOGRAFICAS 68
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html.
14. UIT-T. Recommendation X.25. [PDF] 1998 [cited 2012 21 de Mayo]; Available from: http://www.itu.int/rec/T-REC-X.25-199809-I!Cor1.
15. Gómez Valdivia, J. MPLS. MIGRACIÓN Y SU APLICACIÓN EN REDES PRIVADAS VIRTUALES. [Doc] 2004 [cited 2012 20 de Marzo].
16. ITU-T. ITU-T Recommendations. [Pág. Web] 2012 [cited 2012 24 de Mayo]; Available from: http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx.
17. ITU-T. I series: Integrated services digital network. [Pág. Web] 2010 [cited 2012 24 de Mayo]; Available from: http://www.itu.int/ITU-T/recommendations/index.aspx?ser=I.
18. Gai, S. IPv6 The new protocol for Internet and Intranets. [Pág. Web] [cited 2012 21 de Mayo]; Available from: http://www.ip6.com/us/book/.
19. Mashable, I. IPv4. [Pág. Web] 2012 [cited 2012 10 de Abril]; Available from: http://mashable.com/follow/topics/ipv4.
20. Postel, J. RFC: 791 INTERNET PROTOCOL. 1981 [cited 2012 3 de Abril]; Available from: http://www.rfc-es.org/rfc/rfc0791-es.txt.
21. Law., D. IEEE 802.3 ETHERNET WORKING GROUP [Pág. Web] 2011 [cited 2012 24 De Mayo]; Available from: http://www.ieee802.org/3/.
22. Montañana, R. EL NIVEL DE RED EN INTERNET. 2005 [cited 2012 10 de abril]; Available from: http://www.uv.es/montanan/redes/redes_03.doc.
23. Marín Abreu, A.L. Impactos sobre las Redes de Próxima Generación de la Migración hacia IPv6. [PDF] 2011 [cited 2012 11 de Enero].
24. AT&T. "AT&T-New Generation of the Internet Protocol". [PDF] 2006 [cited 2012 2 de abril]; Available from: http://www.corp.att.com/gov/ipv6/IPv6_wh_pp06.pdf.
25. Huston, G. "Anatomy: A Look Inside Network Address Translators". [Pag Web] 2004 [cited 2012 2 de abril]; Available from: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html.
26. Marín Abreu, A.L. RETOS DE SEGURIDAD CON IPV6 EN UN ENTORNO UBICUO. [PDF] 2011 [cited 2012 11 de Enero].
27. Depletion, I.A. IPv4 Address Depletion. [Pág. Web] 2007 [cited 2012 11 de Enero]; Available from: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-3/103_addr-dep.html.
28. Deering, S. and R. Hinden. RFC 2460 Internet Protocol, Version 6 (IPv6). [Pág. Web] 1998 [cited 2012 17 de Mayo]; Available from: http://www.ietf.org/rfc/rfc2460.txt.
29. CISCO, S.y. "IPv6 Deployment Strategies". [Página Web] 2005 [cited 2012 13 de abril]; Available from:
REFERENCIAS BIBLIOGRAFICAS 69
http://www.cisco.com/en/US/tech/tk872/technologies_white_paper09186a00800c9907.shtml.
30. Gilligan, R.y.N., E. RFC 2893. Transition Mechanisms for IPv6 Hosts and Routers. [Página Web] 2000 [cited 2012 11 de abril]; Available from: http://www.ietf.org/rfc/rfc2893.txt.
31. Durand, A.F., P.;Guardini, I.; y Lento, D. RFC 3053 - IPv6 Tunnel Broker. [Página Web] 2001 [cited 2012 11 de abril]; Available from: http://www.faqs.org/rfcs/rfc3053.html.
32. Kotal, V. "Principles, implementation and transition to IPv6 protocol." [PDF] 2006 [cited 2012 10 de abril]; Available from: http://techie.devnull.cz/skola/master-thesis/.
33. Crawford, M.y.F. RFC 2464-Transmission of IPv6 Packets over Ethernet Networks. [TXT] 1998 [cited 2012 12 de abril]; Available from: http://www.arin.net/reference/rfc/rfc2464.txt.
34. Armitage, G.S., P. y Jork, M. RFC 2492-IPv6 over ATM Networks. [Página Web] 1999 [cited 2012 12 de abril]; Available from: http://www.faqs.org/rfcs/rfc2492.html.
35. Rosen, E., A. Viswanathan, and R. Callon. RFC 3031 - Multiprotocol Label Switching Architecture. [Pág. Web] 2001 [cited 2012 13 de Enero]; Available from: http://www.faqs.org/rfcs/rfc3031.html.
36. Ataucuri, D.D. IPV6 como protocolo núcleo de las redes de nueva generación. Situación actual y perspectivas." [PDF] 2002 [cited 2012 13 de abril].
37. Muthukrishnan, K.y.M., A. RFC 2917 - A Core MPLS IP VPN Architecture. [Página Web] 2000 [cited 2012 3 de abril]; Available from: http://www.faqs.org/rfcs/rfc2917.html.
38. Clercq, J.D.C., M. y Faucheur, F. Le. RFC 4659 - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. [Página web] 2006 [cited 2012 3 de abril]; Available from: http://tools.ietf.org/html/rfc4659.
39. Farinacci, D.L., T.;Hanks, S.;Meyer, D.; y Traina, P. RFC 2784 - Generic Routing Encapsulation (GRE). [Página Web] 200 [cited 2012 4 de abril]; Available from: http://www.faqs.org/rfcs/rfc2784.html.
40. Guichard, J.F., François Le y Vasseur, Jean-Philippe. Definitive MPLS Network Designs. IPv6 Over MPLS Networks. [Página Web] 2005 [cited 2012 4 de abril]; Available from: http://www.fengnet.com/book/Definitive%20MPLS%20Network%20Designs/toc.html.
41. CISCO y Östling, J. IPv6@Cisco The present and the future…. [PDF] 2004 [cited 2012 6 de abril]; Available from: http://www.noc.kth.se/sunet/ipv6/pdf/Cisco_IPv6_Update.pdf.
REFERENCIAS BIBLIOGRAFICAS 70
42. CISCO. IPV6 OVER MULTIPROTOCOL LABEL SWITCHING: IPV6 PROVIDER EDGE ROUTER AND IPV6 VPN PROVIDER EDGE ROUTER". [PDF] 2004 [cited 2012 6 DE ABRIL]; Available from: http://www.cisco.com.
43. Clercq, J.D.O., D.;Prevost, S.; y Faucheur, F. Le. RFC 4798-Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). [TXT] 2007 [cited 2012 9 de abril]; Available from: http://www.ietf.org/rfc/rfc4798.txt.
44. Semeria, C. RFC 2547bis: BGP/MPLS VPN Fundamentals. [PDF] 2001 [cited 2012 30 de marzo]; Available from: http://www.juniper.net/solutions/literature/white_papers/200012.pdf.
45. CONVERGENCIA HACIA REDES NGN. [PDF] 2010 [cited 2012 20 de marzo].
46. Postel, J. and J. Reynolds. RFC 959 FILE TRANSFER PROTOCOL (FTP). [Pág. Web] 1985 [cited 2012 17 de Mayo]; Available from: http://www.w3.org/Protocols/rfc959/.
47. Suominen, K. Electronic Mail Related RFC Documents. [Pág. Web] 1998 [cited 2012 17 de Mayo]; Available from: http://www.tac.nyc.ny.us/mail/rfc-index.html.
48. W3C. HTTP - Hypertext Transfer Protocol. [Pág. Web] 2012 [cited 2012 17 de Mayo]; Available from: http://www.w3.org/Protocols/.
49. Marín Abreu, A.L. Calidad de Servicio de la Voz sobre el Protocolo de Internet en escenarios de transición hacia IPv6. [PDF] 2012 [cited 2012 30 de Enero]; Available from: http://uciencia.uci.cu/es/node/1746.
50. Huawei. Additional Student Manual for QoS Technologies. [Doc] 2012 [cited 2012 22 de Mayo].
51. Gómez Valdivia, J. MPLS. Curso introductorio. [PDF] 2012 [cited 2012 8 de Junio].
52. Wilkins, S. Cisco Voice Over IP (VoIP) QoS Basics. [Pág. Web] 2011 [cited 2012 22 de Mayo]; Available from: http://www.petri.co.il/voip-quality-of-service-basics.htm.
53. Schulzrinne, H., et al. RFC 1889-RTP: A Transport Protocol for Real-Time Applications. [Pág. Web] 1996 [cited 2012 4 de Junio]; Available from: http://www.ietf.org/rfc/rfc1889.txt.
54. Martin, J. VoIP Quality of Service - Basic Theory. [PDF] 2009 [cited 2012 22 de Mayo]; Available from: http://www.pacnog.org/pacnog5/track4/presos/PacNOG5_voip_qos.pdf.
55. Cranley, N., L. Fiard, and L. Murphy. Quality of Service for Streamed Multimedia over the Internet. [PDF] 2007 [cited 2012 8 de Junio]; Available from: http://pel.ucd.ie/files/quality%20of%20service.pdf.
56. Gil Cabezas, J. PROTOCOLO DE TRANSPORTE EN TIEMPO REAL RTP [PDF] 2009 [cited 2012 8 de Junio]; Available from: http://www.uco.es/~i62gicaj/RTP.pdf.
REFERENCIAS BIBLIOGRAFICAS 71
57. Olivera Moreno, R. Propuesta de Implementación de NGN en Granma. [PDF] 2006 [cited 2012 24 de Mayo].
58. Schulzrinne, H., A. Rao, and R. Lanphier. RFC 2326-Real Time Streaming Protocol (RTSP). [Pág. Web] 1998 [cited 2012 4 de Junio]; Available from: http://www.ietf.org/rfc/rfc2326.txt.
59. Cuervo, F., et al. RFC 3015- Megaco Protocol Version 1.0. [Pág. Web] 2000 [cited 2012 4 de Junio]; Available from: http://www.ietf.org/rfc/rfc3015.txt.
60. Handley, M. and V. Jacobson. RFC 2327- SDP: Session Description Protocol. [Pág. Web] 1998 [cited 2012 4 de Junio]; Available from: http://www.ietf.org/rfc/rfc2327.txt.
61. ITU-T. H.323 : Packet-based multimedia communications systems. [PDF] 2009 [cited 2012 5 de Junio]; Available from: http://www.itu.int/rec/T-REC-H.323-200912-I/en.
62. McCann, J., S. Deering, and J. Mogul. RFC-1981 Path MTU Discovery for IP version 6. [Pág. Web] 1996 [cited 2012 4 de Junio]; Available from: http://www.ietf.org/rfc/rfc1981.txt.
63. Camacho Aguilera, R.L. Propuesta de situación de las Centrales Tandem con tengnoñogía de Redes de Próxima Generación. [PDF] 2011 [cited 2012 24 de Mayo].
64. Marín Muro, Y. Establecimiento de una llamada con H248. [Doc] 2012 [cited 2012 12 de Junio].
65. Contreras, G. IPv6 over MPLS 6PE and 6VPE. [PDF] 2007 [cited 2012 5 de Junio]; Available from: http://lacnic.net/documentos/seminarios/6PE_6VPE_LACNIC.pdf.
66. Networks, E. Quality of Service for Voice-over-IP Networks. [PDF] 2006 [cited 2012 8 de Junio]; Available from: http://www.extremenetworks.com/libraries/whitepapers/WPQoSVoIPNetworks_1314.pdf.
67. Gómez Valdivia, J., Modelo OSI y otras Arquitecturas, in PPT. 2008.
68. IANA. IANA Home Page. [Página Web] 2006 [cited 2012 26 de marzo]; Available from: http://www.iana.org/.
ACRONIMOS 72
ACRONIMOS
ADSL (Asymetric Digital Subscriber Line.)
AFI (Address Family Identifier.)
ALG (Aplication Layer Translation)
AMGs (Access Media Gateways, Pasarelas de Acceso .)
ARPANET (Red de la Agencia de Proyectos de Investigación Avanzada.)
ATM (Asynchronous Transfer Mode.)
BE (Best-Effort.)
BIS (Bump-In-the-Stack.)
B-ISDN (Red Digital de Servicios de Banda Ancha.)
CAR (Committed Access Rate.)
CBQ (Class-based Queue.)
CBWFQ (Cola según su peso justo-basado en clases.)
CCSS7 (Common Channel Signaling System 7).
CE (Custumer Edge.)
CoS (Clase de Servicio.)
CQ (Colas Personalizadas.)
CIDR (Classless Inter-domain Routing.)
CPE (Costumer Premise Equipment.)
DHCP (Dynamic Host Configuration Protocol.)
DNS (Domain Name System.)
ACRONIMOS 73
DS (Differentiated Service.)
DSCP (Differentiated Service Codepoint.)
DSL (Digital Subscriber Line, Líneas de Subscriptor Digital.)
DSTM (Dual Stack Transitios Mechanism.)
DTMF (Tonos Duales de Multifrecuencia)
ETECSA (Empresa de Telecomunicaciones de Cuba S.A.)
FIFO (First In First Out.)
FO (Fibra Óptica.)
FR (Frame Relay.)
FRR (Fast Re-Route.)
FTP (File Transfer Protocol, Protocolo de Transferencia de Ficheros.)
GRE (Generic Routing Encapsulation.)
GW (Gateways.)
HTTP (Hypertext Transport Protocol, Protocolo de Transferencia de Hiper Texto.)
IADs (Integrate Access Devises, Dispositivos de Acceso Integrado.)
IETF (Internet Engineering Task Force.)
IP (Internet Protocol.)
IPSec (Internet Protocol Security.)
IS (Integrated Service.)
ISATAP (Intrasite Automatic Tunnel Addressing Protocol.)
ISDN (Integrated Services Digital Network.)
ISP (Internet Service Provider.)
LAN (Local Area Network.)
LDP (Label Distribution Protocol.)
ACRONIMOS 74
LFI (Link Fragmentation and Interleaving.)
MAN (Metropolitan Area Network.)
MGs (Media Gateways, Pasarelas de Medios.)
MGC (Media Gateway Controller, Controlador de Pasarelas de Medios.)
MGCP (Media Gateway Control Protocol, Protocolo de Control de Pasarela de Medios.)
MPLS (Multiprotocol Label Switching, Conmutación por Etiquetas del Multiprotocolo.)
MP-BGP (Multi Protocol-Border Gateway Protocol.)
NAT (Network Address Translation.)
NAT-PT (Network Address Translator-Protocol Translator.)
NGN (Nex Generation Network.)
P (Provider.)
PBXs (Private Branch Exchange.)
PE (Provider Edge.)
PPP (Point to Point.)
PQ (Prioridad de Colas.)
PS (Proveedor de Servicio.)
PSTN (Public Switched Telephony Network.)
PVC (Private Virtual Circuit.)
QoS (Quality of Service.)
RD (Route Distinguisher.)
RDSI (Red Digital de Servicios Integrados.)
RFC (Request For Comments.)
ROAD (Routing and Addressing.)
RR (Reflector Route.)
ACRONIMOS 75
RSVP (Protocolo de Reserva de Recursos.)
RTCP (Real –time Transport Control Protocol.)
RTP (Real-time Transport Protocol, Protocolo de Transporte en Tiempo Real.)
RTPQ (Protocolo de Cola de transporte de Tiempo Real.)
RTSP (Real Time Streaming Protocol, Protocolo de Transmisión de Flujo Continuo en
Tiempo Real.)
SAFI (Sub Address Family Identifier)
SCN (Switchet Circuit Network.)
SCTP (Stream Control Transmission Protocol, Protocolo de Control de Transmisión de
Cadena.)
SDH (Synchronous Digital Hierarchy.)
SG (Signaling Gateway, Pasarelas de Señalización.)
SHDSL (Symmetric High Speed Digital Subscriber Line.)
SIGTRAN (SIGnaling TRANsport.)
SIP (Session Inition Protocol, Protocolo de Inicialización de Sesiones)
SMGs (Signaling Media Gateways, Pasarelas de Señalización de Medios.)
SNMP (Simple Network Management Protocol,)
TCP (Transmission Control protocol, Protocolo de Control de Transmisión.)
TDM (Multiplexadores por División de Tiempo.)
TE (Traffic Engineering.)
TMGs (Trunk Media Gateways, Pasarelas Troncales.)
ToS (Tipo de Servicio.)
UA (Universal Access)
UCLV (Universidad Central de las Villas.)
UDP (User Datagram Protocol.)
ACRONIMOS 76
UGP (Unicast Global Prefix.)
UMG (Universal Media Gateways, Pasarela de Medios Universal.)
VC (Circuitos Virtuales.)
VoIP (Voice Over Internet Protocol.)
VPN (Virtual Private Network , Redes Privadas Virtuales.)
VRF (Virtual Route Forwarding.)
WAN (Wide Area Network.)
WFQ (Detección Temprana de Pesos tomados al azar.)
WRED (Weighted Random Early Detection.)
xDSL (x-type Digital Subscriber Line, Línea de Abonado Digital tipo - x.)
GLOSARIOS 77
GLOSARIOS
A
ADSL (Asymetric Digital Subscriber Line: Tecnología que permite transmitir información
digital a grandes velocidades a través de las líneas telefónicas convencionales. Es
asimétrica porque usualmente en subida la mayor velocidad es mayor que en bajada.)
Anycast (Es una comunicación entre un único transmisor y lo más cercanos de varios
receptores en un grupo.)
B
Backbone (Mecanismo de conectividad primario en un sistema distribuido. Todos los
sistemas que tengan conexión al backbone (columna vertebral) pueden interconectarse entre
sí, aunque también puedan hacerlo directamente o mediante redes alternativas.)
C
CE (Customer Edge Router: Es un enrutador situado en el lado del cliente, el cual provee
una interfase Ethernet entre la LAN del cliente y la red de núcleo del proveedor.)
E
e-learning (Aprendizaje que es facilitado por el uso de herramientas digitales, y contenido
de Internet.)
G
Gateway (Puerta de Acceso: Dispositivo que permite conectar entre si dos redes
normalmente de distinto protocolo o un Host a una red. En Español: Pasarela)
GRE (Generic Routing Encapsulation: Protocolo de tunelización desarrollado por CISO
para encapsular una amplia gama de paquetes son diferentes tipos de protocolos dentro de
un túnel IP.)
I
GLOSARIOS 78
IP/MPLS (Es una plataforma que combina la conmutación de etiquetas con el
enrutamiento de la capa de red. Soporta el transporte de múltiples protocolos de capas
superiores, y garantiza la seguridad durante la transmisión de la información. Puede ser
considerado como el backbone de algunos proveedores. [19])
IPv4 (IPv4 es la versión 4 del Protocolo IP [Internet Protocol]. Esta fue la primer versión
del protocolo que se implemento extensamente, y forma la base de Internet.)
IPv6 (IPv6 es la versión 6 del protocolo IP [Internet Protocol]. Es la versión que está
destinada a sustituir al actual estándar IPv4.)
IPSec (Internet Protocol Security: Es un estándar para proveer seguridad en la capa de red,
o la capa de procesamiento del paquete.)
L
LDP (Label Distribution Protocol: Protocolo que define la distribución de etiquetas.)
M
Multicast (Comunicación entre un solo emisor y múltiples receptores.)
N
NGN (Redes de Próxima Generación: NGN es una red basada en paquetes; capaz de
proveer servicios de telecomunicaciones, y de emplear diferentes anchos de banda. Emplea
tecnologías de transporte que manejan la calidad de servicio (QoS) según las necesidades
del tráfico; y además las funciones relacionadas con los servicios son independientes de las
tecnologías o niveles que subyacen por debajo del nivel de aplicación de la arquitectura
TCP/IP. [18])
P
P (Provider: Es un enrutador situado en el núcleo de la red del proveedor.
Los enrutadores CE se conectan a los enrutadores PE; y estos se conectan con otros
enrutadores PE a través de los enrutadores P; y de esta manera se conforman las estructuras
básicas de un backbone MPLS.)
PE (Provider Edge Router: Es un enrutador situado en el borde de la red del proveedor.)
GLOSARIOS 79
Pasarela (o gateway en inglés: es un dispositivo, que realiza la conversión de protocolos
entre diferentes tipos de redes o aplicaciones)
Q
QoS (Calidad de Servicio: Efecto global de las prestaciones de un servicio que determinan
el grado de satisfacción de un usuario al utilizar dicho servicio. El término Calidad de
servicio no se emplea para expresar niveles de excelencia en el sentido comparativo, sino
en el sentido cuantitativo, para efectuar evaluaciones tecnológicas. [17])
R
Router (Un router (enrutador o encaminador) es un dispositivo hardware o software de
interconexión de redes de ordenadores/computadoras que opera en la capa 3 (nivel de red)
del modelo OSI. Este dispositivo interconecta segmentos de red o redes enteras. Hacen
pasar paquetes de datos entre redes tomando como base la información de la capa de red.)
RR (El Route Reflector ofrece una alternativa a la necesidad de implementar un malla
completa de iBGP. El RR actúa como el punto central para las sesiones iBGP. El
propósito de RR es la concentración. Múltiples enrutadores BGP pueden “hablar” con el
punto centra, donde el RR actúa como servidor reflector de rutas; e lugar de “hablar” con
cada uno de los enrutadores en la malla. Los demás enrutadores iBGP se convierten en
clientes RR.)
S
SDH (Synchronous digital hierarchy: Es una técnica avanzada para la transmisión de datos
sobre redes de FO)
T
TCP (Transport Control Protocol: Es uno de los protocolos de la capa de transporte de la
arquitectura TCP/IP más empleados en la actualidad.)
TCP/IP (Conjunto o familia de protocolos desarrollados para permitir a dispositivos [hosts]
heterogéneos compartir recursos a través de una red. Se diseñó teniendo en cuenta como
elemento básico la existencia de muchas redes interconectadas por medio de enrutadores o
pasarelas. Los protocolos TCP e IP son los más conocidos y de ahí el nombre generalizado.
GLOSARIOS 80
Algunas de sus características fundamentales son: Independencia de la tecnología de red
subyacente [abstracción del hardware]; interconexión universal [direccionamiento y
enrutamiento]; y estándares de protocolos de aplicación. [19])
Tunnel Broker (Es un servicio el cual provee un tunnel de red. Este túnel puede
proporcionar conectividad encapsulada sobre una infraestructura existente hacia una nueva
infraestructura.)
W
Web (La World Wide Web (del inglés, Telaraña Mundial), la Web o WWW, es un sistema
de hipertexto que funciona sobre Internet.)
ANEXOS 81
ANEXOS
Anexo #1 Propuesta del diseño de la Red IP/MPLS
Figura #17 Propuesta del Backbone IP/MPLS en Cuba.
ANEXOS 82
Anexo #2 Modelo OSI y Arquitectura TCP/IP
Figura #18 Analogía entre el modelo OSI y la Arquitectura TCP/IP. [67]
ANEXOS 83
Anexo #3 Formato de la cabecera de IPv4
Figura #19 Cabecera del datagrama IPv4. [8]
ANEXOS 84
Anexo #4 Formato de la cabecera de IPv6
Figura #20 Cabecera del datagrama IPv6. [10]
ANEXOS 85
Anexo #5 Mecanismos de Tunelización
Configuración Manual de Túneles IPv6.
IPv6 sobre IPv4 Túnel GRE.
Tunnel Broker.
Túnel Automático Compatible IPv4.
Túnel Automático 6to4.
Configuración Manual de Túneles IPv6.
Este tipo de túnel es equivalente a un enlace dedicado entre dos dominios IPv6 sobre un
backbone IPv4. El uso primario es para conexiones estables que requieren comunicaciones
regulares y seguras entre dos enrutadores de borde, entre un sistema final, y un enrutador
final; o para conectarse a una red IPv6 remota, como es el caso de 6bone. Cuando los
enrutadores de borde y los sistemas finales, se encuentran al final del túnel, se deben hacer
implementaciones dual stack. En cada extremo del túnel, se configuran las direcciones
IPv4 e IPv6 del enrutador dual stack en la interfase del túnel, y debe identificarse los
puntos fuente, y destino empleando direcciones IPv4.
Para las Empresas, el ISP provee el prefijo de dirección IPv6, y también el destino IPv4
requerido para el punto de destino del túnel. Véase la Figura #21.
Figura #21 Configuración manual de túneles IPv6. [3]
Debido a que cada túnel existe solamente entre dos enrutadores, cuando adicionamos
enrutadores debemos adicionar nuevos túneles para abastecer todos los caminos nuevos que
ANEXOS 86
se crean entre los enrutadores. Como cada túnel es gestionado de manera independiente,
mientras más enrutadores existan, mayores gastos de administración existirían. [29]
IPv6 sobre IPv4 Túnel GRE
IPv6 sobre IPv4 Túnel GRE, utiliza los estándares que describen la técnica de tunelización
GRE, la cual provee los servicios necesarios para implementar cualquier esquema de
encapsulación punto a punto. Como en la configuración manual de túneles, los túneles
GRE están enlazados entre dos puntos, con un túnel separado para cada enlace. Los túneles
no están amarrados a un protocolo de transporte específico, pero en este caso se transporta
IPv6 como el protocolo viajero sobre GRE como el protocolo portador. El uso primario es
para conexiones estables que requieren de una comunicación regular y segura, entre dos
enrutadores de borde, o entre un enrutador de borde y un sistema final. El enrutador de
borde, y los sistemas finales tienen que tener habilitado el dual stack. En la Figura #22
puede apreciarse la configuración GRE, y como en la configuración manual de túneles
IPv6, deben configurarse las direcciones IPv4, e IPv6 de la interfase GRE en el enrutador
dual stack; así como los puntos de origen y destino del túnel con direcciones IPv4. [29]
Figura #22 IPv6 sobre IPv4 Túnel GRE. [3]
Tunnel Broker
Un servicio de Tunnel Broker le permite a los clientes, el acceso a un backbone IPv6, ya
sea para utilizar aplicaciones IPv6 que corren en un sistema final dual stack, o un sistema
final IPv6 conectado a enrutadores dual stack. El servicio Tunnel Broker, que emplea
túneles 6-sobre-4 para conectar los sistemas finales a un backbone IPv6, manejan
automáticamente los requerimientos y configuración para las empresas, en lugar de forzar a
los administradores de estos sistemas a configurar manualmente estos túneles.
ANEXOS 87
Figura #23 Túnel Broker. [3]
La limitación fundamental radica e que el sistema final o los enrutadores, aceptan cambios
de configuración desde un servidor remoto; con las implicaciones de seguridad que estas
actividades acarrean. [29]
Túnel Automático Compatible IPv4
Un túnel automático compatible IPv4, puede ser configurado entre dos enrutadores de
borde o entre un enrutador de borde, y un sistema final. La dirección IPv6 se forma con
0:0:0:0:0:0 en la parte más significativa con 96 bits, y los 32 bits de la IPv4 en la parte
menos significativa de la dirección resultante.
Figura #24 Túnel Automático Compatible con IPv4. [3]
Este mecanismo de transición fue definido al principio del proceso de desarrollo de IPv6, y
su uso futuro puede se limitado. De cualquier manera este es un método sencillo para crear
túneles para IPv6 sobre IPv4. Tiene como principal limitación su difícil escalabilidad para
grandes redes, debido a que cada host requiere una dirección IPv4, y otra IPv6 para poder
determinar los puntos extremos del túnel. Otra limitación consiste en que todas las
comunicaciones solamente pueden establecerse entre direcciones compatibles IPv4. [29]
ANEXOS 88
Túnel Automático 6to4
Un túnel automático 6to4 permite que los dominios aislados IPv6 que sean conectados a
través de la red IPv4; y permite conexiones remotas a redes IPv6. La principal diferencia
entre este mecanismo, y la configuración manual de túneles, radica en que los enrutadores
no son configurados en pares (y por tanto no requieren configuración manual) debido a que
ellos tratan la infraestructura IPv4 como un enlace virtual, que emplea una dirección IPv4
incrustada en la dirección IPv6, que le permita encontrar el extremo final del túnel. Cada
dominio IPv6 requiere enrutadores dual stack que identifiquen los túneles IPv4 por un
prefijo de ruteo único en la dirección de IPv6 (la dirección IPv4 del destino del túnel está
conectada al prefijo 2002::/16). Este prefijo de enrutamiento único fue asignado por la
IANA [68] para el uso en los esquemas 6to4. Como en la configuración manual de los
túneles compatibles IPv4, la gestión de los NAT necesita estar enlazada con la gestión de
los túneles, y cualquier cambio de configuración en el NAT que se haga de forma
independiente, no será permitida a través de la trayectoria del túnel.
El escenario más simple para el despliegue de túneles 6to4 es donde se interconectan
múltiples sitios IPv6, cada uno de los cuales tiene al menos un enlace compartido con IPv4.
Esta red pudiera se la Internet global, o pudiera ser el backbone de una Empresa en
particular. El requerimiento clave es que cada sitio tenga una dirección IPv6 de tipo 6to4.
Como en otros mecanismos de tunelización, las entradas apropiadas en el DNS que
funciona para ambos protocolos IP, le permitirán a las aplicaciones seleccionar la dirección
requerida.
Figura #25 Interconectando Dominios 6to4. [3]
Como el uso de IPv6 nativo está pasando de ser un experimento a ser la realidad de muchos
países; el próximo paso es el uso, tanto de direcciones IPv6 6to4, como de direcciones IPv6
ANEXOS 89
estándares. El enrutador que provee servicios de enrutamiento entre el dominio IPv6
nativo, y el dominio 6to4, recibe el nombre e “relay router”. En el dominio nativo se
espera que corra un protocolo de enrutamiento; mientras que en el dominio 6to4 no se
necesita este tipo de protocolos. La comunicación entre sitios 6to4 y los dominios IPv6
nativos, necesitan al menos un “relay router”. [29]
Figura #26 Interconexión de Sitios 6to4 y dominios IPv6 nativos empleando “relay routers” [3]
ANEXOS 90
Anexo #6 Gestión de la Congestión
• FIFO
Figura #27 Diagrama de Cola tipo “First In First Out” [50]
• Prioridad de Colas
Figura #28 Diagrama de Prioridad de Cola. [50]
ANEXOS 91
• Colas Personalizadas (CQ)
Figura #29 Diagrama de Cola Personalizada. [50]
• Detección Temprana de pesos tomados al azar (WFQ, por sus siglas en inglés)
Figura #30 Diagrama de Colas según su Peso justo. [50]
ANEXOS 92
• Cola según su peso justo-basado en clases (CBWFQ, por sus siglas en inglés)
Figura #31 Diagrama de Colas según su Peso justo-Basado en Clases. [50]
ANEXOS 93
Anexo #7 Protocolo para el manejo de colas en RTP
El Protocolo de cola de transporte de Tiempo Real, es una simple tecnología de colas, que
provee mayor prioridad, y reserva ancho de banda para el tráfico que tiene mayores
requerimientos de “tiempo real”, tales como la voz, y el video. Esto reduce la demora, la
variación de la demora; a valores mínimos, y asegura la calidad de los servicios sensibles a
las demoras.
Figura #32 Diagrama del Protocolo de Colas de Transporte de Tiempo Real [50]
Como se muestra en la figura #32, en este tipo de mecanismo, el Protocolo RTP le asigna a
los paquetes de “tiempo real” una mayor prioridad, asignándoles un mejor puesto dentro de
la cola. Solamente los paquetes UDP (User Datagram Protocol, por sus siglas en inglés),
cuyo número de puerto es un número par en el rango determinado pueden ser paquetes
RTP. El rango de los puertos se puede configurar, estos van desde 16384 hasta 32767. El
mecanismo de manejo de colas RTP puede ser utilizado junto con los mecanismos de colas
FIFO, PQ, CQ, WFQ, y CBT. Esta es de las de más alta prioridad.
Los paquetes en RTP son configurados con Tasa de Límite. Los paquetes cuya tasa superan
el valor especificado se descartan. Esto garantiza que los paquetes en la cola de RTP no
pueden ocupar anchos de banda excesivos. La cola de RTP proporciona una solución al
problema que surge cuando la cola de alta prioridad contiene paquetes para un tiempo largo
y por lo tanto, los otros paquetes en la cola, que poseen una baja prioridad; son incapaces
de obtener ancho de banda. [50]
ANEXOS 94
Anexo #8 Velocidades y duración de la paquetización de los diferentes protocolos
Algoritmos de CODEC de voz.
Velocidad. Duración de la paquetización.
Tecnología de codificación y decodificación.
64 kbit/s 5ms PCM
64 kbit/s 10ms PCM
64 kbit/s 20ms PCM
G.711
64 kbit/s 30ms PCM
8 kbit/s 10ms CS-ACELP
G.729 8 kbit/s 20ms CS-ACELP
5.3 kbit/s 30ms CELP
G.723.1 6.3 kbit/s 30ms MP-MLQ
Figura #33 Velocidad y duración de la paquetización de los diferentes protocolos
ANEXOS 95
Anexo #9 Conformación del paquete de voz con CODEC G.711
Este protocolo a su vez se encapsula sobre UDP, el que a su vez se monta sobre IP, que en
la Red de Área Local (LAN) viaja sobre Ethernet.
Figura #34 Conformación del paquete de voz con CODEC G.711
Esta suma de protocolos hace que el ancho de banda requerido para el tráfico de voz sobre
Ethernet sea mayor al ancho de banda del audio. Para una ventana de 20 ms y con
codificación de audio Ley A, se obtienen 160 bytes de voz por trama (Bytes de voz/trama =
64 kbps * 20 ms / 8 = 160 bytes).
El paquete IP (incluyendo los protocolos RTP y UDP) agregan 40 bytes adicionales (Bytes
de paquete IP = 160 + 40 = 200 bytes). La trama Ethernet agrega otros 26 bytes: Bytes de
Trama Ethernet = 200 + 26 = 226 bytes.
En este ejemplo, cada 20ms se genera 226 bytes que se deben enviar por la LAN. Esto
equivale a un ancho de banda de 90,4 kbps (compárese con los 64 kbps del flujo de
audio): Ancho de banda LAN = 226 * 8 / 20 ms = 90,4 kbps.
Debe notarse que este cálculo fue hecho para el envío de audio en una dirección. Como las
comunicaciones son bidireccionales, el ancho de banda real requerido en la LAN será el
doble. Puede utilizarse la supresión de silencio o Detección de Actividad de la Voz (VAD),
en las que no se envían paquetes cuando no hay audio. En este caso, el ancho de banda
total es similar al ancho de banda unidireccional. Por lo visto anteriormente, el ancho de
banda de la voz paquetizada en la LAN depende del tamaño de la ventana (típicamente 10,
20 o 30 ms) y el CODEC utilizado.
ANEXOS 96
Anexo #10 Registro de un MGW
Figura #35 Registro de un MGW
Para que un equipo pueda realizar llamadas ante el MGC, si el MGC acepta al MGW
entonces el MGW podrá realizara o recibir llamadas.
SVC_CHG_REQ: (MGW-- MGC)
MEGACO/1 [191.169.150.172]:2944
T=3{
C= - {
SC=ROOT{
SV{
MT=RS,RE=902}}}}
Para registrarse el MGW le envía al MGC una solicitud en el comando SVC_CHG_REQ.
A continuación mostramos el significado de cada uno de los parámetros del mando:
Línea 1: Indica que versión la versión del protocolo es la 1, la dirección IP del equipo de
acceso es 191.169.150.172 y el puerto para la comunicación es el 2944.
ANEXOS 97
Línea 2: Indica que el ID de la transacción es TRANSACTIONID=3
Línea 3: Especifica que se trata de un contexto nulo.
Línea 4: Se trata del comando SERVICE CHANGE. El ID de la terminación es
TERMINATION ID=ROOT que indica que el comando es aplicable para todo el MGW.
Línea 5: La descripción del SERVICE CHANGE encapsulada en el comando SERVICE
CHANGE.
Línea 6: Son los parámetros contenidos en el descriptor del SERVICE CHANGE indicando
que el método del SERVICE CHANGE es RESTART y la razón es un WARM BOOT.
SVC_CHG_REPLY (MGC------ MGW)
MEGACO/1 [191.169.150.170]:2944
P=3{C= - {SC=ROOT{SV{}}}}
Mensaje de respuesta del MGC al MGW a la solicitud de registro:
Línea 1: Indica que es el protocolo MeGaCo con versión 1. Se especifica la dirección IP y
puerto del MGC.
Línea 3: Indica el ID de la transacción=3 y el contexto nulo. El comando SERVICE
CHANGE hace referencia con ROOT a todo el MGW mostrando que el MGC ha recibido
correctamente la solicitud de registro.
De existir algún problema con el registro del equipo de acceso
ANEXOS 98
Anexo #11 Inicialización de un MGW
Después que el MGW completa el registro de forma satisfactoria, el MGC modifica las
propiedades de todas las terminaciones semi-permanentes del MGW contenidas en el
contexto nulo. Al mismo tiempo le indica al MGW detectar los eventos de descolgado de
los puertos del equipo de acceso.
Figura #36 Inicialización de un MGW
MOD_REQ (MGC----- MGW)
MEGACO/1 [191.169.150.170]:2944
T=372794419{C= - {
MF=A0{
E=369099777{al/*},
SG{}}}}
Después del registro acertado, el MGC realiza operaciones en la terminación del MGW en
el contexto nulo y modifica las características de la terminación con el comando MODIFY.
La descripción del texto del comando de MOD_REQ está como sigue:
ANEXOS 99
Fila 1: Protocolo MEGACO, la versión es 1. MGC-MG, la dirección IP y Puerto del MGC
es [191.169.150.170]:2944.
Fila 2: El número de transacción es ″372794419″. La transacción se encapsula en el
contexto nulo.
Fila 3: Comando MODIFY que se utiliza para modificar las propiedades de la terminación
A0.
Fila 4: Event descriptor, en el que RequestID es “369099777” .El MGC solicita al MGW
para detectar todos los acontecimientos en la línea analógica, que ocurren en la terminación
A0, tales como descolgado.
Row 5: Signal descriptor. En este caso la señal es NULL que indica que el MGC le solicita
al MGW detener todas las señales que están siendo intercambiadas.
MOD_REPLY (MGW----- MGC)
MEGACO/1 [191.169.150.172]:2944
P=372794419{
C= - {MF=A0}}
Después de recibir el comando MODIFY, el MGW responde con MOD_REPLY.
ANEXOS 100
Anexo #12 Llamada desde un UA5000 de Guantánamo hasta un UA5000 de Baracoa
Abonado A GTM: (355556)
MGW IP: 10.50.27.14:2944
TID: 410
Codec: G.711A
Abonado B BARACOA: (645399)
MGW IP: 10.50.27.61:2944
TID: 1420
Codec: G.729
Figura #37 Llamada desde un UA5000 de Guantánamo hasta un UA5000 de Baracoa
En esta llamada el abonado 355556 llama al 645399, establecen la llamada y después de
unos segundos de conversación el abonado A cuelga primero.
Secuencia de intercambio de Señalización H.248
ANEXOS 101
1 NTFY_REQ (MGW----- MGC):
ANEXOS 102
El llamador Usuario A (355556) que corresponde a la terminación A410 descuelga el
teléfono. El MGW notifica al SoftX3000 del evento de offhook con el comando de
NTFY_REQ. El SoftX3000 confirma la recepción del evento del offhook y responde. En
este momento el MGC realiza a partir de la dirección IP del MGW y el TID la conversión
de número de equipo (EN) a numero de directorio (DN). Realizando esta operación el
MGC es que conoce el número del abonado llamador.
Línea 1: Corresponde a las direcciones IP del MGW y el MGC.
Línea 2: Protocolo MEGACO, la versión es 1. La dirección IP y el puerto del MGW
[10.50.27.14]:2944
Línea 3: El número de transacción es ″18491970″. La transacción se encapsula en el
contexto nulo.
Línea 4: Comando NOTIFY, que se utiliza para notificar la terminación A410.
Línea 5: OBSERVED EVENT: Descriptor de evento detectado. En este caso, el MGW
donde está la terminación A detecta el evento del offhook del usuario A y divulga este
acontecimiento al SoftX3000. El RequestID es " 2769057731 ", se proporciona la fecha y
hora a la que se produce el evento “20120608T12533400” así como el evento en cuestión
que el descolgado.
1-NTFY_REPLY (MGC------ MGW):
ANEXOS 103
En el NTFY_REPLY el SOFTSWITCH especificando el numero de la transacción, el
contexto nulo y el ID de la terminación TID=A410. La función de este mensaje es que
equipo de acceso conozca que el MGC ha reconocido la solicitud.
2-MOD_REQ (MGC------ MGW):
Cuando el SOFTX300 recibe el evento de descolgado inmediatamente le envía al MGW el
MOD_REQ al equipo de acceso para indicarle al MGW:
Que ponga tono de discar al usuario A que se encuentra en la terminación 410.
Supervisar los eventos de colgado, flash, etc.
El DIGIT MAP disponible que nos es más que las formas de marcación existentes y la
longitud de las mismas. Si el usuario marca una numeración que esta fuera del DIGIT MAP
escuchará tono de ocupado.
Después que el MGW recibe las indicaciones del MGC el equipo de acceso le envía al
SOFTX300 el MOD_REPLY como respuesta al mensaje recibido MOD_REQ y le pone
tono de discar al abonado.
dd/ce: DigitMap Completion event in the DTMF detection Packages
cg/dt: Dial tone signal in the Call Progress Tones Generator Packages
ANEXOS 104
2-MOD_REPLY (MGW------ MGC):
Esta es la respuesta del MGW al MGW relacionado con la solicitud de MOD_REQ. La
explicación de los parámetros es igual que en los mensajes anteriores.
3-NTFY_REQ (MGW------ MGC):
El usuario A relacionado con el TID A410 disca el numero deseado, la terminación colecta
los dígitos marcados y lo trata de machear con el DIGIT MAP. En caso de que el DIGIT
MAP coincida la terminación le envía al MGC un NTFY_REQ y posteriormente el MGC le
envía al MGW un NTFY_REPLY indicando que se ha recibido correctamente la petición.
El parámetro METH=FM nos indica que el numero marcado por el usuario ha coincidido
con el DIGIT MAP.
dd/ce: DigitMap Completion event in the DTMF detection Packages
A continuación mostramos la explicación de cada una de las líneas de este mensaje:
Línea 1: Corresponde a las direcciones IP y puertos del MGW y el MGC.
Línea 2: Protocolo MEGACO, la versión es 1. La dirección IP y el puerto del MGW
[10.50.27.14]:2944
ANEXOS 105
Después que el MGC obtiene el número discado analiza la clase de servicio (COS) del
abonado llamador para verificar si tiene acceso al servicio llamado. Como en este caso el
usuario si tiene acceso al servicio, continúa el procesamiento de llamada y se procede a
localizar en la base de datos de abonados la terminación física o el puerto del número
llamada. Para ello el MGC después de localizar el abonado obtiene la dirección IP y el TID
del abonado llamada. De esta forma el MGC identifica el MGW donde se encuentra el
abonado llamado.
3-NTFY_REPLY (MGC------ MGW):
Esta es la respuesta del MGC al NTFY que envió el MGW.
4-ADD_REQ (MGC------ MGW):
TABLA DE ILUSTRACIONES 106
TABLA DE ILUSTRACIONES
Fig. #1 ATM en el transporte de voz, datos y video 7
Fig. #2 Integración entre la Red ATM//FR y la Red IP/MPLS 10
Fig. #3 IPv6 sobre Túneles IPv4 18
Fig. #4 IPv6 sobre enlaces de datos dedicados 19
Fig. #5 Arquitectura 6PE 24
Fig. #6 Distribución de rutas y etiquetas en el núcleo IPv4, para 6VPE 25
Fig. #7 Ancho de Banda 34
Fig. #8 Retardo extremo a extremo (Delay) 35
Fig. #9 Variación de la demora (Jitter) 36
Fig. #10 Pérdida de paquetes 37
Fig. #11 Protocolos que participan en la Señalización de VoIP 42
Fig. #12 Estructura del paquete RTP 43
Fig. #13 Flujo de los paquetes IPv6 en entornos de VoIPv6 49
Fig. #14 Arquitectura NGN con IPv4 52
Fig. #15 Redes Privada Virtuales, 6VPE 61
Fig. #16 Arquitectura NGN con IPv6 y modelo 6VPE en el núcleo MPLS 63
Fig. #17 Propuesta del Backbone IP/MPLS en Cuba 81
Fig. #18 Analogía entre el modelo OSI y la Arquitectura TCP/IP 82
Fig. #19 Cabecera del datagrama IPv4 83
Fig. #20 Cabecera del datagrama IPv6 84
Fig. #21 Configuración manual de túneles IPv6 85
TABLA DE ILUSTRACIONES 107
Fig. #22 IPv6 sobre IPv4 Túnel GRE 86
Fig. #23 Tunnel Broker 87
Fig. #24 Túnel Automático Compatible con IPv4 87
Fig. #25 Interconectando Dominios 6to4 88
Fig. #26 Interconexión de Sitios 6to4 y dominios IPv6 nativos empleando “relay routers”89
Fig. #27 Diagrama de Cola tipo “First In First Out” 90
Fig. #28 Diagrama de Prioridad de Cola. 90
Fig. #29 Diagrama de Cola Personalizada. 91
Fig. #30 Diagrama de Colas según su Peso justo. 91
Fig. #31 Diagrama de Colas según su Peso justo-Basado en Clases. 92
Fig. #32 Diagrama del Protocolo de Colas de Transporte de Tiempo Real 93
Fig. #33 Velocidad y duración de la paquetización de los diferentes protocolos 94
Fig. #34 Conformación del paquete de voz con CODEC G.711 95
Fig. #35 Inicialización de un MGW 96
Fig. #36 Registro de un MGW 98
Fig. #37 Llamada desde una UA5000 de Guantánamo hasta un UA5000 de Baracoa 100
