Qos

Calidad de Servicio (QoS)
Ampliacin Redes 4-1
ndice
Concepto de Calidad de Servicio Calidad de servicio en LANs Calidad de Servicio en Internet
Modelo IntServ y protocolo RSVP Modelo DiffServ
Control de congestin en Internet MPLS

Ampliacin Redes 4-2
Requerimientos de Calidad de Servicio de las aplicaciones

Aplicacin Correo electrnico Transferencia de ficheros Fiabilidad Retardo Alta (*) Alta (*) Alto Alto Jitter Alto Alto Ancho de Banda Bajo Medio
Acceso Web
Login remoto
Alta (*)
Alta (*)
Medio
Medio
Alto
Medio
Medio
Bajo
Audio bajo demanda

Vdeo bajo demanda Telefona
Media
Media Media
Alto
Alto Bajo
Medio
Medio Bajo
Medio
Alto Bajo
Vdeoconferencia
Media
Bajo
Bajo
Alto
(*) La fiabilidad alta en estas aplicaciones se consigue automticamente al utilizar el protocolo de transporte TCP
Ampliacin Redes 4-3
Congestin y Calidad de Servicio

Sera muy fcil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello habra que sobredimensionar todos los enlaces, cosa no siempre posible o deseable. Para dar QoS con congestin es preciso tener mecanismos que permitan dar un trato distinto al trfico preferente y cumplir el SLA (Service Level Agreement).
Ampliacin Redes 4-4
Efectos de la congestin en el tiempo de servicio y el rendimiento
Tiempo de Servicio
Sin Congestin Congestin Moderada
Congestin Fuerte
Sin Congestin Congestin Moderada
Congestin Fuerte
Carga
QoS intil QoS til y viable QoS inviable QoS intil QoS til y viable
Rendimiento
Carga
QoS inviable
Ampliacin Redes 4-5
Calidad de Servicio (QoS)

Decimos que una red o un proveedor ofrece Calidad de Servicio o QoS (Quality of Service) cuando se garantiza el valor de uno o varios de los parmetros que definen la calidad de servicio que ofrece la red. Si el proveedor no se compromete en ningn parmetro decimos que lo que ofrece un servicio best effort. El contrato que especifica los parmetros de QoS acordados entre el proveedor y el usuario (cliente) se denomina SLA (Service Level Agreement)
Ampliacin Redes 4-6
Parmetros tpicos de los SLAs

Parmetro Significado Ejemplo 99,9% 2 Mb/s 0,1% 80 mseg 20 mseg Disponibilidad Tiempo mnimo que el operador asegura que la red estar en funcionamiento Ancho de Banda Prdida de paquetes Round Trip Delay Jitter Indica el ancho de banda mnimo que el operador garantiza al usuario dentro de su red Mximo de paquetes perdidos (siempre y cuando el usuario no exceda el caudal garantizado) El retardo de ida y vuelta medio de los paquetes La fluctuacin que se puede producir en el retardo de ida y vuelta medio
Ampliacin Redes 4-7
Fluctuacin del retardoJitter

Emisor Red Receptor
Emisor Transmite
t A
50 ms 50 ms
B
90 ms
Congestin
Receptor Recibe
Red vaca
Retardo: 70 ms 20 ms (retardo: 70 ms, jitter: 40 ms)

Ampliacin Redes 4-8
Relacin entre la probabilidad de llegada de los datagramas y los parmetros del SLA
Probabilidad
El tiempo mnimo de propagacin depende de las caractersticas fsicas de la red
Retardo mnimo Retardo medio
Jitter
Tiempo Datagramas considerados perdidos por haberse entregado demasiado tarde
Ampliacin Redes 4-9
Reduccin del Jitter

La principal causa de jitter es la congestin Se puede reducir el jitter aadiendo un retardo adicional en el lado del receptor. Por ejemplo con un retardo de 70 20 ms se puede asegurar jitter 0 si se aade un retardo de 40 ms (90 0 ms). Para el retardo adicional el receptor ha de tener un buffer suficientemente grande. En algunas aplicaciones no es posible aadir mucho retardo pues esto reduce la interactividad. Ej.: videoconferencia, telefona por Internet
Ampliacin Redes 4-10
Calidad de Servicio: Reserva o Prioridad?

Existen dos posibles estrategias para dar trato preferente a un usuario en una red:
Carril BUS: reservar capacidad para su uso exclusivo. A veces se denomina QoS hard. Ej.: VCs ATM con categora de servicio CBR Ambulancia: darle mayor prioridad que a otros usuarios. A veces se denomina QoS soft. Ejemplo: Token Ring
Cada una tiene ventajas e inconvenientes.

Reserva o Prioridad?
Ventajas Inconvenientes
Reserva
Da una garanta casi total Los paquetes no necesitan llevar ninguna marca que indique como han de ser tratados, la informacin la tienen los routers
Los routers no necesitan conservar informacin de estado.
Requiere mantener informacin de estado en todos los routers por lo que pasa la comunicacin Se requiere un protocolo de sealizacin para efectuar la reserva en todo el trayecto
Los paquetes han de ir marcados con la prioridad que les corresponde La garanta se basa en factores estadsticos, es menos segura que la reserva de recursos (puede haber overbooking)
Prioridad
Sumario

QoS en LANs
Desarrollos en 802.1p y 802.1Q Campo prioridad de tres bits. Hasta ocho niveles posibles. Similar al campo prioridad de Token Ring, pero incompatible. No se ha extendido su uso. Dudosa utilidad dada la posibilidad de sobredimensionar a bajo costo Necesidad de acompaarlo de polticas de uso (sistema de contabilidad/facturacin).
Etiquetado de tramas segn 802.1Q

Trama 802.3
Dir. MAC Destino Dir. MAC Origen Ethertype/ Longitud Datos Relleno (opcional)
CRC
Trama 802.1Q
Dir. MAC Destino
Dir. MAC Origen
X8100
Tag
Ethertype/ Longitud Datos
Relleno (opcional)
CRC
El Ethertype X8100 indica protocolo VLAN
Pri
CFI
VLAN Ident.
12
Bits
Pri: Prioridad (8 niveles posibles) CFI: Canonical Format Indicator (indica formato de direcciones MAC) VLAN Ident.: Identificador VLAN (mximo 4096 en una misma red)
Sumario

Calidad de Servicio en Internet

La congestin y la falta de QoS es el principal problema de Internet actualmente. TCP/IP fue diseado para dar un servicio best effort. Existen aplicaciones que no pueden funcionar en una red congestionada con best effort. Ej.: videoconferencia, VoIP (Voice Over IP), etc. Se han hecho modificaciones a IP para que pueda funcionar como una red con QoS
Calidad de Servicio en Internet

El Santo Grial de las redes de computadores es disear una red que tenga la flexibilidad y el bajo costo de la Internet, pero que ofrezca las garantas de calidad de servicio extremo a extremo de la red telefnica.
S. Keshav: 'An Engineering Approach to Computer Networking, 1997
Calidad de servicio en Internet

Se han desarrollado y estandarizado los dos mecanismos de QoS, reserva y prioridad:
IntServ (Integrated Services) y protocolo RSVP. El usuario solicita de antemano los recursos que necesita; cada router del trayecto ha de tomar nota y efectuar la reserva solicitada. DiffServ (Differentiated Services). El usuario marca los paquetes con un determinado nivel de prioridad; los routers van agregando las demandas de los usuarios y propagndolas por el trayecto. Esto le da al usuario una confianza razonable de conseguir la QoS solicitada.
Ambos son compatibles y pueden coexistir

Sumario

Clasificacin de las aplicaciones en IntServ (Integrated Services)

Tolerantes a prdidas Elsticas Datos UDP: DNS, SNMP, NTP, etc. Tiempo Flujos Multimedia en Real modo streaming, videoconferencia, telefona sobre Internet, etc. Intolerantes a prdidas Datos sobre TCP: FTP, Web,e-mail, etc. Emulacin de circuitos (simulacin de lneas dedicadas)
Tipos de servicio en IntServ

Servicio
Garantizado
Caractersticas
Equivalencia en ATM
Garantiza un caudal mnimo y un CBR retardo mximo VBR-rt Cada router del trayecto debe dar garantas A veces no puede implementarse por limitaciones del medio fsico (Ej. Ethernet compartida VBR-nrt
Carga Controlada Calidad similar a la de una red de datagramas poco cargada (Controlled Load) Se supone que el retardo es bajo, pero no se dan garantas Best Effort Ninguna garanta (como antes sin QoS)
UBR
Reparto de recursos en IntServ

Best Effort
Caudal
Carga controlada
Garantizado Tiempo
IntServ y RSVP
Para ofrecer QoS IntServ se basa en la reserva previa de recursos en todo el trayecto Para esa reserva se emplea el protocolo RSVP (Resource ReserVation Protocol) muy relacionado con el modelo IntServ Se supone que la reserva permitir asegurar la QoS solicitada (siempre y cuando la red tenga an recursos suficientes) Normalmente la reserva se realiza para una secuencia de datagramas relacionados entre s, que es lo que llamamos un flujo.
Concepto de flujo
Un flujo es una secuencia de datagramas que se produce como resultado de una accin del usuario y requiere la misma QoS Un flujo es simplex (unidireccional) Un flujo es la entidad ms pequea a la que los routers pueden aplicar una determinada QoS Ejemplo: una videoconferencia estara formada por cuatro flujos, dos en cada sentido, uno para el audio y otro para el vdeo. Los flujos pueden agruparse en clases; todos los flujos dentro de una misma clase reciben la misma QoS.
Flujos en una videoconferencia
A 147.156.135.22
B 158.42.35.13
Flujo vdeo A->B: 147.156.135.22:2056 -> 158.42.35.13:4065 Flujo audio A->B: 147.156.135.22:3567 -> 158.42.35.13:2843 Flujo vdeo B->A: 158.42.35.13:1734 -> 147.156.135.22:6846 Flujo vdeo B->A: 158.42.35.13:2492 -> 147.156.135.22:5387
Agrupacin de flujos
Flujo rojo (128 Kb/s): 147.156.21.20:2038158.26.112.76:2127 Reserva total flujos de vdeo: en sentido X Y: 384 Kb/s Vdeo 128 Kb/s IP: 147.156.21.20 Puerto UDP: 2038
IP: 158.26.112.76 Puerto UDP: 2127
Flujo verde (256 Kb/s): 147.156.47.12:3124158.26.36.97:5753 Vdeo 256 Kb/s IP: 147.156. 47.12 Puerto UDP: 3124
IP: 158.26.36.97 Puerto UDP: 5753
Identificacin de flujos
En IPv4 se hace por:
Direccin IP de origen Puerto de origen Direccin IP de destino Puerto de destino Protocolo de transporte utilizado (TCP o UDP)
En IPv6 la identificacin puede hacerse como en IPv4 o alternativamente usando el campo etiqueta de flujo en vez de los nmeros de puertos. An no hay ninguna implementacin de RSVP que utilice la etiqueta de flujo.
Que es RSVP?
Reserva la capacidad solicitada por un flujo en todos los routers del camino. Es un protocolo de sealizacin (como el utilizado para establecer SVCs en ATM). Requiere guardar informacin de estado en todos los routers del trayecto. Es un servicio orientado a conexin. Est pensado principalmente para trfico multicast No es un protocolo de routing (de eso se ocupar OSPF, IS-IS, PIM-SM, etc.
Componentes de RSVP
Para implementar RSVP los routers han de incorporar cuatro elementos: Admission Control: comprueba si la red tiene los recursos suficientes para satisfacer la peticin. Equivalente al CAC (Connection Admission Control) de ATM. Policy Control: determina si el usuario tiene los permisos adecuados para la peticin realizada (por ejemplo si tiene crdito disponible). La comprobacin se puede realizar consultando una base de datos mediante el protocolo COPS (Common Open Policy Service) Packet Classifier: clasifica los paquetes en categoras de acuerdo con la QoS a la que pertenecen. Cada categora tendr una cola y un espacio propio para buffers en el router. Packet Scheduler: organiza el envo de los paquetes dentro de cada categora (cada cola).
RSVP (Cont.)
RSVP reserva la capacidad solicitada en todos los routers del camino. Cada router ha de mantener el detalle de todas las conexiones activas que pasan por l, y los recursos que cada una ha reservado. El router mantiene informacin de estado sobre cada flujo que pasa por l. Si no se pueden asegurar las condiciones pedidas se rechaza la llamada (control de admisin)
Problemas de IntServ/RSVP
RSVP produjo una euforia inicial (19961997) que luego di paso a la decepcin. La razn principal fueron problemas de escalabilidad debidos a la necesidad de mantener informacin de estado en cada router. Esto hace inviable usar RSVP en grandes redes, por ejemplo en el core de Internet.
Problema de escalabilidad de RSVP

Estos routers han de mantener informacin sobre muchos flujos y por tanto mucha informacin de estado
Core de Internet
Problemas de IntServ/RSVP
Los fabricantes de routers no han desarrollado implementaciones eficientes de RSVP, debido al elevado costo que tiene implementar en hardware las funciones de mantenimiento de la informacin de estado. A pesar de todo RSVP/IntServ puede desempear un papel en la red de acceso, donde los enlaces son de baja capacidad y los routers soportan pocos flujos. Recientemente ha resurgido el inters por RSVP por su aplicacin en MPLS y funciones de ingeniera de trfico. En estos casos el nmero de flujos no suele ser muy grande
Funcionamiento de RSVP en Multicast

Emisor (flujo de 1,5 Mb/s)
1,5 Mb/s
Las reservas se agregan a medida que ascienden en el rbol multicast. As se optimiza el uso de la red (solo se reserva una vez en cada tramo).
1,5 Mb/s
1,5 Mb/s
1,5 Mb/s 1,5 Mb/s
Receptor
Receptor
Receptor
Problemas de RSVP en Multicast

La combinacin de Multicast y RSVP plantea algunos problemas no resueltos, por ejemplo:
Por cuenta de que receptor se efecta el Policy Control en la parte comn del rbol? Si se concede la reserva al primer solicitante, que pasa cuando ese se borra del grupo y quedan otros suscritos? Si no se le concede al primero, que pasa si luego se le concede a otro solicitante? Suponiendo que se cobre por el servicio A quin se le factura el uso de la parte comn? se prorratea entre todos los usuarios activos en ese momento? Eso significa que el precio cambiar con el uso.
RFCs sobre IntServ/RSVP

RFC 1633 (6/1994): Integrated Services in the Internet Architecture: an Overview RFC 2205 (9/1997): RSVP Version 1 Functional Specification RFC 2206 (9/1997): RSVP MIB using SMIv2 RFC 2207 (9/1997): RSVP Extensions for IPSEC Data Flows RFC 2208 (9/1997): RSVP Version 1 Applicability Statement Some Guidelines on Deployment RFC 2209 (9/1997): RSVP Version 1 Message Processing Rules RFC 2210 (9/1997): The Use of RSVP with IETF Integrated Services RFC 2211 (9/1997): Servicio de carga controlada RFC 2212 (9/1997): Servicio Garantizado RFC 2213 (9/1997): Integrated Services Management Information Base Using SMIv2 RFC 2214 (9/1997): Integrated Services MIB Guaranteed Service Extensions using SMIv2 RFC 2215 (9/1997): General Characterization Parameters for Integrated Services RFC 2379 (8/1998): RSVP over ATM Implementation Guidelines RFC 2380 (8/1998): RSVP over ATM Implementation Requirements RFC 2382 (8/1998): A Framework for Integrated Services and RSVP over ATM RFC 2490 (1/1999): A Simulation Model for IP Multicast with RSVP RFC 2688 (9/1997): Integrated Services Mappings for Low Speed Networks RFC 2689 (9/1999): Providing Integrated Services over Low-bitrate Links RFC 2745 (1/2000): RSVP Diagnostic Messages RFC 2746 (1/2000): RSVP Operation over IP Tunnels RFC 2747 (1/2000): RSVP Cryptographic Authentication RFC 2748 (1/2000): The COPS (Common Open Policy Service) Protocol RFC 2749 (1/2000): COPS usage for RSVP RFC 2750 (1/2000): RSVP Extensions for Policy Control RFC 2752 (1/2000): Identity Representation for RSVP RFC 2814 (5/2000): Subnet Bandwidth Manager (para RSVP Admis. Ctrl) RFC 2815 (5/2000): Integrated Service Mappings on IEEE 802 Networks RFC 2816 (5/2000): A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies RFC 2872 (6/2000): Appl. and Sub Appl. Ident. Policy Elem. for RSVP RFC 2961 (4/2001): RSVP Refresh Overhead Reduction Extensions RFC 2996 (11/2000): Format of the RSVP DCLASS Object RFC 2998 (11/2000): A Framework for Integarted Services Operation over Diffserv Networks RFC 3006 (11/2000): Integrated Services in the Presence of Compressible Flows RFC 3097 (4/2001): RSVP Cryptographic Authentication RFC 3175 (9/2001): Aggregation of RSVP for IPv4 and IPv6 Reservations RFC 3182 (10/2001): Identity Representation for RSVP RFC 3209 (12/2001): RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3210 (12/2001): Applicability Statement for Extensions to RSVP for LSP-Tunnels
Sumario

Modelo DiffServ (Differentiated Services)

Intenta evitar los problemas de escalabilidad que plantea IntServ/RSVP. Se basa en el marcado de paquetes nicamente. No hay reserva de recursos por flujo, no hay protocolo de sealizacin, no hay informacin de estado en los routers. Las garantas de calidad de servicio no son tan severas como en IntServ pero en muchos casos se consideran suficientes.
DiffServ
En vez de distinguir flujos individuales clasifica los paquetes en categoras (segn el tipo de servicio solicitado). A cada categora le corresponde un SLA (Service Level Agreement). Los usuarios pueden contratar o solicitar un determinado caudal en la categora que deseen. Los routers tratan cada paquete segn su categora (que viene marcada en la cabecera del paquete). El Policy Control/Admission Control slo se ha de efectuar en los routers de entrada a la red del proveedor y en los que atraviesan fronteras entre proveedores diferentes (normalmente en las fronteras entre sistemas autnomos).
DiffServ
La informacin se puede sumarizar fcilmente ya que todos los flujos quedan clasificados en alguna de las categoras existentes. El nmero de categoras posibles es limitado e independiente del nmero de flujos o usuarios; por tanto la complejidad es constante, no proporcional al nmero de usuarios (decimos que la arquitectura es escalable, o que escala bien). La informacin de QoS no est en los routers sino que cabalga montada en los datagramas.
Version Lon.Cab. TOS Identificacin Tiempo de vida
Longitud total X D M Desplazamiento F F fragmento Protocolo Checksum Direccin de origen Direccin de destino Opciones
Cabecera IPv4 antes de DiffServ

Version Lon.Cab. DS Identificacin Tiempo de vida Longitud total XDM Desplazamiento F F fragmento Protocolo Checksum Direccin de origen Direccin de destino Opciones
Cabecera IPv4 con DiffServ (RFC2474, 12/1998)

Campo TOS (obsoleto)

Campo TOS
Precedencia
Precedencia: prioridad (ocho niveles) D,T,R,C: flags para indicar la ruta que se quiere utilizar: D: Delay (mnimo retardo) T: Throughput (mximo rendimiento) R: Reliability (mxima fiabilidad) C: Cost (mnimo costo) X: bit reservado
Campo DS (RFC 2474)

Campo DS
DSCP
CU
DSCP: Differentiated Services CodePoint. Seis bits que indican el tratamiento que debe recibir este paquete en los routers CU: Currently Unused (reservado). Este campo se utiliza actualmente para control de congestin
Campo DS en IPv6
El campo DS, con igual longitud y formato que en IPv4, se coloca en IPv6 sustituyendo al campo prioridad (de 4 bits) y a los cuatro primeros bits del campo etiqueta de flujo que se reduce de 24 a 20 bits. Los cambios no produjeron problemas ya que ninguno de los dos campos (prioridad ni etiqueta de flujo) se haba utilizado.
Versin Prior. Longitud de carga til
Etiqueta de flujo Sig. Cabecera
Lmite saltos
Direccin de origen (16 bytes)
Direccin de destino (16 bytes)
Cabecera IPv6 antes de DiffServ (RFC 1883)

Versin DS Longitud de carga til Etiqueta de flujo Sig. Cabecera Lmite saltos
Direccin de origen (16 bytes)
Direccin de destino (16 bytes)
Cabecera IPv6 con DiffServ (RFC2474, 12/1998)

Aparicin del campo DS en IPv4 e IPv6

IPv4 Antes
Precedencia D T R C
X
CU
IPv4 e IPv6 Ahora
DSCP
IPv6 Antes
Prioridad
Etiq. de Flujo (1-4)
Los tres primeros bits se interpretan como prioridad en todos los casos
Campo DSCP
6 bits = 64 codepoints (categoras de trfico) diferentes. De momento se han dividido en 3 grupos:
Codepoint xxxyy0 xxxx11 xxxx01
Valores 32 16 16
Uso Estndar Local/experimental Reservado
En el grupo estndar los tres primeros bits (xxx) indican la clase

Tipos de Servicio en DiffServ

Servicio Expedited Forwarding o Premium Caractersticas Es el que da ms garantas. Equivale a una lnea dedicada Garantiza Caudal, tasa de prdidas, retardo y jitter Valor 101110 en DSCP Asegura un trato preferente, pero sin fijar garantas (no hay SLA) Se definen cuatro clases y en cada una tres niveles de descarte de paquetes Sin garantas, pero obtendr trato preferente frente a best effort sin prioridad Equivalencia en ATM CBR VBR-rt
Assured Forwarding
VBR-nrt
Best Effort con prioridad
ABR
Best Effort sin Ninguna garanta, obtiene solo las migajas UBR prioridad
Reparto de recursos en DiffServ

Best Effort sin prioridad Caudal Best Effort con prioridad
Assured Forwarding
Expedited Forwarding o Premium
Tiempo
Servicio EF (Expedited Forwarding, RFC2598)

Es el que da ms seguridad (virtual leased line). Ofrece un SLA (Service Level Agreement) que garantiza:
Un caudal mnimo Una tasa mxima de prdida de paquetes Un retardo mximo Un jitter mximo El valor DSCP es 101110
Servicio AF (Assured Forwarding, RFC2597)

Asegura un trato preferente, pero no garantiza caudales, retardos, etc. Se definen cuatro clases, pudindose asignar una cantidad de recursos (ancho de banda y espacio en buffers) diferente a cada una. En cada clase se definen tres categoras de descarte de paquetes (alta, media y baja). DSCP: cccdd0 (ccc = clase, dd = descarte)
Codepoints del Servicio AF (RFC2597)

Menor probabilidad de descarte Mayor probabilidad de descarte
Precedencia de descarte dd
Clase ccc
Mayor prioridad
Baja 01 10001 01101 01001 00101
Media 10 10010 01110 01010 00110
Alta 11 10011 01111 01011 00111
4 100 3 011 2 010
Menor prioridad
1 001
Traffic Policing en Servicio AF

En el servicio AF el usuario puede contratar con el ISP un caudal para una clase determinada. El ISP puede aplicar traffic policing sobre el trfico del usuario y si se excede jugar con los bits de precedencia de descarte, usndolos de forma parecida al bit DE de Frame Relay o al CLP de ATM. En DiffServ se pueden fijar tres categoras, en funcin de lo gorda que sea la infraccin.
Otros codepoints
Las clases 111 y 110 estn reservadas para paquetes de control de la red y protocolos de routing El DSCP 000000 es por defecto el servicio Best Effort sin prioridad. Otros DSCP de la clase 000 pueden usarse para servicios Best Effort con prioridad.
Valores de codepoint, campo DSCP

111110 111100 111010 111000 110110 110100 110010 110000 101110 101100 101010 101000 100110 100100 100010 100000 Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Reservado (routing y control) Expedited (Premium) Configurable por el usuario Configurable por el usuario Configurable por el usuario Assured Clase 4 Preced. Alta Assured Clase 4 Preced. Media Assured Clase 4 Preced. Baja Configurable por el usuario 011110 011100 011010 011000 010110 010100 010010 010000 001110 001100 001010 001000 000110 000100 000010 000000 Assured Clase 3 Preced. Alta Assured Clase 3 Preced. Media Assured Clase 3 Preced. Baja Configurable por el usuario Assured Clase 2 Preced. Alta Assured Clase 2 Preced. Media Assured Clase 2 Preced. Baja Configurable por el usuario Assured Clase 1 Preced. Alta Assured Clase 1 Preced. Media Assured Clase 1 Preced. Baja Configurable por el usuario Configurable por el usuario Configurable por el usuario Configurable por el usuario Best Effort (default)
Implementacin de DiffServ en los routers
Identificar y separar trfico en las diferentes clases
Descartar trfico que se comporta mal para garantizar la integridad de la red
Marcar trfico, si es necesario. Asigna al DSCP el valor que corresponde
Priorizar, proteger y aislar trfico
Controlar rfagas y conformar trfico
Encolamiento de paquetes en los routers

Cola Expedited Cola Assured 4 Cola Assured 3 WFQ Cola Assured 2 Cola Assured 1 Cola Best Effort FWFQ Lnea de salida PQ
DiffServ
La informacin necesaria para aplicar el Policy Control y Administrative Control es mantenida para toda la red por un elemento denominado el Bandwidth Broker (BB). El BB es el encargado de realizar todos los controles administrativos y gestionar los recursos de red disponibles. El BB puede intercambiar informacin con otros BB de otras redes. Los ISPs pueden acordar polticas de intercambio mutuo.
Arquitectura DiffServ
Origen Bandwidth Brokers (control de admisin, gestionar recursos de red, configurar routers perifricos y fronterizos) Destino
BB
BB
AS ISP 1
Routers core Routers core
AS ISP 2
Router perifrico (controlar, marcar flujos)
Router fronterizo saliente (dosificar agregados)
Router fronterizo entrante (classificar, controlar, marcar aggregados)
Controlar = traffic policing Dosificar = traffic shaping

RFCs Modelo Diffserv

RFC 2430 (10/1998): A Provider Architecture for DiffServ and Traffic Eng. RFC 2474 (12/1998): Definition of the DS field in the IPv4 and IPv6 Headers RFC 2475 (12/1998): An Architecture for Differentiated Service RFC 2597 (6/1999): Servicio Expedited Forwarding RFC 2598 (6/1999): Servicio Assured Forwarding RFC 2638 (7/1999): A Two-bit DiffServ Architecture for the Internet RFC 2963 (10/2000): A Rate Adaptive Shaper for Differentiated Services RFC 2983 (10/2000) Differentiated Services and Tunnels RFC 3086 (4/2001): Def. of DiffServ Per Domain Behaviors & Rules for Spec. RFC 3270 (5/2002): MPLS Support of DiffServ RFC 3287 (7/2002): Remote Monitoring MIB Extensions for DiffServ RFC 3289 (5/2002): Management Information Base for the DiffServ Architect.
IntServ vs DiffServ
IntServ fue desarrollado con anterioridad a DiffServ. Sin embargo DiffServ se ha extendido ms que IntServ DiffServ permite agregar flujos, el modelo es escalable. Debido a estas diferencias muchos fabricantes de routers implementan versiones eficientes de DiffServ, pero no de IntServ. Actualmente muchos ISP implementan DiffServ. Qbone (red expermiental de QoS en Internet 2) utiliza el modelo DiffServ.
RSVP/IntServ vs DiffServ
RSVP/IntServ
Informacin por flujo en cada router Problemas de escalabilidad nfasis en multicast
BB
DiffServ
BB
Cada red tiene un BB que gestiona sus recursos Recursos controlados en punto de acceso Paquetes clasificados por categoras Enfocado a trfico agregado, no a flujos
Combinacin de RSVP y DiffServ

RSVP
DiffServ
RSVP
RSVP
RSVP
En la periferia de la red el uso de RSVP no plantea problemas y puede ser necesaria la reserva estricta de recursos. En este caso el router que conecta con el core traducir la peticin al servicio DiffServ ms parecido.
Referencias QoS
Quality of Service-Fact or Fiction? Geoff Huston, Internet Protocol Journal Vol. 3 N 1. http://www.cisco.com/warp/public/759/ipj_3-1/ipj_31_qos.html Intserv: http://www.ietf.org/html.charters/intserv-charter.html RSVP: http://www.ietf.org/html.charters/rsvp-charter.html . Ver tambin: http://www.isi.edu/rsvp/pub.html Diffserv: http://www.ietf.org/html.charters/diffserv-charter.html Grupo de Trabajo QoS Internet2: http://www.internet2.edu/qos/wg Qbone: http://qbone.internet2.edu B. Teitelbaum: Internet 2 Qbone: A Test Bed for Differentiated Services, http://www.isoc.org/inet99/proceedings/4f/4f_1.htm Proyecto Quantum: http://www.dante.net/quantum
Sumario

Control de congestin en Internet

El mecanismo tradicional de control de congestin en IP es el control que ejerce TCP por medio del slow-start. Este mecanismo solo acta cuando ya se ha perdido algn paquete Cuando los routers empiezan a descartar por llenado de buffers suelen descartar todos los paquetes que les llegan. Esto hace que todas las sesiones TCP ejecuten el slowstart y se cae en un comportamiento oscilante. El rendimiento es malo. Se ha visto que el rendimiento global mejora si se descartan algunos paquetes (al azar) bastante antes de llenar los buffers. Esto obliga a algunas sesiones a realizar el slow-start, pero no todas a la vez. Esto se conoce como RED (Random Early Detect o Random Early Discard)
Mecanismos de Control de Congestin en Internet

Mecanismo Slow Start Consiste en: Cuando un host detecta prdidas reduce el ritmo y se autocontrola. Aplicado a nivel de: Transporte (TCP) Red (IP)
RED (Random Cuando los routers detectan Early Detect) congestin descartan paquetes al azar. Los hosts reducen el ritmo. ECN (Explicit Cuando los routers detectan Congestion congestin notifican a los hosts para Notification) que reduzcan el ritmo.
Red (IP) y Transporte (TCP)
ECN en Internet
El RFC 2481(1/1999) defini el uso de los dos bits libres del campo DS para el subcampo ECN (Explicit Congestion Notification). Tambin se aadieron dos flags en la cabecera TCP. Se especific como un protocolo Experimental El RFC 3168 (7/2001) deja obsoleto al RFC 2481, eleva el ECN al status de Standards Track y aclara algunos puntos Ya hay algunas implementaciones de ECN (Linux)
Campo ECN en IP (RFC 3168)

DSCP ECN
ECN Significado
00
01 10
El Host emisor no soporta ECN.

El Host emisor soporta ECN (caso alternativo). El Host emisor soporta ECN (caso normal).
11
El Host soporta ECN. La red ha marcado congestin.
Formato de los bytes 13 y 14 en la cabecera TCP

Antes de ECN:
4 bits 6 bits
6 bits
Long. Cabecera
Reservado
U A P R S F R C S S Y I G K H T N N Flags
Despus de ECN:
4 bits 4 bits 8 bits
Long. Cabecera
Reservado C E U A P R S F W C R C S S Y I R E G K H T N N Flags
CWR: Congestion Window Reduced ECE: ECN Echo

Funcionamiento de IP y TCP con ECN

1: A enva un paquete a B IP: ECN = 10 TCP: CWR = 0, ECE = 0 2: Router Y recibe el paquete, detecta congestin y cambia ECN IP: ECN = 11 3: B recibe el paquete y detecta que ha habido congestin en el camino (ECN = 11)
1
X
2
Y Z
3 4
5
5: A recibe aviso de B (ECE = 1)
6 7
6: TCP de A reduce su ventana y enva confirmacin a B indicando que ha recibido el aviso IP: ECN = 10 TCP: CWR = 1, ECE = 0
4: TCP de B enva paquete de aviso a A IP: ECN = 10 TCP: CWR = 0, ECE = 1
7: B recibe confirmacin (CWR = 1) y se queda tranquilo (sabe que no ha de insistir con ECE = 1)
ECN en una red que engaa al host

1: A enva paquete a B IP: ECN = 10 TCP: CWR = 0, ECE = 0 3: Router Z recibe paquete, pone ECN = 10 y lo enva a B
2: Router X pone ECN = 00 y lo enva
1
X
Router frontera de ISP
Red del ISP 2 Y Z

Router frontera de ISP Cuando router Y sufra congestin descartar paquetes (nunca cambiar ECN pues la red no lo soporta)
Host B nunca detecta congestin, por tanto nunca pone a 1 flag ECE
ECN alternativo
El caso alternativo funciona igual, salvo que el host pone el segundo bit y el router el primero Con dos posibles maneras de marcar el soporte de congestin en el host resulta mucho ms difcil para el ISP engaar al usuario Por ejemplo en el caso anterior el router Z no sabe si ha de restaurar el ECN 10 o el 01. Para saberlo tendra que preguntar al router de entrada (X) y mantener ambos informacin de estado para cada conexin TCP activa
Funcionamiento de ECN
El bit de congestin de ECN equivale en IP a:
El bit EFCI de ATM (bit intermedio del campo PTI, EFCI=Explicit Forward Congestion Indication) El bit FECN (Forward Explicit Congestion Notification) de Frame Relay
Sumario

Policy routing: El problema del pez

Problema:
Usuario A Tarifa premium Usuario B Tarifa normal Enlaces de alta capacidad El ISP no puede controlar en X que solo vaya por la ruta de alta capacidad el trfico dirigido a C desde A y no el de B C Usuario C
A X B
Backbone del ISP

V W
Enlaces de baja capacidad
Solucin ATM:
Usuario A Tarifa premium Usuario B Tarifa normal
PVC A-C
Y
Al crear diferentes PVCs el ISP puede separar fcilmente el trfico de A del de B
X
B
Backbone del ISP

V W
Usuario C
PVC B-C
Este es un ejemplo de lo que se denomina Ingeniera de Trfico
Problema de los routers IP

Es difcil encaminar eficientemente los datagramas cuando hay que respetar reglas externas, ajenas a la direccin de destino, es decir hay que hacer policy routing o enrutamiento por polticas de uso Resulta difcil hacer Gigarouters eficientes que respeten el policy routing Esto es especialmente crtico en los enlaces troncales de las grandes redes. ATM puede resolver el problema gracias a la posibilidad de fijar la ruta de los datagramas mediante el establecimiento del VC
ATM vs IP
Ventajas de ATM Rpida conmutacin (consulta en tabla de VPI o VPI/VCI) Posibilidad de fijar la ruta segn el origen (ingeniera de trfico) Inconvenientes de ATM SAR (segmentacin y reensamblado). Solo se da en el origen y destino. Overhead (13%) debido al Cell tax (cabecera) encapsulado AAL5, etc.
MPLS
MPLS (Multiprotocol Label Switching) intenta conseguir las ventajas de ATM, pero sin sus inconvenientes Asigna a los datagramas de cada flujo una etiqueta nica que permite una conmutacin rpida en los routers intermedios (solo se mira la etiqueta, no la direccin de destino) Las principales aplicaciones de MPLS son:
Funciones de ingeniera de trfico (a los flujos de cada usuario se les asocia una etiqueta diferente) Policy Routing Servicios de VPN Servicios que requieren QoS
Solucin MPLS al problema del pez

Las etiquetas solo tienen significado local y pueden cambiar a lo largo del trayecto (como los VPI/VCI de ATM)
5 3
5 3 2
V
Usuario A Tarifa premium
Usuario C
7

W
Usuario B Tarifa normal
Los routers X y Z se encargan de etiquetar los flujos segn origen-destino

C ha de distinguir de algun modo los paquetes que enva hacia A o B (puede usar subinterfaces diferentes)
Terminologa MPLS
FEC (Forwarding Equivalence Class): conjunto de paquetes que entran en la red MPLS por la misma interfaz, que reciben la misma etiqueta y por tanto circulan por un mismo trayecto. Normalmente se trata de datagramas que pertenecen a un mismo flujo. Una FEC puede agrupar varios flujos, pero un mismo flujo no puede pertenecer a ms de una FEC al mismo tiempo. LSP (Label Switched Path): camino que siguen por la red MPLS los paquetes que pertenecen a la misma FEC. Es equivalente a un circuito virtual en ATM o Frame Relay. LSR (Label Switching Router) : router que puede encaminar paquetes en funcin del valor de la etiqueta MPLS LIB (Label Information Base): La tabla de etiquetas que manejan los LSR. Relaciona la pareja (interfaz de entrada - etiqueta de entrada) con (interfaz de salida - etiqueta de salida) Los LSR pueden ser a su vez de varios tipos:
LSR Interior: el que encamina paquetes dentro de la red MPLS. Su misin es nicamente cambiar las etiquetas para cada FEC segn le indica su LIB
LSR Frontera de ingreso: los que se encuentran en la entrada del flujo a la red MPLS (al principio del LSP). Se encargan de clasificar los paquetes en FECs y poner las etiquetas correspondientes.
LSR Frontera de egreso: Los que se encuentran a la salida del flujo de la red MPLS (al final del LSP). Se encargan de eliminar del paquete la etiqueta MPLS, dejndolo tal como estaba al principio
Terminologa MPLS
LSPs
LIB
5 5 4 5 3
Y
FECs
4 7
3
4 7
Router IP ordinario (no MPLS enabled)
A Routers IP ordinarios (no MPLS enabled)
2 W
LIB
LIB 3 2 2 7
LSR Frontera de ingreso
LSR Frontera de egreso
LSRs Interiores (V, W, Y)
Creacin de los LSP (Label Switched Path) Se puede hacer:

Por configuracin, de forma esttica (equivalente a los PVCs en ATM) Por un protocolo de sealizacin:
LDP: Label Distribution Protocol RSVP mejorado
El enrutamiento del LSP se hace en base a la informacin que suministra el protocolo de routing, normalmente IS-IS o (ms raramente) OSPF. Siempre se usan algoritmos del estado del enlace, que permiten conocer la ruta completa y por tanto fijar reglas de ingeniera de trfico. Si una vez fijado el LSP falla algn enlace hay que crear un nuevo LSP por otra ruta para poder pasar trfico
Clasificacin del trfico en FECs

Se puede efectuar en base a diferentes criterios, como por ejemplo:
Direccin IP de origen o destino (direccin de host o de red) Nmero de puerto de origen o destino (a nivel de transporte) Campo protocolo de IP (TCP; UDP; ICMP, etc.) Valor del campo DSCP de DiffServ Etiqueta de flujo en IPv6
MPLS
MPLS funciona sobre multitud de tecnologas de nivel de enlace: lneas dedicadas (PPP), LANs, ATM o Frame Relay. En ATM y Frame Relay la etiqueta MPLS ocupa el lugar del campo VPI/VCI o en el DLCI La etiqueta MPLS se coloca delante del paquete de red y detrs de la cabecera de nivel de enlace. Las etiquetas pueden anidarse, formando una pila. Esto permite ir agregando (o segregando) flujos. El mecanismo es escalable.
Formato de la etiqueta MPLS

Bits 20 Etiqueta 3 1 8 TTL
Exp S
Etiqueta: La etiqueta propiamente dicha que identifica una FEC (con significado local) Exp: Bits para uso experimental; una propuesta es transmitir en ellos informacin de DiffServ
S: Vale 1 para la primera entrada en la pila (la ms antigua), cero para el resto
TTL: Contador del nmero de saltos. Este campo reemplaza al TTL de la cabecera IP durante el viaje del datagrama por la red MPLS.
Situacin de la etiqueta MPLS

PPP (Lneas dedicadas)
Cabecera PPP Pila de etiquetas MPLS Cabecera IP Datos Cola PPP
LANs (802.2)
Cabecera MAC
Cabecera LLC
Pila de etiquetas MPLS
Cabecera IP
Datos
Cola MAC
Campo VPI/VCI Etiqueta MPLS Superior Cabecera ATM Campo DLCI Resto de etiquetas MPLS Cabecera IP Datos
ATM
Frame Relay
Etiqueta MPLS Superior Cabecera Frame Relay
Resto de etiquetas MPLS
Cabecera IP
Datos
Cola Frame Relay
Tratamiento del campo TTL

Al entrar un paquete en la red MPLS el router de ingreso inicializa el TTL de la etiqueta al mismo valor que tiene en ese momento la cabecera IP Durante el viaje del paquete por la red MPLS el campo TTL de la etiqueta disminuye en uno por cada salto. El de la cabecera IP no se modifica. A la salida el router de egreso coloca en la cabecera IP el valor del TLL que tena la etiqueta, menos uno Si en algn momento el TTL vale 0 el paquete es descartado Si hay etiquetas apiladas solo cambia el TTL de la etiqueta situada ms arriba. Cuando se aade una etiqueta hereda el valor de la anterior en la pila, cuando se quita pasa su valor (menos uno) a la que tena debajo.
Apilamiento de etiquetas en MPLS

IP (17) IP (17) Paquete IP (TTL)
U
Red MPLS ISP A 4 (16)

V
LSR de Ingreso 2 nivel
2 (15) Etiqueta (TTL) de 1er nivel

LSR de Egreso 2 nivel
7 (14) Etiqueta (TTL) de 2 nivel
2 (15) LSR de Ingreso 1er nivel LSR Interior 1er nivel Los routers U y Z han constituido un LSP con dos LSR interiores, V e Y
Red MPLS ISP B 7 (14) 2 (15)

X
LSR Interior 1er nivel
LSR de Egreso 1er nivel
2 (13)
Y
Para el ISP B parece como si V e Y fueran routers IP ordinarios (no MPLS enabled)
Los routers V e Y estn enlazados por un LSP que ha creado el ISP B. V e Y no ven las etiquetas rojas que manejan W y X
Red MPLS ISP C 8 (12)

Z
En cierto modo es como si entre V e Y se hubiera hecho un tnel que atravesara W y X

IP (11)
Aplicaciones de MPLS
Redes de alto rendimiento: las decisiones de encaminamiento que han de tomar los routers MPLS en base a la LIB son mucho ms sencillas y rpidas que las que toma un router IP ordinario (la LIB es mucho ms pequea que una tabla de rutas normal). La anidacin de etiquetas permite agregar flujos con mucha facilidad, por lo que el mecanismo es escalable. Ingeniera de Trfico: se conoce con este nombre la planificacin de rutas en una red en base a previsiones y estimaciones a largo plazo con el fin de optimizar los recursos y reducir congestin. QoS: es posible asignar a un cliente o a un tipo de trfico una FEC a la que se asocie un LSP que discurra por enlaces con bajo nivel de carga. VPN: la posibilidad de crear y anidar LSPs da gran versatilidad a MPLS y hace muy sencilla la creacin de VPNs. Soporte multiprotocolo: los LSPs son vlidos para mltiples protocolos, ya que el encaminamiento de los paquetes se realiza en base a la etiqueta MPLS estndar, no a la cabecera de nivel de red.
RFCs MPLS
RFC 2702 (9/1999): Requirements for Traffic Engineering Over MPLS RFC 2917 (9/2000): A Core MPLS IP VPN Architecture RFC 3031 (1/2001): MPLS Architecture RFC 3032 (1/2001): MPLS Label Stack Encoding RFC 3035 (1/2001): MPLS using LDP and ATM VC Switching RFC 3036 (1/2001): LDP (Label Distribution Protocol) Specification RFC 3063 (2/2001): MPLS Loop Prevention Mechanism RFC 3270 (5/2002): MPLS Support of DiffServ RFC 3346 (8/2002): Applicability Statement for Traffic Engineering with MPLS RFC 3353 (8/2002): Overview of IP Multicast in a MPLS Environment
Referencias MPLS
MPLS Forum: http://www.mplsforum.org/ MPLS Resource Center: http://www.mplsrc.com/ MPLS Working Group: http://www.ietf.org/html.charters/mplscharter.html Proyecto MPLS for Linux: http://sourceforge.net/projects/mpls-linux/ MPLS. William Stallings, Internet Protocol Journal Vo. 4 N 3 http://www.cisco.com/warp/public/759/ipj_4-3/ipj_4-3_mpls.html MPLS: Una arquitectura de backbone para la Internet del siglo XXI. Jos Barber, Boletn RedIRIS N 53, septiembre 2000. http://www.rediris.es/rediris/boletin/53/enfoque1.html Red MPLS de ONO (Telia) en Espaa: http://www.microsoft.com/spain/download/technet/6onoTechnnet_200 1.ppt

Qos

Cargado por

Copyright:

Formatos disponibles

Qos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Qos

Cargado por

Copyright:

Formatos disponibles

Calidad de Servicio (QoS)

Ampliacin Redes 4-1

Control de congestin en Internet MPLS

Requerimientos de Calidad de Servicio de las aplicaciones

Audio bajo demanda

Ampliacin Redes 4-3

Congestin y Calidad de Servicio

Efectos de la congestin en el tiempo de servicio y el rendimiento

Sin Congestin Congestin Moderada

Sin Congestin Congestin Moderada

Ampliacin Redes 4-5

Calidad de Servicio (QoS)

Ampliacin Redes 4-6

Parmetros tpicos de los SLAs

Ampliacin Redes 4-7

Fluctuacin del retardoJitter

Retardo: 70 ms 20 ms (retardo: 70 ms, jitter: 40 ms)

El tiempo mnimo de propagacin depende de las caractersticas fsicas de la red

Retardo mnimo Retardo medio

Tiempo Datagramas considerados perdidos por haberse entregado demasiado tarde

Ampliacin Redes 4-9

Reduccin del Jitter

Calidad de Servicio: Reserva o Prioridad?

Cada una tiene ventajas e inconvenientes.

Ampliacin Redes 4-12

Control de congestin en Internet MPLS

Ampliacin Redes 4-14

Etiquetado de tramas segn 802.1Q

Dir. MAC Destino

Dir. MAC Origen

Ethertype/ Longitud Datos

El Ethertype X8100 indica protocolo VLAN

Ampliacin Redes 4-15

Control de congestin en Internet MPLS

Calidad de Servicio en Internet

Calidad de Servicio en Internet

Ampliacin Redes 4-18

Calidad de servicio en Internet

Ambos son compatibles y pueden coexistir

Control de congestin en Internet MPLS

Clasificacin de las aplicaciones en IntServ (Integrated Services)

Ampliacin Redes 4-21

Tipos de servicio en IntServ

Reparto de recursos en IntServ

Ampliacin Redes 4-25

Flujos en una videoconferencia

Ampliacin Redes 4-26

IP: 158.26.112.76 Puerto UDP: 2127

IP: 158.26.36.97 Puerto UDP: 5753

Problema de escalabilidad de RSVP

Ampliacin Redes 4-33

Funcionamiento de RSVP en Multicast

Ampliacin Redes 4-35

Problemas de RSVP en Multicast

RFCs sobre IntServ/RSVP

Ampliacin Redes 4-37

Control de congestin en Internet MPLS

Modelo DiffServ (Differentiated Services)

Ampliacin Redes 4-40

Version Lon.Cab. TOS Identificacin Tiempo de vida