CAPITULO V

 

DISEÑO DE LA PROPUESTA

 

Índice

Descripción

5.1 Conceptualización

5.2 Objetivos

5.3 Alcance

5.5 Fases de la propuesta.

5.6 Validación de la propuesta

 

5.1 Conceptualización

Los mecanismos de Calidad de servicio (QoS) ofrecen prioridad a unos determinados tipos de tráfico, sobre diferentes tecnologías, incluyendo: Frame Relay, Asynchronous Transfer Mode (ATM), LANs y líneas dedicadas, con el fin de garantizar la entrega del tráfico de acuerdo a la importancia de cada aplicación en caso de competencia por los recursos de la red.

Para la aplicación de QoS es importante tomar en cuenta el ancho de banda disponible para cada enlace donde se categoriza en tres (3) tipos:

Baja velocidad: enlaces con anchos de banda menores a 768 Kbps.

Media velocidad: enlaces con anchos de banda entre 768 Kbps y un T1 / E1 (1.544 Kbps /2.048 Kbps).

Alta velocidad: enlaces con anchos de banda superiores a un T1 / E1 (1.544 Kbps / 2.048 Kbps).

 

     La clasificación de acuerdo a la capacidad de transmisión o velocidad de los enlaces hacia redes definen la cantidad de niveles de servicio para la implementación de políticas de Calidad de Servicio (QoS). Casi todos los enlaces utilizados por PDVSA  están dentro de la categoría de enlaces de alta velocidad. Cisco Systems Inc. recomienda una categorización de niveles de servicio no menor de cinco (5) clases y no mayor de once (11) para conexiones de alta velocidad. Estas consideraciones están especificadas en el documento Enterprise QoS Solution Reference Network Design Guide Version 3.3, disponible en la pagina Web del fabricante. En las consideraciones y recomendaciones que se mencionan a continuación se hace también referencia a los documentos QoS Baseline At-a-Glance y QoS Configuration and Monitoring At-A-Glance.

 

5.2 Objetivo

El objetivo de la propuesta es ofrecer unos mecanismos o políticas de calidad de servicio (QoS) hacer aplicados en la red de Pdvsa Gas Anaco  con el fin de garantizar la entrega de información a los usuarios sin causar retardo en las aplicaciones y evitando congestión a los enlaces.

 

5.3 Alcance de la propuesta

A través de esta propuesta se le proporcionará a Pdvsa Gas Anaco una metodología, para aplicar Calidad de Servicio (QoS) con el fin de mejorar los servicios de red ofrecidos a los usuarios, la propuesta solamente es como referencia y no debe ser considerada la única forma de implementar las políticas de Calidad de Servicio (QoS) dentro de PDVSA. Puede servir de modelo para una implementación futura, pero no pretende servir como plantilla al estilo “Copy and Paste”. Por lo que se recomienda evaluar bien el escenario y ajustar la configuración según sea el caso.

 

5.4 Fases de la Propuesta

Para dar inicio al diseño de la propuesta de políticas de Calidad de Servicio (QoS), se deben seguir varias fases como son:

1. Identificar el tráfico y sus requerimientos: en este paso se audita la red, se determina el porcentaje de utilización del ancho de banda del enlace, se determina las aplicaciones críticas para el negocio lo cual ayuda a determinar el número de clases necesarias que involucren todas las aplicaciones críticas, se define los niveles de servicio requerido para cada clase de tráfico en término de response time y disponibilidad.

2. División del tráfico dentro de clases: Una vez identificado el tráfico a caracterizar se crea las clases de servicios, Cisco Systems propone la división entre cinco (5) o seis (6) niveles tal como se muestra en la figura 1.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                             Figura 1 Clases de Servicios, Fuente: Aro 2007

 

     La figura anterior define los cinco (5) niveles de servicio iniciales, con la asignación de precedencia IP (IPP) y/o código DiffServ (DSCP, AF) y Cos (capa 2) para la marcación de los paquetes antes de que ingresen a la capa de WAN de la red. La política de calidad de servicio (QoS) implementada debe estar apalancada por políticas compatibles dentro de las regiones en cuanto a la clasificación y marcaje de los paquetes.

 

     En la siguiente tabla se definen las aplicaciones comúnmente clasificadas por cada nivel de servicio y los anchos de banda recomendados de acuerdo a las mejores practicas tomando en cuenta las necesidades de muchas empresas que pagan por enlaces WAN a proveedores de servicio de transmisión (Caries).

 

Tabla Nº 1 Aplicaciones por Clases de Servicio, Fuente: Aro, 2007

 

 

3. Método y modelo de QoS: El método que se implementara para el diseño es la línea de comando modulares de QoS (MQC), el cual es un método estructural que le permite al administrador de la red crear políticas de tráfico y relacionarlas con las interfaces, es decir, primero se identifica el tráfico a través de listas de acceso, Ip precedence, DSCP, CoS, MAC address, luego se crean las clases que involucran las listas de acceso ya creada y por ultimo se crean las políticas que involucra cada clase creada y esa política se relaciona a una interfaz física o lógica del router.

 

     El modelo a utilizar será el DiffServ explicado en el capítulo II, por ser uno de los modelos más escalable y flexible en la implementación de Qos, en donde el tráfico será identificado por clases de acuerdo a los requerimientos del negocio, cada clase pueden ser asignadas a diferentes niveles de servicio

 

4. Clasificación de aplicaciones: Para la clasificación del tráfico se utilizó los “Class-Maps” que permiten dar flexibilidad a la posterior aplicación de políticas a través de “Policy-MAP” a la entrada de cada enrutador. Se utilizan opciones para los comandos “match” de acuerdo a la librería de protocolos (PDLM) incluidas en NBAR y listas de control de acceso (ACL) por nombre, estas listas de acceso deben ser creadas de acuerdo a las necesidades y requerimientos de cada aplicación, por lo que no se muestran en el modelo. Los protocolos y listas de control de acceso que deben ser seleccionados están dentro los símbolos “menor que” (<) y “mayor que” (>).

 

4. Diseño de políticas: Se utilizan opciones para los comandos “match” de acuerdo a la librería de protocolos (PDLM) incluidas en Netflow y listas de control de acceso (ACL) por nombre, estas listas de acceso deben ser creadas de acuerdo a las necesidades y requerimientos de cada aplicación, por lo que no se muestran en el modelo. Los protocolos y listas de control de acceso que deben ser seleccionados están dentro los símbolos “menor que” (<) y “mayor que” (>).

 

!

class-map match-any VoIP

description Clasificacion de Telefonia IP por defecto

match protocol rtp voice

match protocol rtcp

!

class-map Video

description Clasificacion de Video por defecto

match protocol rtp video

!

class-map match-any Misión-Critica

description Clasificacion de aplicaciones criticas de primer nivel

match protocol <lista de protocolos>

match acces-group name <Mision-Critica-1>

!

class-map match-any Transaccional

description Clasificacion de aplicaciones criticas de segundo nivel

match protocol <lista de protocolos>

match acces-group name < Transaccional >

!

class-map match-any Aplicaciones Importantes

description Clasificacion de aplicaciones importantes

match protocol <lista de protocolos>

match acces-group name <Aplicaciones Críticas>

!

class-map Mejor esfuerzo

description Clasificacion de aplicaciones Mejor Esfuerzo

match protocol <lista de protocolos>

match acces-group name <Mejor Esfuerzo>

!

4.1 Política de marcación del tráfico a la entrada del enrutador

 

     En primer lugar se hace referencia a las clases (class-maps) definidas anteriormente empleando clases anidadas (Nested Class-Maps) para mantener la flexibilidad de la configuración

 

!

class-map Core-Telefonia-IP-Entrada

match class-map VoIP

!

class-map Core-Video-Entrada

match class-map Video

!

class-map Core-Mision-Critica-1-Entrada

match class-map Mision-Critica

!

class-map Core-Mision-Critica-2-Entrada

match 2 class-map Transaccional

!

class-map Core-Mision-Critica-3-Entrada

match class-map Aplicaciones Importantes

!

class-map Core-Transaccional-1-Entrada

match class-map Mejor Esfuerzo

 

 

     En segundo lugar se aplica la política de marcación del tráfico a la entrada del enrutador. Para que la política se active se necesita el comando “service-policy input QOS-Core-Entrada” en la interfaces para el trafico que entra al equipo. La intención inicial es utilizar nombres de PHB (Per-Hop-Behaviour) como EF y AF, Dejando los CS (Class Selectors) para futuras expansiones del modelo de seis (6) clases sugerido en este documento.

!

policy-map QOS-Core-Entrada

class Core-Telefonia-IP-Entrada

set dscp EF

!

class Core-Video-Entrada

set dscp AF41

!

class Core-Mision-Critica-1-Entrada

set dscp AF31

!

class Core-Mision-Critica-2-Entrada

set dscp AF32

!

class Core-Mision-Critica-3-Entrada

set dscp AF33

!

class Core-Transaccional-1-Entrada

set dscp AF21

!

!

4.2 Política de despacho del tráfico a la salida del enrutador (Encolamiento y Manejo de Congestión)

 

     La clasificación se hace de acuerdo a DSCP y/o nombres de PHB, asumiendo que los paquetes IP llegan a la interfaz de salida previamente marcados. Cualquier paquete que no coincida con los “class-maps” a este nivel son ubicados en la clase por defecto (class-default) que es tratada bajo la filosofía de mejor esfuerzo (Best Effort).

!

class-map Core-Telefonia-IP-Salida

match dscp EF

!

class-map Core-Video-Salida

match dscp AF41 AF42 AF43

!

class-map Core-Mision-Critica-Salida

match dscp AF31 AF32 AF33

!

class-map Core-Transaccional-Salida

match dscp AF21 AF22 AF23

!

class-map Core-Mejor-Esfuerzo-Salida

match dscp AF11 AF12 AF13

!

class-map Core-Carronero-Salida

match dscp default

 

 

La política de despacho se aplica a la salida del enrutador. Para que la política se active se necesita el comando “service-policy output QOS-Core-Salida” en la interfaz para el trafico que sale del equipo.

 

!

policy-map QOS-Core-Salida

!

class Core-Telefonia-IP-Salida

priority percent 18

!

class Core-Video-Salida

bandwidth percent 15

!

class Core-Mision-Critica-Salida

bandwidth percent 15

random-detect dscp-based

!

class Core-Transaccional-Salida

bandwidth percent 12

random-detect dscp-based

!

class Core-Importante-Salida

bandwidth percent 10

random-detect dscp-based

!

class class-default

bandwidth percent 30

!

 

Esta política garantiza un mínimo de ancho de banda por cada clase, y permite el uso del ancho de banda disponible en caso de que otras clases no lo estén utilizando, excepto para la clase Core-Telefonia-IP-Salida.

 

5.5 Validación de la Propuesta

 

El modelo de configuración presentado será discutida a nivel técnico tanto con el personal administrador de la red como con el personal de aplicaciones con el fin de analizar si los criterios tomados en consideración solventaran el problema de congestionamiento de la red y que medidas se deben tomar en cuenta para afectar lo menos posible al usuario a la hora de hacer las pruebas para la implementación de la propuesta y a nivel gerencial con el Gerente de AIT Gas con el fin de informarle las acciones a tomar para implementar la propuesta y que beneficios le traerá a la empresa.