POLÍTICAS DE QOS PARA INTERFACES TRONCALES DE LOS EQUIPOS METRO Y CORE MPLS DE UNA RED BASADA EN ASON

Transcripción

1 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 de las especificaciones de las políticas de QoS para 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 ; 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 [] Figura. Modelo de Red de dos capas basada en ASON Figura. Topología de Red Concebida Las tablas de mapeo de tráfico a colas en las interfaces de salida incluyen solo el campo de los paquetes MPLS [], 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.. SERVICIOS PRESTADOS Los servicios prestados por las redes de las operadoras son: Servicios Residenciales:. Internet. Video (IPTV, Video On Demand) esta próxima a salir al mercado. VoIP Servicios Corporativos:. Internet IP (IP dedicado). LAN to LAN (VLL y VPLS). VPN IP MPLS. 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 []. 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 Topología de red basado en ASON Next Generation Escenario evaluado de acuerdo al escenario a evaluar.

2 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 pqt (esto es, una cola prioritaria, dos colas concurrentes y dos parámetros de descartes para cada cola), otras son pq8t (esto es, una cola prioritaria y tres colas concurrentes y ocho parámetros de descarte para cada cola), otras son p7q8t, 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 colas en cada interfaz de salida, en la modalidad pqt, para garantizar configuraciones homogéneas. 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.. 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[7]. 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[7].. 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. 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. La arquitectura de QoS en la arquitectura Differentiated Services (DiffServ) definida en las RFC 7 y RFC 7 [9][]. La 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: TC de Entrada: - Classificação Clasificación - Marcação Marcado - Policiamento Policing PHB: PHB: - Filas Colas - Controle de de Congestión Congestionamento TC TC de de Saída: Salida - Filas Colas - Controle de de Congestión Congestionamento - Policiamento Policing, Shaping Figura 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 8.p 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 8.p para bit ó 8.p 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). 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. Ya que los CPE`s no confiables son configurados por el propio cliente, esto significa que la marcación realizada en el paquete

3 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 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... 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,, Video, Datos Críticos, Datos no-críticos, [6]. Según lo expresado anteriormente, en una primera fase de implementación se configurarán todos los equipos de la red con colas en cada interfaz de salida, en la modalidad pqt, para garantizar configuraciones homogéneas [7]. Por consiguiente, las 6 clases de servicio definidas deben ser traducidas en las colas, según lo descrito en el apartado.. 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 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 Video Datos Críticos Datos No Críticos TIPO DE TRÁFICO Tráfico de aplicaciones de Tiempo Real (VoIP, otras) Tráfico TV Broadcast y Video Streaming Tráfico de Gestión Tráfico Datos PLATINO Tráfico de Routing del cliente Tráfico de control de VoD Tráfico de Datos ORO Tráfico de Datos PLATA Tráfico de Datos BRONCE Tráfico Tabla - Asignación sugerida de valores 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. 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 del encabezado de los paquetes MPLS[]. En el ítem.6 se incluye una tabla sugerida de mapeo de valores IP Precedence y DSCP a 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:... 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. Pérdida de paquetes : <,%; Delay: < ms; Jitter: < ms.... 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. Pérdida de paquetes: <, %; Delay: < ms; Jitter: < ms.... 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 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.

4 Pérdida de paquetes: <, %; Delay: < ms; Jitter: < ms.... 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. Pérdida de paquetes: < %; Delay: < ms; Jitter: < ms.... 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. Pérdida de paquetes: < %; Delay: no aplica; Jitter: no aplica... Mecanismos de QoS.... Marcado 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 () del encabezado MPLS, ya que el campo TOS del paquete IP no puede ser leído en una red MPLS []. En caso de utilizar los bits DSCP del campo TOS, existen hasta 6 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. Este comportamiento de identificar el PHB del paquete a través del Exp Field es denominado E-LSP []. Ubicación del campo TOS y correspondencia entre los bits IP Precendence y DSCP: Version Length ToS 8 bits IP- IP- Len ID Offset TTL Proto FCS DATA SA DA 7 6 IP Precedence DS CP Differentiated Service Code Point Bits DiffServ Flow control Figura 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[]. Este comportamiento default solo será evitado configurando un TC que configure el MPLS Exp Field. En el caso de CPEs no confiables, se debe ignorar el marcado del DSCP, y marcar el CoS y 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). 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. Se sugiere mantener una relación uno a uno entre el marcado 8.p (CoS) y el Bit, para garantizar un tratamiento coherente de los tráficos provenientes de la MetroEthernet y del Backbone IP[]. 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 bits. De esta manera, el marcado 8.p 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.... Control de Admisión 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 [] 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.... 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: 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.... 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

5 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 y soporta hasta ocho colas, número suficiente para implementar las clases definidas.... Control de Congestión (Dropping) 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 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. La estrategia tail drop se aplica en casos de aplicaciones noadaptativas como las de la clase. 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. 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 cuando distinto valor es mapeado a la misma cola. Los mecanismos descriptos serán aplicados a las configuraciones de TC en el borde de la red y PHB en interior del backbone IP. La forma de aplicar estos mecanismos a los PHB se detalla en el capítulo siguiente... 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.... Configuración de colas para todas las interfaces troncales COLA q q q q Datos Nombre Control de red 7 6 Drop profile WRED HIGH WRED Tabla Configuración de colas de salida para interfaces con colas... Configuración de colas para interfaces que no soportan COLA q q q Nombre Control de red 7 6 Drop profile WRED HIGH Tabla Configuración de colas de salida para interfaces con colas Dado que 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, se propone la utilización de 6 colas en una fase posterior. Nota: en equipos Juniper M, T y T6 con Enhanced II FPC, es posible utilizar niveles de descarte: Low, Medium-Low, Medium-High y High. Utilizando opcionalmente estos niveles se puede configurar el Drop Profile para las interfaces con y colas asignando correlativamente estas prioridades a los,, y respectivamente. De esta manera se tendrá una mejor priorización del tráfico... Configuración de 6 colas, modelo evolutivo a ser implementado en una segunda fase COLA q q q q q q Video Nombre Control de red Datos críticos Datos no críticos 7 6 Drop profile WRED HIGH WRED WRED Tabla Configuración de colas de salida para interfaces con 6 colas 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. Esta propuesta se basa en las siguientes consideraciones: 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

6 Conclusiones 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, pero esto no es posible en la configuración de 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. 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 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 [] Boudani, Ali. An Effective Solution for Multicast scalability: The MPLS Multicast Tree (MMT). draft-boudani-mpls-multicasttree-.txt. November [] Allied Telesis, Advanced QoS White Paper, marzo 7 [6]Metro Ethernet Forum. Metro Ethernet Network Architecture Framework. Part : Ethernet Services Layer. April doc [7] Frank Brockners. Metro Ethernet Services and standarization. Cisco Networkers. Cannes (France). November [8] Thomas Martin. Metro Ethernet Arquitectures. Cisco Networkers. Cannes (France). November. [9] RFC 7 - Definition of the Differentiated Services Field (DS Field) in the IPv and IPv6 Headers 998 IETF. [] RFC 7 - An Architecture for Differentiated Service 998 IETF. [] David Allan, Nigel Bragg, Alan Mcguire y Andy Reid. Ethernet as Carrier Transport Infrastructure. IEEE Communications Manager. February 6. [] ducts_configuration_guide_chapter986a8679f8.html#wp 89. [] ducts_configuration_guide_chapter986a8679f8.html#wp 868. [] Biyn Raahemi, AnGe, Maher Ali. Metro Ethernet Quality of Services. Alcatel Telecommunications Review. December. [] Michael Beck. Ethernet in the First Mile. MacGraw-Hill.. [6] Ethernet Services Definitions Phase I, Draft v., Metro Ethernet Forum, March. [7] Ethernet Services Definitions Phase I, Draft v., Metro Ethernet Forum, March. CLASE TIPO DE TRÁFICO EJEMPLO DE APLICACIÓN IP Precedence DSCP Tráfico de aplicaciones de Tiempo Real (VoIP, otras) Voz, VideoConferencia EF Video Tráfico TV Broadcast y Video Streaming VideoConferencia, Video Broadcasting, Video Streaming, VoD CS,AF x Datos Críticos Tráfico de Gestión Gestión de elementos de Red, Radius, SNMP CS Tráfico Datos PLATINO SAP, ERP AFx Tráfico de Routing y Gestión de VPN BGP interno del cliente Routing CE-PE 6,7 CS6,CS7 Tráfico de control de VoD RTSP CS Tráfico de Datos ORO SNA AFx Datos No Críticos Tráfico de Datos PLATA FTP, HTTP, SMTP, POP AFx Tráfico de Datos BRONCE de VPN Tráfico Tráfico de Internet Tabla 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. [] Yezid Donoso Meisel, Ramon Fabregat, Multidifusión IP sobre MPLS sin y con QoS Noviembre. [] Ash. LSP Modification Using CR-LDP. RFC. January [] Awduche. RSVP-TE: Extensions to RSVP for LSP Tunnels. RFC 9. December.