TECSUP PFR Comunicaciones de Datos II

113
UNIDAD VIII


TEL: REDES DE ACCEDO ADSL




1. INTRODUCCIN

MPLS crea redes flexibles y escalables, esto incluye ingeniera de trfico y
Soporte de VPNs el cual ofrece calidad de servicio QoS con mltiples clases de
servicios CoS.

2. OBJETIVOS

Identificar los componentes de la red MPLS
Diferenciar los diferentes modelos de QoS en MPLS


3. INGENIERA DE TRFICO

La ingeniera de trfico es el proceso que mejora la utilizacin de la red mediante
la distribucin del trfico en ella de acuerdo con la disponibilidad de los recursos,
el trfico actual y el esperado. CoS y QoS pueden ser factores a tener en cuenta en
este proceso.

Como resultado, se evita la congestin en cualquier camino. La mejora de la
utilizacin de la red no implica, necesariamente, que se obtenga el mejor camino,
pero s el mejor camino para un determinado tipo de trfico.

La ingeniera de trfico permite al proveedor hacer un mejor uso de los recursos
y permitir reservar enlaces para determinadas clases de servicio o clientes.

El objetivo bsico de la ingeniera de trfico es adaptar los flujos de trfico a los
recursos fsicos de la red. La idea es equilibrar de forma ptima la utilizacin de
esos recursos, de manera que no haya algunos que estn suprautilizados, con
posibles puntos calientes y cuellos de botella, mientras otros puedan estar
infrautilizados.

En una red IP/ATM los flujos de trfico seguan el camino ms corto calculado
por el algoritmo IGP correspondiente. En casos de congestin de algunos enlaces,
el problema se resolva al aadir ms capacidad a los enlaces.

La ingeniera de trfico MPLS consiste en trasladar determinados flujos
seleccionados por el algoritmo IGP sobre enlaces ms congestionados, a otros
enlaces ms descargados, aunque estn fuera de la ruta ms corta (con menos
saltos).
Comunicaciones de Datos II TECSUP PFR

114




Aqu encontramos el caso de las rutas forzadas. La ruta que un LSP puede tomar
puede forzarse para que cumpla unos requerimientos seleccionados en el LER de
entrada (un caso particular de ellas son las rutas explcitas, donde el parmetro
que fuerza este camino es el orden que debe seguir).

Los parmetros que pueden ser utilizados para describir esas rutas son el ancho
de banda, el retardo, la prioridad, etc., que se desea para un flujo de trfico.


Para calcular estas rutas existen dos mtodos:

Calcular en el LER de entrada toda la ruta basndose en informacin sobre el
estado de la red.
Calcular la ruta salto a salto con informacin local a cada LSR sobre la
disponibilidad de los recursos.

Los dos mtodos pueden combinarse si en alguna parte de la ruta la informacin
no est disponible (ej. en un Sistema Autnomo).

Pero no basta slo con obtener la ruta, es necesario reservar los recursos para
poder satisfacer el servicio requerido.

Existen dos aproximaciones: TE-RSVP y CR-LDP, ambas utilizan el
encaminamiento explcito para crear los LSPs e introducen una sobrecarga de
informacin adicional al crear, mantener y destruir un LSP, pero sta, es mnima
comparada con la generada al procesar la cabecera IP.





TECSUP PFR Comunicaciones de Datos II
115
3.1. TE-RSVP

TE-RSVP (Trafic Engneering RSVP) es una extensin del protocolo RSVP.
TE-RSVP es un protocolo de sealizacin soft state que utiliza UDP o
datagramas IP para la comunicacin entre compaeros LSR (LSR peers).

Creacin de un ER-LSP (Explicitly-Routed Label Switched Path):

El LER de entrada quiere establecer un nuevo LSP hacia el LER de
salida. Los parmetros de trfico determinan por dnde debe pasar
la ruta, as que el LER de entrada enva un mensaje PATH con la ruta
explcita hacia el LER de salida y con los parmetros de trfico que
requiere la sesin.
Cada nodo de la ruta que recibe el mensaje determina si es la salida
para ese LSP, si no lo es, sigue enviando el mensaje PATH
eliminndose de la ruta. En cualquier caso cada LSR crear una
nueva sesin.

Una vez llega al LER de salida, ste determina qu recursos ha de
reservar y devuelve un mensaje RESV que distribuir la etiqueta que
ha elegido para ese LSP y contendr los detalles de la reserva.
Los LSRs intermedios emparejan los mensajes PATH y RESV que
han recibido segn el identificador de LSP, reservan los recursos que
indica RESV, asignan una etiqueta para el LSP, rellenan la tabla de
envo y envan la nueva etiqueta en otro mensaje RESV.
El LER de entrada, cuando lo recibe, enviar un mensaje de
confirmacin RESVConf para indicar que se ha establecido el LSP.
Despus de haberse establecido el LSP se enviarn mensajes
peridicos para mantener el camino y las reservas.


3.2. CR-LDP

CR-LDP (Constraint-based LDP), a diferencia de TE-RSVP, no necesita de
implementaciones adicionales ya que est basado en LDP y utiliza su
misma estructura para los mensajes.

Es un protocolo hard state y utiliza sesiones TCP entre compaeros LSR.

Detalle de la creacin de un ER-LSP (Explicitly-Routed Label Switched
Path):

El LER de entrada quiere establecer un nuevo LSP hacia el LER de
salida. Los parmetros de trfico determinan por dnde debe pasar
la ruta, as que el LER de entrada reserva los recursos que necesita y
enva un mensaje LABEL_REQUEST con la ruta explcita hacia el
LER de salida y con los parmetros de trfico que requiere la sesin.

Comunicaciones de Datos II TECSUP PFR

116
Cada nodo de la ruta que recibe el mensaje reserva los recursos y
determina si es la salida para ese LSP, si no lo es, sigue enviando el
mensaje LABEL_REQUEST eliminndose de la ruta. Puede reducir
la reserva si los parmetros de trfico estn marcados como
negociables.

Una vez llega al LER de salida, ste realiza cualquier negociacin
final sobre los recursos y hace la reserva. Asigna una nueva etiqueta
al nuevo LSP y la distribuye en un mensaje LABEL_MAPPING que
contiene los parmetros de trfico finales reservados para el LSP.

Los LSRs intermedios emparejan los mensajes LABEL_REQUEST y
LABEL_MAPPING que han recibido segn el identificador de LSP,
asignan una etiqueta para el LSP, rellenan la tabla de envo y envan
la nueva etiqueta en otro mensaje LABEL_MAPPING.

En cuanto llegue al LER de entrada se habr establecido el LSP.


3.2.1. Comparacin de ambos mtodos

TE-RSVP es soft state, lo cual significa que la informacin es
intercambiada cuando se establece el LSP, pero se deben enviar
mensajes peridicos para notificar que la conexin todava se
requiere. Por el contrario, CR-LDP es hard state, es decir, toda la
informacin se intercambia al iniciar la conexin y no se
produce ms informacin adicional hasta que el LSP se elimine.

El hecho que TE-RSVP sea soft state e introduzca una sobrecarga
adicional hace que no sea escalable ya que esta sobrecarga
crecer proporcionalmente con el nmero de sesiones RSVP.
Para evitar esto se intenta resumir la informacin y aprovechar
un nico mensaje para enviar varios mensajes de refresco.

CR-LDP utiliza conexiones TCP lo que hace que stas sean ms
fiables y seguras, mientras que TE-RSVP utiliza UDP o
datagramas IP para establecer las comunicaciones, lo que
supone mayor vulnerabilidad aunque puede utilizar IPSec o
algn otro esquema de encriptacin.

Las conexiones TCP de CR-LDP permiten detectar un fallo
mediante notificaciones propias de TCP. Esta notificacin se
procesa rpidamente as que las acciones oportunas sean
iniciadas. Sin embargo, una conexin fallida en TE-RSVP ser
detectada cuando no se reciba un determinado mensaje de
refresco y, dependiendo de cmo se haya configurado, detectar
un fallo tardar segundos o minutos antes de que puedan
iniciarse las acciones de recuperacin.

TECSUP PFR Comunicaciones de Datos II
117
Ambos protocolos soportan re-encaminamiento (re-routing):

TE-RSVP puede crear una nueva ruta a partir de un salto
diferente en un LSR, as, en el momento en que se detecte el
fallo refrescar esta nueva ruta que pasar a ser operativa y, la
antigua se eliminar cuando deje de recibir mensajes de
refresco.
Otra alternativa que soportan ambos protocolos es crear una
ruta completa alternativa mientras se usa la antigua, en el
momento que se produzca un fallo la nueva ruta ser operativa
y se eliminar la antigua.

CR-LDP soporta que un LSP d servicio a muchos hosts
mediante la designacin de FECs, mientras que RSVP slo
reserva ancho de banda a una nica direccin IP.

La eleccin entre los diferentes protocolos se deber a factores como
la complejidad de la red, si las conexiones van a ser cortas o
permanentes, qu grado de tolerancia a fallos se requiere, etc.


3.2.2. Herramientas de Administracin de TE

TunnelVision (Componente Cliente servidor el cual corre sobre
plataformas Solareis y Windows 2000), No es una herramienta de
modelamiento de redes . Utiliza tecnologas como WANDL,
Orchestream, MakeSys, Opnet, para las aplicaciones de
administracin.















Nota: verificar http://www.opnet.com/


Comunicaciones de Datos II TECSUP PFR

118

Tnel Vision


4. BANDWIDTH BROKER

En principio, la definicin funcional del BB es similar al papel que este elemento
en realiza DiffServ. Lo que cambia es fundamentalmente la interaccin con los
elementos del dominio. A la hora de disear un elemento gestor de este tipo para
BB, una de las decisiones a tomar es si hacerlo un elemento centralizado o un
sistema distribuido.
Actualmente pueden encontrarse un buen nmero de aproximaciones en uno y
otro sentido. En la primera definicin de una arquitectura para DiffServ
publicada por el IETF se sugiere la implementacin del BB como un elemento
centralizado.
Entre los problemas que generalmente se achaca a la aproximacin centralizada
podemos encontrar su potencial baja escalabilidad y la creacin de un nico
punto de fallo en la red.

Por ello, existen propuestas como, en la se expone un arquitectura de control de
admisin completamente distribuida. Las propuestas distribuidas se basan en la
dispersin de la informacin de estado entre todos los elementos a lo largo de la
ruta de control, requiriendo por tanto protocolos ms o menos complejos para
conseguir esta dispersin de forma consistente.
TECSUP PFR Comunicaciones de Datos II
119
Ello acarrea necesariamente una modificacin en los equipos de control
instalados actualmente para soportar estos nuevos mecanismos.
Sin embargo en una propuesta centralizada la complejidad no queda diseminada
por los equipos de red, reduciendo el coste del procesamiento de las peticiones
de servicio y evitando generalmente la sustitucin de los equipos para proceder a
la implantacin de la arquitectura. Debemos tener en cuenta que, para que la
provisin de QoS en Internet sea una realidad, es razonable considerar una
minimizacin la cantidad de equipos de red a sustituir.
Adems, en se demuestra cmo la utilizacin de un BB centralizado puede
satisfacer los requerimientos de escalabilidad de los sistemas autnomos
actuales, proponiendo a su vez la posibilidad de replicar la funcionalidad en
varios equipos dispersos en la red para eliminar la existencia de un nico punto
de fallo, incidiendo adicionalmente en un incremento de la escalabilidad.


4.1. FUNCIONES

Las funciones a realizar por el BB son una extensin de la especificacin
para DiffServ, donde ahora para gestionar los recursos de ancho de banda
del dominio, mediante la asignacin de caminos a los flujos de datos de los
usuarios, debe disponer de informacin que le permita obtener dichas rutas
a lo largo del dominio MPLS basndose en los requerimientos de calidad
de servicio.


4.2. TOPOLOGA

En la definicin inicial de un BB para DiffServ est contemplado que un BB
debe disponer de conectividad con todos los routers del dominio. Esto se
debe a que para proporcionar un cierto servicio en DiffServ, el BB debe
configurar los routers para que stos proporcionen dicho servicio. Al
introducir MPLS la situacin cambia, debido al establecimiento de los LSP.
Por ello, no resulta necesario el control desde el BB de todos los routers del
AS (Autonomous System), sino tan slo los ubicados en los bordes. Esta
simplificacin en la ruta de control no es, sin embargo, aplicable a la ruta
de datos, en la que todos los routers deben implementar el mdulo post-
routing para la aplicacin de distintas polticas de descarte a las distintas
clases de trfico.
Una vez definida la topologa de la red de acuerdo a figura, podemos
determinar que la comunicacin ser de la siguiente manera: los usuarios
envan peticiones de servicio a los nodos frontera del dominio, y stos
realizan las peticiones al BB. El BB da rdenes a los nodos frontera para
proporcionar ciertos servicios a determinados usuarios, y los nodos lo
hacen mediante la creacin y/o asignacin de caminos MPLS para el trfico
de stos usuarios.

Comunicaciones de Datos II TECSUP PFR

120


Ejemplo de topologa del BB


4.3. PETICIN DE SERVICIO INTRA-DOMINIO

En nuestro modelo, los usuarios realizan peticiones a su LER de entrada al
dominio en lugar de hacerlo al BB. Esto implica que el usuario que hace la
peticin debe incorporar algn mecanismo de sealizacin. Gracias a esta
organizacin para la sealizacin, se alcanza un grado de transparencia
mayor con respecto al modelo DiffServ tradicional. En el nodo frontera o
LER se recibe la RAR, y se enva al BB una peticin de servicio.

Una RAR (tambin denominada BAR o Bandwidth Broker Allocation Request)
informa de que el usuario se dispone a realizar un envo de trfico.
Contiene la siguiente informacin:

Identificador del usuario: que consta de su direccin IP, ms el
nmero de puerto fuente del nuevo flujo. Esto identifica de forma
unvoca un flujo procedente de un cliente.
Tipo de servicio que desea recibir para el trfico que se dispone a
enviar.
Destinatario (direccin IP) del trfico.
Throughput requerido.

Cuando la RAR llega al BB, es el PDP (Policy Decisin Point) quien se hace
cargo de ella. Analiza su informacin, determina si es una peticin correcta,
e inmediatamente consulta al PMT (Policy Management Tool) para saber si se
adecua a los datos que el BB tiene almacenados sobre ese usuario y sus
SLA. Si todo es correcto y existen recursos libres para satisfacer esta
demanda, se enva al usuario a travs de su LER despus de la apertura del
LSP correspondiente, una RAA (Resource Allocation Answer) afirmativa, en
el caso contrario se enva una RAA negativa. En el momento en que un
usuario recibe una RAA afirmativa puede comenzar a enviar trfico, pues
ste ser tratado con el nivel de servicio que ha especificado en la RAR
(previamente contratado).



TECSUP PFR Comunicaciones de Datos II
121
4.4. PETICIN DE SERVICIO INTER-DOMINIO

Se gestiona de igual forma que la anterior hasta el momento en el que el BB
determina que el destinatario del trfico no se encuentra en su dominio. Al
descubrir esto, realiza el siguiente proceso: el BB enva un mensaje con la
peticin al BB par upstream. ste procesa dicho mensaje y determina si el
destino se encuentra en su dominio o es accesible desde l, si existen
acuerdos con el BB remitente o bien si se puede satisfacer la peticin con el
servicio requerido, es decir, si dispone de los recursos suficientes.
Los acuerdos entre BB de dominios adyacentes se realizan previamente al
proceso de admisin de SLA de clientes. Se trata de acuerdos realizados
generalmente mediante un procedimiento administrativo que
posteriormente son codificados en las BD de los BB, del mismo modo que
los SLA de los clientes. Cuando un BB requiere que un flujo de uno de sus
clientes atraviese un dominio vecino, se lo comunica a dicho dominio y ste
comprueba que la peticin entra dentro de la cuota reservada al dominio
fuente. Por ejemplo, dos dominios adyacentes A y B pueden tener un
acuerdo que consista en que el 10% de los recursos del dominio A se
reservan para el trnsito de trfico procedente del dominio B, y viceversa.

4.5. ATENCIN DE PETICIONES Y RESERVA DE RECURSOS

Despus de que el cliente recibe una RAA afirmativa del BB puede
comenzar a enviar el trfico para el cual se envi la RAR. Previamente, el
BB debe preparar el camino al nuevo trfico. Para ello, pide al LER al que el
cliente envi su RAR y que a su vez envi la peticin al BB, bien que cree
un LSP y enve por el trfico en cuestin, que directamente lo enve por
algn LSP existente que cumpla con los requerimientos (agregacin de
flujos) o incluso que reubique otros flujos para dejar sitio al nuevo.
En el caso de que existan condiciones temporales en el SLA del cliente, el
BB debe encargarse de que stas se cumplan. Es decir, que si por ejemplo se
ha contratado un servicio de alta calidad durante tres horas, debe
controlarse el tiempo durante el que el cliente ha estado haciendo uso de
este servicio, y si sobrepasa el lmite de las tres horas deben denegarse los
nuevos envos de este cliente.

4.6. SEALIZACIN

Se requiere un protocolo de sealizacin que sirva para comunicar los
nodos con los BBs. Puede utilizarse para este propsito algn protocolo
existente, aunque la falta de estandarizacin en este sentido nos ha llevado a
implementar uno sencillo, exclusivamente dedicado a esa tarea.
Denominamos SSP (Simple Signaling Protocol) al protocolo de sealizacin
que proponemos. La simplicidad del mismo resulta en una relativa
simplicidad de implantacin. Un protocolo de sealizacin complejo puede
limitar la implantacin y posterior expansin de la arquitectura, ya que
todos los clientes deben incorporarlo.

Comunicaciones de Datos II TECSUP PFR

122
Para el intercambio de mensajes SSP se utilizarn sesiones SSP. En este
contexto se define una sesin como un dilogo entre elementos pares. Se
consideran elementos pares los elementos de red que soportan el protocolo
SSP y que tienen un enlace fsico punto a punto entre ellos (LER y BB dentro
de un dominio, BB y BB entre varios dominios). Para soportar una sesin se
crea una conexin de transporte TCP durante la fase de descubrimiento.
Esta conexin se mantendr activa desde su establecimiento; y slo se
terminar en caso de que ocurra algn error fatal o se reinicie la red por
algn motivo administrativo.

El protocolo SSP tiene las siguientes categoras de mensajes:

Servicios, donde se encuentran los mensajes para la comunicacin de
los elementos soportados por el protocolo,
Topologa, destinados a los elementos pares, con los que se pueden
establecer y mantener sesiones para el intercambio de mensajes SSP
y
Notificacin.


4.7. ESTRUCTURA

Al igual que en DiffServ, el BB tiene dos partes diferenciadas: PDP (Policy
Decision Point) y PMT (Policy Management Tool), con las mismas
funcionalidades, tal y como se refleja en la figura de abajo.




5. MPLS QOS

En calidad de servicio, estrictamente, slo QoS ofrece garanta y genricamente
engloba mecanismos de CoS y ToS. Ej. IETF RSVP, DiffServ.

CoS(Clase de servicio. Ej. 802.1p) y ToS (Tipo de servicio). Ej. DiffServ

Herramientas de la calidad de servicio:

Control de admisin. CaC para peticin de conexin.
Policy Traffic
Modelado del trfico (Traffic Shapping). Ej. Algoritmo leaky buket en ATM.
Clasificacin y marcado de paquetes. Ej byte ToS en IPv4
TECSUP PFR Comunicaciones de Datos II
123
Protocolos de sealizacin. Ej. RSVP y LDP
Control de congestin. Algoritmos de control de congestin. FIFO, PQ, CQ o
WFQ.

Existen dos modelos de QOS Integrated Services (IntServ) o Servicios Integrados
y Differentiated Services o Servicios Diferenciados (Diffserv).


5.1. DIFFSERV

Es un protocolo de QoS del IETF para distinguir clases de servicio
marcando paquetes. Tambin etiqueta y clasifica paquetes.

Caractersticas:

Usa 6 bits en la cabecera IP para ordenar el trfico en Behavior
Aggregates Pbs.
Define a numero de Per Hop Behaviors - PHBs
Usa PHBs para construir servicios como Lnea Arrendada Virtual
Redefine el campo de Tipo de Servicio de la cabecera IPv4 estndar
(DSCP DiffServ Code Point).



PHB(Per Hop Behavior). Define caractersticas de clases Diffserv. PHB
Describe las caractersticas de una clase DS, descartes, retraso y jitter, ancho
de banda asignado, trfico restringido y paquetes descartados en
situaciones de congestin.

Hay 3 tipos de PHBs. Definidos en Diffserv:

Best-effort class Esta clase tiene los bits: 000 Assured Forwarding
PHB Bits del selector de clase: 001 010, 011, 100.
Expedited Forwarding PHB Selector de bits de clase 101.
Expedited Forwarding es utilizado para aplicaciones que
necesitan un ancho de banda garantizado y son muy sensibles a los
retrasos.
Comunicaciones de Datos II TECSUP PFR

124
Valores EF: IP precedence = 5 DSCP = 101110

Ej: #route-map DATA permit 10
# match ip address 103
# set ip precedence 5

El Estndar Assured Forwarding, especifica cuatro clases de
anchos de banda y describe el tratamiento que cada una debe de
recibir, especifica los niveles de prdida de paquetes, resultando
un total de 12 posibles clases. (Assured Forwarding es
conveniente para datos que no requieren tratamientos
prioritarios, por lo que no es conveniente para VoIP.)

5.2. MODELO INTEGRADO

Es un modelo para describir los posibles niveles de calidad de servicio
quelas aplicaciones pueden solicitar. (RFC 2210) Para ello es necesario:
Una definicin uniforme de los parmetros de calidad de servicio.
Un protocolo de reserva de recursos que implemente estos parmetros
desde el emisor al receptor pasando por todos los nodos intermedios
(RSVP).

5.2.1. Componentes de Inserv:

Clasificador de Paquetes. Establece clases de servicio para los
paquetes entrantes.
Planificador de Paquetes. Distribuye los paquetes en colas y
decide el orden de transmisin de los mismos.
Control de Admisin. Decide si hay recursos suficientes para
aceptar la reserva.
Protocolo de reserva. Se encarga de establecer una conexin con
una determinada QoS en todo el camino. Por excelencia es
RSVP

5.2.2. Caractersticas y objetivos de RSVP:

Es un protocolo de sealizacin.
Proporciona la mayor QoS para aplicaciones y elementos de red.
Cada receptor debe hacer la reserva y la mantiene el tiempo que
desee.
Su tarea consiste en establecer y mantener la reserva de recursos
en un rbol de distribucin.
Reserva de recursos para unicast y multicast. Las reservas son
unidireccionales.
Las reservas son iniciadas y mantenidas por el receptor.
Se basa en los protocolos de routing existentes. Soporta IPv4 e
IPv6
Es transparente para routers que no lo soportan.

TECSUP PFR Comunicaciones de Datos II
125
MPLS est diseado para poder cursar servicios diferenciados, segn el
Modelo DiffServ del IETF. Este modelo define una variedad de
mecanismos para poder clasificar el trfico en un reducido nmero de
clases de servicio, con diferentes prioridades.
Segn los requisitos de los usuarios, DiffServ permite diferenciar servicios
tradicionales tales como el WWW, el correo electrnico o la transferencia de
ficheros (para los que el retardo no es crtico), de otras aplicaciones mucho
ms dependientes del retardo y de la variacin del mismo, como las de
vdeo y voz interactiva.
Para ello se emplea el campo ToS (Type of Service), rebautizado en DiffServ
como el octeto DS. Esta es la tcnica QoS de marcar los paquetes que se
envan a la red.







MPLS se adapta perfectamente a ese modelo, ya que las etiquetas MPLS
tiene el campo EXP para poder propagar la clase de servicio CoS en el
correspondiente LSP.

De este modo, una red MPLS puede transportar distintas clases de trfico,
ya que:

El trfico que fluye a travs de un determinado LSP se puede asignar a
diferentes colas de salida en los diferentes saltos LSR, de acuerdo con la
informacin contenida en los bits del campo EXP.


Comunicaciones de Datos II TECSUP PFR

126
Entre cada par de LSR exteriores se pueden aprovisionar mltiples LSPs,
cada uno de ellos con distintas prestaciones y con diferentes garantas de
ancho de banda. P. ej., un LSP puede ser para trfico de mxima
prioridad, otro para una prioridad media y un tercero para trfico best-
effort, tres niveles de servicio, primera, preferente y turista, que,
lgicamente, tendrn distintos precios.

Cisco IOS 12.1(5)T: compilado para Core DiffServ RFCs (RFCs:
2474,2475,2597,2598):
Plataformas: C72xx, C75xx, C12xxx [12.0(ST)]
MPLS mejoras en QoS
Opera exclusivamente en bits EXP.
Deje el Byte IP ToS Intacto






















6. REFERENCIAS BIBLIOGRFICAS

http://www.mplsforum.org
http://www.mplsrc.com
http://www.ietf.org

Translacion desarrollada para:
CoS = {IP Prec., DSCP, EXP, ATM CLP, F.Relay DE-Bit, 802.1Q/p}
CoS translation = Translation de cualquiera (Except ATM CLP) to Any

Comandos para el Modular QoS CLI:
1) Extendidos matches para class-maps:
match fr-de
match cos <0-7>
match ip precedence n
match ip dscp n
match mpls exp <0-7>
2) Extended sets for policy-maps:
set atm-clp
set fr-de
set cos <0-7>
set ip precedence n
set ip dscp n
set mpls exp n