You are on page 1of 124

Universidad de Mendoza

Facultad de Ingeniera
Tesis de Maestra en Teleinformtica
Controlador de Ancho de Banda
Ing. Diego Fernando Navarro
Directores de Tesis:
Magister Ing. Hugo Etchegoyen
Ing. Osvaldo Rosso
Mendoza, Noviembre de 2005
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Agradecimientos
Quiero agradecerle especialmente a Claudia mi esposa por su continuo aliento,
comprensin, compaa y amor.
A mi Familia, en especial a mis padres Ral y Kitty por haberme educado y dado
siempre todo para llegar a realizar mis metas.
A Jjo por su compaerismo, humildad y entrega en todos los proyectos que hemos
compartido.
A Alfredo, Carlos y Salvador por confiar en m, en mi trabajo y ayudar a
desarrollarme como alumno, docente y persona.
A Silice S.A. y a todo el grupo humano que lo compone por permitir y ayudar a
que este trabajo se desarrolle y divulgue.
A la empresa ITC S.A. por contribuir con su requerimiento a la construccin de
este proyecto y en particular a Sergio Lorenzo por su paciencia y aporte a la
estabilidad del desarrollo aqu expuesto.
2/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
ndice de contenido
1. Resumen...............................................................................................................6
2. Introduccin.........................................................................................................8
3. La Internet Hoy ...................................................................................................9
3.1. Simplicidad de Estado................................................................................10
3.2. Equidad.......................................................................................................10
3.3. Aplicaciones de prxima generacin..........................................................11
4. Componentes de QoS ........................................................................................13
4.1. Una jerarqua de Redes...............................................................................14
4.2. Comportamiento predecible por salto........................................................16
4.3. Congestin transitoria, latencia, jitter y prdida.........................................16
4.4. Clasificacin, Encolado y Scheduling........................................................19
4.5. Comportamiento predecible borde a borde................................................19
4.6. Modelos Extremo y Ncleo........................................................................20
4.7. Modelado y Vigilancia ..............................................................................21
4.8. Marcado y Reordenamiento........................................................................24
4.9. Ruteo Borde a Borde .................................................................................25
4.9.1. El ruteo basado en QoS.......................................................................26
4.10. Sealizacin..............................................................................................28
4.11. Polticas, autenticacin y facturacin ......................................................31
4.12. Un router genrico....................................................................................34
5. Modelos de Red borde a borde ..........................................................................38
5.1. Evolucin de QoS y modelos extremo a extremo......................................39
5.2. Modelos de QoS.........................................................................................41
5.2.1. IntServ.................................................................................................41
5.2.2. DiffServ..............................................................................................43
5.3. MPLS Conmutacin multiprotocolo por etiqueta...................................45
6. Control de Trfico en Linux...............................................................................49
6.1. Introduccin................................................................................................49
6.2. Terminologa..............................................................................................52
6.3. Elementos del Control de Trfico...............................................................54
6.4. Disciplinas de cola simples, sin clases.......................................................59
6.4.1. pfifo_fast.............................................................................................59
3/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.4.2. Token Bucket Filter............................................................................60
6.4.3. Stochastic Fairness Queueing.............................................................61
6.4.4. ESFQ, Extended Stochastic Fair Queuing..........................................62
6.4.5. RED (Random Early Detection).........................................................63
6.5. Disciplinas de colas classfull......................................................................65
6.5.1. DSMARK...........................................................................................66
6.5.2. HTB (Hierarchical Token Bucket) [HTBLUG]..................................68
6.5.2.1. Compartiendo el enlace...............................................................68
6.5.2.2. Jerarqua de comparticin...........................................................72
6.5.2.3. Velocidad Techo.........................................................................74
6.5.2.4. Rfagas........................................................................................75
6.5.2.5. Priorizando la comparticin del ancho de banda........................78
7. Implementacin..................................................................................................81
7.1. Introduccin................................................................................................81
7.2. Arquitectura general ..................................................................................83
7.3. Funcionamiento y detalle de componentes de la Arquitectura...................84
7.4. Aspectos Importantes del Diseo...............................................................86
7.5. Implementacin de la Arquitectura............................................................88
7.5.1. Daemon (sheiper-server).....................................................................88
7.5.2. Interfaz de Administracin Web.........................................................92
7.6. Funcionalidades..........................................................................................96
7.6.1. Login/Logout......................................................................................97
7.6.2. Gestin de Trfico..............................................................................98
7.6.3. Clientes.............................................................................................101
7.6.4. Redes.................................................................................................102
7.6.5. Servicios...........................................................................................104
7.6.6. Eventos.............................................................................................107
7.6.7. Backup..............................................................................................109
7.6.8. Parmetros........................................................................................111
7.6.9. Usuarios............................................................................................114
7.6.10. Controlador.....................................................................................116
7.7. Casos de Aplicacin.................................................................................118
7.7.1. ITC S.A.............................................................................................118
4/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.7.2. Universidad de Mendoza..................................................................119
8. Conclusiones....................................................................................................121
5/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
1. Resumen
En la actualidad la gran mayora de las organizaciones posee algn tipo de
enlace a Internet. Ese enlace es provisto por un ISP (Internet Service Provider -
Proveedor de Servicios de Internet) que presta el servicio en base a un abono por
algn nivel de servicio pautado con el cliente (generalmente asociado a una
cantidad de ancho de banda).
En la organizacin seguramente el enlace en poco tiempo se encuentre
saturado y muchos usuarios estn descontentos, an cuando la capacidad del
enlace sea la adecuada, debido a que algunos usuarios monopolizan el uso del
enlace.
Probablemente el ISP llegue al cliente con alguna tecnologa de ltima
milla que supera en capacidad al ancho de banda contratado por el cliente. Si el
cliente tiene acceso a Internet a la velocidad de la ltima milla terminar
recibiendo mucho ms de lo que ha contratado, seguramente a expensas de que
otro cliente perciba una degradacin en el servicio contratado.
Ambos problemas son similares solo que se encuentran en puntos
distintos de la cadena de conectividad. Tanto la organizacin como el ISP
requieren de una herramienta que permita realizar una asignacin adecuada del
ancho de banda seguramente por debajo de la velocidad de la tecnologa fsica de
red. Esta herramienta puede ser un hardware especfico, de ser as se requerir de
un dispositivo por cada cliente a controlar. O como alternativa se puede utilizar
algn software que realice la asignacin adecuada.
Este trabajo trata especficamente sobre el problema antes planteado y
presenta un software que ha sido desarrollado y corre sobre herramientas de
software libre. El software implementa un Controlador de Ancho de Banda que
a travs del uso de algoritmos ampliamente difundidos realiza una distribucin
justa del ancho de banda disponible y permite asignar a clientes conectados a l
servicios especficos (de downstream y upstream) con un ancho de banda mnimo
garantizado y un mximo configurable.
Durante el trayecto del trabajo se desarrollar en detalle la problemtica,
los modelos, estndares y las soluciones de lo que en la actualidad se conoce
6/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
como QoS (Quality Of Service) sobre redes IP de mejor esfuerzo.
En particular se detallarn las herramientas que posee el sistema operativo
GNU/Linux para implementar QoS y al final se presentar el desarrollo completo
del controlador de ancho de banda.
El software aqu presentado es un producto existente de la empresa en la
que trabajo denominado Sheiper, esta tesis se ha elaborado en base al mismo, el
cual fue desarrollado en forma conjunta con el Ing. Juan Jos Ciarlante.
Originalmente se desarroll como una solucin a los requerimientos
planteados por un ISP de la provincia de Mendoza, ITC SA, que brinda servicios
de acceso a Internet y se puso en funcionamiento a finales del ao 2003 cuando la
empresa posea un enlace a Internet de 5 Mbit. En la actualidad la empresa sigue
utilizando Sheiper como su software de control de ancho de banda y posee tres
controladores montados cada uno sobre un enlace a Internet de 22 Mbits c/u.
A parte de la empresa ITC, el controlador se encuentra en funcionamiento
en otro ISP de la provincia de San Juan desde finales de 2004 y en la Universidad
de Mendoza desde comienzos de 2004, entre otros.
A partir de la presentacin de este trabajo el software ser contribuido a la
comunidad de software libre y liberado bajo licencia GNU/GPL disponible en
http://sheiper.silice.biz.
7/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
2. Introduccin
El concepto subyacente en este trabajo son la problemtica, las
motivaciones y las necesidades actuales que llevan a tener que implementar un
control de ancho de banda ya sea en organismos o en empresas proveedoras de
servicios de comunicaciones.
Como marco referencial del presente trabajo se desarrollar la
problemtica de la Red IP en perspectiva a la provisin de QoS, conjuntamente
con los mecanismos y soluciones para este tipo de nivel de servicio sobre
tecnologa de redes IP.
Utilizando los conceptos y estndares actuales se desarrollar un
controlador de ancho de banda (de borde) que permita definir "curvas" de trfico
(en funcin del tiempo) a las que deberan ajustarse los flujos de datos.
Entre los objetivos del presente trabajo se encuentran los siguientes:
Desarrollar la problemtica y los mecanismos existentes para poder
modelar un servicio con QoS sobre una red de Mejor Esfuerzo
como son las redes IP.
Presentar el estado del arte de los algoritmos y mecanismos
actuales disponibles para el control de ancho de banda sobre
enlaces de datos en Linux.
Integrar y desarrollar software de administracin para implementar
un controlador de ancho de banda utilizando Sistema Operativo
Linux y herramientas de Software Libre.
8/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
3. La Internet Hoy
El siguiente captulo ha sido realizado tomando textos de [QOSIPNW]
Antes de embarcarnos en una investigacin de QoS (Quality of Service-Calidad
de Servicio) de la Internet, es necesario realizar un repaso sobre el estado del
networking sobre IP (Internet Protocol) y las aplicaciones que estn guiando su
evolucin.
Uno de los axiomas fundamentales del networking de IP es que la red tiene que
ser los ms simple que sea posible proveyendo el conjunto mnimo de funciones
que permita que los bordes inteligentes puedan comunicarse. Esta filosofa es
un poco contraria a la de los proveedores de telecomunicaciones tradicionales,
donde sus redes son inteligentes de manera tal que los dispositivos utilizados por
los usuarios finales, sean extremadamente simples (por ejemplo el telfono).
La proliferacin de la plataforma PC, utilizada como dispositivo final inteligente,
ha sido una de las razones ms importante del xito de Internet en la dcada de los
90 (en contraste con todo el esfuerzo de la industria tradicional de
telecomunicaciones para desarrollar e introducir sus propios servicios de red
digitales). La funcin mnima de la simple red IP era la conectividad esto es, la
entrega de paquetes de datos desde una fuente a un destino en un perodo de
tiempo razonable si es que exista un camino entre ambos puntos. La definicin
de perodo de tiempo razonable poda variar entre milisegundos o segundos, y en
ltima instancia no haba garanta que todos los paquetes enviados puedan llegar
al destino. De esta manera, todos asuman que los dispositivos de borde
inteligentes y las aplicaciones que ellos soportaban, de alguna manera se las
arreglaran.
Este principio era, y es, la definicin de una red que hace el mejor esfuerzo (Best
Effort network). Hasta la red ms simple requiere de cierto grado de inteligencia
interna para poder encontrar los caminos adecuados entre una fuente y un destino
en este caso los protocolos de ruteo de IP. Si bien es cierto que podemos pensar
que los protocolos de ruteo IP pueden adaptarse dinmicamente frente a desastres
naturales, guerras o cambios de configuraciones, hoy existe una fuerte demanda
9/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
para que las redes IP extiendan sus funcionalidades mnimas para incluir ms que
simple conectividad. Las aplicaciones que utilizan flujos de tiempo real o
interactividad estn imponendole a la red necesidades de tiempos de respuestas
rpidos y predecibles. Los clientes que utilizan redes IP estn demandando
garantas de ancho de banda. Las nuevas aplicaciones necesitan una red que
provea lineas de tiempo y previsibilidad como caractersticas principales.
3.1. Simplicidad de Estado
Dado que la definicin de servicios es tan simple, una red IP elimina mucha de la
complejidad interna asociada con las telecomunicaciones tradicionales. En redes
tradicionales, la sealizacin establece informacin de estado a lo largo de todo el
camino extremo a extremo para asegurar que los componentes internos de la red
puedan reconocer y manejar de manera apropiada el trfico de datos que ser
realizado. Con una red IP de mejor esfuerzo, no se requiere sealizacin de
extremo a extremolos puntos finales simplemente se conectan a la red y
comienzan a enviar paquetes. La filosofa de IP es desacoplar el borde inteligente
de la red simple. Esta prctica significa minimizar la interaccin entre cualquier
punto final (endpoint) y el estado interno de la red. La sealizacin de usuario
final(end user) y ponerle atencin a las fluctuaciones del estado de la red,
tradicionalmente han sido considerado como cosas malas en el mundo.IP
En un nivel filosfico, este comportamiento debilita el desacoplamiento borde/red.
En un nivel prctico, mantener informacin de estados consume memoria en cada
ruteador (router), y cambiar la informacin de estado regularmente consume CPU
en cada router. Los cambios regulares en la informacin de estado estn
generalmente asociados con comunicacin de sealizacin extra entre los routers,
consumiendo ancho de banda que de otra manera estara disponible para cursar
paquetes de usuarios.
3.2. Equidad
La red simple tradicionalmente no ha incluido ningn mecanismo para asegurar
que los recursos son compartidos de manera equitativa entre los puntos finales.
10/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
En efecto, la aplicacin del principio extremo a extremo ha concluido en que TCP
es la fuente principal de equidad dentro de la Internet actual. El algoritmo de
control de flujo con ventanas de TCP se ajusta dinmicamente para asegurar que
est utilizando tanto ancho de banda como le es posible antes de comenzar a
perder paquetes. Cada conexin TCP interpreta la prdida de paquetes como si
hubiera congestin en algn lugar dentro de la red, y en respuesta baja la
velocidad con la que transmite. An pensando que todos los puntos finales son
independientes, existe una expectativa que si todos corren algoritmos de TCP de
control de flujo similares, cada uno conseguir una buena transmisin y la
capacidad de la red ser compartida de manera equitativa. No obstante, este
enfoque tiene un taln de Aquiles importante deja la equidad de la red en
manos de los extremos finales. Esto podra ser aceptable cuando una sola
organizacin controla la red y el software que corren en cada punto final. Pero en
el mundo real, cualquiera puede modificar el software corriendo en los puntos
finales para crear un TCP ms agresivo, o para apagar el control de flujo
completamente. La Internet ha visto ya ejemplos de sistemas operativos
populares con parches para este mismo fin. El efecto es que la persona que lo
utiliza ve una performance excelente a expensa de los TCP's de otros que se estn
reservando de poder transmitir. Rpidamente, ms personas desarrollan TCP's
agresivos, o escriben sus aplicaciones para utilizar UDP en primer lugar (UDP no
tiene control de flujo). Desde una buena perspectiva de negocios, no se puede
dejar el control del uso de los recursos de la red en los puntos finales. Esta es una
de las razones fundamentales por la cual los proveedores de servicios estn
buscando mecanismos basados en la red para controlar los flujos de trficos
extremo a extremo, independientemente de lo que cada extremo final quiera
utilizar.
3.3. Aplicaciones de prxima generacin
Claramente las tcnicas existentes no necesitaran cambiar si estuvieran cubriendo
las demandas actuales. Los crecimientos en la capacitad de transportar paquetes
en bruto pueden satisfacer los grandes volmenes de trfico de email o Web. Pero
existen nuevas aplicaciones que han capturado la imaginacin del pblico. Han
11/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
aparecido servicios de tiempo real de video o audio y la gente quiere acceso a este
tipo de aplicaciones pero de manera ms estable. Servicios interactivos de
telefona IP necesitan delays bajos y predecibles. Y los proveedores comerciales
de servicios estn buscando la manera de compartir su infraestructura de routers
IP a travs de mltiples clientes, garantizando que el trfico de ningn cliente
afecte el servicio de los otros. Todos estos factores estn conduciendo la demanda
por una nueva red IP con un ncleo ms inteligente que antes.
12/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
4. Componentes de QoS
El siguiente captulo ha sido realizado tomando textos de [QOSIPNW]
Sin importar el tamao o el alcance de una red IP, la calidad de servicio observada
se construye de la concatenacin de QoS borde a borde provista por cada dominio
a travs del cual pasa el trfico. Finalmente, la calidad de servicio extremo a
extremo depende de las caractersticas de QoS de cada salto individual en una ruta
dada.
Mucha de la imprevisibilidad, la prdida de paquetes o el jitter (variacin en la
cantidad de latencia entre paquetes de datos recibidos) de los servicios IP se debe
a la manera en la que los router del modelo mejor esfuerzo manejan las
congestiones transitorias internas. Si un puerto en particular se vuelve el punto
focal para dos o mas flujos de datos (streams) de trfico entrante, un router de
mejor esfuerzo simplemente utiliza un encolado primero que entra primero que
sale (FIFO) sobre el enlace de salida. El encolado introduce latencia (latency) o
demora (delay) y la potencial prdida de paquetes si la cola se desborda. Cuando
el patrn del trfico es del tipo impulsivo o por rfagas (bursts), la latencia
inducida por el encolado vara de manera impredecible de paquete a paquete
manifestndose ella misma como jitter en los flujos de trficos afectados.
Las redes IP (de empresas, acceso y backbone) estn siendo utilizadas para llevar
trfico perteneciente a una creciente cantidad de clientes con requerimientos
diversos, por ejemplo, Telefona IP, VPN's, transferencia de datos masivas, y e-
commerce de misin crtica. Cada cliente realiza requerimientos nicos en
referencia a cierto nivel de servicio o previsibilidad, an en presencia de
congestiones transitorias debidas a otros trficos que atraviesan la red. La
demanda de una proteccin relativa o absoluta de otro trfico en algn segmento
de la red en particular se aplica tanto a redes LAN de alta velocidad, como a una
red basada en enlaces T1 o E1 privados, acceso discado (dialups) o redes de
acceso ISDN, o Redes Troncales (backbones) de alta capacidad tipo OC-48/STM-
16. Esta demanda conlleva a tres requerimientos tcnicos:
QoS por Salto: El elemento controlable mas pequeo dentro de la red
es el nodo (router o switch) unido por dos o ms enlaces. Estos nodos
deben estar basados en una arquitectura que permita aplicar encolado
13/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
(queueing) y scheduling (scheduling) diferenciado en cada salto y ser
capaz de utilizar las caractersticas de QoS de los enlaces inter nodos.
Ruteo e ingeniera de trfico: Cuando existen mltiples caminos dentro
de la red, distribuir el trfico entre todos esos caminos puede reducir la
carga promedio y las rfagas dentro de cada uno de esos caminos.
Esta prctica mejora la calidad de servicio aparente de la red porque
cada router se ve menos obligado a descartar o desestabilizar paquetes.
Se requieren mecanismos para descubrir e imponer a veces el reenvo
por el camino no mas corto.
Sealizacin y aprovisionamiento: De nada sirve tener mecanismos de
QoS o de reenvo por un camino que no es el mas corto si no se pueden
gestionar. Una solucin prctica requiere algn grado de distribucin
automtica de parmetros de QoS o de restricciones de ingeniera de
trfico a todos los nodos en la red. Cuando un cliente cambia sus
requerimientos de QoS es necesario poder distribuirlos.
4.1. Una jerarqua de Redes
Cualquier red que tomemos en cuenta est construida de una jerarqua de
componentes.
Cualquier camino desde un punto a otro esta formado de una concatenacin de
caminos ms cortos (saltos [hops]) al mismo nivel. Un camino a un nivel N se
vuelve un salto en un camino de nivel N+1. Tomemos la capa IP como punto de
referencia: esta hecha de routers actuando como puntos de conmutacin para los
paquetes IP y enlaces que mueven los paquetes IP entre los routers. Cada enlace
es un nico salto en IP, pero el enlace en si mismo puede estar hecho por un
nmero de nodos y saltos a su nivel. El enlace puede ser una nica Ethernet, un
segmento de una Ethernet conmutada, un tnel IP, una conexin virtual de ATM.
En el caso de una Ethernet conmutada, pueden existir uno o ms conmutadores
(switchs) ethernet entre los dos routers. Los tneles IP usan una sola red IP para
actuar como un enlace para otra red IP ( o a veces la misma red cuando cierto tipo
de trfico es necesario esconderlo de algunas secciones de la red). Una conexin
virtual ATM (VC - Virtual Channel: Un trmino genrico usado para describir el
14/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
transporte unidireccional de celdas ATM asociadas por un valor de identificador
comn nico [DACOMCOM]) provee un servicio extremo a extremo entre los
extremos del VC, pero en realidad este VC puede atravesar muchos conmutadores
ATM en su camino. El QoS entre dos puntos depende de los routers y las
caractersticas de QoS del enlace entre esos dos puntos. Claramente el transporte
de paquetes entre router se construye con las caractersticas de QoS de cada
enlace. Si la tecnologa del enlace no provee QoS controlable, los routers pueden
hacer muy poco para compensarlo porque dependen de cada enlace para proveer
una conectividad predecible entre routers.
Sin embargo, en presencia de tecnologas de enlaces con QoS, el comportamiento
de los routers hace o rompe la disponibilidad de QoS a nivel IP. La estratificacin
es recursiva. Por ejemplo, las caractersticas de QoS de un VC ATM depende de
cuan predecible son los enlaces entre los conmutadores ATM tanto como en los
conmutadores mismos. Un VC ATM puede extenderse a lo largo de varios
conmutadores ATM utilizando circuitos SDH o SONET para el transporte de
celdas entre los conmutadores. Los circuitos SDH o SONET estn hechos de
varios saltos a travs de varios anillos y multiplexores. Finalmente, los circuitos
SONET o SDH pueden estar multiplexados sobre una misma fibra ptica con
otros circuitos totalmente independientes usando diferentes longitudes de onda
que utilizan multiplexacin por divisin de longitud de onda (WDM), una
tecnologa de fibra ptica que permite simular mltiples fibras pticas virtuales
sobre el mismo segmento fsico de fibra. La Internet agrega una complejidad
adicional al modelo ya que muchos de los caminos extremo a extremo no se
encuentra dentro de la misma red IP y muy probablemente se extiendan sobre
mltiples redes IP independientemente administradas, cada uno con sus propias
polticas y caractersticas de QoS.
Cuando solo se espera el mejor esfuerzo no es necesario preocuparse por las
redes intermediaras a lo largo del camino, ya que su poltica de routeo permite el
reenvo de trfico. Sin embargo, para soportar QoS extremo a extremo, es
necesario saber ms acerca del comportamiento dinmico de la red. No es
necesario conocer como cada red cubre sus objetivos de QoS. Es suficiente con
15/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
caracterizar a cada red en trminos de la latencia, jitter y probabilidad de prdida
de paquetes que puede ser impuesta al trfico.
Dado que la red de una persona es el enlace de otra, la nocin de QoS extremo a
extremo debe ser generalizada a QoS borde a borde. La QoS alcanzada desde un
extremo a otro de la red se construye con la concatenacin de redes con sus
propias caractersticas de QoS borde a borde, y cada uno de los caminos dentro
de cada red se construye con enlaces que pueden ser redes en si mismas, de nuevo
caracterizadas con sus propias capacidades de QoS borde a borde. La habilidad de
caracterizar el comportamiento de QoS borde a borde de una red depende de la
habilidad de caracterizar y controlar el comportamiento de los enlaces y los nodos
a nivel de red.
4.2. Comportamiento predecible por salto
El objetivo en un ambiente con Qos es proveer un servicio de entrega predecible
para cierto tipo o clases de trfico independientemente de otro trfico que este
fluyendo a travs de la red en cualquier momento. Una forma alternativa de este
objetivo es pensar en una solucin de red IP multiservicio donde el trfico
tradicional de rfagas pueda compartir la misma infraestructura (routers, switches,
y enlaces) con trfico que posee requerimientos ms estrictos de latencia, jitter,
ancho de banda o prdida de paquetes. Sin importar si uno se focaliza en redes de
acceso, para empresas o de backbone (o alguna combinacin de todas), el camino
extremo a extremo que recorren los paquetes de un solo usuario est formado por
una secuencia de routers y enlaces. Entonces, la atencin debe ser puesta sobre el
comportamiento del reenvo de paquetes dinmico de los routers. Un router
tradicional se centra sobre donde debe reenviar los paquetes (realizando la
decisin de reenvo sobre la direccin de destino de cada paquete y la tabla de
ruteo), los routers de redes IP con QoS deben poseer un control de cuando deben
enviar los paquetes. Es necesario ver ms de cerca aquellos elementos que
afectan cuando los paquetes son reenviados.
4.3. Congestin transitoria, latencia, jitter y prdida
Cada router es el punto controlable ms pequeo donde convergen o divergen
decenas, centenas y miles flujos de paquetes no relacionados. En la mayora de
16/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
las redes de datos , el trfico arriba en rfagas que fluctan. En algunas ocasiones,
el arribo de rfagas simultaneas sobre mltiples enlaces, los cuales estn
destinados al mismo enlace de salida (que tiene una capacidad finita), pone al
router en una situacin donde tiene ms paquetes de los que inmediatamente
puede enviar.
Por ejemplo, el trfico convergente de mltiples enlaces Ethernet de 100Mbit/s
puede exceder muy fcilmente la capacidad de un enlace WAN OC-3/STM-1 de
155Mbits. Para poder lidiar con estas situaciones, todos los routers poseen colas
internas (buffers) dentro de las cuales el router almacena los paquetes que se
exceden hasta que puedan ser enviados. Bajo estas circunstancias los paquetes
que intentan atravesar el router experimentan demoras adicionales. Este router se
dice que esta sufriendo una congestin transitoria. La demora experimentada
por un paquete de extremo a extremo es una combinacin de las demoras de
transmisin de cada enlace y las demoras experimentadas en el procesamiento por
cada router. La demora que contribuyen tecnologas de enlaces como SONET o
SDH, lineas punto a punto, o circuitos ATM virtuales, son muy predecibles
dado su diseo. Sin embargo, la demora que contribuye cada router por el
almacenamiento en sus colas por situaciones de congestin, no es predecible.
Flucta con los cambios en los patrones de congestin, generalmente variando de
un momento a otro an para los paquetes que tienen el mismo destino. Esta
componente fluctuante de la demora extremo a extremo generalmente se conoce
como jitter.
Otro tema es la prdida de paquetes. Dado que los routers tienen una capacidad
de almacenamiento finita, si se lo somete a una congestin sostenida esta puede
llevar que se saturen las colas. Cuando llegan paquetes, y la capacidad de
almacenamiento se encuentra agotada, estos deben ser descartados hasta que haya
espacio disponible en las colas. Claramente, tenemos un problema. Un router
tradicional tiene solo una sola cola para cada punto de congestin y no existen
mecanismos para aislar diferentes clases o tipos de trfico de los efectos del
trfico que est atravesando el router.
17/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Las fluctuaciones de los trficos no relacionados que pasan a travs de una cola
compartida en cada punto de congestin interna es probable que tenga una gran
influencia sobre la latencia, jitter y prdida de paquetes de cada flujo.
Algunos tipos de trfico (por ejemplo, conexiones TCP que transportan emails)
toleran mejor las demoras que las prdidas de paquetes, lo cual sugiere que tener
grandes colas es lo ideal. Sin embargo, otros tipos de trficos por ejemplo, en
una comunicacin UDP transportando video o audio streaming es preferible que
los paquetes sean descartados a que sean mantenidos demasiado tiempo en la red,
lo cual sugiere que colas pequeas seran mejores.
Consideremos un escenario donde los paquetes llegan por cada interfaz de
entrada del router a una velocidad mxima de Y1 hasta Yn paquetes por segundos.
El enlace saliente extrae paquetes de la cola a X paquetes por segundo. Si
tomamos la velocidad total de entrada como Y, la suma de (Y1 + Y2 + ...+ Yn).
Cuando Y es menor que X, los paquetes no tienen que esperar en la cola. Sin
embargo, es ms que probable que Y puede dar rfagas por encima de X, en este
caso la cola ve un crecimiento en su tamao. El nmero de paquetes (P) en la cola
despus de un intervalo (T) es expresado como P=T x (Y X). Un paquete que
llega en un tiempo T y encuentra que la cola esta parcialmente llena experiencia
una demora adicional de X x P segundos (porque el paquete debe esperar que la
cola drene a X paquetes por segundos). Si un paquete llega cuando la cola est
llena (P = L , el espacio disponible en la cola), el paquete no tiene donde ir y es
tirado. El jitter viene del hecho que los componentes de Y son de rfagas y no
correlacionados. La descripcin anterior tambin se mantiene si se expresa la
velocidad de entrada y salida en bits por segundo y el espacio disponible en la
cola en bits (o bytes). Si los paquetes tienen un tamao fijo, existe una relacin
simple entre las dos formas de expresin. Sin embargo, en ambientes IP tpicos
los paquetes no son de tamao fijo, agregando mas variaciones a la relacin entre
la velocidad de salida, el nmero de paquetes demorados y la demora
experimentada por esos paquetes. La demora tambin puede ser una funcin de la
tecnologa de la red subyacente por ejemplo, el esquema de BackOff de ethernet
(procedimiento de retroceso exponencial binario mediante el cual el emisor
espera un lapso aleatorio para transmitir cuando hay una colisin, despus de la
primera colisin esperar el doble de tiempo, despus de la segunda 4 veces ese
18/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
tiempo). Sin embargo, el backoff en Ethernet se presenta como una
imprevisibilidad del enlace.
4.4. Clasificacin, Encolado y Scheduling
Entonces que se necesita para mejorar. Las caractersticas de demora, jitter, y
prdida de paquetes de una red IP dada, en ultima instancia se resumen a las
caractersticas de QoS de los enlaces y la dinmica de la utilizacin y
administracin de las colas dentro de cada router. Si la carga de la red supera la
velocidad del servicio, una sola cola en cada punto de congestin no es suficiente.
En lugar de esto, se necesita una cola para cada clase de trfico identificable y as
a esta cola poder aplicarle caractersticas independientes de demora, jitter y
prdida de paquetes. Cada una de estas colas debe tener su propia poltica para
descartar paquetes (por ejemplo diferentes transferencias por encima de las cuales
los paquetes son descartados aleatoria o determinsticamente).
Por supuesto, tener mltiples colas por cada interfaz de salida es intil si no se
posee un mecanismo para asignar los paquetes a la cola correcta. Se requiere un
mtodo de clasificacin por encima del tradicional. Finalmente, las colas deben
compartir la capacidad finita que posee el enlace de salida. Este requerimiento
implica un mecanismo adicional de scheduling (poder fijar un orden y tiempo de
salida a los paquetes) para intercalar paquetes de cada cola, y as, controlar el
acceso al enlace de salida de manera controlable y predecible. Para los contenidos
de este trabajo, los requerimientos antes planteados pueden resumirse en una
declaracin: Las redes con QoS requieren de routers que puedan Clasificar,
Encolar y Temporizar (Classify, Queue, Schedule) cualquier tipo de trfico que
sea necesario. A todos los routers que cumplan estos requerimientos los
llamaremos "basados en arquitecturas CQS" o simplemente "routers CQS".
4.5. Comportamiento predecible borde a borde
Como se dijo antes, un servicio extremo a extremo se construye con la
concatenacin y estratificacin de comportamientos borde a borde y por salto.
Los operadores de Redes, centrados en las capacidades borde a borde de sus
redes, tienen un rango de posibilidades para mezclar y hacer trabajar en conjunto
comportamientos por salto. A travs de los aos han emergido varios esquemas
19/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
de solucin, cada uno reflejando conjuntos diferentes de presunciones y
compromisos en lo que respecta a las capacidades de CQS y de ruteo de los
routers dentro de la red.
La primera y ms importante observacin es que los diseadores de la red se
enfrentan a una disyuntiva entre la cantidad de clases de trfico que pueden ser
transportadas por sus redes y el nmero de clases de trfico que las arquitecturas
de CQS de sus routers pueden manejar.
Algunas soluciones se basan en arquitecturas distribuidas de borde ncleo, donde
el ncleo est compuesto por routers rpidos con limitadas capacidades de CQS y
los bordes son ms lentos pero con avanzadas capacidades de CQS.
Una segunda observacin es que los algoritmos de ruteo existentes (por camino
ms corto) actualmente en la Internet no son los ms ptimos o los necesarios
para diferentes clases de trfico que atraviesan una malla arbitraria de routers y
enlaces. Una sola mtrica puede no ser la apropiada para todo el trfico que
atraviesa una seccin particular de la red. Adicionalmente, el paradigma de
reenvo basado en el destino hace muy dificultoso poder forzar que algn
subconjunto del trfico sea encaminado por un camino alternativo que no sea el
ms corto.
4.6. Modelos Extremo y Ncleo
Ya sea en hardware o en software, el diseo de una buena arquitectura de CQS no
es generalmente algo trivial. En muchas implementaciones de software, la poca
disponibilidad de procesamiento, hace muy difcil el poder introducir
clasificacin, manejo de colas y temporizacin sin afectar la performance global
del dispositivo o caja. Las implementaciones de hardware han empezado a ser de
uso comn y hasta hace poco el diseo de una implementacin de CQS para IP
cerrada en un hardware era demasiado riesgosa comercialmente. El modelo borde
y ncleo permite poner routers de ncleo por hardware (preparados para mayor
velocidad) dejando el procesamiento complejo a los routers basados en software
(ms lentos) en los extremos. Los routers de borde pueden estar preparados para
clasificar y encolar independientemente cientos o miles de colas de trfico,
mientras que para los routers de ncleo se asume que tendrn un manejo limitado
20/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
de colas. Un nmero de colas limitadas en el ncleo conlleva a un nuevo
requerimiento para los routers de borde y es que estos deben ser capaces de
suavizar las rfagas del trfico que est entrando a la red. En las discusiones
anteriores con respecto al control de QoS por salto, las clases de trfico
individuales tenan permitido ser completamente impredecibles, asumiendo que
sera posible aislarlas adecuadamente y temporizarlas en cada punto de
congestin. En el modelo borde inteligente/ncleo bobo es requisito que el
aislamiento sea hecho en los bordes, no se hace en el ncleo. Mltiples clases de
trfico pueden encontrarse sumadas dentro de la misma cola compartida dentro de
un router de ncleo. El potencial de interferencia mutua es alto a menos que la
red imponga algn nivel de previsibilidad antes que el trfico llegue a los routers
de ncleo. La solucin es que los routers de los bordes se encarguen de manipular
las caractersticas temporales de cada clase de trfico antes que entren al ncleo.
El modelo de Servicios Diferenciados (Differentiated Services- DiffServ) de la
IETF (Internet Engineering Task Force Grupo de Trabajo en Ingeniera de
Internet) es un ejemplo.
4.7. Modelado y Vigilancia
El objetivo primario de una arquitectura CQS es el de proteger el trfico en cada
cola de las rfagas del trfico en otras. En un esquema por salto, est claro que,
para dar el apropiado aislamiento todo el trfico sensible a QoS, un scheduler
necesita garantizar solamente un cierto intervalo para el peor caso ( o un ancho de
banda mnimo) .
Si hay capacidad ociosa disponible, es de esperar que el comportamiento de un
buen scheduler sea el de dar esa capacidad a las colas que tienen paquetes
esperando por ser enviados. Sin embargo, desde una perspectiva completa de la
red est prctica no es siempre deseable. Simplemente vaciando una cola lo ms
rpido que la velocidad de la lnea de salida permite (en ausencia de trfico de
otras colas) puede incrementar las rfagas percibidas por los routers que se
encuentran ms abajo en el camino. Como resultado, se puede presentar un
problema serio si los routers que se encuentran ms abajo en el camino no poseen
la misma granularidad que el router local. Adicionalmente, los proveedores de
21/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
servicio pueden querer limitar la tasa de transferencia mxima a la que un cliente
puede enviar paquetes a travs de la red. Si un cliente frecuentemente tiene ms
ancho de banda que su mnimo garantizado (quizs porque la red es nueva o esta
subutilizada) surge una cuestin de percepcin: El cliente comienza a asociar la
performance tpica con lo que esta pagando. Si la capacidad de repuesto siempre
se achica, el cliente recibir una performance de borde a borde cercana al mnimo
garantizado. Sin embargo, el cliente simplemente percibe que el servicio se ha
degradado y se queja. Administrar las expectativas de los clientes es una parte
importante del negocio, y en este caso pueden usarse herramientas tecnolgicas
para poner un tope de manera preferencial. Introduciendo un lmite superior al
ancho de banda mximo (o un intervalo mnimo entre paquetes) disponible para
una clase de trfico se denomina modelado de trfico (traffic shaping). Un
scheduler con modelado (shapping scheduler) se configura para proveer un
intervalo mnimo de servicio (el tiempo entre que se quitan paquetes de la misma
cola) y un intervalo mximo de servicio (para garantizar un lmite de demora o
ancho de banda mnimo). Los paquetes que llegan en un intervalo entre paquetes
mas corto que el permitido por el scheduler son encolados hasta su transmisin,
suavizando la rfaga original.
Una manera simple de un modelador scheduler (shaping scheduler) se lo conoce
generalmente como balde agujereado [leaky bucket], porque no importa que tan
rpido lleguen los paquetes solo pueden escapar del balde a una tasa fija).
El modelado no es una funcin simple de introducir dentro de un router de mejor
esfuerzo porque esta funcin parte de la base que existe una arquitectura de CQS
apropiada. Aunque no muy elegante, una solucin alternativa es la de introducir
un comportamiento de descarte de paquetes que sea sensible a las rfagas de
trfico excedente de una clase. Cuando muchos paquetes lleguen en un intervalo
muy corto, los paquetes simplemente son descartados. Este proceso se conoce
como vigilancia [policing]. La vigilancia puede ser implementada sin colas ni
scheduleres, aunque tpicamente necesita alguna forma de clasificacin para
diferenciar las diferentes reglas de vigilancia impuestas a cada clase de trfico. En
su forma ms simple, cada clase de trfico posee un contador asociado. El
contador es incrementado regularmente cada T segundos y decrementado cuando
22/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
un paquete (que pertenece a la clase) es reenviado. Si llega un paquete para ser
transmitido cuando el contador est en cero, el paquete es descartado en ese lugar.
Cuando no se estn transmitiendo paquetes, el contador incrementa hasta un lmite
fijo L. El efecto neto es que cuando llegue un flujo de paquetes con un intervalo
promedio entre paquetes de T segundos (o mayor) pasen sin ser tocados. Sin
embargo, si llega una rfaga de ms de L paquetes en menos de T segundos, el
contador llega a cero y los paquetes adicionales son descartados. El valor de L
afecta la tolerancia a las rfagas de la funcin de vigilancia, y T configura la tasa
por la cual por debajo el trfico esta asegurado. Esta prctica es una forma severa,
aunque efectiva, de modificar las rfagas de trfico desde el router con vigilancia
hacia adelante.
La utilidad de la vigilancia se basa en asumir que la mayora del trfico de rfaga
se origina en aplicaciones que estn utilizando protocolos adaptativos extremo a
extremo, como TCP.
La prdida de paquetes se asume como un indicador de congestin transitoria, y
TCP reacciona bajando la tasa a la que inyecta paquetes dentro de la red.
La vigilancia permite que los operadores de red falsifiquen congestiones
transitorias para una clase de trfico particular antes que esta realmente ocurra.
An si la clase de trfico no est utilizando un protocolo de transporte adaptativo
extremo a extremo, la vigilancia protege al resto de la red ya que continua
descartando los paquetes que exceden los parmetros permitidos. El modelado y
la vigilancia son dos herramientas extremadamente tiles para los diseadores de
red que se enfrentan con tener que balancear el numero de clases de trfico que
mueven sus redes y el nmero de clases de trfico que sus arquitecturas de CQS
pueden manejar.
Bsicamente el asunto es que se puede permitir que las clases de trfico sean
impredecibles solo si se pueden aislar adecuadamente en cada potencial punto de
congestin. Si no es posible este aislamiento, se debe imponer cierto nivel de
previsibilidad antes del potencial punto de congestin. En el modelo borde
inteligente/ncleo bobo, la solucin es que cada router de borde de manera
preventiva modele y/o vigile las clases de trfico individuales antes que estas
entren en el ncleo, con el objetivo de imponer un orden general, suavidad, y
23/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
previsibilidad dentro de cada clase de trfico (y, por lo tanto, la suma de todas
esas clases de trfico). El modelado tambin puede ser muy til en la salida de
una red en aquellas situaciones donde la vigilancia de la prxima red puede ser
ms nociva.
4.8. Marcado y Reordenamiento
Si bien el modelado puede ser una solucin sofisticada para suavizar el trfico de
rfagas, la vigilancia simple es un instrumento severo. Se han introducido
algunas variaciones para suavizar el efecto de la vigilancia en los routers de
borde. Un nodo que este haciendo vigilancia puede elegir solamente marcar los
paquetes (en vez de descartarlos inmediatamente) si exceden un lmite de rfaga.
Los routers que se encuentran mas adelante en el camino del paquete tratan a estos
con menor prioridad que los que se encuentran sin marcas. Si ocurre una
congestin transitoria que comienza a llenar las colas de alguno de los routers que
se encuentran en el camino, estos routers pueden comenzar a descartar los
paquetes marcados antes de comenzar a tirar los paquetes que no tienen marcas.
Se pueden aplicar refinamientos a este comportamiento de manera que el nodo
original que esta haciendo vigilancia puede implementar un conjunto de lmites
de rfagas, si un paquete excede el lmite inferior de rfagas, los paquetes
subsiguientes comienzan a ser marcados y se los transmite, si la rfaga continua y
excede el lmite superior los paquetes son descartados. Alternativamente, el nodo
que esta haciendo vigilancia puede implementar mltiples niveles de tasas de
arribo promedio, una tasa baja para la cual los paquetes son reenviados sin
marcar, una tasa intermedia para la cual los paquetes son marcados y reenviados y
una tasa alta para la cual los paquetes por encima de esta tasa directamente son
descartados.
El impacto en la red de ncleo es mas suave que el que hubiera tenido un
mecanismo de vigilancia simple, porque muchos de los paquetes que estaban en
una rfaga sern marcados en vez de descartarlos. La ventaja de este esquema es
que, frente a la ausencia de congestin en otro punto de la red, este trfico en
particular puede utilizar ms el ancho de banda disponible. Pueden inventarse
muchos algoritmos para proveer mltiples niveles de marcado y para clculos de
24/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
tasas de transferencia. Sin embargo, los diseadores de red que planeen utilizar
marcado de trfico en los bordes deben seleccionar correctamente los routers de
ncleo. El punto central de preocupacin es el reordenamiento de los paquetes
marcados relativo a los paquetes no marcados dentro de una misma clase de
trfico. Esta situacin puede ocurrir si el router de ncleo utiliza dos colas
separadas para diferenciar entre los paquetes marcados y los paquetes no
marcados de una misma clase de trfico.
Dado que los paquetes marcados son de baja prioridad, una implementacin
puede elegir reflejar esta prioridad relativa asignando ms ancho de banda del
scheduler a la cola que almacena los paquetes no marcados . Como consecuencia
un paquete marcado que llegue antes que un paquete no marcado (pertenecientes a
la misma clase de trfico) puede que sea programado para ser enviado despus
que un paquete no marcado (o viceversa). Asumiendo que el paquete marcado
puede completar su camino hasta el destino, la aplicacin en el destino percibe
que el trfico contiene paquetes fuera de orden. Dado que la especificacin de IP
no preve que los paquetes sean reordenados por la red, esta prctica debera
evitarse porque la mayora de los protocolos extremo a extremo no manejan esta
situacin de manera eficiente. En redes donde el marcado tiene como objetivo
incrementar la probabilidad de descarte de los paquetes, la solucin no es muy
difcil. Inicialmente se deja que los routers de ncleo ignoren las marcas de la
vigilancia cuando los paquetes son clasificados en las colas, asegurando que todos
los paquetes en una clase de trfico sean colocados en una cola
independientemente de su prioridad de descarte. Luego se modifica el nivel de
descarte de paquetes para esa cola en funcin de si el paquete esta marcado o no.
El algoritmo de descarte de paquetes del router de ncleo, as, se activa de manera
ms agresiva para los paquetes marcados y de esta manera se logra el
comportamiento deseado de borde a borde.
4.9. Ruteo Borde a Borde
No hay ninguna restriccin en como se conectan los enlaces y los routers para
formar una red IP. Los mecanismos de Internet de ruteo por camino mas corto se
basan en asumir que la topologa de la red rara vez se mantiene esttica y debe ser
monitorizada dinmicamente. En cualquier red realista, cada router puede tener
25/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
ms de una interfaz de salida por la cual puede enviar un paquete, el rol de los
protocolos de ruteo es establecer una sola interfaz por la cual se debera enviar el
paquete. Para poder hacer que los clculos sean realizables, la eleccin de la
interfaz apropiada se realiza con algoritmos controlados por una sola mtrica para
determinar el camino ms corto. Sin embargo, han surgido dos inconvenientes
importantes cuando se trata de utilizar estos mismos mecanismos para soportar
QoS.
Primero est el argumento de que una sola mtrica puede no ser apropiada para
todo el trfico que atraviesa una seccin particular de la red.
Segundo, el paradigma de reenvo basado en el destino hace difcil forzar que un
subconjunto del trfico sea encaminado por un camino distinto al ms corto.
4.9.1. El ruteo basado en QoS
Los protocolos de ruteo basado en QoS intentan tomar mltiples mtricas para
construir las tablas de reenvo. Estos protocolos han sido estudiados por aos y
generalmente se han desarrollado tomando como condicin inicial que la red est
construida en base a routers IP de mejor esfuerzo. Comenzando con esta
condicin inicial, el ruteo basado en una sola mtrica presenta una serie de
limitaciones cuando se lo trata de utilizar para cubrir las demandas de QoS en un
ambiente multiservicio.
Se puede considerar una mtrica como un tipo de costo donde cada enlace (hop)
tiene un costo asociado. El protocolo de ruteo intenta buscar caminos que tengan
el menor costo hacia todos los destinos posibles. Sin embargo, estos costos no
pueden representar los intereses y necesidades de todos los tipos de trfico.
Podra representar la latencia de un enlace, su ancho de banda disponible, su
probabilidad de prdida de paquetes, o quizs el gasto de enviar paquetes sobre
ese enlace ? Seleccione uno. Terminar encontrando que para algn trfico la
seleccin es apropiada mientras que para otros es un desperdicio de recursos.
Por ejemplo, considere una red donde la latencia es la mtrica. Seguramente el
camino ms corto ahora satisface las necesidades de las aplicaciones que tienen
requerimientos de tiempo real muy ajustados. Pero esas aplicaciones no estn
solas. La red generalmente est siendo utilizada por aplicaciones
26/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
tradicionalmente de rfagas que no se preocupan por la latencia. El trfico de
estas (otras) aplicaciones tambin sigue el camino ms corto por la latencia
mnima, sumndose a la carga que tienen los routers de mejor esfuerzo a lo largo
del camino. Un efecto colateral desafortunado es que el trfico de rfagas
consume el mismo espacio de colas que esta destinado al trfico de tiempo real,
incrementando el jitter y la latencia promedio experimentada por el trfico que
atraviesa los routers. Este enfoque tambin afecta la precisin de los costos de
latencia que los protocolos de ruteo usan para determinar el camino ms corto.
El ruteo basado en QoS crea rboles de mltiples caminos mas cortos, cubriendo
la topologa actual de routers y enlaces con cada rbol utilizando diferentes
combinaciones de parmetros como mtricas de enlaces. El objetivo es minimizar
la coexistencia innecesaria de trficos con diferentes requerimientos de QoS
dentro de los mismos routers. Los paquetes que tienen requerimientos de latencia
son reenviados utilizando el rbol que tiene la latencia como mtrica. Los
paquetes que no tienen requerimientos de tiempo real pueden tener un rbol
diferente (construido con una mtrica para minimizar el costo financiero de ese
camino).
Existen varias consideraciones con la implementacin del ruteo basado en QoS:
Cada router necesita tener mltiples tablas de ruteo (o algo funcionalmente
equivalente) sobre las cuales realizar la bsqueda del prximo destino de cada
paquete, una para cada tipo de rbol de camino mas corto. Se utilizan campos
adicionales en la cabecera del paquete para seleccionar uno de los posibles
prximos saltos asociados con la direccin de destino del paquete. Esta
situacin complica el diseo del motor de bsqueda del prximo salto.
Esto genera un incremento en el uso de procesador (CPU) del router, ya que
debe soportar una instancia de cada protocolo para cada rbol de camino mas
corto. Este requerimiento genera un incremento en el tiempo que le toma
converger a los protocolos de ruteo (de cada router en una red) cuando se
presenta una transicin en la red. El tiempo de convergencia se incrementa si
se requiere que el protocolo de ruteo calcule los rboles en base a mltiples
mtricas simultneamente.
Mtricas tales como la latencia o el ancho de banda disponible son altamente
27/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
dependientes del trfico que fluye en cada instante por la red. Un rbol de
camino ms corto que se construye con valores de latencia configurados de
manera esttica se vuelve completamente obsoleto cuando el trfico comienza a
atravesar la red. La alternativa, de actualizar el costo de cada enlace con
mediciones de tiempo real, representa una pesadilla de teora de control cada
actualizacin del costo puede resultar en recalcular todos los rboles de
camino ms corto asociados, lo cual lleva a una sobrecarga de procesamiento
continua sobre todos los routers.
Resulta interesante ver que el desarrollo de routers con arquitectura de CQS de
alguna manera reduce la necesidad de ruteo basado en QoS.
Por ejemplo, considerando el ejemplo donde la mtrica de costeo era la latencia.
Ahora consideremos que cada router tiene al menos dos colas por interfaz de
salida, una para el trfico que es sensible a la latencia y otra para el resto del
trfico. Todo el trfico es ruteado por caminos de la ms baja latencia.
Asumiendo que los routers clasifican de manera correcta el trfico en las dos
colas, el servicio que tiene el trfico sensible a la latencia es independiente de las
rfagas que tiene todo el resto del trfico. As, cualquier protocolo de ruteo
convencional de una sola mtrica, cuando se utiliza con routers de arquitectura
CQS, pueden soportar mltiples niveles diferentes de servicio.
La condicin principal de esto es que exista suficiente capacidad a lo largo del
nico rbol para proveer un servicio adecuado a todos los participantes.
4.10. Sealizacin
Asumiendo que es posible proveer encolado diferencial y scheduling en cada salto
de la red y que se pudiera controlar de manera apropiada la capa de enlace, resulta
necesario tener los mecanismos para poder establecer y modificar el
comportamiento de la red.
Este tema requiere de la coordinacin de los comportamientos a lo largo de cada
camino.
Este proceso se conoce generalmente como sealizacin el hecho de informarle
a cada salto a lo largo de un camino (o caminos) como reconocer el trfico para el
28/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
cual debe realizarse algn procesamiento especial y que tipo de procesamiento
debe realizarse. La sealizacin puede lograrse de varias maneras y con diversos
grados de flexibilidad, temporizacin e intervencin humana.
En un extremo se encuentra la sealizacin dinmica borde a borde, donde la red
es informada cada vez y todas las veces que una nueva clase de trfico necesita
algn soporte especfico. La red responde bajo demanda estableciendo (o
modificando informacin existente) internamente informacin adicional en cada
salto para poder lograr el comportamiento requerido borde a borde. Ejemplos de
sealizacin a demanda incluyen a la Interfaz Usuario Red y la Interfaz Red Nodo
(UNI y NNI puede consultar captulo 11 de [DACOMCOM]) de ATM y el
protocolo RSVP (Resource Reservation Protocol Protocolo de Reserva de
Recurso [RFC2205]) de la IETF.
Generalmente las nuevas tecnologas de red o no tienen protocolos de sealizacin
dinmica o no han madurado al punto en que surjan implementaciones de
protocolos de sealizacin confiables. Bajos estas circunstancias generalmente las
redes son aprovisionadas (generalmente se conoce as a los procesos necesarios
para configurar la infraestructura de la red para proveer un servicio) para nuevos
servicios utilizando intervencin humana para poner a punto los controladores de
los enlaces y los nodos a lo largo del camino.
El aprovisionamiento es una forma de sealizacin, aunque los tiempos de
respuesta estn muy por encima de los de la sealizacin dinmica.
Dado que el nmero de enlaces y nodos puede ser muy grande, muchos
fabricantes estn desarrollando controladores centralizados o servidores donde se
realiza la configuracin y el aprovisionamiento. Estos controladores luego
distribuyen de manera automtica las reglas apropiadas a los enlaces y nodos de la
red.
Diseos ms avanzados permiten que estos controladores reaccionen de manera
automtica cambiando las condiciones de la red de acuerdo a polticas generales
que pueden ser configuradas por un operador. Si bien estos esquemas
centralizados son un mecanismo dinmico, difieren de la sealizacin borde a
borde en que esta no est controlada por el usuario.
29/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Generalmente, se le llama sealizacin, dentro del contexto de IP, a las acciones
adicionales que se requieren para establecer cierto nivel de QoS borde a borde
sobre y dentro de una red IP de mejor esfuerzo.
Como se aclar antes este proceso puede involucrar comportamientos dinmicos o
aprovisionados (o alguna combinacin). En todos los casos, el proceso de
establecer el nivel deseado de QoS borde a borde requiere un balanceo cuidadoso
de los recursos existentes en cada salto y los caminos que cubren toda la red.
Cuando la sealizacin solicita un objetivo de QoS, hay que considerar muchas
variables.
Para un camino dado, el protocolo de sealizacin debera determinar si los
recursos (por ejemplo, el espacio en las colas o el uso del ancho de banda del
enlace) estn disponibles a los largo del camino. Si el primer camino chequeado
no soporta el nivel deseado de QoS, un protocolo de sealizacin ideal debera
encontrar otro camino e intentar nuevamente. Como un ejemplo, la sealizacin
PNNI de ATM (Private Network Node Interface) prueba diferentes caminos hasta
que encuentra uno que soporta el nivel de QoS extremo a extremo requerido.
Probar caminos alternativos presupone que la red tiene la capacidad de forzar
trfico a lo largo del camino que es encontrado que es capaz de soportar el nivel
de QoS deseado. Sin embargo, en IP convencional sin conexin, el trfico debe
seguir el rbol de camino mas corto establecido por los protocolos de ruteo
(utilizando cualquier mtrica configurada por el operador de la red). Como
consecuencia la IETF desarroll su mecanismo de sealizacin RSVP para que
simplemente siga (o se adapte) cualquier ruta que exista en la red sin intentar
descubrir una ruta alternativa de camino mas corto que podra soportar un nivel
de QoS mejor.
RSVP evita cualquier reingeniera a las redes IP existentes, no reinventa o replica
las acciones de los protocolos de ruteo IP existentes, y puede ser introducido
como un hardware simple o un upgrade de software en los routers existentes.
Sin embargo, si los recursos estn agotados dentro de un camino mas corto en
particular, no existe una forma simple para RSVP de forzar el trfico a lo largo
de un camino mas largo, pero que quizs se encuentre ms alivianado.
Otra tema con la sealizacin es la cantidad de informacin de estado adicional
30/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
que deben acarrear los routers.
Informacin de estado es todo lo que los routers necesitan para caracterizar un
trfico en especial - por ejemplo, informacin de cabecera IP sobre la cual se
realiza la clasificacin del trfico- y procesarlo por ejemplo, colas asociadas,
parmetros para descartar paquetes, y prioridades y pesos para el scheduler. Las
tablas de ruteo y reenvo que ya mantiene cada router representan informacin de
estado topolgico agregando sealizacin para QoS incrementa el nmero de
tablas que consumen espacio de memoria valioso en los routers.
Cualquier solucin realista de QoS para redes IP debe satisfacer demandas que
generalmente son conflictivas, el hecho de ser simple de implementar, no enviar
una cantidad de informacin de estado excesiva, estar optimizada para utilizar los
recursos de la red, adaptarse de manera dinmica a los cambios de ruteo y
trabajar en un mundo donde el ruteo y la sealizacin se encuentran desacoplados.
4.11. Polticas, autenticacin y facturacin
Si le ofrecieran un asiento en un avin en primera clase a precio de un asiento de
clase turista, seguro lo tomara, no ? Como mucho se preguntara donde est la
trampa, pero al final nadie se niega a un mejor servicio por el mismo precio de
uno peor ya sea ms comodidad en un asiento de avin, la velocidad de entrega de
un servicio encomiendas, o el acceso a Internet a travs de un ISP local.
Por supuesto, inmediatamente surge un problema simple, si no le estn cobrando
un precio ms alto por un servicio mucho mejor todos quieren tenerlo tambin.
Cualquier tecnologa de red que permite ofrecer diferenciacin de niveles de
servicio tambin tiene la necesidad de diferenciar los derechos de cada usuario
para utilizar un nivel de servicio en particular. Si todos tienen derecho a utilizar el
mejor nivel de servicio al mismo tiempo, los recursos pueden agotarse, o la red
tiene que estar preparada para poder cubrir dicha demanda. En general los
recursos de la red estn limitados a algunos niveles de servicio, y por eso se debe
habilitar o deshabilitar el acceso a esos niveles de servicio a ciertos usuarios en
funcin de los derechos de uso que tienen. ( Si la red estuviera dimensionada
31/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
para brindar un servicio superior a todos, sin ningn impacto en el costo de la red,
cual sera la justificacin de ofrecer niveles de servicio inferiores ?).
Los derechos de uso se pueden establecer de varias maneras - por ejemplo,
pagando un abono (costo financiero) o asignacin administrativa (ranking de
importancia de usuario).
Un proveedor de servicio con fines comerciales seguramente se incline por utilizar
un esquema de abono usted recibe el nivel de servicio por el cual paga. Una red
empresarial puede manejar la asignacin de servicio en funcin del nivel del
usuario dentro de la compaa (o el departamento al que pertenece).
Todo el tema de establecer y monitorear los derechos de los usuarios a utilizar
cierto nivel de servicio recin comienzan a verse en la Internet. Primero surgen
cuestiones de polticas (identificando las clases de servicio que ciertos usuarios
estn en condiciones de negociar). En segundo lugar se encuentra el problema de
autenticacin (procurando que la entidad que est utilizando la red es el usuario
que dice ser, ya sea en el momento de negociar los derechos de uso o en el
momento de cursar trfico). En tercer lugar se encuentra la facturacin
(descontando el consumo del usuario correcto) si el abono se utiliza para
establecer los derechos de uso.
La facturacin puede ser til dentro de redes empresariales, donde puede utilizarse
para proveer granularidad adicional para control de uso ms all del nivel del
usuario dentro de la organizacin. Los tres temas se encuentran fuertemente
acoplados a la sealizacin de la red porque el sistema de sealizacin de la red
debe establecer el nivel de servicio requerido borde a borde y asociarlo con el
trfico que viene del usuario. Si los usuarios estn utilizando sealizacin
dinmica borde a borde para negociar sus derechos de uso, el protocolo de
sealizacin debe estar fuertemente acoplado con los mecanismos de polticas,
autenticacin y facturacin.
No se debe cobrar a los usuarios servicios que no han requerido, para evitar
problemas legales o de mala publicidad (quizs una de las peores situaciones para
un proveedor que quiere ganarse la confianza del mercado).
Por supuesto, se debe cobrar de manera adecuada a los usuarios por los servicios
32/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
que si utilizan. Si la estructura de abono del operador se basa en la cantidad
utilizada, el consumo debe ser registrado y autenticado.
Si se van a utilizar protocolos de sealizacin borde a borde en ambientes de
abono por uso, estos protocolos necesitan incorporar suficientes campos de
autenticacin de usuario. (Un operador puede intentar deducir la identidad del
usuario en funcin del punto de conexin fsico, pero en un mundo de acceso
dialup este enfoque raramente sirve). En la ausencia de estas capacidades, el
usuario y el proveedor de servicio se ven forzados a utilizar canales manuales o
ms tradicionales para negociar el nivel de servicio (fax, telfono, o servicio
postal).
Alternativamente, el proveedor de servicio puede esperar a que los usuarios no
tiendan a impersonalizarse (cuando un usuario intenta hacerse pasar por otro) unos
a otros al momento de solicitar un nivel de servicio. Los ambientes empresariales
son generalmente ms estructurados y controlados, y en estos ambientes la
autenticacin basada exclusivamente en la posicin topolgica del nodo puede
asumirse como suficiente. Sin embargo, si la red empresarial incluye nodos
mviles o cualquier cosa que lleve a que los usuarios se muevan dentro de la
topologa de la red, puede ser necesario tener en cuenta los mismos aspectos que
en los proveedores comerciales de servicio.
Surgen dos problemas si el proveedor de servicio decide incorporar una
componente de facturacin basada en el uso en el abono por derecho de uso.
Primero, no ha surgido un consenso en la industria en qu constituye una mtrica
realista de uso, si es cantidad de paquetes, rfagas, ancho de banda pico o medio,
o alguna medicin compleja de latencia o jitter. Segundo, despus de decidir cual
es la mtrica que los usuarios entendern, surge el problema de medirla dentro de
la red y asociarla al usuario adecuado. La medicin de patrones de trfico en
tiempo real es un problema mayor porque requiere infraestructura de
procesamiento y necesita realizarse para cada una de las instancias de trfico
definidas para cada usuario.
33/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
4.12. Un router genrico
Un router genrico tiene unos pocos bloques funcionales:
Mltiples Interfaces
Un motor de Reenvo (Forwarding Engine)
Un motor de Administracin (Management Engine)
Las interfaces de entrada aceptan paquetes de otros routers, y (en funcin de la
direccin de destino) el motor de reenvo encamina el paquete por la interfaz de
salida correcta. Cada interfaz utiliza mecanismos propios de la capa de enlace
subyacente para transmitir los paquetes hasta en prximo router (prximo salto).
Cuando un router cree que la congestin localizada se est incrementando, puede
comenzar a descartar o marcar los paquetes como una manera de indicar este
estado al resto de los routers que lo rodean.
El comportamiento del motor de reenvo, paquete a paquete, es controlado por el
motor de administracin.
Como discutimos antes, una tabla conocida como la base de informacin de
34/124
Figura 1: Router Genrico [QOSIPNW]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
reenvo (FIB-Forwarding Information Base) es la que maneja las decisiones de
reenvo del router (a donde enviar los paquetes).
Para cada posible direccin IP de destino, se realiza una bsqueda del prefijo ms
amplio dentro de la FIB. Si esa bsqueda encuentra una coincidencia, la entrada
correspondiente describe por cual interfaz de salida debe enviarse el paquete, si no
hay coincidencia el paquete es descartado. El contenido de la FIB refleja el estado
actual de la topologa IP que rodea al router, segn lo hayan determinado los
protocolos de ruteo de IP-por ejemplo OSPF (Open Shortest Path First) o BGP4
(Border Gateway Protocol version 4).
La figura 1 es un modelo muy abstracto. Los routers primitivos tenan una sola
CPU manejando toda la administracin y las funciones de reenvo. Los routers
han evolucionado hacia arquitecturas ms distribuidas, todas diseadas para
reducir o eliminar los cuellos de botella. En los routers de backbones de alta
performance, el motor de reenvo se encuentra distribuido a lo largo de un
conjunto de interfaces interconectadas por un conmutador (switch) de alta
velocidad o un back plane. An as, estos routers tienen una secuencia de pasos
comunes que los paquetes deben seguir mientras son procesados.
Ahora que el tema QoS se est volviendo importante, el proceso de reenvo esta
siendo rediseado para poner ms atencin en el momento en que los routers
envan los paquetes.
35/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
La figura 2 provee una vista abstracta del procesamiento que ocurre dentro del
motor de reenvo que se vea en la figura 1. En general el paquete pasa a travs de
tres etapas:
Clasificacin y bsqueda en la FIB (para establecer la identidad del
paquete y adonde est yendosu interfaz de salida).
Marcado y Vigilancia [Marking y Policing] (para reaccionar si el paquete
no ha llegado en un intervalo de tiempo apropiado)
Encolado [Queueing] y scheduling (para reenviar el paquete de acuerdo
a las reglas de comparticin del enlace o el modelado de trfico o para
descartarlo de acuerdo a las reglas de control de congestin)
La etapa de clasificacin del paquete establece el contexto completo dentro del
cual el paquete ser manejado en el router. Si bien la mayor parte de este
contexto ser utilizado para establecer caractersticas temporales de manejo
(vigilancia, marcado, encolado, y scheduling), algo del contexto puede ser usado
para modificar la decisin de reenvo. Por ejemplo, un router avanzado puede
mantener mltiples FIB (representando los rboles de caminos mas corto basado
36/124
Figura 2: Arquitectura de un router con CQS [QOSIPNW]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
en diferentes mtricas) y elegir entre ellas utilizando informacin de la cabecera
del paquete (por ejemplo, la direccin de origen del paquete).
Una equivalencia, o por lo menos una relacin muy cercana, existe siempre entre
el contexto del paquete (como se ha establecido a travs de la clasificacin) y su
clase (como es percibido en un enfoque extremo a extremo).
La figura 2 asume (de manera simplificada) que la congestin solo ocurre en las
interfaces de salida. Se requiere arquitectura de CQS en todos los puntos de
congestin, ya sea dentro de la red o dentro de un router.
Algunas arquitecturas de routers pueden tener puntos de congestin internos (por
ejemplo, en la entrada del backplane o de la fbrica de conmutacin ) y deben
proveer encolado y temporizacin diferenciada en todos estos puntos.
Los vendedores de routers diferencian sus productos basados en la relacin costo
versus performance. Los routers de mejor esfuerzo primitivos tenan su mayor
cuello de botella en la etapa de bsqueda dentro de la FIB. Sin embargo, en los
ltimos aos se han desarrollado algoritmos de bsqueda para la FIB
extremadamente rpidos millones de bsquedas por segundo son algo comn en
los diseos de los routers de alta gama- entonces ya no es una preocupacin los
tiempos de bsqueda.
El factor que ha llevado a los fabricantes a repensar sus arquitecturas es el
procesamiento adicional que se necesita para proveer una arquitectura de CQS.
A medida que se introduzcan en el mercado capacidades de QoS, muchos routers
se diferenciarn por como (o si) implementan los componentes funcionales que
aparecen en la figura 2.
Dependiendo del rol que juega el router en el servicio extremo a extremo, algunas
funciones pueden no ser implementadas (como las mltiples FIB o la vigilancia y
el marcado) o implementarlas en una forma limitada (como la clasificacin y el
encolado).
37/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
5. Modelos de Red borde a borde
El siguiente captulo ha sido realizado tomando textos de [QOSIPNW] y [EEQOSND].
Hemos desarrollado los detalles de como cada router puede diferenciar el trfico,
proveer una comparticin predecible del ancho de banda, y utilizar descarte de
paquetes o marcado para mantener la congestin promedio bajo control. Pero esta
informacin no significa demasiado sin un modelo de red completo de como estos
mecanismos deben ser utilizados. En este captulo se exploraran tres modelos de
red Servicios Integrados (Integrated Services, IntServ o IS), Servicios
Diferenciados (Differentiated Services, DiffServ o DS), y Conmutacin por
etiquetas multiprotocolo (Multiprotocol Label Switching, MPLS).
Un nmero de conceptos son comunes a cada enfoque:
Una red es caracterizada teniendo routers de Ncleo y de Borde.
Los routers de borde aceptan trfico de clientes (esto es, paquetes de cualquier
fuente afuera de la red) dentro de la red.
Los routers de ncleo proveen servicio de reenvo de paquete entre los routers
de ncleo y/o los routers de borde.
Los routers de borde caracterizan, vigilan, y/o marcan el trfico de los clientes
que esta siendo admitido por la red.
Los routers de borde pueden rechazar requerimientos de trfico sealizados por
fuentes externas (por ejemplo, redes de clientes); este proceso se denomina
control de admisin.
Los routers de ncleo diferencian el trfico al punto que sea necesario para
hacer frente a la congestin transitoria dentro de la red misma.
Se debe utilizar multiplexado estadstico donde se considere apropiado para
maximizar la utilizacin de los recursos de ncleo. El enfoque difiere en los
detalles en funcin de lo que se espera que hagan los routers de ncleo o borde
y como son coordinadas sus acciones para generar los servicios borde a borde
deseados utilizando ptimamente los recursos internos de la red.
38/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
5.1. Evolucin de QoS y modelos extremo a extremo
Las redes IP de mediados de los 90 eran invariablemente redes de mejor esfuerzo,
y la Internet, como un todo, permanece as hoy. Las redes empresariales privadas
y las redes de proveedores, sin embargo, han sido transformadas de modelos de
mejor esfuerzo a modelos ms complejos de servicios diferenciados, lo cual
significa que la red brinda diferentes niveles de servicio a aplicaciones diferentes.
El primer intento de estandarizar QoS lleg a mediados de los 90, cuando la IETF
public la RFC de Servicios Integrados ([RFC1633]).
Esta RFC se centraba en un protocolo de sealizacin denominado RSVP
(Resource Reservation Protocol). RSVP sealiza requerimientos de ancho de
banda y latencia para cada sesin discreta en cada nodo a lo largo del camino que
los paquetes toman desde el extremo emisor hasta el extremo receptor.
Inicialmente, RSVP requera que cada nodo cuidara sus reservas, lo cual era
realmente impracticable sobre la Internet, en donde coexisten servidores,
conmutadores y routers de distintas pocas, distintas caractersticas y fabricantes.
Con el objeto de mejorar estos inconvenientes, emergieron otro conjunto de
estndares -el modelo DiffServ- como un segundo intento de estandarizacin de
QoS.
39/124
Figura 3: Evolucin de QoS [EEQOSND]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
El modelo DiffServ describe varios comportamientos a ser adoptados por cada
nodo con capacidades de DiffServ. Los nodos podan utilizar cualquier
mecanismo (propietario o no) que estuviera disponible, elegido por el fabricante,
para dar conformidad al estandar. Marcas de paquetes, como IP Precedence (IPP)
y su sucesor, Differentiated Services Code Points (DSCPs), fueron definidos
conjuntamente con comportamientos por salto especficos (Per Hop Behaviors-
PHB) para cada tipo de trfico clave.
Como los modelos IntServ y DiffServ han evolucionado, la popularidad de un
mtodo versos la del otro ha oscilado, y su coexistencia se ha vuelto una batalla
creciente, con seguidores de ambos lado. En la actualidad el debate sobre la
ventaja de cada uno continua sin una resolucin clara y acordada por toda la
industria. Ninguno de los dos mtodos ofrece una solucin completa y los
elementos de ambos deberan combinarse para proveer un mtodo ms general
aplicable a un rango mas amplio de tipos de trfico y aplicaciones.
Como definicin acotada podemos decir:
IntServ utiliza un concepto basado en flujo de la mano de un protocolo de
sealizacin a lo largo del camino del paquete. El protocolo de sealizacin
garantiza que estn disponible los recursos adecuados (en cada salto) para el
flujo antes de admitir el flujo dentro de la red. En implementaciones iniciales,
el modelo IntServ adoleca de problemas de escalabilidad por la cantidad de
40/124
Figura 4: IntServ y DiffServ [EEQOSND]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
flujos que necesitaban administracin en los backbones de la red.
Diffserv utiliza marcas de paquetes para clasificar y tratar cada paquete
independientemente. Aunque esto escala bien (por lo cual las empresas y los
proveedores lo implementan ms frecuentemente), no ofrece garantas
especficas de ancho de banda a los paquetes que pertenecen a un flujo y, por lo
tanto, falla en proveer control de admisin a nuevos flujos.
Sin una clara ventaja de cada modelo, los mecanismos de QoS continan usando
un mix de IntServ y DiffServ para ofrecer los servicios requeridos en las redes.
A finales de los 90, las tcnicas de QoS se volvieron ms sofisticadas y fueron
adaptadas a tecnologas de red avanzadas, como Multiprotocol Label Switching
(MPLS) y Virtual Private Networks (VPNs).
La tendencia mas reciente en QoS es la simplificacin y la automatizacin, con el
objetivo de simplemente y eficientemente proveer QoS inteligente sobre redes
IP. Cuando se lo mira como funcionalidades individuales, las tecnologas de QoS
ofrecen un montn de comandos sumamente complejos que pueden ser
configurados. En manos de un administrador capaz, esto puede ser utilizado para
construir redes sofisticadas. Sin embargo, tambin puede resultar en
configuraciones muy complejas. Muchos administradores no tienen el tiempo o el
deseo de investigar a fondo las tecnologas de QoS a este nivel de expertise y por
otro lado preferiran definir polticas de alto nivel y dejar que la red haga las
cosas correctas para implementarlas.
5.2. Modelos de QoS
Como introducimos anteriormente existen dos modelos para proveer niveles de
servicios diferenciados: IntServ y DiffServ. A continuacin se brinda ms detalle
de cada uno.
5.2.1. IntServ
Pensemos en la red IP de mejor esfuerzo en trminos del servicio de correo
simple. El correo es enviado cuando se puede y si se puede, pero tambin puede
que se pierda (llegando en algn momento indeterminado en el futuro o capaz que
41/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
no llegue nunca). Como comparacin, IntServ es similar al servicio de correo
certificado, como el correo diplomtico o un servicio de courier, con ciertos
parmetros en lo que respecta a prdidas y entrega garantizada.
Ms detalladamente, IntServ es una especificacin de lo siguiente:
Lo que el emisor est enviando (velocidad, unidad mxima de transmisin
(MTU), etc), como se ha descripto en Tspec (Transmission Specification
Especificacin de transmisin)
Lo que el receptor necesita (ancho de banda, MTU, etc), como se ha descripto
en Rspec (Receiver Specification Especificacin de Receptor).
Como es realizada la sealizacin sobre de la red por el receptor y el emisor
(esto es el uso de RSVP).
El esquema de trabajo de IntServ preserva la semntica extremo a extremo de QoS
para IP. Los puntos extremos clave son las aplicaciones emisoras y receptoras
que solicitan un nivel de servicio deseado a la red para un conjunto de flujos,
definidos por sus direcciones de origen, destino, puertos origen, destino y
protocolo de transporte. IntServ describe tres tipos principales de servicio que
puede solicitar una aplicacin:
Guaranteed Services (Servicio garantizado [RFC2212]) Provee lmites
firmes (matemticamente probables) sobre las demoras de encolado de
paquetes extremo a extremo , haciendo lo posible por proveer un servicio que
garantice el ancho de banda y la demora.
Controlled load (Carga Controlada - [RFC2211]) Provee al flujo de
aplicacin una calidad de servicio equivalente al QoS que recibira el mismo
flujo en un elemento de red que se encuentra bajo muy poca carga, pero utiliza
control de capacidad (adminisin) para asegurar que el servicio es recibido an
si el elemento de red est sobrecargado.
Besteffort service (Servicio de Mejor Esfuerzo) - no provee ninguna garanta
de servicio de ningn tipo.
Las ventajas del modelo IntServ:
Simplicidad conceptual, facilitando la integracin con la administracin de
42/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
polticas de la red.
QoS discreta por flujo, hacindolo arquitecturalmente conveniente para control
de admisin de llamadas de voz, lo cual permite avisar a los puntos finales si el
ancho de banda necesario est disponible.
Las desventajas del modelo:
Todos los elementos de la red deben mantener e intercambiar mensajes de
estado y sealizacin por cada flujo, lo cual puede requerir de una cantidad de
ancho de banda significativo en redes grandes.
Se utilizan mensajes de refresco peridicos, lo cual puede requerir proteccin
frente a prdida de paquete para mantener la(s) sesin(es) intactas.
Todos los nodos intermediarios deben implementar RSVP.
5.2.2. DiffServ
Continuando con la analoga con el servicio de correo, DiffServ puede ser
comparado a diferentes capas de servicio de correo, como simple, certificado,
prioritario, y express. Cada servicio ofrece parmetros de entrega particulares, y
la pieza de correo es estampada en cada punto de manejo intermediario para
asegurar que consigue el servicio requerido. Sin embargo, no hay un tipo
especfico de conexin entre el emisor de la pieza de correo y el tratamiento que
recibe el correo.
La premisa de DiffServ es muy simple: Ofrece niveles de servicio de red
diferentes a un paquete, citando posibilitando discriminacin de servicio
escalable en la Internet sin la necesidad de estado por flujo y sealizacin en cada
salto ([RFC2474]). Los paquetes de un servicio particular pertenecen a una
clase particular, y el tratamiento de cada clase se describe en un PHB (Per
Hop Behavior- Comportamiento por salto) el cual debe cumplir el nodo de la red.
Se pueden construir servicios significativos con la combinacin de lo siguiente:
Activando un campo de la cabecera IP al momento de entrar en la red o en los
lmites de la red (IPP o DSCP).
Usando este campo para determinar en los nodos dentro de la red el reenvo de
paquetes.
Condicionando a los paquetes marcados en los lmites de la red de acuerdo con
los requerimientos o reglas de cada clase o servicio.
43/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
La esencia de DiffServ es la especificacin de los PHBs que una aplicacin puede
recibir por parte de la red:
Expedited forwarding (Reenvo expeditivo [RFC3246]) provee un servicio
de prioridad estricta (comparando con el correo podra ser el servicio express).
Assured forwarding (Reenvo asegurado [RFC2597]) provee una garanta
de entrega calificada (comparable al correo certificado) y maneja la sobre
suscripcin a este servicio (especficamente, esquemas de marcado o descarte
para el trfico excedente)
Class selectors (Selectores de Clases [RFC2474]) provee cdigos de puntos
(PHB) que pueden utilizarse para compatibilidad hacia atrs con el modelo de
precedencia de IPV4
Best effort service (Servicio de mejor esfuerzo) provee un servicio tipo
entrega cuando sea posible (comparable al servicio de correo simple).
Diffserv construye servicios desde los PHB clasificando paquetes en clases en el
borde, o lmite, de la red y marcando los paquetes correctamente. Opcionalmente,
los paquetes pueden ser medidos con tcnicas de vigilancia o modelado. El
ncleo de la red implementa los PHBs y utiliza las marcas de los paquetes para
hacer el encolado y las decisiones de descarte de paquetes.
El modelo DiffServ tiene estas ventajas:
Escalabilidad No es necesario mantener informacin de estado o flujos.
Performance El contenido del paquete solo se inspecciona una sola vez para
clasificarlo. En ese momento, el paquete es marcado y todas las decisiones de
QoS posteriores se hacen de acuerdo al valor en un campo fijo de la cabecera,
reduciendo los requerimientos de procesamiento.
Interoperabilidad Todos los fabricantes ya estn ejecutando IP.
Flexibilidad El modelo DiffServ no dictamina que se implemente ninguna
funcionalidad particular en un nodo de red (como una tcnica de encolado). El
nodo puede utilizar cualquier tcnica que optimice su hardware y arquitectura,
mientras sea consistente con el comportamiento esperado definido en los
PHBs.
44/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
El modelo DiffServ tiene estas desventajas:
No hay reservaciones de ancho de banda extremo a extremo, por lo tanto, las
garantas de servicio pueden ser imparciales en los nodos de la red que no
implementen los PHBs correctamente sobre enlaces congestionados o por
nodos que no estn correctamente diseados para el volumen de trfico
esperado de una clase especfica.
La ausencia de control de admisin por flujo o por sesin hace posible que las
aplicaciones se congestionen unas con otras. (Por ejemplo, si solamente hay
ancho de banda para 10 llamadas de voz y se permite una llamada ms (11),
todas las once llamadas sufren un deterioro de la calidad).
5.3. MPLS Conmutacin multiprotocolo por etiqueta
A medida que un paquete de una red no orientada a conexin viaja de un router a
otro, cada router realiza una decisin de reenvo independiente para ese paquete.
Esto es, cada router analiza las cabeceras del paquete, y cada router ejecuta un
algoritmo de capa de ruteo. Cada router independientemente elige el prximo
salto para el paquete, basado en su anlisis de la cabecera del paquete y el
resultado del algoritmo de ruteo.
Las cabeceras de un paquete contienen mucha ms informacin que la necesaria
para elegir simplemente el prximo salto. Seleccionar el prximo salto puede
pensarse como la composicin de dos funciones. La primer funcin particiona el
conjunto de todos los paquetes posibles en un conjunto de Clases de Reenvo
Equivalentes (Forwarding Equivalence Clases (FECs). La segunda mapea cada
FEC al prximo salto. A tal grado la decisin de reenvo se ve afectada, paquetes
diferentes que son mapeados dentro del mismo FEC son indistinguibles. Todos
los paquetes que pertenecen a una FEC particular y los cuales viajan de un nodo
particular seguirn el mismo camino (o si se est utilizando algn tipo de ruteo
multi camino, todos seguirn uno de un conjunto de caminos asociados con la
FEC).
En el reenvo de IP convencional, un router particular tpicamente considerar que
dos paquetes estn en el mismo FEC si hay algn prefijo X en la tabla de ruteo de
45/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
router de manera que X es la coincidencia ms grande para la direccin de
destino de cada paquete. A medida que el paquete atraviesa la red, cada salto en
su turno reexamina el paquete y lo asigna a una FEC.
En MPLS, la asignacin de un paquete en particular a una FEC particular se
realiza solo una vez, cuando el paquete ingresa a la red. La FEC a la que es
asignada el paquete se codifica como un pequeo valor de tamao fijo conocido
como una etiqueta (label). Cuando un paquete es reenviado a su prximo salto,
la etiqueta es enviada junto con l, esto es, los paquetes son etiquetados antes de
ser reenviados.
En los saltos siguientes, no hay ms anlisis de la cabecera de capa de red del
paquete. En vez de ello, la etiqueta es utilizada como un ndice dentro de una
tabla que especifica el prximo salto, y una nueva etiqueta. La etiqueta anterior se
reemplaza con una nueva etiquete, y el paquete es reenviado a su prximo salto.
En el paradigma de reenvo de MPLS, una vez que el paquete es asignado a una
FEC, no hay ningn anlisis ms de la cabecera por parte de los routers siguientes,
todo el reenvo se manejado por las etiquetas. Esto tiene varias ventajas sobre el
reenvo convencional de capa de red.
El reenvo MPLS puede ser realizado por conmutadores que son capaces de
hacer bsqueda y reemplazo de etiqueta, pero no son capaces de realizar un
anlisis de la cabecera de capa de red, o no son capaces de analizar la cabecera
de capa de red a una velocidad adecuada.
Dado que a los paquetes se le asigna un FEC cuando entran en la red, el router
de ingreso puede utilizar, para determinar la asignacin, cualquier informacin
que tiene sobre el paquete, an si la informacin no puede ser recabada de la
cabecera de capa de red. Por ejemplo, los paquetes que llegan en diferentes
puertos pueden ser asignados a diferentes FEC. El reenvo convencional, por
otro lado, solo puede considerar informacin que viaja con el paquete en la
cabecera del paquete.
Un paquete que entra en la red en un router particular puede ser etiquetado
diferente que el mismo paquete entrando en la red por un router diferente, y
como resultado las decisiones de reenvo que dependen del router sobre el que
ingres pueden hacerse de manera fcil. Esto no puede hacerse con reenvo
convencional, dado que la identidad del router de ingreso del paquete no viaja
46/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
con el paquete.
Las consideraciones que determinan como un paquete es asignado a una FEC
se pueden hacer ms y ms complicadas, sin ningn tipo de impacto sobre
todos los routers que simplemente reenvan paquetes etiquetados.
Algunas veces es deseable forzar a los paquetes para que sigan una ruta
particular que ha sido elegida explcitamente antes o en el momento en que el
paquete entra en la red, en vez de que sea elegida por el algoritmo de ruteo
dinmico a medida que el paquete viaja a travs de la red. Esto puede hacerse
como una cuestin de poltica, o para soportar ingeniera de trfico. En el
reenvo convencional, esto requiere que el paquete cargue una codificacin de
su ruta dentro del paquete (source routing). En MPLS se puede utilizar una
etiqueta para representar la ruta, de manera la identidad explcita de la ruta no
necesita ser cargada con el paquete.
Algunos routers analizan la cabecera de red del paquete no solo para elegir el
prximo salto, sino tambin para determinar la precedencia o la clase de
servicio que debe darse. Luego pueden aplicarse diferentes umbrales de descarte
o disciplinas de temporizacin a diferentes paquetes. MPLS permite (pero no
requiere) que la precedencia o la clase de servicio sea total o parcialmente inferida
de la etiqueta. En este caso, se puede decir que la etiqueta representa la
combinacin de una FEC y una precedencia o clase de servicio.
47/124
Figura 5: Ncleo simplificado de un motor de reenvo LSR [QOSIPNW]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
MPLS significa Multiprotocol Label Switching, multiprotocolo porque estas
tcnicas son aplicables a CUALQUIER protocolo de capa de red.
Un router que soporta MPLS se lo conoce como un Label Switching Router o
LSR.
48/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6. Control de Trfico en Linux
El siguiente captulo ha sido realizado tomando textos de [LNTCIO]y [TFCOHT]
6.1. Introduccin
El ncleo (kernel) de Linux ofrece una amplia variedad de funciones de control
de trfico. Las partes del kernel, y varios programas de espacio de usuario para
controlarlos han sido implementadas por Alexey Kuznetsov.
La figura 6 muestra de manera general como el kernel procesa los datos que
recibe de la red, y como genera nuevos datos para ser enviados sobre la red: los
paquetes llegan por una interfaz de entrada, donde pueden ser susceptibles a
vigilancia (policing). La vigilancia descarta paquetes indeseados, por ejemplo, si
el trfico est llegando demasiado rpido. Despus de la vigilancia, los paquetes o
son directamente reenviados a la red (por ejemplo sobre una interfaz diferente, si
la mquina est trabajando como un router o un bridge), o son pasados a capas
superiores en el stack de protocolos (ej: a un protocolo de transporte como UDP o
TCP) para realizar algn procesamiento adicional. Esas capas superiores pueden
generar datos por si solas y entregarlo a capas inferiores para tareas como
encapsulamiento, ruteo, y eventualmente transmisin.
El reenvo incluye la seleccin de una interfaz de salida, la seleccin del
prximo salto, encapsulamiento, etc. Una vez que todo esto ha sido realizado, los
paquetes son encolados en la interfaz de salida respectiva. Este segundo punto es
donde el control de trfico entra en juego. El control de trfico puede, entre otras
cosas, decidir si los paquetes son encolados o si son descartados (por ejemplo: si
la cola ha alcanzado algn lmite de tamao, o si el trfico excede alguna
49/124
Figura 6: Procesamiento de datos de la Red [LNTCIO]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
velocidad lmite), puede decidir en que orden son enviados los paquetes (por
ejemplo para dar prioridad a ciertos flujos), puede demorar el envo de paquetes
(por ejemplo para limitar la velocidad del trfico saliente), etc.
Una vez que el control de trfico ha liberado un paquete para ser enviado, el
driver de dispositivo lo toma y lo emite sobre la red.
El cdigo de control de trfico en el kernel de Linux consiste en los siguientes
componentes principales:
disciplinas de cola (queueing disciplines)
clases (dentro de una disciplina de cola)
filtros (filters)
vigilancia (policing y los conceptos relacionados)
Cada dispositivo de red tiene una disciplina de cola asociada a l, que controla
como son tratados los paquetes encolados en ese dispositivo.
La figura 7 muestra el smbolo que utilizaremos para una disciplina de cola sin
una estructura interna visible. Por ejemplo, sch_fifo es una disciplina de cola as
de simple, que solo consiste en una sola cola, donde todos los paquetes son
almacenados en el orden que han sido encolados, y que es vaciada tan rpido
como el dispositivo puede enviar.
Otras disciplinas ms elaboradas pueden utilizar filtros para distinguir entre
diferentes clases de paquetes y procesar cada clase de una manera especfica, por
ejemplo, dando prioridad a una clase por encima de las otras.
50/124
Figura 7: Disciplina de cola simple sin clases
[LNTCIO]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
La figura 8 muestra un ejemplo de esa disciplina de cola. Puede verse que varios
filtros mapean a la misma clase.
Las disciplinas de cola y las clases estn ntimamente atadas: la presencia de
clases y sus semnticas son propiedades fundamentales de la disciplina de cola.
En contraste con eso, los filtros pueden ser combinados arbitrariamente con
disciplinas de cola y clases sin importar si la disciplina de cola tiene clases o no.
Pero la flexibilidad no termina an- las clases normalmente no almacenan sus
paquetes ellas mismas, utilizan otra disciplina de cola para que se encargue de eso.
Esa disciplina de cola puede ser elegida arbitrariamente de un conjunto de
disciplinas de cola variadas y esas disciplinas pueden tener clases, y esas clases
pueden utilizar disciplinas de colas, etc.

La figura 9 muestra un ejemplo de este apilado: primero, hay una disciplina de
cola con dos prioridades de retardo (delay).
Los paquetes que son seleccionados por el filtro van a la clase de alta prioridad,
mientras todos los dems paquetes van a la clase de baja prioridad. Siempre que
51/124
Figura 8: Disciplina de cola simple con mltiples clases [LNTCIO]
Figura 9: Combinacin de disciplinas de cola Prioridad, TBF y FIFO [LNTCIO]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
haya paquetes en la cola de alta prioridad, sern enviados antes que los paquetes
en la cola de baja prioridad (por ejemplo: la disciplina de cola sch_prio trabaja de
esa manera). Para prevenir que el trfico de alta prioridad no mate de hambre al
trfico de baja prioridad, se usa la disciplina de cola Filtro Token Bucket (Token
Bucket Filter TBF), la cual fuerza una velocidad de hasta 1 Mbps. Finalmente,
el encolado de los paquetes de baja prioridad se realiza con una disciplina de cola
FIFO.
Los paquetes son encolados de la siguiente manera: cuando se llama a la funcin
de encolar de una disciplina de cola, esta ejecuta un filtro despus de otro hasta
que alguno de los dos encuentra una coincidencia. Luego encola el paquete en la
clase correspondiente, lo cual generalmente significa llamar a la funcin encolar
de la disciplina de cola que est dentro de esa clase. Los paquetes que no
coinciden con alguno de los filtros generalmente son asignados a una clase por
defecto.
Tpicamente, cada clase posee (es duea de) una cola, pero en principio
tambin es posible que varias clases compartan la misma cola o que se utilice una
sola cola para todas las clases de una disciplina de cola. Sin embargo es
importante aclarar que los paquetes no cargan una identificacin explcita de a que
clase han sido asignados. Las disciplinas de cola que cambian la informacin por
clase cuando desencolan paquetes (pe: CBQ) por consiguiente puede que no
trabajen correctamente si las colas interiores son compartidas, a menos que
tengan la capacidad de repetir la clasificacin o pasar el resultado la clasificacin
del desencolado al encolado de alguna manera.
Usualmente cuando se encolan los paquetes, el flujo correspondiente puede ser
vigilado, por ejemplo descartando paquetes que exceden cierta velocidad.
6.2. Terminologa
Desafortunadamente, la terminologa utilizada para describir los elementos de
control de trfico est lejos de ser consistente en la literatura, y hay algunas
variaciones an dentro del control de trfico de Linux. La idea es poner las cosas
en su contexto.
La siguiente figura muestra el modelo arquitectnico y la terminologa de IntServ
y Diffserv y como los elementos del control de Trfico de Linux se relacionan a
52/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
ellos. Notes que las clases juegan un rol ambivalente, porque determinan el
resultado final de una clasificacin y tambin pueden ser parte de un mecanismo
que implementa algn comportamiento de encolado o scheduling.
53/124
Figura 10: Relacin de los elementos de la arquitectura de IntServ y DiffServ con el control
de trfico del kernel de Linux [LNTCIO]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.3. Elementos del Control de Trfico
Nota: En este punto y en adelante se utilizarn trminos en ingls para referirse a los elementos
de control de trfico de Linux para evitar ambigedades.
Shaping
Un "shaper" retarda los paquetes para satisfacer una velocidad estipulada. Se
utilizan para limitar el trfico de manera que no supere una velocidad,
generalmente para suavizar el trfico de rfagas. Utilizan mecanismos de token y
bucket (puede ver Captulo 5 de [COMNET]) .
Scheduling
Un "scheduler" ordena o desordena los paquetes antes de ser desencolados.
Scheduling es el mecanismo por el cual los paquetes son ordenados (o
desordenados) entre la entrada y la salida de una cola.
Los mecanismos de scheduling tratan de compensar varias condiciones de red.
Un algoritmo del tipo "Encolado Justo (Fair queuing - SFQ) intenta prevenir que
un solo flujo se apodere del uso de la red. Un algoritmo tipo round robin (WRR)
le da a cada flujo un turno para salida de la cola.
Classifying
Los clasificadores (classifiers) ordenan o separan el trfico entre colas.
Clasificacin es el mecanismo por el cual los paquetes son separados para tener
diferente tratamiento, posiblemente diferente colas de salida.
En Linux el modelo permite que un paquete "fluya" a travs de una serie de
clasificadores dentro de una estructura de control de trfico y que sea clasificado
de acuerdo a las polticas (policing).
Policing
Los "policers" miden y limitan el trfico en una cola en particular.
Policing, como un elemento del control de trfico, es simplemente un mecanismo
por el cual el trfico es limitado. Un policer aceptar trfico a una determinada
velocidad, y luego realizar alguna accin si el trfico excede la velocidad fijada.
Una de las opciones puede ser que el trfico sea descartado o puede ser
54/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
reclasificado.
Un policer es una pregunta tipo si/no acerca de que hacer con el trfico que
ingresa en una cola. Si bien un policer utiliza mecanismos de token bucket no
tiene la capacidad de retardar el trfico como un "shaper".
Dropping
Descartar un paquete, un flujo o una clasificacin.
Marking
Es el mecanismo por el cual un paquete es alterado o marcado.
No confundir con el marcado provisto por fwmark (marca de Firewall en Linux).
Los mecanismos de marcado del control de trfico instalan una marca en el
paquete mismo, la cual es usada y respetada por otros routers dentro de un mismo
dominio administrativo (DiffServ).
Componentes del Control de Trfico en Linux
Elemento Tradicional Componente de Linux
Shaping Una class ofrece capacidades de shaping.
qdisc Una qdisc (queue discipline) es un scheduler.
Classifying El objeto filter realiza la clasificacin utilizando un
objeto classifier. En Linux los classifiers no pueden
existir fuera de los filter.
policing Un policer solo existe como parte de un filter.
dropping Para hacer drop del trfico se requiere un
filter con un policer que utilice "drop" como accin.
marking Se utiliza dsmarkqdisc.

55/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
qdisc
Una qdisc es un scheduler. Cada interfaz de salida necesita un scheduler de algn
tipo, por defecto el scheduler es una cola FIFO. Otras qdisc disponibles en Linux
reordenaran los paquetes que ingresen a la cola del scheduler de acuerdo a las
reglas que imponga el scheduler.
Una qdisc es el bloque fundamental sobre la cual se construye el control de trfico
en Linux, tambin es llamada queuing discipline (disciplina de cola).
Existen dos tipos de qdisc (classfull y classless).
Una qdisc del tipo classfull puede contener clases (ver ms adelante classes),
aunque no es obligatorio y provee un manejador (handler) al cual asignar filtros
(ver filters ms adelante).
Una qdisc del tipo classless no contiene clases, por lo tanto no es posible
asignarle filtros, como este tipo de qdisc no contiene hijos de ningn tipo no hay
dada que clasificar.
Generalmente se confunde el trmino root qdisc e ingress qdisc. Estas no son
realmente disciplinas de colas, sino que son ubicaciones a donde se pueden
asignar estructuras de control de trfico para salida (egress) o entrada (ingress).
Cada interfaz posee las dos, la qdisc de egress ms comn es la root qdisc.
Puede contener cualquier disciplina de cola (qdisc) con sus potenciales classess y
estructura de clases. Todo el trfico transmitido por una interfaz atraviesa la root
qdisc.
El trfico aceptado por una interfaz atraviesa la ingress qdisc. Con su limitada
utilidad, no permite clases hijas y solo existe la posibilidad de asignarle un filter.
A los efectos prcticos la ingress qdisc es un objeto al que se le puede asignar un
policer para limitar la cantidad de trfico aceptado por una interfaz.
class
Las clases (classes) solo existen dentro de las classful qdisc. Las clases son muy
flexibles y puede contener mltiples clases hijas o una sola qdisc hija.
No hay ninguna prohibicin para que una clase contenga una classful qdisc, lo
cual permite modelar escenarios de control de trfico muy complejos.
Cualquier clase puede tener un nmero arbitrario de filters asignados a ella. Lo
56/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
cual permite la seleccin de una clase hija, o el uso de un filtro para reclasificar o
para eliminar el trfico que ingresa en una clase.
Una leaf class es una clase terminal dentro de una qdisc.
Contiene una qdisc (por defecto FIFO) y nunca tendr una clase hija.
filter
Un filtro (filter) es el componente ms complejo del control de trfico en Linux.
Provee un mecanismo para relacionar los distintos elementos claves del control de
trfico. El rol ms simple y obvio de un filter es el de clasificar los paquetes.
Los filters (filtros) de Linux permiten que el usuario clasifique los paquetes en
una cola de salida con varios filtros o con un solo filtro.
* Un filtro debe contener la frase classifier
* Un filtro puede tener la frase policer
Los filtros pueden ser asignados a las classful qdiscs o a las classes.
Los paquetes encolados siempre entran a la root qdisc primero. Una vez que el
filtro de la qdisc a sido superado el paquete puede ser dirigido a cualquier
subclase (que puede tener sus propios filtros) donde el paquete puede seguir para
mayor clasificacin.
classifier
Los objetos filter, que pueden ser manipulados usando el comando tc pueden
utilizar diferentes mecanismos de clasificacin. El ms comn es el clasificador
u32, que permite que el usuario seleccione paquetes en funcin de los atributos de
los paquetes.
Los clasificadores son herramientas que pueden ser utilizados como parte de un
filtro filter para identificar las caractersticas de un paquete o la metadata de un
paquete. El objeto classifier de Linux es directamente comparable a la operacin
bsica y elemental del mecanismo classifying de control de trfico.
57/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
policer
Este mecanismo elemental es utilizado en el control de Trfico de Linux como
parte de un filter. Un policer invoca a una accin cuando esta por encima de la
velocidad especificada , y otra accin cuando se est por debajo.
Si bien policing y shaping son elementos bsicos del control de trfico para
limitar el uso del ancho de banda, un policer nunca deber retardar el trfico.
Solo debe realizar una accin basado en un criterio especificado.
drop
Este mecanismo bsico del control de trfico, en el control de Trfico de Linux es
utilizado como parte de un policer. Cualquier policer asignado a un filter puede
tener como accin drop. La funcin de drop es descartar directamente los
paquetes.
handle
Cada class y cada classful qdisc requiere de un identificador nico dentro de la
estructura de control de trfico. Este identificador nico es conocido como un
handle y tiene dos miembros constitutivos, un major number y un minor
number. Estos nmeros pueden ser asignados de manera arbitraria de acuerdo a
las siguientes reglas:
major El usuario puede utilizar cualquier nmero arbitrario, sin embargo
todos los objetos que tengan el mismo padre dentro de la estructura de
control de trfico deben tener el mismo major number
minor Este nmero identifica a una qdisc si es igual a 0. Cualquier otro
valor significa que se trata de una clase. Todas las clases que tienen el
mismo padre deben tener un minor diferente.
El handle ffff:0 est reservado para la ingress qdisc.
El handle es utilizado como destino (target) en los argumentos classid y flowid
de la sentencia tc filter.
58/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.4. Disciplinas de cola simples, sin clases
6.4.1. pfifo_fast
First In, First Out, FIFO (el primero que entra es el primero que sale), lo que
significa que ningn paquete recibe un tratamiento especial. Al menos, no mucho.
Esta cola tiene 3 de lo que llamamos bandas. Dentro de cada banda, se aplican
las reglas FIFO. Sin embargo, no se procesar la banda 1 mientras haya paquetes
esperando en la banda 0. Lo mismo se aplica para las bandas 1 y 2. Esta
disciplina utiliza el campo TOS (Type Of Service del paquete IP para ms
informacin consultar RFC 791 y RFC1349) y una mscara de asignacin de
prioridades (priomap) para seleccionar las bandas de prioridades.
Usage: ... [p|b]fifo [ limit NUMBER ]
El nico parmetro es NUMBER, si es pfifo NUMBER=paquetes
si es bfifo NUMBER=bytes .
59/124
Figura 11: Disciplina de cola pfifo_fast [TFCOHT]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.4.2. Token Bucket Filter
El Token Bucket Filter (TBF) es una qdisc sencilla que se limita a dejar pasar
paquetes que lleguen a una tasa que no exceda una impuesta administrativamente,
pero con la posibilidad de permitir rfagas cortas que excedan esta tasa.
TBF es muy preciso, amigable para la red y el procesador. Debera ser la primera
eleccin si solo se requiere ralentizar una interfaz.
La implementacin de TBF consiste en una cola (el bucket o balde), que se llena
constantemente con piezas virtuales de informacin denominadas tokens, a una
tasa especfica (token rate). El parmetro ms importante del bucket es su tamao,
que es el nmero de tokens que puede almacenar.
60/124
Figura 12: Disciplina de cola TBF [TFCOHT]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Usage: ... tbf limit BYTES burst BYTES[/BYTES] rate KBPS [ mtu
BYTES[/BYTES] ]
[ peakrate KBPS ] [ latency TIME ]
El parmetro rate permite especificar la velocidad para este scheduler
Se debe especificar el parmetro burst que es el tamao del bucket en
bytes.
El parmetro limit es el nmero de bytes a encolar antes que los
paquetes
sean eliminados.
Ejemplo
tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
6.4.3. Stochastic Fairness Queueing
Stochastic Fairness Queueing (SFQ) es una implementacin sencilla de la familia
de algoritmos de colas justas (fair queueing). Es menos preciso que los otros, pero
mientras distribuye el trfico bastante equitativamente tambin requiere menos
clculos.
La palabra clave en SFQ es conversacin (o flujo), que se corresponde en su
mayora a una sesin TCP o a un flujo UDP. El trfico se divide en un nmero
bastante grande de colas FIFO, una por cada conversacin. Entonces se enva el
trfico de una manera parecida a round robin, dando a cada sesin por turnos la
oportunidad de enviar datos.
Esto lleva a un comportamiento bastante equitativo y evita que una nica
conversacin ahogue a las dems. SFQ se llama estocstica porque realmente
no crea una cola para cada sesin, sino que tiene un algoritmo que divide el
trfico en un nmero limitado de colas usando un algoritmo de hash.
61/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Usage: ... sfq [ perturb SECS ] [ quantum BYTES ]
El parmetro pertub permite especificar cuan seguido sfq cambia
su algoritmo de hashing. El parmetro quantum controla cuantos
bytes son sacados de cada FIFO interna con algoritmo round robin.
Este parmetro (quantum) no puede ser menor al MTU.
Ejemplo
#tc qdisc add dev ppp0 root sfq perturb 10
#tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)
62/124
Figura 13: Disciplina de Cola SFQ [TFCOHT]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.4.4. ESFQ, Extended Stochastic Fair Queuing
Conceptualmente, esta qdisc no es diferente a SFQ sin embargo permite que el
usuario controle ms parmetros que en SFQ simple. Esta qdisc permite que el
usuario controle que algoritmo de hashing (el hashing es un mtodo para
organizar la informacin de cadenas o smbolos en tablas que permite luego que
estos sean buscados de manera rpida) se utilizar para distribuir el acceso al
ancho de banda, de esta manera es ms probable que el usuario pueda configurar
una distribucin de ancho de banda realmente ms justa.
Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
Where:
HASHTYPE := { classic | src | dst }

6.4.5. RED (Random Early Detection)
RED es una qdisc classless que limita su tamao de cola inteligentemente.
Las colas regulares simplemente descartan paquetes del final cuando estn llenas,
lo cual puede no ser el comportamiento ms ptimo. RED tambin realiza un
descarte del final, pero lo hace de una manera ms gradual.
Cuando la cola llega a un largo promedio, los paquetes encolados tienen una
chance configurable de ser marcados (lo cual puede terminar en descarte). Esta
chance aumenta linealmente hasta un punto llamado el mximo promedio del
largo de la cola, sin embargo la cola puede ser ms grande.
Esto tiene un montn de beneficios sobre el simple descarte del final, y consume
poco procesador. Previene las retransmisiones sincronizadas despus de una
rfaga de trfico, lo cual causa ms retransmisiones.
El objetivo es tener una cola de tamao pequeo, lo cual es bueno para la
interactividad y a dems no molesta al trfico TCP con demasiados descartes
despus de una rfaga de trfico.
Dependiendo de si se ha configurado ECN (explicit congestion notification), el
63/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
marcado puede significar descarte o simplemente que el paquete est pasado de
sus lmites.
El tamao promedio de la cola se utiliza para determinar la probabilidad de
marcado. Esto es calculado utilizando un promedio exponencial mvil ponderado
(EWMA), el cual puede ser ms o menos sensible a las rfagas.
Cuando el tamao promedio de la cola esta por debajo de min bytes, ningn
paquete ser marcado. Cuando excede min, la probabilidad de ser marcado crece
linealmente hasta un valor probability, hasta que el tamao promedio de la cola
llegue hasta max bytes. Dado que probability normalmente no se configura al
100% el tamao de la cola puede crecer considerablemente por encima de max , es
por eso que se utiliza el parmetro limit para poner un mximo estricto para el
tamao de la cola.
Usage: ...red limit BYTES min BYTES max BYTES avpkt BYTES burst
PACKETS probability PROBABILITY bandwith KBPS [enc]
A continuacin se explican los parmetros.
Min Tamao promedio de la cola al cual el marcado se vuelve una
posibilidad.
Max A este tamao promedio de la cola, la probabilidad de marcado
es mxima. Debera ser por lo menos dos veces el valor de min
para prevenir retransmisiones sincronizadas.
Probability Mxima probabilidad de marcado, especificada como un
nmero en punto flotante desde 0.0 a 1.0.
Valores sugeridos son 0.01 o 0.02 (1% a 2%, respectivamente)
Limit Lmite estricto sobre el tamao real de la cola (no el promedio)
en bytes. Paquetes por encima de este valor son descartados.
Debera ser mayor que max+burst. Se recomienda configurar
este valor varias veces ms grande que max.
64/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Burst Se utiliza para determinar que tan rpido es influenciado el
tamao promedio de la cola por el tamao real de la cola.
Experimentos de casos reales sugieren la siguiente regla
orientativa: (min+min+max)(3*avpkt)
Avpkt Especificado en bytes. Se utiliza con burst para determinar la
constante de tiempo para los clculos del tamao promedio de la
cola. 1000 es un buen valor.
Bandwidth Este valor se utiliza para calcular el tamao promedio de la cola
despus de un perodo de inactividad. Debera configurarse
igual al valor de ancho de banda de la interfaz. Esto no
significa que RED har shapping.
Ecn Como se mencion antes, RED puede marcar o descartar,
Explicit Congestion Notification permite que RED notifique a
hosts remotos que su trfico excede el ancho de banda
disponible. Los hosts que no soportan ECN solo pueden ser
notificados descartando sus paquetes. Si se especifica este
parmetro, los paquetes cuyos hosts dicen soportar ECN solo
sern marcados y no descartados, a menos que el tamao de la
cola llegue a limit bytes.
6.5. Disciplinas de colas classfull
La flexibilidad y el poder del Control de Trfico de Linux puede realizarse con la
ayuda de disciplinas de cola que soportan clases (classfull qdisc). Las qdisc
classfull pueden tener filtros (filters) conectados, permitiendo que los paquetes
sean dirigidos a clases particulares y subcolas (qdisc dentro de qdisc).
Hay algunos trminos comunes para describir clases que estn conectadas
directamente a la qdisc root y para clases que son terminales. Las clases
conectadas a la root qdisc se conocen como root classes, y ms generalmente
como inner classes. Cualquier clase terminal dentro de una disciplina de cola se
conoce como una leaf class como analoga a la estructura de rbol de las clases.
65/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.5.1. DSMARK
La disciplina de cola DSMARK fue diseada especialmente para cumplir
completamente con las especificaciones de DiffServ. Se encarga del marcado de
paquetes dentro de la implementacin de DiffServ en Linux.
Su comportamiento es realmente muy simple cuando se lo compara con otras
disciplinas de cola del control de Trfico en Linux.
Contrariamente a otras disciplinas de cola, DSMARK no hace shapping, control o
policing de trfico. Tampoco prioriza, retarda, reordena o descarta paquetes.
Solo marca paquetes usando el campo DS.
DSMARK, se ve como una disciplina de cola full class. Y en realidad lo es. Las
clases con numeradas 1,2,3,4,...., n-1, donde n es un parmetro que define el
tamao de una tabla interna necesaria para implementar el comportamiento de la
disciplina de cola. Este parmetro se denomina indices. Siendo q el nmero de
cola, el elemento q:0 es la cola principal misma. Elementos a partir de q:1 a q:n-
1 son las clases de la disciplina de cola (representados en la figura 14 como
66/124
Figura 14: Disciplina de Cola DSMARK [APGTLTC]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
rectngulos amarillos). Cada una de esas clases puede ser seleccionada utilizando
un filtro (el elemento representado por los rectngulos verdes) conectado a la
disciplina de cola; los paquetes que estn siendo seleccionados por el filtro son
puestos en su clase DSMARK respectiva.
Cmo, dnde y cundo la clase DSMARK marca los paquetes? Los paquetes
son marcados en el campo DS (Differentiated Services Field para ms
informacin consultar [RFC2474]).
Son marcados con un valor entero que se define para cada clase cuando se
configura la disciplina de cola. Los paquetes son marcados justo antes de dejar la
disciplina de cola para ser colocados en la interfaz de salida.
Para crear una nueva disciplina de cola DSMARK se utiliza el siguiente comando:
#tc add qdisc dev eth0 handle <hd> root dsmark indices <id> [default_index
<did>] [ set_tc_index]
67/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.5.2. HTB (Hierarchical Token Bucket) [HTBLUG]
HTB surge como una disciplina ms entendible, intuitiva y ms rpida para
reemplazar a la qdisc CBQ en Linux.
HTB permite controlar el uso del ancho de banda saliente sobre un enlace dado.
Permite que se utilice un slo enlace fsico para simular varios enlaces ms
pequeos y para enviar diferentes tipos de trfico sobre diferentes enlaces
simulados. Se necesita especificar como dividir el enlace fsico en enlaces
simulados y como decidir que enlace simulado tiene que utilizar un paquete dado
para ser enviado.
Cual es la diferencia entre HTB y otra classfull como DSMARK . Bsicamente
su comportamiento. Una clase HTB solo controla el lmite superior de los
paquetes que fluyen por ella mientras que una clase DSMARK solo marca los
paquetes que fluyen por ella.
6.5.2.1. Compartiendo el enlace
Problema: Se tienen dos clientes, A y B, ambos
conectados a la Internet a travs de la interfaz
eth0. Se quiere dar 60kbps a B y 40 kbps a A.
Luego se quiere que en A se subdivida el ancho
de banda en 30 kbps para WWW y 10 kbps
para todo lo dems. Cualquier ancho de banda
disponible puede ser utilizado por cualquier
clase que lo necesite (en proporcin al ancho de
banda asignado).
HTB asegura que la cantidad de servicio provista a cada clase sea al menos el
mnimo entre la cantidad solicitada y el ancho de banda asignado. Cuando una
clase solicita menos que la cantidad asignada, el ancho de banda remanente
(excedente) se distribuye a las otras clases que soliciten servicio.
Anotacin: en la literatura esto se lo denomina borrowing (pedir prestado) del
ancho de banda excedente. Es importante aclarar, que este no parece ser el
trmino correcto porque no hay obligacin de devolver el recurso que se est
68/124
Figura 15: HTB Servicios a Controlar
[HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
pidiendo prestado.
Los diferentes tipos de trfico son representados por clases en HTB, un ejemplo
simple:
tc qdisc add dev eth0 root handle 1: htb default 12
Este comando conecta una disciplina de cola HTB a la eth0 y le da el handle 1:
esto es solo un nombre o identificador para poder referenciarlo posteriormente.
La parte default 12 significa que cualquier trfico que no sea clasificado ser
asignado a la clase 1:12 .
Anotacin: En general (no solo para HTB), los handles se escriben x:y donde x es
un entero identificando a una qdisc e y es un entero identificando a una clase que
pertenece a la qdisc x. El handle para una qdisc debe tener como valor y cero (0)
y el handle para una clase no debe tener como valor y cero.
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps
La primer linea crea una root class, 1:1 debajo de la qdisc 1:. Se define como
root class a la que tiene como padre a la qdisc htb. Una root class, como otras
clases debajo de una qdisc htb permite que sus hijos tomen prestado unos de
otros, pero una root class no puede pedir prestado de otra. Se podra haber creado
a las otras tres clases directamente debajo de la qdisc htb, pero cuando hubiera
trfico excedente en una no estara disponible para las otras. En este caso
queremos permitir que tomen prestado, es por eso que se ha creado una clase
extra para servir como root y poner a las clases que realmente mueven el trfico
debajo de esta.
Nota: El motivo por el cual se repite dev eth0 en todos los casos y no se coloca
solamente el handle, es porque los handles son locales a la interfaz en la que estn
definidos, por ejemplo, eth0 y eth1 pueden tener cada una clases con el handle
1:1.
69/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
A parte de definir las clases hay que describir que paquetes pertenecen a cada
clase.
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip src 1.2.3.4 flowid 1:11
(Identificamos a A con su IP address imaginemos que es 1.2.3.4)
No se ha creado un filtro para la clase 1:12 porque es la clase por omisin
(default) y todo el trfico que no sea clasificado cae directamente sobre ella.
Opcionalmente se pueden conectar disciplinas de cola a las clases leaf. Si no se
especifica nada se les asigna pfifo.
Estos son todos los comandos que se necesitan.
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
70/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
A continuacin se presentarn resultados de varios escenarios utilizando HTB.
Para la realizacin de los mismos se utiliz una herramienta desarrollada por el
mismo constructor de HTB denominada ethloop
http://luxik.cdi.cz/~devik/qos/ethloop/) , ethloop es un generador de paquetes y
una herramienta de medicin, el trfico que genera es colocado como salida de
una interfaz y eso permite simular los flujos necesarios realizando la medicin
de los mismos. Para generar los grficos se ha utilizado la salida de ethloop para
alimentar la herramienta gnuplot (http://gnuplot.sourceforge.net) .
Veamos que sucede si se envan paquetes a cada clase a 90 kbps y despus se deja
de enviar paquetes de una clase a cada momento. En figura 16 hay anotaciones
como 0:90k. La posicin horizontal en el medio de la etiqueta (en este caso
cerca de 9, marcado tambin con un 1 en rojo) indica el momento en que el
trfico de alguna clase cambia. Antes de los dos puntos (:) esta un identificador
para la clase (0 para la clase 1:10, 1 para la clase 1:11, 2 para la clase 1:12) y
despus de los dos puntos esta la nueva velocidad arrancando en el momento que
71/124
Figura 16: HTB - Comportamiento del trfico [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
aparece la anotacin. Por ejemplo la velocidad de la clase 0 se cambia a 90 k al
momento 0 , 0 (=0k) en el instante 3, y de nuevo a 90k en el momento 6.
Inicialmente todas las clases generan 90 kb. Dado que esto es mayor que
cualquiera de las velocidades especificadas, cada clase es limitada a su velocidad
especificada. En el momento 3 cuando se deja de enviar paquetes de la clase 0, la
velocidad dada a la clase 0 es reubicada a las otras dos clases en proporcin a sus
velocidades especificadas, 1 parte para la clase 1 y 6 partes a las clase 2.
(El aumento en la clase 1 es difcil de ver porque solo son 4kbps). Similarmente
en el momento 9 cuando el trfico de clase 1 se detiene su ancho de banda es
reubicado a las otras dos (y el aumento en la clase 0 es difcil de ver).
Al momento 15 es mas fcil ver que la asignacin a la clase 2 se divide en 3 partes
para la clase 0 y 1 parte para la clase 1. Al momento 18 ambas clases 1 y 2 se
detienen por lo tanto la clase 0 toma todos los 90 kbps que solicita.
Es bueno que se desarrolle el concepto de quantum ahora. En realidad cuando
ms clases quieren tomar prestado ancho de banda se les da a cada una un
nmero de bytes antes de atender a una otra clase que compite. Este nmero se
llama quantum. Debera verse que si varias clases estn compitiendo por el
ancho de banda de su padre (parent) entonces consiguen ancho de banda en
proporcin a sus quantums. Es importante saber que para una operacin precisa
los quantums deben ser lo ms pequeo posible y mayores que la MTU.
Normalmente no es necesario configurar los quantums manualmente dado que
HTB selecciona valores precomputados. HTB computa los quantums de las
clases (cuando se agrega o se cambia) dividiendo la tasa de la clase por un
parmetro global llamado r2q. El valor por defecto de r2q es 10 porque la MTU
(Maximum Transfer Unit, la mayor cantidad de datos que se puede transferir por
unidad a travs de una red fsica dada) tpica es 1500, el valor por defecto es
bueno para valores desde 15 kBps (120 kbit). Para velocidades menores coloca el
r2q en 1 cuando crea la qdisc es un buen valor desde 12kbit lo cual debera ser
suficiente. Se puede evitar los warnings en los logs cuando el valor precomputado
este mal. Cuando se especifica el quantum en la lnea de comando el r2q es
ignorado para esa clase.
Esto pareciera ser una buena solucin si A y B no son clientes diferentes.
Sin embargo, si A est pagando por 40kbps entonces podra preferir que su ancho
72/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
de banda de WWW en desuso sea utilizado por el mismo por otro servicio en vez
de que lo utilice B.
Este requerimiento puede cubrirse con HTB utilizando jerarquas de clases.
6.5.2.2. Jerarqua de comparticin
El problema anterior puede resolverse con la jerarqua de clases de la figura 17.
El cliente A ahora est representado explcitamente por su propia clase. Tomes
en cuenta que la cantidad de servicio provista a cada clase es al menos el mnimo
entre la cantidad que solicita y la cantidad asignada a la clase. Esto se aplica a las
clases HTB que no son padres de otras clases HTB. Se le llama a estas clases leaf
classes.
Para las clases HTB que son padres de otras clases HTB, a las cuales se las llama
interior classes, la regla es que la cantidad de servicio es al menos el mnimo entre
la cantidad asignada a la clase y la suma de la cantidad solicitada por todos sus
hijos.
En este caso se asignan 40kbps al cliente A. Esto significa que si A solicita
menos que la cantidad asignada para WWW, el excedente ser utilizado por otro
tipo de trfico de A (si hay demanda ), al menos hasta que la suma de 40kbps.
Nota: Las reglas de clasificacin de paquetes pueden asignar paquetes a nodos
interiores. Para eso se debe conectar otra lista de filtro al nodo interior.
Finalmente debera llegar a la clase especial 1:0. La velocidad entregada a un
padre (parent) debera ser la suma de las velocidades de sus hijos.
73/124
Figura 17: HTB Servicios a Controlar con
Jerarqua [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Los comandos son los siguientes:
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil
100kbps
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 40kbps ceil
100kbps
tc class add dev eth0 parent 1:2 classid 1:10 htb rate 30kbps ceil
100kbps
tc class add dev eth0 parent 1:2 classid 1:11 htb rate 10kbps ceil
100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil
100kbps
Viendo la figura 18 con los resultados de la solucin jerrquica,
cuando el trfico de WWW de A para, el ancho de banda asignado es reubicado a
otro trfico de A de manera que el ancho de banda total de A sigue siendo 40kbps.
Si todo el trfico de A solicita menos de los 40kbps el excedente ser asignado a
B.
74/124
Figura 18: Comportamiento del trfico jerrquico [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
6.5.2.3. Velocidad Techo
El argumento ceil (techo) especifica el ancho de banda mximo que puede utilizar
una clase. Esto limita cuanto ancho de banda puede pedir prestado una clase.
El ceil por default es el mismo que el rate asignado.
En el ltimo ejemplo se cambi el ceil (techo) de 100kbps para las clases 1:2 (A)
y 1:11 (Otro trfico de A) del ejemplo anterior a 60kps y 20kbps respectivamente.
El grfico de la figura 18 difiere del de la figura 16 en que en el momento 3
(cuando el trfico de WWW se para) porque el otro trfico de A est limitado a
20kbps. Por lo tanto el cliente A consigue solo 20kbps en total y los 20kbps
inutilizados son asignados a B.
La segunda diferencia es al momento 15 cuando B para. Sin el ceil (techo), todo
el ancho de banda es entregado a A, pero ahora A solo tiene permitido utilizar
60kpbs, entonces los otros 40kbps quedan inutilizados.
Esta funcionalidad debera ser de mucha utilidad para los ISP porque ellos
seguramente quieren limitar la cantidad de servicio que consigue un cliente en
particular an cuando los otros clientes no estn solicitando servicio. (Los ISP
probablemente quieren que los clientes paguen ms dinero por un servicio mejor).
Es importante aclarar que las clases root no tienen permitido pedir prestado,
entonces no hay forma de definirles un ceil.
Nota: El ceil para una clase debera ser al menos igual al rate. Tambin, el ceil
de una clase debera ser al menos igual al ceil de cualquiera de sus hijos.
6.5.2.4. Rfagas
El hardware de networking solo puede enviar un paquete a la vez y a la velocidad
que el hardware tiene. El software para compartir un enlace puede utilizar esta
habilidad para aproximar el efecto de mltiples enlaces de diferentes velocidades.
Por lo tanto la velocidad (rate) y el techo (ceil) no son realmente medidas
instantneas sino promedios durante un tiempo que tome enviar algunos paquetes.
Lo que ocurre realmente es que se deja que una clase curse trfico enviando unos
pocos paquetes a mxima velocidad durante un momento y luego se hace lo
75/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
mismo con las otras clases.
Los parmetros burst y cburst controlan la cantidad de datos que pueden ser
enviados a mxima velocidad (la velocidad del hardware) sin intentar dar servicio
a otra clase.
Si cburst es mas pequeo (idealmente el tamao de un paquete) modela las
rfagas (shaping) para no exceder la velocidad ceil, de la misma forma que lo
hace el peakrate de TBF.
Cuando se ve que el burst de una clase padre es menor que el de alguna clase hija
entonces es de esperar que la clase padre se quede congelada algunas veces
(porque la clase hija solicitar ms que lo que la clase padre puede manejar).
HTB recordar estas rfagas negativas hasta 1 minuto.
Uno puede preguntarse porque son necesarias las rfagas, bien, es una forma
barata y simple de mejorar los tiempos de respuesta sobre enlaces congestionados.
Por ejemplo el trfico de WWW es de rfagas. Uno puede solicitar una pgina y
que entre en el valor de un burst y poder leerla.
Durante el perodo de tiempo de inactividad el valor de burst volver a cargarse
de nuevo.
Nota: El valor de burst y cburst de una clase debera siempre ser al menos igual
o mayor que el de cualquiera de sus hijos.
76/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
En el grfico de la figura 19 puede verse el caso del ejemplo anterior donde se ha
cambiado el parmetro burst a 20kbps para la clase roja y amarilla (A), pero
cburst se lo dej en el por defecto (2kb).
El crecimiento del verde es al momento 13 debido al valor de burst en la clase
SMTP. El verde estuvo por debajo del lmite desde el momento 9 y acumul 20kb
de burst. El crecimiento es hasta 20kbps (limitado por el ceil porque tiene cburst
cercano al valor de 1 paquete).
Se puede llegar a pensar porque no hay un crecimiento del rojo y el amarillo en el
momento 7. Esto es porque el amarillo ya est en el lmite de su ceil y no tiene
ms espacio para rfagas adicionales.
Hay un comportamiento no deseado el valle que hace el magenta al momento 4.
Esto es porque intencionalmente se dej sin agregar burst a la clase del enlace
77/124
Figura 19: Comportamiento del trfico jerrquico con cambio en burst y
cburst de [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
root (1:1). La clase record el crecimiento del momento 1 y en el momento 4
cuando la clase azul quiso pedir prestado de la clase amarilla se lo deneg y se
compens a si misma.
Limitacin: cuando se opera con altas velocidades en computadoras con timers
de baja resolucin es necesario configurar un burst y un cburst mnimo a todas
las clases. La resolucin del timer de un i386 es de 10ms y 1ms en un Alpha. El
burst mnimo puede computarse como max_velocidad*resolucin_de_timer.
Entonces para 10Mbit en un i386 se necesita un bursts de 12kb.
Si se configura un burst demasiado pequeo se recibir una velocidad menor a la
que se ha configurado. El comando tc computar y configurar el burst ms
pequeo que se pueda si no se lo especifica.
6.5.2.5. Priorizando la comparticin del ancho de banda
Priorizar trfico tiene dos aspectos. Primero afecta como el ancho de banda
excedente se distribuye entre las clases hermanas. Hasta ahora hemos visto que el
ancho de banda excedente se distribuye de acuerdo a los valores de rate.
78/124
Figura 20: Comportamiento del trfico jerrquico con cambio en las
prioridades de [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Ahora veremos la misma configuracin de la parte de jerarqua de clases sin ceil
ni burst cambindole la prioridad a todas las clases a 1 excepto a SMTP (verde) a
la cual se le pondr 0 (mayor prioridad).
Desde el punto de vista del compartido se puede ver que la clase toma todo el
ancho de banda excedente. La regla es que se le ofrece el ancho de banda
excedente primero a la clases con prioridades superiores.
Pero las reglas sobre el rate y el ceil todava se respetan.
Tambin hay una segunda cara del problema. Es el delay total del paquete. Es
difcil de medir sobre una ethernet porque es muy rpida. Pero hay una ayuda
simple.
Se puede agregar HTB simple con el rate de una clase limitado a menos de
100kbps y agregar una segunda HTB (la que queremos medir) como hija.
Entonces se puede simular un enlace ms lento con delays mayores.
Por simplicidad se plantea un escenario de dos clases:
# qdisc for delay simulation
tc qdisc add dev eth0 root handle 100: htb
tc class add dev eth0 parent 100: classid 100:1 htb rate 90 kbps
# real measured qdisc
tc qdisc add dev eth0 parent 100:1 handle 1: htb
AC="tc class add dev eth0 parent"
$AC 1: classid 1:1 htb rate 100kbps
$AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps prio 1
$AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps prio 1
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 2
tc qdisc add dev eth0 parent 1:11 handle 21: pfifo limit 2
Nota: HTB como hija de otra HTB no es lo mismo que una clase debajo de otra
clase dentro del mismo HTB. Esto es porque una clase que en HTB puede enviar
lo har tan rpido como el hardware puede. Por lo tanto el delay de la clase que
est limitando es solo limitado por el equipamiento y no por los ancestros.
En el caso de HTB debajo de HTB el HTB de afuera simula un nuevo
equipamiento de hardware con todas las consecuencias (mayor delay).
Se coloca un simulador para generar 50kbps para ambas clases y a los 3 segundos
se ejecuta el siguiente comando:
79/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
# tc class change dev eth0 parent 1:2 classid 1:10 htb \
rate 50kbps ceil 100kbps burst 2k prio 0
Como se puede ver en la figura 21 el delay de la clase WWW cay cercano a cero
mientras el delay de SMTP creci. Cuando se prioriza para tener un delay mejor
siempre se hace sobre la base que el delay de las otras clases empeorar.
Ms tarde (a los 7 segundos) el simulador comienza a generar trfico WWW a 60
kbps y SMTP a 40kbs. Ah se puede ver un comportamiento interesante. Cuando
la clase (WWW) est por encima de sus lmites HTB prioriza la parte del ancho de
banda que est por debajo de sus lmites primero.
Qu clases deberan priorizarse ?
Generalmente aquellas clases donde realmente se necesita bajos delays. El
ejemplo anterior podra haber sido trfico de video o audio o trfico interactivo
(telnet, SSH) que es de rfagas naturalmente y no afectar negativamente a los
otros flujos.
Un truco comn es priorizar ICMP para tener delays de ping muy buenos an
sobre enlaces totalmente utilizados (pero tcnicamente visto esto no es lo que uno
quiere cuando mide conectividad).
80/124
Figura 21: Comportamiento del trfico jerrquico con cambio en las
prioridades a los 3 segundos de [HTBLUG]
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7. Implementacin
7.1. Introduccin
Hemos visto la situacin actual de la problemtica de IP frente a la
posibilidad de realizar QoS, conjuntamente con los modelos estndares (de capa 3
[IntServ-DiffServ] y capa 2[MPLS]) para enfocar alternativas de solucin a estos
inconvenientes.
Adicionalmente se han desarrollado las capacidades de Linux como sistema
operativo y herramienta para realizar QoS.
Dada la existencia de poderosas herramientas (Linux / tc / iptables) y las
necesidades explicitadas, se propuso desarrollar un Controlador de Ancho de
Banda (de borde), con caractersticas de distribucin de ancho de banda con
alguna poltica justa.
Se dice que el controlador es de borde dado que se orient su diseo y
construccin a poder brindar una herramienta de administracin a ISPs que
integran el ltimo eslabn de la cadena de distribucin de servicio de acceso a
Internet u organizaciones que poseen enlace propio de Internet y requieren una
herramienta para control de su enlace.
El controlador desarrollado no implementa un modelo de QoS extremo a
extremo, pudiendo, en caso de ser necesario extender sus funcionalidades dado
que el Sistema Operativo subyacente, Linux, soporta los estndares de DiffServ e
IntServ.
Si bien en el presente trabajo se ha desarrollado la situacin actual de la
tecnologa y los problemas ms comunes, cabe destacar que el desarrollo que se
explicar a continuacin fue motivado por las necesidades de una empresa de
Telecomunicaciones de la provincia de Mendoza, ITC SA, quien encarg a la
empresa en la que trabajo (Silice S.A.) la construccin de un controlador de ancho
de banda.
En ese contexto conform un equipo de trabajo con el Ing. Juan Jos Ciarlante
quien trabajo conmigo en la construccin del controlador.
81/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Los requerimientos iniciales fueron los siguientes:
Permitir asignar una franja de trfico a usuarios del servicio de red a
controlar, y si el trfico no est utilizado que pueda ser repartido entre los
otros usuarios, siempre garantizando un mnimo a cada uno.
Permitir asignar trfico en funcin de Direccin IP origen o grupo de
direcciones IP de origen y tipo de servicio que el cliente esta consumiendo
(puerto destino). [Flujo]
Implementar un sistema de monitoreo capaz de realizar un histrico del
trfico utilizado y una vista instantnea.
Dotar al equipo con caractersticas de ser "transparente" para el resto de los
equipos activos de manera que en caso de desperfecto pueda ser
reemplazado por un patch cord de red.
Poder construir curvas de trfico para los servicios que permitan modificar
la asignacin de ancho de banda en funcin del tiempo.
Utilizar como hardware de base un equipo de computacin convencional.
Para poder satisfacer los requerimientos iniciales se dise una solucin
que realice una gestin del trfico de la red que maximice la distribucin
equitativa del ancho de banda en funcin de la utilizacin de la red garantizando
un mnimo a cada cliente.
Para esto el controlador debe conocer el ancho de banda total disponible ya
que el funcionamiento es el siguiente: a cada red de cliente se le puede asignar un
ancho de banda mnimo y un ancho de banda mximo, en condiciones de alta
utilizacin de la red todos los clientes reciben el ancho de banda mnimo
asignado, y en condiciones de baja utilizacin de la red la diferencia entre el
ancho de banda total de la red y el utilizado actualmente se distribuye
proporcionalmente entre todos los clientes que estn haciendo uso del servicio
hasta alcanzar (si hay ancho de banda disponible) el mximo asignado a cada
cliente pero sin superarlo.
82/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.2. Arquitectura general
83/124
Figura 22: Esquema de Arquitectura del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
El controlador funciona sobre una equipo tipo PC con sistema Operativo Linux,
toda la informacin de configuracin y registro es almacenada en un motor de
base de datos.
El controlador est compuesto por un demonio (daemon) (Sheiper-Server) que
realiza las acciones de bajo nivel (interaccin con el sistema operativo, toma de
muestras de trfico, insercin de datos al motor de base de datos) y una interfaz
web responsable del resto de las tareas.
La interfaz interacta con el daemon a traves de un socket local en el servidor
desadaptando potenciales inconvenientes de seguridad.
7.3. Funcionamiento y detalle de componentes de la Arquitectura
La base del controlador es el sistema operativo Linux con su soporte de QoS y las
herramientas que permiten su configuracin.
Dentro de las mltiples disciplinas de cola se seleccion HTB (Hierarchical Token
Bucket), que se ajusta perfectamente a los requerimientos planteados (ver en
detalle HTB en el captulo anterior).
Esta disciplina de cola cuenta con scripts de configuracin estndares (htb.init)
que permiten definir las clases y su jerarqua, no obstante ello, las posibilidades de
clasificacin de los filtros de la arquitectura de control de trfico (tc) son bastante
limitadas en comparacin con el soporte de netfilter (firewalling de Linux).
Es por esto que se utiliz como herramienta para realizar la etapa de clasificacin,
iptables, que permite mayores capacidades de seleccin de paquetes.
Para realizar la identificacin y determinacin del contexto de los paquetes
(flujos) el controlador utiliza iptables con marcas de firewall, las cuales existen
solo durante el viaje del paquete dentro del kernel de Linux (no confundir con
marcas que viajan en algn campo de la cabecera IP tipo DSCP). Cuando el
paquete es identificado (de acuerdo a la informacin de configuracin) es marcado
y su marca de firewall se asocia a una clase de trfico dentro de la jerarqua HTB.
La granularidad de control de trfico dentro del controlador se asocia al concepto
de servicio, un servicio tiene asociada una marca de firewall y una clase de
trfico. Al servicio se le definen parmetros de control de trfico (ancho de banda
mximo y ancho de banda mnimo [rate y ceil de HTB]) y se le pueden definir
84/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
mltiples filtros de paquete IP, denominados condiciones IP.
Las condiciones IP son reglas de iptables que permiten cubrir un amplio espectro
de clasificacin y asociarlas a un servicio con la marca de firewall, de esta manera
un servicio puede tener mltiples condiciones IP, lo cual brinda una gran
versatilidad al controlador.
El controlador diferencia los flujos de subida (upstream, controlando el trfico
saliente en la interfaz de red que da al enlace de subida, generalmente Internet) de
los de bajada (downstream, controlando el trfico saliente que da a la interfaz del
enlace de bajada, generalmente una LAN o MAN de clientes/usuarios).
Dado que en la realidad los servicios no existen por si solos, el controlador posee
un modelo orientado al control de clientes, que generalmente tienen asociados
datos de direccionamiento IP que le son nicos (aunque esta no es la nica manera
de operar que tiene el controlador). Para esto se pueden definir clientes
(Empresas,Organizaciones, Puestos de trabajos, etc.) a los cuales se le pueden
asociar mltiples redes (Direccionamiento IP CIDR (Classless InterDomain
Routing para ms informacin consultar RFC1338 y RFC1519)) y las redes son
las que poseen servicios.
En la mayora de los casos el controlador se utiliza definiendo clientes, creando
una red para el cliente y dos servicios por defecto, uno para el trfico hacia el
cliente y otro para el trfico desde el cliente, cada uno con su mximo y mnimo.
La medicin de trfico instantnea se obtiene consultando el estado de las clases
de trfico, utilizando las herramientas que provee la arquitectura de control de
trfico de Linux (tc).
La medicin del trfico promedio de un servicio se realiza tomando muestras cada
5 minutos sobre los contadores de bytes de las reglas de firewall de las marcas
asociadas a cada clase de trfico. Estos contadores son almacenados directamente
en la base de datos para su posterior procesamiento, graficado y anlisis.
El controlador posee un mdulo de eventos que permite definir cambios sobre los
parmetros de trfico de un servicio en particular o de todos los servicios. Los
eventos se definen en un formato similar a cron de Unix. Es decir, es posible
definir un evento y que este se active en una hora, minuto, da del mes, da de la
semana o mes en particular. Una sucesin de eventos permite crear una curva
de trfico para un servicio en particular, lo cual es de extrema utilidad para los
85/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
ISP, ya que se puede hacer que el controlador modifique su comportamiento en la
noche o los fines de semana por ejemplo.
La informacin de configuracin (clientes, redes, servicios, condiciones IP y
estadsticas de trfico, parmetros generales, usuarios) queda totalmente
almacenada en un motor de base de datos. Para la implementacin se seleccion
el Motor de Base de datos MySQL, que presenta muy buenas caractersticas de
disponibilidad y performance.
Toda la administracin se realiza utilizando un navegador, ya que la interfaz est
desarrollada en lenguaje PHP corriendo en un servidor de Web Apache. Esto
permite administrar el controlador desde cualquier lugar con acceso IP al mismo.
La interfaz interacta a travs de un protocolo de aplicacin con el daemon
(sheiper-server) que realiza las tareas de bajo nivel, y tambin realiza accesos a la
base de datos para construir las configuraciones que utilizan los scripts estndares
de HTB y la administracin en general.
La interfaz web est desarrollada orientada a objetos y con manejo de sesiones y
roles de usuarios. Permite definir usuarios con roles, administrador u operador.
Los distintos roles se diferencian fundamentalmente en que el rol operador solo
tiene acceso a ver la actividad del controlador sin poder realizar ningn cambio
sobre el mismo y el rol administrador tiene acceso y control total sobre el
controlador.
7.4. Aspectos Importantes del Diseo
Como se explic anteriormente, el controlador define servicios que se asocian a
clases de trfico que pertenecen a una jerarqua de trfico propia de HTB.
Dado que la disciplina de cola, inherentemente es jerrquica, el controlador ms
all de su configuracin general (cliente-> red -> servicio de UP y servicio de
DOWN) soporta la definicin de servicios que son hijos de otros servicios (con
dos niveles de profundidad).
Para ejemplificar, en modo normal al definir un cliente se le asignara un ancho de
banda mnimo y mximo para todo lo que enva o reciba. Por ejemplo 128kits
(mximo y mnimo como si fuera una linea dedicada de 128kbits).
Con el controlador es posible definir nuevos servicios que dependen de este
86/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
servicio padre y realizar una diferenciacin por ejemplo creando un nuevo
servicio que mapee todo el trfico de www (http) y que tenga un ancho de banda
(mximo y mnimo) de 64 kbits. Este nuevo servicio tomar prestado de su padre
hasta los 64kbits y los restantes 64kbits sern utilizados por todos los otros
protocolos que no sean http.
Otro aspecto importante de diseo es la separacin de funciones entre la interfaz
Web y el daemon (sheiper-server). Todas las actividades que realizan cambios
sobre el sistema operativo requieren de privilegios de root (reglas de iptables,
cambios sobre las clases de trfico, configuracin de interfaces de red, rutas, etc.).
Dado que la operacin del controlador es a travs de la interfaz web, hubiera sido
necesario correr el servidor de Web con privilegios de root, lo cual est
totalmente no recomendado. Para poder realizar estas tareas y tener una
separacin de privilegios, se opt por la construccin de un protocolo de
aplicacin entre el controlador y la interfaz y hacer que esta comunicacin se diera
utilizando un socket. El daemon realiza un bind sobre una interfaz local
(127.0.0.1), permitiendo que solamente sea accedido desde la misma mquina
donde corre la administracin, pero en ningn caso es posible ejecutar un
comando del sistema operativo desde la interfaz Web.
Otro aspecto importante del diseo es que el controlador puede manejar un cliente
y una red especial (0.0.0.0/0) con sus dos servicios de down y up. En estos
servicios se mapea todo el trfico que no es clasificado por ningn otro servicio
que est definido dentro del controlador. Esto da una herramienta muy til al
momento de implementar un controlador de ancho de banda, ya que se puede
arrancar su implementacin utilizando la red especial 0.0.0.0 y despus empezar a
definir una por una las dems redes.
A su vez, cada entidad del modelo de datos est reflejada, dentro del cdigo de la
interfaz del controlador, por su correspondiente clase.
87/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.5. Implementacin de la Arquitectura
Como vimos en los detalles de la arquitectura, el controlador se compone
fundamentalmente de:
Daemon (sheiper-server)
Interfaz de Administracin Web
7.5.1. Daemon (sheiper-server)
El daemon interacta con la interfaz a travs de un socket tcp utilizando un
protocolo de aplicacin.
Este protocolo de aplicacin representa el conjunto de acciones que la interfaz
puede solicitar al controlador y est compuesto por verbos (acciones) y
argumentos para los mensajes desde la interfaz al controlador, y las respuestas
devuelven un cdigo de error (400) o xito (200) tipo http, un salto de lnea y la
salida de la accin solicitada.
A continuacin se detallan los mensajes del protocolo:
Mensaje desde la
Interfaz
Respuesta del Controlador Descripcin
start 200 Ok
400 Error en encender
Tiene por objetivo encender el control
de ancho de banda
stop 200 Ok
400 Error en apagar
Tiene por objetivo apagar el control de
trfico
version 200 Ok
$Id: sheiper-server.sh,v 1.18
Devuelve la versin del cdigo del
controlador
88/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
status Apagado
200 Ok
Command: status
OFF
iptables_NET=0
tc_eth0=0
tc_eth1=0
Encendido
200 Ok
Command: status
ON
Tiene por objetivo consultar el estado
del controlador, si est encendido o est
apagado
net conf {parmetros} Tiene por objetivo pasarle al
controlador los parmetros de
configuracin general que son
necesarios para que el controlador
pueda arrancar y configurar las
interfaces de red, el ancho de banda del
enlace a controlar, las rutas a redes
internas, etc.. .
net routeadd {ruta} 200 Ok Tiene por objetivo pasarle al
controlador un destino en notacin
CIDR para que sea colocado como una
ruta a travs de la interfaz interna del
controlador. Esta ruta se hace efectiva
inmediatamente.
net routedel {ruta} 200 Ok Tiene por objetivo pasarle al
controlador un destino en notacin
CIDR para que sea eliminado de la tabla
de ruteo. Este cambio se hace efectivo
inmediatamente.
net stop 200 ok Tiene por objetivo detener las interfaces
de red.
net start 200 ok Tiene por objetivo encender las
interfaces de red.
89/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
net restart 200 ok Tiene por objetivo detener y encender
las interfaces de red.
dump iface count addr Salida en formato ethereal del
volcado de red de los
paquetes.
Tiene por objetivo realizar un volcado
de count (cantidad de paquetes)
paquetes sobre la interfaz iface para
todos los paquetes que pertenezcan a
addr (en notacin CIDR).
Stats iface [classid] 200 Ok
Command: stats iface [class]
Salida que muestra una lnea
por cada clase de trfico
compusta por:
classid classidpadre
rateactual backlog min max
Tiene por objetivo consultar al
controlador sobre el trfico instantneo
de todas las clases de una interfaz (iface)
. Si se especifica classid solo muestra el
trfico de esa clase en particular.
El daemon est desarrollado completamente en lenguaje de scripting del shell
bash de Linux.
En efecto el daemon es un script que podra ser invocado desde la linea de
comando del controlador, para poder transformarlo en un servicio tcp, lo que se ha
hecho es utilizar xinetd, que se encarga de realizar toda la gestin de tcp para la
comunicacin. Es decir, xinetd permite que la entrada estandar y la salida
estandar del script sea un socket tcp.
Desde el punto de vista de la configuracin la implementacin del daemon y el
servicio de xinetd se ha realizado de la siguiente manera:
Servicio de xinetd: /etc/xinetd.d/sheiper y /etc/services
/etc/xinetd.d/sheiper
service sheiper
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/local/sheiper/sbin/sheiper-server.sh
log_on_success += DURATION USERID
log_on_failure += USERID
bind = 127.0.0.1
}
90/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
/etc/services
[Se agrega una lnea que asocia el servicio al puerto tcp donde se
va a realizar el bind]
sheiper 9006/tcp
El archivo de configuracin /etc/xinetd.d/sheiper en conjunto con la lnea de
configuracin en /etc/services le dicen a xinetd que debe realizar un bind del
ejecutable /usr/local/sheiper/sbin/sheiper-server.sh en el puerto tcp 9006 sobre la
direccin IP 127.0.0.1, y que este ejecutable correr con privilegios de root.
De esta manera se logra prender el daemon sheiperserver y dejarlo asociado
solamente a la mquina local.
Como parte de las herramientas necesarias para poder realizar su tarea sheiper-
server utiliza la herramienta de configuracin de la disciplina de cola HTB. Esta
herramienta se compone de archivos de configuracin (ubicados en /
etc/sysconfig/htb/ ) y un script denominado htb.init .
El script htb.init est programado enteramente en bash y responde al estndar de
procesos de inicio SysV, esto es, puede ser colocado en el lugar donde se ubican
todos los scripts de inicio de servicios o aplicaciones en conformidad con el
runlevel en el que est ejecutando el equipo.
En trminos generales htb.init se encarga de leer los archivos de configuracin y
generar los comandos de tc (tc como se vio anteriormente, es el comando que
permite manipular la configuracin del control de trfico en Linux) que plasman
las diferentes clases de trfico que se requieren.
El daemon sheiper-server invoca a htb.init cada vez que es necesario: crear,
modificar o eliminar las configuraciones de control de trfico.
Este aspecto fue una consideracin de implementacin importante, ya que se
podra haber hecho que el controlador directamente generara las clases de trfico,
pero se entendi como importante mantenerse acorde a los estndares.
91/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.5.2. Interfaz de Administracin Web
La interfaz de administracin web se implement utilizando el lenguaje de
programacin PHP, que posee caractersticas ptimas para el acceso a base de
datos y tambin un muy buen soporte de la API de sockets.
La interfaz debe comunicarse con el controlador y permitir que el administrador
realice las acciones necesarias.
Dado que el daemon toma la informacin de los archivos de configuracin de htb
y las aplica, la interfaz debe generarle los archivos de configuracin (que
describen las clases de trfico) a partir de la informacin de alto nivel que asocia a
clientes-> redes -> servicios.
La informacin de alto nivel se almacena en la base de datos utilizando el
siguiente modelo de datos:
Como puede verse un cliente puede tener una o muchas redes, cada red puede
tener uno o muchos servicios, los servicios pueden tener ninguna o muchas
condiciones IP, ninguno o muchos eventos y ninguna o muchas stats.
El modelo de datos adicionalmente tiene dos tablas administrativas. La tabla
usuario se utiliza para almacenar los usuarios, sus contraseas, el rol y desde que
direccin IP pueden conectarse al controlador para adminitrarlo. La tabla
92/124
Figura 23: Modelo de Datos del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
parmetro se utiliza para almacenar los parmetros de configuracin general del
controlador, aqu se encuentran almacenadas las rutas de red, el ancho de banda
del enlace que se est controlando, las interfaces de red, etc. .
En base al mismo modelo de datos se implement una clase de PHP por cada
entidad del modelo, para manipular los mtodos que pueden realizarse sobre ese
tipo de objetos.
Adicionalmente se desarroll una clase que implementa los mtodos del
controlador, que en general estn asociados a los verbos del protocolo de
aplicacin ms otros mtodos que cumplen tareas de entrega de informacin por
pantalla.
Las clases que se utilizan para la interfaz son las siguientes:
sheiper_backup.php: Esta clase implementa los mtodos necesarios para
poder realizar copias de seguridad y mantenimiento de las bases de datos
del controlador.
sheiper_cliente.php: Esta clase implementa los atributos y los mtodos
que describen y permiten administrar los clientes.
sheiper_condip.php: Esta clase implementa los atributos y los mtodos
que describen y permiten administrar las condiciones IP.
sheiper_controlador.php: Esta clase fundamentalmente implementa los
mtodos que permiten hacer uso del daemon, esta clase tiene la
inteligencia para hablar con el daemon en el lenguaje del protocolo de
aplicacin antes descripto.
sheiper_estadistica.php: Esta clase implementa los mtodos que realizan
clculos sobre los trficos instantneos y sobre el trfico promedio
almacenado en la base de dato para poder mostrar grficos de consumo y
construir rankings de consumo.
sheiper_evento.php: Esta clase implementa los mtodos que permiten
administrar y activar los eventos que modifican el comportamiento de los
servicios. Esta clase utiliza como soporte un script que est vinculado al
cron del sistema y se ejecuta cada un minuto. Este script revisa los
eventos definidos e instruye al daemon para realizar los cambios
necesarios.
sheiper_parametro.php: Esta clase implementa los mtodos que
93/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
permiten crear, eliminar y consultar los parmetros generales.
sheiper_proto.php: Esta clase es de soporte para la clase controlador, ya
que se encarga de implementar los mtodos para gestionar el socket de tcp
y el protocolo de aplicacin interfaz-daemon
sheiper_red.php: Esta clase implementa los atributos y los mtodos que
describen y permiten administrar las redes.
sheiper_servicio.php:Esta clase implementa los atributos y los mtodos
que describen y permiten administrar los servicios.
sheiper_usuario.php: Esta clase implementa los atributos y los mtodos
que describen y permiten administrar los usuarios.
Las clases son utilizadas para instanciar los objetos que realmente le dan vida a
la interfaz de administracin. La interfaz se compone de los siguientes mdulos:
clases.inc.php: Se encarga de incluir el cdigo de la definicin de todas
las clases para que puedan ser instanciadas en cualquier script que lo
incluya (a classes.inc.php).
config.inc.php: Tiene la informacin general de configuracin para poder
basicamente acceder a la base de datos.
index.php: Se encarga de presentar el formulario de login del usuario.
validar.php: Es invocado por el index.php para realizar la validacin del
usuario, si esta es correcta, se crear una sesin en PHP para mantener la
informacin persistente. Una vez validado el usuario y creada su sesin se
invoca al script que se haya definido en los parmetros como el script
principal, generalmente : sheiper.php. Si el usuario es incorrecto se lo
redirige nuevamente a index.php
auth.inc.php: Una vez que se valid al usuario y se creo la sesin de PHP,
este script se utiliza para incluirlo en todos los scripts que se desea
verificar que quien est tratando de acceder es un usuario correctamente
validado y que tiene una sesin.
abm_backup.php: Permite consultar el tamao de las tablas de la base de
datos, limpiarlas y realizar copias de seguridad de la misma.
94/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
abm_cliente.php: Altas, Bajas, Modificaciones de Clientes.
abm_condip.php: Altas, Bajas, Modificaciones de Condiciones IP.
abm_evento.php:Altas, Bajas, Modificaciones de Eventos.
abm_parametro.php: Altas, Bajas, Modificaciones de Parmetros.
abm_red.php: Altas, Bajas, Modificaciones de Red.
abm_servicio.php: Altas, Bajas, Modificaciones de Servicios.
abm_usuario.php: Altas, Bajas, Modificaciones de Usuarios.
dump.php: Permite realizar el volcado de paquetes de una red en
particular.
evento.php: Se utiliza para aplicar los eventos que se hayan definido. Es
utilizado por el cron del sistema.
footer.inc.php: Definicin HTML del pie de pgina.
header.inc.php: Definicin HTML de la cabecera de pgina.
logout.php: Permite cerrar la sesin de usuario y lleva a index.php.
sheiper_conf.php: Permite realizar tareas de control sobre el daemon,
apagarlo, prenderlo, solicitarle estadsticas, agregar rutas, eliminar rutas,
apagar o encender las interfaces de red, apagar o encender el control de
trfico. Todas las tareas que soporta el protocolo de aplicacin.
sheiper.php: Esta es la consola de administracin y visualizacin general
del controlador. Presenta toda la informacin del trfico, los clientes y sus
estadsticas en una sola vista.
stats_hist.php: Permite realizar las consultas del trfico promedio
histrico de un servicio.
stats.php: Permite visualizar el trfico instantneo de un servicio.
stats_root.php: Permite visualizar el trfico instantneo de la clase root,
es decir todo el trfico que est cursando el controlador.
95/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6. Funcionalidades
El controlador permite asignar parmetros de trfico (mximo, mnino) a
servicios, un servicio est caracterizado por una o varias condiciones IP (una
condicin IP es una regla que especifica que caractersticas de IP debe cumplir un
paquete para cumplir con esa regla). El servicio es la mnima unidad estadstica y
de control. Los servicios son asignados a una red y es de esta manera que se
asocian los parmetros de trfico con las redes.
El controlador permite dar de alta clientes, estos clientes son los que pueden tener
una o mas redes a las cuales es posible asignarles servicios.
La interfaz web (bajo protocolo http sobre ssl) cuenta con los siguientes
mdulos:
Login/Logout
Gestin de trfico
Clientes
Redes
Servicios
Condiciones IP
Eventos
Backup
Parmetros
Usuarios
Controlador
96/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.1. Login/Logout
Dado que la administracin se realiza por la interfaz web, para poder acceder a la
misma es necesario ingresar al URL del controlador, que generalmente es su IP y
un directorio dentro del web server.
Una vez colocado el URL ser necesario validarse para poder ingresar, una vez
validado no es necesario volver a colocar el usuario y contrasea, salvo que se
realice un Logout.
97/124
Figura 24: Login del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.2. Gestin de Trfico
Una vez que el usuario se ha validado el controlador ingresa al mdulo de Gestin
de Trfico (esto es configurable por parmetros), este mdulo es la consola de
visualizacin y control general.
Como se ve en la figura 25 se presentan todas las redes definidas, con su
correspondiente cliente y los servicios definidos para cada red. En azul se colocan
todos los servicios que sean de downstream y en rojo todos los servicios de
upstream.
Cada servicio aparece definido (de izquierda a derecha) con una cadena
descriptiva (por ej. : Default_Down), su trfico mnimo, su trfico mximo, un
nmero 5 (ventana emergente que muestra el trfico instantneo cada 5 segundos),
98/124
Figura 25: Pantalla de Gestin de Trfico del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
un nmero 10 (ventana emergente que muestra el trfico instantneo cada 10
segundos)(figura 26), una letra H (ventana emergente que accede al mdulo de
estadsticas histricas), una letra E (vnculo que lleva a visualizar todos los
eventos del servicio), un nmero (que representa el backlog de la clase del
servicio) y un nmero que representa el trfico del servicio.
A la izquierda de la definicin del servicio se presenta la red y el cliente al que
pertenece. Tambin se presenta un vnculo especial dump que permite realizar un
volcado instantneo del trfico de esa red en particular, a los efectos de
diagnstico.
En la parte superior se presenta la informacin sobre la cantidad de ancho de
banda asignado a todos los servicios definidos (de mnimos y mximos) y tambin
es posible ver el consumo total de manera instantnea accediendo al vnculo
Down o Up.
Por encima de esta informacin se tienen listas desplegables para facilitar la
ubicacin de un cliente o red en particular y a la derecha aparecen dos botones:
Visualizar y Reconfigurar. El botn Visualizar permite realizar un refresco de la
pgina Gestin de Trfico. El botn Reconfigurar se utiliza para que los cambios
aplicados a algn servicio, red o condicin IP entren en efecto una vez hechos.
99/124
Figura 26: trfico instantneo
de un servicio
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Al realizar una reconfiguracin la interfaz toma los cambios de la base de datos,
reescribe los archivos de configuracin y le enva la orden de ejecutar los cambios
al daemon.
100/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.3. Clientes
Como se ve en la figura 27 esta pantalla permite dar de alta, baja y modificar
clientes con sus datos de direccin, cuit, apellido, nombre, email y telfono de
contacto.
Estos datos son opcionales, a los efectos del funcionamiento del controlador, pero
son de mucha utilidad para poder tener autocontenido dentro los datos necesarios
para contactar y gestionar clientes.
Adicionalmente es posible desde aqu visualizar si el cliente posee redes definidas
y con el enlace a las redes poder acceder a la prxima pantalla.
101/124
Figura 27: Altas, Bajas, Modificaciones de Clientes del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.4. Redes
Como puede verse en la figura 28 desde esta pantalla es posible dar de alta, baja o
modificar los datos las redes de un cliente, si se ha accedido a travs del enlace en
la pantalla Clientes, o de todas las redes si se ha accedido directamente a esta
pantalla.
Desde aqu tambin es posible crear nuevas redes seleccionando el cliente al que
pertenecen.
Al momento del alta de una red, aparte de la informacin CIDR, es necesario
consignar el ancho de banda mnimo y mximo que se le asignar a los servicios
por defecto de Upstream y Downstream.
Tambin es posible realizar una importacin de datos para definicin en lote de
102/124
Figura 28: Altas, Bajas, Modificaciones de Redes del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
muchas redes. Esto se logra seleccionando el cliente en la lista desplegable y
pegando una lista de redes en el campo Importar desde lista, con el siguiente
formato:
CIDR , Ancho de banda mnimo (en kbits), Ancho de Banda Mximo (en kbits).
Ejemplo de lista:
192.168.100.0/26,128,512
192.168.200.0/24,256,256
Esto dara de alta dos redes, una con un mnimo de 128 kbits y un mximo de
512kbits, y otra red con un mnimo y mximo de 256 kbits (enlace dedicado).
En la lista de redes creadas se consigna a la derecha los servicios que se
encuentran definidos para esa red en particular, como mnimo aparecern dos
servicios (default_up y default_down). Haciendo click sobre el enlace servicios es
posible acceder a los servicios definidos para esa red, como veremos en la
prxima pantalla.
103/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.5. Servicios
La figura 29 presenta la interfaz de alta, baja y modificacin de servicios.
Los servicios son la mnima unidad de gestin dentro del controlador, permiten
caracterizar flujos y afectarles parmetros de trfico (ancho de banda mnimo,
ancho de banda mximo y sentido: upstream y downstream).
Dado que el controlador implementa una disciplina de cola jerrquica desde este
lugar es posible crear servicios que son hijos de otros servicios.
Los servicios son las entidades a las que se les asigna parmetros de trfico, por
defecto al dar de alta una red se crean dos servicios por defecto que lo que hacen
es clasificar segn los datos de red (CIDR) los flujos de subida y bajada
asocindolos a las clases de trfico que realmente controlan el ancho de banda de
upstream y de downstream.
Internamente al realizar esta tarea lo que el controlador hace es crear una nueva
clase que depende de una clase root (esta clase posee el ancho de banda total del
104/124
Figura 29: Altas, Bajas, Modificaciones de Servicios del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
enlace que se est controlando) que est afectada a la interfaz de red que da hacia
la red interna (donde se crea la clase de downstream) y crea una nueva clase que
depende de la clase root que est afectada a la interfaz de red que da hacia la red
externa (donde se crea la clase de upstream).
Si bien el mecanismo antes expuesto describe el modo normal en que se opera el
controlador, es posible definirle a los servicios por defecto nuevos servicios que
dependan de ellos. Funcionalmente esto hace que el ancho de banda del servicio
por defecto sea compartido por los anchos de banda definidos a los servicios hijos.
Cuando se crean servicios hijos es necesario definir en el controlador las reglas
de clasificacin que harn que el trfico sea tratado por esos nuevos servicios
hijos. Para esto se utilizan las condiciones IP.
Las condiciones IP son reglas que son pasadas prcticamente sin modificacin a la
arquitectura de iptables para realizar una seleccin segn el amplio espectro de
clasificacin que posee esa herramienta. De esa manera es posible crear un
servicio hijo que posee multiples condiciones IP. Como ejemplo imaginemos que
una red tienen un servicio por defecto de downstream de 128 kbit de mnimo y
mximo y se le define un servicio hijo de 32kbits de mnimo y de mximo, y se
quiere que ese servicio hijo controle todo el trfico de HTTP y POP.
Para ello es posible definirle al servicio hijo dos condiciones IP:
Para clasificar el trfico de http (dado que es downstream) los paquetes
destinados al cliente llevarn puerto origen 80 y sern de protocolo tcp.
Para clasificar el trfico de smtp (dado que es downstream) los paquetes
destinados al cliente llevarn puerto origen 110 y sern de protocolo
tcp.
De esta manera el cliente tendr un servicio de downstream por defecto donde
todo el trfico de HTTP y POP no podr superar los 32kbits y el ancho de banda
restante ser utilizado por todos los otros flujos que no cumplen con las
condiciones IP definidas. La figura 30 muestra la configuracin de las dos
condiciones IP ejemplificadas.
105/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
106/124
Figura 30: Altas, Bajas, Modificaciones de Condiciones IP del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.6. Eventos
La figura 31 presenta la interfaz que permite el alta, baja y modificacin de los
eventos del controlador de ancho de banda.
El objetivo de un evento es poder modificar los parmetros de trfico de un
servicio (o todos), en base a una temporizacin que tiene una unidad mnima de
un minuto.
El concepto subyacente apunta a poder crear una curva en funcin del tiempo
que permita definir diferentes parmetros de trfico a un servicio (o a todos). Esto
es posible lograrlo ya que una sucesin de eventos permite definir los puntos de
esta curva.
Los eventos se asocian a un servicio y permiten aplicarle una frmula al valor del
107/124
Figura 31: Altas, Bajas, Modificaciones de Eventos del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
trfico asignado. Por ejemplo es posible generar un evento que duplique el ancho
de banda de un servicio colocando un : * 2 , en el campo frmula.
La temporizacin se realiza colocando los parmetros de tiempo en un formato
equivalente al de cron de Unix.
108/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.7. Backup
La figura 32 muestra la interfaz de administracin de la base de datos del
controlador de ancho de banda que presenta un formulario con opciones para
realizar tareas sobre la base y tambin una tabla que presenta todas las tablas que
componen la base de datos con su cantidad de registros.
Esta interfaz permite realizar un volcado (dump) de toda la base de datos,
seleccionando un rango de fechas, ya sea en el disco del controlador o envindola
a travs del navegador para que pueda ser almacenada en la mquina desde donde
se est accediendo.
La base de datos del generalmente tiene su mayor crecimiento en la tabla que
almacena las muestras de trfico de cada servicio (cada 5 minutos), es por esto
109/124
Figura 32: Backup de Base de Datos del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
que esta interfaz tambin permite realizar una limpieza de esta tabla seleccionando
un rango de fechas. Es posible contar cuantos registros posee la tabla de
estadsticas antes de limpiarla o realizar un volcado de la misma.
110/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.8. Parmetros
La figura 33 muestra la interfaz que permite administrar los parmetros del
controlador de ancho de banda.
El objetivo de los parmetros es poder modificar valores generales de
configuracin que el controlador utiliza. Por ejemplo es necesario poder
configurar cual es el ancho de banda total disponible, cual es la interfaz de red que
se encuentra conectada al enlace de Upstream y cual es la interfaz que se
encuentra conectada a la red a controlar.
Para darle un mejor grado de administracin se decidi almacenar esta
informacin en la base de datos y concentrar toda la administracin de parmetros
de configuracin en un solo punto. Si bien todos los parmetros quedan
111/124
Figura 33: Altas, Bajas, Modificaciones de Parmetros del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
almacenados en la base de datos, el demonio sheiper-server necesita de algunos de
estos parmetros para poder iniciar y realizar sus tareas. Es por esto que este
daemon posee un archivo de configuracin (/usr/local/sheiper/etc/sheiper.conf)
que es generado desde la interfaz Web, tomando valores de los parmetros.
Los parmetros son manejados por una clase que genera un arreglo asociativo y lo
mantiene en memoria disponible para cualquier parte de la interfaz web que
requiera acceso a los mismos.
Para darle una lgica y mejor administracin los parmetros son agrupados bajo el
campo grupo en funcin de su tarea.
A continuacin se muestra la tabla de parmetros de configuracin del controlador
con su correspondiente uso:
Nombre Valor Grupo Uso
bwtotaldown 2000000 bwcontrol
Define el ancho de banda total
disponible para asignar a servicios de
downstream. Se recomienda el valor
real del enlace a controlar menos un 5%.
bwtotalup 2000000 bwcontrol
Define el ancho de banda total
disponible para asignar a servicios de
Upstream. Se recomienda el valor real
del enlace a controlar menos un 5%.
confpath /etc/sysconfig/htb/ bwcontrol
Define el directorio donde se grabarn
los archivos de configuraci!n de htb "ue
genera la interfa# de administraci!n.
down eth$ bwcontrol
Define cual es el dispositivo de la
interfa# "ue se encuentra conectada al
enlace de downstream.
%&U $500 bwcontrol
Define el tama'o de la %&U del enlace
de Upstream.
(2) * bwcontrol +ste es el valor de r2" de htb.
tbcacheservd
own
cacheserviciodown bwcontrol
Define el nombre de la tabla de
intercambio "ue se utili#a para generar
la informaci!n "ue termina grabndose
en los archivos de configuraci!n de htb
para los servicios de downstream.
tbcacheservu
p
cacheservicioup bwcontrol
Define el nombre de la tabla de
intercambio "ue se utili#a para generar
la informaci!n "ue termina grabndose
en los archivos de configuraci!n de htb
para los servicios de upstream.
up eth0 bwcontrol
Define cual es el dispositivo de la
interfa# "ue se encuentra conectada al
enlace de Upstream.
112/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
host localhost daemon
Define el host o ,- de la m"uina donde
est corriendo el daemon sheiper.server.
port /000 daemon
Define el port donde est atendiendo el
daemon sheiper.server.
1(-,23 2 netconf
Define la cantidad de pa"uetes de
arping "ue se utili#aran cuando el
controlador realice un arping.
D421% sheiperng netconf
Define el nombre de la base de datos del
controlador de ancho de banda.
D4-1S canilla netconf
Define el password del usuario con el
"ue debe conectarse a la base de datos.
D4&14 stats netconf
Define cual es el nombre de la tabla de
estad5sticas de trfico del controlador.
D4US( sheiper netconf
Define el nombre del usuario de la base
de datos.
36-U4 200.0$.$50.57 netconf Define la ,- del 36 por default.
,8-(, eth$ netconf
Define cual es el dispositivo de la
interfa# "ue da a la red a controlar. Se
utili#a a los efectos de las rutas a
m"uinas "ue estn detrs del
controlador.
,8-U4 eth0 netconf
Define cual es el dispositivo de la
interfa# "ue da a la red del enlace de
upstream. Se utili#a a los efectos de
ruteo.
,--(, $/2.$09.$.$/72 netconf
Define cual es la ,- "ue presenta el
controlador hacia la red del enlace de
downstream.
,--U4 200.0$.$50.5*/70 netconf
Define cual es la ,- "ue presenta el
controlador hacia la red del enlace de
Upstream.
loginfail inde:.php web
Define cual es el script al "ue la interfa#
enviar al usuario "ue falle en el nombre
o password de login. &ambi;n se utili#a
como el nombre del script "ue utili#a la
interfa# cuando el usuario reali#a un
logout.
logino< sheiper.php web
Define cual es el script al "ue la interfa#
enviar al usuario "ue realice un login
correcto.
113/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.9. Usuarios
La figura 34 presenta la interfaz de administracin de usuarios del controlador de
ancho de banda.
El controlador maneja un modelo de usuarios que posee dos roles:
administrador que tiene permisos para realizar cualquier tarea y consulta que
permite acceder a Gestin de Trfico en modo lectura sin posibilidad de acceder
al dump de red.
La idea es que se pueda dar acceso al controlador a ciertos operadores para poder
monitorear los clientes pero que no se pueda realizar modificaciones sobre los
mismos.
Al realizar el alta de un usuario debe colocarse el nombre de usuario, la
114/124
Figura 34: Altas, Bajas, Modificaciones de Usuarios del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
contrasea que utilizar, el rol y es posible asignar una IP desde la cual este
usuario podr acceder al controlador (en notacin CIDR, ejemplo:
200.32.111.1/32). Si se quiere dar acceso al controlador a un usuario desde
cualquier direccin IP puede colocarse 0.0.0.0/0 o % que es equivalente.
115/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.6.10. Controlador
La figura 35 muestra la interfaz que permite realizar tareas de gestin del servicio
de control de ancho de banda, consulta de las estadsticas crudas, estado del
controlador y tareas de gestin de red y configuracin del controlador.
El botn Apagar apaga el control de ancho de banda liberando el trfico que
atraviesa el controlador.
El botn Prender enciende el control de ancho de banda.
El botn Versin informa la versin del daemon sheiper-server.
El botn Status informa si el control de ancho de banda est encendido o
apagado.
La lista desplegable {up | down} y el botn Estadsticas permite visualizar las
116/124
Figura 35: Gestin del servicio y red del Controlador de Ancho de Banda
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
estadsticas crudas de las clases de trfico de upstream o downstream.
La ltima lista desplegable y el botn Netconf permiten realizar tareas de gestin
del archivo de configuracin y de la red. A continuacin se presenta una lista de
las tareas posibles:
Opcin Uso
(econf. (ed +sta opci!n toma los parmetros de la base de datos y genera el archivo
de configuraci!n del controlador =/usr/local/sheiper/etc/sheiper.conf>.
+sta opci!n es necesario utili#arla cuando se reali#an cambios sobre
parmetros "ue necesita el daemon sheiper.server para traba?ar.
1paga (ed +sta opci!n apaga las funciones de red@ interrumpiendo todo el trfico
"ue atraviesa el controlador. +sta opci!n se recomienda utili#arla solo
desde la consola del controlador.
+nciende (ed +sta opci!n enciende las funciones de red del controlador. Solo es
posible reali#arla desde la consola del controlador.
(einicia (ed (eali#a un 1paga (ed y un +nciende (ed.
1grega (uta +sta opci!n permite agregar una ruta a una red o m"uina "ue se
encuentra en la red conectada al enlace de downstream. +sta operaci!n
tiene un efecto inmediato y adicionalmente almacena la ruta como un
parmetro.
4orra (uta +sta opci!n permite eliminar una ruta de los parmetros del controlador
y "uita la ruta del controlador. &iene un efecto inmediato.
Aista (uta +sta opci!n lista las rutas definidas en el controlador.
117/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
7.7. Casos de Aplicacin
Como se explic anteriormente el presente desarrollo inicialmente fue
motivado por los requerimientos concretos de una empresa proveedora de
servicios de Internet de la ciudad de Mendoza (ITC S.A.). Posteriormente se
implement el mismo controlador en la Universidad de Mendoza y en otras
empresas proveedoras de servicio de acceso a Internet.
A continuacin se comentan los resultados y experiencias obtenidas de cada
implementacin.
7.7.1. ITC S.A.
ITC S.A. es una empresa con ms de 15 aos de experiencia en la provisin de
servicios de Telecomunicaciones en la ciudad de Mendoza.
La empresa posee una red MAN (Metropolitan Area Network) de fibra ptica
basada en tecnologa Ethernet de 100 Mbit (actualmente posee troncales de
Gigabit Ethernet) llegando al usuario final con ethernet de 10Mbit como mnimo
(ltima milla).
Si bien la empresa comenz brindando servicio de conectividad dentro de su
MAN, orient gran parte de sus recursos a dar servicio de acceso a Internet.
Inicialmente cada abonado tena su conexin Ethernet y todos accedan libremente
a Internet compitiendo por el ancho de banda disponible (originalmente 1 Mbit de
Internet).
Cuando la empresa decidi realizar una comercializacin masiva del servicio de
Internet se encontr con el obstculo de poder controlar el ancho de banda de los
usuarios para poder implementar una linea de productos con ancho de banda
diferentes.
Despus de evaluar alternativas propietarias de cajas tomaron contacto con la
empresa en la que trabajo (Silice S.A.) y nos realizaron los requerimientos del
controlador especificado en este trabajo.
En ese momento la empresa ya contaba con un enlace a Internet de 5 Mbit y la
alternativa al controlador de ancho de banda aqu especificado era la adquisicin
de hardware especfico que era incosteable por la empresa.
Una vez desarrollado el controlador se instal sobre una PC Pentium III con
118/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
procesador de 500 Mhz, 256 Mbytes de RAM y disco rgido de 20 Gbytes.
El equipo inmediatamente permiti modelar servicios de acceso tipo banda ancha
con ancho de banda mnimo garantizado y a su vez enlaces dedicados.
El rendimiento del equipo fue ptimo para las necesidades de la compaa, lo que
motivo la migracin de todo el ncleo de la red a servidores basados en sistema
operativo Linux.
Inicialmenente la compaa posea un enlace de 5 Mbit con un proveedor
mayorista de Internet, en el lapso de un ao y medio pas a tener tres
proveedores mayoristas de Internet (cada uno con su correspondiente controlador
de ancho de banda) y en la actualidad cada controlador (sobre otro hardware,
servidores IBM Pentium IV) maneja 22 Mbits de Internet, con aproximadamente
350 clientes por controlador. Los motores de base de datos de los controladores
manejan informacin de estadsticas de trfico sobre tablas que llegan a los 30
millones de registros.
7.7.2. Universidad de Mendoza
La situacin de la Universidad de Mendoza era diferente a la de un proveedor de
servicios de acceso a Internet y es por este motivo que es importante comentarla.
La Universidad posee un enlace de Internet de 1 Mbit, si bien los servicios de
acceso a Internet estn controlador por ciertas polticas, la mayora de los usuarios
tena acceso de navegacin.
Bajo estas condiciones si un solo usuario de la Universidad lograba contactar
contra un sitio con un buen ancho de banda para hacer un download (por Ej: 1
Mbit o ms), poda monopolizar todo el enlace y hacer que la percepcin de
servicio de todos los dems usuarios fuera realmente mala.
Adicionalmente se adicion un equipo de videoconferencia con soporte de IP.
Este equipo permite realizar videoconferencias sobre Internet (si bien no es el
medio ms recomendado), pero requiere cierta garanta de ancho de banda
mnimo como para poder operar, para poder garantizar esto, sin tener un
controlador de ancho de banda, lo que habra que hacer es desconectar a toda la
Universidad del enlace y conectar el equipo al momento de realizar una
videoconferencia IP.
119/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Fue por esto que se decidi implementar el controlador y asignar ancho de banda
a diferentes subnets del rango de la red interna (una red /24, 192.168.1.0/24),
permitiendo que todos los usuarios de las subnets (generalmente relacionados a
una misma unidad organizativa o facultad) tuvieran un mnimo garantizado y
tambin se aplicaron reglas de control de trfico para puestos de trabajo
especficos ( 192.168.1.x /32).
A parte de poder garantizar estos mnimos a los usuarios el controlador permiti
que al momento de realizar videoconferencias, todo el ancho de banda de la
Universidad se disminuyera a 784 Kbit, asignndole este ancho de banda a la
configuracin de enlace del controlador, y conectando el equipo de
videoconferencia a la zona pblica de Internet de la Universidad.
120/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
8. Conclusiones
Desde el punto de vista de las funcionalidades podemos concluir que el
controlador, y en particular Linux como sistema operativo, posee avanzadas
capacidades para la implementacin de mecanismos de control de ancho de banda.
Si bien este trabajo demostr la implementacin de un controlador de borde, el
sistema operativo posee todas las capacidades para implementar completamente
QoS extremo a extremo.
Como software el controlador posee una arquitectura robusta y ha
demostrado una performance sobresaliente al punto de encontrarse funcionando
sobre enlaces de 22 Mbits de Internet, controlando ms de 500 clientes con una
altsima disponibilidad equivalente a cajas de hardware especfico.
Como relacin costo/beneficio el controlador permite que la organizacin
que lo implemente tenga un ahorro significativo en equipamiento y en costo de
propiedad total, ya que se lo puede ejecutar en hardware convencional de PC.
Como direccin futura, si bien no sera acorde a estndares, se podra
extender este desarrollo para implementar controladores distribuidos en todos los
puntos de la red de un proveedor de servicios para construir un modelo de QoS
extremo a extremo.
121/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Bibliografa
QOSIPNW: Grenville Armitage, Quality Of Service In IP Networks,
2000,Oreilly.
DACOMCOM: William Stallings, Data and Computer Communications,
1997,Prentice Hall.
RFC2205: Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification ,,http://www.ietf.org/rfc/rfc2205.txt
EEQOSND: Tim Szigeti, Christina Hattingh, End-to-End QoS Network Design,
Noviembre 09, 2004,Cisco Press.
RFC1633: , Integrated Services in the Internet Architecture, ,
http://www.ietf.org/rfc/rfc1633.txt
RFC2212: Specification of Guaranteed Quality of Service ,,
http://www.ietf.org/rfc/rfc2212.txt
RFC2211: Specification of the Controlled-Load Network Element Service ,,
http://www.ietf.org/rfc/2211.txt
RFC2474: Definition of the Differentiated Services Field ,,
http://www.ietf.org/rtf/rfc2474.txt
RFC3246: An Expedited Forwarding PHB ,,http://www.ietf.org/rfc/rfc3246.txt
RFC2597: Assured Forwarding PHB Group ,,http://www.ietf.org/rfc/rfc2597.txt
LNTCIO: Werner Almesberger, Linux Network Traffic Control - Implementation
Overview, Febrero 4, 2001.
TFCOHT: Traffic Control HOWTO ,Martin A. Brown,http://linux-
ip.net/articles/Traffic-Control-HOWTO/index.html
COMNET: Andrew S. Tanenbaum, Computer Networks 4th Edition,
2003,Pearson.
APGTLTC: A Practical Guide to Linux Traffic Control ,Jason
Boxman,http://www.trekweb.com/~jasonb/articles/traffic_shaping/index.html
HTBLUG: HTB Linux queuing discipline manual - user guide ,Martin
Devera,http://luxik.cdi.cz/~devik/qos/htb/
122/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
ndice de Figuras
Figura 1: Router Genrico [QOSIPNW] 34
Figura 2: Arquitectura de un router con CQS [QOSIPNW] 36
Figura 3: Evolucin de QoS [EEQOSND] 39
Figura 4: IntServ y DiffServ [EEQOSND] 40
Figura 5: Ncleo simplificado de un motor de reenvo LSR [QOSIPNW] 47
Figura 6: Procesamiento de datos de la Red [LNTCIO] 49
Figura 7: Disciplina de cola simple sin clases [LNTCIO] 50
Figura 8: Disciplina de cola simple con mltiples clases [LNTCIO] 51
Figura 9: Combinacin de disciplinas de cola Prioridad, TBF y FIFO [LNTCIO]
51
Figura 10: Relacin de los elementos de la arquitectura de IntServ y DiffServ con
el control de trfico del kernel de Linux [LNTCIO] 53
Figura 11: Disciplina de cola pfifo_fast [TFCOHT] 59
Figura 12: Disciplina de cola TBF [TFCOHT] 60
Figura 13: Disciplina de Cola SFQ [TFCOHT] 62
Figura 14: Disciplina de Cola DSMARK [APGTLTC] 66
Figura 15: HTB Servicios a Controlar [HTBLUG] 68
Figura 16: HTB - Comportamiento del trfico [HTBLUG] 71
Figura 17: HTB Servicios a Controlar con Jerarqua [HTBLUG] 73
Figura 18: Comportamiento del trfico jerrquico [HTBLUG] 74
Figura 19: Comportamiento del trfico jerrquico con cambio en burst y cburst de
[HTBLUG] 77
Figura 20: Comportamiento del trfico jerrquico con cambio en las prioridades
de [HTBLUG] 78
Figura 21: Comportamiento del trfico jerrquico con cambio en las prioridades a
los 3 segundos de [HTBLUG] 80
Figura 22: Esquema de Arquitectura del Controlador de Ancho de Banda 83
Figura 23: Modelo de Datos del Controlador de Ancho de Banda 92
Figura 24: Login del Controlador de Ancho de Banda 97
Figura 25: Pantalla de Gestin de Trfico del Controlador de Ancho de Banda 98
Figura 26: trfico instantneo de un servicio 99
Figura 27: Altas, Bajas, Modificaciones de Clientes del Controlador de Ancho de
123/124
Diego F. Navarro Tesis de Maestra: Controlador de Ancho de Banda
Banda 101
Figura 28: Altas, Bajas, Modificaciones de Redes del Controlador de Ancho de
Banda 102
Figura 29: Altas, Bajas, Modificaciones de Servicios del Controlador de Ancho
de Banda 104
Figura 30: Altas, Bajas, Modificaciones de Condiciones IP del Controlador de
Ancho de Banda 106
Figura 31: Altas, Bajas, Modificaciones de Eventos del Controlador de Ancho de
Banda 107
Figura 32: Backup de Base de Datos del Controlador de Ancho de Banda 109
Figura 33: Altas, Bajas, Modificaciones de Parmetros del Controlador de Ancho
de Banda 111
Figura 34: Altas, Bajas, Modificaciones de Usuarios del Controlador de Ancho de
Banda 114
Figura 35: Gestin del servicio y red del Controlador de Ancho de Banda 116
124/124

You might also like