UNIVERSIDAD AUTÓNOMA “GABRIEL RENE MORENO”

INGENIERIA EN SISTEMAS

ARQUITECTURA DE LOS
SISTEMAS PARA BRINDAR QoS.
RESUMEN -CUESTIONARIO

DOCENTE : ING. NOLBERTO ZABALA

MATERIA : REDES II
ESTUDIANTES : IBLIN MAITHE VARGAS MOSCOSO
REGISTRO : 215100239

FECHA : 08/06/2022

MONTERO-SANTA CRUZ-BOLIVIA
2022
 RESUMEN
Aplicar QoS a la gestión de procesos plantea satisfacer una serie de garantías para cumplir con las
expectativas en la ejecución de las aplicaciones. En los sistemas Linux, el tratamiento de la QoS en
las aplicaciones esta diferenciado por su tipo. Así una aplicación de tiempo real (TR) consta de un
tratamiento privilegiado respecto a una aplicación tradicional. Esto se traduce en una mayor
priorización y disponibilidad de recursos para satisfacer las demandas de las aplicaciones de TR.
En cuánto a las aplicaciones tradicionales no se han incorporado mayores mecanismos para brindar
garantías de QoS a las mismas. Por eso se presenta un estudio que busca identificar y analizar los
requerimientos de QoS desde un enfoque aspectual. El estudio plantea una serie de escenarios, los
cuales definen casos de uso basados en aspectos sobre los requerimientos de QoS para aplicaciones
tradicionales Linux. Se describen conceptos sobre los requerimientos de QoS y su posterior
modelado con aspectos, tal que la tarea de cumplimentar los requerimientos de QoS en programas
existentes sea mucho más simple y flexible. Además se describen algunos aspectos de la aplicación
de la QoS en sistemas paralelos, en distribuidos y en sistemas en red. En resumen el presente
trabajo estudia conceptos básicos de calidad de servicio y algunos de sus marcos de aplicación
siguiendo un enfoque aspectual. Planteando posibles casos de uso genéricos para aplicar mejoras en
la prestación de la QoS mediante aspectos en la planificación y gestión de recursos de aplicaciones
tradicionales. Los sistemas operativos basados en el Kernel Linux son de interés por la posibilidad
de configurar y personalizar su comportamiento. El planificador de procesos Linux reconoce dos
clases de tareas: tareas de tiempo real y tareas comunes. Las tareas se diferencian por el tratamiento
que reciben, así una aplicación de tiempo real (TR) consta de un tratamiento privilegiado respecto a
una aplicación del tipo tradicional. Esto se traduce en una mayor priorización y disponibilidad de
recursos para las aplicaciones de TR. En cuanto a las aplicaciones tradicionales no se han
incorporado mayores mecanismos para brindar garantías de QoS a las mismas. Cumplir con las
expectativas en la ejecución de las aplicaciones plantea satisfacer una serie de garantías para QoS.
Proporcionar tales garantías de QoS en el contexto de un sistema operativo de propósito general
multiprogramado es factible. Un camino posible es modificar el código base de las aplicaciones
para que implementen los mecanismos para proporcionar QoS. Tal modificación no es sencilla y
tiene consecuencias no deseadas como la invasión de código para el manejo de QoS en el código
base de la aplicación. Esto último, genera problemas de mantenibilidad, reuso y flexibilidad en el
código de la misma. Por eso se presenta un estudio que busca identificar y analizar los
requerimientos de QoS desde un enfoque aspectual. Cuyo objetivo es proporcionar garantías de
QoS para alcanzar los niveles de rendimiento deseados en el contexto de un sistema operativo de
propósito general multiprogramado.El enfoque aspectual provee una alternativa para realizar los
cambios necesarios sin requerir la reescritura sustancial del código. Además, el enfoque aspectual
tiene como ventaja el poder introducir nuevos comportamientos al código original sin necesidad de
modificar su estructura base y sobre todo evitando mezclar funciones adicionales con el objetivo
del programa. De esta manera se mantienen encapsuladas las funciones que no conforman la
funcionalidad principal del sistema o lógica de negocio; conocidas como crosscutting concerns
(Jackson A. y otros, 2009)(Schauerhuber A. y otros, 2006). Previendo así las dificultades de
mantenibilidad, reuso y flexibilidad por reescritura y/o modificación de código. Para poder
dimensionar las garantías de QoS necesarias, en la primera Sección se explican conceptos
relacionados a la QoS y garantías típicas sobre las mismas. El comportamiento de las garantías de
QoS en un sistema influyen en su efectividad y rendimiento. Por lo que en la misma Sección se
analizan métricas en relación a las garantías de QoS. Esta obra está bajo una Licencia Creative
Commons Atribución-NoComercial-SinDerivar 4.0 Internacional.
77 ICT-UNPA-149-2016 ISSN: 1852-4516 Aprobado por Resolución N° 0875/16-R-UNPA En
vista al desarrollo de un Framework que aporte garantías de QoS en la plataforma Linux en la
Sección2, se analiza un sistema operativo basado en ese Kernel para enumerar los mecanismos
existentes para implementar la planificación y gestión de recursos. Además se describe conceptos
de QoS en la planificación aplicada a servicios, Grid y Cloud. Para comprender las principales
características de la Programación Orientada a Aspectos (AOP) y su posible utilización en el
modelado de requerimientos de QoS en una aplicación, la Sección 3 aborda conceptos básicos de
ese enfoque.
La Sección 4 plantea una serie de casos de uso con escenarios genéricos sobre los cuáles aplicar
las garantías de QoS utilizando un enfoque aspectual en el contexto de un sistema operativo de
propósito general multiprogramado. Los casos de uso se centran en garantizar los requerimientos
de QoS durante la ejecución de los procesos y usar el enfoque aspectual para introducir las
modificaciones requeridas. Los casos de uso planteados utilizan aspectos y abarcan diferentes
condiciones de ejecución de procesos.
1.1 La Calidad de Servicio (QoS) En este apartado se estudiará el concepto de calidad de servicio
(QoS), sus características y alcances, las condiciones para lograr una buena implementación en un
sistema paralelo y/o distribuido. Además se definen conceptos relacionados a las garantías de
calidad como las métricas para QoS en distintos entornos.
Desde el punto de vista del usuario, se dice que la percepción de QoS en general esta asociada a los
requerimientos que se deben satisfacer para cumplir con las expectativas sobre la ejecución de las
aplicaciones (Xiao X., 2008), servicios y redes. En otras palabras la incorporación de QoS se
realiza para obtener una percepción satisfactoria de aplicaciones, servicio o redes.
Una definición viable para la QoS en principio debería hacer distinción entre aquella que es
aplicada al ámbito de las comunicaciones para integrar componentes y/o servicios sobre una red, y
aquella que es aplicada sobre la gestión de recursos (Hyden E.A., 1994).
En el ámbito de las redes de comunicación LAN y WAN la QoS esta asociada al manejo apropiado
del tráfico de red, tal que se garantice la entrega de los paquetes de datos oportunamente.
En ese sentido las redes de ordenadores están empezando a ofrecer garantías de calidad de servicio
con respecto al retardo de paquetes y el ancho de banda de conexión. Estas garantías de QoS son de
poca utilidad si no pueden extenderse a las aplicaciones que se ejecutan en los puntos finales
(Bruno J. et al., 1998). Por otro lado, dentro del modelo de calidad de servicios basado en
asignación de recursos, la QoS aparece en formas diferentes como parte de las interfaces entre las
capas de un sistema.
En la interfaz entre una aplicación y el sistema operativo, el sistema se ve como un proveedor de
servicios y la aplicación se considera como un cliente del servicio. La aplicación puede entonces
solicitar una determinada QoS al sistema operativo (Hyden E.A., 1994). En otras palabras, el
sistema operativo debe tener la capacidad de suministrar recursos del sistema a las solicitudes de
manera que se logren los niveles deseados de rendimiento de forma predecible, por ejemplo para
múltiples aplicaciones multimedia (Bruno J. et al., 1998). En términos generales los recursos
(memoria caché, memoria, tiempo de procesamiento, dispositivos de entrada y/o salida, bufferes)
disponibles del host y su uso eficiente determinan Esta obra está bajo una Licencia Creative
Commons Atribución-NoComercial-SinDerivar 4.0 Internacional.78 ICT-UNPA-149-2016 ISSN:
1852-4516
Aprobado por Resolución N° 0875/16-R-UNPA el éxito al cumplir los requerimientos de los
procesos que demandan un cierto nivel de QoS. Los sistemas operativos con multiprogramación de
procesos en general no ofrecen garantías de calidad de servicio ya que el rendimiento de una sola
aplicación es, en parte, determinada por la carga total en el sistema (Bruno J. et al., 1998). Los
sistemas operativos en tiempo real son capaces de entregar garantías de rendimiento, tales como
demoras límite, pero requieren que las aplicaciones se puedan modificar para aprovechar el tiempo
real (Bruno J. et al., 1998). Algunos enfoques existentes orientados a la aplicación tratan de
mantener información sobre las demandas de la aplicación y realizar la reserva de recursos en el
sistema final basada en el cálculo detrás de la necesidad (Bechler M., Ritter H., 2001)(Nahrstedt K.
et al., 1998) (Wolf L. C., Steinmetz R., 1997).
La aplicación del enfoque por asignación de los recursos puede estar estrictamente orientada al
usuario. Donde el uso compartido de los recursos en el sistema final y el sesgo de la distribución de
los mismos se debe hacer en favor de las aplicaciones en las cuáles el usuario se centra actualmente
(Bechler M., Ritter H., 2001). Al considerar como las aplicaciones manejan los recursos
disponibles, es posible diferenciar a las aplicaciones adaptativas que tratan de adaptarse a la
situación actual, pero no pueden controlar activamente los recursos y las aplicaciones proactivas
que participan activamente sobre el efecto de la distribución de los recursos por adelantado
(Bechler M., Ritter H., 2001). Las plataformas con chip multiprocesador (CMP) son capaces de
manejar múltiples hilos de ejecución sobre los núcleos, proveen una forma de incrementar la carga
de trabajo simultáneo. La Figura 1 muestra los posibles escenarios en plataformas CMP, bajo
multiprogramación, virtualización o arquitecturas heterogéneas. La introducción de la
virtualización permite consolidar la carga de trabajo sobre una misma plataforma, además permite
controlar el número de núcleos asignados a cada carga de trabajo. Aunque el soporte de hardware o
software de hoy en día para controlar la asignación de recursos de la plataforma, tales como
espacio de caché y ancho de banda de memoria para las cargas de trabajo individuales no están
garantizado (Iyer R. et al., 2007). La priorización de los diferentes recursos del sistema puede ser
crítica a la hora de hablar de gestión eficiente. Dada las condiciones del sistema, establecer
prioridades a la hora de asignar recursos garantizaría cumplir con las metas de QoS, siendo factible
una distribución no equitativa asumiendo un detrimento de otros procesos en vista de mejorar el
desempeño de la aplicación y/o sistema global (Iyer R. et al., 2007). La definición de las políticas
de calidad de servicio varía en términos de los objetivos para cumplir con las condiciones
necesarias de los requerimientos de QoS de la aplicación.

Los requerimientos de QoS necesarios para aplicaciones IP están descriptos por La International
Telecommunication Union (ITU), fijando objetivos de rendimiento para redes con aplicaciones
comunes IP (Xiao X., 2008). En la Tabla 1 se describen las métricas comúnmente aplicadas para
QoS. Aplicación QoS Métricas Permite medir Entorno de planificación compartido Retraso limite
Equidad Servicio Acumulativo Efectividad y rendimiento Reserva de recursos para garantía de
velocidad de procesamiento Basada en prioridades RUM RPM OPM Grado eficacia de una política
de planificación En cluster, Grid o cloud Capacidad Grado de demanda de recursos a satisfacer En
Redes Retardo o latencia Variación Rendimiento Tasa de pérdida de paquetes Grado de
funcionamiento de la red Tabla 1: Métricas aplicables en QoS La evaluación cuantitativa de
métricas que poseen una interrelación para múltiples requerimientos de QoS puede ser difícil
(Hoffert J. et al., 2010). En parte debido a las fluctuaciones que introducen los entornos dinámicos
sobre los cuáles se ejecutan las aplicaciones.
Qué es la calidad de servicio (QoS)
A. QoS se refiere a la capacidad de una red para ofrecer un mejor servicio a un tráfico de red
seleccionado a través de varias tecnologías subyacentes, entre ellas, Frame Relay, modo de
transferencia asíncrona (ATM, asynchronous transfer mode), Ethernet y redes 802.1X, SONET y
redes con routing IP.
Calidad de servicio (QoS) es un conjunto de tecnologías que permite que las aplicaciones soliciten
y reciban niveles de servicio predecibles en términos de la capacidad de rendimiento de datos
(ancho de banda), variaciones de latencia (fluctuación) y retraso. En particular, las funciones de
QoS ofrecen un servicio de red mejor y más previsible a través de los siguientes métodos:
 Admite un ancho de banda dedicado.

 Mejora de las características de pérdida.

 Cómo evitar y administrar la congestión de la red.

 Define el tráfico de red.

 Configuración de prioridades de tráfico en la red.

El Grupo de trabajo en ingeniería de Internet (IETF) define las dos arquitecturas siguientes para
QoS:
 Servicios integrados (IntServ)

 Servicios diferenciados (DiffServ)

IntServ utiliza el protocolo de reserva del recurso (RSVP) para señalizar expresamente las
necesidades de QoS del tráfico de una aplicación en todos los dispositivos de un trayecto extremo a
extremo a través de la red. Si cada dispositivo de la red junto con el trayecto puede reservar el
ancho de banda necesario, la aplicación que se origina puede comenzar la transmisión. La petición
de comentarios (RFC) 2205 define el RSVP, y la RFC 1633 define el IntServ.
DiffServ se centra en el agregado y el aprovisionamiento de QoS. En lugar de señalizar los
requisitos de QoS de una aplicación, DiffServ utiliza un Punto de código de servicios diferencias
(DSCP) en el encabezado IP para indicar los niveles de QoS requeridos. La versión 12.1(5)T de
software del IOS® de Cisco introdujo el cumplimiento DiffServ en los routers de Cisco. Si desea
más información, consulte los siguientes documentos:
 Servicio integrado en la versión 12.1 del IOS de Cisco
 Implementación de DiffServ para calidad de servicio de extremo a extremo
 Implementación de políticas de calidad del servicio (QoS) con DSCP
 CUESTIONARIO
Introducción
Este documento responde a las preguntas más frecuentes de Servicio (QoS).

1P. El objetivo de los sistemas para brindar (qos) es

entender la arquitectura y los conceptos de las técnicas y procedimientos para brindar qos.
F V
2P. ¿A que parámetros nos referimos con decir recursos de red?
a) Ancho de banda. Parición de retraso o jitter. Retraso temporal o delay. Pérdida de paquete o
fiabilidad.
b) Servicios integrados (IntServ) Servicios diferenciados (DiffServ)
c) Servicio integrado en la versión 12.1 del IOS de Cisco Implementación de DiffServ para calidad
de servicio de extremo a extremo

3P. DiffServ utiliza el protocolo de reserva del recurso (RSVP) para señalizar expresamente
las necesidades de QoS del tráfico de una aplicación en todos los dispositivos de un trayecto
extremo a extremo a través de la red. Si cada dispositivo de la red junto con el trayecto puede
reservar el ancho de banda necesario, la aplicación que se origina puede comenzar la
transmisión.
F V
4P. DiffServ se centra en el agregado y el aprovisionamiento de QoS. En lugar de señalizar
los requisitos de QoS de una aplicación, DiffServ utiliza un Punto de código de servicios
diferencias (DSCP) en el encabezado IP para indicar los niveles de QoS requeridos.
F V
5P. IntServ utiliza el protocolo de reserva del recurso (RSVP) para señalizar expresamente
las necesidades de QoS del tráfico de una aplicación en todos los dispositivos de un trayecto
extremo a extremo a través de la red. Si cada dispositivo de la red junto con el trayecto puede
reservar el ancho de banda necesario, la aplicación que se origina puede comenzar la
transmisión.
F V
6P. ¿Qué significa congestión, retardo y fluctuación?
A. Una interfaz experimenta congestión cuando tiene más tráfico del que puede gestionar. Los
puntos de congestión de red son candidatos fuertes para los mecanismos de Calidad de Servicio
(QoS). A continuación, un ejemplo de los puntos de congestión más comunes:
La congestión de red resulta en retardo. Una red y sus dispositivos introducen varios tipos de
retrasos, como se explica en Conocimientos sobre el retraso en redes de paquetes de voz. La
variación en el retardo se conoce como fluctuación, según se explica en Comprensión de la
fluctuación en redes de voz en paquetes (plataformas de Cisco IOS). Es necesario controlar y
minimizar tanto la demora como las fluctuaciones para admitir el tráfico en tiempo real e
interactivo.

7P. ¿Qué es MQC?

A. MQC significa interfaz de línea de comando (CLI) de calidad de servicio (QoS) modular. Está
diseñado para simplificar la configuración de QoS en los routers y switches de Cisco, mediante la
definición de una sintaxis de comandos y un conjunto final de comportamientos de QoS en común
entre las plataformas. Este modelo reemplaza al modelo anterior por el cual se definía una sintaxis
única para cada función de calidad de servicio (QoS) y para cada plataforma.
El MQC comprende los tres pasos siguientes:
1. Definir una clase de tráfico ejecutando el comando class-map.
2. Cree una política de tráfico asociando la clase de tráfico con una o más funciones de
calidad de servicio (QoS) al ejecutar el comando policy-map.
3. Adjuntar la directiva del tráfico a la interfaz, subinterfaz o circuito virtual (VC)
ejecutando el comando service-policy.
Nota: Se implementan las funciones de condicionamiento del tráfico de DiffServ, como marcado y
modelado, mediante la sintaxis MQC.
Para obtener más información, consulte Interfaz de línea de comando de calidad del servicio
modular.

8P. ¿Qué significa que la política de servicio sólo es compatible en las interfaces VIP con el
mensaje de DCEF habilitado?
A. En procesadores de interfaz versátil (VIP) de la serie 7500 de Cisco, solo se admiten funciones
de Calidad de servicio (QoS) distribuida a partir de Cisco IOS 12.1(5)T, 12.1(5)E y 12.0(14)S. La
acción de habilitar distributed Cisco Express Forwarding (dCEF) habilita automáticamente la QoS
distribuida.
Interfaces no VIP, denominadas procesadores de interfaz heredada (IP), soportan las características
QoS centrales del modo en que fueron habilitadas en el procesador de conmutación de ruta (RSP).
Si desea más información, consulte los siguientes documentos:
  Mecanismo de cola de espera equitativo y ponderado basado en clases distribuido y
detección temprana aleatoria y ponderada distribuida
 Mecanismo de cola de baja latencia distribuido
 Modelado del tráfico distribuido
 Interfaz versátil de procesador distribuida FRF.11 y FRF.12 para el IOS de Cisco versión
12.1 T

9P. ¿Cuántas clases admite una política de calidad del servicio (QoS)?
A. En versiones del IOS de Cisco anteriores a la 12.2 usted podía definir un máximo de sólo 256
clases, y podía definir sólo 256 clases dentro de cada política si las mismas clases eran vueltas a
usar para diferentes políticas. Si usted tiene dos políticas, el número total de clases de ambas
políticas no debe superar 256. Si una política incluye el Mecanismo de cola de espera equitativo y
ponderado basado en clases (CBWFQ) (lo que significa que contiene una declaración de ancho de
banda [o prioridad] dentro de cualquiera de las clases), el número total de clases compatibles es 64.
En Cisco IOS versiones 12.2(12), 12.2(12)T y 12.2(12)S, esta limitación de 256 asignaciones de
clase globales se ha cambiado, y ahora es posible configurar un máximo de 1024 asignaciones de
clase globales y utilizar 256 asignaciones de clase dentro de la misma asignación de política.

10P. ¿Cómo se procesan las actualizaciones de routing y los mensajes de actividad de

Protocolo punto a punto (PPP) / Control de enlace de datos de alto nivel (HDLC) cuando se
aplica una política de servicio?
A. Los routers de Cisco IOS utilizan los dos mecanismos siguientes para priorizar los paquetes de
control:
 Precedencia IP

 pak_priority

Ambos mecanismos están diseñados para garantizar que ni el router ni el sistema de colocación en
cola interrumpan los paquetes de control clave o los interrumpan en último lugar cuando una
interfaz de salida está congestionada. Para obtener más información, consulte la sección
Introducción a de cómo se envían a cola las actualizaciones de ruteo y los paquetes de control en
una interfaz con una política de servicio de QoS.

11P. ¿Se admite la Calidad del servicio (QoS) en las interfaces configuradas con Puente y
routing integrado (IRB)?
A. No. No puede configurar las funciones de QoS cuando la interfaz está configurada
para IRB.

12P. ¿Qué es la clasificación previa de calidad de servicio (QoS)?

A. La clasificación previa de QoS permite hacer coincidir y clasificar el contenido del encabezado
de IP original de los paquetes que pasan por encapsulamiento, tunelización o cifrado. Esta función
no describe el proceso de copiar el valor original del byte del tipo de servicio (ToS) desde el
encabezado del paquete original al encabezado de túnel. Si desea más información, consulte los
siguientes documentos:
 Configuración de QoS para redes virtuales privadas
 Calidad de servicio para Redes virtuales privadas, módulo de funciones 12.2(2)T

13P. ¿Qué campos del encabezado del paquete pueden ser observados? ¿Qué valores están
disponibles?
A. La característica de marcación basada en la clase le permite configurar o marcar el encabezado
de la capa 2, capa 3 o el Multiprotocol Label Switching (MPLS) de sus paquetes. Si desea más
información, consulte los siguientes documentos:
 Configuración de marcado de paquetes basado en clases
 ¿Cuándo establece un router el bit CLP en una célula ATM?
 ‘Configuración del paquete de marcación en PVC de Frame Relay’

14P. ¿Puedo priorizar el tráfico basado en el URL?

A. Yes. El reconocimiento de la aplicación con base en la red (NBAR) le permite clasificar
paquetes mediante la concordancia de campos en la capa de la aplicación. Antes de la introducción
de NBAR, la clasificación más granular eran los números de puertos de protocolo de control de
transmisión (TCP) y protocolo de datagramas de usuario (UDP) de capa 4. Si desea más
información, consulte los siguientes documentos:
 Preguntas y respuestas sobre el reconocimiento de aplicaciones basado en la red
 Red de aplicación NBAR
 Uso del reconocimiento de la aplicación basada en la red y Listas de control de acceso para
el bloqueo del gusano "Código rojo
 Cómo proteger su red del virus Nimda

15P. ¿Qué plataformas y qué versiones del software IOS de Cisco y admiten el
Reconocimiento de aplicación con base en la red (NBAR)
A. Las siguientes versiones de software de Cisco IOS son compatibles con NBAR:

Versión mínima del Software del IOS de

Platform Cisco
7200 12.1(5)T
7100 12.1(5)T
3660 12.1(5)T
3640 12.1(5)T
3620 12.1(5)T
2600 12.1(5)T
1700 12.2(2)T
Nota: Debe activar Cisco Express Forwarding (CEF) para utilizar NBAR.
NBAR distribuido (DNBAR) está disponible en las siguientes plataformas:

Versión mínima del Software del IOS de

Platform Cisco
7500 12.2(4)T, 12.1(6)E
FlexWAN 12.1(6)E

Nota: NBAR no es compatible con las interfaces VLAN de la Tarjeta de función de switch

multicapa (MSFC) de Catalyst 6000, la serie Cisco 12000 o el Módulo de switch de ruta (RSM)
para la serie Catalyst 5000. Si no ve incluida una plataforma en particular, póngase en contacto con
su representante técnico de Cisco.