Propuesta de arquitectura multiprotocolo para la implantación

incremental de un modelo de servicio con garantías QoS sobre

redes IP
Alfonso Gazo Cervero, José Luis González-Sánchez
Área de Ingeniería Telemática. Departamento de Informática. Universidad de Extremadura.
Av/ Universidad s/n. 10071 Cáceres
Teléfono 927 257 253 Fax: 927 257 202
Email:{agazo,jlgs}@unex.es

Abstract Internet currently offers a very simple delivery service, based in the best-effort model.
Using this model, the higher guarantee that the network provides is reliable data delivery. Never-
theless, new kinds of applications have been recently developed, like videoconference, VoIP or VPN,
which are sensitive to the QoS that they obtain from the network. In particular, traditional data deliv-
ery, where reliability can be obtained in change of not-controlled delays, becomes inacceptable.
Before these new kinds of applications can be widely used, the Internet infraestructure must be
modified to offer QoS at real-time and end to end controlled delays. Nevertheless, it seems reasonable
to consider this requirement high enough to, in case of taking it on, it could only be satisfied at long
time and big effort.
In this work we propose an architecture that enables an incremental implantation over Internet
of a model of service in a way that the user QoS requirements could be satisfied at the places where
certain mechanisms would be present.

1. Introducción ciones propietarias para la provisión de garantías QoS,

La simplicidad del modelo de servicio basado en
best-effort es una de las razones esenciales del éxito de
Internet. Esta simplicidad ha permitido que IP sea im-
plementado sobre cualquier nivel de enlace concebible
y también ha provocado que la gestión de red y la in-
terconexión de proveedores sean tareas asumibles por
organizaciones de muy diferente tamaño. Junto con las
ventajas inherentes de la tecnología no orientada a co-
nexión y el principio de diseño extremo a extremo, el
modelo de servicio best-effort ha permitido una Inter-
net rápida, sencilla, barata y altamente escalable.
Sin embargo, ahora el reto consiste en conseguir
diferenciar esquemas de tráfico como un servicio de
valor añadido a la red, sin añadir una complejidad adi-
cional significativa y sin poner en peligro los principios
de diseño que han hecho de Internet la red de mayor
éxito en la actualidad.
La implantación de tecnologías como VPN sobre
Internet, VoIP, aplicaciones de telemedicina, televigi-
lancia o domótica requiere esta diferenciación con ob-
jeto de ofrecer garantías con respecto a la calidad del
servicio (QoS, Quality of Service) [1] ofertada. Un es-
cenario especialmente atractivo para la implementa-
ción de QoS sobre IP es la posibilidad de proporcionar
un entorno multiservicio sobre el núcleo de una red de
un proveedor de servicios.
Si bien en el contexto de un único proveedor de
servicios se pueden adoptar, e incluso desarrollar, solu-
la dificultad surge cuando se trata de aplicar un mode-
lo outsourcing donde, para la provisión de un servicio,
se requiera la intervención coordinada de más de un
proveedor. Por ello se hace necesaria la implantación
de un modelo de servicio que, si no es único para to-
dos los proveedores de servicio presentes en Internet,
sí que debería permitir al menos la interoperabilidad
entre modelos diferentes.
Este trabajo comienza analizando el modelo de ser-
vicio utilizado actualmente en Internet, para a conti-
nuación describir las propuestas más relevantes para
la provisión de garantías QoS. Analizando algunos pa-
rámetros organizativos de Internet en la actualidad, se
presenta una propuesta cuya característica principal es
la de no requerir la migración completa de los elemen-
tos de red en Internet para lograr la provisión de garan-
tías QoS. Por último, se presentan los trabajos futuros
y las conclusiones extraídas hasta el momento.
2. Trabajos relacionados
Posiblemente el modelo de servicio más popular
es el best-effort, en el que el tráfico se procesa lo más
rápidamente posible, pero no existen garantías ni res-
tricciones temporales ni siquiera de entrega real. Éste
es el único modelo de servicio soportado hasta ahora
por Internet. Otro modelo de servicio ampliamente ex-
tendido es el ofrecido por la red telefónica, donde se
asigna un circuito fijo para cada llamada.
 Últimamente se han desarrollado dos modelos para
proporcionar QoS en Internet: el modelo de Servicios
Integrados (IntServ) [2] y el modelo de Servicios Dife-
renciados (DiffServ) [3]. La base de IntServ es reser-
var recursos (ancho de banda y espacio en búfer) para
cada flujo de forma que la QoS pueda ser garantizada
en caso de que sea necesario. La base de DiffServ es
dividir el tráfico en clases diferentes y dar a cada una
de estas clases un tratamiento diferente. Ambos mode-
los necesitan utilizar mecanismos ubicados en los ni-
veles de red y de transporte para poder proporcionar
esta QoS.
El enfoque DiffServ está considerado actualmente
por muchos expertos como el modelo a implantar para
proporcionar QoS en Internet. Desde esta perspectiva,
técnicas como la ingeniería de tráfico, MPLS [4], enca-
minamiento basado en restricciones, reencaminamien-
to rápido, redirección de tráfico o equilibrio de carga
son independientes. Sin embargo, en [5] se argumenta
que la utilización de los modelos IntServ/DiffServ no
resuelve todos los problemas relacionados con la ob-
tención de QoS en Internet y se expone una arquitectu-
ra que incluye el modelo DiffServ, pero también otras
técnicas en los niveles de aplicación y de red (tabla 1).
DiffServ proporciona una degradación diferencia-
da (o no degradación) en el rendimiento para clases de
tráfico diferentes allí donde hay congestión en la red.
Si puede evitarse la congestión, el rendimiento de todo
el tráfico será bueno incluso sin DiffServ. La ingenie-
ría del tráfico puede evitar la congestión causada por
una distribución de tráfico no equitativa a lo largo de
la red. Es por esto por lo que la ingeniería del tráfico
resulta útil para proporcionar QoS.
De forma adicional, DiffServ no proporciona me-
canismos para atender fallos en enlaces o en router. En
estas situaciones en las que el tráfico enviado a lo largo
de la ruta se pierde, el tiempo de recuperación es crí-
tico. De ahí la necesidad de implantar mecanismos de
reencaminamiento rápido para la provisión de QoS.
La redirección de tráfico resulta útil para evitar
congestionar ciertas zonas de la red, de modo que exis-
tan varias fuentes dispersas geográficamente que sean
elegidas por los clientes de forma dinámica. El equili-
bro de carga permite la utilización de varios servido-
res, en este caso geográficamente cercanos, entre los
que se distribuyen las peticiones de los clientes. El ob-
jetivo de la aplicación de mecanismos de equilibro de
carga es el incremento de la disponibilidad del servicio
y la reducción de la carga por servidor.
En la figura 1 se muestra una evolución de algunas
de las tecnologías implicadas en la provisión de garan-
tías QoS en Internet.
3. Arquitectura propuesta para
la implantación incremental de
garantías QoS
3.1. Motivación
Desde la especificación de IntServ se ha intentado
incorporar una arquitectura que permitiera ofrecer QoS
sobre Internet, ya que es deseable que Internet se utili-
ce como una infraestructura común para soportar tan-
to la comunicación en tiempo real como la que no es
en tiempo real. Se podría construir una infraestructura
totalmente nueva para los servicios en tiempo real, de
forma paralela, dejando Internet tal y como está actual-
mente. Sin embargo, se perderían las ventajas signifi-
cativas de la compartición estadística entre los tráficos
en tiempo real y no tiempo real, además de convertirse
en algo más complejo de construir y administrar que
una infraestructura común.
El tamaño actual de Internet provoca que la mo-
dificación de su arquitectura para poder ofrecer QoS
esté lejos de ser una tarea sencilla. Cada dominio de
encaminamiento (conocido como Autonomous System
o AS) tiene su propia configuración hardware y soft-
ware sobre la que no siempre se puede actuar para in-
corporar extensiones a los protocolos soportados y/o
configurados. Por diversos motivos, existirán organi-
zaciones que, siendo responsables de uno o varios AS,
decidan migrar su arquitectura hacia una arquitectura
que pueda proporcionar QoS, mientras otras postpon-
gan esta decisión.
El hecho de que no se realice una implantación
completa de la nueva arquitectura en Internet provoca
que no se puedan ofrecer garantías estrictas relativas a
la obtención de QoS, aunque sí se proporcionen garan-
tías estadísticas bajo ciertas restricciones.
Bajo el prisma de DiffServ, la situación no es ne-
cesariamente. Aunque los requerimientos en los ele-
mentos de la red para la implantación de una arqui-
tectura DiffServ en un AS parecen inferiores a los de
la implantación de una arquitectura IntServ, no dejan
de existir unos requisitos mínimos que muchos AS ac-
tualmente no alcanzan.
Nuestra premisa de partida consiste en que el re-
quisito de migrar completamente toda la arquitectura
de Internet para poder ofrecer garantías de QoS a los
usuarios resulta inaceptable. Las propuestas relaciona-
das con la arquitectura Internet2 QBone [6] todavía
están lejos de llegar a los usuarios finales, que actual-
mente demandan de la red la obtención de QoS. Las
aplicaciones se encuentran en este sentido por delante
de los servicios que la red puede ofrecer.
Este trabajo está dirigido a la propuesta de una es-
pecificación que permita realizar una migración de la
actual arquitectura de Internet hacia una arquitectura
capaz de proveer QoS. La característica fundamental
de esta arquitectura es la posibilidad de realizar una
implantación incremental, de forma que puedan reali-
zarse garantías QoS incluso si existieran nodos en la
red que tan sólo proporcionaran un modelo de servicio
 Tabla 1: Algunos mecanismos que garantizan o ayudan a la provisión de QoS en Internet

Nivel Esquema de QoS Mecanismos Objetivo del esquema de QoS

Aplicación Redirección de trá- Redirección mediante URL, Redirigir el tráfico lejos de una par-
fico y equilibrio de equilibro de carga te congestionada de la red o un ser-
carga vidor
Transporte / Diffserv Clasificación, contador, Proporcionar servicios diferencia-
Red marcador, adaptador, des- dos para diferentes clases de tráfi-
cartador, RED co, especialmente durante conges-
tión en la red
Red Ingeniería de tráfico MPLS, encaminamiento ba- Evitar congestión en la red
sado en restricciones, señali-
zación de rutas LSP y proto-
colos IGP de estado de enla-
ce mejorados
Reencaminamiento Recuperación local Evitar la pérdida de paquetes debi-
rápido do a fallo de enlaces o router.

1981 1989 1994 1995 1998 1999 2000 2001 2002

IPv4 OSPFv1 OSPFv2

Carga controlada
IntServ QoS garantizada
RSVP

IPv6 OSPF para IPv6 RSVP IPv4+IPv6

Arq 2-bit
PDB Spec TE + DS
DiffServ EF PHB
AF PHB
VW PDB
BH PDB
MPLS + DS

Figura 1: Evolución de algunas tecnologías implicadas en la provisión de QoS en Internet

best-effort. Esto da lugar a una evolución de la actual
arquitectura de Internet, no una modificación completa
(figura 2).
A continuación se exponen cuáles son los objetivos
de este trabajo.
3.2. Alcance y objetivos
La arquitectura actual de Internet no ofrece nin-
guna garantía con respecto a los parámetros de QoS,
salvo la entrega fiable. Partimos entonces de que cual-
quier modificación de la arquitectura que permita a In-
ternet ofrecer una garantía mayor será considerado un
avance, pero sólo si no repercute negativamente sobre
el rendimiento actual de la red.
Por ello, en este trabajo se pretende:
Incorporar mecanismos que permitan negociar
la QoS obtenida desde la red. Si la red no pue-
de ofrecer los requerimientos de QoS mínimos
aceptables por el cliente, debe indicárselo recha-
zando la negociación [7].
Que la incorporación de estos mecanismos ten-
ga un impacto negativo mínimo sobre el ren-
dimiento de la arquitectura actual. Los tráficos
best-effort y QoS deben coexistir, no estar en-
frentados.
Que la incorporación de estos mecanismos ten-
ga un impacto mínimo sobre cambios de confi-
guración de la equipación actual, proporcionan-
do mecanismos de configuración automática allí
donde puedan estar disponibles.
Que las pilas de protocolos best-effort no se vean
modificadas en ninguno de los elementos de la
red.
El fin último es proporcionar QoS a los clientes que lo
soliciten y contraten en caso de que pueda encontrarse
algún modo de proporcionar esta QoS. Si los paráme-
tros de QoS son inaceptables, el cliente no se encon-
trará con un caso diferente al actual funcionamiento de
Internet, que no realiza ninguna garantía con respecto
a estos parámetros. Si es imposible garantizar los pará-
metros de QoS incluso con estos nuevos mecanismos,
 Figura 2: Evolución hacia una arquitectura que permita la provisión de QoS sobre Internet
tampoco se habrá llegado a una situación peor a la ac-
tual.
De este modo se aportarían ventajas a los siguien-
tes agentes:
Los usuarios se verán beneficiados de las ven-
tajas que supone la posibilidad de contratar una
conexión QoS.
El ISP tiene garantizada una ventaja competitiva
con respecto al resto de ISP que no ofrezcan un
servicio QoS.
Los carrier que oferten un servicio QoS acaba-
rán manejando más volumen de tráfico, ya que
a través de ellos seguirá circulando tráfico best-
effort y adicionalmente, todo el tráfico de las co-
nexiones QoS que los carrier de la competencia
pierden por no ofertar QoS. Este incremento en
el volumen de tráfico supondrá, de forma directa
o indirecta [8], un aumento en sus beneficios.
Uno de los escenarios de clara aplicación de la pro-
puesta puede encontrarse en los AS Multihoming, tan-
to en el caso de que el AS pertenezca a un cliente o a
un proveedor. En este caso, el AS dispone de conecti-
vidad mediante varios proveedores. Si suponemos que
alguno de estos proveedores oferta un servicio QoS,
los equipos del AS Multihoming podrán negociar au-
tomáticamente el establecimiento de rutas QoS a través
de los proveedores que dispongan de una arquitectura
capaz de garantizar conexiones QoS. Para ello bastará
con haber negociado un acuerdo de nivel de servicio
(Service Level Agreement o SLA) entre el AS Multiho-
ming y el AS proveedor que oferta QoS. Con respec-
to a las conexiones no-QoS, podrán encaminarse bien
por los proveedores que ofertan QoS (ya que además
mantienen el servicio best-effort) o bien por los que
no (figura 3). De este modo, si cada AS que atravie-
sa un flujo de aplicación dispone de la posibilidad de
encontrar una ruta QoS a través de alguno de sus pro-
veedores, se podrá garantizar un servicio QoS incluso
si no todos los nodos en la red ofertan un servicio QoS.
1 Los router son los responsables de calcular esta ruta, pero el BB también puede calcularla, ya que dispone de la información de encami-
namiento que los router del AS le proporcionan. De este modo, el BB puede determinar si sobre esta ruta se satisfacen los parámetros de QoS
solicitados.
3.3. Arquitectura
3.3.1. Bandwidth Brokers (BB)
Todavía existen decisiones de diseño abiertas rela-
cionadas con los BB, aunque podemos encontrar va-
rios trabajos en curso [9, 10, 11, 12, 13, 14, 15] en los
que se fijan algunas de ellas, llegando en algunos casos
a desarrollos funcionales.
La figura de un agente BB como parte de un do-
minio DiffServ (DiffServ Domain o DSD) se introduce
en [16], aunque para nuestra propuesta se requiere de
la presencia de un agente en el contexto de un AS que
realice tareas complementarias a las del BB. Decidi-
mos incorporar esta nueva funcionalidad como parte
del BB del AS, siendo la siguiente:
Control de los router del DSD mediante di-
ferentes protocolos de señalización, e incluso
de mecanismos como Telnet/SSH allí donde los
router no soportaran ningún protocolo de seña-
lización específico (como COPS o RSVP). Este
control está relacionado con el establecimiento
de los parámetros requeridos por las diferentes
clases de servicio. Equipos de encaminamien-
to diferentes pueden soportar protocolos de se-
ñalización diferentes para el establecimiento de
estos parámetros y el BB debe poder contro-
lar todos los dispositivos de encaminamiento del
DSD.
Soporte de señalización directa RSVP para
reserva de recursos. Con objeto de permitir la
interoperabilidad entre DSD y redes IntServ, los
ingress router presentes en un DSD y conecta-
dos a redes IntServ señalizarán directamente a
su BB las peticiones RSVP que reciben desde
los egress router de la red IntServ (figura 4).
Monitorización de la información de encami-
namiento realizado en el DSD. Para ello, el BB
debe comportarse como un elemento que recibe
la información del protocolo de encaminamiento
como si fuera un router más, pero sin embargo
no propaga la información de encaminamiento
computada al resto de los router.
Actuación directa sobre las restricciones
QoSR. Si, utilizando un algoritmo de encami-
Figura 3: Un AS Multihoming puede enviar tráfico QoS a través del proveedor que lo soporta, y tráfico best-effort
a través de cualquiera
namiento no-QoSR, la ruta calculada1 para esta-
blecer un flujo best-effort no satisficiera los re-
querimientos para establecer un flujo QoS, el BB
deberá actuar para que los router implicados uti-
licen una ruta diferente. Si se utiliza un algorit-
mo de encaminamiento QoSR, esta funcionali-
dad no es necesaria y el BB se limitará a la mo-
nitorización de la provisión global de QoS. Esto
puede permitir la implantación de provisión de
QoS en un AS incluso sin que todos sus elemen-
tos estén preparados para proporcionar garantías
QoS.
En la figura 4 se muestra una perspectiva general de
la relación de los BB con el resto de elementos de su
entorno.
Los BB deben conocer la topología del AS en el
que se encuentran, para lo que disponen de una ba-
se de datos de interfaces, además de la información
de encaminamiento obtenida mediante el protocolo de
encaminamiento. El conocer la topología permite a los
BB, entre otras tareas, comunicarse directamente con
los router del AS para controlarlos. Este control puede
realizarse mediante diferentes mecanismos de señali-
zación y control:
RSVP [17], donde no se utilizan todos los meca-
nismos descritos en su especificación, sino tan
sólo aquellos de señalización de reservas me-
diante mensajes RESV. A través de estos mensa-
jes, el BB indica directamente al router corres-
pondiente las características de las reservas para
cada uno de los niveles de servicio en el contexto
del propio router.
COPS [18], un protocolo basado en TCP que uti-
liza un modelo cliente/servidor basado en los si-
guientes elementos:
• El PEP (Policy Enforcement Point) es una
entidad donde se aplican las políticas es-
tablecidas. Generalmente el PEP será un
router o un gateway ubicado en una fron-
tera del AS.
• El PDP (Policy Decision Point) es el res-
ponsable de la obtención de las reglas a
aplicar y de la generación de decisiones de
acuerdo con las peticiones recibidas desde
el PEP. El PDP actúa por tanto como ser-
vidor para el PEP. Por sus características,
podría integrarse con el BB del AS.
SNMP [19], incorporado en la mayoría de los
router, puede permitir el control del router por
parte del BB para establecer los parámetros de
clasificación y planificación de paquetes en ca-
so de que el router no soporte otros protocolos
como RSVP o COPS.
Telnet/SSH. Si el router no dispusiera de capa-
cidad de ser controlado mediante COPS o RSVP
y su agente SNMP no implementara el MIB co-
rrespondiente para el establecimiento de los pa-
rámetros de clasificación y planificación de pa-
quetes, el BB todavía podría controlar el router
mediante mecanismos Telnet/SSH.
En caso de utilizar un control basado en COPS, los
router además deben conocer la localización del BB
en el AS. Esta localización del BB desde los router
puede estar preconfigurada (mediante SNMP o Tel-
net/SSH) o bien puede realizarse automáticamente me-
diante SLP[20].
Además, los BB deben localizar los BB de los DSD
adyacentes. Como decisión de diseño abierta se propo-
nen varias opciones:
Incorporar la información de localización en la
información distribuida mediante el protocolo
BGP.
Incorporar señalización entre router in-
gress/egress para que indiquen directamente la
localización de los BB de sus respectivos AS.
Utilizar el protocolo SLP, aunque para ello de-
ben encontrarse disponibles capacidades de en-
caminamiento multicast en los AS adyacentes.
 Figura 4: Relación entre BB de AS adyacentes
3.3.2. Arquitectura intra-DSD
De forma generalizada se acepta que el protoco-
lo OSPF no es lo suficientemente flexible como para
proporcionar un buen equilibro de carga. Precisamen-
te esta es una de las razones para introducir tecnolo-
gías más flexibles, como MPLS, siendo esta una línea
de trabajo abierta en la actualidad cuando se relaciona
con la provisión de QoS en Internet.
Para el caso concreto de la utilización de OSPF, se
proponen varias alternativas para los aspectos relacio-
nados con el encaminamiento QoS en el contexto de
un AS:
Incorporación de extensiones QoSR al protoco-
lo OSPF, mediante la propuesta de LSA opacos
[21]. En este caso, los dispositivos de encamina-
miento implicados en la provisión de QoS deben
soportar las extensiones propuestas.
Utilización de la capacidad de OSPF para la
construcción de bases de datos de estado de en-
lace diferentes en función del campo TOS de
IPv4. De este modo se sigue utilizando el en-
caminamiento best-effort sin necesidad de mo-
dificar el protocolo, y se pueden añadir métricas
diferentes a los enlaces en función de paráme-
tros QoS que se utilizarán para procesar los flu-
jos QoS. En cualquier caso, debe realizarse un
mapeo entre la clase de servicio asignada a un
flujo y el campo TOS sintético aplicado para de-
terminar qué base de datos de estado de enlace
debe utilizarse.
Actuación sobre las métricas de encaminamien-
to OSPF, mediante un agente externo que moni-
torice la correcta provisión de QoS conforme a
las métricas establecidas en el contexto del DSD
y actúe cuando estas métricas no permitan el es-
tablecimiento de una nueva conexión QoS. De
este modo, en ciertas ocasiones, se provocaría la
actualización de las bases de datos de estado de
enlace cuando se requiera una nueva conexión.
Para evitar un impacto excesivo sobre la red, se
podrían utilizar mecanismos de histéresis que li-
miten estas actualizaciones.
3.3.3. Arquitectura inter-DSD
La arquitectura inter-DSD todavía no ha sido estu-
diada en profundidad, pero se parte de dos alternativas:
Modificación de BGP con extensiones QoSR.
Para determinar qué router disponen de capaci-
dades QoS, se podría utilizar la propuesta [22].
Señalización interDSD a través de los BB de los
DSD adyacentes. De este modo son los propios
BB los que acaban determinando los AS que
cruzará el flujo QoS que está tratando de esta-
blecerse. Una vez que los BB han determinado
los AS que atravesará el flujo, tan sólo tienen
que indicar a los router de sus DSD respectivos
cuál es el egress router que debe utilizarse.
4. Conclusiones y trabajos futu-
ros
En este trabajo presentamos una propuesta de ar-
quitectura para una implantación incremental de ga-
rantías de QoS sobre redes IP. Su diseño está orientado
a permitir el establecimiento de garantías QoS para los
flujos de aplicación incluso en el caso de que no to-
dos los elementos de la red permitan la asignación de
restricciones QoS.
Por un lado, en el intra-dominio, para el estableci-
miento de garantías QoS a los clientes basta con que
exista al menos una ruta desde el ingress router hasta
el egress router correspondiente de modo que los ele-
mentos de red atravesados permitan el establecimiento
de mecanismos de clasificación y planificación de pa-
quetes. El BB del dominio es el responsable de las ac-
tuaciones orientadas a que los paquetes que conforman
el tráfico QoS sigan las rutas con restricciones QoS es-
tablecidas, así como del establecimiento de estas res-
tricciones.
Por otro lado, en el inter-dominio, se pueden esta-
blecer garantías QoS si existe al menos una ruta en la
que todos los AS atravesados disponen de capacidad
de provisión de QoS. Puesto que todo AS que permita
la provisión de garantías QoS debe disponer de un BB,
esto permite que los BB de los AS adyacentes pue-
dan intercambiar información para el establecimiento
de rutas QoS a través de ellos, ignorando los AS sin
capacidad de provisión de QoS.
Este escenario resulta especialmente atractivo pa-
ra el caso de los clientes que disponen de conectividad
mediante más de un proveedor (formando un AS Mul-
tihoming), que corresponde con más del 61 % de los
AS en Internet. Si alguno de los proveedores dispo-
ne de capacidad de provisión QoS, en un AS Multiho-
ming el tráfico QoS se puede dirigir a través de estos
proveedores, mientras que el tráfico best-effort se pue-
de dirigir a través de cualquier proveedor, disponga de
capacidad para la provisión de QoS o no.
Actualmente estamos trabajando en el desarrollo
de un prototipo que permita demostrar la potencial via-
bilidad de la propuesta. En este sentido se está traba-
jando sobre el desarrollo de un agente Bandwidth Bro-
ker sobre el sistema operativo Linux para el control
automático de los parámetros de control de tráfico, ini-
cialmente sobre nodos Linux, pero con una arquitec-
tura que permitirá el control por parte del Bandwidth
Broker de otros elementos de red.
Referencias
[1] R. Steinmetz y L. Wolf. Quality of Service: Whe-
re are We? En IWQOS’97, páginas 211–221.
1997.
[2] R. Braden, D. Clark y S. Shenker. Integrated Ser-
vices in the Internet Architecture: an Overview.
IETF RFC 1663, Julio 1994.
[3] K. Nichols, S. Bloake, F. Baker y D. Black. De-
finition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 headers. IETF RFC
2474, Diciembre 1998.
[4] E. Rosen, A. Viswanathan y R. Callon. Multipro-
tocol Label Switching Architecture. IETF RFC
3031, Enero 2001.
[5] Xipeng Xiao. Providing Quality of Service in the
Internet. Tesis Doctoral, Department of Com-
puter Science and Engineering, Michigan State
University, 2000.
[6] Benjamin Teitelbaum y Rüdiger Geib. Internet 2
QBone: A Test Bed for Differentiated Services.
En INET’99. Junio 1999.
[7] E. Crawley, R. Nair, B. Jajagopalan y H. Sandick.
A Framework for QoS-based Routing in the In-
ternet. IETF RFC 2386, Agosto 1998.
[8] Geoff Huston. Interconnection, Peering, and
Settlements. En INET’99. Junio 1999.
[9] British Columbia Institute of Technology.
CA*net II Differentiated services: bandwidth
Broker High Level Design, Noviembre 1998.
[10] M. Günter y T. Braun. Evaluation of Bandwidth
Broker Signalling. En Proc. of IEEE 7th Interna-
tional Conference on Network Protocols, páginas
145–152. Octubre 1999.
[11] Ibrahim Khalil y Torsten Braun. Implementa-
tion of a Bandwidth Broker for Dynamic End-to-
End Capacity Reservation over Multiple Diffserv
Domains. Lecture Notes in Computer Science,
2216:160–??, 2001.
[12] B. Stiller, T. Braun, M. Günter y B. Plattner. The
CATI project: charging and accounting techno-
logy for the Internet. En Proc. of 4th European
Conference: Multimedia Applications, Services
and Techniques, páginas 281–296. Mayo 1999.
[13] R. Rajan, D. Verma, S. Kamat, E. Felstaine y
S. Herzog. A policy framework for Integrated
and Differentiated Services in the Internet. IEEE
Network Magazine, 13(5):35–41, Sep / Oct 1999.
[14] Andreas Terzis, Jun Ogawa, Sonia Tsui, Lan
Wang y Lixia Zhang. A Prototype Implementa-
tion of the Two-Tier Architecture for Differen-
tiated Services. 5th IEEE Real-Time Techno-
logy and Applications Symposium (RTAS99), Ju-
nio 1999.
[15] Jussi Lemponen. Implementation of Differentia-
ted Services Policy Information Base on Linux.
Proyecto Fin de Carrera, Tampere University of
Technology. Department of Information Techno-
logy, Abril 2001.
[16] K. Nichols, V. Jacobson y L. Zhang. A Two-bit
Differentiated Services Architecture for the Inter-
net. IETF RFC 2638, Julio 1999.
[17] R. Braden, L. Zhang, S. Berson, S. Herzog
y S. Jamin. Resource ReSerVation Protocol
(RSVP). IETF RFC 2205, Septiembre 1997.
[18] D. Durham, J. Boyle, R. Cohen, S. Herzog,
R. Rajan y A. Sastry. The COPS (Common Open
Policy Service) Protocol. IETF RFC 2748, Enero
2000.
[19] F. Baker, K. Chan y A. Smith. Management In-
formation Base for the Differentiated Services
Architecture. IETF RFC 3289, Mayo 2002.
[20] E. Guttman, C. Perkins, J. Veizades y M. Day.
Service Location Protocol, Version 2. IETF RFC
2608, Junio 1999.
[21] R. Coltun. The OSPF Opaque LSA Option. IETF
RFC 2370, Julio 1998.
[22] R. Chandra y J. Scudder. Capabilities Advertise-
ment with BGP-4. IETF RFC 3392, Noviembre
2002.