Consideraciones Técnicas para Elaborar un Estándar Definitivo VoIP

Transcripción

1 Consideraciones Técnicas para Elaborar un Estándar Definitivo VoIP Héctor Kaschel C. Enrique San Juan U. Departamento de Ingeniería Eléctrica, Facultad de Ingeniería Departamento de Tecnologías Industriales, Facultad Tecnológica Universidad de Santiago de Chile. Avda. Ecuador # 3519 Estación Central. Santiago Chile. Fonos: (56) (56) (56) A: 2396 Fax: (56) hkaschel@lauca.usach.cl. esanjuan@lauca.usach.cl Resumen En el presente trabajo se realiza una revisión acerca del transporte voz sobre redes IP, estudiando las tecnologías de apoyo que podrían colaborar a la elaboración de un estándar. VoIP definitivo, como son el protocolos MPLS (Multi Protocol Label Switching) y el protocolo de reserva de recursos RSVP (ReSerVation Protocol), los cuales podrían ser apoyados por un conjunto de protocolos desarrollados por la IET F (Internet Engineering Task Force) [33], que proveen una herramienta de ayuda para la comunicación a través de la Telefonía Internet. El conjunto de estos protocolos y estándares, asociados convenientemente, podrían proveer el camino hacia el estándar VoIP definitivo. Abstract In the present work is made an overhaul about the transport voice on IP networks, studying the support technologies that could collaborate to the processing of a definitive VoIP standard, like MPLS protocols (Multi Protocol Label Switching) and the reserve of resources protocol RSVP (ReSerVation Protocol), which could be supported by an assembly of protocols developed by the IETF (Internet Engineering Task Force) [33], they provide a tool with aid for the communication through Internet Telephony. This set of protocols and standards, properly associated, could provide the way towards definitive the VoIP standard. Keywords VoIP, QoS, IP, MPLS, RSVP, ATM, RAS, Q931, RTP, RTCP, G711, G726, G729, G Introducción VoIP tendrá un enorme impacto económico y social en la forma que tendremos para comunicarnos en un futuro muy cercano, especialmente cuando se solucionen los problemas asociados con la calidad de servicio QoS (Quality of Service). Es evidente que superados consensualmente estos problemas, la expansión de la VoIP (específicamente la telefonía IP), el impacto en las telecomunicaciones será dramático, ya que esto traerá como consecuencia la definitiva integración de las redes de voz y datos, sobre una plataforma común, que aparentemente no será ATM, sino que IP. VoIP es una tecnología de gran interés que está teniendo un desarrollo creciente y acelerado, planteándose como alternativa a otras tecnologías para el transporte de la voz, en donde inversiones en redes bajo este concepto, podrían resultar altamente rentables. Sin embargo, la mayor dificultad está relacionada principalmente con el QoS, debido a que IP no provee en forma natural mecanismos de protección para el tráfico de voz. Entre los problemas asociados se encuentran: Los retardos que podrían ser intolerables y que afectan sin duda la calidad de la voz y de la comunicación; la latencia que altera las conversaciones interactivas; pérdidas de paquetes; problemas de jitter; garantía de un ancho de banda apropiado; supresión de eco y confiabilidad, entre otros. Realmente la integración de la voz y los datos en una misma red es una idea antigua, pues desde hace tiempo han surgido soluciones desde distintos fabricantes que, mediante el uso de multiplexores, que permiten utilizar las redes WAN de datos de las empresas (típicamente conexiones punto a punto y Frame-Relay) para la transmisión del tráfico de voz. La falta de estándares, así como el largo plazo de amortización de este tipo de soluciones no ha permitido una amplia imp lantación de las mismas. El estándar temporal para Voz sobre IP se denomina comúnmente VoIP/H.323 y esta fundamentado en el estándar H323 de la ITU (International Telecommunication Union). El VoIP/H.323 comprende a su vez una serie de estándares asociados para la paquetización de comunicaciones multimediales [6]. En este trabajo se da una mirada al estándar

2 H323/VoIP base del VoIP y los dispositivos asociados que permiten interconectar redes de distinta naturaleza para el transporte de voz sobre IP. Se plantean las alternativas para mejorar el QoS en redes IP. Para esto se realiza una revisión general de dos protocolos que en conjunto podrían proveer una mejora sustancial en el camino hacia el transporte de voz sobre IP. Estos protocolos son el MPLS y el RSVP. El MPLS a grandes rasgos pretende identificar una ruta entre el origen y el destino que puede ofrecer la calidad de servicio requerida, ya que por un lado presenta un enfoque orientado a la conexión, así como un enfoque tradicional sin conexión en la misma infraestructura; y por otro, permite la ingeniería de tráfico. El protocolo de reserva de recursos RSVP notifica a todos los nodos que se encuentran a lo largo de la ruta identificada que necesitan reservar los recursos para garantizar la calidad de servicio solicitada. [6] 2.- El estándar H323, punto de partida para VoIP Para Voz sobre IP se adoptó como base el estándar existente de la ITU el H323, que cubre la mayor parte de los mecanismos necesarios para la integración de la voz. En 1997 el Forum VoIP, llegó a un acuerdo para permitir la interoperabilidad de los elementos que intervienen en una red de VoIP. H323 no es el estándar VoIP, pero sí su pilar fundamental. Cuando nos referimos al H323 asociado con VoIP, es común usar el término VoIP/H323. El VoIP/H323 tiene como objetivo primordial facilitar y asegurar la interoperabilidad entre equipos de variados fabricantes. Este VoIP/H323 establece los aspectos tales como la supresión de los silencios, compresión y direccionamiento, y el establecimiento de elementos que permiten la interconectividad con la red telefónica conmutada (RTC) tradicional. En la figura 1 se presenta la torre de protocolos del H323: [15][16] System control user interface Mic Camera Data applications H.225 RAS Channel Q.931 Call setup Audio andvideo H.245 control control RTCP Audio codec G.711 G.723 G.729 Video codec H.261 H.263 T.120 Transport layer (TCP or UDP) IP Figura 1: Torre de protocolos H Descripción general de la pila de protocolo H323 Direccionamiento: H.225: RAS (Registration, Admission and Status). Protocolo de comunicaciones que permite a una estación H323 localizar a otra estación H323 a través de una entidad llamada Gatekeeper. Realiza el servicio de resolución de nombres en direcciones IP, con el mismo propósito que RAS pero mediante un servidor DNS. Señalización: Q.931: Se emplea para la señalización inicial de la llamada, provee la conexión lógica entre el que llama y el llamado. H.245: Protocolo de control, usado para conectar dos participantes, después del establecimiento Q.931, para el intercambio de información variada relacionada con sus comunicaciones; por ejemplo, tipo de mensaje (audio, video o datos) y formato. En adición provee un conjunto de funciones de control para video conferencia multipartita. RTCP (Real Time Control Protocol): Antes de la descripción de RTCP es adecuado revisar el protocolo RTP (Real Time Transport Protocol). Este protocolo soporta el transporte de media en tiempo real (ejemplo: audio y video) sobre redes de paquetes. El proceso de transporte involucra tomar los flujos de bits generados por el codificador de media, partiéndolo en paquetes, enviando los paquetes a través de la red y luego recobrar los flujos de bit en el receptor. El proceso es complejo, porque los paquetes se pueden perder, retardados por muchas variables y reordenados en la red. El protocolo de transporte debe permitir al receptor detectar estas pérdidas. Debe también llevar información del timing para que el receptor pueda compensar correctamente el jitter (variabilidad en el retardo). Para asistir en esta función, RTP define el formato de los paquetes enviados a través de la red.

3 El protocolo RTCP acompaña a RTP como un protocolo de control, RTCP provee información adicional para los participantes de la sesión. En particular proporciona: QoS feedback- Los receptores en una sesión usan RTCP para reportar la calidad de su recepción a cada enviante. Esta información incluye el número de los paquetes perdidos, el jitter, y retardos round-trip. Esta información puede ser usada por enviantes para aplicaciones adaptivas, que se ajustan codificando los rates y otros parámetros basados en feedback. Intermedia synchronization- Por flexibilidad audio y video son a menudo llevados en flujos de paquetes separados, pero ellos necesitan ser sincronizados en el receptor para proveer lip sync. La información necesaria para la sincronización de fuentes, incluso si son originados por servidores diferentes, es proporcionado por RTCP. Identification- Los paquetes RTCP contienen información tales como: la dirección de , número telefónico y el nombre completo del participante. Esto permite a los participantes de la sesión conocer las identidades de los otros participantes de la sesión. Session Control- RTCP les permite a los participantes indicar que ellos están dejando una sesión (mediante un paquete RTCP BYE). Los participantes pueden también enviar pequeñas notas a otros, tales como por ejemplo: voy saliendo de la oficina. RTCP manda que todos los participantes de la sesión (incluyendo aquellos que sólo escuchan) envíen un paquete periódicamente que contiene la información descrita anteriormente. Estos paquetes son enviados a la misma dirección (multicast or unicast) como media RTP, pero en un puerto diferente. La información es enviada periódicamente, ya que contiene información time-sensitive, como por ejemplo la calidad de recepción que se pone pesada después de alguna cantidad de tiempo. Sin embargo, un participante no puede enviar exactamente un paquete RTCP con un periodo fijo. Ya que RTCP es usado en grupos multicast, podría haber sesiones (como una lectura grande) con centenares o miles de participantes. Si cada uno fuera a enviar un paquete con un periodo fijo, la red llegaría a ser dificultosa con paquetes RTCP. Para corregir esto, RTCP especifica un algoritmo que permite al periodo incrementarse en grupos grandes. Estándares de Compresión de voz: Los estándares recomendados por H323 para la compresión de la voz, son los siguientes: G.711: Modulación por impulsos Codificados PCM a 64kbit/s. G.726: Modulación por impulsos codificados diferencial adaptivo ADPCM, a 16, 24, 32, 40 kbit/s. G.729: Codificador de la voz mediante predicción lineal con excitación por código algebraico de estructura conjugada a 8 kbit/s de complejidad reducida. A estos podemos agregar algunos opcionales como el G.728 (Codificación de señales vocales a 16 kbit/s utilizando predicción lineal con excitación por código de bajo retardo) y G.722 (Codificación de audio de 7 khz) [7][12][13][14]. 4.- Telefonía usando protocolo IP (VoIP) La telefonía IP abarcará un amplio rango de servicios. Estos servicios incluyen no sólo la tradicional conferencia, llamadas a servicios suplementarios de control, transporte de multimedia y movilidad, sino que nuevos servicios que integran Web, , presencia y aplicaciones de mensajería instantánea con telefonía. Además, es generalmente aceptado que la telefonía Internet y la tradicional telefonía de conmutación de circuitos coexistirán por algún tiempo, requiriendo gateways entre los dos mundos. Existen varias formas de transportar telefonía, o para ser más amplio Voz sobre protocolo IP por lo que se hace necesario precisar algunos conceptos: Voz sobre IP: Servicios de transporte de voz (telefonía) sobre redes IP privadas sin realizar una conexión con la red pública conmutada (RTC). Telefonía IP: Telefonía sobre redes IP con interconexión con la RTC. Voz sobre Internet: Transporte de voz y servicios de telefonía sobre la red pública global a través de la interconexión de redes de conmutación de paquetes basadas en el protocolo IP [6][7][11]. 5.- Funcionamiento de VoIP En el transporte de voz sobre protocolo IP, la voz se convierte en paquetes de datos de voz comprimida, adoptando la forma de un datagrama IP, los cuales son transmitidos a través de la red como si fueran datos; la transmisión de voz sobre protocolo IP requiere de un elemento que transforme la voz a datos y realice la división en paquetes IP, este se conoce como DSP, los cuales se incorporan comúnmente en los gateways los cuales son los encargados de transmitir los paquetes IP.

4 En el nodo destino se encuentra otro gateways en donde se produce el proceso inverso. Es posible reservar cierto ancho de banda dentro de la red para mejorar la calidad de la transmisión a través del protocolo RSVP, protocolo que se tratará en el presente trabajo. Para ser más preciso, los gateways en el caso de comunicación entre teléfono y un PC poseen una conexión hacia la RTC y una hacia Internet, digitaliza la voz si es que no lo está, comprime, empaqueta y realiza la traslación entre direcciones IP y números de la RTC, realizando el proceso simultáneamente en ambos sentidos. Cuando la llamada se realiza entre teléfonos a través de la red IP (por ejemplo Internet) pertenecientes a la RTC, el proceso se realiza de forma similar, empleando en este caso dos gateways, uno en cada extremo [1][6][7][11]. En este escenario es posible desviar llamadas telefónicas desde el sistema telefónico tradicional hacia Internet, en donde una vez que se alcanza un servidor cercano al destino, la llamada se traduzca nuevamente a su forma analógica original y puede ser transmitida hacia el teléfono destino perteneciente a la RTC. Los principales componentes de una red VoIP son: Teléfonos IP, Adaptadores para PC, Hub telefónicos, Gateways, Gatekeepeer, Unidades de audio conferencia Múltiple (MCU Voz), Servicios de directorios, Terminales, Proxies. El Gateway Los gateways de VoIP proveen un acceso ininterrumpido a la red IP. Las llamadas de voz se digitalizan, codifican, comprimen y paquetizan en un gateway de origen y luego, se descomprimen, decodifican y rearman en el gateway de destino. Los gateways se interconectan con la RTC según corresponda, a fin de asegurar que la solución sea ubicua. RTC Teléfono IP RED IP HUB Telefónico PABX Gateway Teléfono IP WAN Gateway RTC PC+Adapatador RED IP DNS Unidad de Audioconferencia multiple Gatekeeper PABX Figura 2: Los principales componentes de una red VoIP El Gatekeeper Los gateways se conectan con los gatekeepers de VoIP mediante enlaces estándar H.323v2, utilizando el protocolo RAS H.225. Los gatekeepers actúan como controladores del sistema y cumplen con el segundo nivel de funciones esenciales en el sistema de VoIP de clase carrier, es decir, autentificación, enrutamiento del servidor de directorios, contabilidad de lla madas y determinación de tarifas. Servidores de Backend El tercer nivel de la arquitectura de VoIP corresponde a la serie de aplicaciones de backoffice que constituyen el corazón del sistema operativo de un proveedor de servicios. Poseen las bases de datos inteligentes y redundantes que almacenan información crítica que intercambian con los gatekeepers durante las fases de inicio y término de las llamadas. En el entorno de una oficina central, resulta vital preservar la integridad de los datos de las bases de datos de backend. La solución ofrece un enfoque único que garantiza la resistencia de los servidores de backend y la seguridad de sus bases de datos. Los servidores SQL (Structured Query Language) de Microsoft están integrados dentro de la arquitectura del

5 sistema de backend y administran las bases de datos SQL para las funciones de autentificación, mapeo de directorios, contabilidad y determinación de tarifas. Este nivel de la arquitectura fue optimizado a fin de responder a las necesidades exclusivas de seguridad y disponibilidad de los proveedores de servicios. Para implementaciones a menor escala, el sistema ofrece flexibilidad para consolidar las bases de datos en un solo servidor robusto o en la plataforma de un gatekeeper. MCUs (Multipoint Control Unit) Es el sistema encargado del control de las conferencias múltiples, proporciona todos los servicios para establecer comunicaciones multipunto. Terminales Son los dispositivos que se pueden conectar directamente a IP y soportan H.323. Proxies Son los sistemas que actúan como intermediarios entre diversas entidades, tal y como lo hacen los proxies en las redes IP (conexión entre la Intranet e Internet, por ejemplo). 6.- Calidad de servicio QoS [15][16][17] En forma natural el protocolo IP no garantiza el éxito de la transmisión. Por lo que no pareciera adecuado para el transporte de la voz, debido a que ésta requiere que los paquetes lleguen en orden, para asegurar que no existan pérdidas de los mismos, y garantizar una tasa de transmisión que no supere un umbral determinado. Garantizar calidad de servicio en base a retardos y ancho de banda disponible sólo con el H323 no es realmente posible sobre una red IP, por lo que se deben agregar mecanismos adicionales para garantizar un QoS apropiado. Este ha sido hasta el momento el gran impedimento para el despliegue masivo de la transmisión de voz sobre redes IP. Sin embargo, se han desarrollado algunos mecanismos para mejorar el QoS, diferenciando los paquetes de voz de los paquetes de datos, priorizando la transmisión de los paquetes de voz, y hacer que los retardos asociados a la transmisión de éstos no superen los 150ms. En lo relacionado con la priorización tenemos algunas alternativas: Asignación de un porcentaje de ancho de banda disponible. Establecer prioridad en las colas. Evitar tablas de routers intermedias. Establecer rutas por paquetes; mediante la asignación al tráfico de menor carga. En el estado actual de Internet, es muy posible obtener retardos superiores a los 300ms, con lo que en este escenario resultaría casi imposible tener una conversación normal y fluída. Debido a que las redes de área local no están preparadas en principio para este tipo de tráfico, el problema puede parecer grave, ya que hay que tener en cuenta que los paquetes IP son de longitud variable y el tráfico de datos suele ser a ráfagas. Existen opiniones encontradas acerca de la calidad de las llamadas de voz que se realizan por la Internet pública. Vale la pena destacar que los carriers utilizarán particiones de backbones de IP bien diseñadas para transportar el tráfico de voz sobre IP, simplemente debido a que la Internet pública tiene patrones de tráfico impredecibles y no fue desarrollada para manejar el tráfico de la telefonía de clase carrier. La demora y la pérdida de paquetes durante los períodos de alto nivel de tráfico en la Internet pública degrada la calidad del tráfico altamente sensible a las demoras como ocurre en el caso de la voz en tiempo real. La performance de la voz en la Internet pública puede mejorarse de manera notoria mediante el uso de algoritmos tales como la corrección de errores sin retorno y la protección de paquetes. En la actualidad, se están tratando estos temas y cabe pensar que la voz sobre IP pronto podrá proveer una calidad de voz con una fidelidad significativamente superior a la que existe hoy en día. Gracias a nuevos estándares que vendrían a reforzar el estándar base VoIP/H323 como son los protocolos MGCP (Media Gate Control Protocol), SIP (Session Initiation Protocol) [34], MPLS y RSVP que se verán más adelante en este trabajo, los poderosos DSP y otros avances, hacen prever que la voz sobre protocolo IP será una realidad con un QoS de consenso, negociable y que satisfacerá a la mayoría. Factores que afectan el QoS Retardo de los paquetes de voz: El retardo máximo para una comunicación de buena calidad de extremo a extremo según el ITU es de 150ms, sin embargo la recomendación G.114 recomienda que el límite máximo en un canal unidireccional de voz sea de 400ms. Cabe destacar que la apreciación de la calidad de una comunicación de voz tiene una alta componente subjetiva, dependiendo de la razón calidad/precio que se le asigne al servicio. Retardos de tales magnitudes pueden resultar inadmisibles para muchos usuarios, especialmente en conversaciones de negocio y video conferencia, pero pueden resultar tolerantes para usuarios en que el factor precio es el más importante.

6 Latencia : Retardo total de los paquetes entre fuente y destino a través de la red. Jitter: Este parámetro resulta crítico para aplicaciones en tiempo real, como la voz, y representa la variación en los tiempos de llegada de los paquetes, que viajan por las diversas rutas o nodos con diferentes estados de congestión. Una alternativa para mejorar el jitter es incorporar la técnica de buffering en los nodos, de tal manera de ir almacenando los paquetes en el interior de un buffer y de esta manera darles un retardo constante, la idea básica es que si el buffer esta vacío el paquete tardara un período de tiempo T constante (por ejemplo, de 20 ms) en atravesarlo, y si el buffer esta con paquetes, los entrantes empujan a los que están en su interior de tal manera que estos salgan con el mismo período T de tiempo. Pérdida de paquetes: La pérdida de paquetes también afecta la calidad de la voz, pero el porcentaje admisible depende en alguna medida de los algoritmos de compresión usados, algunos bajo ciertas condiciones recuperan errores. El límite máximo de pérdida de paquetes se sitúa alrededor del 8 y 10% [7]. 7.- RSVP (ReSerVation Protocol) [4][5][18][19][20][21][22] Su principal función es particionar los paquetes de datos grandes y dar prioridad a los paquetes de voz cuando hay una congestión en un router. RSVP incorpora reserva de ancho de banda y retardo además de establecer una lista de acceso dinámica de extremo a extremo. Sus principales deficiencias se establecen en su defectuoso crecimiento (solución válida en redes pequeñas) y en su deficiente autorización y autentificación. Además hay que tener en cuenta que las actuales infraestructuras no la tienen en cuenta. Si bien este protocolo ayudará considerablemente al tráfico de multimedia por la red, hay que tener en cuenta que RSVP no garantiza una calidad de servicio como ocurre en redes avanzadas tales como ATM que proporcionan QoS de forma estándar. Características Se diseña para trabajar con cualquier servicio de QoS (los objetos propios de la QoS no están definidos por el protocolo). Permite Unicast y Multicast. No es un protocolo de enrutamiento, sino que está pensado para trabajar conjuntamente con éstos. Los protocolos de encaminamiento determinan dónde se reenvían los paquetes mientras que RSVP se preocupa por la QoS de los paquetes reenviados de acuerdo con el encaminamiento. Es un protocolo simplex: petición de recursos sólo en una dirección, diferencia entre emisor y receptor. El intercambio entre dos sistemas finales requiere de reservas diferenciadas en ambas direcciones. Reserva iniciada por el receptor (protocolo orientado al receptor). Mantenimiento del estado de la reserva (soft state) en los routers. El mantenimiento del estado de la reserva es responsabilidad de los usuarios finales. Permite diferentes tipos de reservas. Protocolo transparente para los routers no RSVP. Soporta IPv4 (campo TOS) y IPv6 (campo Flow Label), aunque no sea un protocolo de transporte. Entidades que lo utilizan: Un Host (receptor): para solicitar la QoS a una red para un flujo de datos o una aplicación particular. Un Router: para repartir peticiones de QoS a todos los nodos del camino del flujo de datos. Una petición de recursos que implicará generalmente una reserva de éstos en todos los nodos del camino del flujo de datos. Mecanismo de funcionamiento: Dos tipos de mensajes: 1- Mensajes de path (generados por el emisor): a- Describen el flujo del emisor. b- Proporcionan la información del camino de retorno hacia el emisor. 2- Mensajes de resv (generados por el receptor): a- Petición de reserva de recursos. b- Crean el estado de la reserva en los routers.

7 Figura 3: RSVP, primera aproximación 8.- MPLS (Multiprotocol Label Swiching) [2][3][23-31] El reciente desarrollo del MPLS y los servicios diferenciados han abierto nuevas posibilidades para algunas direcciones de la limitada tecnología convencional. En especial MPLS es una gran ayuda para la ingeniería de tráfico en redes IP y puede tener un importante impacto en el transporte de voz. La Ingeniería de tráfico de Internet es el aspecto de la ingeniería de red de Internet que direcciona las entregas para una ejecución óptima de la operación de la red. Abarca las aplicaciones tecnológicas y principios para la medición, modelamiento, caracterización, y control de tráfico de Internet [8]. También incluye las aplicaciones de conocimiento de técnicas para alcanzar la ejecución de objetivos específicos, incluyendo movimiento de tráfico confiable y expedito a través de la red, eficiente utilización de los recursos de la red, y planificación de la capacidad de la red. Una buena ingeniería de tráfico incrementa el valor de una red para los proveedores de servicios y la comunidad de usuarios de Internet. Desarrollos en MPLS [8-14] abren nuevas posibilidades para direcionar algunas de las limitaciones de los sistemas IP en lo que concierne a la ingeniería de tráfico. Un marco para MPLS es presentado en [11] y una arquitectura para él es descrita en [14]. Los requerimientos para la ingeniería de tráfico sobre MPLS se aclarada en [8]. Aunque MPLS es una tecnología relativamente simple (basada en el clásico paradigma label swapping), habilita la introducción de capacidades de control sofisticados que hacen progresar las funciones de Ingeniería de tráfico en redes IP [8-10,12,13]. Un aspecto particularmente interesante de MPLS es que él soporta eficientemente control de conexión de origen a través label-switched path. Cuando MPLS es combinado con servicios diferenciados y bajo restricciones de ruteo, ellos llegan a ser poderosos y complementarios proporcionando QoS en redes IP. Principio de funcionamiento El MPLS funciona de la siguiente manera: Un router de tráfico con capacidad de MPLS denominados router de tráfico con conmutación de etiquetas LSR (Label Switching Routers) de acceso, recibe un paquete IP, analiza la cabecera IP y determina el destino. Este LSR de acceso añade una etiqueta al paquete IP, que identifica el trayecto orientado hacia el destino y envía este paquete hacia el siguiente LSR [14-17]. El siguiente LSR envía el paquete basándose únicamente en la etiqueta. No inspecciona la totalidad de la cabecera del IP. Debido a que los valores de la etiqueta solo tienen un significado local, puede que le LSR tenga que intercambiar la etiqueta recibida por otra que sea válida en el enlace con el LSR siguiente. Antes de cualquier envío de paquetes, es necesario que los LSR cuenten con un acuerdo acerca de la relación existente entre las etiquetas y los trayectos. Esto se consigue utilizando el protocolo de distribución de etiquetas LDP (Label Distribution Protocol). Siempre que la topología de la red experimente un cambio (por ejemplo, a causa de fallos de enlaces) se determinarán nuevos trayectos y el LDP proporcionará una nueva relación de las etiquetas a los trayectos.

8 La importancia de MPLS El MPLS es importante por dos razones. Por un lado presenta un enfoque orientado a la conexión, así como un enfoque sin conexión en la misma infraestructura; y por otro, permite la ingeniería de tráfico. El MPLS proporciona tanto un enfoque orientado a la conexión y basado en la calidad de servicio, como un enfoque tradicional sin conexión basado en la capacidad disponible en ese momento. 1b. Creación de rutas LSPs mediante tablas de intercambio de etiquetas entre LSRs adyacentes. Distribución a los LSR por el LDP 1a. Construcción tablas de encaminamiento, mediante Protocolos internos (OSPF, IS-IS, RIP ) 4. LSR cola (salida): Quita la etiqueta y Entrega el paquete al destino. 2. LSR cabecera (entrada): examina el paquete, lo procesa (funciones de servicio Nivel 3), lo etiqueta y lo envía al backbone 3. LSRs del backbone conmutan los paquetes mediante intercambio de etiquetas Figura 4. Funcionamiento de una red MPLS Conclusiones El estándar H323/VoIP, el despliegue de RSVP, MPLS, en conjunto con los protocolos desarrollados por el IETF [33] (que proveen una solución parcial para la VoIP) y los actuales y futuros desarrollos relacionados, prometen que el estándar definitivo de la voz sobre el protocolo IP será una realidad, y el despliegue de esta tecnología también. En lo relativo al tiempo para su implementación, no está claro el escenario y éste dependerá también de las adecuaciones y desarrollos de las actuales y futuras redes, y de las políticas corporativas y gubernamentales. Lo que sí parece evidente es que la implantación sobre entornos privados, en donde se posee el control de todos los parámetros de la red, la implantación debería producirse muy rápidamente, tanto sobre redes ATM y redes IP privadas. También está muy entendido que en lo relacionado con el QoS aún hay mucho por investigar, en especial si se trata QoS sobre redes IP. Referencias [1] IEC: Accelerating the Deployment of Voice over IP (VoIP) and Voice over ATM (VoATM)1. Introduction Carriers are moving voice services to packet networks both to reduce upfront and operational costs and to provide more value-added services in /voip _voatm/ topic01.html - WebProforum Tutorials Mar 2002 [2] Multiprotocol Label Switching (MPLS) web Proforum Tutorials International Engineering Consortium Copyright Mar-April 2002 [3] MPLS Applications MPLS addresses today's network backbone requirements effectively by providing a standardsbased solution that accomplishes the following: improves packet-forwarding tutorials/mpls/topic06.html - size 2.0K - WebProforum Tutorials mar 2002 [4] RSVP Refresh Overhead Reduction Extensions Network Working Group Request for Comments: 2961 Juniper Networks, Inc. G. Swallow Cisco Systems, Inc.P. Pan Juniper Networks, Inc. [5] Resource-Reservation Protocol (RSVP) PDF Table of Contents. Chapter Goals Resource Reservation Protocol. Explain the purpose of RSVP tunneling. Resource Reservation Protocol. Background. /td/doc/cisintwk/ito_doc/rsvp.htm Feb 2002 [6] Nikolaos Anerousis et.al. TOPS: An Architecture for telephony over Packet Networks IEEE Journal on selected areas in communications, January 1999

9 [7] Bo li, Mounir Hambi et.al QoS-Enabled Voice support in the next -generation internet: Isues, existinging Approaches and challenges IEEE Communications Magazine, April 2000 [8] Minoli Daniel, Emma Minoli, Delivering Voice over Frame Relay and ATM, Wiley Computer Publishing, Inc, 1998 [9] Minoli Daniel, Emma Minoli, Delivering Voice over IP Networks, Wiley Computer Publishing, Inc, 1998 [10] The ATM Forum, Technical Committee Voice and Telephony Over ATM to Desktop Specification AF-VTOA , February 1999 [11] Voz sobre IP, proxrecet.html [12] Presente y futuro de la Integración de las redes de voz sobre IP, http/ [13] ITU Recommendation H323: Visual telephone systems and equpment for local area networks provide a nonguaranted quality of service 1996 [14] Christian Huitema et.al An Architecture for Residential Internet Telephony Service, IEEE Networks, May/June 1999 [15] Carlos Marchant Voz sobre Redes de Paquetes Universidad de Santiago de Chile 1998 [16] Jesús Angel Pastor Ferrero Voz sobre IP: presente y futuro de integración de redes de voz sobre IP" [17] VOIP Voz sobre IP trabajos3/voip/ voip.shtml [18] Andrew S. Tanenbaum, RSVP Redes de computadores Editorial PEARSON 1997 [19] RSVP backup/apuntes.htm [20] Sergi Sánchez, Xavi Masip, Jordi Domingo Protocolo RSVP: Evolución y experiencias. [21] RSVP apres01/sld012.htm [22] RSVP [23] D. Awduche et al., "Requirements for Traffic Engineering Over MPLS," RFC 2702, Sept [24] D. Awduche et al., "Extensions to RSVP for Traffic Engineering," IETF Internet draft, work in progress, Feb [25] D. Awduche, A. Hannan, and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels," IETF Internet draft, work in progress, july [26] R. Callon et al., "A Framework for Multiprotocol Label switching." IETF Internet draft, work in progress. Nov [27] B Jamoussi et al., "Constraint-Based LSP Setup Using LDP," IETF Internet draft, work in progress, Feb [28] T. Li, G. Swallow, and D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," IETF Internet draft, work in progress, Feb [29] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label switching Architecture," IETF Internet draft, work in progress, June [30] Shen and H. Smit, "Calculating GP Routes over Traffic Engineering Tunnels," IETF Internet draft, work in progress, June [31] José Barberá MPLS: Una arquitectura de backbone para la Internet del siglo XXI Unisource Iberia S.A 2000, <jose.barbera@aucs-europe.com> [32] Tony Li, Prockect Networks, inc. MPLS and the Evolving Internet Architecture IEEE Communications Magazine, December 1999 [33] Henning Shulzrinne The IETF Internet Telephony Architecture and Protocols et.al., IEEE Network, May/June 1999 [34]