Consideraciones Tcnicas para Elaborar un Estndar Definitivo VoIP

Hctor Kaschel C. Enrique San Juan U.

Departamento de Ingeniera Elctrica, Facultad de Ingeniera
Departamento de Tecnologas Industriales, Facultad Tecnolgica
Universidad de Santiago de Chile.
Avda. Ecuador # 3519 Estacin Central. Santiago Chile.
Fonos: (56) 2 -7762963 - (56) 27786417 - (56) 26811100 A: 2396 Fax: (56) 2 - 6819079
e-mail: hkaschel@lauca.usach.cl. esanjuan@lauca.usach.cl

Resumen
En el presente trabajo se realiza una revisin acerca del transporte voz sobre redes IP, estudiando las tecnologas de
apoyo que podran colaborar a la elaboracin de un estndar. VoIP definitivo, como son el protocolos MPLS (Multi
Protocol Label Switching) y el protocolo de reserva de recursos RSVP (ReSerVation Protocol ), los cuales podran ser
apoyados por un conjunto de protocolos desarrollados por la IETF (Internet Engineering Task Force) [33], que proveen
una herramienta de ayuda para la comunicacin a travs de la Telefona Internet. El conjunto de estos protocolos y
estndares, asociados convenientemente, podran proveer el camino hacia el estndar 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, G728.

1.- Introduccin
VoIP tendr un enorme impacto econmico 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 expansin de la VoIP (especficamente la
telefona IP), el impacto en las telecomunicaciones ser dramtico, ya que esto traer como consecuencia la definitiva
integracin de las redes de voz y datos, sobre una plataforma comn, que aparentemente no ser ATM, sino que IP.
VoIP es una tecnologa de gran inters que est teniendo un desarrollo creciente y acelerado, plantendose como
alternativa a otras tecnologas para el transporte de la voz, en donde inversiones en redes bajo este concepto, podran
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 proteccin para el trfico de voz. Entre los problemas asociados se
encuentran: Los retardos que podran ser intolerables y que afectan sin duda la calidad de la voz y de la comunicacin; la
latencia que altera las conversaciones interactivas; prdidas de paquetes; problemas de jitter; garanta de un ancho de
banda apropiado; supresin de eco y confiabilidad, entre otros. Realmente la integracin 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 (tpicamente conexiones punto a
punto y Frame-Relay) para la transmisin del trfico de voz. La falta de estndares, as como el largo plazo de
amortizacin de este tipo de soluciones no ha permitido una amplia imp lantacin de las mismas.
El estndar temporal para Voz sobre IP se denomina comnmente VoIP/H.323 y esta fundamentado en el estndar H323
de la ITU (International Telecommunication Union). El VoIP/H.323 comprende a su vez una serie de estndares
asociados para la paquetizacin de comunicaciones multimediales [6]. En este trabajo se da una mirada al estndar

H.225
RAS
Channel
Q.931
Call
setup
H.245
control
Audio
andvideo
control
RTCP
Audio
codec
G.711
G.723
G.729
Video
codec
H.261
H.263
T.120
Transport layer (TCP or UDP)
IP
System control user interface Mic Camera Data
applications
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 revisin
general de dos protocolos que en conjunto podran 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 conexin, as como un enfoque tradicional sin conexin en la misma infraestructura; y por otro, permite la ingeniera
de trfico. 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 estndar H323, punto de partida para VoIP
Para Voz sobre IP se adopt como base el estndar existente de la ITU el H323, que cubre la mayor parte de los
mecanismos necesarios para la integracin 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 estndar VoIP, pero s su pilar
fundamental. Cuando nos referimos al H323 asociado con VoIP, es comn usar el trmino 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 supresin de los silencios, compresin y direccionamiento, y el
establecimiento de elementos que permiten la interconectividad con la red telefnica conmutada (RTC) tradicional. En la
figura 1 se presenta la torre de protocolos del H323: [15][16]










Figura 1: Torre de protocolos H323


3.- Descripcin general de la pila de protocolo H323
Direccionamiento:
H.225: RAS (Registration, Admission and Status). Protocolo de comunicaciones que permite a una estacin H323
localizar a otra estacin H323 a travs de una entidad llamada Gatekeeper.
Realiza el servicio de resolucin de nombres en direcciones IP, con el mismo propsito que RAS pero mediante un
servidor DNS.
Sealizacin:
Q.931: Se emplea para la sealizacin inicial de la llamada, provee la conexin lgica entre el que llama y el llamado.
H.245: Protocolo de control, usado para conectar dos participantes, despus del establecimiento Q.931, para el
intercambio de informacin variada relacionada con sus comunicaciones; por ejemplo, tipo de mensaje (audio, video o
datos) y formato. En adicin provee un conjunto de funciones de control para video conferencia multipartita.
RTCP (Real Time Control Protocol): Antes de la descripcin 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,
partindolo en paquetes, enviando los paquetes a travs 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 prdidas. Debe tambin llevar informacin del timing
para que el receptor pueda compensar correctamente el jitter (variabilidad en el retardo). Para asistir en esta funcin,
RTP define el formato de los paquetes enviados a travs de la red.

El protocolo RTCP acompaa a RTP como un protocolo de control, RTCP provee informacin adicional para los
participantes de la sesin. En particular proporciona:
QoS feedback- Los receptores en una sesin usan RTCP para reportar la calidad de su recepcin a cada enviante. Esta
informacin incluye el nmero de los paquetes perdidos, el jitter, y retardos round-trip. Esta informacin puede ser
usada por enviantes para aplicaciones adaptivas, que se ajustan codificando los rates y otros parmetros 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 informacin necesaria para la sincronizacin
de fuentes, incluso si son originados por servidores diferentes, es proporcionado por RTCP.
Identification- Los paquetes RTCP contienen informacin tales como: la direccin de e-mail, nmero telefnico y el
nombre completo del participante. Esto permite a los participantes de la sesin conocer las identidades de los otros
participantes de la sesin.
Session Control- RTCP les permite a los participantes indicar que ellos estn dejando una sesin (mediante un paquete
RTCP BYE). Los participantes pueden tambin enviar pequeas notas a otros, tales como por ejemplo: voy saliendo de
la oficina. RTCP manda que todos los participantes de la sesin (incluyendo aquellos que slo escuchan) enven un
paquete peridicamente que contiene la informacin descrita anteriormente. Estos paquetes son enviados a la misma
direccin (multicast or unicast) como media RTP, pero en un puerto diferente. La informacin es enviada
peridicamente, ya que contiene informacin time-sensitive, como por ejemplo la calidad de recepcin que se pone
pesada despus 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, podra 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 llegara a ser
dificultosa con paquetes RTCP. Para corregir esto, RTCP especifica un algoritmo que permite al periodo incrementarse
en grupos grandes.

Estndares de Compresin de voz:
Los estndares recomendados por H323 para la compresin de la voz, son los siguientes:
G.711: Modulacin por impulsos Codificados PCM a 64kbit/s.
G.726: Modulacin por impulsos codificados diferencial adaptivo ADPCM, a 16, 24, 32, 40 kbit/s.
G.729: Codificador de la voz mediante prediccin lineal con excitacin por cdigo algebraico de estructura conjugada a
8 kbit/s de complejidad reducida.
A estos podemos agregar algunos opcionales como el G.728 (Codificacin de seales vocales a 16 kbit/s utilizando
prediccin lineal con excitacin por cdigo de bajo retardo) y G.722 (Codificacin de audio de 7 kHz) [7][12][13][14].

4.- Telefona usando protocolo IP (VoIP)
La telefona IP abarcar un amplio rango de servicios. Estos servicios incluyen no slo la tradicional conferencia,
llamadas a servicios suplementarios de control, transporte de multimedia y movilidad, sino que nuevos servicios que
integran Web, e-mail, presencia y aplicaciones de mensajera instantnea con telefona. Adems, es generalmente
aceptado que la telefona Internet y la tradicional telefona de conmutacin de circuitos coexistirn por algn tiempo,
requiriendo gateways entre los dos mundos.
Existen varias formas de transportar telefona, o para ser ms amplio Voz sobre protocolo IP por lo que se hace
necesario precisar algunos conceptos:
Voz sobre IP: Servicios de transporte de voz (telefona) sobre redes IP privadas sin realizar una conexin con la red
pblica conmutada (RTC).
Telefona IP: Telefona sobre redes IP con interconexin con la RTC.
Voz sobre Internet: Transporte de voz y servicios de telefona sobre la red pblica global a travs de la interconexin de
redes de conmutacin 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 travs de la red como si fueran datos; la transmisin de voz
sobre protocolo IP requiere de un elemento que transforme la voz a datos y realice la divisin en paquetes IP, este se
conoce como DSP, los cuales se incorporan comnmente en los gateways los cuales son los encargados de transmitir los
paquetes IP.


RED IP
Telfono IP
WAN
RED IP
Telfono IP
HUB
Telefnico
PABX
RTC
Gateway
PABX
RTC
Unidad de
Audioconferencia
multiple
DNS
Gatekeeper
PC+Adapatador
Gateway

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 transmisin a travs del protocolo RSVP, protocolo que se tratar
en el presente trabajo. Para ser ms preciso, los gateways en el caso de comunicacin entre telfono y un PC poseen una
conexin hacia la RTC y una hacia Internet, digitaliza la voz si es que no lo est, comprime, empaqueta y realiza la
traslacin entre direcciones IP y nmeros de la RTC, realizando el proceso simultneamente en ambos sentidos. Cuando
la llamada se realiza entre telfonos a travs 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 telefnicas desde el sistema telefnico tradicional hacia Internet, en donde una vez que se
alcanza un servidor cercano al destino, la llamada se traduzca nuevamente a su forma analgica original y puede ser
transmitida hacia el telfono destino perteneciente a la RTC.

Los principales componentes de una red VoIP son:
Telfonos IP, Adaptadores para PC, Hub telefnicos, Gateways, Gatekeepeer, Unidades de audio conferencia Mltiple
(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 segn corresponda, a fin de asegurar que la solucin sea ubicua.





















Figura 2: Los principales componentes de una red VoIP


El Gatekeeper
Los gateways se conectan con los gatekeepers de VoIP mediante enlaces estndar H.323v2, utilizando el protocolo RAS
H.225. Los gatekeepers actan como controladores del sistema y cumplen con el segundo nivel de funciones esenciales
en el sistema de VoIP de clase carrier, es decir, autentificacin, enrutamiento del servidor de directorios, contabilidad de
llamadas y determinacin de tarifas.
Servidores de Backend
El tercer nivel de la arquitectura de VoIP corresponde a la serie de aplicaciones de backoffice que constituyen el corazn
del sistema operativo de un proveedor de servicios. Poseen las bases de datos inteligentes y redundantes que almacenan
informacin crtica que intercambian con los gatekeepers durante las fases de inicio y trmino 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
solucin 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 estn integrados dentro de la arquitectura del

sistema de backend y administran las bases de datos SQL para las funciones de autentificacin, mapeo de directorios,
contabilidad y determinacin 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 mltiples, 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 actan como intermediarios entre diversas entidades, tal y como lo hacen los proxies en las redes
IP (conexin 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 transmisin. 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 prdidas
de los mismos, y garantizar una tasa de transmisin que no supere un umbral determinado. Garantizar calidad de servicio
en base a retardos y ancho de banda disponible slo 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 transmisin 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
transmisin de los paquetes de voz, y hacer que los retardos asociados a la transmisin de stos no superen los 150ms.
En lo relacionado con la priorizacin tenemos algunas alternativas:
Asignacin de un porcentaje de ancho de banda disponible.
Establecer prioridad en las colas.
Evitar tablas de routers intermedias.
Establecer rutas por paquetes; mediante la asignacin al trfico de menor carga.
En el estado actual de Internet, es muy posible obtener retardos superiores a los 300ms, con lo que en este escenario
resultara casi imposible tener una conversacin normal y fluda. Debido a que las redes de rea local no estn
preparadas en principio para este tipo de trfico, el problema puede parecer grave, ya que hay que tener en cuenta que
los paquetes IP son de longitud variable y el trfico de datos suele ser a rfagas. Existen opiniones encontradas acerca de
la calidad de las llamadas de voz que se realizan por la Internet pblica. Vale la pena destacar que los carriers utilizarn
particiones de backbones de IP bien diseadas para transportar el trfico de voz sobre IP, simplemente debido a que la
Internet pblica tiene patrones de trfico impredecibles y no fue desarrollada para manejar el trfico de la telefona de
clase carrier. La demora y la prdida de paquetes durante los perodos de alto nivel de trfico en la Internet pblica
degrada la calidad del trfico altamente sensible a las demoras como ocurre en el caso de la voz en tiempo real. La
performance de la voz en la Internet pblica puede mejorarse de manera notoria mediante el uso de algoritmos tales
como la correccin de errores sin retorno y la proteccin de paquetes.
En la actualidad, se estn 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 da.
Gracias a nuevos estndares que vendran a reforzar el estndar base VoIP/H323 como son los protocolos MGCP
(Media Gate Control Protocol), SIP (Session Initiation Protocol ) [34], MPLS y RSVP que se vern ms 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 mayora.

Factores que afectan el QoS
Retardo de los paquetes de voz: El retardo mximo para una comunicacin de buena calidad de extremo a extremo
segn el ITU es de 150ms, sin embargo la recomendacin G.114 recomienda que el lmite mximo en un canal
unidireccional de voz sea de 400ms. Cabe destacar que la apreciacin de la calidad de una comunicacin de voz tiene
una alta componente subjetiva, dependiendo de la razn 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 ms importante.

Latencia : Retardo total de los paquetes entre fuente y destino a travs de la red.
Jitter: Este parmetro resulta crtico para aplicaciones en tiempo real, como la voz, y representa la variacin en los
tiempos de llegada de los paquetes, que viajan por las diversas rutas o nodos con diferentes estados de congestin. Una
alternativa para mejorar el jitter es incorporar la tcnica 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 bsica es que si el buffer esta
vaco el paquete tardara un perodo de tiempo T constante (por ejemplo, de 20 ms) en atravesarlo, y si el buffer esta con
paquetes, los entrantes empujan a los que estn en su interior de tal manera que estos salgan con el mismo perodo T de
tiempo.
Prdida de paquetes: La prdida de paquetes tambin afecta la calidad de la voz, pero el porcentaje admisible depende en
alguna medida de los algoritmos de compresin usados, algunos bajo ciertas condiciones recuperan errores. El lmite
mximo de prdida de paquetes se sita alrededor del 8 y 10% [7].

7.- RSVP (ReSerVation Protocol) [4][5][18][19][20][21][22]
Su principal funcin es particionar los paquetes de datos grandes y dar prioridad a los paquetes de voz cuando hay una
congestin en un router. RSVP incorpora reserva de ancho de banda y retardo adems de establecer una lista de acceso
dinmica de extremo a extremo. Sus principales deficiencias se establecen en su defectuoso crecimiento (solucin vlida
en redes pequeas) y en su deficiente autorizacin y autentificacin. Adems hay que tener en cuenta que las actuales
infraestructuras no la tienen en cuenta. Si bien este protocolo ayudar considerablemente al trfico 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 estndar.

Caractersticas
Se disea para trabajar con cualquier servicio de QoS (los objetos propios de la QoS no estn 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 dnde se reenvan los paquetes mientras que RSVP se preocupa
por la QoS de los paquetes reenviados de acuerdo con el encaminamiento. Es un protocolo simplex: peticin de recursos
slo en una direccin, 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 aplicacin
particular. Un Router: para repartir peticiones de QoS a todos los nodos del camino del flujo de datos.
Una peticin 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 informacin del
camino de retorno hacia el emisor.
2- Mensajes de resv (generados por el receptor): a- Peticin de reserva de recursos. b- Crean el estado de la reserva en
los routers.























Figura 3: RSVP, primera aproximacin

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 tecnologa convencional. En especial MPLS es una gran ayuda para la ingeniera de trfico en redes IP y
puede tener un importante impacto en el transporte de voz.
La Ingeniera de trfico de Internet es el aspecto de la ingeniera de red de Internet que direcciona las entregas para una
ejecucin ptima de la operacin de la red. Abarca las aplicaciones tecnolgicas y principios para la medicin,
modelamiento, caracterizacin, y control de trfico de Internet [8]. Tambin incluye las aplicaciones de conocimiento de
tcnicas para alcanzar la ejecucin de objetivos especficos, incluyendo movimiento de trfico confiable y expedito a
travs de la red, eficiente utilizacin de los recursos de la red, y planificacin de la capacidad de la red. Una buena
ingeniera de trfico 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 ingeniera de trfico. Un marco para MPLS es presentado en [11] y una arquitectura
para l es descrita en [14]. Los requerimientos para la ingeniera de trfico sobre MPLS se aclarada en [8]. Aunque
MPLS es una tecnologa relativamente simple (basada en el clsico paradigma label swapping), habilita la introduccin
de capacidades de control sofisticados que hacen progresar las funciones de Ingeniera de trfico en redes IP [8-
10,12,13]. Un aspecto particularmente interesante de MPLS es que l soporta eficientemente control de conexin de
origen a travs 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 trfico con capacidad de MPLS denominados router de trfico
con conmutacin de etiquetas LSR (Label Switching Routers) de acceso, recibe un paquete IP, analiza la cabecera IP y
determina el destino. Este LSR de acceso aade una etiqueta al paquete IP, que identifica el trayecto orientado hacia el
destino y enva este paquete hacia el siguiente LSR [14-17]. El siguiente LSR enva el paquete basndose 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 vlida en el enlace con
el LSR siguiente. Antes de cualquier envo de paquetes, es necesario que los LSR cuenten con un acuerdo acerca de la
relacin existente entre las etiquetas y los trayectos. Esto se consigue utilizando el protocolo de distribucin de etiquetas
LDP (Label Distribution Protocol ). Siempre que la topologa de la red experimente un cambio (por ejemplo, a causa de
fallos de enlaces) se determinarn nuevos trayectos y el LDP proporcionar una nueva relacin de las etiquetas a los
trayectos.

2. LSR cabecera (entrada):
examina el paquete, lo
procesa (funciones de
servicio Nivel 3), lo etiqueta
y lo enva al backbone
3. LSRs del backbone
conmutan los paquetes
mediante intercambio de
etiquetas
4. LSR cola (salida):
Quita la etiqueta y
Entrega el paquete
al destino.
1b. Creacin de rutas
LSPs mediante tablas
de intercambio de
etiquetas entre LSRs
adyacentes. Distribucin
a los LSR por el LDP
1a. Construccin tablas de encaminamiento,
mediante Protocolos internos (OSPF, IS-IS, RIP)
La importancia de MPLS
El MPLS es importante por dos razones. Por un lado presenta un enfoque orientado a la conexin, as como un enfoque
sin conexin en la misma infraestructura; y por otro, permite la ingeniera de trfico.
El MPLS proporciona tanto un enfoque orientado a la conexin y basado en la calidad de servicio, como un enfoque
tradicional sin conexin basado en la capacidad disponible en ese momento.



















Figura 4. Funcionamiento de una red MPLS


Conclusiones
El estndar H323/VoIP, el despliegue de RSVP, MPLS, en conjunto con los protocolos desarrollados por el IETF [33]
(que proveen una solucin parcial para la VoIP) y los actuales y futuros desarrollos relacionados, prometen que el
estndar definitivo de la voz sobre el protocolo IP ser una realidad, y el despliegue de esta tecnologa tambin. En lo
relativo al tiempo para su implementacin, no est claro el escenario y ste depender tambin de las adecuaciones y
desarrollos de las actuales y futuras redes, y de las polticas corporativas y gubernamentales. Lo que s parece evidente
es que la implantacin sobre entornos privados, en donde se posee el control de todos los parmetros de la red, la
implantacin debera producirse muy rpidamente, tanto sobre redes ATM y redes IP privadas. Tambin est muy
entendido que en lo relacionado con el QoS an 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 http://www.iec.org/online/tutorials /voip _voatm/ topic01.html - WebProforum
Tutorials Mar 2002
[2] Multiprotocol Label Switching (MPLS) web Proforum Tutorials International Engineering Consortium Copyright
2002 http://www.iec.org/ Mar-April 2002
[3] MPLS Applications MPLS addresses today's network backbone requirements effectively by providing a standards-
based solution that accomplishes the following: improves packet-forwarding http://www.iec.org/online/
tutorials/mpls/topic06.html - size 2.0K - WebProforum Tutorials mar 2002
[4] RSVP Refresh Overhead Reduction Extensions http://www.ietf.org/rfc/rfc2961.txt 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.
http://www.cisco.com/univercd/cc /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

[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-
0083.001, February 1999
[11] Voz sobre IP, http://www.cespa.es/ga/recetga/ proxrecet.html
[12] Presente y futuro de la Integracin de las redes de voz sobre IP, http/www.astic.es/vozip.htm
[13] ITURecommendation 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] Jess Angel Pastor Ferrero Voz sobre IP: presente y futuro de integracin de redes de voz sobre IP"
http://www.astic.es/vozip.htm
[17] VOIP Voz sobre IP http://www.monografias.com/ trabajos3/voip/ voip.shtml
[18] Andrew S. Tanenbaum, RSVP Redes de computadores Editorial PEARSON 1997
[19] RSVP http://www.fi.upm.es/~jgarcia/public_html_ backup/apuntes.htm
[20] Sergi Snchez, Xavi Masip, Jordi Domingo Protocolo RSVP: Evolucin y experiencias.
www.rediris.es/rediris/boletin/46-47/ponencia11.html
[21] RSVP http://jungla.dit.upm.es/~proy/doct/claudia/ apres01/sld012.htm
[22] RSVP http://gsyc.escet.urjc.es/docencia/cursos/fse-mbone/transpas/node10.html
[23] D. Awduche et al., "Requirements for Traffic Engineering Over MPLS," RFC 2702, Sept. 1999.
[24] D. Awduche et al., "Extensions to RSVP for Traffic Engineering," IETF Internet draft, work in progress, Feb.
1999.
[25] D. Awduche, A. Hannan, and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels," IETF
Internet draft, work in progress, july 1999.
[26] R. Callon et al., "A Framework for Multiprotocol Label switching." IETF Internet draft, work in progress. Nov.
1997.
[27] B Jamoussi et al., "Constraint-Based LSP Setup Using LDP," IETF Internet draft, work in progress, Feb. 1999.
[28] T. Li, G. Swallow, and D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," IETF Internet draft,
work in progress, Feb. 1999.
[29] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label switching Architecture," IETF Internet draft, work
in progress, June 1998.
[30] Shen and H. Smit, "Calculating GP Routes over Traffic Engineering Tunnels," IETF Internet draft, work in
progress, June 1999.
[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] http://www.netbricks.net/pdfnew/sip-bricks.pdf