2. En redes de Alta velocidad IP con QoS, es necesario especificar el perfil de tráfico para una conexión para decidir cómo asignar los distintos recursos de la red. Estas Redes brindan soporte de conectividad a tráfico con requerimientos de performance muy diferentes: VoIP, videoconferencias, navegación web, transacciones sobre bases de dato, etc. Cada uno de estos tipos de tráfico tiene requerimientos diferentes de ancho de banda, condiciones diferentes de delay, pérdida de paquetes, etc. Poder dar respuesta a diferentes requerimientos de performance sobre una misma infraestructura de red supone la implementación de Calidad de Servicio (QoS). Todo esto debe ser analizado, ya que calidad en redes no es solo marcación de paquetes y redundancia en canales. CALIDAD EN REDES DE ALTA VELOCIDAD
3. Calidad de Servicio de las aplicaciones (*) La fiabilidad alta en estas aplicaciones se consigue automáticamente al utilizar el protocolo de transporte TCP Alto Bajo Bajo Media Vídeoconferencia Bajo Bajo Bajo Media Telefonía Alto Medio Alto Media Vídeo bajo demanda Medio Medio Alto Media Audio bajo demanda Bajo Medio Medio Alta (*) Login remoto Medio Alto Medio Alta (*) Acceso Web Medio Alto Alto Alta (*) Transferencia de ficheros Bajo Alto Alto Alta (*) Correo electrónico Ancho de Banda Jitter Retardo Fiabilidad Aplicación
4.
5. Carga Rendimiento Sin Congestión Congestión Fuerte Congestión Moderada Efectos de la congestión en el tiempo de servicio y el rendimiento Sin Congestión Congestión Fuerte Congestión Moderada Tiempo de Servicio Carga QoS útil y viable QoS inútil QoS inviable QoS útil y viable QoS inútil QoS inviable
6. Parámetros típicos de los SLAs Redes de Alta velocidad 20 mseg La fluctuación que se puede producir en el retardo de ida y vuelta medio Jitter 80 mseg El retardo de ida y vuelta medio de los paquetes Round Trip Delay 0,1% Máximo de paquetes perdidos (siempre y cuando el usuario no exceda el caudal garantizado) Pérdida de paquetes 45 Mb/s Indica el ancho de banda mínimo que el operador garantiza al usuario dentro de su red Ancho de Banda 99,97% Tiempo mínimo que el operador asegura que la red estará en funcionamiento Disponibilidad Ejemplo Significado Parámetro
7.
8. Problemas de enrutamiento Congestión Delay Predecible No predecible Jitter Pérdida de paquetes 100Mbps 100Mbps 100Mbps 155Mbps Buffer End-to-end Delay Delay del enlace Delay del procesa- miento
9. Basado en el análisis de la cabecera del paquete y del resultado de ejecutar un algoritmo de enrutamiento. En cada nodo se repite el cálculo Problema de IP Routing 200.1.2 .1 200.15.16 .3 200.15.16 .4 201.8.9. 4 201.8.9 .8 200.15.16 .30 201.10.11 .3 201.10.11 .20 Host B Datos Host B Datos Host B Datos Host B Datos Red 1 200.1.2 . 0 Red 2 200.15.16 . 0 Red 3 201.8.9 . 0 Red 4 201.10.11 . 0 Host B Host A Host B Datos Host B Datos
15. Clasificación de las aplicaciones en IntServ (Integrated Services) Emulación de circuitos (simulación de líneas dedicadas) Flujos Multimedia en modo ‘streaming’, videoconferencia, telefonía sobre Internet, etc. Tiempo Real Datos sobre TCP: FTP, Web,e-mail, etc. Datos UDP: DNS, SNMP, NTP, etc. Elásticas Intolerantes a pérdidas Tolerantes a pérdidas
24. Problema de escalabilidad de RSVP Estos routers han de mantener información sobre muchos flujos y por tanto mucha información de estado ‘ Core’ de Internet
25.
26. Cabecera IPv4 antes de DiffServ Cabecera IPv4 con DiffServ (RFC2474, 12/1998)
27.
28.
29.
30. Cabecera IPv6 antes de DiffServ (RFC 1883) Cabecera IPv6 con DiffServ (RFC2474, 12/1998)
31. IPv4 Antes IPv6 Antes IPv4 e IPv6 Ahora Aparición del campo DS en IPv4 e IPv6 Los tres primeros bits se interpretan como prioridad en todos los casos DSCP CU Precedencia D T R C X Prioridad Etiq. de Flujo (1-4)
32. Implementación de DiffServ en los routers Identificar y separar tráfico en las diferentes clases Descartar tráfico que se comporta mal para garantizar la integridad de la red Marcar tráfico, si es necesario. Asigna al DSCP el valor que corresponde Priorizar, proteger y aislar tráfico Controlar ráfagas y conformar tráfico
33. Arquitectura DiffServ Router periférico (controlar, marcar flujos) Router fronterizo entrante (classificar, controlar, marcar aggregados) Router fronterizo saliente (dosificar agregados) Routers ‘ core’ Routers ‘ core’ Bandwidth Brokers (control de admisión, gestionar recursos de red, configurar routers periféricos y fronterizos) BB BB Origen Destino Controlar = traffic policing Dosificar = traffic shaping AS ISP 1 AS ISP 2
Es bien sabido que incluso desde una perspectiva de optimizar el uso global de los recursos no es deseable una excesiva carga en los enlaces. Cuando la carga aumenta el tiempo de servicio crece de forma exponencial y como consecuencia de esto las aplicaciones no pueden funcionar o retransmiten la información que creían perdida. Por tanto a partir de un cierto nivel de carga no solo crece el tiempo de servicio, sino que disminuye el rendimiento obtenido del enlace debido a las retransmisiones. El objetivo de la Calidad de Servicio es asegurar que en casos de carga relativamente elevada (la zona marcada como de ‘congestión moderada’ en la gráfica) las aplicaciones que lo requieran podrán disfrutar de un tiempo de servicio reducido. Si la red tiene siempre niveles de carga inferiores el funcionamiento se complica y no se obtiene beneficio al aplicar mecanismos de Calidad de Servicio. Si la red tiene normalmente niveles fuertes de congestión los mecanismos de Calidad de Servicio difícilmente serán capaces de asegurar el nivel de calidad pedido a las aplicaciones que así lo requieran.
Aunque el protocolo RSVP y el modelo IntServ se especificaron hace ya varios años, su uso se ha limitado a experiencias piloto y no se ha extendido entre los fabricantes de routers y por ende entre los proveedores de servicios Internet. En cambio DiffServ y el mecanismo de prioridades, a pesar de ser más reciente, ya está funcionado en varios proveedores de servicios Internet. La razón principal para la acogida de DiffServ y el abandono de IntServ es la escalabilidad de este último y el costo en recursos que representa conservar información de estado sobre cada flujo activo en cada router del trayecto. En los routers del backbone de Internet esto supone mantener tablas con miles de entradas que se han de estar actualizando constantemente. Ningún fabricante de routers ha podido (o ha querido) desarrollar una implementación eficiente de RSVP.