POLÍTICAS DE QOS PARA INTERFACES TRONCALES DE

POLÍTICAS DE QOS PARA INTERFACES TRONCALES DE LOS EQUIPOS METRO Y CORE MPLS
DE UNA RED BASADA EN ASON
Octavio José Salcedo Parra
Universidad Nacional de Colombia-Universidad Distrital Francisco José de Caldas
Giovanny Narvaez
Universidad Distrital Francisco José de Caldas
Francisco J Puente
Universidad Distrital Francisco José de Caldas
Resumen:
Este articulo presenta una evaluación
especificaciones de las políticas de QoS para
de
las
interfaces
troncales de los equipos Metro y Core MPLS de una red basada en
ASON de proyecto “Prototipo para evaluar las ventajas técnicas y
de costo beneficio en redes backbone con servicios de nueva
generación basadas en ASON (Automatic Switched Optical
network)”, en la primera parte se definen los servicios prestados
por los proveedores de servicios, en la segunda se hace un análisis
de la QoS de los servicios con el objetivo de nivel de servicio
(SLO), posteriormente se define la arquitectura de QoS adoptada
y por ultimo se define los mecanismos de QoS
En este capitulo se va analizar Figura 2; pero es necesario tener en
cuenta algunos parámetros de diseño, por lo tanto se contempla
una nueva configuración de 6 colas en interfaces de salida para ser
implantada una vez que se haya alcanzado un suficiente grado de
actualización de la planta que permita configurarlas en todas las
interfaces troncales de las redes Metro y Core.
Palabras Claves: Calidad de Servicio (QoS), Metro Ethernet,
Ingeniaría de Trafico, Clasificación de paquetes. Objetivo de
Nivel de Servicio (SLO)
Introduccion
En la época en que vivimos actualmente el tráfico sigue creciendo
a ritmo acelerado y plantea grandes retos a los operadores de
telecomunicaciones que han visto superado el tráfico de voz por el
de datos, cuya aportación económica es mucho menor.
Para este nuevo reto, es indispensable tener redes flexibles, que
utilicen tecnologías que optimice el ancho de banda, seguras,
gestionables y que sean integrables con otros servicios, de ahí la
importancia de definir las políticas de QoS para interfaces
troncales de los equipos Metro Ethernet y Core MPLS de una red
basada en ASON.
El Objetivo de este articulo es especificar las políticas de QoS
para interfaces troncales de los equipos Metro y Core MPLS de
una red basada en ASON, este basado de acuerdo las nuevas
aplicaciones que están surgiendo en Internet que han producido
en aumento de la necesidad de transmitir información desde un
origen a múltiples destinos (multidifusión) y que esta transmisión
se haga garantizando ciertos parámetros de Calidad de Servicio
como pueden ser el Delay máximo y el número de paquetes que
pueden ser descartados sin afectar a la calidad de la transmisión de
la información. Esta Calidad de Servicio no puede ser asegurada
por los protocolos TCP/IP por lo que se han desarrollado
diferentes tecnologías para superar este inconveniente [1]
Figura 2. Topología de Red Concebida2
Las tablas de mapeo de tráfico a colas en las interfaces de salida
incluyen solo el campo EXP de los paquetes MPLS [4], que son
los paquetes presentes internamente en las redes Metro y Core. La
clasificación de paquetes y la correspondencia con valores IP
Precedence y DSCP deberá especificarse en los mencionados
documentos Plan Técnico o similares para cada servicio y para
cada tipo de tráfico que deba ser cursado por la red de cada
proveedor de servicios.
Se elimina la clase “Datos Excedentes” como tal. Deberá definirse
la manera en que se mapean los excedentes de cada tipo de tráfico
en los documentos de cada servicio.
1.1
SERVICIOS PRESTADOS
Los servicios prestados por las redes de las operadoras son:
Servicios Residenciales:
1. Internet
2. Video (IPTV, Video On Demand) esta
próxima a salir al mercado
3. VoIP
Servicios Corporativos:
1. Internet IP (IP dedicado)
2. LAN to LAN (VLL y VPLS)
3. VPN IP MPLS
1.2
QoS
Con el modelo de red propuesto, la red puede ser configurada para
alcanzar los requisitos de red basados en cada uno de los
servicios. Siendo así, garantizar una cantidad de ancho de banda
para los servicios a lo largo de la red va a depender del modelo de
clasificación, marcado y encolado de los mismos, sin olvidarse
del control y gestión de la congestión en el core de la red [5].
Figura 1. Modelo de Red de dos capas basada en ASON1
1
Topología de red basado en ASON “Next Generation”
La pérdida de paquetes se produce por desborde de una cola en el
momento de congestión, y el delay y jitter están asociados a la
configuración de los servicios, además de ser impactados por
situaciones de congestión. O sea, la pérdida de paquetes puede ser
significativamente reducida si se aplica una política de
encolamiento adecuada en la red y si se emplea una planificación
de capacidad adecuada (Capacity Planning), así como el delay de
2
Escenario evaluado de acuerdo al escenario a evaluar.
los paquetes y el jitter para los servicios en que estos parámetros
son de significativa importancia.
La definición de las colas a lo largo de la red, ya sea en el
Backbone IP o en la MetroEthernet, está totalmente ligada al
número de colas disponibles en cada interfaz. Esto se debe a que
podemos encontrar interfaces con distintas configuraciones de
colas. Algunas interfaces son del tipo 1p2q2t (esto es, una cola
prioritaria, dos colas concurrentes y dos parámetros de descartes
para cada cola), otras son 1p3q8t (esto es, una cola prioritaria y
tres colas concurrentes y ocho parámetros de descarte para cada
cola), otras son 1p7q8t, más allá de otras interfaces existentes en
el mercado, o sea, existen varias configuraciones que pueden ser
hechas para que el tráfico se ubique en las colas correctas. Es
importante que los tráficos sean clasificados y marcados en la
entrada de la red para que los mismos sean encolados de forma
correcta y de acuerdo con los requisitos de red esperados por el
servicio [6].
Dado que la nueva gama de equipos de Core y Metro, así como
nuevas placas de interfaces en equipos antiguos ya soportan 8
colas por interfaz, se incorpora en este capitulo un mapeo de
clases de servicio a 6 colas, lo que permitirá dar mayor
flexibilidad a la red para gestionar los requerimientos de calidades
de servicio y brindar una mejor diferenciación de tratamiento de
tráfico ante condiciones exigentes.
Generalmente en una primera fase de implementación se
configurarán todos los equipos de la red con 4 colas en cada
interfaz de salida, en la modalidad 1p3q2t, para garantizar
configuraciones homogéneas.
arquitectura DiffServ propone una forma de implantar QoS en las
redes IP con la capacidad de ampliación requerida por grandes
redes como los backbones de los proveedores de servicio IP.
El modelo de Diffserv se basa en la definición de clases de
servicio y en la implementación de mecanismos que permitan
tratar cada clase de forma diferenciada con relación a diversos
requisitos de red (delay, throughput, jitter)[8].
La implementación de una Arquitectura de QoS se divide en dos
partes:
•
Clases de servicios y Traffic Conditioners (TC) en los
elementos de borde de la red.
•
Clases de servicios y Per Hop Behavior (PHB) del core
de la red IP y red MPLS
La separación se debe a las definiciones de la Arquitectura
DiffServ y que especifica la necesidad de:
•
Aplicación de los condicionamientos de tráfico (TC) en
el borde del backbone, para adecuar el tráfico de cliente a las
condiciones fijadas en el SLA.
•
Reserva de ancho de banda y priorización de las
aplicaciones en el backbone a través de la aplicación de PHBs, de
forma de garantizar los objetivos de SLA.
La siguiente figura ilustra esta arquitectura:
En una fase posterior, una vez que se haya alcanzado un grado de
actualización de la planta que permita configurar 6 colas en todas
las interfaces, se propone migrar las configuraciones a 6 colas.
1.3
SERVICE LEVEL OJECTIVE (SLO)
El Objetivo de Nivel de Servicio (SLO) corresponde a un
conjunto de parámetros de desempeño y criterios técnicos
definidos para la totalidad de la red, para cada servicio prestado
por la red. En suma, el SLO corresponde a los valores máximos y
mínimos prestados por la red.
Dadas las características dinámicas de cualquier red, la garantía de
SLO es un proceso continuo dentro de la red y depende
directamente del diseño de la red, así como su arquitectura y
operación.
Por lo tanto, para garantizar los parámetros, la red debe ser
monitoreada continuamente a fin de verificar que los parámetros
medidos se encuadren dentro de los parámetros definidos. En caso
que ocurrir un desvío de estos parámetros se deberán realizar
acciones correctivas para que los SLA’s acordados con los
clientes no se vean perjudicados. Tales acciones pueden ser:
reconfiguración de la red, ampliación del ancho de banda e
interfaces y hasta el mismo cambio de equipamientos[17].
Para cada descripción del servicio será definido un SLO, definido
a partir de resultados de laboratorio.
Además de la configuración de red, el SLO ofrecido está
directamente relacionado con el MTBF (Mean Time Between
Failure) de cada equipamiento, por lo tanto las especificaciones de
los equipos de red deben garantizar que los SLOs sean
cumplidos[17].
1.4
ARQUITETURA DE QoS
En esta sección se detalla la arquitectura de QoS a ser adoptada
para la red de forma de implementar las clases en las redes Metro
Ethernet, red IP y red IP/MPLS basadas en ASON.
PHB:PHB:
- Colas
Filas
- Control
Controlede
deCongestión
Congestionamento
TC de Entrada:
- Clasificación
Classificação
- Marcado
Marcação
- Policing
Policiamento
TCde
deSaída:
Salida
TC
- Colas
Filas
- Control
Controlede
deCongestión
Congestionamento
- Policing,
Policiamento
Shaping
Figura 3 – Arquitectura del Modelo Diffserv
Desde el punto de vista de la arquitectura Diffserv, la clasificación
y el marcado deben suceder en el punto más próximo posible del
cliente, o sea, en el primer, nodo de red capaz de realizar esta
funcionalidad. Siendo así, el DSLAM será responsable por el
marcado del tráfico de acuerdo con el servicio ofrecido, de esta
forma todo el tráfico proveniente del DSLAM será considerado
como tráfico confiable por parte del switch directamente
conectado. O sea, las puertas de los switches conectadas al
DSLAM’s no tendrán la responsabilidad de clasificar y marcar los
paquetes, una vez que esta función será del DSLAM. Por ello,
más allá de la responsabilidad de confiar en el tráfico, el switch
puede tener la responsabilidad de remarcar el tráfico. Eso ocurre,
porque el tráfico proveniente del DSLAM se modifica con el
marcado 802.1p y fija como responsabilidad del switch remarcar
el tráfico en el caso que el mismo sea enviado fuera de la red
metro. La remarcación ocurrirá en el caso de mapear 802.1p para
EXPbit ó 802.1p para DSCP.
Para los clientes corporativos, existen dos tipos de CPE, los
llamados confiables (gestionados por un sistema de Gestion) y los
no confiables (no gestionados por el mismo proveedor).
Más allá de la definición de la arquitectura de QoS, se debe
realizar también una Planificación de la Capacidad de la Red,
definiéndose de qué forma el ancho de banda será dividido entre
las clases.
Los CPE’s confiables pertenecen a la operadora, y ésta, a su vez,
es responsable por la configuración y gestión del equipo, por lo
tanto, y al igual que para el DSLAM, el TC se encuentra en el
propio CPE, y el próximo elemento de red, sea ese un Switch, un
Router o un DSLAM, se debe basar en el marcado recibido.
La arquitectura de QoS en la arquitectura Differentiated Services
(DiffServ) definida en las RFC 2474 y RFC 2475 [9][10]. La
Ya que los CPE`s no confiables son configurados por el propio
cliente, esto significa que la marcación realizada en el paquete
puede no estar de acuerdo con la política implementada por la red
de la operadora para el servicio contratado, por consiguiente todo
el tráfico recibido desde este CPE en un DSLAM, Switch Ethernet
o un Router de la red, debe ser ignorado el marcado existente en el
DSCP, y marcar el CoS y/o EXP Bit para la clase de servicio
contratada. El Byte TOS (que incluye al DSCP) no debe ser
alterado dentro de la red pues tal campo podrá ser utilizado dentro
de la red del cliente.
Para los casos en que los CPE`s están conectados a la red por una
linea DSL, el DSLAM debe estar dimensionado para soportar
todo el ancho de banda contratado por el cliente evitando que
ocurran congestiones de paquetes en ese punto de la red.
En las secciones que siguen se definen diversas clases de servicio
y se detallan los mecanismos de QoS utilizados para
implementarlas.
1.4.1
Definición de clases de servicio
Las clases de servicio constituyen un agregado de aplicaciones
que comparten los mismos requisitos de red (delay, throughput,
jitter).
Se propone la definición de 6 clases de servicio en el núcleo de la
red IP, las cuales se consideran suficientes para encaminar la gran
mayoría de las aplicaciones: Control de red, Real Time, Video,
Datos Críticos, Datos no-críticos, Best Effort [16].
Según lo expresado anteriormente, en una primera fase de
implementación se configurarán todos los equipos de la red con 4
colas en cada interfaz de salida, en la modalidad 1p3q2t, para
garantizar configuraciones homogéneas [7]. Por consiguiente, las
6 clases de servicio definidas deben ser traducidas en las 4 colas,
según lo descrito en el apartado 1.4.3 del capitulo. En una fase
posterior, una vez que se haya alcanzado la actualización de la
planta y exista soporte de un mínimo de 6 colas en todas las
interfaces, se podrán migrar las configuraciones.
Los paquetes de los protocolos de routing y control generados por
los equipos de la red forman parte de la clase “Control de Red” y
deben ser mapeados a una cola específica no compartida por otros
tipos de tráfico para evitar competencia con tráfico de clientes.
Dicha cola no debe implementar mecanismos de descarte de
paquetes ante eventos de congestión pues se trata de tráfico vital
para el funcionamiento de la red. La mayoría de los equipos
realizan una marcación automática de este tráfico con valor de
DSCP CS6 , Cos 6 y/o EXP 6. Esta cola debe tener garantía
absoluta de Ancho de Banda, aún en casos de congestión grave.
La clase Control de Red solo existe en el interior de la red y no
puede ser utilizada por ningún otro servicio.
La siguiente tabla muestra las clases de servicio que la red dispone
y ofrece hacia el exterior:
CLASE
TIPO DE TRÁFICO
Real Time
Tráfico de aplicaciones de
Tiempo Real (VoIP, otras)
5
Video
Tráfico TV Broadcast y Video
Streaming
4
Datos Críticos
EXP
Tráfico de Gestión
3
Tráfico Datos PLATINO
3
Tráfico de Routing del cliente
3
Tráfico de control de VoD
2
Tráfico de Datos ORO
2
Datos No
Críticos
Tráfico de Datos PLATA
1
Tráfico de Datos BRONCE
1
Best Effort
Tráfico Best Effort
0
Tabla 1 - Asignación sugerida de valores EXP en los PE de la Red
La asignación de valores de IP Precedence y/o DSCP deberá ser
definida en los documentos que traten la implementación de cada
servicio ofrecido por la red.
En dichos documentos deberá publicarse una tabla que muestre la
correspondencia entre los valores IP Precedence y/o DSCP, según
sea el caso, y los valores EXP. Luego en el presente documento se
encuentra la definición de cómo cada paquete es tratado en las
colas de salida de los troncales de Metro y Core para cada valor
EXP del encabezado de los paquetes MPLS[15].
En el ítem 1.6 se incluye una tabla sugerida de mapeo de valores
IP Precedence y DSCP a EXP para ser aplicado en un nodo de
borde o PE.
A continuación se describe brevemente cada clase, con sus
características salientes y requisitos:
1.4.1.1
Real Time
Destinada a las aplicaciones en tiempo real, interactivas y
bidireccionales. Los principales representantes de esta clase son
las aplicaciones de voz sobre IP (VoIP) y Video conferencia.
Debe ofrecer garantías mínimas para un throughput variable,
bajos índices de pérdida de paquetes, bajos delay y jitter.
SLO pretendido:
Pérdida de paquetes : < 0,5%;
Delay: < 50 ms;
Jitter: < 2 ms.
1.4.1.2
Video
El tráfico de video es generalmente unidireccional y no
necesariamente se ve afectado por el delay. Respecto al jitter, el
mismo es corregido por los buffers del STB. El video es muy
sensible a descartes puesto que la información transportada por los
paquetes es enviada de forma comprimida.
Los tráficos de Video Broadcast y Video Streaming, así como el
de Voz, no son adaptativos. Las fuentes que originan este tipo de
tráfico, en la gran mayoría de los casos, no modifican la tasa de
generación de paquetes al ocurrir descartes en el trayecto.
SLO pretendido:
Pérdida de paquetes: < 0,1 %;
Delay: < 100 ms;
Jitter: < 5 ms.
1.4.1.3
Datos críticos
Destinada a aplicaciones residenciales o corporativas.
Se trata de aplicaciones que requieren Ancho de Banda
garantizado y bajo delay.
Esta clase suportará el tráfico de Gestión de los equipos de red y
los equipos de cliente. Ejemplos de aplicaciones que se encuadran
en esta clase son: SNMP, Telnet, SSH, HTTP, RADIUS, etc.
Las aplicaciones que mejor se adaptan a esta clase en general
requieren un bajo throughput pero deben ser priorizadas respecto
a otros tráficos de datos para que sea posible, por ejemplo, acceder
a gestionar un equipo de red o de cliente (CPE) aún en situaciones
de congestión.
Esta clase admite 2 sabores o sub-clases, uno de mayor prioridad
que el otro, de manera que pueden mapearse en ella tráficos muy
críticos diferenciados de otros tráficos también críticos pero de
menor prioridad.
En esta clase deberían mapearse tráficos tipo “Bussiness Low
Latency”, destinada a aplicaciones especificas, como por ejemplo
las transportadas nativamente sobre protocolo SNA, que exigen
bajísima latencia y pérdida de paquetes, pero demandan bajo
throughput.
La principal diferencia en relación a la clase Datos No Críticos se
refiere al bajo ancho de banda necesario y al bajo delay.
SLO pretendido:
Pérdida de paquetes: < 0,1 %;
Delay: < 100 ms;
Jitter: < 40 ms.
En el caso de CPEs no confiables, se debe ignorar el marcado del
DSCP, y marcar el CoS y EXP Bit en función de la puerta física
(interface) o lógica (VLAN) de entrada, o incluso en función del
número de port del protocolo de Transporte de los Frames (por
ejemplo, port TCP o UDP).
1.4.1.4
En ningún momento el campo TOS deberá ser remarcado, pues se
trata de la aplicación del cliente final, y la red lo transportará de
acuerdo al servicio contratado y no de acuerdo al servicio
requerido por la marca. De hecho podría ser de interés del cliente
utilizar la marca del TOS para su QoS interno.
Datos no críticos
Destinada a aplicaciones de datos no tan críticas para la empresa
para las cuales el tiempo de respuesta debe ser bajo. Como
representantes de esta clase se ubican aplicaciones de base de
datos, e intranet.
Son aplicaciones adaptativas (generalmente basadas en TCP), que
requieren throughput garantizado relativamente alto y variable y
presentan baja tolerancia a pérdidas.
Según lo recomendado en la Especificación de Política de
Switching, las redes Metro Ethernet deben evolucionar a MPLS
en el futuro y, por lo tanto, el encolamiento del tráfico estará
basado en los EXP bits. De esta manera, el marcado 802.1p será
utilizado solamente en las conexiones de los Switches de la red
Metro Ethernet hacia los accesos de cliente y deben estar
detallados en los Planes Técnicos que definen los servicios.
SLO pretendido:
Pérdida de paquetes: < 1 %;
Delay: < 150 ms;
Jitter: < 50 ms.
1.4.1.5
Best Effort
Destinada a aplicaciones poco rigurosas en relación a los
requisitos de red (delay, jitter, throughput). Como representante
de esta clase, tendríamos las aplicaciones asociadas a la
navegación en Internet y al correo electrónico.
Son aplicaciones que presentan tolerancia a descartes y soportan
valores de RTT (Round Trip Time) altos.
SLO pretendido:
Pérdida de paquetes: < 1 %;
Delay: no aplica;
Jitter: no aplica.
1.4.2
Mecanismos de QoS.
1.4.2.1
Se sugiere mantener una relación uno a uno entre el marcado
802.1p (CoS) y el EXP Bit, para garantizar un tratamiento
coherente de los tráficos provenientes de la MetroEthernet y del
Backbone IP[11].
1.4.2.2
El control de admisión se ejecuta antes de iniciar una aplicación
con el objeto de verificar la existencia de suficientes recursos en la
red para garantizar la calidad requerida.
El protocolo RSVP [3] será usado como mecanismo de control de
admisión para las aplicaciones de tiempo real cuando sea
necesario. Este protocolo está fuera del alcance de este
documento.
1.4.2.3
El marcado de paquetes IP y MPLS posibilita la diferenciación de
clases y grupos de aplicaciones en el acceso. El marcado entre los
CPE’s y el borde de la red hará uso de los bits IP Precedence o
DSCP (incluidos en el campo TOS del paquete IP) y el CoS (bits
de QoS del paquete Ethernet). Internamente el marcado se realiza
sobre el campo Experimental Field (EXP) del encabezado MPLS,
ya que el campo TOS del paquete IP no puede ser leído en una red
MPLS [14].
En caso de utilizar los bits DSCP del campo TOS, existen hasta 64
posibles marcas. Si se utilizan los bits IP Precedence del campo
TOS, se tienen 8 marcas posibles. Hacia adentro de la red, a partir
del equipo PE, solo se disponen 8 marcas posibles para el campo
EXP. Este comportamiento de identificar el PHB del paquete a
través del Exp Field es denominado E-LSP [2].
Ubicación del campo TOS y correspondencia entre los bits IP
Precendence y DSCP:
7
ToS
8 bits
6
5
Len
4
IP Precedence
3
Policing y Shaping
El policing controla el volumen de tráfico de las aplicaciones y
clases en las interfaces de entrada y salida. Algunas razones para
su empleo se enumeran a continuación:
Marcado
Version
Length
Control de Admisión
ID
2
Offset
1
TTL
Proto
FCS
IPSA
IPDA
DATA
0
DiffServ Flow control
•
El ancho de banda consumido por clase debe
controlarse para que el cliente no exceda lo contratado;
•
La cola prioritaria empleada en los routers
para el tráfico de tiempo real interactivo debe estar
limitada a volúmenes de tráfico que no comprometan la
performance de esas aplicaciones y de las aplicaciones
de las demás clases;
•
Aplicaciones no-adaptativas, basadas en el
protocolo UDP, no reaccionan a notificaciones de
congestión y tienden a perjudicar a las aplicaciones que
sí reaccionan (basadas en TCP); para evitar situaciones
de este tipo sus tasas deben ser limitadas;
Existen dos formas para implementar policing: Traffic Policing y
Traffic Shaping. El primero se basa en el descarte del tráfico que
excede los bursts especificados. El segundo restringe la emisión
de tráfico a una tasa media o máxima especificadas, reteniendo los
excesos de tráfico en los buffers de las interfaces de salida. El
Traffic Policing puede ser aplicado en interfaces de entrada y de
salida. El Traffic Shaping solo actúa en interfaces de salida.
Vale aclarar que el mecanismo de shaping introduce delay y jitter
y por tanto no es aconsejable utilizarlo para aplicaciones de
tiempo real.
Los mecanismos de Policing serán detallados en los documentos
que refieren a la política de QoS en el acceso, para cada servicio.
DS CP
Differentiated Service Code Point Bits
Figura 4
El frame MPLS formado a partir de un paquete entrante en la red
MPLS heredará, por default, el valor de los bits IP Precedence del
paquete IP original[14]. Este comportamiento default solo será
evitado configurando un TC que configure el MPLS Exp Field.
1.4.2.4
Gestión de la Congestión (Queueing)
La función Queueing (Gestión de la Congestión) implementa la
distribución del tráfico de cada clase de servicio en las interfaces
de salida de los routers. La asignación de ancho de banda mínima
por clase es fundamental para garantizar los índices exigidos del
throughput, delay y jitter requerido. Con la asignación de ancho
de banda a una clase está siendo reservada una cola que tendrá el
derecho de competir por la cola de salida del router (TX-queue) en
la tasa especificada por el ancho de banda. Para aplicaciones con
requisitos rigurosos de delay y jitter, como las de la clase Real
Time, la asignación de ancho de banda en la cola prioritaria de los
routers es obligatoria. La cola prioritaria es una cola que tiene
prioridad en la asignación de la TX-queue, cuando el ancho de
banda asignado para esa cola no la excede.
Vale aclarar que la asignación de ancho de banda por clase es
conservadora, o sea, el ancho de banda asignado y no utilizado por
una clase podrá ser utilizado por las demás clases si hubiese
necesidad.
En los elementos del backbone la función de scheduling será
implementada por los mecanismos CB-LLQ y CB-WFQ. En
algunos routers, el mecanismo de cola utilizado es el MDRR
(Modified Deficit Round Robin). El MDRR está implementado por
hardware y es equivalente a los mecanismos anteriores, a pesar de
poseer menor precisión en su forma de asignar ancho de banda, el
MDRR posee también una cola prioritaria que puede ser empleada
para el soporte de la clase Real Time y soporta hasta ocho colas,
número suficiente para implementar las clases definidas.
1.4.2.5
1.4.3.1
Configuración de 4 colas para todas las interfaces
troncales
COLA
Nombre
q3
Control de red
q2
Real Time
q1
Datos
q0
El mecanismo Weighted Random Early Detection (WRED)
implementará las estrategias de random drop regulando inclusive
las prioridades de descarte de paquetes en función del valor del
campo EXP cuando distinto valor EXP es mapeado a la misma
cola.3
Los mecanismos descriptos serán aplicados a las configuraciones
de TC en el borde de la red y PHB en interior del backbone IP.
No Drops
6
No Drops
5
Tail Drop
4
WRED LOW
3
WRED LOW
2
WRED LOW
1
WRED HIGH
0
WRED
Tabla 2 – Configuración de colas de salida para interfaces con 4
colas
1.4.3.2
Configuración de 3 colas para interfaces que no
soportan 4
COLA
EXP
Drop profile
Control de
red
7
No Drops
6
No Drops
q1
Real Time
5
Tail Drop
q0
Best Effort
4
WRED LOW
3
WRED LOW
2
WRED LOW
1
WRED LOW
0
WRED HIGH
q2
El mecanismo de dropping (Controle de Congestión) actúa para
prevenir situaciones de congestión cuando las colas de salida de
los routers agotan sus recursos. En dichas situaciones ocurre
pérdida de paquetes o descartes sin distinción de clase (tail drop).
Las aplicaciones reaccionan de manera diferente a esos descartes.
La estrategia tail drop se aplica en casos de aplicaciones noadaptativas como las de la clase Real Time. Esas aplicaciones no
reaccionan a la congestión y, por lo tanto no se obtiene ningún
beneficio aplicándole random drop a ese tipo de tráfico.
Drop profile
7
Best Effort
Control de Congestión (Dropping)
La función de dropping puede implementar dos estrategias para
tratar descarte de paquetes: tail drop o random drop. El random
drop se utiliza para aplicaciones que reaccionan a la pérdida de
paquetes reduciendo su tasa de emisión de paquetes, adaptándose
así a situaciones de congestión. El random drop se anticipa a
situaciones extremas de congestión y prioriza determinadas
aplicaciones al descartar paquetes selectivamente en las colas.
EXP
Nombre
Tabla 3 – Configuración de colas de salida para interfaces con 3
colas
Dado que 4 colas resulta insuficiente para dar cumplimiento a los
requisitos de diferenciación de tráfico por calidades, como resulta
de las especificaciones de servicios como VPN de nivel 3, se
propone la utilización de 6 colas en una fase posterior.
Nota: en equipos Juniper M320, T320 y T640 con Enhanced II
FPC, es posible utilizar 4 niveles de descarte: Low, Medium-Low,
Medium-High y High. Utilizando opcionalmente estos 4 niveles
se puede configurar el Drop Profile para las interfaces con 3 y 4
colas asignando correlativamente estas 4 prioridades a los EXP 4,
3, 2 y 1 respectivamente. De esta manera se tendrá una mejor
priorización del tráfico
1.4.3.3
Configuración de 6 colas, modelo evolutivo a ser
implementado en una segunda fase
La forma de aplicar estos mecanismos a los PHB se detalla en el
capítulo siguiente.
COLA
1.4.3
Configuración de las colas de las interfaces troncales
en los equipos de Metro (PE y P) y Core (P)
Las tablas siguientes presentan la configuración de las colas en las
interfaces de salida de lo equipos de Metro y Core que actúen
como PE y P en la red MPLS.
EXP
Drop profile
7
No Drops
6
No Drops
5
Tail Drop
Video
4
Tail Drop
Datos críticos
3
WRED LOW
Nombre
q5
Control de red
q4
Real Time
q3
q2
2
WRED HIGH
q1
Datos no críticos
1
WRED
q0
Best Effort
0
WRED
Tabla 4 – Configuración de colas de salida para interfaces con 6
colas
Esta propuesta se basa en las siguientes consideraciones:
3
Marcado, policing, queueing y dropping no son las únicas funciones que
implementan los PHB o los Traffic Conditioning en la Arquitectura
DiffServ, pero son las fundamentales. Otras funciones podrán ser
implementadas para el caso de QoS en ADSL como Link Fragmentation,
Header Compression, entre otros.
Al mezclar en la misma cola tráfico basado en
UDP (el tráfico de Video, por ejemplo) y tráfico basado
en TCP, se produce un efecto denominado “TCPstarvation/UDP-dominance”
en
situaciones
de
congestión cuando se produce descarte de paquetes en la
cola. Este efecto implica la “inundación” de la cola por
parte del tráfico UDP que no bajará la tasa de
generación, frente al tráfico TCP que sí lo hará en
presencia de descarte de paquetes. Tampoco es
conveniente mezclar el tráfico de Gestión y el de Datos
PLATINO con el de Video Broadcast, por este mismo
motivo.
Por su naturaleza no adaptativa, no se obtiene
ningún beneficio utilizando un mecanismo de control de
congestión como WRED para el tráfico de video. Este
tráfico debiera ser mapeado a una cola con mecanismo
Tail Drop, pero esto no es posible en la configuración de
4 colas.
Es necesario tratar en distinta cola el tráfico de
Datos Críticos y el de Datos No Críticos puesto que
tienen distintos requisitos de calidad.
En general, el modelo de 6 colas presenta una
mejor distribución del tráfico en las interfaces de salida,
atendiendo los requisitos de las 6 clases de servicio
mencionadas en este documento: Control de red, Real
Time, Video, Datos críticos, Datos no críticos y Best
Effort.
Conclusiones
De acuerdo a las parámetros se plantea un mapeo sugerido para
configurar un equipo de borde o PE en una Red basada en ASON.
A continuación se presenta una tabla que amplía la tabla 1 con los
valores sugeridos de IP Precedence o DSCP, según sea el caso de
aplicación, todo depende del clase de servicio.
La primera columna indica las clases que la Red MPLS (Core +
Metro) ofrece hacia el exterior. Las otras columnas son una
sugerencia de cómo mapear cada tráfico o aplicación a esas clases,
y valores sugeridos de IP Precedence y DSCP que surgen de
diversas fuentes
CLASE
TIPO DE TRÁFICO
IP
Precedence
DSCP
EXP
Real Time
Tráfico de aplicaciones de
Tiempo Real (VoIP, otras)
Voz, VideoConferencia
5
EF
5
Video
Tráfico TV Broadcast y
Video Streaming
VideoConferencia,
Video Broadcasting,
Video Streaming, VoD
4
CS4,AF4
x
4
Datos Críticos
Tráfico de Gestión
Gestión de elementos
de Red, Radius, SNMP
3
CS3
3
Tráfico Datos PLATINO
SAP, ERP
3
Tráfico de Routing y
Gestión de VPN
BGP interno del cliente
Routing CE-PE
Tráfico de control de VoD
Datos No
Críticos
Best Effort
EJEMPLO DE
APLICACIÓN
3
AF3x
6,7
CS6,CS7
3
RTSP
2
CS2
2
Tráfico de Datos ORO
SNA
2
AF2x
2
Tráfico de Datos PLATA
FTP, HTTP, SMTP,
POP3
1
AF1x
1
Tráfico de Datos BRONCE
Best Effort de VPN
0
0
1
Tráfico Best Effort
Tráfico de Internet
0
0
0
Tabla 5 – Mapeo sugerido para el acceso
Respecto al tráfico de routing de cliente, se refiere a los
protocolos de ruteo que el cliente implementa extremo a extremo
entre dispositivos de su red interna y que no son interpretados por
la red. El tráfico de routing PE-CE para accesos del servicio VPN
no trascienden el PE y por tanto no se mapean en MPLS. Ese
tráfico utilizará típicamente IP Precedence 6 o 7.
Referencias.
[1] Yezid Donoso Meisel, Ramon Fabregat, Multidifusión IP
sobre MPLS sin y con QoS Noviembre 2005.
[2] Ash. LSP Modification Using CR-LDP. RFC 3214. January
2002
[3] Awduche. RSVP-TE: Extensions to RSVP for LSP Tunnels.
RFC 3209. December 2001.
[4] Boudani, Ali. An Effective Solution for Multicast scalability:
The MPLS Multicast Tree (MMT). draft-boudani-mpls-multicasttree-00.txt. November 2001
[5]
Allied
Telesis,
Advanced
QoS
White
Paper,
www.alliedtelesis.com, marzo 2007
[6]Metro Ethernet Forum. “Metro Ethernet Network Architecture
Framework”. Part 2: Ethernet Services Layer. April 2005
http://www.metroethernetforum.org/PDFs/Standards/MEF12.
doc
[7] Frank Brockners. “Metro Ethernet Services and
standarization”. Cisco Networkers 2005. Cannes (France).
November 2005
[8] Thomas Martin. “Metro Ethernet Arquitectures”. Cisco
Networkers 2005. Cannes (France). November 2005.
[9] RFC 2474 - Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers 1998 IETF.
[10] RFC 2475 - An Architecture for Differentiated Service 1998
IETF.
[11] David Allan, Nigel Bragg, Alan Mcguire y Andy Reid.
“Ethernet as Carrier Transport Infrastructure”. IEEE
Communications Manager. February 2006.
[12]http://www.cisco.com/en/US/products/hw/switches/ps708/pro
ducts_configuration_guide_chapter09186a00801679f8.html#wp1
480292.
[13]http://www.cisco.com/en/US/products/hw/switches/ps708/pro
ducts_configuration_guide_chapter09186a00801679f8.html#wp1
480168.
[14] Biyn Raahemi, AnGe, Maher Ali. “Metro Ethernet Quality of
Services”. Alcatel Telecommunications Review. December
2004.
[15] Michael Beck. “Ethernet in the First Mile”. MacGraw-Hill.
2005 .
[16] “Ethernet Services Definitions – Phase I, Draft v5.5”, Metro
Ethernet Forum, March 2004.
[17] “Ethernet Services Definitions – Phase I, Draft v5.5”, Metro
Ethernet Forum, March 2004.