<?xml version="1.0" encoding="ISO-8859-1"?><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<front>
<journal-meta>
<journal-id>0123-921X</journal-id>
<journal-title><![CDATA[Tecnura]]></journal-title>
<abbrev-journal-title><![CDATA[Tecnura]]></abbrev-journal-title>
<issn>0123-921X</issn>
<publisher>
<publisher-name><![CDATA[Universidad Distrital Francisco José de Caldas]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S0123-921X2011000100004</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[Desempeño de la calidad del servicio (QoS) sobre IPv6]]></article-title>
<article-title xml:lang="en"><![CDATA[Performance of the quality of service (QoS) over IPv6]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Salcedo Parra]]></surname>
<given-names><![CDATA[Octavio José]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[López]]></surname>
<given-names><![CDATA[Danilo]]></given-names>
</name>
<xref ref-type="aff" rid="A02"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Ríos]]></surname>
<given-names><![CDATA[Ángela Patricia]]></given-names>
</name>
<xref ref-type="aff" rid="A03"/>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,Universidad Distrital Francisco José de Caldas  ]]></institution>
<addr-line><![CDATA[Bogotá ]]></addr-line>
<country>Colombia</country>
</aff>
<aff id="A02">
<institution><![CDATA[,Universidad Distrital Francisco José de Caldas  ]]></institution>
<addr-line><![CDATA[Bogotá ]]></addr-line>
<country>Colombia</country>
</aff>
<aff id="A03">
<institution><![CDATA[,ETB  ]]></institution>
<addr-line><![CDATA[Bogotá ]]></addr-line>
<country>Colombia</country>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>01</month>
<year>2011</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>01</month>
<year>2011</year>
</pub-date>
<volume>15</volume>
<numero>28</numero>
<fpage>32</fpage>
<lpage>41</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://www.scielo.org.co/scielo.php?script=sci_arttext&amp;pid=S0123-921X2011000100004&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.co/scielo.php?script=sci_abstract&amp;pid=S0123-921X2011000100004&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.co/scielo.php?script=sci_pdf&amp;pid=S0123-921X2011000100004&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[Las nuevas aplicaciones como VoIP, e-commerce y videoconferencia son sensibles al desempeño de la red y hacen que la capacidad de las redes de proporcionar Calidad de Servicio sea cada vez más importante. IPv6 se fue desarrollado para resolver algunos de los problemas de IPv4, tales como la QoS, la seguridad y el agotamiento de las direcciones IP. Las redes IP actuales proporcionan un envío de tráfico de mejor esfuerzo, por lo tanto, no ofrecen ningún tipo de garantías de Calidad de Servicio. Sin embargo, existen servicios, entre ellos la voz, con rigurosos requisitos de retardo y variación del retardo (jitter), lo que hace necesario añadir funcionalidad a las IP para que las redes basadas en este protocolo sean capaces de soportar este tipo de servicios. Por su parte, IPv6 utiliza dos campos que pueden ser utilizados para implementar QoS: Etiqueta de Flujo y Clase de Tráfico. En este artículo se describen los mecanismos y las arquitecturas que se utilizan para proporcionar Calidad de Servicio en una red. Posteriormente, se especifican las características que utilizan los protocolos IPv4 e IPv6 para implementar QoS. En las últimas secciones, se presentan los resultados de la comparación de dos escenarios, en los cuales se evalúan.]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[New applications such as VoIP, e-commerce and video conferencing are sensitive to network performance, making the network capacity to provide quality of service is increasingly important. IPv6 was developed to solve some of the problems of IPv4, such as QoS, security and IP address exhaustion. Current IP networks provide better traffic delivery effort, therefore, offer no guarantee of quality service. However, there are services, including voice, with stringent requirements for delay and delay variation (jitter), which makes it necessary to add functionality to IP networks based on this protocol are capable of supporting such services. For its part, IPv6 uses 2 fields that can be used to implement QoS, which are: Flow Label and Traffic Class. This article describes the mechanisms and architectures that are used to provide QoS on a network. Later, you specify the features that use both IPv4 and IPv6 to implement QoS. In the last sections present the results of the comparison of 2 scenarios, which are evaluated.]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[DivServ]]></kwd>
<kwd lng="es"><![CDATA[IntSer]]></kwd>
<kwd lng="es"><![CDATA[IPv6]]></kwd>
<kwd lng="es"><![CDATA[QoS]]></kwd>
<kwd lng="en"><![CDATA[DivServ]]></kwd>
<kwd lng="en"><![CDATA[IntSer]]></kwd>
<kwd lng="en"><![CDATA[IPv6]]></kwd>
<kwd lng="en"><![CDATA[QoS]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[  <font face="Verdana" size="2">      <p align="center"><font size="4"><b>Desempe&ntilde;o de la calidad del servicio (QoS) sobre IPv6</b></font></p>     <p align="center"><font size="3"><b><i>Performance of the quality of service (QoS) over IPv6</i></b></font></p>     <p>    <center><b>Octavio Jos&eacute; Salcedo Parra<sup>1</sup>, Danilo L&oacute;pez<sup>2</sup>, &Aacute;ngela Patricia R&iacute;os<sup>3</sup></b></center></p>     <bR>     <p><sup>1</sup>Ingeniero de Sistemas, Mag&iacute;ster en Teleinform&aacute;tica, Mag&iacute;ster en Econom&iacute;a. Docente de la Universidad Distrital Francisco Jos&eacute; de Caldas. Bogot&aacute;, Colombia. <a href="mailto:ojsalcedop@udistrital.edu.co"><u>ojsalcedop@udistrital.edu.co</u></a>    <br> <sup>2</sup>Ingeniero Electr&oacute;nico, Mag&iacute;ster en Teleinform&aacute;tica. Docente de la Universidad Distrital Francisco Jos&eacute; de Caldas. Bogot&aacute;, Colombia. <a href="mailto:dalopezs@udistrital.edu.co"><u>dalopezs@udistrital.edu.co</u></a>    <br> <sup>3</sup>Ingeniera de Sistemas, Mag&iacute;ster en Ciencias de la Informaci&oacute;n y de las Comunicaciones. Ingenier&iacute;a Junior de ETB. Bogot&aacute;, Colombia, <a href="mailto:aprios@gmail.com"><u>aprios@gmail.com</u></a></p>      <p>Fecha de recepci&oacute;n: agosto 21 de 2010, Fecha de aceptaci&oacute;n: febrero 1 de 2011.</p>  <hR>     ]]></body>
<body><![CDATA[<p><font size="3"><b>Resumen</b></font></p>     <p>Las nuevas aplicaciones como VoIP, e-commerce y videoconferencia son sensibles al desempe&ntilde;o de la red y hacen que la capacidad de las redes de proporcionar Calidad de Servicio sea cada vez m&aacute;s importante. IPv6 se fue desarrollado para resolver algunos de los problemas de IPv4, tales como la QoS, la seguridad y el agotamiento de las direcciones IP. Las redes IP actuales proporcionan un env&iacute;o de tr&aacute;fico de mejor esfuerzo, por lo tanto, no ofrecen ning&uacute;n tipo de garant&iacute;as de Calidad de Servicio. Sin embargo, existen servicios, entre ellos la voz, con rigurosos requisitos de retardo y variaci&oacute;n del retardo <i>(jitter), </i>lo que hace necesario a&ntilde;adir funcionalidad a las IP para que las redes basadas en este protocolo sean capaces de soportar este tipo de servicios. Por su parte, IPv6 utiliza dos campos que pueden ser utilizados para implementar QoS: Etiqueta de Flujo y Clase de Tr&aacute;fico.</p>     <p>En este art&iacute;culo se describen los mecanismos y las arquitecturas que se utilizan para proporcionar Calidad de Servicio en una red. Posteriormente, se especifican las caracter&iacute;sticas que utilizan los protocolos IPv4 e IPv6 para implementar QoS. En las &uacute;ltimas secciones, se presentan los resultados de la comparaci&oacute;n de dos escenarios, en los cuales se eval&uacute;an.</p>     <p><b><i>Palabras clave: </i></b>DivServ, IntSer, IPv6, QoS. </p> <hR>     <p><font size="3"><b>Abstract</b></font></p>     <p>New applications such as VoIP, e-commerce and video conferencing are sensitive to network performance, making the network capacity to provide quality of service is increasingly important. IPv6 was developed to solve some of the problems of IPv4, such as QoS, security and IP address exhaustion. Current IP networks provide better traffic delivery effort, therefore, offer no guarantee of quality service. However, there are services, including voice, with stringent requirements for delay and delay variation (jitter), which makes it necessary to add functionality to IP networks based on this protocol are capable of supporting such services. For its part, IPv6 uses 2 fields that can be used to implement QoS, which are: Flow Label and Traffic Class. This article describes the mechanisms and architectures that are used to provide QoS on a network. Later, you specify the features that use both IPv4 and IPv6 to implement QoS. In the last sections present the results of the comparison of 2 scenarios, which are evaluated.</p>     <P><b><i>Key words:</i></b> DivServ, IntSer, IPv6, QoS.</P> <hR>     <p><font size="3"><b>1.   Introducci&oacute;n</b></font></p>     <p>Un aspecto clave tanto para usuarios como para los operadores de redes de comunicaciones es garantizar la calidad de servicio (QoS) prestado en las redes de datos y servicios asociados. Para ello, es necesario realizar medidas que permitan comprobar que las redes est&aacute;n proporcionando el servicio contratado. Con el fin de caracterizar la calidad de servicio, numerosas iniciativas como IP Performance Metrics (IPPM) e IP Flow Information Export (IPFIX) definen m&eacute;tricas y arquitecturas que permiten a todas la partes implicadas llegar a un acuerdo sobre el nivel de calidad de servicio proporcionado y medir su cumplimiento.</p>     <p>Actualmente se dispone de diferentes t&eacute;cnicas para estandarizar y lograr los requerimientos de QoS de las aplicaciones en tiempo real, tales como IntServ, DiffServ y MPLS; las cuales han sido estudiadas para determinar sus ventajas y desventajas &#91;1&#93;.</p>     ]]></body>
<body><![CDATA[<p>Por su parte, el protocolo IPv4 cuenta con el campo Tipo de Servicio (ToS) para que los paquetes con diferentes opciones de ToS se puedan manejar con diversos niveles de servicio dentro de la red. Debido a que no ha sido clara la definici&oacute;n de este campo, se ha dificultado la construcci&oacute;n de mecanismos de control consistentes y su estandarizaci&oacute;n, lo que ha conducido a que el ToS no sea ampliamente utilizado &#91;2&#93;.</p>     <p>Algunos de los problemas asociados con la QoS en IPv4 son: IPv4 proporciona un modelo fijo y limitado para la diferenciaci&oacute;n del tr&aacute;fico, el campo de prioridades s&oacute;lo permite codificar prioridades relativas; el campo Tipo de Servicio es demasiado peque&ntilde;o y no ha sido adoptado, la fragmentaci&oacute;n produce congesti&oacute;n y consume muchos recursos de la red, y el protocolo ICMP tiene demasiadas opciones y produce una sobrecarga en los mecanismos de control &#91;3&#93;. Debido a estas limitaciones, Internet Engineering Task Force (IETF) desarroll&oacute; una nueva versi&oacute;n del protocolo IP, conocido como IPv6 &#91;4&#93; &#91;5&#93;.</p>     <p><font size="3"><b>2.   Calidad de servicio</b></font></p>     <p>La calidad del servicio (QoS) se define como la capacidad de una red para proporcionar diversos niveles de servicio a los diferentes tipos de tr&aacute;fico. Al contar con QoS es posible asegurar una correcta entrega de la informaci&oacute;n, dando preferencia a aplicaciones de desempe&ntilde;o cr&iacute;tico, donde se comparten simult&aacute;neamente los recursos de red con otras aplicaciones no cr&iacute;ticas. QoS hace la diferencia al proveer un uso eficiente de los recursos en caso de presentarse congesti&oacute;n en la red, seleccionando un tr&aacute;fico espec&iacute;fico de &eacute;sta, prioriz&aacute;ndolo seg&uacute;n su importancia relativa, y utilizando m&eacute;todos de control y evasi&oacute;n de la congesti&oacute;n para darles un tratamiento preferencial. Implementando QoS en una red, se logra un rendimiento de &eacute;sta m&aacute;s predecible y una utilizaci&oacute;n de ancho de banda m&aacute;s eficiente.</p>     <p><b><i>2.1.   Niveles de QoS</i></b></p>     <p>Existen tres niveles de servicio: mejor esfuerzo, servicio diferenciado y servicio garantizado.</p> <ol type="a">     <lI>    <p><i> Mejor esfuerzo o best-effort</i>: es cuando la red hace todo lo posible para entregar el paquete a su destino, pero no hay garant&iacute;a de que esto ocurra. Este es el modelo utilizado por las aplicaciones de FTP y HTTP.</p></lI>     <li>    <p><i> Servicios integrados: </i>el modelo de Servicios Integrados provee a las aplicaciones de un nivel garantizado de servicio, negociando par&aacute;metros de red de extremo a extremo. La aplicaci&oacute;n solicita el nivel de servicio necesario con el fin de operar apropiadamente y se basa en la QoS para que se reserven los recursos de red necesarios antes de que la aplicaci&oacute;n comience a operar.</p></li>     ]]></body>
<body><![CDATA[<li>    <p><i>Servicios diferenciados: </i>este incluye un conjunto de herramientas de clasificaci&oacute;n y de mecanismos de cola que proveen a ciertas aplicaciones o protocolos con determinadas prioridades sobre el resto del tr&aacute;fico en la red.</p></li>    </ol>      <p><B><i>2.2.  Administraci&oacute;n de la congesti&oacute;n</i></B></p>     <p>La administraci&oacute;n de la congesti&oacute;n es un t&eacute;rmino que abarca diferentes tipos de estrategias de encolamiento para manejar situaciones donde la demanda de ancho de banda de las aplicaciones excede el ancho de banda total que puede proporcionar la red.</p>     <p><b><i>2.2.1.   FIFO</i></b></p>     <p>Es el tipo m&aacute;s simple de encolamiento, consiste en un b&uacute;fer sencillo que retiene los paquetes salientes hasta que la interfaz de transmisi&oacute;n pueda enviarlos. Los paquetes se env&iacute;an fuera de la interfaz en el mismo orden en el que llegaron al b&uacute;fer.</p>     <p><b><i>2.2.2.&nbsp; &nbsp;Cola de Prioridad (PQ)</i></b></p>     <p>Es un sencillo enfoque para ofrecer un tratamiento preferencial a los paquetes identificados. Los paquetes que llegan a la interfaz se separan en cuatro colas: baja, normal, media y alta prioridad. La salida de estas cuatro colas alimenta un b&uacute;fer de transmisi&oacute;n de la interfaz. Los paquetes siempre se sirven desde las primeras colas de alta prioridad; este mecanismo se ajusta a condiciones donde existe un tr&aacute;fico importante, pero puede causar la total falta de atenci&oacute;n de colas de menor prioridad.</p>     <p><B><i>2.2.3.&nbsp; &nbsp;Cola personalizada (CO)</i></B></p>     ]]></body>
<body><![CDATA[<p>Permite al administrador priorizar el tr&aacute;fico sin los efectos laterales de inanici&oacute;n de las colas de baja prioridad, especificando el n&uacute;mero de paquetes o bytes que deben ser atendidos para cada cola. Se pueden crear hasta 16 colas para categorizar el tr&aacute;fico, donde cada cola es atendida al estilo Round-Robin. CQ ofrece un mecanismo m&aacute;s refinado de encolamiento, pero no asegura una prioridad absoluta como PQ. CQ se utiliza para proveer tr&aacute;ficos particulares de un ancho de banda garantizado en un punto de posible congesti&oacute;n, asegurando una porci&oacute;n fija del ancho de banda y permitiendo al resto del tr&aacute;fico utilizar los recursos disponibles.</p>     <p><B><i>2.2.4.   Weighted Fair Queuing (WFQ)</i></B></p>     <p>Este mecanismo asigna una ponderaci&oacute;n a cada flujo de forma que determina el orden de tr&aacute;nsito en la cola de paquetes. La ponderaci&oacute;n se realiza mediante discriminadores disponibles en TCP/IP (direcci&oacute;n de origen y destino, y tipo de protocolo en IP, n&uacute;mero de Socket -puerto de TCP/UDP-) y por el ToS en el protocolo IP WFQ crea una cola separada para cada tipo de tr&aacute;fico y utiliza un valor predeterminado para la profundidad de la cola.</p>     <p><B><i>2.2.5.   Modified Deficit Round Robin (MDRR)</i></B></p>     <p>Cuando se configura MDDR para encolamiento, las colas que no est&aacute;n vac&iacute;as se atienden una tras otra en forma <i>round robin. </i>Cada vez que una cola es atendida, una cantidad de datos fija es desencolada y entonces el algoritmo atiende la siguiente cola. Cuando una cola es atendida, MDDR hace seguimiento del n&uacute;mero de bytes de datos que fueron desencolados por encima del valor configurado. En el siguiente paso, cuando la cola es atendida nuevamente, menos datos son desencolados para compensar el n&uacute;mero de m&aacute;s que fue atendido en el turno anterior. Como resultado, la cantidad promedio de datos atendidos, por cola, ser&aacute; muy cercano al valor configurado. Adicionalmente, MDDR mantiene una cola prioritaria que se atiende de manera preferencia! &#91;6&#93;.</p>     <p><B><i>2.3.  T&eacute;cnicas para evitar la congesti&oacute;n</i></B></p>     <p>Los mecanismos descritos no solucionan el problema de congesti&oacute;n; &eacute;stos establecen reglas para que el tr&aacute;fico m&aacute;s sensible tenga cierta prioridad sobre el resto del tr&aacute;fico. Por otra parte, las t&eacute;cnicas para evitar congesti&oacute;n monitorean el flujo de tr&aacute;fico de la red con el prop&oacute;sito de anticipar y minimizar su efecto.</p>     <p><B><i>2.3.1.   Random Early Detection (RED)</i></B></p>     <p>Monitorea el tama&ntilde;o de la cola y cuando &eacute;sta alcanza un umbral determinado, selecciona aleatoriamente flujos TCP individuales de los cuales descarta paquetes con el objetivo de indicar al emisor que debe disminuir la tasa de env&iacute;o.</p>     <p><b><i>2.3.2.   Weighted Random Early Detection (WRED)</i></b></p>     ]]></body>
<body><![CDATA[<p>Combina las capacidades del algoritmo RED con la precedencia IP.</p>     <p><B><i>2.4.   Policing y Modelamiento de Tr&aacute;fico (Traffic Shaping)</i></B></p>     <p>Muchas veces es necesario limitar el tr&aacute;fico saliente en una interfaz determinada, con el fin de administrar eficientemente los recursos de la red. Ante esta necesidad existen dos metodolog&iacute;as de limitaci&oacute;n de ancho de banda: Policing y Modelamiento de Tr&aacute;fico (Traffic Shaping). Mediante Policing se especifica la limitaci&oacute;n a un m&aacute;ximo de tasa de transmisi&oacute;n para una Clase de Tr&aacute;fico; si este umbral es excedido, una de las acciones inmediatas ser&aacute; ejecutada: transmitir, descartar, o remarcar. En otras palabras, no es posible almacenar los paquetes para posteriormente enviarlos, como es el caso de Traffic Shaping.</p>     <p>Por otra parte, las t&eacute;cnicas de Traffic Shaping son un poco m&aacute;s diplom&aacute;ticas por la manera como operan. En vez de descartar el tr&aacute;fico que excede cierta tasa determinada, atrasan &aacute;l tr&aacute;fico sobrante a trav&eacute;s de colas, con el fin de modelarla a una tasa que la interfaz remota pueda manejar. El resto del tr&aacute;fico excedente es inevitablemente descartado.</p>     <p>Traffic Shaping (TS) es una buena herramienta en situaciones en las que el tr&aacute;fico saliente debe respetar una cierta ta&aacute;xima de transmisi&oacute;n. Este proceso es realizado independientemente de la velocidad real del circuito; esto significa que es posible modelar tr&aacute;ficos de Web o FTP a velocidades inferiores a las del receptor. TS puede hacer uso de las listas de acceso para clasificar el flujo y puede aplicar pol&iacute;ticas restrictivas de TS a cada flujo. Policing descarta o remarca los paquetes en exceso si es que sobrepasan el l&iacute;mite definido; de esta manera, el tr&aacute;fico que es originado en r&aacute;fagas se propaga por la red, no es suavizado como en TS, y controla la tasa de salida mediante descarte de paquetes, por lo que disminuye el retardo por encolamiento. Sin embargo, debido a estos descartes, el tama&ntilde;o de la ventana deslizante de TCP debe reducirse, afectando as&iacute;  el rendimiento global del flujo &#91;7&#93;.</p>     <p><B><i>2.5.   Clasificaci&oacute;n y marcado</i></B></p>     <p>La clasificaci&oacute;n se utiliza para separar paquetes basados en ciertas caracter&iacute;sticas, tales como la direcci&oacute;n origen y destino, predefiniendo patrones en el campo ToS de 8 bits del encabezado IP (Precedencia IP o DSCP-Differentiated Services Code-Point-), as&iacute;  como tambi&eacute;n pueden estar basados en informaci&oacute;n de protocolos de nivel superior. El campo ToS del encabezado del paquete puede ser reemplazado por los enrutadores con un valor relevante alas pol&iacute;ticas de QoS definidas en la red. Esta acci&oacute;n sobre un paquete se denomina marcado &#91;8&#93;.</p>     <p><font size="3"><b>3.   Arquitecturas de QoS</b></font></p>     <p>Hay 2 arquitecturas de QoS que han sido propuestas y estandarizadas por la IETF. La primera se denomina Servicios Integrados (IntServ) y la segunda, Servicios Diferenciados (DiffServ). IntServ provee QoS a trav&eacute;s de la reserva de recursos a lo largo del camino de datos, antes de iniciar la transmisi&oacute;n de los paquetes. Por otra parte, DiffServ incluye un conjunto de herramientas de clasificaci&oacute;n y de mecanismos de cola que proveen a ciertas aplicaciones o protocolos, determinadas prioridades sobre el resto del tr&aacute;fico en la red.</p>     <p><B><i>3.1.  Servicios Integrados</i></B></p>     ]]></body>
<body><![CDATA[<p>La primera arquitectura propuesta para ofrecer QoS en IP fue la arquitectura de Servicios Integrados o IntServRFC 1633 &#91;9&#93;. &Eacute;sta se basa en garantizar QoS a trav&eacute;s de la reserva de recursos extremo a extremo para cada flujo.</p>     <p>El modelo se sustenta en los siguientes supuestos:</p> <ul>     <lI>    <p> Los recursos se deben gestionar de forma directa y expl&iacute;cita para satisfacer los requerimientos de las aplicaciones. Esto implica la utilizaci&oacute;n de mecanismos para control de admisi&oacute;n y reservaci&oacute;n de recursos.</p></lI>     <li>    <p> Internet debe ser la infraestructura com&uacute;n para el tr&aacute;fico normal y el de tiempo real, ya que construir una nueva red para el tr&aacute;fico de tiempo real ser&iacute;a demasiado complejo. Esto implica que se debe unificar la pila de protocolos para cualquier tipo de tr&aacute;fico, es decir, IP debe ser utilizado tambi&eacute;n para el transporte de datos de tiempo real.</p></li>    </ul>      <p>Cada flujo se debe atender independientemente y no puede influenciar a otros. La arquitectura define dos clases de servicio adicionales al mejor esfuerzo: servicio garantizado y servicio de carga controlada, las cuales especifican el tratamiento que deben recibir los flujos a lo largo del camino. Adem&aacute;s, IntServ requiere que los recursos necesarios para satisfacer los requerimientos de una aplicaci&oacute;n o servicio se reserven sobre el trayecto con anticipaci&oacute;n, para lo cual es necesario el Protocolo de Reservaci&oacute;n de Recursos (RSVP). &Eacute;ste utiliza un conjunto de mensajes de se&ntilde;alizaci&oacute;n para transportar informaci&oacute;n sobre los requerimientos y propiedades de cada flujo, la cual se utiliza para mantener tablas de estado en cada uno de los nodos, generando as&iacute;  un alto tr&aacute;fico de se&ntilde;alizaci&oacute;n y ocupaci&oacute;n de recursos en los dispositivos &#91;10&#93;.</p>     <p><B><i>3.2.   Servicios diferenciados</i></B></p>     <p>DiffServ se basa en la divisi&oacute;n del tr&aacute;fico en un n&uacute;mero limitado de clases de servicio, trasladando el procesamiento m&aacute;s complejo a los nodos de frontera del dominio. DiffServ no necesita que una aplicaci&oacute;n reserve recursos para cada flujo sino que los requerimientos de QoS de los usuarios se especifiquen en un Acuerdo de Nivel de Servicio (SLA)&#91;11&#93;.</p>     ]]></body>
<body><![CDATA[<p>Todo el tr&aacute;fico que ingresa a un dominio DiffServ se clasifica asign&aacute;ndosele un comportamiento de reenv&iacute;o predeterminado denominado Comportamiento por Saltos (PHB) (Per Hop Behavior). Es por esto que los paquetes deben marcarse con un c&oacute;digo que diferencia los distintos comportamientos. La marca se realiza cambiando un campo del encabezado IP, particularmente el tipo de servicio por un c&oacute;digo denominado DSCP que consta de seis bits para diferenciar clases de tr&aacute;fico y dos bits reservados &#91;12&#93;. El c&oacute;digo se asigna en los terminales o en el enrutador de ingreso al dominio DiffServ y se examina en cada uno de los nodos del trayecto con el fin de gestionar colas y controlar los mecanismos de planificaci&oacute;n en los enrutadores.</p>     <p>Se han definido dos PHBs adicionales al mejor esfuerzo que conforman las nuevas clases de servicio que se describen a continuaci&oacute;n. El Reenv&iacute;o Expedito (EF) proporciona un servicio de baja p&eacute;rdida de paquetes, bajo retardo, <i>bajo jitter </i>y ancho de banda asegurado que es equivalente al servicio llamado L&iacute;nea Arrendada Virtual. Los paquetes pertenecientes al PHBEF se marcan con el c&oacute;digo 101110. Por otra parte, el Reenv&iacute;o Asegurado (AF) proporciona una alta probabilidad de que los par&aacute;metros del tr&aacute;fico sean conformes a los acuerdos; aunque se permite que el cliente genere m&aacute;s tr&aacute;fico del acordado, el exceso no ser&aacute; tratado de la misma manera; adem&aacute;s, se definen cuatro clases de AF con diferentes niveles de prioridad y con marcas que permiten saber qu&eacute; paquetes se eliminar&aacute;n primero en caso de congesti&oacute;n.</p>     <p>Es importante se&ntilde;alar que dado a que la marcaci&oacute;n de tr&aacute;fico se realiza en el ingreso al dominio DiffServ, la calidad de servicio se garantiza &uacute;nicamente en una direcci&oacute;n.</p>     <p><font size="3"><b>4.   QoS en IPv6</b></font></p>     <p>El campo ToS fue implementado dentro del grupo de dise&ntilde;o de IPv4 como un campo de ocho bits, compuesto por un valor de precedencia IP de tres bits y cuatro bits indicadores. Su funci&oacute;n es especificar par&aacute;metros de prioridad, retardo, rendimiento y fiabilidad. De este modo, los paquetes con diversas opciones de ToS se pueden manejar con diferentes niveles de servicio dentro de la red.</p>     <p>De acuerdo a la recomendaci&oacute;n RFC 791 &#91;13&#93;, el ToS proporciona una indicaci&oacute;n de los par&aacute;metros de calidad de servicio deseados. &Eacute;stos se utilizan para especificar el tratamiento del datagrama durante su transmisi&oacute;n en una red en particular. Algunas redes ofrecen prioridad de servicio, lo cual consiste en considerar el tr&aacute;fico de alta prioridad como m&aacute;s importante que el resto (generalmente aceptando s&oacute;lo tr&aacute;fico por encima de cierta prioridad en momentos de sobrecarga). La elecci&oacute;n m&aacute;s com&uacute;n es un compromiso de tres factores: bajo retardo, alta fiabilidad y alto rendimiento.</p>     <p>El campo ToS est&aacute; compuesto por un campo de precedencia, tres indicadores D, T, R y dos bits no utilizados; el campo de precedencia utiliza ocho niveles, de cero (rutinaria) a siete (paquete de control de red); los tres bits indicadores permiten especificar qu&eacute; es lo que m&aacute;s interesa, el retardo, el rendimiento o la fiabilidad. A continuaci&oacute;n se presenta un resumen del campo ToS:</p> <ul>     <li>    <p> Bits   0-2 : prioridad.</p></li>     <lI>    ]]></body>
<body><![CDATA[<p> Bit    3:0 = retardo normal, 1 = bajo retardo.</p></lI>     <li>    <p> Bit    4:0 = rendimiento normal, 1 = alto rendimiento.</p></li>     <li>    <p> Bit   5: 0 = fiabilidad normal, 1= alta fiabilidad.</p></li>     <li>    <p> Bits 6-7: reservado para uso futuro.</p></li>    </ul>      <p>El subcampo de precedencia es una medida de importancia relativa al datagrama. Se utilizan ocho-niveles de precedencia. IP tratar&aacute; de proporcionar un tratamiento preferencial a los diagramas con precedencias superiores.</p> <ul>     <li>    ]]></body>
<body><![CDATA[<p> 111-Control de Red</p></li>     <li>    <p> 110-Control Entre Redes</p></li>     <lI>    <p> 101 - CRITICO/ECP</p></lI>     <li>    <p> 100 - Muy urgente (Flash Override)</p></li>     <li>    <p> 011-Urgente (Flash)</p></li>     <lI>    ]]></body>
<body><![CDATA[<p> 010-Inmediato</p></lI>     <li>    <p> 001-Prioridad</p></li>     <li>    <p> 000 - Rutina</p></li>    </ul>      <p>El uso de los indicadores de retardo, rendimiento y Habilidad puede incrementar el coste (en cierto sentido) del servicio. En muchas redes un mejor desempe&ntilde;o de uno de estos par&aacute;metros significa un peor desempe&ntilde;o de otro. Por lo tanto, excepto para casos excepcionales, no se deben establecer m&aacute;s de dos indicadores.</p>     <p>Por su parte, el protocolo IPv6 tiene dos campos que pueden ser utilizados como herramientas para implementar QoS: Etiqueta de Flujo y Clase de Tr&aacute;fico &#91;5&#93;.</p>     <p>    <center><img src="img/revistas/tecn/v15n28/v15n28a04fig1.jpg"></center></p>      ]]></body>
<body><![CDATA[<p>El campo Etiqueta de Flujo de 20 bits en la cabecera IPv6 se agrega para permitir el etiquetado de paquetes que pertenecen a flujos de tr&aacute;fico particulares y puede ser usado por el origen para etiquetar secuencias de paquetes para las cuales solicita un manejo especial por parte de los enrutadores IPv6, tal como la calidad de servicio no est&aacute;ndar o el servicio en tiempo real. Se exige a los <i>hosts </i>o a los enrutadores, que no dan soporte a las fondones del campo Etiqueta de Flujo, poner el campo en cero al enviar un paquete, pasar el campo inalterado al reenviar un paquete e ignorar el campo al recibir un paquete.</p>     <p>El campo de ocho bits Clase de Tr&aacute;fico en la cabecera IPv6 es utilizado por los nodos origen y/o enrutadores intermedios para identificar y distinguir entre las diferentes clases o prioridades de paquetes IPv6; su fond&oacute;n es similar al campo ToS de IPv4.</p>     <p>Los siguientes requisitos generales se aplican al campo Clase de Tr&aacute;fico:</p>  <ul>     <lI>    <p> La interface de servicio para el servicio IPv6 dentro de un nodo debe proporcionar un medio para que un protocolo de capa superior proporcione el valor de los bits Clase de Tr&aacute;fico en los paquetes originados por &eacute;ste. El valor por defecto debe ser cero para todos los ocho bits.</p></lI>     <li>    <p> Los nodos que soportan un uso espec&iacute;fico de algunos o todos los bits Clase de Tr&aacute;fico se les permite cambiarlos en los paquetes que los nodos originan, reenv&iacute;an o reciben, como sea requerido para ese uso espec&iacute;fico. Los nodos deben ignorar y dejar sin alterar los bits del campo Clase de Tr&aacute;fico para los cuales no dan soporte a un uso espec&iacute;fico.</p></li>     <li>    <p>Un protocolo de capa superior no debe asumir que el valor de los bits Clase de Tr&aacute;fico en un paquete recibido es el mismo que el valor enviado por el origen del paquete.</p></li>    </ul>      ]]></body>
<body><![CDATA[<p><font size="3"><b>5.   Simulaci&oacute;n y resultados</b></font></p>     <p><b><i>5.1.   Simulaci&oacute;n</i></b></p>     <p>Se utiliza la herramienta Opnet para simular dos escenarios en los cuales se eval&uacute;a la QoS de la red, la cual est&aacute; compuesta por dos sedes de una empresa, conectadas a trav&eacute;s de un enlace de 1 Mbps y que requieren utilizar un aplicativo de videoconferencia; tambi&eacute;n se utiliza una pol&iacute;tica de tr&aacute;fico en la interfaz saliente del enrutador de Medell&iacute;n para manejar la asignaci&oacute;n de ancho de banda; se emplean listas de control de acceso para clasificar los flujos de tr&aacute;fico en clases de tr&aacute;fico de acuerdo a la direcci&oacute;n origen y a cada flujo se le asigna un porcentaje del ancho de banda.</p>     <p>    <center><img src="img/revistas/tecn/v15n28/v15n28a04fig2.jpg"></center></p>      <p>La diferenciaci&oacute;n de los distintos flujos se hace mediante el campo ToS proporcionado por los datagramas IR Un ToS diferente puede ser seleccionado para cada flujo de tr&aacute;fico definido en la red. Una vez caracterizado en una de las categor&iacute;as IP-ToS, el tr&aacute;fico es etiquetado con el ToS especificado y experimenta un servicio diferenciado en la red. A trav&eacute;s de esta diferenciaci&oacute;n, el tr&aacute;fico sufre un encolamiento que depende del tr&aacute;fico existente en otras colas en las que est&aacute; compitiendo por el mismo interfaz de salida. Para este caso, se utiliza MDRR como mecanismo de encolamiento y cuatro pares de clientes de videoconferencia, cada par usa diferente ToS.</p>     <p><b><i>5.2.   Resultados</i></b></p>     <p>En las siguientes gr&aacute;ficas se muestran los resultados comparando el retardo y el tr&aacute;fico enviado y recibido en cada uno de los dos modelos teniendo en cuenta la prioridad.</p>     <p>En las<a href="#fig3"> Figuras 3</a> y<a href="#fig4"> 4</a> se observa el retardo extremo a extremo para los clientes con menor y mayor prioridad; el cliente con mayor prioridad tiene un retardo menor.</p>      <p>    ]]></body>
<body><![CDATA[<center><a name="fig3"><img src="img/revistas/tecn/v15n28/v15n28a04fig3.jpg"></a></center></p>      <p>    <center><a name="fig4"><img src="img/revistas/tecn/v15n28/v15n28a04fig4.jpg"></a></center></p>      <p>Al utilizar como mecanismo de clasificaci&oacute;n el campo ToS del paquete IPv4 y el campo Clase de Tr&aacute;fico IPv6, se obtienen resultados similares y es posible emplear las mismas t&eacute;cnicas y arquitecturas que se utilizaban en IPv4.</p>     <p>    <center><img src="img/revistas/tecn/v15n28/v15n28a04fig5.jpg"></center></p>     <p>    <center><img src="img/revistas/tecn/v15n28/v15n28a04fig6.jpg"></center></p>      <p><font size="3"><b>6.   Conclusiones</b></font></p>     <p>Tanto los mecanismos como las arquitecturas utilizadas para proveer Calidad de Servicio en una red son implementados de la misma forma en ambas versiones de IP La diferencia entre la QoS de IPv4 e IPv6 se centra en el proceso de clasificaci&oacute;n del tr&aacute;fico en el que los paquetes o flujos son diferenciados a trav&eacute;s de varios par&aacute;metros tales como la direcci&oacute;n de origen o destino, DSCP o los valores de precedencia IP y los tipos de protocolos de nivel superior. IPv6 proporciona mayor facilidad de clasificar los paquetes con identificadores de tr&aacute;fico. Adicionalmente, el campo Etiqueta de Flujo tiene la ventaja de estar localizado antes de los campos de direcci&oacute;n, lo que ayuda a reducir los retardos en la verificaci&oacute;n del paquete.</p> <hR>     ]]></body>
<body><![CDATA[<p><font size="3"><b>Referencias bibliogr&aacute;ficas</b></font></p>     <!-- ref --><p>&#91;1&#93; Internet Protocol versi&oacute;n 6. RFC 2460. Diciembre 1998.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000144&pid=S0123-921X201100010000400001&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;2&#93; <i>An Architecture for Differentiated Services. </i>RFC 2475. Diciembre 1998.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000145&pid=S0123-921X201100010000400002&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;3&#93; C. Popoviciu, E. Levy-Abegnoli, P. Grossetete, "Deploying IPv6 Networks&quot;. <i>Cisco Press, </i>p. 176, 2006.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000146&pid=S0123-921X201100010000400003&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;4&#93; S. &Aacute;lvarez, A. Gonz&aacute;lez, <i>Estudio y Configuraci&oacute;n de Calidad de Servicio para Protocolos IPv4 e IPv6 en una Red de Fibra &Oacute;ptica WDM, </i>&#91;en l&iacute;nea&#93;. Disponible en: <a href="http://www.elo.utfsm.cl/investigacion/publicaciones/2005/QoS_RevIngUTA.pdf" target="_blank">http://www.elo.utfsm.cl/investigacion/publicaciones/2005/QoS_RevIngUTA.pdf</a>.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000147&pid=S0123-921X201100010000400004&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;5&#93; <i>Resource Reservation Protocol. </i>RFC 2208. Septiembre 1997.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000148&pid=S0123-921X201100010000400005&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;6&#93;     A. L&oacute;pez, <i>Calidad de Servicio en IPv6, </i>&#91;en l&iacute;nea&#93;. Disponible en: <a href="http://www.redes-linux.com/manuales/ipv6/alberto_lopez_QoS_tutorial.pdf" target="_blank">http://www.redes-linux.com/manuales/ipv6/alberto_lopez_QoS_tutorial.pdf</a>.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000149&pid=S0123-921X201100010000400006&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;7&#93; M. Flannagan "Administering Cisco QoS for IP Networks", <i>Sungress</i>, 2001.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000150&pid=S0123-921X201100010000400007&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;8&#93; <i>Integrated Services in the Internet Architecture: an Overview. </i>RFC 1633. Junio 1994.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000151&pid=S0123-921X201100010000400008&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;9&#93; E. Fgee, J.D. Kenney, W.J. Phillips, W. Robertson, S. Sivakumar, &quot;Comparison of QoS performance between IPv6 QoS management model and IntServ and DiffServQoS models&quot;, <i>Communication Networks and Services Research Conference, </i>Proceedings of the 3rd Annual. 2005, pp. 287-292. 2005.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000152&pid=S0123-921X201100010000400009&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;10&#93; M. Flannagan, &quot;Administering Cisco QoS for IP Networks (Paperback)&quot;, <i>Syngress, </i>2001.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000153&pid=S0123-921X201100010000400010&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;11&#93; IP Version 6 Working Group (IPv6), &#91;en l&iacute;nea&#93;. Disponible en: <a href="http://www.ietf.org/html.charters/ipv6­charter.html" target="_blank">http://www.ietf.org/html.charters/ipv6-charter.html</a>.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000154&pid=S0123-921X201100010000400011&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;12&#93; <i>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. </i>RFC 2474. Diciembre 1998.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000155&pid=S0123-921X201100010000400012&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p>&#91;13&#93; Internet Protocol DARPA Internet, Program Protocol Specification. RFC 791. Septiembre 1981.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=000156&pid=S0123-921X201100010000400013&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --> ]]></body><back>
<ref-list>
<ref id="B1">
<nlm-citation citation-type="">
<source><![CDATA[Internet Protocol versión 6]]></source>
<year>Dici</year>
<month>em</month>
<day>br</day>
</nlm-citation>
</ref>
<ref id="B2">
<nlm-citation citation-type="">
<source><![CDATA[An Architecture for Differentiated Services]]></source>
<year>Dici</year>
<month>em</month>
<day>br</day>
</nlm-citation>
</ref>
<ref id="B3">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Popoviciu]]></surname>
<given-names><![CDATA[C]]></given-names>
</name>
<name>
<surname><![CDATA[Levy-Abegnoli]]></surname>
<given-names><![CDATA[E]]></given-names>
</name>
<name>
<surname><![CDATA[Grossetete]]></surname>
<given-names><![CDATA[P]]></given-names>
</name>
</person-group>
<source><![CDATA["Deploying IPv6 Networks"]]></source>
<year>2006</year>
<page-range>176</page-range><publisher-name><![CDATA[Cisco Press]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B4">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Álvarez]]></surname>
<given-names><![CDATA[S]]></given-names>
</name>
<name>
<surname><![CDATA[González]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
</person-group>
<source><![CDATA[Estudio y Configuración de Calidad de Servicio para Protocolos IPv4 e IPv6 en una Red de Fibra Óptica WDM]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B5">
<nlm-citation citation-type="">
<source><![CDATA[Resource Reservation Protocol]]></source>
<year>Sept</year>
<month>ie</month>
<day>mb</day>
</nlm-citation>
</ref>
<ref id="B6">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[López]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
</person-group>
<source><![CDATA[Calidad de Servicio en IPv6]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B7">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Flannagan]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
</person-group>
<source><![CDATA["Administering Cisco QoS for IP Networks"]]></source>
<year>2001</year>
<publisher-name><![CDATA[Sungress]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B8">
<nlm-citation citation-type="">
<source><![CDATA[Integrated Services in the Internet Architecture: an Overview]]></source>
<year>Juni</year>
<month>o </month>
<day>19</day>
</nlm-citation>
</ref>
<ref id="B9">
<nlm-citation citation-type="confpro">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Fgee]]></surname>
<given-names><![CDATA[E]]></given-names>
</name>
<name>
<surname><![CDATA[Kenney]]></surname>
<given-names><![CDATA[J.D]]></given-names>
</name>
<name>
<surname><![CDATA[Phillips]]></surname>
<given-names><![CDATA[W.J]]></given-names>
</name>
<name>
<surname><![CDATA[Robertson]]></surname>
<given-names><![CDATA[W]]></given-names>
</name>
<name>
<surname><![CDATA[Sivakumar]]></surname>
<given-names><![CDATA[S]]></given-names>
</name>
</person-group>
<source><![CDATA["Comparison of QoS performance between IPv6 QoS management model and IntServ and DiffServQoS models"]]></source>
<year>2005</year>
<conf-name><![CDATA[ Communication Networks and Services Research Conference, Proceedings of the 3rd Annual]]></conf-name>
<conf-date>2005</conf-date>
<conf-loc> </conf-loc>
<page-range>287-292</page-range></nlm-citation>
</ref>
<ref id="B10">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Flannagan]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
</person-group>
<source><![CDATA["Administering Cisco QoS for IP Networks (Paperback)"]]></source>
<year>2001</year>
<publisher-name><![CDATA[Syngress]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B11">
<nlm-citation citation-type="">
<source><![CDATA[IP Version 6 Working Group (IPv6)]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B12">
<nlm-citation citation-type="">
<source><![CDATA[Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474]]></source>
<year>Dici</year>
<month>em</month>
<day>br</day>
</nlm-citation>
</ref>
<ref id="B13">
<nlm-citation citation-type="">
<source><![CDATA[Internet Protocol DARPA Internet, Program Protocol Specification. RFC 791]]></source>
<year>Sept</year>
<month>ie</month>
<day>mb</day>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
