RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL PROTOCOLO …

RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL PROTOCOLO RSVP EN AMBIENTES INTRANET

HOLMES JAHIR GRANADOS NAVARRO

UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION

MAGISTER EN INGENIERIA DE SISTEMAS BOGOTA D.C., JULIO 2003

RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL PROTOCOLO RSVP EN AMBIENTES INTRANET

TESIS DE MAESTRIA PRESENTADA POR: HOLMES JAHIR GRANADOS NAVARRO

DIRIGIDA POR: ING. RAFAEL CAMERANO

Tesis como requisito para optar el título de

Magister en Ingeniería de Sistemas

UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION

MAGISTER EN INGENIERIA DE SISTEMAS BOGOTA D.C., JULIO 2003

PAGINA DE ACEPTACION

______________________

______________________

______________________

______________________

_____________________________ Presidente del Jurado

______________________________ Jurado

_____________________________ Jurado

Bogotá, Agosto de 2003

iii

DEDICATORIA

A Dios, que sabe el trabajo que me costo escribirlo y que nos permite ver la luz todos los dias.

A mi esposita , Yamile, porque me alento en cada instante y me espero con muchisima paciencia.

A Mamá, Papá, Mateo y Glenda, porque son mi soporte y siempre están conmigo.

A mi, por recuperar el tiempo perdido y no fallarme.

iv

AGRADECIMIENTOS

Al Profesor Rafael Camerano, quien con su apoyo y luz permitio que el trabajo se hiciera realidad . Al Profesor German Vega, quien fue clave en el momento de definir los alcances y restricciones del proyecto. A la Direccion de Infraestructura y Planeacion de Bellsouth Colombia, especialmente a los Ingenieros Gonzalo Orjuela y Erick Pinzon, que permitieron reforzar mis conocimientos y recomendaciones sobre el protocolo de reserva de recursos en el estudio de un caso practico. Al Ingeniero Alberto Gaviria de Bellsouth Colombia quien me aterrizo sobre el uso real de RSVP y su experiencia y conocimiento fueron las bases de las recomendaciones practicas. Al Departamento de Ingenieria de Sistemas de la Universidad de los Andes, por la formacion recibida.

v

CONTENIDO

0. INTRODUCCION.................................................................................17 1. QOS: CALIDAD DE SERVICIO ..............................................................18

1.1. DEFINICION ..................................................................................... 18 1.1.1. Factores que afectan la calidad de servicio(Qos) ................................................ 19

1.1.1.1. Retardo.......................................................................................................19 1.1.1.2. Jitter...........................................................................................................19 1.1.1.3. Perdida de paquetes y paquetes en desorden.................................................19 1.1.1.4. Ancho de banda ..........................................................................................20 1.1.1.5. Sincronización de canales y multicast...........................................................20

1.2. ARQUITECTURA BASICA DE QOS .......................................................... 20 1.3. NIVELES DE SERVICIO QOS ................................................................. 22

1.3.1. Servicio Best Effort............................................................................................ 22 1.3.2. Servicio Diferenciado ........................................................................................ 22 1.3.3. Servicio Integrado (Integrated Service)............................................................... 23

1.4. HERRAMIENTAS PARA LA FUNCIONALIDAD QOS...................................... 24 1.4.1. Como Funciona QoS ......................................................................................... 25 1.4.2. Control de Admisión.......................................................................................... 25 1.4.3. Especificación y conformación del tráfico........................................................... 26

1.4.3.1. Algoritmo token bucket...............................................................................27 1.4.4. Clasificación de paquetes .................................................................................. 27 1.4.5. Marcado de paquetes......................................................................................... 29 1.4.6. Priorización...................................................................................................... 29 1.4.7. Planificadores y disciplinas de servicio............................................................... 30

1.4.7.1. Fifo (First In, First Out) ...............................................................................30 1.4.7.2. Cola de Prioridades (Prioritizing Traffic, PQ) ...............................................31 1.4.7.3. Politica Round Robin (Custom Queuing, CQ) ...............................................32 1.4.7.4. Politica Weighted Fair Queueing (WFQ) ......................................................33

1.4.8. Control de congestión........................................................................................ 35 1.4.8.1. RED (Random Early Detection) ...................................................................35 1.4.8.2. WRED (Weighted Random Early Detection) ................................................36

1.4.9. Fragmentación e Inserción(Link Fragmentation and Interleaving) ....................... 36 1.4.10. Incremento de la Eficiencia(RTP-HC) ................................................................ 36 1.4.11. Protocolos de Señalización ............................................................................... 37

1.5. SEÑALIZACION DE QOS ...................................................................... 38 1.5.1. IP Precedence................................................................................................... 39 1.5.2. Protocolo De Reserva de Recursos ..................................................................... 40 1.5.3. Subnetwork Bandwidth Manager (Protocolo SBM).............................................. 40 1.5.4. Calidad de Servicio RSVP-ATM......................................................................... 41

1.6. IMPLEMENTACION DE QOS .................................................................. 42 1.6.1. Nivel de enlace.................................................................................................. 43

1.6.1.1. ATM..........................................................................................................43 1.6.1.2. Frame Relay ...............................................................................................44

1.6.1.3. IEEE 802.1.................................................................................................44 1.6.2. Nivel de red ...................................................................................................... 45

1.6.2.1. Marcado de paquetes...................................................................................45 1.6.2.2. Clasificación de paquetes.............................................................................46 1.6.2.3. Encolamiento de paquetes............................................................................46 1.6.2.4. MPLS.........................................................................................................46

1.6.3. Nivel de Aplicación y de Transporte ................................................................... 47 1.6.3.1. RSVP.........................................................................................................48 1.6.3.2. RTP (Real Time Protocol) ...........................................................................49

1.7. MODELOS DE SERVICIOS.................................................................... 49 1.7.1. Sobreaprovisionamiento de la red ...................................................................... 49

1.8. EL MODELO DE SERVICIOS INTEGRADOS .............................................. 50 1.8.1. Reserva de recursos........................................................................................... 50 1.8.2. Señalización...................................................................................................... 51

1.9. MODELO DE SERVICIOS DIFERENCIADOS.............................................. 52 1.10. ESTRATEGIAS DE APLICACION DE QOS............................................... 55

1.10.1. QoS centrada en la red ...................................................................................... 55 1.10.2. QoS punto a punto -basada en la red................................................................... 55 1.10.3. QoS punto a punto -basado en la aplicación ........................................................ 56

1.11. RESUMEN DE LA ARQUITECTURA PARA QOS........................................ 56 1.11.1. Qos Punto a punto - Integración de Tecnologías .................................................. 57

1.11.1.1. El producto de calidad/eficacia .....................................................................57 1.11.1.2. Integración de tecnologías ...........................................................................58

1.12. VENTAJAS Y EJEMPLOS DE QOS ........................................................ 60 1.12.1. Ejemplo 1: Mejor rendimiento de aplicaciones de misión crítica a través de vínculos WAN.................................................................................................................. 60 1.12.2. Ejemplo 2: Repercusiones del trafico multimedia en la red.................................. 60 1.12.3. Ejemplo 3: Redes de convergencia y compatibilidad multimedia .......................... 61

2. RSVP: PROTOCOLO DE CONFIGURACION DE RESERVA DE RECURSOS...62 2.1. MARCO GENERAL............................................................................... 62 2.2. CARACTERISTICAS Y RESUMEN DE OPERACION...................................... 65

2.2.1. Funcionamiento del protocolo............................................................................ 68 2.2.1.1. Ejemplos ....................................................................................................69 2.2.1.2. Estructura de una implementación RSVP......................................................70

2.3. CLASES DE CALIDAD DE SERVICIO EN RSVP ......................................... 72 2.3.1. Servicio Garantizado......................................................................................... 72

2.3.1.1. Información característica............................................................................72 2.3.1.2. Requerimientos en cada elemento de la red...................................................73 2.3.1.3. Limite del retardo extremo a extremo ...........................................................74

2.3.2. Servicio de carga controlada ............................................................................. 75 2.4. MECANISMOS DE RSVP..................................................................... 76

2.4.1. Las reservas...................................................................................................... 76 2.4.2. Reenvío de reservas........................................................................................... 78 2.4.3. Estilos de reserva .............................................................................................. 78 2.4.4. Creación del camino de datos ............................................................................ 80 2.4.5. Como se realiza la reserva? ............................................................................... 81

2.4.5.1. Tratamiento de la reserva en un nodo............................................................81 2.4.6. Soft State .......................................................................................................... 82

2.4.6.1. Funcionamiento y procesado de los mensajes de refresco..............................82 2.4.6.2. Cancelación del soft state.............................................................................84

2.4.7. OPWA.............................................................................................................. 84 2.4.8. Zonas que no soportan RSVP............................................................................. 85

2.5. MENSAJES RSVP................................................................................ 86 2.5.1. La cabecera ...................................................................................................... 87 2.5.2. Tipos de mensajes RSVP.................................................................................... 88 2.5.3. Los objetos RSVP.............................................................................................. 89 2.5.4. Composición de los mensajes RSVP.................................................................... 90 2.5.5. Composición de los objetos RSVP ...................................................................... 91

2.5.5.1. Objeto Session ............................................................................................91 2.5.5.2. Objeto Rsvp-hop.........................................................................................92 2.5.5.3. Objeto Integrity...........................................................................................92 2.5.5.4. Objeto Time-Values ....................................................................................93 2.5.5.5. Objeto Error-Spec .......................................................................................93 2.5.5.6. Objeto Scope ..............................................................................................94 2.5.5.7. Objeto Style ................................................................................................94 2.5.5.8. Objeto Flowspec .........................................................................................94 2.5.5.9. Objeto Filter-Spec.......................................................................................96 2.5.5.10. Objeto Sender-Template ..............................................................................97 2.5.5.11. Objeto Sender-Tspec...................................................................................97 2.5.5.12. Objeto Adspec ............................................................................................98 2.5.5.13. Objeto policy-data.....................................................................................100 2.5.5.14. Objeto resv-confirm ..................................................................................100

2.6. EJEMPLOS DE QOS Y RSVP ................................................................ 100 2.6.1. QoS para VoIP................................................................................................ 100 2.6.2. QoS para video streaming................................................................................ 102

2.7. PROBLEMAS DE RSVP ....................................................................... 103 2.8. MITOS SOBRE RSVP ......................................................................... 105

2.8.1. Escalabilidad.................................................................................................. 105 2.8.2. Control de admisión........................................................................................ 106 2.8.3. Retardo en el establecimiento de la llamada...................................................... 106

3. IMPLEMENTACION DE RSVP EN INTRANETS: RECOMENDACIONES ....108 3.1. INTRODUCCION .............................................................................. 108 3.2. PUNTOS A TENER EN CUENTA............................................................ 109

3.2.1. Rsvp y servicios integrados en redes LAN......................................................... 109 3.2.2. Motivación a Qos.... no solo mas ancho de banda.............................................. 110 3.2.3. Barreras de implementación de QoS................................................................. 113 3.2.4. Primero QoS, luego RSVP ............................................................................... 114 3.2.5. Las posibilidades de QoS................................................................................. 116 3.2.6. Características de una solución de QoS ........................................................... 119

3.2.6.1. Forzamiento de políticas de QoS punto a punto ..........................................119 3.2.6.2. Múltiples parámetros.................................................................................119 3.2.6.3. Clasificación .............................................................................................119 3.2.6.4. Control Centralizado .................................................................................120 3.2.6.5. Herramientas de administración QoS ..........................................................120

3.2.7. Áreas de aplicación ......................................................................................... 120 3.2.8. Las variables o factores.................................................................................. 122

3.2.8.1. Tipos de aplicaciones y usuarios ................................................................122 3.2.8.2. Tipos de trafico.........................................................................................123 3.2.8.3. Tipos de comunicación ..............................................................................124 3.2.8.4. Inventario de la base instalada ...................................................................124

3.2.8.5. Grado de utilización de la red.....................................................................125 3.2.8.6. Parámetros de calidad de servicio ...............................................................125 3.2.8.7. Modelos de calidad de servicio ..................................................................126 3.2.8.8. Mecanismos de calidad de servicio ............................................................126 3.2.8.9. Productos .................................................................................................128 3.2.8.10. Costos ......................................................................................................128 3.2.8.11. Proveedores de servicios y Tecnología .......................................................128 3.2.8.12. Recurso Humano.......................................................................................129 3.2.8.13. Instalación y Mantenimiento......................................................................129 3.2.8.14. Servicios de soporte ..................................................................................129

3.3. RECOMENDACIONES PARA LA IMPLEMENTACION DE QOS Y RSVP ........... 130 3.3.1. Esquema planteado ......................................................................................... 130 3.3.2. Definición de requerimientos de Qos................................................................ 132

3.3.2.1. Expectativas y antecedentes de QoS ...........................................................135 3.3.2.2. Planes pilotos, ejemplos de productos y estándares......................................136 3.3.2.3. Plan estratégico de calidad de servicio .......................................................136 3.3.2.4. Inventario de la base instalada ....................................................................137 3.3.2.5. Identificación de usuarios y aplicaciones ....................................................138 3.3.2.6. Definición de requerimientos de la estrategia de QoS .................................138 3.3.2.7. Definición e escenarios de aplicación de la estrategia de QoS.......................139

3.3.3. Análisis de los requerimientos de Qos, diseño y modelación............................... 141 3.3.3.1. Caracterización de las aplicaciones.............................................................143 3.3.3.2. Definición de alternativas de QoS ..............................................................144 3.3.3.3. Estudio de viabilidad y costos por estrategia ...............................................147

3.3.4. Desarrollo de la estrategia de Qos ................................................................... 147 3.3.4.1. Selección de la estrategia y características de la solución .............................148 3.3.4.2. Pautas de diseño, instalación e implantación ...............................................150 3.3.4.3. Planes de administración, seguridad y mantenimiento. .................................153

3.3.5. Desarrollo del protocolo RSVP. ....................................................................... 154 3.3.5.1. RSVP en desktops, switches y enrutadores de la capa 3...............................155 3.3.5.2. Soporte parcial en switches de la capa 2, usando priorización de tráfico.......155

3.3.6. Consideraciones sobre la implementación de RSVP........................................... 157 3.4. EJEMPLO DE ESTUDIO: IMPLEMENTACION DE RSVP PARA VOIP EN UN CENTRO DE VENTAS Y SERVICIOS DE BELLSOUTH COLOMBIA ......................... 158

3.4.1. Requerimientos ............................................................................................... 159 3.4.2. Alternativas .................................................................................................... 160 3.4.3. Esquema......................................................................................................... 161 3.4.4. Enseñanzas ..................................................................................................... 164

4. CONCLUSIONES ...............................................................................166

4.1. SOBRE LA ESTRATEGIA DE CALIDAD DE SERVICIO ............................... 166 4.2. SOBRE RSVP................................................................................... 167 4.3. CONSIDERACIONES FINALES............................................................. 168

REFERENCIAS...........................................................................................170 BIBLIOGRAFIA .........................................................................................172

ix

INDICE DE TABLAS Tabla 1. Disciplinas de servicio ......................................................................... 34 Tabla 2. Prioridades IEEE802.1p y tipos de trafico............................................... 44 Tabla 3. Mecanismos QoS y producto QE ........................................................... 58 Tabla 4. Comparación de los modelos IntServ y DiffServ ...................................... 58 Tabla 5. Parámetros de Tspec y Rspec............................................................... 73 Tabla 6. Estilos de reserva .............................................................................. 79 Tabla 7. Información del objeto ADSPEC ............................................................ 85 Tabla 8. Estilos de reserva .............................................................................. 85 Tabla 9. Tipos de mensajes RSVP ..................................................................... 88 Tabla 10. Objetos RSVP ................................................................................. 89 Tabla 11. Objetos RSVP y clases ...................................................................... 91 Tabla 12. Puntos fuertes y débiles de RSVP...................................................... 104 Tabla 13. Beneficios esperados de QoS........................................................... 112 Tabla 14. Razones para no implementar QoS.................................................... 113 Tabla 15. Caracterización de las aplicaciones.................................................... 143 Tabla 16. Consideraciones sobre la estrategia de QoS ....................................... 146 Tabla 17. Dispositivos de la solución VoIP y RSVP ............................................ 163

x

INDICE DE FIGURAS Figura 1. Elementos básicos para la implementación de QoS ................................. 21 Figura 2. Tipos de router ................................................................................ 21 Figura 3. Algoritmo Token Bucket ..................................................................... 27 Figura 4. Clasificación de paquetes en la capa 2................................................. 28 Figura 5. Clasificación de paquetes en la capa 3.................................................. 29 Figura 6. Funcionamiento del algoritmo de la cola con prioridades. ......................... 31 Figura 7. Funcionamiento del planificador Round Robin. ....................................... 32 Figura 8. Asignación de pesos por flujos o clases................................................. 33 Figura 9. Alcance de los mecanismos de señalización de QoS ................................ 39 Figura 10. El campo ToS y los bits de precedencia ............................................... 39 Figura 11. Ubicación de RSVP dentro del modelo de capas de internet................... 48 Figura 12. Red de servicios diferenciados ........................................................... 53 Figura 13. Arquitectura final de QoS ................................................................. 56 Figura 14. Servicios integrados sobre una red Diffserv ......................................... 59 Figura 15. Entrega de flujo de datos RSVP sobre la infraestructura de red. .............. 64 Figura 16. Implementación de RSVP en una red Cisco........................................ 65 Figura 17. RSVP: orientado al receptor y árboles multicast................................... 67 Figura 18. Sesión de distribución multicast......................................................... 67 Figura 19. Reserva de recursos mediante los mensajes PATH y RESV ..................... 68 Figura 20. Ejemplo de RSVP ............................................................................ 69 Figura 21. Videoconferencia con RSVP ............................................................... 70 Figura 22. Servidor y enrutador bajo el protocolo RSVP ........................................ 71 Figura 23. Posición de RSVP dentro del modelo de capas de internet ..................... 71 Figura 24. Elementos de una reserva RSVP ........................................................ 77 Figura 25. Procesamiento de reservas ............................................................... 77 Figura 26. Ejemplos de reservas con los diferentes estilos .................................... 80 Figura 27. Zonas que no soportan RSVP ............................................................ 86 Figura 28. Formato de los mensajes RSVP ......................................................... 87 Figura 29. Mensajes RSVP ............................................................................... 90 Figura 30. Objeto SESSION ............................................................................. 91 Figura 31. Objeto RSVP-HOP ........................................................................... 92 Figura 32. Objeto TIME-VALUES ....................................................................... 93 Figura 33. Objeto ERROR-SPEC........................................................................ 93 Figura 34. Objeto STYLE ................................................................................. 94 Figura 35. Objeto FLOWSPEC........................................................................... 95 Figura 36. Objeto FILTER-SPEC........................................................................ 97 Figura 37. Objeto SENDER-TSPEC .................................................................... 97 Figura 38. Objeto ADSPEC .............................................................................. 99 Figura 39. Objeto RESV_CONFIRM .................................................................. 100 Figura 40. Ejemplo de solución VoIP implementada por Cisco.............................. 101 Figura 41. Ejemplo de video streaming usando RSVP y una malla ATM.................. 102 Figura 42. Flujo de trabajo ............................................................................ 108 Figura 43. Estrategias de Qos para intranets .................................................... 110 Figura 44. Qos: Retos y motivaciones ............................................................. 111 Figura 45. Factores que contribuyen a la importancia de QoS .............................. 112

Figura 46. Barreras para no implementar QoS .................................................. 114 Figura 47. Dimensiones de desarrollo de una estrategia de QoS........................... 116 Figura 48. Implementación de una tecnología de QoS ........................................ 118 Figura 49. Areas de implementación ............................................................... 122 Figura 50. Tipos de tráfico en función de la sensibilidad al retraso o perdida .......... 123 Figura 51. Evolución de una estrategia de QoS ................................................. 130 Figura 52. Fases de una estrategia de QoS....................................................... 131 Figura 53. Definición de requerimientos en una estrategia de QoS........................ 133 Figura 54. Definición de requerimientos en una estrategia de QoS........................ 134 Figura 55. Tareas dentro de la fase de requerimientos ....................................... 135 Figura 56. Tareas dentro de la fase de requerimientos ....................................... 136 Figura 57. Definición de la base instalada dentro de la organización ..................... 138 Figura 58. Un objetivo especifico define un “escenario de aplicación” ................... 140 Figura 59. La fase de análisis en una estrategia de calidad de servicio .................. 141 Figura 60. Técnicas presentes en una estrategia de QoS..................................... 145 Figura 61. Desarrollo de la estrategia de calidad de servicio ................................ 148 Figura 62. Definición de un plan de QoS .......................................................... 148 Figura 63. Selección de la estrategia de calidad de servicio ................................. 149 Figura 64. Instalación de RSVP en desktops y enrutadores de la capa 3 ................ 155 Figura 65. Switches 802.1p/Q que soportan RSVP por priorización de tráfico.......... 156 Figura 66. RSVP y Subnet Bandwiidth Manager(SBM)......................................... 157 Figura 67. Fragmento red telefónica Bellsouth.(Ciudad de Cali) ............................ 160 Figura 68. Un esquema de VoIP y RSVP........................................................... 162 Figura 69. Configuración de enrutador para soporte de RSVP .............................. 164

xii

RESUMEN

Esta tesis trata de calidad de servicio, o sea la capacidad de una red para ofrecerle a las aplicaciones los recursos que requiere. Dentro del amplio tema de calidad de servicio se detalla en particular un mecanismo denominado RSVP(protocolo de reserva de recursos), que permite comunicar y establecer las reservas de recursos en todos los dispositivos de la red. El principal aporte de este trabajo esta en mostrar las herramientas que debe considerar una empresa(ambiente intranet), cuando decide definir un plan de calidad de servicio que le permita responder a las necesidades de sus aplicaciones actuales y futuras. En esta estrategia también se definen los elementos principales a considerar en la implementación del protocolo RSVP, asumiendo que la empresa haya decidido incluirlo dentro de su plan de calidad de servicio.

xiii

ABSTRACT

This document threats about quality of service, in other words, the capacity of a network to bring resources to applications on request. Inside the wide issue of quality of service is detailed a mechanism called RSVP allowing to comunicate and to establish the reservation of resources on all nodes connected to the net. The main importance of this work is to show the tools that a company on an Internet environment must consider at the moment of define a quality service plan allowing it to respond to the needs of their actual and future applications. On this strategy are also defined the main elements to "keep on mind" on the implementation of the RSVP protocol, assuming that the company had previusly decided to include it on its quality of service plan.

xiv

OBJETIVOS

Este trabajo muestra una serie de recomendaciones sobre como implementar una estrategia de calidad de servicio en la red de una organización(intranet). La estrategia de calidad de servicio esta orientada a permitir que cierto trafico sea tratado de forma diferencial, contrario al modelo actual de Internet, donde la red proporciona el mejor servicio posible sin ninguna garantía de ancho de banda, retraso de paquetes o perdida. Particularmente esta tesis persigue los siguientes objetivos:

• Analizar los principales mecanismos y herramientas de calidad de servicio desde el punto de vista de la red, enfocado en un ambiente intranet.

• Realizar una investigación acerca del estado de desarrollo, implementación y

normalización del protocolo de reserva de recursos RSVP.

• Realizar un análisis comparativo de RSVP y otras alternativas disponibles no solo en el campo técnico sino también en el económico.

• Generar una guía inicial que permita definir los parámetros y tareas adecuadas

que deben considerarse para la implementación de una estrategia de calidad de servicio en un ambiente intranet.

• Generar las recomendaciones sobre la estrategia de desarrollo del protocolo

RSVP como parte del plan integral de calidad de servicio de la organización.

xv

ORGANIZACION DEL DOCUMENTO

Este documento esta organizado en 4 capítulos , el primer capitulo esta relacionado con todo el marco teórico respecto al tema de calidad de servicio(QoS), allí se describen las técnicas, los modelos que se pueden utilizar, las tecnologías, la integración de estas tecnologías y el soporte en cada una de las capas del modelo de Internet(enlace, red, transporte, aplicación). El segundo capitulo trata el tema del protocolo de reserva de recursos(RSVP), se describen sus características, los mecanismos y mensajes que utiliza, sus eventuales restricciones y problemas, los niveles de servicio ofrecidos y algunos ejemplos de funcionamiento y aplicación. El tercer capitulo presenta una serie de recomendaciones a la hora de seleccionar e implementar una estrategia de calidad de servicio en un ambiente como intranet; sin pretender ser una guía exhaustiva, se definen las áreas, técnicas, variables y fases que se deben considerar dentro de un plan de implementación. Como parte de la estrategia de QoS definida por la organización, se plantean los elementos puntuales que se requieren para el desarrollo del protocolo de reserva de recursos(RSVP) y se referencia un caso real de implementación; este caso de estudio sirve para ilustrar en términos prácticos las dificultades que se deben superar para desarrollar un método de reserva de recursos y una estrategia de calidad de servicio. El cuarto capitulo resume las experiencias y conclusiones, resultado del estudio y la investigación realizada, enfocadas principalmente en los aportes desde el punto de vista practico. Aunque el énfasis principal es el estudio del protocolo RSVP y su desarrollo en ambientes como intranets, el tema esta muy relacionado con la estrategia de QoS que deba implementar la organización, por ello este documento muestra RSVP como parte integral de una estrategia de calidad de servicio.

xvi

17

0. INTRODUCCION

La arquitectura actual de red basada en el protocolo IP, que gobierna los ambientes internet e intranets ofrece un servicio simple de entrega punto a punto basado en el modelo “best-effort”. Bajo estas condiciones la mayor garantía que ofrece la red es la entrega de datos fiable usando protocolos como TCP,etc. Este modelo funciona para aplicaciones tradicionales, estilo FTP o telnet, donde es mas importante la entrega de los paquetes que el retardo asociado. En la actualidad han surgido nuevas aplicaciones como la videoconferencia , voz sobre IP, realidad virtual que son mucho mas sensibles a la calidad de servicio. Es preferible para este tipo de aplicaciones, la pérdida de un paquete de datos en la red a la introducción de un gran retardo en la entrega de los paquetes; Una estrategia de calidad de servicio esta orientada a permitir que las aplicaciones obtengan de la red el nivel de servicio deseado, como parte de estas estrategia esta el protocolo RSVP definido en el RFC 2205 y cuyo objetivo es permitir que las aplicaciones reserven una cierta cantidad de recursos de la red; RSVP se encarga de crear y mantener estas reservas a través de los árboles de distribución necesarios. La implantación de una estrategia de calidad de servicio en un ambiente incluso pequeño como intranets, es un proceso complejo, la definición de posibles escenarios no es una tarea trivial, y depende de diversas variables como: la tecnología de la red, protocolos subyacentes de la capa de red y enlace, capacidad de enrutadores, aplicaciones y necesidades del usuario, capacidad económica de la empresa, costos, capacidad de servidores y soporte de la estrategia por parte de estos. Por tanto la decisión de implementar o no un plan de calidad de servicio no es una tarea trivial, ya que deben tenerse en cuenta consideraciones técnicas, económicas y culturales. Este documento esta orientado a mostrar en primera medida, las herramientas que puede una empresa utilizar para generar una estrategia de calidad de servicio que cubra las necesidades del plan estratégico de la organización. Dentro de esta estrategia de calidad de servicio, la empresa debe decidir cual técnica utilizara para propagar en la red las peticiones de calidad de servicio que recibe desde las aplicaciones de los usuarios, es en este momento que se analiza el protocolo RSVP, como mecanismo para la señalización de QoS y para la reserva de recursos. En la guía desarrollada ,se definen una serie de fases y estrategias a considerar para que la empresa desarrolle un plan de QoS de acuerdo a sus necesidades, costos y a los productos disponibles en el mercado. Se muestra desde el punto de vista de implementación los elementos a considerar para el desarrollo del protocolo RSVP en un ambiente intranet, las restricciones existentes , los productos y los beneficios asociados a su aplicación.

18

1. QoS: CALIDAD DE SERVICIO

1.1. DEFINICION En los últimos años, las necesidades de los usuarios de computación han tendido a aplicaciones cuyo efecto sobre la red es la posibilidad de integrar voz, video y datos. Estas aplicaciones de tiempo real, que tienen tolerancias limitadas con respecto a los retardos de red, deben convivir con el trafico de datos que no es de tiempo real. Esta convivencia ha planteado nuevos problemas sobre los requerimientos de red. El trafico multimedia es el que presenta los retos mas importantes en términos de la red y normalmente se refiere al trafico compuesto por audio y video. Qos se define como la capacidad de una red para proporcionar mejor servicio a un trafico de red seleccionado, aun cuando esta red disponga de diversos tipos de tecnologías subyacentes, tales como Ethernet y redes 802.1, redes inalámbricas, redes enrutadas IP, ATM y Frame Relay. Es decir, es un mecanismo de tratamiento preferencial a unas clases especificas de trafico, opuesto a la filosofía del modelo “best effort”, actualmente usado en internet (Agarwal,2000, párr. 2) . La calidad de servicio siempre se va a referir de emisor a receptor. Pero ésta va a depender de la calidad de servicio que pueda ofrecer cada subred. Por ello se necesitan mecanismos globales que gestionen esta calidad y negocien con las subredes la calidad de servicio individualmente. Cada subred tiene que proporcionar mecanismos locales de calidad de servicio como puede ser ATM o 802.1p. Así, la calidad de servicio global será consecuencia de las calidades de servicio negociadas en cada una de las subredes. La gestión de calidad de servicio en cada subred vendrá determinada por el modelo de servicio, que podrá ser de servicios integrados o diferenciados. Este modelo determinará como se gestionan los recursos en la subred y la relación con el resto de las subredes. En redes Frame Relay o ATM la calidad de servicio se garantiza mediante un contrato de CIR(Commitated Information Rate) con el usuario. Para disponer de una calidad de servicio aceptable en redes IP se han diseñado herramientas a la medida como el protocolo de tiempo real (RTP) y de reservación (RSVP)(Anonimo, Calidad de servicio en redes IP, párr 1). Qos se encarga de entregar a la red mejores y mas predecible servicios mediante: § Soporte de ancho de banda dedicado § Mejorando la característica de perdida de paquetes § Evitando y manejando la congestión de la red § Organizando el tráfico § Introduciendo prioridades de tráfico a lo largo de la red.

19

1.1.1. Factores que afectan la calidad de servicio(Qos) Según Anjali Agarwall(2000) los siguiente factores pueden impactar la calidad de servicio: retardo, jitter, perdida de paquetes y desorden, ancho de banda. A continuación ilustramos una definición de cada uno de estos términos. 1.1.1.1. Retardo Las demoras normalmente se atribuyen al retardo de acumulación, procesamiento del paquete y retardo de red. El retardo de red se define como el tiempo promedio en que un paquete de datos recorre la red. El retardo se controla con un buen diseño de red que minimice el numero de saltos y por la llegada de dispositivos de switching más rápidos, como switches de la capa3, sistemas de tag switching: sistemas MPLS y switches ATM. La experiencia con los sistemas de conferencia multimedia y los estándares ITU sugieren un retraso máximo de 150 ms en las aplicaciones de video interactivas. En telefonía este retraso es más exigente(<25 ms) para evitar el eco. Para video específicamente, otro tema son los tiempos de compresión y descompresión de las imágenes; el video debe tener de 25 a 30 imágenes por segundos, esto deja un tiempo máximo de compresión-descompresión de 33 a 40 ms, para evitar el solapamiento en la compresión de las imágenes. Restando a los 150 ms (según lo definido por ITU), tanto el tiempo de compresión como de descompresión, nos deja un retraso máximo de 70 a 84 ms para la transmisión en la red. Si a su vez a este valor restamos los retardos por los elementos del enlace(gateway,routers) y asumiendo una ruta de tres saltos LAN-WAN-LAN(que es una topología frecuente), nos queda un retraso máximo aceptable de 10 a 15 ms por salto. Aunque estos cálculos son aproximados y dependen de muchos otros factores, nos dan una aproximación a los problemas de transmisión. 1.1.1.2. Jitter Se define como la variación en el tiempo de llegada entre los paquetes. Remover o eliminar el Jitter requiere recoger los paquetes en búferes y mantenerlos el tiempo suficiente para permitir que el paquete mas demorado llegue a tiempo y se reproduzca en la secuencia correcto. 1.1.1.3. Perdida de paquetes y paquetes en desorden Las redes IP no garantizan la entrega de paquetes, mucho menos en orden, algunos paquetes serán borrados en periodos de congestión y carga. Para transmisión en tiempo real se plantea que el tratamiento y gestión de errores sea a niveles superiores(protocolos de aplicación). En una red en tiempo real , la perdida de paquetes puede ocurrir debido a la saturación de la memoria en los nodos(buffer overrun) o al superar el retraso máximo exigido.

20

1.1.1.4. Ancho de banda Se define como la máxima tasa de transferencia de datos que puede ser sostenida entre dos puntos finales. El trafico multimedia maneja grandes volúmenes de información. Por ejemplo, un CD ROM, con 72 minutos de sonido estéreo, requiere 648 Mbytes y una película de 90 minutos ocuparía 120 Gbytes, ambos sin comprimir(Hernández, 2001, p. 3). Por tanto la información multimedia se trata casi exclusivamente de forma comprimida y el ancho de banda dependerá del tipo de compresión y de la calidad con que se quiera transmitir. Para compresión de video los estándares mas conocidos son MPEG,DVI y H.261; para MPEG y MPEG2 el ancho de banda esta entre 1.2 y 40 Mbps. En el caso de audio, con calidad telefónica el ancho de banda varia de 4 a 32 Kbps(dependiendo de la codificación ADPCM o CELP) y con calidad CD y usando compresión MP3 varía de 32 a 256 kbps. Para el caso especifico de Voz sobre IP se usa un ancho de banda de (64 +16 kbps). 1.1.1.5. Sincronización de canales y multicast Cuando audio y video y otros datos vienen por diferentes canales, se necesitan de mecanismos para la sincronización de los distintos flujos en el destino; esto se supera con una combinación de asignación de tiempos y almacenamiento antes de su visualización y en general este tema no afecta a la red, sino que es responsabilidad del destino. La multidufisión(multicast) es la capacidad de la red para enviar información eficientemente a múltiples destinos; esto es una característica común al tráfico multimedia y permite el ahorro de recursos en la red, al utilizar un único canal, siempre que sea posible compartirlo por todos los receptores(Hernández, 2001, p. 5) . 1.2. ARQUITECTURA BASICA DE QoS Hay 3 puntos fundamentales para la implementación de QoS: Funcionalidad Qos: Esta debe estar disponible en cada elemento simple de la red(enrutador,switches). Técnicas de señalización de Qos(esta tesis estudia solo RSVP): Para coordinar Qos entre los elementos extremos de la red. Normas,manejo y funciones de control QoS: Además de capacidad de administración extremo a extremos de la red. La figura siguiente ( tomada del libro Internetworking Technology Overview, Capitulo 46, Cisco Press, Junio 1999), ilustra los elementos básicos de una implementación QoS.

21

Figura 1. Elementos básicos para la implementación de QoS

En general, para efectos de Qos, no todos los enrutadores tienen la misma estructura y es muy importante la diferenciación entre enrutadores de borde y enrutadores internos1.

Enrutador de borde

Enrutador interno

Figura 2. Tipos de router

Las técnicas de Qos difieren si el enrutador es de borde o interno. Esta diferenciación es mucho mas importante en grandes redes como Internet.

1 Tomado del documento de internet: Evaluación de mecanismos de calidad de servicio en los routers para servicios multimedia

22

Para los enrutadores de borde, este debe tener las capacidades de clasificación de paquetes, control de admisión y administración de la configuración. Para los enrutadores internos las principales capacidades son: el tratamiento de la congestión o la forma como la evita. 1.3. NIVELES DE SERVICIO QoS El nivel de servicio hace referencia a la habilidad de la red para repartir el servicio que se requiere, entre los diferentes tipos específicos de tráfico entre los bordes de la red. Los niveles de servicio se diferencian según el ancho de banda, retardo y perdida de paquetes.

La calidad de servicio puede proporcionarse en 3 niveles, dependiendo del grado deseado punto a punto(Braden,Clark & Shenker,1994 ):

• Best effort • Diferenciado (Diffentiated service) • Servicio Garantizado( o también llamado Integrated Service).

1.3.1. Servicio Best Effort Es el modelo mas sencillo de servicio, la aplicación envía la información en el momento que quiere, en cualquier cantidad, sin ningún permiso y sin informar a la red. A su vez, la red reparte o envía la información si le es posible, sin asegurar ningún retraso , throughput o fiabilidad. En este servicio hay ausencia de QoS, proporciona la conectividad básica sin prioridades o garantías. La entrega de paquetes al enlace se hace en orden FIFO. Ejemplos de este tipo de trafico son las transferencias de archivo. 1.3.2. Servicio Diferenciado En este modelo, el trafico se agrupa o se agrega dentro de un pequeño numero de clases, en el que cada clase recibe una particular QoS en la red. Esta basado en el uso de múltiples clases que satisfacen requerimientos diferentes de QoS. Trata algún tipo de tráfico mejor que el resto; sin embargo no hay una garantía total y definitiva. En este modelo, no se usan señales para especificar los servicios requeridos de la red , esta característica es su principal diferencia con el modelo llamado Integrated Service (que se describe en el siguiente apartado). La red intenta hacer una clasificación basada en una serie de clases de QoS, especificadas en cada paquete. Esta clasificación se puede hacer usando diferentes métodos como IP precedence (Precedencia IP) o DSCP. Este modelo es utilizado para aplicaciones críticas, que necesitan una Qos extremo-extremo diferenciada.

23

Se apoya en algoritmos ya conocidos como CAR para el marcado de paquetes, WFQ para la gestión de colas y WRED para el manejo de la congestión en la red. Detalle de estos algoritmos serán estudiados en un capitulo posterior. 1.3.3. Servicio Integrado (Integrated Service) También es conocido como el servicio Guaranteed level ( servicio garantizado), este ofrece garantía de recursos íntegramente y las aplicaciones realizan una petición de una clase de servicio específica a la red, antes de comenzar a enviar información. La petición se realiza explícitamente, mediante una señalización, de modo que la aplicación informa a la red sobre las características de su tráfico, y pide una clase particular de servicio que se adapte a sus necesidades tanto de ancho de banda como de retraso. La aplicación sólo envía información, una vez recibe la confirmación de la petición por parte de la red. La red realiza un control de admisión , en función de lo que solicita la aplicación y los recursos disponibles en la red. Esta clase de servicio implica una reservación absoluta de recursos de red, típicamente ancho de banda; esto necesariamente esta relacionado con reservaciones en el espacio de buffer de almacenamiento y con apropiadas disciplinas de encolamiento. Este tipo de servicio es para tráfico sensitivo al retardo, tal como voz y video. Caen en este tipo de servicio las aplicaciones que requieren un retardo fijo. La red mantiene información del estado de sí misma por flujos, mirando la clasificación, normas y al algoritmo de cola en cada estado. El mecanismo más importante dentro de la implementación del modelo “Integrated Service” es el protocolo llamado RSVP, que puede ser utilizado por la aplicación para enviar los requerimientos de QoS al enrutador. Con RSVP pueden usarse dos clases de servicio:

• Servicio Garantizado (Guaranteed Rate Service).

• Servicio de Carga Controlada(Controled Load Service) El servicio garantizado permite a las aplicaciones reservar un ancho de banda, y así permite conocer sus requerimientos. Ejemplo: En una aplicación de voz sobre IP (VoIP), puede reservar 32 Mbps de extremo a extremo utilizando esta clase de servicio. Se puede utilizar Weighted Fair Queueing (WFQ) junto con RSVP para proporcionar esta clase de servicio. Este tipo de servicio provee un servicio a los clientes con retardos de encolamiento extremo a extremo matemáticamente probables; posibilita el proveer de un servicio en el que se garantiza, para los paquetes del flujo de datos:

• Que dispondrán de un cierto ancho de banda garantizado. • Que el retardo sufrido por un paquete NUNCA será superior a un cierto retardo

límite. • Y que nunca se producirán perdidas de paquetes (para aquellos paquetes que

estén conformes con las especificaciones del flujo). (Tomado de Burguillos & López,1999,cap.5,p. 87)

24

El servicio de carga controlada, proporciona a las aplicaciones la posibilidad de tener bajos tiempos de retardo y alto throughput en momentos de congestión en la red. Se puede usar RSVP junto con el mecanismo Weighted Random Early Detection(WRED), para poder proporcionar esta clase de servicio. Este servicio proporciona al cliente un flujo de datos con una calidad de servicio aproximadamente igual que la calidad que obtendría el mismo flujo de un elemento de red poco cargado, pero usando un control de admisión para asegurar que dicho servicio se recibe aun cuando el elemento de red se encuentre sobrecargado. Una aplicación que espere recibir este tipo de servicio deberá asumir que:

• Un gran porcentaje de los paquetes transmitidos serán entregados sin problemas por la red.(El porcentaje de paquetes perdidos se debe aproximar a la tasa de errores de paquete básica del medio de transmisión)

• El retardo de transito experimentado por la mayoría de los paquetes entregados

no deberá diferir demasiado respecto al retardo mínimo que experimente la entrega de un único paquete(Burguillos & López,1999 ,cap.5,p. 85)

Decidir cual tipo de servicio es apropiado para desarrollar en la red, depende de varios factores:

• La aplicación o el problema que el cliente esta tratando de resolver. Cada uno de los 3 tipos es apropiado para ciertas aplicaciones. Esto no necesariamente implica que un cliente debe migrar a servicio diferenciado y luego a servicio garantizado(aunque normalmente ocurrirá). Un servicio diferenciado o aun un servicio “best-effort” puede ser apropiado dependiendo de los requerimientos de aplicación del cliente.

• La tasa a la cual los clientes pueden actualizar sus infraestructuras; hay una

ruta de actualización de estas infraestructura desde la tecnología necesaria para proporcionar servicios diferenciados hasta los requerimientos técnicos para proporcionar servicios garantizados, que es una ampliación de lo que se requiere para servicios diferenciados.

• El costo de implementar y desarrollar servicio garantizado es mayor que

implementar servicio diferenciado. 1.4. HERRAMIENTAS PARA LA FUNCIONALIDAD QoS Las herramientas QoS son muy variadas y actúan sobre los diferentes niveles (enlace, red, transporte, etc.). Pueden ser tanto tratamiento de colas con preferencias, protocolos de reserva de ancho de banda, mecanismos contra la congestión, etc., dependiendo de los problema específicos que se quieran resolver.

25

1.4.1. Como Funciona QoS Las aplicaciones generan trafico de red a ritmos variables y requieren que la red transporte los datos a la velocidad que estas necesitan, algunas son mas o menos tolerantes a retrasos en la entrega de sus paquetes o incluso a la perdida de alguno de ellos, si los recursos de red fueran infinitos, cada aplicación obtendría exactamente lo que requiere, al ritmo requerido, sin latencia y sin perdidas, sin embargo, la realidad es que hay partes de la red donde los recursos no pueden responder a la demanda. Las redes se conforman por la unión de dispositivos como enrutadores, switches, modificadores, los cuales, intercambian trafico entre ellos, mediante interfaces. Si una interfaz de salida, en un dispositivo, envía trafico a una velocidad inferior que el trafico entrante, se produce congestión. La capacidad de una interfaz para enviar trafico a la red, constituye un recurso de red fundamental. Los mecanismos de QoS funcionan al establecer preferencias en la asignación de este recurso en favor de cierto tráfico. Para poder realizar esto, es necesario identificar tráficos diferentes. El tráfico que llega a los dispositivos se separa en distintos flujos mediante el proceso de clasificación de paquetes. El trafico de cada flujo se envía a una cola en la interfaz de salida, las colas utilizan para su gestión distintos algoritmos, los cuales determinan la velocidad a la que se reenvía el tráfico de cada cola. De esta forma, se determinan los recursos que se asignan a cada cola y a los flujos correspondientes.

Para proporcionar QoS en redes, es necesario configurar y proporcionar a los dispositivos de red lo siguiente (Resumen de los mecanismos de Qos y cómo inter operan, Microsoft 1999,párrafo 11)

§ Información de clasificación para que los dispositivos separen el trafico en flujos

§ Colas y algoritmos de administración de estas (scheduling )que controlen el trafico de los diferentes flujos

Ambas características, constituyen los mecanismos de control de tráfico, estos mecanismos deben proporcionarse o configurarse para todos los dispositivos de red, de una forma coordinada, para asegurar QoS de un extremo a otro. Para proporcionar servicios útiles, se requieren tanto los mecanismos de control de tráfico como los mecanismos de provisión y configuración, también denominados mecanismos de señalización de QoS (RSVP es el protocolo mas representativo e importante de los mecanismos de señalización y es el objeto de estudio de esta tesis). 1.4.2. Control de Admisión El control de admisión determina si el requerimiento de una conexión, esta permitido que sea transportado por la red. Si la red no puede aceptar un determinado trafico porque no lo puede gestionar o afectase al resto de los tráficos, no debería admitirlo. Las principales condiciones detrás de la decisión de aceptación son la carga de tráfico actual, la calidad de servicio(QoS) actual, el perfil de trafico requerido, La calidad de servicio(QoS)

26

requerida y otras consideraciones adicionales de precios o estrategias. Para que las redes IP cumplan con la calidad de servicio requerida, el control de admisión debe ejecutarse en la configuración de flujos RVSP o en el establecimiento de rutas MPLS. Una conexión, en resumen, se acepta, sólo si existen suficientes recursos para satisfacer los requerimientos del nuevo canal y de los ya existentes. Para esto, con los modelos de tráfico y disciplinas de servicio se han desarrollado unos tests que indican si se puede admitir un nuevo flujos con tales características. Estos test pueden ser a nivel de un nodo o a nivel de red. A nivel de nodo, se chequea contra la información de estado del nodo, en caso de no poderse admitir se rechaza directamente la conexión. A nivel de red, el receptor comprueba , con toda la información de los nodos, por los que ha pasado el mensaje de conexión, si se cumplen los requerimientos solicitados; en caso afirmativo se envía al emisor un mensaje de establecimiento del canal, en caso negativo se envía un mensaje de rechazo. 1.4.3. Especificación y conformación del tráfico Una especificación de flujo es un acuerdo entre todos los componentes de una red para especificar el tráfico que va a tener, de una forma precisa y predeterminada (Tanembaum,1996). La idea es que antes de establecer o definir una conexión en la red, el origen del flujo informe sobre las características del flujo de trafico a transmitir y el servicio deseado, esta información es la que compone la especificación del flujo. Uno de los elementos mas importantes de esta especificación, es la descripción de cómo se va a introducir el tráfico en la red, que se suele denominar modelo de tráfico. El objetivo es regular el trafico a transmitir , con el fin de eliminar la congestión en la red. Este mecanismo que permite regular el trafico de acuerdo al modelo de tráfico establecido se denomina conformación del trafico(traffic shapping). Algunos mecanismos para conformación del trafico que retrasan el exceso de tráfico mediante buffers, modelando de esta forma el flujo de trafico son: Generic Traffic Shaping(GTS) o Frame Relay Traffic(FRTS). La técnica GTS retrasa el exceso de trafico mediante buffers, modelando el flujo de trafico. Trabaja reduciendo el tráfico saliente limitando el ancho de banda de cada tráfico específico y enviándolo a una cola de espera. De esta forma permite una mejor performance en topologías con tasa de bit diferentes(Documento: Calidad de servicio en Redes IP ,PDF. Capitulo 2. Herramientas para QoS) Al hecho de monitorizar el trafico para que cumpla el patrón acordado se denomina comprobación del tráfico(traffic polic ing); el mecanismo mas conocido para comprobación de trafico es el algoritmo llamado CAR(Committed Access Rate ); que controla la máxima transferencia de trafico transmitida o recibida en una interface y se configura principalmente en enrutadores de la periferia. El algoritmo (CAR) define cuales paquetes están dentro o exceden los limites establecidos basados en la tasa promedio de transmisión y el tamaño y tiempo de las ráfagas de trafico permitidas; de acuerdo a esto, transmite el paquete, lo descarta o edita su valor de prioridad (IP precedence )y lo evalúa nuevamente usando la siguiente política; cada interface puede tener múltiples políticas dependiendo del tipo de tráfico. Los modelos de trafico mas comunes son el leaky bucket y token bucket. Describiremos a manera de ejemplo el modelo token bucket.

27

1.4.3.1. Algoritmo token bucket El objetivo del algoritmo es permitir transmitir a mayores velocidades cuando la fuente genera un pico. El algoritmo funciona así: existe un cubo que contiene tokens generados a una tasa r (ver figura siguiente). El cubo admite como máximo b tokens, estando al inicio lleno. para transmitir un bit se debe coger un token del cubo y eliminarlo, mientras existan tokens, la fuente puede insertar el trafico a la red a la velocidad deseada. Cuando se acaban los tokens, debe esperar el próximo token que se genere, lo que implica que la tasa de transmisión disminuye a r. Por tanto lo que permite el algoritmo es poder transmitir en un determinado intervalo a velocidades superiores a r.

Figura 3. Algoritmo Token Bucket

El parámetro r significa la tasa de datos sostenible continuamente , mientras que b especifica en cuanto se puede exceder esta tasa para cortos periodos de tiempos. El trafico debe obedecer la regla que para cualquier periodo de tiempo t , la cantidad de datos enviados no puede ser superior a rt+b. Adicionalmente se puede imponer un límite en la tasa de transmisión que es la tasa pico p(define la velocidad pico de los datos, medida en bytes de datagramas IP por segundo). con este limite el trafico no puede ser superior a min[pt,rt+b]. 1.4.4. Clasificación de paquetes Para poder proporcionar la calidad de servicio requerida, es critico clasificar los paquetes, para permitir diferentes tratamiento de QoS. la clasificación puede basarse en varios campos presentes en el encabezado IP( por ejemplo, las direcciones fuente y destino y el tipo de protocolo) y en encabezados de protocolos de niveles mas altos (por ejemplo números de puerto origen / destino tanto para TCP como UDP) o en

28

otros criterios especificados por listas de acceso o clasificación basada en una dirección MAC. La clasificación de los paquetes debe realizarse lo antes posible( en los bordes de la “nube”). Cualquier nodo de la red debe ser capaz de marcar y clasificar el paquete. Cuando un paquete es marcado , todos los demás nodos de la red lo tratan según el grupo signado al mismo. Existen varios métodos para clasificar los paquetes, mostramos algunos ejemplos para el modelo de servicios diferenciados: § Precedencia IP( Define el campo ToS y usa 3 bits en la cabecera). § DSCP( usa 6 bits en la cabecera e incluye el anterior). § MPLS(bit experimental). § Ethernet 802.1p(define CoS y usa 3 bits) § Bit CLP en ATM(usa un bit)

Figura 4. Clasificación de paquetes en la capa 2

29

Figura 5. Clasificación de paquetes en la capa 3

Obtener un mecanismo eficiente y consistente de clasificación de paquetes, constituye actualmente un área de investigación bastante activa. 1.4.5. Marcado de paquetes Como resultado de los mecanismos de monitoreo de trafico o por discriminación voluntaria, los paquetes deben ser marcados en la red para un tratamiento particular de QoS (por ejemplo altas / bajas perdidas, prioridad de retardo). El marcado de paquetes IP se hace usando el byte ToS(Type of Service) para IPv4 y el byte de Clase de trafico para IPv6. 1.4.6. Priorización Se refiere a la capacidad de proporcionar diferentes tratamiento de retardo, por ejemplo , los paquetes de prioridad mas alta, se sirven siempre antes que los paquetes de baja prioridad tanto en el contexto del procesamiento del paquete como en la transmisión en los enlaces salientes. Los nodos también implementan tratamiento de prioridad en perdidas: por ejemplo, se pierden mucho mas los paquetes de baja prioridad que los paquetes con prioridad mas alta. La prioridad debe estar acompañada de los mecanismos de scheduling para lograr garantizar la calidad de servicio deseada.

30

1.4.7. Planificadores y disciplinas de servicio Una aplicación común de los algoritmos de planificación es proporcionar una calidad de servicio a nivel de red aislando unos tráficos de otros. Los planificadores también pueden ser usados para permitir a los usuarios compartir un enlace de forma equitativa. El planificador es como un sistema de colas , en el que un servidor proporciona servicio a varios clientes; los clientes encolan paquetes, que se escogen de acuerdo a la disciplina de servicio definida por el algoritmo de planificación. Los atributos deseables para un algoritmo de planificación son los siguientes (Hernández,2001,p. 18): § Aislamiento de flujo: aislar un canal de los efectos indeseables de otro.

§ Retraso emisor-receptor garantizado: El planificador debe proporcionar un

retraso garantizado de emisor a receptor, este limite de retraso debería depender solo de los parámetros de la sesión y no de las otras sesiones.

§ Utilización: El algoritmo debe maximimizar el uso del ancho de banda

§ Equidad(Fairness): El algoritmo de planificación debe servir a todas las sesiones

con tasas que sean proporcionales a su reserva, de tal forma que se distribuya el ancho de banda disponible entre las sesiones activas, de acuerdo a la prioridad de cada una de ellas.

§ Fácil implementación: El algoritmo debe ser de baja complejidad y fácil de

implementar en software o hardware. § Escalabilidad: el algoritmo debe comportarse bien en nodos con un gran

numero de sesiones y con una variedad de velocidades de enlaces. Los planificadores asignan 3 clases de recursos: ancho de banda( qué paquete es transmitido), tiempo (cuando es transmitido el paquete) y memoria (que paquetes son descartados), esto afecta a tres parámetros básicos: rendimiento, retraso y tasa de perdida(Hernández,2001,p. 19): Una vez los paquetes han sido debidamente marcados y clasificados según la información contenida en la cabecera del paquete (DSCP o IP Precedence). Cada clase o cada conjunto de clases tendrán asignada una cola de prioridad en el router. Cada una de estas colas garantiza un ancho de banda diferente, de modo que se pueden diferenciar diferentes clases de servicio. Los siguientes párrafos comentan de forma breve las técnicas de encolamiento disponibles para Qos. 1.4.7.1. Fifo (First In, First Out) Este es el mecanismo de Qos por default en redes IP(servicio best-effort), el primer mensaje en entrar es el primer mensaje en salir. Es válido sólo en redes con mínima congestión. No provee protección, no analiza el ancho de banda ni la posición en la cola de espera. Este algoritmo al igual que los demás mecanismos de cola, tiene como

31

limitación la capacidad de su buffer en momentos de congestión. Hoy en día, se requieren algoritmos más sofisticados, que permitan diferenciar entre distintos tipos de paquetes, por lo que este método esta cayendo en desuso. 1.4.7.2. Cola de Prioridades (Prioritizing Traffic, PQ) Este mecanismo asegura que el trafico importante reciba un servicio rápido en cada punto de la red, donde el mecanismo este presente. Cada uno de los paquetes debe ser colocado en cada una de las 4 posibles clases de prioridad de trafico(alta, media, normal y baja prioridad). La prioridad del paquete depende del marcado explicito que lleve el paquete (por ejemplo el valor del campo Type of Service de la cabecera IP), de la dirección IP del destino o fuente, del puerto destino o de cualquier otro criterio, como la interfaz del router por la que llegue el paquete, el tipo de protocolo, el tamaño del paquete etc. Los paquetes que no pueden ser clasificados serán asignados a la cola de prioridad normal. A la hora de seleccionar el próximo paquete a transmitir , esta política seleccionará el primero disponible de la cola con mayor prioridad(lógicamente entre aquellas que no estén vacías). Para seleccionar qué paquete de la cola de mayor prioridad se escoge, se suele utilizar una política FIFO.

Figura 6. Funcionamiento del algoritmo de la cola con prioridades.

La figura anterior(Tomada del documento Simulación de protocolo de reserva de recursos, Daniel Burguillos y Juan José López,2000,Sección 5.4 ,Capitulo 5) muestra el funcionamiento de la política de colas con prioridades. Los paquetes 1,3,4 pertenecen a la clase de mayor prioridad mientras que los paquetes 2 y 5 pertenecen a la clase de baja prioridad. El paquete 1 llega de primero y es transmitido inmediatamente dado que el enlace no está ocupado. Durante la transmisión del primero llegan los paquetes 2 y 3. Después de la transmisión del paquete 1 se selecciona el paquete 3 (que pertenece a la clase de prioridad alta) aunque llegó después del paquete 2. Durante la transmisión del paquete 2 llega un nuevo paquete de prioridad alta; la llegada del nuevo paquete no interfiere en la transmisión del paquete 2, aunque sea de prioridad mas alta; este comportamiento se denomina no preemptivo.

32

El inconveniente principal de esta técnica, es que el método es estático y no se adapta a los requerimientos de la red. 1.4.7.3. Politica Round Robin (Custom Queuing, CQ) Este mecanismo se basa en garantizar el ancho de banda mediante una cola de espera programada. El operador reserva un espacio de buffer y una asignación por tiempos a cada tipo de servicio. Es una reservación estática, y se permite especificar el numero máximo de paquetes(o bytes) en cada cola ; El sistema mantiene 17 colas de salida para cada interface; La cola con número 0 es utilizada para paquetes de alta prioridad como keepalive y paquetes de señalización. Esta técnica permite que varias aplicaciones compartan la red y que además tengan asignado un ancho de banda mínimo garantizado y unas garantías aceptables en cuanto a los retrasos. En resumen, el ancho de banda se comparte proporcionalmente entre las aplicaciones o usuarios. Este tipo de servicio es bueno para puntos críticos de la red, donde queremos asignar a un determinado tráfico un ancho de banda mínimo garantizado, recortando ancho de banda de otros tipos de tráfico; para ello se reserva una porción de la cola para un determinado tipo de tráfico y se usa el algoritmo round robin, para dar servicio a las colas. Los paquetes se clasifican en clases, pero a diferencia de la política anterior, el servicio se alterna entre los paquetes de todas las clases(en vez de servir primero a los de mayor prioridad). En la forma mas sencilla y suponiendo exclusivamente dos clases de paquetes, primero se transmite un paquete de la clase 1, seguido por uno de la clase 2, seguido por otro de la clase 1, etc.

Figura 7. Funcionamiento del planificador Round Robin.

En el ejemplo de la Figura 7(Tomada del documento: Simulación de protocolo de reserva de recursos,Daniel Burguillos y Juan José López,2000,Sección 5.4 , Capitulo 5) los paquetes 1,2 y 4 pertenecen a la clase uno, mientras que los paquetes 3,5 pertenecen a la clase dos. El algoritmo esta constantemente buscando paquetes en forma circular en cada una de las colas, cuando el paquete 1 llega este se transmite inmediatamente. Los paquetes 2 y 3 llegan a sus colas durante la transmisión del paquete 1. Al finalizar la transmisión del paquete 1 que pertenecía a la clase 1, el planificador debe seleccionar un paquete perteneciente a la clase 2, por tanto el

33

paquete 3 se envía. Tras enviar el paquete 3 (clase dos) se debe seleccionar un paquete de la clase uno (paquete 2), y durante la transmisión del mismo llega el paquete 4; luego de transmitir el paquete 2, se envía el paquete 4, aunque sea de la misma clase, puesto que no existen mas paquetes en las otras colas. 1.4.7.4. Politica Weighted Fair Queueing (WFQ) Una generalización de la política Round Robin que se ha mostrado muy importante en las arquitecturas con reserva de QoS es la política Weighted Fair Queueing(WFQ). Esta política es la más utilizada, y entre otros, se utiliza en los routers CISCO (IOS rel. 11.0) los paquetes al igual que en round robin también son clasificados en clases. El algoritmo también trata estas clases de forma circular y si una clase no tiene paquetes disponibles se salta a la siguiente, hasta encontrar uno disponible. WFQ difiere de Round Robin, en que cada clase recibe una cantidad de servicio diferencial en cualquier intervalo de tiempo. Esta repartición del servicio se hace asignando pesos a cada clase (según su importancia, les asigna un porcentaje de ancho de banda de la línea).

Figura 8. Asignación de pesos por flujos o clases

Supongamos que la clase i tiene un peso Pi bajo WFQ, dado un intervalo de tiempo en el que siempre hayan paquetes de la clase i para enviar , se garantiza que la clase i llegará a una tasa de transferencia mínima de:

∑ j

i

PP

Donde j toma valores sobre todas las clases que dispongan de paquetes para enviar. Por lo tanto para un ancho de banda del enlace C, la clase i llegara a una tasa de transferencia mínima de:

( )∑ = Nj j

i

PP

C..1

34

Esta descripción del algoritmo es idealizada porque no toma en cuenta el hecho de que los datos están organizados en paquetes de tamaño variable (lo que se conoce como un modelo fluido,”fluid model”,en el que se considera que los datos son infinitamente divisibles y no como paquetes. WFQ fue creado por S. Shenker y otros en 1989, existen varias variaciones como STFQ, WF2Q,Virtual Clock y Self Clocked Fair Queueing; estas variaciones intentan reducir el coste de computación que supone la simulación del modelo fluido, simulación necesaria para la implementación del algortimo WFQ. El algoritmo WFQ reduce el problema de retraso producido por el algoritmo slow-start de TCP 2, que produce ondas de tráfico en la red, y puede producir situaciones de congestión. WFQ trabaja con dos mecanismos muy diferenciados de señalización: IP precedence o DSCP, y Resource Reservation Protocol (RSVP). Es decir que se puede utilizar tanto para implementar servicios diferenciados(Diffserv) como servicios integrados(Intserv). El protocolo RSVP utiliza a WFQ para localizar espacios de buffer y garantizar el ancho de banda. WFQ puede estar basado en clases o flujos, de modo que puede dividir la entrada en varios flujos en función de los bits de precedencia. Los flujos de baja prioridad se reparten el ancho de banda sobrante de los flujos de alta prioridad. WFQ basado en clases permite garantizar un gran ancho de banda, mientras que WFQ basado en flujos permite garantizar un ancho de banda relativo. WFQ basado en flujos es recomendado para pequeñas aplicaciones que hacen poco uso de la voz(en Voz sobre IP). Mientras que WFQ basado en clases es recomendado para una gran cantidad de conversaciones sobre una línea de gran capacidad(en Voz sobre IP). En general mecanismo WFQ esta muy extendido para aplicaciones que requieren QoS, es adecuado para situaciones donde se necesita un buen tiempo de respuesta, para usuarios que hagan tanto un uso elevado de la red, tanto como para los que hagan un uso mas leve, sin añadir ancho de banda adicional. WFQ además asegura que las diferentes colas no se queden privadas de un mínimo ancho de banda, de modo que el servicio proporcionado al tráfico es más predecible y otra ventaja con respecto a los mecanismos anteriores, es que el algoritmo se adapta automáticamente a los cambios de la red, por tanto se minimiza la necesidad de configuración. La siguiente tabla resume las principales diferencias entre estas disciplinas de servicio.

Tabla 1. Disciplinas de servicio

Característica WFQ CFQ PQ Numero de colas numero de colas es

configurable (256 por default)

16 4

2 ampliación del algoritmo slow-start en el libro Redes de Ordenadores, Andrew S. Tanenbaum.capitulo 5

35

Tipo de servicio asegura igualdad entre los tipos de trafico, basado en pesos

servicio round robin. asignación de ancho de banda para las diferentes clases de servicio

paquetes con alta prioridad salen primero.

Configuración No hay configuración requiere configuración

requiere configuración.

1.4.8. Control de congestión Para que la calidad de servicio en redes IP, opere de una manera estable y eficiente es esencial que estas tengan capacidades robustas y viables de control de congestión; esta capacidad se refiere a la habilidad para controlar el flujo y el trafico excesivo durante los periodos de congestión. Los algoritmos Tail Drop, RED(Random Early Detection), WRED (Weighted Random Early Detection),DWRED (Distributed RED) y ECN( Explicit Congestion Notification) son algunas de las técnicas actualmente utilizadas y están enfocadas inicialmente en evitar que la congestión ocurra. Las técnicas de administración de congestión se deben usar para determinar si los enlaces de WAN están congestionados, es decir si los usuarios o ciertas aplicaciones están presentando una degradación en el servicio y deben apuntar a lograr una justa distribución del ancho de banda y una adecuada priorización de tráfico tanto para aplicaciones críticas como multimedia. 1.4.8.1. RED (Random Early Detection) Este mecanismo intenta evitar la congestión de la red (y la probabilidad de perdida), en vez de reaccionar a ella. El algoritmo monitorea el trafico y en caso de producirse una fuerte congestión(identificada por la longitud promedio de las colas) puede ser capaz de realizar el descarte de paquetes oportunos, es decir, no realizando un descarte paquete al azar, lo cual podría producir por ejemplo, la eliminación de un paquete clave que produjera la reacción de los algoritmos de control de control de congestión (slow-start) de TCP; El resultado es que la fuente al darse cuenta, disminuye la velocidad de trasmisión. Esta técnica le da a los operadores de la red, la posibilidad de aplicar normas de manejo del trafico y maximizar el throughput bajo condiciones de congestión. Fue propuesto por Sally Floyd y Van Jacobson y aprovecha las ventajas de los mecanismos de control de congestión de TCP(protocolo de nivel de transporte), aplicando una serie de algoritmos(Tomado del documento Evaluacion de mecanismos de calidad de servicio en los routers para servicios multimedia, parrafo 81 ):

• Distingue entre picos de tráfico temporales, que pueden ser absorbidos por la red y cargas excesivas de tráfico que pueden saturar la red.

• Trabaja en cooperación con el extremo generador del trafico para evitar la

oscilación producida por el protocolo TCP, que puede causar ondas de congestión en la red.

36

• RED trabaja con TCP, para anticiparse y manejar la congestión en momentos de tráfico excesivo, para maximizar el throughput mediante el descarte de paquetes.

1.4.8.2. WRED (Weighted Random Early Detection) Esta técnica posee todas las capacidades anteriormente citadas para el algoritmo RED y combina estas con IP Precedence (Precedencia IP) para proveer diferentes clases de servicio en función de las características de la información. WRED también proporciona manejadores para tráfico prioritario en momentos de congestión; esta técnica puede colaborar con RSVP, proporcionando un controlador de carga, o indicando si es factible una reserva de espacio en alguna cola. WRED es un mecanismo utilizado para QoS, pero no es muy aconsejable usarlo en el caso especifico, por ejemplo de VoIP (Voz sobre IP). Es más recomendable hacer uso de otros mecanismos para el descarte de paquetes. 1.4.9. Fragmentación e Inserción(Link Fragmentation and Interleaving) El trafico interactivo como Telnet y VoIP es susceptible de sufrir latencia y jitter con grandes paquetes en la red o largas colas en enlaces de baja velocidad. Así por ejemplo, si un paquete llega a su cola de prioridad(estando esta vacía) mientras esta saliendo del router otro paquete en ese mismo momento, perteneciente a otra clase, se originara un retardo . En un caso particular; el retardo producido por un MTU de 1500 bytes en una línea de 64 Kbps puede llegar a ser de 187.5 ms, que resulta inaceptable en el caso de VoIP. La técnica llamada LFI(Link Fragmentation and Interleaving) se basa en la fragmentación de datagramas y el intercalado de los paquetes de tráfico. En el caso especifico de VoIP, los paquetes no deben fragmentarse, los paquetes de datos deberían entonces fragmentarse y entre ellos enviarse los paquetes de voz. Para garantizarle a los paquetes de voz un retardo de máximo 10 ms, el tamaño máximo del paquete de datos se define por la cantidad de datos que se puedan enviar en 10 ms, los paquetes de VoIP se insertan entre estos paquetes, asegurando un retraso mucho menor(muy inferior a los 187.5 ms) 1.4.10. Incremento de la Eficiencia(RTP-HC) El protocolo de tiempo real RTP lo mencionamos por separado en un apartado siguiente. La compresión del encabezado de RTP (HC:Header Compression), permite mejorar la eficiencia del enlace en paquetes de corta carga util. Se trata de reducir los 40 bytes de RTP/UDP/IP a una fracción de 2 a 5 bytes, eliminando aquellos que se repiten en todos los datagramas.

37

Como los servicios de tiempo-real generalmente trabajan con paquetes pequeños y generados en forma periódica se procede a formar un encabezado de longitud reducida que mejore la eficiencia de la red. 1.4.11. Protocolos de Señalización Para que la red pueda brindar una calidad de servicio especifica, los nodos finales deben indicar un nivel especifico de QoS e informar sobre el perfil de trafico que van a generar. Esta característica ha sido un parte fundamental de las redes orientadas a conexión como ATM; sin embargo, para redes no orientadas a conexión (como redes IP), esta funcionalidad es relativamente nueva. Los protocolos RSVP y LDP(Label Distribution Protocol) son ejemplos de señalización en redes IP; temas relacionados con la escalabilidad de los protocolos y las capacidades para indicar diferentes necesidades de QoS, son objeto permanente de investigación. Para conseguir una provisión efectiva de QoS de red, se debe desarrollar en forma continua los mecanismos de provisión y configuración a través de los distintos dispositivos de red. Los mecanismos de provisión y configuración se clasifican en: de arriba a abajo o señalizados(Microsoft,2000,p.4). La provisión de arriba a abajo utiliza un sistema de administración de red, que se encarga de “insertar” de forma estática, la configuración necesaria en un conjunto de dispositivos de red, es decir se definen los criterios para clasificar paquetes, las colas, el marcado de paquetes y los parámetros de acuerdo a unas necesidades especificas de trafico y de Qos; esta técnica tiene el problema inicial de tratar de obtener un criterio de clasificación adecuado, no solo basado en encabezados IP, sino que los recursos deberían asignarse por aplicaciones o usuarios y no por valores de direcciones IP o puertos; adicionalmente la técnica trata de anticipar los volúmenes de trafico en los nodos de la red y de acuerdo a esto configura sus valores, esto hace que la solución no escale cuando el patrón de trafico cambia. La señalización RSVP complementa los mecanismos de provisión de arriba a abajo. Los hosts generan mensajes de señalización, que describen el trafico relacionado con una sesión específica; estos mensajes usan la ruta habitual que toma el trafico de datos, RSVP permite que la red conozca el tipo de servicio requerido, el tipo de aplicación, los recursos que se requieren, la forma de identificar una sesión en particular y los recursos de los dispositivos de red que se verán afectados por el trafico de datos asociado. Este tipo de señalización tiene la ventaja de que proporciona una relación directa entre la información de clasificación y los usuarios y las aplicaciones; además los dispositivos compatibles con RSVP son capaces de evaluar de forma dinámica las repercusiones que tendría el tráfico en los recursos y de notificar a los dispositivos ascendentes cuando no tienen los recursos suficientes para controlar los flujos de trafico adicionales. En el apartado siguiente describimos a mayor profundidad el concepto de señalización QoS, particularmente el protocolo RSVP, que constituye el objeto de estudio de esta tesis. No todas las herramientas disponibles son usadas en los mismos enrutadores. Por ejemplo, la clasificación de paquetes, el control de admisión y el manejo de la configuración se usan en los enrutadores de borde, en tanto que en los enrutadores centrales (backbone) se gestiona la congestión. El tratamiento de la congestión se

38

fundamenta en el manejo de las colas en buffer mediante diferentes técnicas. El buffer es la primer línea de defensa frente a la congestión. Una segunda defensa es el control de flujo. El problema del control de flujo en TCP es que se ha planeado de extremo-a-extremo y no considera el efecto de los pasos intermedios. 1.5. SEÑALIZACION DE QoS La señalización QoS es una forma de la red de comunicación que le permite a una estación final, o nodo de red, comunicarse con sus vecinos para reclamar un tratamiento preferencial a cierto trafico. La señalización Qos se define como la estrategia de comunicación de requerimientos de Qos a través de toda la red, para que cada nodo pueda gestionar sus recursos. Una verdadera Qos punto a punto, requiere que cada elemento en la red (switch, router, firewall, cliente y servidor) entregue su parte de QoS y que todos los elementos sean coordinados con señalización de QoS(Cisco IOS Quality of Service Solutions Configuration Guide,2000, párr. 1). La señalización es necesaria para poder garantizar esta calidad de servicio pero al coste de consumir recursos. En este sentido, si se aumenta la señalización entre elementos se puede sobrecargar la red. Una alternativa es que se administre la red para que sólo determinados dispositivos críticos participen en la señalización y el control de admisión. Por ello, es muy importante al diseñar una red en tiempo real, tener en cuenta la sobrecarga que suponen los protocolos que ofrecen calidad de servicio. Una red IP puede lograr QoS punto a punto, por ejemplo, usando parte del encabezado IP, para solicitar un tratamiento especial a trafico sensitivo al tiempo. El señalamiento de QoS, que toma ventaja de IP proporciona una técnica poderosa de señalización punto a punto. RSVP y IP Precedence ( precedencia IP) caen dentro de esta categoría. IP Precedence es un mecanismo in-band (en banda) y RSVP es un mecanismo fuera de banda, el primero señala un servicio diferenciado ( differentiated QoS) y el segundo un servicio garantizado (guaranteed QoS). La siguiente figura nos muestra los distintos mecanismos de señalizacion viables de Qos y como ellos, tienen alcances limitados(no punto a punto) a través de la red(en algunas partes de la infraestructura). RSVP e IP precedence hacen señalización punto a punto y la combinación de ambas técnicas constituye una poderosa combinación de señalización QoS(IP precedence para el modelo diffserv[“servicios diferenciados”] y RSVP para el modelo intserv[“servicios integrados”].

39

Figura 9. Alcance de los mecanismos de señalización de QoS

1.5.1. IP Precedence Esta técnica utiliza los 3 bits de precedencia en el campo tipo de servicio (ToS) del encabezado de IPv4, para especificar una clase de servicio a cada paquete. En esta técnica, el trafico se puede dividir hasta en seis clases de servicio y los métodos de encolamiento, que están en los nodos de la red, pueden usar esta clasificación para proporcionar el manejo apropiado.

Figura 10. El campo ToS y los bits de precedencia

Las técnicas de encolamiento como WFQ, CAR, etc pueden utilizar estos valores para el manejo de los paquetes.

40

Se pueden usar características como PBR (policy-based routing) y CAR (commited access rate), para configurar el valor de precedencia basado en listas extendidas de clasificación de accesos. Usando estas técnicas, se pueden definir los valores de la precedencia por aplicación de usuario, por destino o subred origen. Típicamente estas características se desarrollan tan cerca como se pueda a la orilla de la red o al dominio administrativo, de tal forma que la política establecida se propague fácilmente en los restantes elementos de la red. El valor de precedencia IP puede ser fijada en el servidor o cliente de la red, sin embargo este valor puede sobrescribirse por las políticas presentes dentro de la red. 1.5.2. Protocolo De Reserva de Recursos RSVP es el primer protocolo estándar significativo de la industria, para configurar dinámicamente Qos punto a punto, a través de una red heterogénea. RSVP, el cual corre sobre IP, le permite a una aplicación reservar dinámicamente el ancho de banda de la red. RSVP es el único protocolo estándar de señalización, diseñado para garantizar ancho de banda punto a punto, para redes IP. RSVP es una importante característica de QoS, pero no resuelve todos los problemas e impone algunas restricciones, tal como el tiempo requerido para configurar una reservación punto a punto. El capitulo siguiente de este documento describe a detalle los mecanismos y mensajes empleados por el protocolo. 1.5.3. Subnetwork Bandwidth Manager (Protocolo SBM) RSVP y sus definiciones de clases de servicios son bastante independientes de las tecnologías de red subyacentes. Esta independencia requiere que un usuario defina el mapeo de RSVP dentro de las tecnologías de subred. SBM responde específicamente a este requerimiento para redes IEEE 802, este define un protocolo de señalización para control de admisión basado en LAN, que permite a los enrutadores con capacidad RSVP y los dispositivos de las capas 2 y 3 soportar reserva de recursos LAN para flujos de datos RSVP. El método de señalización de SBM es similar al protocolo RSVP, dentro de las características de las entidades SBM tenemos (Cisco,2000) : § Se encuentran en dispositivos de la capa 2 y 3.

§ Administran recursos sobre un segmento de red. Un segmento se define como

un segmento físico de la capa 2 compartido por varios emisores, tales como un segmento Ethernet compartido (shared Ethernet) o un segmento Token Ring.

§ Los dispositivos que soporten SBM y que se encuentre dentro de un segmento

de red, pueden ser elegidos como un DSBM (Designated Subnetwork Bandwitdh Manager) o “administrador de ancho de banda en la subred”, este

41

dispositivo se encargara del control de admisión de requerimientos de reservas de recursos en la subred, dicho de otra manera, el dispositivo DSBM tendrá la responsabilidad de rechazar, procesar, reenviar o mantener el estado de los flujos RSVP en un segmento especifico. Un segmento de red que posea un DSBM será un “segmento administrable” y solo podrá existir un DSBM por segmento administrable.

Cuando un DSBM reciba un mensaje RSVP PATH ( el mensaje que envía RSVP para definir la ruta), este construye y mantiene un estado PATH para la sesión y anota la dirección del nodo de donde recibió el mensaje, luego reenvía el mensaje a la dirección destino. Cuando un DSBM reciba un mensaje de requerimiento RSVP (RSVP RESV) para el “segmento administrable” , el lo procesara como si se tratara de un nodo RSVP, basado en el ancho de banda disponible, si no se puede obtener el requerimiento de recursos dentro del segmento, el DSBM retorna un mensaje de error al nodo del cual recibió el requerimiento (mensaje RESVERR), en caso de que los recursos sean suficientes, y el DSBM acepte la reservación, el mensaje RESV se envía al nodo anterior, usando la información consignada por el estado local PATH del paso anterior. 1.5.4. Calidad de Servicio RSVP-ATM La característica de Qos RSVP-ATM, permite que sobre una red ATM se proporcione un servicio de carga controlada usando RSVP (este tipo de servicio requiere que los paquetes con reservas experimenten un desempeño equivalente a uno sobre una red poco cargada, es decir con muy poca perdida y retardo moderado). Esta característica requiere la habilidad para establecer sobre una nube ATM un circuito virtual conmutado(SVC: switched virtual circuit) como respuesta a un mensaje de requerimiento de reservación RSVP, de esta forma se mapea una sesión RSVP en un SVC de ATM. Esta característica se traduce específicamente en las siguientes tareas: § Se debe configurar una interfase para crear dinámicamente SVC como

respuesta a mensajes de requerimiento RSVP. Para asegurar la QoS definida por RSVP el circuito virtual(SVC), se establece con un perfil de QoS de acuerdo a las especificaciones de flujo de RSVP (flowspec). Esta correspondencia se da entre los parámetros de la tasa(rate) y el tamaño de rafaga “burst size” en la especificación de flujo de RSVP(flowspec) y los valores SCR(sustained cell rate) y MBS ( maximum burst size) de la conexion ATM.

En una conexión ATM, SCR es un limite superior de la tasa media de transmisión de una conexión. MBS representa el factor de ráfagas(bustiness) de la conexión; especifica el máximo número de celdas que pueden ser transmitidas por una fuente a la tasa pico ( en terminología ATM, se designa como PCR:tasa pico de emisión de la fuente) cumpliendo el valor SCR negociado.

Mensaje RSVP RESV ---> SVC

42

flowspec --> perfil de QoS § Se adiciona la metodología del algoritmo DWRED(Distributed Weighted Random

Early Detection) a la interface del adaptador de puerto mejorado ATM (PA-A3), para soportar una política de borrado de paquetes (algoritmo DWRED) por circuito virtual. Esto asegura, que en caso de requerirse el borrado de paquetes, primero se borran paquetes “best-effort” y no aquellos paquetes que requieren el apropiado QoS, determinado por el token bucket de RSVP, o sea, se borran primero los paquetes poco prioritarios.

§ Se debe configurar IP precedence y los valores de ToS que deben ser usados

para los paquetes que cumplan o excedan los perfiles de Qos. Si el agoritmo DWRED esta configurado por circuito virtual, se usan los bits de prcedencia y ToS para determinar cuales paquetes serán borrados en caso de congestión en el circuito virtual.

Tradicionalmente RSVP trabaja en conjunto con WFQ, el algoritmo WFQ le proporciona a RSVP las garantías de ancho de banda y le proporciona la visibilidad para todos los paquetes, esto permite que RSVP pueda identificarlos y marcarlos de forma adecuada. La característica de Qos RSVP-ATM permite desacoplar RSVP del algoritmo WFQ, en vez de este, RSVP se asocia con ATM-SVC para manejar los requerimientos de reservación (y proporcionar garantías de ancho de banda) y el algoritmo Netflow, para que los paquetes sean visibles al protocolo. Existen ejemplos comerciales disponibles que soportan estas características en enrutadores proporcionados por Cisco, Nortel o 3COM. Por ejemplo: el enrutador Cisco 7500 posee esta habilidad. No es objeto de esta tesis, entrar en el detalle del tema, para una consulta exhaustiva el libro Cisco IOS Quality of Service Solution Configuration Guide en su capitulo “Configuring RSVP-ATM QoS Interworking” es un buen punto de partida. 1.6. IMPLEMENTACION DE QoS En este apartado, se busca resumir los diferentes métodos de implementación de calidad de servicio, que usualmente en la literatura se relacionan como mecanismos de control de trafico; estos se clasifican normalmente en mecanismos por conversación(un solo flujo) o mecanismos por acumulación(flujos agregados); en los mecanismos por conversación hay un solo flujo unidireccional entre dos aplicaciones(emisor-receptor) y se trata por separado cada flujo de trafico; en este caso la red asigna recursos independientes al resto de las conversaciones y mantiene un control de ellos. En el núcleo de grandes redes, donde es posible soportar cientos de miles de conversaciones simultáneamente, este mecanismo no es practico. Los mecanismos por acumulación agrupan varios flujos de trafico en una sola clase y el tratamiento del trafico se basa en estas clases creadas. La agregación permite reducir en conjunto los recursos necesarios y obtener una calidad de servicio casi equivalente al modelo por conversación. Los servicios diferenciados son claros ejemplos de uso de trafico agregado.

43

Dentro de los mecanismos de control de trafico, esta la arquitectura de servicios integrados(Intserv) que se suele aplicar por conversación individual(aunque también puede soportar flujos agregados);normalmente, aunque no de forma necesaria, Intserv se asocia con el protocolo de señalización RSVP. Otros mecanismos son los llamados Servicios Diferenciados(Diffserv);que permiten un modo simple para dividir en categorías el trafico, basado en el campo del encabezado IP de los paquetes conocido como DSCP(diffserv code point), de acuerdo a estas agrupaciones se definen las prioridades. El estándar 802.1p es un mecanismo de control de trafico de acumulación apropiado para el uso en muchas redes de área local(LAN), define un campo en el encabezado de acceso al medio(MAC) de los paquetes Ethernet, que puede transportar uno de los ocho valores preferentes; esta técnica normalmente puede relacionarse con un protocolo de señalización de prioridades en switches de la capa 2 como el protocolo SBM(Subnetwork Bandwith Manager). El protocolo MPLS permite la administración de ancho de banda para flujos agregados, mediante el control de enrutamiento de la red, de acuerdo a unas etiquetas encapsuladas en las cabeceras de los paquetes. ATM es una tecnología de capa de vínculo que ofrece un tratamiento del tráfico de alta calidad; ATM divide los paquetes en celdas y a continuación se envían a la cola y se controlan con los algoritmos de administración de cola adecuados para uno o varios servicios ATM. A continuación describimos los distintos métodos de implementación de QoS en cada una de las diferentas capas de la red, tomando como estructura la definida en el documento “Quality of Service(QoS) in the New Public Network Architecture” de Anjali Aqarwal, párrafo 11. 1.6.1. Nivel de enlace El control de acceso al medio debe modificarse para proporcionar servicios diferenciados de tal forma que las garantías de QoS puedan soportarse. las tecnologías disponibles son: ATM, que se asocia con redes WAN y LAN. Frame relay específicamente usado para redes WAN y las redes del estilo IEEE 802 en redes de área local. 1.6.1.1. ATM La tecnología ATM es una arquitectura de conmutación de celdas que utiliza la múltiplexación por división en el tiempo asíncrona. Las celdas son las unidades de transferencia de información en ATM y se caracterizan por tener un tamaño fijo de 53 bytes. Esto simplifica los nodos y permite que la conmutación sea realizada por hardware, con lo que se logra alcanzar altas velocidades. ATM presenta una clasificación de sus servicios de acuerdo a unas necesidades especificas de los usuarios. ATM es quizás el protocolo mas adecuado para la transmisión de multimedia por su gestión de la calidad de servicio. Los servicios denominados CBR(Constant Bit Rate) y VBR(Variable Bit Rate) son apropiados para aplicaciones de voz y telefonía y para aplicaciones multimedia como video.

44

El servicio CBR es usado para conexiones que requieren una cantidad fija(estática) de ancho de banda, con ínfima probabilidad de perdida de celdas, así como retraso bajo y predecible. El tiempo entre celdas es constante y esta caracterizado por una tasa pico(PCR: Peak Cell Rate). El servicio VBR hace mas eficiente el soporte de aplicaciones de video o otras aplicaciones con tráfico a ráfagas. El trafico en este caso se caracteriza por una tasa de tráfico sostenida(SCR) y la tasa pico (PCR). SCR es medido sobre un periodo especifico y representa la tasa media de transmisión. Hay dos subcategorías de servicio para VBR: rt-VBR y nrt-VBR. El tráfico rt-VBR tiene requerimientos estrictos de retraso. El tráfico nrt-VBR no tiene estos requisitos y se puede almacenar en la red (buffering). Los servicios ABR(Available Bit Rate) y UBR(Unspecified Bit Rate) están diseñados para trafico “best-effort” no sensitivo al retardo, tales como la transferencia de archivos y el correo electrónico. 1.6.1.2. Frame Relay se basa en la definición de un contrato CIR (Committed Information Rate), que es un compromiso de parte de la red y un mecanismo de arbitraje sobre suscripción, para lograr un determinado nivel de calidad de servicio con el usuario. 1.6.1.3. IEEE 802.1 En redes 802.1 la especificación 802.1p proporciona un método para permitir encolamiento preferencial y acceso a recursos por clase de trafico, sobre la base de un valor de prioridad escrito en el frame. Este valor proporcionará a través de la subred un método consistente para Ethernet, Token Ring u otro tipo de capas MAC. El campo de prioridad se define como un valor de 3 bits , con un rango de valores de 0 a 7. 7 representa la prioridad mas alta y 0 la más baja. los 8 valores de prioridad se asocian usualmente con algunos tipos de trafico que van desde el servicio best effort (valor 0), el servicio “excellent effort”, apto para aplicaciones de negocios criticas pero tolerantes a algún nivel de retardo, el servicio para multimedia interactiva(sensitiva al retardo o jitter) y el servicio reservado( la prioridad mas alta). Los paquetes se encolan basados en sus valores de prioridad. Estas prioridades se conocen como Clases de Servicio(CoS). Esto permite el tratamiento de trafico de audio y video en dispositivos LAN como “switched Ethernet”. La tabla siguiente muestra un ejemplo de la relación entre el valor de prioridad y el tipo de trafico que se podría soportar.

Tabla 2. Prioridades IEEE802.1p y tipos de trafico

Prioridad Tipo de Trafico 0 Best Effort:ordinaria prioridad LAN 1 Background: mayoría de las transferencias

de archivos, juegos. 2 trafico moderado(spare) 3 Excellent Effort: Servicio “Best effort” para

usuarios importantes 4 Controlled Load(servicio carga controlada):

45

algunas aplicaciones importantes. 5 video: retardo menor a 100 ms 6 Voz: retardo menor a 10 ms 7 Control de red: paquetes de control de alta

prioridad para mantener y soportar la infraestructura de red.

Los host o los enrutadores que envían trafico a una LAN marcan cada paquete transmitido con el valor de preferencia adecuado. Los dispositivos LAN, tales como modificadores, puentes o concentradores deben tratar los paquetes de forma adecuada. La marca de preferencia 802.1p esta limitada a la red LAN. Como esta técnica debe implementarse en el hardware de los dispositivos de red, los enrutadores y switches existentes necesitan reeemplazarse con unos que soporten esta tecnología. Esto se usa específicamente en el estándar Gigabit Ethernet para permitir a Ethernet soportar Clases de Servicio(CoS). El estándar 802.1Q trabaja junto con 802.1p para proporcionar compatibilidad en equipos del legado que no soporte 802.1p. 802.1Q permite mapear las clases de servicio de tal forma que el trafico pueda transitar intacto a través de sistemas intermediarios que no entiendan 802.1p. Es factible implementar una mapeo uno a uno entre frames ethernet 802.1p o Q y IP precedence (Precedencia IP), permitiendo de esta forma construir una red que transporte priorización de una LAN Ethernet a otra a través de una WAN basada en IP o una conexión ISP. Cuando se usa en conjunto con RSVP IEEE 802.1p y Q proporcionan soluciones CoS/QoS (clases de servicio/ calidad de servicio) para toda la red empresarial. 1.6.2. Nivel de red El protocolo IPv4 no es apropiado para la transmisión en tiempo real, aunque IPv6 se ha diseñado para poder soportar este tipo de tráfico. En esta capa, muchos servicios de tiempo real deben distinguirse de los servicios que no son de tiempo real. En esta capa de red se utiliza el campo ToS(Type Of Service) del encabezado IPv4, para especificar la clase de servicio por cada paquete. Estos bits los puede asignar una aplicación, usuario o la subred de destino o de origen. Típicamente esta funcionalidad se desarrolla tan cerca a la orilla de la red, como sea posible, de tal forma que cada dispositivo siguiente de la subred puede proporcionar un servicio basado en el valor de este campo. Dentro de las funciones claves para soporte de Qos en esta capa , se encuentran la siguientes: 1.6.2.1. Marcado de paquetes El enrutador de ingreso debe marcar los paquetes tan pronto como ellos entran en la red, con los valores apropiados, de tal forma que los enrutadores internos puedan tratar los paquetes de la forma correcta( Se usa el campo ToS)

46

1.6.2.2. Clasificación de paquetes Los enrutadores deben chequear todos los paquetes recibidos, para determinar si estos requieren recibir un tratamiento diferencial. 1.6.2.3. Encolamiento de paquetes Los enrutadores deben emplear múltiples colas con múltiples estrategias de planeación de tal forma que el trafico sensitivo al retardo se sirva lo más pronto posible. Para ello existen diferentes disciplinas de colas ya implementadas, como las estudiadas en la sección 1.4 (herramientas para la funcionalidad QoS) Como área activa de investigación esta actualmente el tema de como soportar enrutamiento basado en QoS; esta técnica debe determinar una ruta que soporte las necesidades de QoS de uno o mas flujos en la red; la ruta seleccionada no necesariamente es la “tradicional ruta mas corta”, que se calcula basada en las actuales métricas y políticas. Los enrutadores capaces de QoS pueden soportar la posibilidad de que las aplicaciones marquen sus paquetes para tratamiento prioritario, los paquetes marcados s envían siempre de primero y nunca se borran durante periodos de congestión. Dentro de los protocolos que a nivel de red o a nivel de enlace están jugando un papel muy importante cabe mencionar el protocolo MPLS que explico de manera resumida en la siguiente sección. 1.6.2.4. MPLS El protocolo MPLS (MultiProtocol Label Switching) es una nueva tecnología que combina el enrutamiento de la capa de red con un paradigma de reenvío basado en etiquetas(nivel de enlace). Se espera que esta tecnología mejore la tasa precio/desempeño de los enrutadores; aumentando la escalabilidad de la capa de red y proporcionando una mayor flexibilidad en la entrega de nuevos servicios. El grupo de trabajo IETF MPLS esta definiendo los estándares de la tecnología. Distintos modelos para MPLS han sido propuestos: IP Switching(Ipsilon), Tag Switching (Cisco), ARIS(IBM), CSR(Toshiba). La tecnología MPLS puede operar sobre varias tecnologías a nivel de enlace, lo que incluye SONET, Frame Relay, ATM, Ethernet y Token Ring. MPLS combina las tecnologías de switching de la capa 2 con los servicios de la capa de red, mientras reduce la complejidad y los costos operacionales. Con el esquema actual, un paquete se envía de enrutador a enrutador hasta llegar a su destino; cada enrutador toma una independiente decisión de envío, analizando el encabezado del paquete y corriendo el algoritmo de enrutamiento; la problemática principal consiste en que los enrutadores se convierten en cuellos de botella. MPLS define una potencial solución para el tema, que pretende simplificar la decisión de reenvió dentro del enrutador y proporcionar suficientes garantías a la red para soportar la calidad de servicio deseada; para esto, MPLS adiciona mecanismos orientados a conexión, a los protocolos de la capa de red(como IP, que no son orientados a conexión). Estos mecanismos identifican rutas predeterminadas a través de la red entre dos puntos finales cualquiera; a cada ruta se le asigna una etiqueta

47

conocida como LSP(Label Switched Path: algo así, como “etiqueta de ruta conmutada”). En cada punto de ingreso a la red, un enrutador de borde conocido como Label Edge Router(LER) examina el encabezado IP para determinar el valor de LSP; este valor se encapsula dentro del encabezado MPLS y el paquete se envía al siguiente salto. Todos los enrutadores siguientes denominados LSR(Label Switch Routers), usan la información de la etiqueta del encabezado, para determinar el enlace saliente y la nueva etiqueta de este; el enrutador, intercambia la etiqueta en el encabezado con la nueva etiqueta y envía el paquete. Cómo se realiza la distribución de etiquetas entre los enrutadores?. Cada enrutador negocia con sus vecinos una etiqueta por cada clase equivalente de reenvió (FEC: forwarding equivalence class); la información sobre la topología de la red se obtiene de uno o mas protocolos de enrutamiento tales como OSPF, RIP y BGP. Por cada ruta o agregación de rutas, un vecino asigna una etiqueta; esta información se distribuye entre los enrutadores vecinos usando el protocolo de distribución de etiquetas(LDP). Para cada clase equivalente de reenvío, el enrutador MPLS realiza un mapeo entre una etiqueta entrante y la interface a una etiqueta saliente e interface. Estas asociaciones se almacenan en una base de datos llamada base de información de etiquetas(Label Information Base:LIB) 1.6.2.4.1. MPLS y Servicios Diferenciados (DiffServ) MPLS especifica la forma de mapear el trafico de la capa 3 a una capa 2 orientada a conexión como ATM y frame relay. Este adiciona una etiqueta que contiene información especifica de enrutamiento y permite a los enrutadores asignar una ruta explicita a varias clases de tráfico. La red MPLS proporciona un servicio a trafico DiffServ, mapeando el campo DS a una ruta explic ita a través de la red MPLS. Para cada clase de servicio, la red MPLS proporciona un flujo de datos independiente entre los enrutadores de orilla. El enrutador de la orilla obtiene una información de QoS desde el campo DS del paquete que proviene de un dominio Diffserv y esta información se usa para encontrar una ruta explicita MPLS. 1.6.2.4.2. MPLS y RSVP El grupo de trabajo de IETF investiga actualmente la posibilidad de usar RSVP como protocolo de señalización para establecer LSP (Label Switched Path) y propagar la información de las características de las rutas(por ejemplo: reservación de recursos, reasignaciones, información de QoS, información de reenrutamiento de LSP,etc) en redes MPLS. 1.6.3. Nivel de Aplicación y de Transporte los paquetes pueden ser marcados y clasificados por las capas de transporte y de aplicación. El enrutador debería, por tanto, conocer toda la información de los protocolos de nivel de aplicación, lo que complica aun mas el modelo. Los niveles de transporte y de aplicación deben proporcionar nuevas funcionalidades para soportar

48

las aplicaciones de tiempo real. El protocolo RTP es el estándar para transmisión de datos de tiempo real sobre una red basada en IP, aunque RTP no proporciona capacidad QoS implementa mecanismos como los números de secuencia y estampas de tiempo para el protocolo UDP. En estos niveles se han desarrollado distintos protocolos como RSVP que gestiona el control de admisión y la reserva de recursos. Otros se encargan de la transmisión y sincronismo de audio y video como RTSP(Real-time Streaming Protocol) ,RTP(Real-time protocol), RTCP( que se utiliza para control de calidad de servicio para aplicaciones que trabajan con RTP). 1.6.3.1. RSVP Nuevamente enunciamos acá el protocolo RSVP, pero su detalle mas especifico lo abordamos en el capitulo siguiente, en este apartado lo mencionamos para definir su ubicación dentro de la pila de protocolos que soportan QoS. Recordemos que RSVP permite que un host o un router asegure la reservación de ancho de banda a lo largo de la red IP. Es del tipo orientado al receptor(el receptor solicita la reservacion) y pude funcionar como unicast o multicast. En la figura 11 tomada del articulo de calidad de servicio en redes IP, ilustra la posición del protocolo dentro del modelo de capas de internet. El protocolo RSVP trabaja en conjunto con el protocolo de transporte RTP para servicios de voz y video en tiempo real.

Figura 11. Ubicación de RSVP dentro del modelo de capas de internet

El protocolo RSVP permite reservar el ancho de banda en forma dinámica para asegurar una calidad de servicio QoS en las redes IP. RSVP es utilizado por el host para solicitar una QoS al router para una aplicación particular y es usado por el router para establecer un ancho de banda en todos los nodos intermedios del trayecto. RSVP opera tanto sobre IPv4 como sobre IPv6; no es un protocolo de enrutamiento y solo se utiliza para reservar ancho de banda y buffer. En el modelo de capas el protocolo RSVP ocupa la función de la capa 3 sobre IP, en la misma forma que los protocolos de routing (OSPF y BGP), de multicast (IGMP), de gestión (ICMP) y de transporte (TCP y UDP). Una sesión manejada por el protocolo RSVP está definida

49

mediante 3 direcciones: la dirección IP de destino (receptor), el identificador de protocolo y el puerto UDP. 1.6.3.2. RTP (Real Time Protocol) El protocolo RTP tiene como objetivo asegurar una QoS para servicios del tipo tiempo-real. Incluye la identificación del payload, la numeración secuencial, la medic ión de tiempo y el monitoreo de la calidad (protocolo RTCP). Este protocolo es de nivel de transporte (capa 4) y trabaja sobre UDP de forma que posee un checksum para detección de errores y la posibilidad de múltiplexación de puertos UDP. Sobre RTP se disponen de protocolos de aplicación del tipo H.320/323 para vídeo y voz (H.32x forma una familia del ITU-T de normas para videoconferencia). Los números de secuencia incluidos en RTP permiten al receptor reconstruir la secuencia de paquetes del emisor. RTP consiste de 2 partes estrechamente relacionadas: § El protocolo de tiempo real(RTP) para transportar datos que tienen

propiedades de tiempo real. § El protocolo de control RTP (RTCP) que se encarga de monitorear la calidad de

servicio 1.7. MODELOS DE SERVICIOS 1.7.1. Sobreaprovisionamiento de la red La solución obvia para manejar periodos picos de congestión es sobreaprovisionar la red, o sea proporcionar ancho de banda adicional, anticipándose a las tasas picos de datos durante periodos de alta demanda. Esta estrategia, sin embargo no es económicamente viable-por lo menos, no con las tecnologías e infraestructuras de anchos de banda existentes- y especialmente para el caso de enlaces WAN. Puesto que los picos de datos y las regiones de la red sobre los cuales estos pueden ocurrir, son muy pocas veces posibles de predecir , de todas formas esta estrategia no constituye una alternativa realista y sostenible. la tecnología IP es necesaria así como el ancho de banda, pero ninguno de los dos es suficiente para cubrir todas las necesidades o condiciones de las aplicaciones de usuario. El servicio del “mejor esfuerzo” no puede proporcionar siempre un servicio util o aceptable; aun sobre una red IP relativamente poco cargada, los retardos de entrega pueden variar lo suficiente para afectar negativamente las aplicaciones que tienen restricciones de tiempo real. Para proporcionar algún nivel de confiabilidad cuantificable, los servicios IP deben tener adicionalmente la capacidad para diferenciar el trafico y permitir diferentes niveles de servicio para diferentes usuarios y aplicaciones.

50

un modelo de servicio define las propiedades que debe tener un servicio y que éste ofrece a las aplicaciones que lo usan . los siguientes dos modelos de servicios son complementarios y están diseñados para ser usados en combinación en diferentes contextos de red. § El modelo de servicios integrados: IntServ § El modelo de servicios diferenciados: Diffserv

A continuación definimos cada uno de estos modelos. 1.8. EL MODELO DE SERVICIOS INTEGRADOS El modelo de servicios integrados (Intserv) es una estructura para definir servicios. Como tal, incluye un conjunto de mecanismos de control de tráfico subyacentes. Los servicios Intserv se suelen aplicar por conversación individual. Normalmente, aunque no de forma necesaria, Intserv se asocia con el protocolo de señalización RSVP (tratado en el capitulo siguiente). El modelo de servicios integrados intenta integrar todos los tipos de tráficos posibles en una misma red de uso general. El modelo ofrece servicios cuantificables y mesurables en el sentido que son definidos para proporcionar una determinada calidad de servicio para un tipo de trafico cuantificado. Este modelo está asociado con mecanismos de control de admisión y de reserva de recursos. Cada aplicación negocia el nivel de la calidad de servicio y el esquema mas complejo de modelo de reserva es el llamado de “doble pasada”; en este método se propaga la especificación del tráfico inicial desde el origen a sus posibles destinos; cada uno de los enrutadores presente en la ruta guarda estos valores y posiblemente los ajusta para reflejar su capacidad actual disponible; esta especificación se devuelve al origen que decide si admite o no el canal. Este modelo fue propuesto en el RFC 1633 para soportar tanto trafico de tiempo real, como trafico “best effort”; el modelo esta basado en ingeniería de trafico basada en reservaciones, donde los recursos son explícitamente identificados y reservados. Los nodos de la red deben clasificar los paquetes entrantes y usar las reservaciones para proporcionar servicios específicos. Los nodos ejecutan la reservación de recursos usando un protocolo de señalización dinámico y emplean control de admisión, clasificación de paquetes y planeación inteligente de envíos(scheduling) para lograr la calidad de servicio deseada. El modelo de servicios integrados ( Intserv de forma abreviada) propone un entorno de red, que permite proveer de garantías individuales de calidad de servicio para sesiones de una cierta aplicación. El corazón de esta arquitectura son dos elementos claves: 1.8.1. Reserva de recursos Es necesario que los enrutadores sean capaces de mantener la información de estado suficiente para conocer que cantidad de sus recursos(buffer, ancho de banda) ya han sido adjudicados.

51

1.8.2. Señalización Si una aplicación desea tener la seguridad de cumplir con los requerimientos de Qos extremo a extremo, se debe verificar que cada nodo de la ruta reserve suficientes recursos. Cada enrutador del camino debe asegurarse que dada una petición de una cierta QoS, dispone de los recursos necesarios para garantizar de forma local esa nueva reserva, sin que esto interfiera en el resto del tráfico. El proceso de admisión de una petición se podría resumir en los siguientes pasos:

• Caracterización del tráfico y de la reserva necesaria: Una aplicación debe

declarar sus requerimientos de QoS y caracterizar el tráfico que generará. Se usa la especificación Rspec para definir las características de la reserva y la especificación Tspec para caracterizar el tráfico que el emisor generará en la red o el trafico que el receptor recibirá de la red. Ambos dependen del tipo de servicio que se solicite

• Señalización de la petición:

El Tspec y el Rspec de una sesión deberá encaminarse a los enrutadores en los que deberá instalarse la reserva. Aquí es donde surge, el protocolo RSVP, que es el protocolo de señalización escogido en la arquitectura internet.

• Admisión de la petición elemento a elemento: Cuando un enrutador recibe una petición(Tspec y Rspec) debe decidir si la acepta o la rechaza. Esta decisión dependerá de la reserva pedida, las reservas anteriormente aceptadas, y de los recursos disponibles en el enrutador( Burguillos & López,1999).

Actualmente el modelo define dos tipos de servicio; el servicio de carga controlada(controlled load) y el servicio garantizado(guaranteed) que se describieron en la sección 1.3 En la arquitectura IIS cada nodo capaz de manejar QoS alimenta con los paquetes entrantes el clasificador de paquetes . El clasificador de paquetes ( packet classifier) decide que ruta y que clase de calidad de servicio ( QoS) le corresponde. Un planeador de paquetes ( packet scheduler ), se encarga de encolar y reenviar los paquetes de acuerdo a la calidad de servicio prometida ( QoS). El planeador de paquetes, puede negociar los parámetros de calidad de servicio para el tráfico con la capa de enlace. En todos los nodos los requerimientos de reservación de recursos son manejados por dos módulos, el módulo de control de admisión, y el módulo de control de políticas. El módulo de control de admisión se asegura que los recursos de red son suficientes para atender el requerimiento. El módulo de control de políticas determina quienes pueden y quienes no pueden reservar recursos de red sobre el nodo. El módulo de control de políticas puede igualmente consultar los permisos para requerimientos de reservación de recursos desde diferentes servidores de políticas .

52

El clasificador de paquetes, el planeador de paquetes y el módulo de control de admisión forman el control de tráfico. Estos implementan los nuevos modelos de servicios de QoS definidos por la arquitectura. Este modelo es relativamente complejo y tiene dificultades para escalar en grandes backbones , la arquitectura esta basada en el protocolo RSVP. RSVP permite a una aplicación dinámicamente reservar ancho de banda. Los servidores y enrutadores usan RSVP para entregar sus requerimientos de QoS a todos los enrutadores a través de la ruta y para mantener la información de estado en el servidor y en el router que proporcione el servicio requerido, usualmente ancho de banda y latencia. La reservación de ancho de banda esta basado en el promedio del flujo de datos, la mayor cantidad de datos que el enrutador mantiene en cola, y la mínima Qos requerida. El modelo intserv debe proporcionar principalmente servicio garantizado, de acuerdo con sus técnicas y estándares . Las tecnologías que pueden proporcionar servicios garantizados para partes de la conexión punto a punto son:

• IP-WFQ combinados con señalamiento RSVP o ancho de banda garantizado en un único enlace (sobreaprovisionamiento de la red).

• Ethernet-Subnet Bandwidth Managar(SBM) cuando se usa con un switch

complaint.

• ATM-Variable Bit Rate(VBR) y Constant Bit Rate (CBR)

• Frame Relay-Committed Information Rate(CIR) 1.9. MODELO DE SERVICIOS DIFERENCIADOS El grupo de trabajo Diffserv de la IETF(Internet Engineering Task Force) esta trabajando sobre estándares específic os y definiciones para servicios que caen bajo la categoría de calidad de servicio diferenciada(Differentitated QoS). La idea es obtener un modelo para identificación de flujos, más escalable, flexible y más fácil de implementar que el modelo IntServ/RSVP. Esta basado en la agregación de trafico en vez de la administración de flujos individuales por aplicación. El modelo Diffserv se enfoca principalmente en el uso del campo ToS del encabezado Ipv4 o el byte clase de trafico en Ipv6 como mecanismos de QoS. Estos bits son usados para marcar un paquete de tal forma que reciba un particular tratamiento de reenvió en cada uno de los nodos de la red. La clasificación, el marcado y la definición de políticas de paquetes se hacen en las orillas de la red y solamente los requerimientos de manipulación de paquetes se proporcionan en el backbone(core). En este modelo, la red clasifica el trafico entre distintas clases y les aplica una disciplina de servicio diferenciada con el objetivo de proporcionar distintos niveles de calidad de servicio. En este caso no se reservan recursos por lo que no se puede garantizar a priori una calidad de servicio, se pueden tener varias clases de servicio para tiempo real, con distintos niveles de retraso; existen niveles con servicio predictivo y otros solo con garantía de entrega, el cliente escogerá el tipo de servicio en función del trafico a transmitir y por supuesto, el precio que quiera pagar. Este

53

modelo es menos complejo de implementar que el anterior y se integra fácilmente con el protocolo IP , porque cada paquete se marca con la clase de servicio que requiere. Una arquitectura de servicios diferenciados se basa en tres principios básicos:

• Clasificación: los paquetes se marcan en los nodos de entrada a la red de acuerdo a la clase de servicio requerida.

• Diferenciación: el marcado de los paquete permite determinar como son

tratados los paquetes dentro de la red, y por tanto obtienen un servicio diferenciado.

• Contención: La obtención de una determinada calidad de servicio se basa

en controlar la congestión o carga de la red. Los paquetes se deben ajustar en los nodos de entrada de acuerdo a los requerimientos o reglas de cada clase de servicio. (Hernández,2001,p.50).

La figura 12 muestra un ejemplo de transmisión entre un emisor y receptor usando una red Diffserv. En primer lugar el emisor establece una clase de servicio; esta clase implica un marcado en un nodo cercano al emisor(clasificador); los paquetes una vez marcados entran a la red por un nodo de entrada que realiza la contención del flujo(controlar la carga sobre la red) ; o sea que si los paquetes marcados no cumplen con los patrones definidos por la clase de servicio en particular, se almacenan o se eliminan . Dentro de la red, los nodos internos trataran cada paquete de acuerdo a la clase de servicio determinada en la marca; la salida de la red se hace por el nodo de salida, que a su vez enlaza con otra red.

Figura 12. Red de servicios diferenciados

Las clases de servicio se distinguen mediante el uso de un byte especial dentro de la cabecera del protocolo IP(específicamente dentro del campo ToS) que se denomina el campo de servicios diferenciados( DS field). Este byte contiene seis bits llamados Diffserv Code Point(DSCP)(Nichols 98); junto con dos bits restantes que actualmente no se utilizan. Los tres bits mas significativos de DSCP coinciden con los de ToS, y son usados como selector de clase, es decir, IP Precedence.

54

La forma como cada nodo se comporta o responde frente a una determinada clase de servicio se denomina “comportamiento por salto” (referida como PHB: per-hop behavior, en la literatura del grupo IETF); este comportamiento define como una clase de servicio trata el retraso, jitter, los descartes de paquetes y el ancho de banda asignado . Se han definido 2 clases de servicio ( o sea dos PHB) basándose en el trabajo de DaveClark y Van Jacobson (Nichols 99), adicionales a la clase “best-effort” actualmente definida en internet.

• Servicio premium (Expedited Forwarding): Este servicio es utilizado para aplicaciones que necesitan un ancho de banda garantizado y son muy sensibles a los retrasos; un marcado EF garantiza un servicio prioritario, realizando una reserva de una cierta cantidad del ancho de banda, que se utilizara en tráfico de alta prioridad. En este servicio se obtienen pequeños retrasos siempre que el tráfico origen cumpla con un patrón determinado; es como una especie de línea dedicada en la que no se puede exceder el ancho de banda requerido. El comportamiento de un nodo ante el tráfico agregado de esta clase de servicio, es que la tasa de salida debe ser igual o mayor a la suma de las tasas de entrada, de manera que no halla congestión para los paquetes marcados como clase EF; es decir el servicio debe ser independiente de la carga de la red. Este comportamiento se debe implementar por medio de una cola de prioridades o con esquemas como LLQ y CBQ.

• Servicio seguro (Assured Forwarding): Este servicio especifica cuatro

clases de anchos de banda y describe el tratamiento que cada una debe recibir, especifica los niveles de pérdida de paquetes , resultando un total de 12 posibles clases; es conveniente para datos que no requieren tratamientos muy prioritario; por ejemplo no es conveniente para VoIP. Este servicio asigna al cliente un ancho de banda determinado pero sin garantías; de todas formas es un servicio mejor que el “best-effort” de Internet.

El modelo define también como el tráfico es limitado a la entrada de la red; para ello se utiliza un conformador de tráfico “token bucket” y el trafico que no esté conforme es eliminado. En el servicio seguro este comportamiento es diferente y el tráfico no conforme no es marcado y se trata como “best-effort”. Para la gestión y control de tráfico se añade un elemento denominado “gestor de ancho de banda” (Nichols ,Jacobson & Zhang, 1999). Este elemento tiene dos responsabilidades tal como se definen en el documento de Enrique Hernández, Reserva de Recursos en Redes para Transmisión en Tiempo Real, capitulo 2, pagina 52:

• Controlar la carga de la red e informar a los nodos de entrada y salida(ingress/egress nodes) de la situación de la red para poder contener el tráfico a la entrada.

• Negociar con las redes adyacentes el control de flujo.

Las tecnologías que pueden proporcionar servicios diferenciados para partes de la conexión punto a punto incluyen:

• IP-WRED,WFQ combinados con Precedencia IP(IP Precedence) como mecanismo de señalización o priorización de trafico en un único enlace.

55

• Servicios UBR y ABR de ATM específicamente si no puede ser definida una tasa

mínima de celda en la implementación(MCR: Minimum Cell Rate).

• Priorización de frames en switches en conjunto con señalización 802.1p. 1.10. ESTRATEGIAS DE APLICACION DE QoS Según las estrategias definidas por Microsoft en su documento “Build a Better Network with QoS”3, si una empresa decide agregar capacidad QoS a la red, se pueden escoger 3 métodos de implementación: QoS centrada en la red(networkcentric), Qos punto a punto basada en la red y Qos punto a punto basada en la aplicación 1.10.1. QoS centrada en la red En este método, se puede desarrollar QoS solamente en los dispositivos de red, tales como switches y routers; por tanto no se necesita actualizar sus “aplicaciones de legado” servidores y estaciones de trabajo para soportar QoS, usando políticas de QoS predefinidas , los switches y routers pueden priorizar el trafico entrante, reservar el ancho de banda necesario, colocar los paquetes dentro de las colas apropiadas y reenviar los paquetes; por ejemplo cuando un switch de nivel 3 determina que SAP R/3 esta originando datos(detectando esto por el puerto TCP del paquete);entonces el dispositivo aplica una política para este trafico: por ejemplo, configurando el valor de precedencia IP(IP precedence) a 7 y reservando un ancho de banda de 1Mbps. El método centrado en la red, es el método mas simple para habilitar QoS, puesto que no requiere cambios en el entorno del usuario ; esta estrategia no proporciona QoS en los computadores o nodos receptores. Bay Networks, Cisco y Cabletron soportan esta estrategia. 1.10.2. QoS punto a punto-basada en la red En esta estrategia no solo se implementa QoS en los dispositivos de red sino que adicionalmente se debe implementar en las tarjetas de red de los computadores(computer NIC). Estas tarjetas deben poder clasificar los datos transferidos desde la aplicación y configurar los valores de prioridades para 802.1p e IP Precedence, basado en las políticas predefinidas; por tanto se podría proporcionar QoS punto a punto sin modificar las aplicaciones existentes. Actualmente 3COM soporta esta estrategia.

3 Este documento se encuentra disponible en http://wwww.winnetmag.com/articles/index.cfm?ArticleID=3932

56

1.10.3. QoS punto a punto-basado en la aplicación Esta estrategia requiere que las aplicaciones de servidores y estaciones de trabajo sean capaces de definir e interactuar con sus necesidades especificas de QoS. Usando esta estrategia se puede explotar totalmente en la red, de computador a computador las técnicas de QoS como RSVP y SBM,; esto implica que los sistemas operacionales soporten QoS; Windows 2000 es un ejemplo de sistema operacional con soporte de QoS. 1.11. RESUMEN DE LA ARQUITECTURA PARA QOS Los siguiente pasos resumen los elementos que se deben tener en cuenta para la aplicación de QoS.

• Comprobar que existe suficiente ancho de banda; por ejemplo para el caso de VoIP se debe usar 64 + 16 kbps.

• Elección de un mecanismo para clasificación y marcado de paquetes.

• Elección de un mecanismo de cola.

• Mecanismo de fragmentación.

• Estudio de diferentes métodos a la hora de aplicar los pasos anteriores.

La siguiente gráfica (tomada del documento: Evaluación de mecanismos de calidad de servicio en los routers para servicios multimedia) resume todos los elementos que se deben considerar en la implementación de QoS, para el soporte de aplicaciones especificas.

PR

EV

ISIÓ

N &

MO

NIT

OR

EO

PR

EV

ISIÓ

N &

MO

NIT

OR

EO

VPNsVPNsMultimediaVideo Conference,

Collaborative Computing

MultimediaVideo Conference,


Servicios de misión critica


VoIPVoIP VPNsVPNsMultimediaVideo Conference,


MultimediaVideo Conference,




VoIPVoIP

HybridHybridMPLSMPLSDiffServDiffServIntServIntServ HybridHybridMPLSMPLSDiffServDiffServIntServIntServ

Técnicas de señalización (RSVP, DSCP*, ATM (UNI/NNI))Técnicas de señalización (RSVP, DSCP*, ATM (UNI/NNI))

Mecanismos de enlace eficientes (Compresión, Fragmentación)Mecanismos de enlace eficientes (Compresión, Fragmentación)

Técnicas para evitar congestión (WRED)Técnicas para evitar congestión (WRED)

Técnicas de manejo de congestion (colas) (WFQ, CBWFQ, LLQ)Técnicas de manejo de congestion (colas) (WFQ, CBWFQ, LLQ)

Técnicas de clasificado y marcado (DSCP, MPLS EXP, NBAR, etc.)Técnicas de clasificado y marcado (DSCP, MPLS EXP, NBAR, etc.)

FrameRelay

FrameRelay

PPPHDLC

PPPHDLC SDLC

SDLCATM, POSATM, POS FE,Gig.E

10GE

FE,Gig.E10GE

WirelessFixed,Mobile


BroadBandCable,xDSL

BroadBandCable,xDSL

FrameRelay

FrameRelay

PPPHDLC

PPPHDLC SDLC

SDLCATM, POSATM, POS FE,Gig.E

10GE

FE,Gig.E10GE



BroadBandCable,xDSL

BroadBandCable,xDSL

PO

LIT

ICA

S D

E C

ON

TR

OL

PO

LIT

ICA

S D

E C

ON

TR

OL

Condiciones del tráfico (Policing, Shaping)Condiciones del tráfico (Policing, Shaping)

Figura 13. Arquitectura final de QoS

57

El siguiente apartado define como se pueden integrar las tecnologías para soporte de calidad de servicio punto a punto. 1.11.1. Qos Punto a punto- Integración de Tecnologías 1.11.1.1. El producto de calidad/eficacia Este indicador definido por Microsoft en su documento (Resumen de los mecanismos de QoS y como ínteroperan), muestra el intercambio existente entre la capacidad de una red para ofrecer garantías de alta calidad y la eficacia con la que se pueden utilizar los recursos de la red. Una red se puede garantizar mediante un producto de calidad/eficacia(producto QE constante). Ofrecer garantías de alta calidad exige un compromiso de eficacia y viceversa. Las aplicaciones multimedia suelen requerir garantías de alta calidad. No todas las aplicaciones requieren garantía de alta calidad. Por ejemplo, las transacciones de de bases de datos de cliente/servidor, no pueden cuantificar de forma precisa los requisitos de recursos y, por tanto, no exigen garantías cuantificables. Una forma de proporcionar garantías de alta calidad es proveer considerablemente la red; por ejemplo, si en un caso de telefonía IP sobreaprovisionaramos la red para poder manejar 1000 sesiones simultaneas, podríamos dar una garantía de calidad en el servicio, pero si en termino medio solo se presentan diez sesiones simultaneas; se trata evidentemente de un uso ineficaz de los recursos de red. Un mecanismo alterno para ofrecer garantías de alta calidad es la utilización de la señalización RSVP; con este método se puede proveer los dispositivos de red para la carga media esperada; en el caso excepcional de sobrepasar esta carga , se rechazan las sesiones adicionales pero se mantendría la integridad de las garantías de QoS en la sesiones actuales. Al utilizar RSVP se utilizan los recursos de red de forma mas eficaz(se incrementan el producto QE de la red). Podría parecer que todos los dispositivos de red deberían implementar los mecanismos mas sofisticados de QoS disponibles, sin embargo tales mecanismos tienen un costo de exceso elevado relacionado con la compatibilidad misma del mecanismo; para el caso de RSVP, este exceso adopta la forma de recursos de procesamiento en los dispositivos de red( adiciona carga adicional en el procesamiento que deben hacer los routers). por tanto hay necesidad de evaluar cualquier mecanismo de QoS en términos de la ventaja que ofrece en función del producto QE incrementado frente al costo que conlleva en términos de su implementación. La siguiente tabla tomada del documento de Microsoft Resumen de los mecanismos de QoS y como ínter operan, capitulo 5, pagina 7 ilustra el concepto en términos de las tecnologías disponibles.

58

Tabla 3. Mecanismos QoS y producto QE

Las columnas mas a la derecha y en la parte inferior representan los mecanismos de Qos mas sofisticados. La celda superior izquierda no representa ningún mecanismo de QoS y ofrece un producto QE limitado. Una LAN provista en exceso es un ejemplo de una red de este tipo. La celda inferior derecha representa una red en la que cada elemento procesa la señalización RSVP por conversación y aplica el control de trafico IntServ por conversación. Las celdas intermedias representan compromisos entre el producto QE y la implementación de la técnica de Qos. La celda que representa la combinación del control de admisión por conversación y el control de tráfico por acumulación resulta de especial interes. Esta celda representa el modelo que permite integrar las arquitecturas Diffserv e Intserv, tal como lo estudiaremos en el apartado siguiente. El modelo se basa en que los enrutadores de la orilla de la red procesan mensajes de señalización RSVP(denominados agentes de control de admisión) y los enrutadores del centro aplican control de trafico por acumulación y no procesan mensajes de señalización. Este modelo de señalización por conversación en el extremo de la red y de control de trafico por acumulación en el centro , produce un buen intercambio entre el producto QE y el exceso de Qos asociado. Se puede aplicar a topologías de red arbitrariamente complejas. Se prevee que los proveedores de acceso a internet (ISP) utilicen un modelo parecido para ofrecer servicios QoS basados en VPN. 1.11.1.2. Integración de tecnologías Antes de discutir los temas de integración de los modelos Diffserv e IntServ, es bueno poner en perspectiva las características de cada uno de estos, como se resume en la siguiente tabla.

Tabla 4. Comparación de los modelos IntServ y DiffServ

Consideración IntServ/ RSVP DiffServ Mantenimiento del estado

Basado en el receptor No, se hace comprobación de los parámetros de trafico

Nivel de servicio Basado en clases Contratos de niveles de servicio

Ancho de banda Alto uso de ancho de banda para señalización

No hay restric ciones sobre la disponibilidad de ancho de banda

Trafico Inapropiado para escenarios Apropiado para trafico alto, no

59

de alto trafico debido a la señalización por flujo.

es apropiado para redes de bajo trafico.

Escalabilidad No es muy escalable Escalable Compatibilidad con enrutadores

Todos los enrutadores deben ser compatibles con IntServ

Solo los enrutadores de borde necesitan ser compatibles con DiffServ

Estado en el router Estado de flujos por aplicación Flujos agregados Parece ser un consenso general, después de revisar algunos artículos y RFC de IETF que las estrategias de integración de los modelos parecen encaminados a mostrar el modelo DiffServ dentro del backbone(core) de la red, mientras que IntServ ofrecerá integración de los proveedores de servicio dentro de las regiones periféricas de la red. La relación entre los servicios integrados y diferenciados es un tema de estudio actualmente. El grupo IETF esta trabajando en este campo y en general se propone tratar la red de servicios diferenciados como un nodo dentro de la red de servicios integrados(Bernet,2000). Esto significa que toda la red se comportará como un nodo de la red de servicios integrados como se muestra en la siguiente grafica.

Figura 14. Servicios integrados sobre una red Diffserv

Los nodos de entrada y salida de la red Diffserv gestionaran los mensajes RSVP(mensajes de requerimiento de reservación y de establecimiento de ruta) y definirán las clases de servicio para toda la subred, como si fuera un nodo RSVP. También está en estudio el mapeo de las clases de “servicio controlado” y “garantizado” a las clases de Diffserv. Las especificaciones de QoS expresadas por IntServ deben ser mapeadas al comportamiento por salto del modelo DiffServ. El objetivo es usar Diffserv como el mecanismo para entregar servicios integrados(IntServ) específicos . La iniciativa para desarrollar esta arquitectura, esta basada en las características de clasificación de trafico y enrutamiento de Diffserv. Diffserv es capaz de limitar en forma dinámica o estática los niveles de trafico dentro de una clase de trafico particular, de tal forma, que con la correcta configuración, las clases de servicio particular pueden ser identificadas análogamente a las especificadas por el modelo IntServ. Mientras Diffserv se posiciona como el servicio de entrega preferido de Internet y trafico WAN, por su escalabilidad y flexibilidad en grandes redes, es igualmente meritorio su combinación con el modelo de servicios integrados(IntServ). El principal beneficio es la posibilidad de proporcionar servicios garantizados a diferentes mercados y redes de soporte. Intserv se basa en la reservación de recursos, mientras

60

que DiffServ trata preferencialmente al trafico prioritario, por tanto los dos modelos (y su integración) muestran posibilidades para el desarrollo de modelos viables de negocios basadas en las provisiones de recursos requeridas por el cliente. Las estrategias de servicios integrados ganaran fuerza y extenderán la oferta de garantías consistentes punto a punto para QoS. 1.12. VENTAJAS Y EJEMPLOS DE QOS Los últimos años han sido testigos del crecimiento exponencial en las redes de computadores, constantemente los administradores de red deben agregar nuevos recursos para poder responder a las necesidades de los usuarios; esta situación se ha agudizado por la entrada en el escenario de las aplicaciones multimedia. Los mecanismos de QoS proporcionan un conjunto de herramientas que el administrador de la red puede usar para gestionar el uso de recursos de red de una forma controlada y eficaz. El resultado esperado es que estos mecanismos de QoS pueden ayudar a mejorar el servicio a los usuarios de la red, al mismo tiempo que se reduce los costos de ofrecer dichos servicios y se frena el ritmo al que es necesario aumentar la capacidad de la red. A continuación detallamos algunos ejemplos de los beneficios que se esperan como resultado de la implantación de QoS(Resumen de los mecanismos de QoS y cómo interoperan, capitulo 2, pagina 1). 1.12.1. Ejemplo 1: Mejor rendimiento de aplicaciones de misión crítica a

través de vínculos WAN En el caso de aplicaciones como SAP, utilizadas en intranets de área extensa, los enlaces WAN son propensos a la congestión, lo que lleva normalmente a respuestas lentas de la aplicación. Con QoS, el administrador de la red puede definir prioridades para este tipo de aplicaciones a fin de que no las afecte los problemas de congestión y que el impacto sobre otras aplicaciones menos significativas no sea muy grande. Este tipo de solución, haciendo un paralelo al trafico vehicular usa la misma idea de proporcionar carrilles especiales a un trafico particular(estilo transmilenio) 1.12.2. Ejemplo 2: Repercusiones del trafico multimedia en la red. Las aplicaciones de transmisión de multimedia tales como NetMeeting, Real Audio y otras son cada vez mas populares entre los usuarios de red y generan una gran cantidad de tráfico UDP. Este trafico tiene la particularidad de no dar marcha atrás en el caso de congestión en la red; normalmente para evitar esto, el administrador de la red prohíbe o limita la implementación de aplicaciones multimedia. Qos permite controlar las repercusiones de estas aplicaciones en la red.

61

1.12.3. Ejemplo 3: Redes de convergencia y compatibilidad multimedia No es necesario solamente controlar las repercusiones del trafico multimedia, sino proporcionar un servicio especifico a este tipo de aplicaciones. QoS puede garantizar una calidad de servicio específica a determinadas aplicaciones de medios de secuencias. QoS permite convergencia real de redes de multimedia y de datos. Entre las ventajas que ofrece esta convergencia se puede destacar la telefonía IP utilizable con el ahorro de costos proporcional.

62

2. RSVP: PROTOCOLO DE CONFIGURACION DE RESERVA DE RECURSOS

2.1. MARCO GENERAL Si alguna vez ha intentando mantener una conversación de sonido en una red IP ocupada, ya sabe que el sonido puede cortarse cada vez que otras aplicaciones absorben parte del ancho de banda. El protocolo RSVP, para este caso específico es un método para lograr que el funcionamiento de las redes IP se asemeje más al de las redes telefónicas. RSVP permite que un sistema reserve una cantidad predeterminada de ancho de banda en una ruta de acceso específica de la red, lo que elimina la posibilidad de escasez de ancho de banda y reduce el jitter; la ruta de acceso específica, combinada con las especificaciones de QoS, se denomina flujo.

RSVP por tanto permite que las aplicaciones obtengan diferentes QoS para sus flujos de datos. Esta capacidad reconoce que diferentes aplicaciones tienen diferentes requerimientos de desempeño en la red. Algunas aplicaciones tradicionales interactivas o en batch requieren entrega confiable de datos pero no imponen ningún requerimiento para el tiempo de entrega; los tipos de aplicaciones mas nuevas tales como telefonía IP, videoconferencia y otras formas de comunicaciones multimedia requieren casi exactamente lo opuesto: la entrega de datos debe ser oportuna pero no necesariamente confiable; por esto, RSVP proporciona a las redes IP, la capacidad de soportar requerimientos divergentes para diferentes tipos de aplicaciones.

RSVP, es un protocolo de control de Internet tal como ICMP, que se encarga del establecimiento y mantenimiento de las reservas de los recursos a través de los árboles de distribución necesarios. RSVP no es un protocolo de enrutamiento, sino que trabaja en conjunto con ellos e instala el equivalente a listas dinámicas de acceso a través de las rutas que los protocolos de enrutamiento calculan. Por tanto implementar el protocolo en una red existente no requiere migración a un nuevo protocolo de enrutamiento.

RSVP es usado por los servidores para determinar la calidad de servicio que requieren y por los enrutadores para ofrecer servicios con Qos garantizada. Por tanto es un protocolo de señalización completamente independiente del tipo de calidad de servicio que la red provea. Esto implica que en la reserva de los recursos de la red para una aplicación con este modelo intervengan dos agentes distintos:

• El Protocolo de señalización ( en este caso RSVP), el cual permite a una aplicación hacer las reservas de recursos necesarias, y mantenerlas a lo largo de todo el camino que deberá seguir el flujo de datos que esta genere.

• Los Mecanismos que aseguren que, una vez hecha la reserva de una cierta

calidad de servicio para un flujo de datos, los paquetes pertenecientes al mismo

63

serán tratados de manera que se cumplan los parámetros de calidad aceptados en la reserva.

RSVP define la manera de crear, mantener y eliminar reservas de calidad de servicio, pero no define la manera de llevar a cabo dichas reservas, esto es responsabilidad del modelo de servicios integrados(intserv). Pero no define la manera de llevar a cabo dichas reservas. Esta visión, y el hecho de que RSVP es independiente de los algoritmos de encaminamiento de la red y que esté pensado para trabajar con IPv6, hacen que RSVP sea un protocolo pensado de cara al futuro de la red.

RSVP es un protocolo de señalización de extremo a extremo fuera de banda, que solicita una determinada cantidad de ancho de banda y latencia con cada salto de red que soporta. Si un nodo de la red(enrutador) no soporta RSVP, este protocolo se mueve hasta el siguiente salto. Un enrutador de la red tiene la opción de aprobar o de negar la reserva sobre la base de la carga de la interfaz para la que se solicita el servicio.

El protocolo esta definido por varias RFC(2205 a 2210), entre las que destaca la especificación funcional RFC2205(Braden,Berson,Herson,Jamin&Zhang,1997). Además existe un proyecto para una nueva versión del protocolo denominado RSVP2 de la University of Southern California/Information Sciences Institute. También existen varias implementaciones de libre distribución para Linux, FreeBSD,etc: MIcrosoft soporta RSVP con Windows 2000 y CISCO en sus enrutadores.

Para redes LAN existe una extensión de RSVP denominada SBM( Subnet Bandwidth Manager). RSVP, falla, normalmente en este tipo de redes, debido a la imposibilidad de mapear las posibilidades de Qos en los dispositivos de nivel 2. En la mayoría de la documentación se asocia el protocolo con las especificaciones de flujos definidas por el grupo Intserv, así como la funcionalidad de control de admisión, siendo estas características, responsabilidades propias del modelo de servicios integrados(IntServ).

Según el RFC 2205 (Braden, et al,1997) RSVP se ha diseñado con los siguientes objetivos en mente:

• Dar la posibilidad de que cada receptor haga sus propias reservas de

acuerdo a lo que cada uno requiera( receptores heterogéneos)

• Adaptarse dinámicamente a la conexión y desconexión de miembros de un grupo.

• Permitir a los usuarios especificar sus necesidades a nivel de aplicación.

• Debe adaptarse a los cambios que se presenten en las rutas, aunque no es

un protocolo de enrutamiento, si debe mantener un estado de las rutas

• Controlar el overhead generado por el mismo para que no crezca linealmente o con el numero de participantes

• Permitir acomodar distintas tecnologías en su implementación.

La siguiente figura(tomada del libro Internetworking Technologies Handbook, capitulo 48,Cisco Press, Junio 1999) ilustra un ambiente general del protocolo RSVP, desde el punto de vista de emisores, receptores e infraestructura de red.

64

Figura 15. Entrega de flujo de datos RSVP sobre la infraestructura de red.

En RSVP un flujo de datos es una secuencia de datagramas que tienen la misma fuente, destino(una o mas maquinas) y calidad de servicio(QoS). Los requerimientos de QoS se comunican a través de la red vía una especificación de flujo, que esencialmente es una estructura de datos usada por los servidores para requerir servicios especiales desde la red. Esta especificación, simplemente describe el nivel de servicio requerido por el flujo de datos. Normalmente se asocian a tres tipos o clases de servicios definidos por diferentes tipos de trafico(Ver sección 1.3 de este documento ), que para RSVP son: best-effort, garantizado(guaranteed o también denominado rate-sensitive traffic:trafico sensitivo a la tasa), o de carga controlada(también llamada delay-sensitive traffic: trafico sensitivo al retardo) . RSVP en resumen, permite que una aplicación solicite una especifica QoS para sus flujos de datos tal como se muestra en la Figura 16, tomada del libro Internetworking Technology Overview,Cisco Press, capitulo 46, pagina 14. Los administradores de red pueden apoyarse en los beneficios de RSVP en la red, aun para aplicaciones y servidores que no soporten el protocolo. Los servidores y enrutadores usan RSVP para entregar los requerimientos de Qos a los enrutadores que están en la ruta del flujo de datos y mantener la información de estado necesaria para proporcionar el servicio requerido, usualmente ancho de banda y latencia. RSVP usa una tasa de datos promedio, la cantidad de datos mayor que se puede mantener en cola y la mínima QoS para determinar la reservación de ancho de banda.

65

Figura 16. Implementación de RSVP en una red Cisco

Los algoritmos WFQ o WRED son los elementos de soporte para RSVP que permiten establecer la clasificación y planeación de paquetes requerida para los flujos reservados. Usando WFQ, RSVP puede entregar un nivel de servicio garantizado. Usando WRED, el protocolo RSVP entrega un servicio de carga controlada. RSVP puede desarrollarse en redes existentes con una actualización del software. 2.2. CARACTERISTICAS Y RESUMEN DE OPERACION las características básicas de RSVP, que permiten adaptarse a los objetivos de diseño, según el RFC 2205 son :

• Realiza reservas de recursos para aplicaciones unicast y multicast, adaptándose dinámicamente a los cambios de rutas y miembros de grupo.

• RSVP es simplex, esto es, hace reservas para flujos unidireccionales.

• RSVP es orientado al receptor, los receptores escogen el nivel de servicio

requerido y son responsables de iniciar y mantener la reserva activa mientras quieran recibir datos. Esto es así, porque el receptor es quien conoce sus limitaciones y la calidad de servicio que recibe. Esto permite la gestión de peticiones heterogéneas.

• El estado en routers y host es ‘soft’ , es decir, deben ser refrescados

periódicamente. Durante una comunicación larga es posible que nuevos miembros se unan al grupo mientras que otros lo dejen, y las rutas se modifican debido a los cambios en la red, por ello RSVP mantiene un estado de red. Esta información se mantiene por medio de mensajes que se envían

66

periódicamente para refrescar el estado. RSVP distingue 2 clases de información en cada enrutador: el estado de la ruta y el estado de la reserva.

• RSVP no es un protocolo de encaminamiento, pero depende de los protocolos

de enrutamiento presentes y futuros(los protocolos futuros deben calcular rutas incorporando la información de QoS y no necesariamente los resultados serán iguales a los usados con los protocolos de enrutamiento actuales).

• RSVP mantiene y transporta parámetros de control de tráfico y policy control

que son transparentes a RSVP.

• Proporciona varios modelos y estilos de reserva para satisfacer a una variedad de aplicaciones. La reserva de recursos en un router asigna ciertos recursos a la entidad que hace la reserva, pero no determina qué paquetes pueden usar estos recursos. Hay una función separada llamada filtro de paquetes, que selecciona los paquetes que pueden usar estos recursos. Este filtro puede ser estático o dinámico y permite establecer varios modelos de reserva. Actualmente existen tres estilos de reserva: libre, filtro fijo y filtro dinámico.

• RSVP proporciona una operación transparente a través de enrutadores que no

lo soportan.

• Soporta tanto IPv4 como IPv6.

• Control de sobrecarga del protocolo: la sobrecarga de RSVP se determina por tres factores:(Hernández,2001,cap.2,p.41) el número de mensajes RSVP enviados, el tamaño de los mensajes y los periodos de refresco de los mensajes de ruta y reserva. Para reducir la sobrecarga, RSVP funde los dos mensajes mientras atraviesan la red.

• Modular: RSVP tiene interfaz con otros 3 componentes en la arquitectura

intserv(arquitectura de servicios integrados):

o la especificación de flujo(flowspec) que se maneja a nivel de aplicación o sesión.

o el protocolo de enrutamiento de la red, que lleva los mensajes hasta los receptores.

o el control de admisión en la red que realiza las decisiones basado en el flowspec que se encuentra en los mensajes de reserva.

Una primera aproximación a un modelo de reservas podría indicarnos que las reservas fueran controladas desde el emisor; sin embargo esta aproximación, genera numerosos problemas: si se agrega un nuevo miembro dentro del árbol de distribución o si un elemento abandona el árbol, es responsabilidad del receptor reconfigurar una nueva conexión punto a multipunto con los receptores, lo que genera una enorme sobrecarga en la red cuando el grupo es de grandes dimensiones. Este esquema no podría tratar con receptores de características heterogéneas(algunos receptores podrían usar mejor hardware, u otros tener una conexión con menor ancho de banda) , como el emisor no conoce a priori a sus receptores, solo podría crear una reserva uniforme creando situaciones de desaprovechamiento de reservas o de injusticia.

67

El modelo de RSVP, por el contrario es basado en el receptor y es este quien reserva los recursos y mantiene esta reserva, mientras desee recibir datos del emisor. Cada receptor por tanto hace las reservas específicas adaptadas a sus necesidades. Esta característica se ilustra en la figura siguiente:

Figura 17. RSVP: orientado al receptor y árboles multicast

RSVP permite que varios receptores hagan reservas de recursos diferentes para un mismo grupo de distribución multicast. Esto, que en principio no afecta mucho al protocolo, complica la implementación de las aplicación y la solución al tema es responsabilidad de estas. La figura 17 muestra múltiples fuentes, múltiples receptores de datos para una particular aplicación distribuida. Las flechas indican flujos de datos desde los emisores S1 y S2 a los receptores R1, R2 y R3 y la nube representa la malla de distribución creada por el protocolo de enrutamiento multicast. La distribución multicast replica cada paquete de datos desde un emisor Si, para entrega a cada receptor Rj. La entrega unicast desde S1 a R1 se trata como un caso especial, esta malla de distribución multicast se conoce como una sesión. Una sesión esta definida por la dirección IP común(multicast) de destino de los receptores.

Figura 18. Sesión de distribución multicast

68

2.2.1. Funcionamiento del protocolo Para reservar flujo, el cliente y el servidor deben tener recursos asignados de cada elemento del hardware de red que participe en la transmisión. Para iniciar el proceso de reserva, el cliente envía un mensaje PATH al receptor. Estos mensajes son encaminados siguiendo las tablas de enrutamiento normales hacia los receptores. Los mensajes PATH contienen información sobre las características de tráfico que tendrán los datos enviados por el emisor y las características de recursos que tiene el camino de datos hasta cada uno de los receptores A medida que cada dispositivo de red(routers/switches) recibe el mensaje PATH se agrega a sí mismo a la lista y reenvía el mensaje. Esta lista permite que los paquetes posteriores de la misma sesión sigan la misma ruta. cualquier elemento de hardware que no entienda RSVP reenviará el mensaje como cualquier otro paquete, sin agregarse a la lista de hardware(o lista de dispositivos de red). El nodo receptor envía luego una respuesta al mensaje PATH que se denomina mensaje RESV( o de reserva). Este mensaje usa la misma ruta que el mensaje PATH(en orden inverso, por supuesto), puesto que cada salto de la ruta de acceso esta enumerado en el mensaje(cada salto se conoce como el previous hop en la literatura de RSVP). Cuando cada uno de los nodos intermedios recibe un mensaje RESV; guarda la información necesaria para mantener esa reserva y la pasa al nodo anterior(básicamente, comprueba que dispone del ancho de banda solicitado por la reserva y efectúa la reserva en ese momento). El proceso completo de reserva se ilustra en la figura 18(tomada del libro Introducción a Microsoft Windows 2000 Server, capitulo 6: Introducción a la infraestructura de red, publicado por Microsoft Press)

Figura 19. Reserva de recursos mediante los mensajes PATH y RESV

Si alguno de los dispositivos de red no puede reservar los recursos, el problema se indica mediante un mensaje de error. El jitter que puede producirse por utilizar diferentes rutas de acceso se reduce, porque todos los paquetes de esa sesión pasarán exactamente a través de los mismos enrutadores.

69

El emisor reenvía automáticamente un mensaje PATH de forma periódica para adaptarse a los estados cambiantes de la red. De manera predeterminada, este envío del mensaje PATH se produce cada 30 segundos. Si el dispositivo de red que tiene recursos reservados no recibe ningún mensaje PATH en un intervalo determinado de tiempo (que de forma predeterminada es 90 segundos), se eliminará la reserva. Así se evita que un error en la conexión comprometa recursos innecesariamente y las reservas de recursos permanezcan por siempre. Una vez finalizada la sesión, la estación que interrumpe la conexión enviará un mensaje PATH especial que indica al dispositivo de red que libere los recursos. Este se denomina mensaje PATH TEAR. 2.2.1.1. Ejemplos Los siguientes ejemplos(tomados del documento : Simulador del protocolo de reserva de recursos, Daniel Burguillos y Juan José López capitulo 3, pagina 48) ilustran la operación del protocolo RSVP. Supongamos que hay un emisor multicast que transmite el vídeo de un evento deportivo, y que el protocolo subyacente en la red ha determinado que el camino que debe seguir el flujo de datos es el mostrado en la figura 18( los números que acompañan a cada receptor es la velocidad a la que desea recibir datos). Y supongamos también que la señal de video está dividida en capas para acomodarla de forma correcta a la heterogeneidad de los receptores.

ORIGEN

Router A Router B

Router C

Router D

R3 3 Mbps R4

3 Mbps

Figura 20. Ejemplo de RSVP

El emisor envía mensajes Path que establece las rutas a seguir por los flujos de datos. Cada receptor, a su vez, envía un mensaje de reserva hacia el emisor el cual incluye la velocidad a la que desea recibir los datos. Cuando un mensaje de reserva alcanza un router, este ajusta su planific ador de paquetes para acomodarlo a la nueva reserva. El ancho de banda que un router envía hacia el siguiente dependerá de los anchos de banda que se han reservado por debajo de él. En la figura anterior los receptores R1, R2, R3 y R4 reservan respectivamente 20 kbps, 120 Kbps, 3 Mbps, 3 Mbps y 3 Mbps. La máxima petición que ha recibido el router D es de 3 Mbps, por lo que envía , para esta transmisión una reserva al router B de 3 Mbps ( nótese que no se reserva 6 Mbps, esto es porque R3 y R4 están viendo el mismo evento deportivo; por este motivo las reservas se han fusionado). La máxima petición que ha recibido el router C es de 100 Kbps, por lo que envía esta reserva al router B ( la codificación por capas

70

de la señal de video asegura que la señal de 20 Kbps que necesita R1 está incluida en la de 100 Kbps de R2 ). De la misma manera el router B fusiona las reservas de C y D enviando una única reserva de 3 Mbps hacia el router A, la cual llega al nodo origen de los datos. Tomemos ahora un nuevo escenario en el que cuatro personas están participando de una videoconferencia, tal y como se muestra en la figura 19. Cada una de estas personas tiene tres ventanas abiertas con la imagen de los otros tres participantes. Supongamos que el protocolo de enrutamiento multicast ha definido el árbol de distribución multicast como se muestra en la figura. Finalmente, supongamos que cada persona desea recibir los vídeos con una calidad de 3 Mbps. En este caso en cada uno de los enlaces de este árbol multicast deberán reservarse 9 Mbps en una dirección y 3 Mbps en la otra ( nótese que en este caso no se fusionan las reservas, dado que cada persona desea recibir 3 flujos de datos diferentes ).

Figura 21. Videoconferencia con RSVP

2.2.1.2. Estructura de una implementación RSVP una implementación RSVP según el RFC 2205 define la estructura de bloques mostrada en la figura 22. El protocolo debe estar soportado en los hosts extremos(emisores y receptores) y en los enrutadores por los que deberán pasar el flujo de datos. Como es imposible introducir un protocolo nuevo en toda la red al mismo tiempo, RSVP contempla la posibilidad de que en la ruta existan zonas sin soporte del protocolo(RSVP tunneling o zonas no RSVP). Al igual que otros protocolos de control como ICMP o IGMP, RSVP se ejecuta en “background” y no en el camino de datos; por tanto los paquetes que deben beneficiarse de la reserva de recursos iniciada por RSVP no serán diferentes de aquellos que no pertenezcan al flujo reservado.

71

Figura 22. Servidor y enrutador bajo el protocolo RSVP

Todos los mensajes de RSVP se encapsulan dentro de datagramas IP( como raw data) al igual, por ejemplo, que los mensajes del protocolo de control ICMP. Si un nodo de la red no dispone de la capacidad para encapsular raw data dentro de datagramas IP, se ha previsto que se encapsule el mensaje RSVP dentro de un mensaje UDP(este tema se especifica en el apéndice C del RFC 2205). La siguiente figura ilustra la posición del protocolo dentro del modelo de capas de internet.

Figura 23. Posición de RSVP dentro del modelo de capas de internet

72

2.3. CLASES DE CALIDAD DE SERVICIO EN RSVP Para RSVP se han especificado formalmente dos clases de calidad de servicio: servicio garantizado y el servicio de carga controlada. 2.3.1. Servicio Garantizado Esta calidad de servicio esta destinada para aplicaciones con requerimientos exigentes de tiempo real. Esta calidad asegura: un ancho de banda, un límite en el retraso y ninguna pérdida en las colas Para esta clase de servicio un flujo se describe usando un modelo token bucket y dada esta descripción , cualquier elemento de la red calcula varios parámetros describiendo como va a manejar los datos del flujo. Combinando los parámetros de todos los elementos que el flujo debe recorrer se calcula el retardo máximo que se produce en el flujo. El retardo extremo a extremo que sufre un paquete esta compuesto por dos componentes de naturaleza diferente: el “retardo fijo”(retardos de transmisión,etc) y el “retardo de encolamiento”. El retardo fijo es una propiedad de la ruta seleccionada, el cual no se determina por el servicio garantizado(guaranteed). El servicio garantizado determina exclusivamente el retardo de encolamiento, el cual es función del tamaño del token bucket (b) y de la tasa de transferencia de datos(o ancho de banda R) que la aplicación solicite. El servicio garantizado no controla ni el retardo mínimo ni el retardo medio de los datagramas, solo controla el retardo máximo de encolamiento, es decir el limite máximo del retardo que sufre un paquete desde el momento que es entregado en un nodo hasta el momento en que es enviado al siguiente nodo. Para el calculo del retardo máximo de un datagrama, deberá sumarse la latencia de la ruta que seguirá al retardo máximo de encolamiento(este termino se calcula en la siguiente sección) . 2.3.1.1. Información característica Una petición de servicio garantizado debe contener la especificación del trafico(mediante un Tspec) y la especificación del servicio requerido(mediante un Rspec). Una nueva petición se acepta si existen suficientes recursos. Una petición para aumentar el Tspec o Rspec de un flujo ya aceptado se toma como una nueva petición. Una petición que reduzca el Tspec o Rspec de un flujo ya aceptado será aceptada siempre. El Tspec contiene los parámetros b,r,p,m y M definidos previamente en el modelo de trafico token bucket. El Rspec tiene la forma de una tasa de transferencia R y un termino de relajación(slack term) S. La tasa de transferencia R se mide en bytes de datagrama IP por segundo, mientras que el término S se mide en microsegundos, y define la diferencia entre el retardo deseado y el que se obtiene de hacer una reserva de nivel R.

73

La siguiente tabla resume los elementos de Tspec y Rspec.

Tabla 5. Parámetros de Tspec y Rspec

Parámetro Tspec Descripción Unidad p Tasa pico del flujo Bytes/s b Tamaño del cubo(bucket dept) Bytes r Tasa de transmisión del cubo(token bucket rate) Bytes/s m Tamaño mínimo de un paquete Bytes M Tamaño máximo de un paquete Bytes Parámetro Rspec R Ancho de banda Bytes/s S Slack term: Diferencia entre el retraso deseado y

el obtenido usando una reserva de ancho de banda R.

µs

2.3.1.2. Requerimientos en cada elemento de la red Cada elemento de red debe asegurar que el servicio para un flujo con tasa de transferencia R será aproximadamente el mismo que el que se obtendría de una línea dedicada de ancho de banda R entre el origen y el destino. Cada enrutador caracteriza el servicio garantizado para un flujo determinado, asignando un ancho de banda R, y un espacio de memoria B, que representa los recursos que el flujo puede consumir, lo que significa que existe un ancho de banda R entre el emisor y el receptor. Para un servicio que siga el modelo de flujo perfecto con un cubo de capacidad b y tasa r(token bucket: ver capitulo Calidad de servicio, Sección 1.4.3.1) se puede calcular el limite de retraso como b/R siempre que R sea mayor que r. Para permitir desviaciones,normalmente se añaden dos términos de error C y D; con lo que el limite del retraso se convierte en b/R + C/R + D. Estos errores normalmente representan un retraso debido a paquetes de su propia cola o a imprecisiones propias del planificador. C: Término de error dependiente de la tasa de transferencia. Representa el retardo que un datagrama del flujo experimentara como consecuencia de los parámetros de transferencia del flujo. Un ejemplo para hacer necesario este tiempo seria la necesidad de serializar un datagrama dividido en celdas ATM. En la practica representa cuanto se aleja el servicio real de un servicio bit a bit. Este termino de error se mide en bytes D: Termino de error independiente de la tasa de transferencia. Representa el peor caso de variación del tiempo de tiempo de transito a través del enrutador. Este termino de error se mide en microsegundos. Con el servicio garantizado se introduce una variable p denominada la tasa pico del flujo(ver modelo token bucket en el capitulo de calidad de servicio de este documento), que reduce los limites del retraso. Además debemos considerar el efecto de la partición en paquetes en el flujo, considerando el tamaño máximo del paquete M ( se mide en bytes y estará de acuerdo con la especificación del flujo).

74

2.3.1.3. Limite del retardo extremo a extremo Tal como se define en la tesis de Enrique Hernandez(Reserva eficiente de recursos en redes de tiempo real, Enero 2001,capitulo 2, pagina 43) y en diferentes documentos relacionados con el modelo Intserv, para un flujo que atraviesa N nodos podemos acotar el retardo de cada paquete con la siguiente expresión(todos los parámetros de la expresión ya han sido mencionados y hacen relación al modelo token bucket y a la cantidad R: porción del ancho de banda del enlace que el flujo necesita, medido en bytes de datagramas IP por segundo).

( )( )

( )( )

tottot D

RCM

rpRRpMb

t ++

+−

−−=Re

en el caso que p>=R>=r

( )tot

tot DRCM

t ++

=Re

En el caso de que R>=p>=r. En la formula totC y totD representan la sumatoria de los términos de error C y D de

cada enrutador de la ruta. Para que este retraso, tal como se define acá se cumpla es necesario que el trafico entrante este conforme al algoritmo token bucket, es decir el trafico esta limitado por la ecuación [ ]rtbpt +,min .

Cada enrutador necesita ser informado de las características del tráfico(Tspec) y del flujo con las características de las reservas realizadas (Rspec). Además necesita los términos sumC y sumD que representan la suma de los términos C y D de cada

enrutador presente en la ruta de los datos, desde el origen hasta llegar a el. Para utilizar este esquema, los enrutadores tienen que aproximarse al modelo de flujo. Para ello se pueden utilizar varios algoritmos de planificación como el WFQ(mencionado en la sección 1.4.7.4 de este documento), Jitter EDD y Virtual Clock, siendo el mas utilizado el primero de ellos. Usando el planificador WFQ los valores de iC y iD se calculan de la siguiente manera:

iD es igual al MTU del enlace dividido por el ancho de banda del enlace, con la

condición de que M debe ser menor que el mínimo MTU de la ruta. El valor de iC se

asume que es M para considerar la fragmentación en paquetes y contabiliza la posibilidad de que un nuevo paquete llegue justo en el momento en que se comienza a enviar un paquete del máximo tamaño aceptado en el enlace de salida( iMTU ) con un

ancho de banda del enlace ( iAB ).

Por tanto:

∑∑ ==i

iitot AB

MTUDD ∑∑ == MCC itot

75

Respecto al tamaño del buffer que se debe reservar en los nodos el valor se calcula como b+ Csum+Dsum*r , donde Csum y Dsum son la suma de todos los parámetros Ci y Di anteriores al nodo. Cuando un receptor genera un RSpec para un mensaje de reserva con servicio garantizado debe incluir un termino de relajacion S (Slack term), que indica la diferencia en el retardo que existe entre el que se obtiene con la reserva de un ancho de banda R, y el retardo que la aplicación realmente necesita. En muchos casos la adición de un Slack Term correcto en un mensaje de reserva hace que la reserva pueda instalarse ( a diferencia de la misma reserva con este término a 0). Este término de relajación da una gran flexibilidad a los enrutadores del camino, ya que permite que adecuen sus reservas a las necesidades reales de la aplicación. Un nodo intermedio puede utilizar una cierta cantidad de slack disponible (Si) para reducir la reserva local. Un ejemplo de aplicaciones que requerirían esta clase de servicios son las videoconferencias H.323, que están diseñadas para correr sobre ISDN o ATM, pero igualmente se encuentran en internet y en muchas intranets basadas en IP. La codificacion H.323 es a una tasa constante o aproximadamente constante y requiere que una tasa de transporte constante este disponible en una red de conmutación de circuitos(como ATM). IP, por su naturaleza, en cambio es un red de conmutación de paquetes y adolece de la falta de mecanismos para soportar una tasa de servicio constante para el flujo de datos de una aplicación dada. A través del servicio garantizado, RSVP permite una tasa de servicio constante en una red de conmutación de paquetes (como IP), para este tipo de aplicaciones. 2.3.2. Servicio de carga controlada Para esta clase de servicio no hay una firme garantía de que se cumpla el servicio requerido. En este caso se puede indicar un Tspec( Especificación del trafico: usualmente el modelo token bucket) para la Qos requerida, aunque no es necesario incluir el parámetro de tasa pico p. Si el flujo se acepta, el enrutador intenta ofrecer un servicio equivalente a un flujo “best-effort” en una red ligeramente cargada. La diferencia crucial es que el flujo no se deteriora aunque aumente la carga de la red. Este tipo de servicio cumple con su propósito utilizando recursos mínimos, lo que permite a las implementaciones utilizar los recursos de red en una forma extremadamente eficiente. El servicio de carga controlada se adapta bien para aplicaciones “blandas” de tiempo real o aplicaciones de audio/vídeo que se recuperan adecuadamente de la pérdida ocasional de frames o cuadros.

76

2.4. MECANISMOS DE RSVP 2.4.1. Las reservas Los dos elementos fundamentales que permiten hacer una reserva en RSVP son la sesión y el descriptor de flujo. La sesión es la unidad para la cual se hace una reserva y equivale a una identificación del receptor. El descriptor de flujo describe la calidad de servicio deseada sobre determinados paquetes de datos que el emisor o emisores generarán. La sesión funciona como una llave principal para los mensajes RSVP y esta definida por los siguientes parámetros :

• DestAddres contiene la dirección IP del destino, ya sea unicast o multicast. • ProtocolId identificador del protocolo IP utilizado (IPV4 o IPV6).

• DstPort(opcional), puerto de destino generalizado, que puede ser tanto un

puerto TCP como UDP, como uno de cualquier otro protocolo de nivel de aplicación. En la practica se usan los puertos TCP/UDP.

En un mensaje RSVP, siempre debe existir un objeto llamado SESSION que contiene los datos descritos anteriormente. Por tanto, una sesión identifica específicamente a una aplicación receptora(por el puerto destino) de un host determinado(por la dirección IP). El descriptor de flujo es la unidad de información que permite definir la calidad de servicio para un conjunto de datos del emisor. Este descriptor de flujo posee dos parámetros:

• Flowspec :Este corresponde a la especificación del flujo, define la calidad de servicio deseada, y aunque este parámetro no depende del protocolo RSVP como tal , en cambio si depende del tipo de servicio utilizado ( normalmente debe ser uno de los tipos de servicios definidos en el modelo de servicios integrados). Este se divide en dos parámetros:

o Rspec(Especificación de la reserva). Describe la calidad de servicio

requerida.

o Tspec(Especificación del tráfico). Describe las características del flujo de datos.

• Filterspec: (Especificación del filtro):Este parámetro define el conjunto de

paquetes de datos, que deberá recibir la calidad de servicio definida por el flowspec. Puede seleccionar arbitrariamente que paquetes recibirán la Qos indicando: paquetes de un emisor dado, paquetes de un protocolo de alto nivel dado, paquetes en función de un campo de la cabecera. Para efectos prácticos

77

este parámetro se simplifica a sólo la dirección IP del emisor y opcionalmente el puerto TCP/UDP

La siguiente figura resume los elementos que definen una reserva de recursos.

Figura 24. Elementos de una reserva RSVP

El filterspec es la información que necesita el clasificador de paquetes, para determinar si un paquete pertenece a algunas de las reservas instaladas en el nodo. El planificador de paquetes a su vez necesita la información del flowspec, para determinar en cada momento el paquete que debe salir por una interfaz específica. La figura siguiente ilustra esta repartición.

Figura 25. Procesamiento de reservas

78

2.4.2. Reenvío de reservas RSVP es independiente del protocolo de enrutamiento que use la red. No tiene mucho sentido establecer un camino de datos con unas reservas especificas y que posteriormente este “camino de datos” no se usara en el momento de hacer el envió de los paquetes(si el algoritmo de enrutamiento, por ejemplo decidiera una ruta diferente entre emisor y receptor). RSVP resuelve el problema haciendo un envío de mensajes “salto a salto” que tiene tres pasos principales:

• Creación de la ruta: El emisor envía un mensaje PATH al receptor, el cual se encamina por la red siguiendo los algoritmos de enrutamiento propios de la misma. En cada nodo RSVP, se anota el nodo anterior desde el cual llego el mensaje.

• Petición de la reserva. el receptor realiza una petición de reserva mediante el

mensaje RESV. Este se envía salto a salto hacia el emisor, siguiendo la ruta definida por el mensaje PATH. (Si se enviara directamente el mensaje al emisor, podría irse por una ruta distinta). Cuando un mensaje RESV llega a un nodo RSVP, este realiza la reserva localmente, consulta cual es el salto anterior (Previous Hop) y reenvía el mensaje a dicho nodo. Así, se asegura que los mensajes de reserva seguirán exactamente el camino inverso recorrido por el mensaje PATH.

• Envío de datos: un nodo que reciba un paquete de datos susceptible de

pertenecer a una de las reservas que tiene instaladas, debe reenviar el paquete de datos siguiendo el camino en el que se ha instalado la reserva

2.4.3. Estilos de reserva Una petición de reserva incluye un conjunto de opciones que se denominan colectivamente el “estilo de reservación” o “estilo de reserva” RSVP incorpora una novedosa característica de diseño, por la cual la reserva de recursos(flowspec), es independiente de para quien se hace la reserva(filterspec). El filterspec se puede cambiar dinámicamente por los receptores, durante la vida de la reserva, sin necesidad de cambiar la calidad de servicio que reciben. Una reserva puede ser de dos tipos(Braden,Berson, Herson,Jamin& Zhang,1997,p.10):

• Shared(compartida). Todas las reservas para cada emisor deben ser tomadas como una sola. Este tipo de reservación es usada por un conjunto de emisores que no interfieren uno con otro y comparten la reserva.

• Distinct(diferenciada). Para cada emisor existe una reserva diferenciada del

resto. Es decir, una opción de reserva se refiere al tratamiento de reservaciones para diferentes emisores dentro de la misma sesión: se puede establecer una reservación diferenciada (“distinct”) por cada emisor o hacer una única reservación que es

79

compartida(“shared”) entre todos los paquetes de un conjunto de emisores seleccionados. Y desde el punto de vista de cómo se especifican los emisores, una reserva puede ser igualmente de uno de estos tipos(Braden,Berson, Herson,Jamin& Zhang,1997,p.11):

• Explicit(explícito) :Cada emisor debe especificarse explícitamente (mediante su dirección IP y puerto)

• Wildcard( por patrón):Los emisores se seleccionan implícitamente mediante un

patrón. Mezclando estas características se obtienen los siguientes estilos de reserva que ofrece el protocolo RSVP(Braden,Berson, Herson,Jamin& Zhang,1997).

Tabla 6. Estilos de reserva

Distinct Shared Explicit Fixed_Filter(FF) Shared_Explicit(SE) Wildcard No aplica. Wilcard-Filter(WF)

Por tanto, existen tres estilos de reservas en RSVP.

• FF: (Filtro Fijo). Los emisores se seleccionan de forma explícita y se hacen reservas separadas por cada uno de ellos. Se crean reservas diferentes para cada emisor.

• SE: (Explicito compartido). Los emisores se seleccionan de forma explícita, pero

las reservas se hacen de forma compartida. Es como una tubería compartida por varios emisores los cuales son seleccionados uno a uno por los receptores.

• WF(por patrón fija): Los emisores se seleccionan de forma implícita(por patrón)

y la reserva es compartida por todos los emisores seleccionados. Se crea una única reserva que es compartida por todos los emisores, es como una tubería en la que pueden escribir todos los emisores y de la que pueden leer varios receptores

La figura 26 (tomada del documento Simulador del protocolo de reserva de recursos, Daniel Burguillos, Juan José López, Enero 2000, pagina 58) muestra los diferentes estilos de reserva. El estilo de reserva WF es el mas voraz en cuanto a recursos necesarios y se extiende automáticamente en el momento que aparecen nuevos emisores. El estilo SE es una restricción del anterior en el cual los emisores se seleccionan explícitamente, el estilo FF es el mas restrictivo ya que no permite que las reservas se compartan entre varios emisores. Las reservas compartidas(shared) son apropiadas para aplicaciones multicast donde es improbable que los diferentes emisores transmitan al mismo tiempo(caso de una aplicación de audio). En cambio, las reservas diferenciadas(distinct) son más

80

apropiadas para servicios como el vídeo, donde cada receptor deseará recibir diferentes imágenes de forma simultánea.

Figura 26. Ejemplos de reservas con los diferentes estilos

2.4.4. Creación del camino de datos El primer paso para utilizar RSVP es crear el camino de datos, con este paso un emisor define el camino que deben seguir los datos hacia el/ o los receptores. Esto se hace a través del mensaje PATH. La ruta del mensaje PATH la definen los algoritmos comunes de enrutamiento. En cada nodo RSVP donde se recibe un mensaje PATH se guarda un “path state” (estado del camino) que contiene como mínimo la dirección del PHOP (salto anterior, previous HOP), que nos servirá luego para encaminar los mensajes de reserva, enviados por los receptores, por la ruta inversa. El mensaje PATH contiene además información adicional para definir el tipo de trafico que el emisor espera generar(guardada en un objeto SENDER-TSPEC). Esto servirá a los receptores a la hora de calcular las necesidades de QoS para recibir dicho trafico de forma efectiva.

81

El formato del mensaje PATH se detalla en la sección 2.5 de este documento. La información recogida en este paso(el “path state”) se almacena en una estructura de datos llamada Path State Block o PSB(definida en el [RFC 2209]), la cual guarda el estado path para una pareja(sesión,emisor) concreta. Si hay errores durante el envío del mensaje PATH, se debe detener el reenvío de este mensaje y se devuelve un error mediante el mensaje PathErr. Cada receptor primero debe unirse a un grupo multidifusion para empezar a recibir los mensajes Path. Esta gestión de los grupos multidifusión esta fuera del ámbito del protocolo RSVP y es parte de la funcionalidad del protocolo IGMP. 2.4.5. Como se realiza la reserva? Cuando un receptor recibe un mensaje PATH , este identifica a un posible emisor para la sesión dada y conoce todas las características del flujo de datos que generará el primero(mediante el objeto SENDER-TSPEC), como las características del camino de datos(mediante el objeto ADSPEC). Con esta información, el receptor tiene información suficiente para hacer una reserva. Las reservas las solicita el receptor mediante el mensaje RESV , que se envía hacia el emisor o emisores, a través de la ruta definida por el mensaje PATH. El formato del mensaje RESV se detalla en la sección 2.5 de este documento. El objeto especifico dentro de un mensaje RSVP, que describe la reserva es el llamado “flow-descr”(descriptor de flujo), que tiene un formato distinto, dependiendo de cada tipo de “estilo de reserva”. 2.4.5.1. Tratamiento de la reserva en un nodo Cuando el mensaje RESV llega a un nodo, se realizan básicamente 2 acciones, que se describen a continuación:

• Instalar la reserva en el nodo: Esto implica varios pasos, los mas importantes son los 3 siguientes:

o Validación administrativa: Es decir el modulo policy control (ver sección

2.2.1.2 ),valida que el usuario que realiza la petición de reserva tenga los permisos suficientes para instalar una reserva en el nodo. Si esta validación falla se devuelve un mensaje de error(mensaje ResvErr).

o Validación de admisión: El modulo de control de admisión se encarga de

consultar si existen recursos suficientes para instalar la reserva.

o Realización de la reserva: Si hay recursos suficientes y la validación administrativa resulta valida, se procede a la instalación de la reserva. Esta instalación consiste(entre otras operaciones) en el paso del filterspec y del flowspec de la petición al modulo clasificador y al planificador de paquetes(packet scheduler) respectivamente.

82

• Reenviar la reserva: cuando se instala la reserva en el nodo, el paso siguiente es que esta continué su camino hacia los emisores. Se resume en dos pasos:

o Merging de reservas: Si el nodo actual ya tiene instalada una reserva

igual o mayor a la solicitada, la petición no se reenvía y las reservan se fusionan(merged).

o Envío al PHOP: Si no es posible hacer una fusión de reservas, la petición

actual debe reenviarse hacia los emisores apropiados, esto se hace, recuperando la dirección o direcciones IP del salto anterior (Previous Hop) y enviando la petición a esa dirección.

La estructura de datos que guarda la información de la reserva en el nodo es llamada Reservation State Block (RSB, definida en el [RFC 2209]). Esta estructura de datos guarda una petición de reserva para la tripleta:(sesión, next hop,filter_spec_list). Donde “filter_spec_list” será una lista de FILTER-SPECs (en estilo SE), un único FILTER-SPEC(en estilo FF) o una lista vacía (en estilo WF). 2.4.6. Soft State El estado path y el estado de reserva deben ser refrescados periódicamente en cada nodo del camino, puesto que son válidos durante un determinado periodo de tiempo(por eso se dice que los estados RSVP en los nodos son “soft”, porque deben refrescarse periódicamente) Asociado con cada estado path y con cada estado de reserva existen dos valores de tiempo:

• “Refresh timeout”. Indica el intervalo de tiempo en el que se debe refrescar el estado path del salto siguiente o el estado de reserva del saldo anterior(en el caso del estado de reserva)

• “cleanup timeout”. Indica el intervalo de tiempo durante el que el estado

asociado es válido. En otras palabras, el estado path o de reserva dejará de ser válido si no recibe un refresco antes de que expire el cleanup timeout.

2.4.6.1. Funcionamiento y procesado de los mensajes de refresco Tanto el mensaje Path como el mensaje Resv contienen un parámetro que corresponde con el “refresh timeout”. Este valor se guarda en cada nodo intermedio junto con el “cleanup timeout”, que se calcula como un cierto número de veces el período de refresco. Cada nodo intermedio del camino tiene la misión de refrescar al nodo siguiente tras la expiración del período de refresco. Es decir, supongamos que el período de refresco de un cierto estado path ha expirado en un nodo; en este caso d icho nodo debe refrescar al NHOP(salto siguiente en el sentido de los datos) mediante el envío de un mensaje Path (este procedimiento aplica también para el estado de reserva y los mensajes Resv). El emisor es quien debe refrescar el estado path del primer nodo del camino. A su vez el receptor es el encargado de refrescar el estado de reserva del último nodo del camino. Si a la

83

expiración del periodo de “cleanup” no se ha recibido un mensaje de refresco , se elimina el estado (path o de reserva), y se envía un mensaje de cancelación del estado (mediante un mensaje PathTear en el caso del estado path, o mediante un mensaje ResvTear en el caso del estado de reserva) El procesado de un mensaje de path, tiene en cuenta los siguientes criterios:

• Si no existe un estado path relacionado, lo crea y reenvía el mensaje al NHOP según las tablas de enrutamiento.

• Si existe un estado path relacionado(se trata de un mensaje de refresco):

o Restablece el “cleanup timeout”(el estado path ha sido refrescado) o El mensaje Path es reenviado al siguiente salto en algunos de los casos

siguientes:

§ Constituye un cambio en el camino establecido: Esto se detecta consultando las tablas de enrutamiento del nodo.

§ El estado path cambia con el nuevo mensaje Path.

Igualmente, en cada nodo del camino se envía un mensaje Path al NHOP en los siguientes casos:

• El protocolo de enrutamiento informa de un cambio en las interfaces de salida.

• El timeout de refresco de un estado path ha expirado. El funcionamiento en el caso de la recepción de un mensaje Resv es equivalente:

• Si no existe un estado de reserva relacionado, lo crea y reenvía el mensaje al PHOP según la información del estado path asociado.

• Si existe un estado de reserva relacionado (es un mensaje de refresco):

o Restablece el “cleanup timeout”(el estado de reserva ha sido

refrescado) o El mensaje Resv es reenviado al salto previo (PHOP) en el caso

siguiente:

§ Constituye un cambio en el estado actual( por ejemplo como

consecuencia de una petición de aumento de la QoS de una reserva ya instalada )

En cada nodo del camino se envía automáticamente un mensaje Resv al PHOP en el siguiente caso:

• El timeout de refresco del estado de reserva ha expirado.

84

2.4.6.2. Cancelación del soft state Cuando expire el “cleanup timeout” tanto para un estado path como para un estado de reserva, se deben realizar las siguientes tareas:

• Eliminar el estado en el nodo local.

• Eliminar los estados relacionados en el camino mediante el envío de un mensaje de “teardown”. Este mensaje será un PathTear en el caso de expiración del estado path, o será un ResvTear en el caso de expiración de un estado de reserva.

Un mensaje de cancelación del estado, destruye el estado en el nodo y debe reenviarse al siguiente nodo sin retardo. El timeout puede expirar debido a varias circunstancias (Burguillos&López,1999,p. 64):

• Se ha perdido un mensaje de refresco. Esto puede ocurrir porque los mensajes RSVP se entregan sin garantías(por viajar en IP) y puede ser que se pierda alguno de ellos, esto se soluciona con las siguientes estrategias:

o Hacer que el “cleanup timeout” sea varia veces superior al “refresh

timeout ”; por ejemplo si es 3 veces el “refresh timeout”, significaría que se deben perder 3 mensajes de refresco para que expire el timeout de cancelación(la probabilidad de perdida de los 3 mensajes es muy baja).

o Reservar una pequeña cantidad de ancho de banda en los enlaces para los mensajes RSVP. Esto se usaría como protección frente a las eventuales perdidas por congestión.

• Cambios en las rutas, definidas por el algoritmo de routing. Lo que significa que

algunos nodos que eran parte del camino de datos ya no lo son y por tanto no recibirán mensajes de refresco, con lo que expirado el timeout cancelaran sus estados.

• Diversos problemas como caídas de los nodos, etc. En estos casos el emisor y el

receptor son informados del problema a través de los mensajes de cancelación. 2.4.7. OPWA Los mensajes Path normalmente contiene una información adicional que se materializa dentro del objeto ADSPEC. Este objeto, como vimos, recoge las características en cuanto a QoS del camino de datos, esta información es muy útil para los receptores, puesto que ellos pueden determinar la QoS que les ofrece el camino de datos. Cuando los mensajes PATH contienen este objeto, se dice que RSVP funciona en modo OPWA(“One Pass With Advertising”, algo así, como un paso con información adicional). Si los mensajes Path no tuvieran este objeto, los receptores tendrian que intentar hacer una reserva a ciegas, es decir ir probando hasta que la reserva sea aceptada.

85

La información del ADSPEC contiene datos generales del camino y dependientes del servicio ofrecido(carga controlada, garantizado). Los datos generales se resumen en la siguiente en la tabla.

Tabla 7. Información del objeto ADSPEC

DATO DEFINICION Latencia mínima se del camino

contiene la suma de las latencias individuales de cada enlace(no se contemplan los retardos de espera en los nodos). Para el servicio garantizado, si a este valor se le suma el límite del retardo en colas(Sección 2.3.1.3) se puede obtener una cota máxima del retardo que se introducirá en los paquetes de datos.

Ancho de banda del camino Contiene el ancho de banda mas pequeño disponible para reservas de entre todos los enlaces que conforman el camino de datos

Global Break bit Indica si hay algún nodo en el camino que no soporta RSVP

Cuenta de los saltos IS (Integrated Services)

Cuenta cuantos nodos del camino soportan RSVP y el modelo de servicios integrados.

MTU del camino Informa del MTU mínimo de entre todos los enlaces individuales del camino

Para el servicio garantizado el Adspec contiene la siguiente información adicional

Tabla 8. Estilos de reserva

Ctot El valor del parámetro C compuesto de todo el camino.(mencionado en la sección 2.3.1.3)

Dtot Valor del parámetro D compuesto de todo el camino. Csum Valor compuesto de C desde el último punto de

“reshaping”(reshaping: es un punto en el cual se deben reclasificar los paquetes que no casan con el Tspec del enlace, en estos puntos el trafico supera las reserva en un determinado enlace)

DSum Valor compuesto de D desde el último punto de “reshaping”

Guaranteed Service Break Bit Informa si hay algún salto en el camino de datos que no implemente el servicio Guaranteed.

2.4.8. Zonas que no soportan RSVP Un nuevo protocolo de red no se puede instalar en todos los nodos al mismo tiempo(mucho menos en una red como Internet). Por tanto la implementación del protocolo(una vez este totalmente estandarizado)debe realizarse por fases , desde una primera implantación en intranets y redes de tamaño mediano e investigación hasta la totalidad de los nodos de la red; por tanto se debe convivir con los nodos que no

86

implementen el protocolo. Dentro del diseño del protocolo esta contemplado que este detecta este tipo de zonas y pueda funcionar bajo esas circunstancias. Evidentemente una zona que no soporte el protocolo puede influir sobre la calidad de servicio que pueda ofrecerse. La siguiente figura muestra una situación de una zona que no soporta el protocolo RSVP.

Figura 27. Zonas que no soportan RSVP

la zona no RSVP esta delimitada por los nodos A y B (estos si implementan el protocolo). Cuando se envía un mensaje PATH, este mensaje no se ve afectado por la zona no rsvp, porque este mensaje solo usa los algoritmos de enrutamiento convencionales. Cuando el mensaje PATH llega al nodo A se guarda el estado path y se reenvia siguiendo los mecanismos de forwarding del nodo, este mensaje atravieza la zona no RSVP llegando al nodo B. El nodo B tiene constancia que el ultimo nodo RSVP fue A, con lo que su estado path guarda la dirección IP de A como nodo anterior, y dado que no ha recibido el paquete del nodo A, deduce que se ha pasado por una zona no RSVP y activa el flag NonRSVP en la cabecera del mensaje. El mensaje llega al receptor de forma normal. Cuando el receptor envía un mensaje RESV, dicho mensaje llega a B salto a salto por la zona RSVP. A B le consta que el salto RSVP anterior fue A, con lo que reenvía el mensaje poniendo como dirección destino la dirección IP de A. El nuevo mensaje se encamina hasta A siguiendo los algoritmos convencionales de enrutamiento(la ruta del mensaje path pudo tomar un camino distinto). Desde A el mensaje se envía salto a salto hasta el emisor. 2.5. MENSAJES RSVP Los mensajes RSVP son enviados dentro de datagramas IP ( aunque el RFC 2205 plantea la posibilidad de encapsulación dentro del protocolo de transporte UDP). Un mensaje RSVP se divide en dos partes, una cabecera común de tamaño fijo( 64 bits) y una secuencia variable de objetos RSVP(los cuales a su vez pueden tener también tamaño variable).Los objetos contienen la información relevante del mensaje.

87

2.5.1. La cabecera Este es el primer objeto de cualquier mensaje RSVP y contiene los campos estrictamente necesarios para identificar el tipo de mensaje. La siguiente figura ilustra los elementos que conforman un mensaje RSVP. Mensaje RSVP Cabecera común objetos

64 bits variable Cabecera común

32 bits

Vers Flag Tipo Mens. Checksum RSVP

SendTTL (reservado) Long. RSVP Objeto RSVP

32 bits

Figura 28. Formato de los mensajes RSVP

A continuación describimos cada uno de los campos que conforman la cabecera común de los mensajes de RSVP.

• Vers: La versión del protocolo • Flag: No tiene un uso definido • Tipo Mens: Tipo de mensaje RSVP. actualmente se han definido los siguientes:

Long. (Bytes) Clase C-Type

(contenido objeto)

88

Tabla 9. Tipos de mensajes RSVP

Valor Tipo de mensaje 1 Path 2 Resv 3 PathErr 4 ResvErr 5 PathTear 6 ResvTear 7 ResvConf

• Checksum RSVP: Suma de comprobación (puede valer 0 para indicar que no se transmite checksum)

• SendTTL: Valor inicial del campo TTL del datagrama IP

• Longitud RSVP: Longitud total en bytes incluyendo la cabecera común.

2.5.2. Tipos de mensajes RSVP RSVP en su versión inicial define 7 tipos de mensajes diferentes cuya utilización se resume a continuación:

• Path: Lo genera los emisores de una sesión y se transmiten en el sentido del flujo de datos hacia los receptoes.

• Resv: Lo genera un receptor que desea recibir datos de uno o varios emisores.

RSVP transporta los mensajes Resv siguiendo la ruta que crearon los mensajes Path anteriormente enviados por los emisores, pero en sentido inverso.

• PathErr: Informa de los errores que puede provocar un mensaje PATH. Se envía

hacia el emisor que generó el error y no cambia el estado path de los nodos por los que pasa.

• ResvErr: Informa que una petición de reserva ha fallado en alguno de los nodos

del camino. El mensaje de error puede hacer referencia a lo siguiente: falla de admisión, ancho de banda no disponible, servicio no soportado, ala especificación del flujo, ruta ambigua.

• PathTear: Elimina los estados path de todos los nodos del camino. Viaja de

emisor a receptor en el sentido del flujo de datos.

• ResvTear: Elimina el estado de reserva en todos los nodos del camino de datos, es enviado desde un receptor hacia todos los emisores, en sentido contrario al flujo de datos.

• ResvConf. Cuando se realiza una reserva, puede pedirse que se genere una

confirmación. En este caso se envía al receptor que lo solicitó un mensaje

89

ResvConf desde el último nodo que reciba el mensaje de reserva(puede ser el nodo emisor). Este mensaje viaja en el sentido del flujo de datos.

La figura 29 muestra la estructura de los principales mensaje RSVP. 2.5.3. Los objetos RSVP un mensaje RSVP contiene una secuencia variable de objetos RSVP. Cada objeto RSVP contiene un tipo de información que tendrá un uso determinados para cada tipo de mensaje. El formato de cualquier objeto RSVP es el mostrado en la figura 26. Contiene una parte fija(de 32 bits) la cual identifica al objeto, y una parte de tamaño variable que alberga el contenido del objeto. Los campos de un objeto RSVP son los siguientes:

• Long: Longitud total del objeto(en bytes). Debe ser múltiplo de 4 • Clase: Clase del objeto (identifica al objeto).

• C-Type: Subtipo del objeto dentro de la clase

Una implementación RSVP debería reconocer los siguientes objetos:

Tabla 10. Objetos RSVP

Clase de Objeto Descripción NULL El contenido de este objeto será ignorado. Este objeto

podrá aparecer en cualquier parte del mensaje SESSION Contiene una dirección IP del destino, un identificador del

protocolo IP y un puerto de destino. Todo mensaje RSVP deberá contenerlo.

RSVP-HOP Contiene la dirección IP del nodo RSVP que envía el mensaje.

TIME-VALUES Valor para el período de refresco usado por el generador del mensaje(R)

STYLE Indica el estilo de reserva usado(FF, SE o WF) FLOWSPEC Define la QoS deseada. Tiene formatos diferentes para

cada estilo de reserva.

FILTER-SPEC Define el subconjunto de paquetes de datos que recibirán la QoS definida por un FLOWSPEC.

SENDER-TEMPLATE Dirección IP del emisor y puerto de origen o etiqueta de flujo. Identifica al emisor

SENDER-TSPEC Define las características del flujo de datos que generará el emisor. El formato depende del tipo de servicio que se implemente en la red

ADSPEC Recoge estadísticas en los mensajes PATH para informar a los receptores de las capacidades reales de la red.

ERROR-SPEC Especifica el tipo de error en mensajes PathErr o ResvErr, y una confirmación en el mensaje ResvConf.

POLICY-DATA Datos para decidir si una reserva es administrativamente permitida, es decir, si el usuario dispone de privilegios

90

Clase de Objeto Descripción suficientes para instalar una reserva en el nodo local

INTEGRITY Contiene datos criptográficos para autentificar al nodo origen y verificar la integridad del mensaje

SCOPE Lista explícita de emisores hacia los que debe reenviarse el mensaje.

RESV-CONFIRM Dirección IP de un receptor que solicitó confirmación 2.5.4. Composición de los mensajes RSVP

Como anteriormente se describe, un mensaje RSVP está compuesto por la cabecera común más una secuencia de objetos. Esta secuencia se define para cada tipo de mensaje RSVP. Algunos objetos son obligatorios y otros opcionales dependiendo del tipo de mensaje. La figura 29(tomada de Burguillos & López,p. 69)muestra el orden recomendado de estos objetos dentro de cada mensaje.

Figura 29. Mensajes RSVP

91

2.5.5. Composición de los objetos RSVP Los mensajes RSVP se componen de una secuencia de objetos. Cada objeto RSVP tiene un objetivo concreto y transporta parte de la información que el mensaje necesita. La identificación de los objetos se hace a través de los parámetros Clase y C-Type que aparecen en la cabecera, los valores se listan en la tabla siguiente.

Tabla 11. Objetos RSVP y clases

Objeto Clase C-Type SESSION 1 1,2 RSVP_HOP 3 1,2 INTEGRITY 4 _ TIME_VALUES 5 1 ERROR_SPEC 6 1,2 SCOPE 7 1,2 STYLE 8 1 FLOWSPEC 9 1,2 FILTER_SPEC 10 1,2,3 SENDER_TEMPLATE 11 1,2,3 SENDER_TSPEC 12 2 ADSPEC 13 2 POLICY DATA 14 1 RESC_CONFIRM 15 1,2

El parámetro C-Type se utiliza para diferenciar entre subtipos de objetos, y normalmente diferencia entre la versión del objeto para IPv4 y la versión para IPv6 (aunque en algún caso sirve para diferenciar entre el tipo de servicio requerido: carga controlada o garantizado). En esta sección, detallamos la estructura interna de los principales objetos RSVP basados en la documentación del RFC 2205 y en el documento Simulador del protocolo de reserva de recursos,Daniel Burguillos,Juan Jose Lopez, capitulo 4, sección 4.8.5. 2.5.5.1. Objeto Session Este objeto identifica una sesión RSVP. Este objeto debe aparecer en todos los mensajes RSVP, dado que informa sobre la sesión a la que corresponde el mensaje. El formato es el siguiente:

32 bits

Dirección destino IPv4 Id Protocolo Flags Puerto destino

Class=1,C-Type=1

Dirección destino IPv6( 16 bytes)

Id Protocolo Flags Puerto destino Class=1,C-Type=2

Figura 30. Objeto SESSION

92

Los parámetros que contienen son los siguientes:

• Dirección destino: La dirección IP(IPv4 o IPv6 dependiendo del C-Type) unicast o multicast del destino de la sesión. El valor no puede ser cer.

• Id protocolo: El identificador del protocolo IP para el flujo de datos

• Puerto destino: puerto TCP/UDP destino para la sesión. para indicar “ninguno”

se dejará a cero. 2.5.5.2. Objeto Rsvp-hop Contiene la dirección IP y el identificador de la interface del último salto RSVP conocido que envía el mensaje, puede corresponder al PHOP(Previous Hop) o al NHOP(Next Hop) dependiendo de la dirección del mensaje.

32 bits

Dirección IPv4 del PHOP/NHOP Logical Interface Handle

Class=3,C-Type=1

Dirección IPv6 del PHOP/NHOP

Logical Interface Handle Class=3,C-Type=2

Figura 31. Objeto RSVP-HOP

los parámetros del mensaje son:

• Dirección del PHOP/NHOP: Dirección IP del último salto RSVP conocido.

• Logical Interface Handle(LIH): identifica la interface por la que se reciben los mensajes de esa session. Un valor 0 indica que no hay interface

2.5.5.3. Objeto Integrity Este objeto no se ha definido completamente, pero contendrá datos criptográficos para autentificar el nodo origen del mensaje y para validar la integridad del mismo.

93

2.5.5.4. Objeto Time-Values Este objeto contiene el periodo de refresco R(en milisegundos) usado para generar el mensaje que lo contiene. Aparece en los mensajes Path y Resv. Su formato se indica a continuación:

32 bits

Periodo de refresco R Class=5,C-Type=1

Figura 32. Objeto TIME-VALUES

2.5.5.5. Objeto Error-Spec Este objeto especifica el tipo de error en mensajes PathErr o ResvErr y la confirmación en el mensaje ResvConf. Su formato se indica a continuación.

32 bits

Dirección IPv4 del nodo de error Flags Código de error Valor de error

Class=6,C-Type=1

Dirección IPv6 del nodo de error

Flags Código de error Valor de error Class=6,C-Type=2

Figura 33. Objeto ERROR-SPEC

Los parámetros que contiene el objeto ERROR-SPEC son:

• Dirección IP del nodo que causó el error • Flags: 0x01.Indica que todavía hay una reserva en el punto de fallo. 0x02.

Indica que el FLOWSPEC que ha fallado es estrictamente mayor que el FLOWSPEC pedido por el recepto(solo en mensajes ResvErr)

• Código del error: Un byte que describe el error. • Valor de error: Dos bytes indicando información adic ional sobre el error.

94

2.5.5.6. Objeto Scope Este objeto contiene simplemente una lista de direcciones IP, usadas para encaminar mensajes con ámbito wildcard, las direcciones deben listarse en orden numérico ascendente. 2.5.5.7. Objeto Style Este tipo de objeto aparece en todos los mensajes de tipo Resv, es decir, en los mensajes Resv, ResvTear,ResvErr y ResvConf. Informa del estilo de reservas que se utiliza en el siguiente objeto(FILTER_SPEC) y su formato se muestra en la figura.

32 bits

Flags Vector de opciones Class=8,C-Type=1

Figura 34. Objeto STYLE

los parámetros que contiene son los siguientes:

• Flags(todavía no definidos)

• Vector de opciones: En este campo se describe el tipo de reserva. Si un nodo no reconoce alguno de los bits, debería ignorarlos y solo interpretar aquellos que conozca. Por ahora se manejan estas combinaciones(definidas por los valores en hexadecimal):

o Estilo WF: 10001b o Estilo FF: 01010b o Estilo SE: 10010b

2.5.5.8. Objeto Flowspec Este objeto contiene los parámetros que describen la calidad de servicio requerida. Hay formatos diferentes para cada tipo de servicio soportado(por ahora solo Garanteed y Controlled Load). El formato de este objeto lo mostramos a continuación, este formato no es propio de RSVP sino que se define en el RFC 2210, el cual introduce el uso de los servicios del Modelo de Servicios Integrados con RSVP.

32 bits

95

Servicio Guaranteed A(0) (no usado) B(10)

C(2) Reservado(0) D(9) E(127) F(0) G(5)

Token Bucket Rate(r) Token Bucket Size(b) Peak Data Rate(p)

Minimum Policed Unit (m) Maximum Policed Unit(M)

H(130) I(0) J(2) Rate(R)

Slack Term(S) Class=9,C-Type=2

Controlled_Load Service

A(0) (no usado) B(7) C(5) Reservado(0) D(6)

E(127) F(0) G(5) Token Bucket Rate(r) Token Bucket Size(b) Peak Data Rate(p)


Class=9,C-Type=2

Figura 35. Objeto FLOWSPEC

Algunos de los parámetros que aparecen en el FLOWSPEC del servicio garantizado son:

• A: Número de versión (0) • B: Longitud total. • C: Cabecera de servicio, servicio número 2(garantizado)

• D: Longitud de los datos del servicio.

• E: Id. del parámetro(El parámetro es la especificación del token bucket “Token

Bucket Tspec”) y el valor del parámetro es 127. • F: Flags del parámetro,(no esta activado actualmente).

• G: Longitud del parámetro 127. En este caso la longitud son 5 palabras, una

por cada característica del token bucket. • Token Bucket Rate(r), Token Bucket Size(b), Peak Data Rate(p), Minimum

Policed Unit(m), Maximun Packet Size(M): Estos parametros especifican el flujo de datos basado en el modelo “token bucket”

• H:Id. del parámetro.(En este caso el parámetro es el Rspec para el servicio

garantizado y el campo corresponde a la identificación del parámetro, cuyo valor es 130).

• I: Flags del parámetro 130.

96

• J: Longitud del parámetro 130. En este caso la longitud son 2 palabras, una por

cada parámetro del Rspec.

• Rate(R), Slack Term(S): Descripción de la calidad de servicio requerida mediante un ancho de banda (R) y un término de relajación del retardo(S).

Para el servicio “carga controlada ” los parámetros son los siguientes:

• A: Número de versión (0) • B: Longitud total. 7 palabras sin contar la cabecera • C: Cabecera de servicio, servicio número 5(carga controlada)

• D: Longitud de los datos Controlled-Load.

• E: Id. del parámetro(El parámetro es la especificación del token bucket “Token

Bucket Tspec”) y el valor del parámetro es 127. • F: Flags del parámetro 127,(no esta activado actualmente).

• G: Longitud del parámetro 127. En este caso la longitud son 5 palabras, una

por cada característica del token bucket. • Token Bucket Rate(r), Token Bucket Size(b), Peak Data Rate(p), Minimum

Policed Unit(m), Maximun Packet Size(M): Estos parametros especifican el flujo de datos basado en el modelo “token bucket”

2.5.5.9. Objeto Filter-Spec Este objeto describe los paquetes que deberán obtener la calidad de servicio descrita en el FLOWSPEC. El formato es el siguiente:

32 bits

Dirección IPv4 origen Puerto origen

Class=10,C-Type=1

Dirección IPv6 origen (16 bytes)

Puerto origen Class=10,C-Type=2

97

Dirección IPv6 origen (16 bytes)

Flow Label(24 bits) Class=10,C-Type=3

Figura 36. Objeto FILTER-SPEC

Los parámetros del objeto son:

• Dirección IP de origen: La dirección IP de un host emisor. Debe ser diferente de 0.

• Puerto origen: El puerto UDP/TCP de un emisor, un valor cero indica “ninguno”.

• Flow Label: Una etiqueta de flujo que identifica a los paquetes pertenecientes a

un flujo de datos. 2.5.5.10. Objeto Sender-Template Este objeto identifica a un nodo originador de trafico. El formato del objeto es igual al del objeto FILTER-SPEC, con el número de clase 12. 2.5.5.11. Objeto Sender-Tspec Este objeto describe las características del flujo de datos que generará el emisor, lo cual se hace mediante la especificacion de un “token bucket”. El formato es el siguiente y los parámetros se describieron previamente cuando se detallo el objeto flowspec.

32 bits

A(0) (no usado) B(7) C(1) Reservado(0) D(6)

E(127) F(0) G(5) Token Bucket Rate(r) Token Bucket Size(b) Peak Data Rate(p)


Class=12,C-Type=2

Figura 37. Objeto SENDER-TSPEC

98

2.5.5.12. Objeto Adspec Este objeto recoge las capacidades de reserva de los nodos del camino de datos. Se utiliza en el mensaje Path para informar a los receptores de las características reales y las posibilidades de reserva del camino de datos. La estructura del objeto es compleja, consta de 3 partes:

• Cabecera de objeto global • Fragmento de parámetros globales por defecto • Secuencia de fragmentos, uno por cada servicio de QoS soportado en el

camino Son obligatorias las dos primeras partes (cabecera y parámetros globales), mientras que la aparición del resto vendrá dada por las características del camino de datos.

32 bits

Cabecera del mensaje

A(0) Reservado Long. total del mensaje(B) Fragmento de parámetros generales(C)

(siempre presente)

Fragmento del servicio Guaranteed(D) (presente si lo requiere la aplicación)

Fragmento del servicio Controlled-Load(E)

(presente si lo requiere la aplicación)

Class=13,C-Type=2 Fragmento de Parámetros Generales

C(1) X Reservado D (8) E(4) F G(1)

IS Hop Count H(6) I J(1)

Ancho de banda estimado del path K(8) L M(1)

Mínima latencia del path N(10) O P(1)

MTU compuesto

Fragmento del servicio Guaranteed

A(2) X Reservado B (N-1) C(133) D(0) E(1)

Valor compuesto de C extremo a extremo ( Ctot) F(134) G H(1)

Valor compuesto de D extremo a extremo(Dtot) I(135) J K(1)

1

99

C compuesto desde el ultimo punto de “reshaping” (Csum) L(136) M N(1)

D compuesto desde el ultimo punto de “reshaping” (Dsum)

parámetros específicos del servicio(si existen)

Fragmento del servicio Controlled-Load

A(5) X B C (N-1)

parámetros específicos del servicio(si existen)

Figura 38. Objeto ADSPEC

A continuación definimos algunos de los parámetros del objeto. Los parámetros de la cabecera del objeto ADSPEC son los siguientes:

• A: Número de versión(0) • B: Longitud total del objeto sin contar la cabecera

• C,D,E: Fragmentos de datos.

Algunos de los parámetros del fragmentos de datos generales son:

• C: Cabecera del servicio , servicio número 1 • D: Global Break Bit(Shenker&Wroclawsky,1997) marcado como X, y longitud

del bloque de datos de parámetros generales

• IS Hop Count: Contabiliza cuantos routers con capacidades RSVP/IS existen en el camino de datos (IS=Integrated Services). Definido en el [RFC 2215].

• Ancho de banda del path: Estimación del ancho de banda del camino de datos,

corresponde con el mínimo ancho de banda de los enlaces individuales que componen el camino(Shenker&Wroclawsky,1997)

• Mínima latencia del path: Representa la latencia extremo a extremo sin tener

en cuenta retardos de encolamiento, es decir la suma de las latencias individuales que componen el camino. Definido por Shenker & Wroclawsky.

• MTU compuesto: El mínimo de los MTUs de los enlaces individuales que

componen el camino de datos. Definido por Shenker & Wroclawsky.

10

N

N

1

100

2.5.5.13. Objeto policy-data Contiene los datos necesarios para decidir si una reserva es administrativamente permitida, o sea, si el usuario dispone de privilegios suficientes para instalar una reserva en el nodo local. Actualmente su formato no ha sido definido. 2.5.5.14. Objeto resv-confirm Este objeto dentro de un mensaje ResvConf o Resv , da la identificación del nodo receptor que ha pedido una confirmación de reserva. Su formato se muestra en la figura siguiente.

32 bits

Dirección IPv4 del receptor Class=15,C-Type=1

Dirección IPv6 del receptor

Class=15,C-Type=2

Figura 39. Objeto RESV_CONFIRM

2.6. EJEMPLOS DE QoS Y RSVP 2.6.1. QoS para VoIP Este primer ejemplo muestra una solución que para nuestro caso, no necesariamente implanta RSVP, sino que utiliza otra estrategia de señalización discutida en la sección 1.5.1 llamada IP precedence(Precedencia IP), mas una herramienta adicional de QoS. Uno de los mas promisorios usos de las redes IP es la posibilidad de compartir bajo la misma infraestructura de red LAN el trafico de voz y el trafico tradicional de datos, esta estrategia puede ayudar a reducir los costos de transmisión reduciendo el número de conexiones de red, compartiendo las conexiones y la infraestructura existente. Presentamos acá un ejemplo de solución propuesta por Cisco, empresa que ha desarrollado diversos productos enfocados al tema de VoIP. Para poder proporcionar la calidad de voz requerida, se debe agregar una capacidad QoS a las tradicionales redes de datos. Las características del software IOS(presente en los enrutadores CISCO) el da al trafico VoIP el servicio que este requiere, mientras el trafico de datos tradicional tambien obtiene el servicio requerido.

101

La figura 40(tomada del libro Internetworking Technology Overview, capitulo 46, pagina 16) muestra el ejemplo de una empresa que ha escogido reducir algunos de sus costos de voz , combinando el trafico de voz, dentro de su existente red IP. El trafico de voz se digitaliza en cada oficina sobre 3600 procesadores de módulos de voz. Este trafico luego es enrutado a través del Gatekeeper de H.323, el cual hace el requerimiento específico de QoS para el tráfico de voz. En este caso el valor de precedencia IP se fija a un valor alto para el trafico de voz; se habilita el algoritmo WFQ sobre todas las interfaces del enrutador para esta red. WFQ automáticamente hace el reenvío del trafico de voz en cada interface de salida, reduciendo de esta forma el retardo y el jitter para este tipo de trafico. traffic. Dado que las redes IP originalmente administran trafico LAN-LAN, muchos datagramas que atraviesan la red son paquetes cuyo tamaño puede ser mayor de 1500 bytes. Sobre un enlace lento (velocidades inferiores a enlaces T1/E1), los paquetes de voz son forzados a esperar detrás de estos grandes paquetes lo que puede adicionar retardos incluso de cientos de milisegundos. La técnica LFI(discutida en la sección 1.4.9) se usa en conjunto con WFQ para partir estos “grandes datagramas” e intercalar el trafico de voz para reducir tanto el retardo como el jitter.

Figura 40. Ejemplo de solución VoIP implementada por Cisco

102

2.6.2. QoS para video streaming Las aplicaciones de video streaming, requieren a menudo una cantidad significativa de ancho de banda para que puedan ser soportadas en una red IP. En la red que se muestra en la figura 28(tomada del libro Internetworking Technology Overview, capitulo 46 [Qos Networking], pagina 16) RSVP se usa en conjunto con ATM PVCs(circuitos virtuales ATM) para proporcionar ancho de banda garantizado a todas las locaciones dispersas. RSVP se configura a través del Cisco IOS(sistema operativo para los enrutadores) para definir rutas desde la redes en las orillas de la red a través del núcleo ATM(backbone ATM). Esta red de rutas garantizadas ,es usada por la aplicaciones de videoconferencia o de simulaciones de tiempo-real.

Figura 41. Ejemplo de video streaming usando RSVP y una malla ATM

Los enlaces OC-3 ATM se configuran con múltiples circuitos virtuales de 3Mbps que conectan a varios sitios remotos. RSVP se encarga de asegurar que la calidad de servicio desde este PVC(circuito virtual) se extienda hasta la aplicación a través de la red local enrutada(red IP). En el futuro el software CISCO IOS deberá extender esta capacidad de RSVP para configurar dinámicamente estos circuitos virtuales conmutados(ATM SVCs: switched virtual circuit). Esto reducirá enormemente la complejidad de configuración, automatizando estas tareas.

103

2.7. PROBLEMAS DE RSVP Si recordamos lo estudiado, 2 tipos de servicio pueden ser requeridos vía RSVP. El primero es el muy estricto “servicio garantizado” que proporciona unos limites definidos sobre el retardo punto a punto y un ancho de banda asegurado para el trafico que conforma las especificaciones del flujo reservado. El segundo tipo de servicio es el “servicio de carga controlada” que da un comportamiento mejor que “best-effort” aun en condiciones de alta carga en la red(congestión), por tanto es posible(por lo menos teóricamente) proporcionar el requisito de QoS para cada flujo en la red, a través de la señalización RSVP y la disponibilidad de recursos. Sin embargo, existen varios inconvenientes prácticos para esta aproximación:

• Cada dispositivo a través de la ruta, incluyendo los sistemas finales como servidores y PCs deben ser capaces de “soportar” RSVP y “señalizar” la calidad de servicio requerida.

• Las reservaciones en cada dispositivo necesitan ser refrescadas

periódicamente, lo que agrega un trafico adicional en la red e incrementa la posibilidad de que la reservación expire(time out), si los paquetes que contienen la información de refresco se pierden. Existen algunos mecanismos que ayudan a solventar el problema, pero esto adiciona una mayor complejidad al protocolo.

• El hecho de mantener el “soft state” en cada enrutador, combinado con el

control de admisión en cada nodo, adiciona una gran complejidad por los requerimientos adicionales de memoria para soportar un gran numero de reservaciones.

• Puesto que la información de estado necesita mantenerse en cada enrutador, la

escalabilidad con cientos de miles de flujos a través del backbone(core) de la red se convierte en un problema.

Por ello, el modelo planteado por RSVP y servicios integrados, ha sido fuertemente criticado con respecto a sus características de escalabilidad; el mantenimiento del estado en los enrutadores y la información de flujo impone un gran overhead sobre las interfaces de los enrutadores. Mucha gente cree que esta aproximación no escala en grandes redes y mucho menos en internet; y no es nuestro tema de estudio, entrar a determinar las razones fundamentales que impiden que el modelo no escale, ya los años han demostrado que la estrategia basada en agregación, al estilo Diffserv y MPLS es la llave ganadora, por ahora. Aun dentro de esta estrategia ganadora, RSVP como protocolo de señalización(separado de intserv) ha demostrado al mercado sus posibilidades y ventajas. Una nueva estrategia propuesta por cisco, es la posibilidad de manejar algún tipo de agregación de RSVP que soluciona los temas de escalabidad(como veremos en la sección 2.8 “Mitos sobre RSVP”). Todas estas reflexiones, conspiran a colocar a RSVP en las orillas de la red, en manos de los administradores de las redes corporativas. Por el contrario, la arquitectura INTSERV y RSVP puede llegar a ser un modelo viable para reservación de recursos en redes corporativas( o sea en intranets, que es hacia

104

donde están enfocadas las recomendaciones que esta tesis plantea). Las redes corporativas están típicamente limitadas en su tamaño y operadas en un único dominio administrativo, por tanto muchos de los problemas de escalabilidad tienden a desaparecer. Los servicios integrados pueden soportar ancho de banda garantizado para telefonía IP y videoconferencia en redes corporativas. RSVP igualmente puede usarse para reservación de recursos y control de admisión para tráfico que va hacia redes de área amplia o Internet. Según David Powell, administrador de productos de QoS de Cisco, “RSVP se esta convirtiendo mas en una tecnología enfocada en la empresa” y este hecho esta demostrado, con la creciente implementación del protocolo en enrutadores y servidores(aplicaciones y equipos) de distintas marcas y modelos. El esquema normalmente sugerido en la mayoría de documentos y RFC es que RSVP señalizará desde la red local(orilla de la red), el ancho de banda requerido, pero en vez de hacer una señalización RSVP(paso a paso) sobre el backbone de la red, se deben usar clases de servicio(diffserv y MPLS) y túneles para enviar los mensajes de señalización que las aplicaciones requieren a través de la red(Internet). Por tanto, a medida que RSVP prolifera en los equipos y aplicaciones con los cuales los usuarios corporativos acceden a internet(como ocurre hoy en día), los administradores de red debe estar preparados para aprender como usar el protocolo para solicitar recursos IP públicos.

Tabla 12. Puntos fuertes y débiles de RSVP

PUNTOS DEBILES Y PUNTOS FUERTES RSVP NO ESCALA!!!

• Estado: Excesivamente grande • Refrescos: Generan demasiado trafico.

NO SE DEBE APLICAR EN EL BACKBONE!

• pero algún modelo de agregación RSVP, podría ser el siguiente paso después de Diffserv.

SE PUEDE APLICAR EN LA ORILLA DE LA RED, EN REDES CORPORATIVAS( INTRANETS)!!!. SE PUEDE USAR COMO PROTOCOLO GENERAL DE SEÑALIZACION IP

• Incluso con MPLS!!!( para requerir recursos IP públicos).

105

2.8. MITOS SOBRE RSVP Aún existen varios mitos relacionados, con la implementación de RSVP(algunos de ellos, ya comentados), estos incluyen:

• Escalabilidad: RSVP es por flujo, pero esto no escala en el backbone. • Control de admisión: RSVP no esta disponible para ejecutar control de admisión

sobre gateways de voz.

• Retardos en establecimiento de las llamadas: El tiempo necesario para establecer una reservación punto a punto es muy alto.

Las secciones siguientes discuten a mayor profundidad cada una de estas afirmaciones, los ejemplos están relacionados con ejemplos de implementación desarrollados por la empresa Cisco. 2.8.1. Escalabilidad Si percibimos RSVP como la arquitectura de Intserv, es probable que esta afirmación sea cierta(como se comento en la sección 2.7). Intserv utiliza RSVP sobre una base por flujo, lo que puede originar problemas de escalabilidad, sin embargo, estos temores son exagerados; por ejemplo los enrutadores Cisco han demostrado la capacidad para manejar mas de 10000 flujos RSVP con mínimo impacto en términos de CPU y Memoria. La implementación de RSVP no genera problemas de escalabilidad para redes pequeñas. Para grandes redes, diversos fabricantes y Cisco recomiendan la implementación de una combinación de las dos arquitecturas de QoS: Intserv con Diffserv( como se define en el Rfc2998) ; esta estrategia, discutida en la sección 1.11.1.2 de este documento, es una solución muy escalable; Intserv se usa en la orilla de la red para proporcionar tratamiento por flujo y control de admisión, mientras que Diffserv se desarrolla en el centro(core), lo que permite que el trafico se maneje de manera agregada. La versión 12.2(2)T del software Cisco IOS, fue el primero en introducir esta integración ( Intserv-Diffserv ) y desde hace aproximadamente 1 año, la versión esta disponible en los productos comerciales(enrutadores). La estrategia de envío de refrescos para cada estado(correspondiente a un flujo), no es escalable. El Rfc2961( Refresh Reduction) es un mecanismo que IETF(grupo Internet Engineering Task Force) ha estandarizado para reducir los mensajes de refresco. La estrategia, consiste en enviar estos mensajes de refresco, no por flujo sino un mensaje único agregado(varios flujos). El software Cisco IOS, soporta esta estrategia desde finales del año 2002. El IETF ha estandarizado un esquema para agregar RSVP: rfc3175: RSVP agregado. Esto permite que se definan puntos de agregación o desagregación, donde se crea una zona donde múltiples estados “paralelos” por flujo se convierte en un único estado. Cisco y otras empresas están investigando activamente la implementación de esta funcionalidad y a finales de este año debe estar disponible en los productos.

106

2.8.2. Control de admisión Contrario al pensamiento generalizado, RSVP resulta ser una ideal selección para la administración del control de admisión. Es el único mecanismo conocido y estandarizado para proporcionar control de admisión punto a punto. RSVP ha sido una parte integral del Software Cisco IOS, desde su invención a mediados de los años 90. La sincronización de llamadas para H.323 se agregó en la versión de 12.1(5)T del software Cisco IOS. La compresión del encabezado IP(cRTP) es una funcionalidad clave para la voz. RSVP no considera la estrategia de control de admisión en ancho de banda comprimido, lo que se hace es “inflar” el ancho de banda de tal forma que RSVP haga el control de admisión de forma adecuada . Este problema esta siendo resuelto y RSVP soportará la compresión del encabezado IP en la sexta modificación de la versión 12.2T del software Cisco IOS. El control de admisión usando RSVP esta disponible en los primeros gateway de voz que incluye los enrutadores cisco series 2600, 3600, el servidor de acceso universal Cisco AS5300, Cisco AS5350,AS5400 y los gateways universales AS5850. 2.8.3. Retardo en el establecimiento de la llamada Este problema es dependiente del desarrollo especifico que se haga del protocolo. Existen diversas razones que pueden originar retardo en la configuración de una reservación punto–a- punto; usualmente hay dos causas principales:

• Los mensajes de control RSVP no se marcan con una prioridad mas alta y/o • Existen perdidas de mensajes de control RSVP en la ruta de la llamada.

Desde la versión 12.2T de Cisco IOS, los mensajes de control de RSVP pueden ser marcados a través de Diffserv(DSCP: Diffserv Code Point), asegurando de esta manera, que estos sean tratados con una prioridad alta. Esta estrategia minimiza los potenciales retardos causados por los algoritmos de planeación en los nodos(scheduling) de acuerdo a los mensajes de control RSVP. La pérdida de mensajes de control RSVP esta relacionada con la situación antes descrita; suponga que estos mensajes no se marcan como de alta prioridad, los mecanismos como WRED tienden a borrar este tipo de paquetes en situaciones de congestión, de tal forma que se aumenta el tiempo en el establecimiento de la reservación. El Rfc2961 define el concepto de “mensajeria confiable RSVP”: el proceso RSVP continuamente retransmite los mensajes hasta que se recibe un mensaje explícito de asentimiento. Esta estrategia esta disponible desde la quinta modificación de la versión 12.2T del software Cisco IOS.

107

La latencia causada por el proceso RSVP en cada enrutador para la ruta de los mensajes de control es extremadamente pequeña. Por ejemplo, el valor es cerca de 10ms por nodo (pruebas en enrutadores Cisco series 3600 y 7200 ), de tal forma que una ruta de 10 saltos podría tomar una décima de segundo para el establecimiento de la llamada(la reserva en este caso). Esto valor no se debe confundir con la latencia que se establece durante la duración de una llamada. En conclusión, RSVP es una solución viable(especialmente en redes corporativas) . El protocolo ha demostrado un gran valor agregado y actualmente esta siendo desarrollado globalmente.

108

3. IMPLEMENTACION DE RSVP EN INTRANETS: RECOMENDACIONES

3.1. INTRODUCCION En este capitulo enunciaremos los elementos, que hemos considerado claves en la implementación de un protocolo de reserva de recursos en un ambiente como intranet, nuestra idea es desarrollar estos puntos claves (producto del análisis y aprendizaje obtenido) enfocándonos en las restricciones y soluciones desde el punto de vista practico. Sin embargo este documento, no pretende ser una guía de implementación de QoS en intranet, pero el desarrollo de reserva de recursos esta estrechamente ligada con este tema. La estructura del capitulo que hemos propuesto esta basada inicialmente en una ambientación sobre los elementos preliminares que se deben tener en cuenta para abordar la reserva de recursos de red en intranets, las variables, áreas de desarrollo y estándares; posteriormente definimos las fases o tares que deben realizarse para la implementación del protocolo y concluimos con un ejemplo real que nos ilustra con mayor claridad el esfuerzo requerido, para lograr el desarrollo de un esquema de reserva de recursos, incluso en un ambiente pequeño, como intranet. Esta guía no debe considerarse un producto final consolidado, mas aun que los estándares y productos referentes al protocolo están en plena evolución, pero si es un punto de partida muy importante para que las organizaciones piensen en sus estrategias de Qos en redes LAN y empiecen a considerar las posibilidades de migración hacia estos temas. Es mi objetivo que este documento contribuya a esclarecer estas inquietudes y a tener un panorama mas claro, que nos permita generar respuestas proactivas a la crecientes necesidades de los usuarios en términos de infraestructura de red y de aplicaciones.

Figura 42. Flujo de trabajo

109

3.2. PUNTOS A TENER EN CUENTA 3.2.1. Rsvp y servicios integrados en redes LAN Una calidad de servicio predecible punto a punto requiere calidad del servicio para el usuario sobre el último kilómetro(en el ámbito de la red LAN) . Para diferenciar entre diferentes clases de servicio, una tecnología LAN debe soportar prioridades para flujos aislados reservados y no reservados. La IEEE ha desarrollado estándares para reenviar clases de trafico en switches y puentes(bridges). El estándar propuesto requiere 3 bits de prioridad en el encabezado de la trama ethernet(tal como lo vimos en la sección 1.6.1.3, donde mostramos el estándar IEEE 802.1p que permite que las redes LAN soporten prioridades, basado en un valor definido en el frame). A fin de proporcionar garantías de QoS, las reservaciones de recursos deben ser hechas sobre la capa de enlace. Por supuesto, los switches de la capa de enlace necesitan clasificadores y mecanismos de planeación para proporcionar diferentes clases de servicio. Para reservación de recursos, los switches de la capa de enlace igualmente necesitan tener asignadores de ancho de banda que mantengan registro de las reservaciones. Un nuevo protocolo se hace necesario para permitir que los asignadores de ancho de banda se puedan hablar entre ellos. Un módulo se encarga de trasladar una reservación de la capa 3 en una reservación de la capa2. Esto proporciona la interface entre un protocolo de reservación de la capa 3 ( tal como RSVP ) y el asignador de ancho de banda. Esta estrategia es la planteada por el protocolo SBM(Subnet Bandwith Manager) que mencionamos en la sección 1.5.3 ; este protocolo define un mecanismo de señalización para control de admisión basado en LAN, que permite a los enrutadores con capacidad RSVP y los dispositivos de las capas 2 y 3, soportar reserva de recursos LAN para flujos de datos RSVP. ATM podría hacer posible la garantía de calidad de servicio, pero no es claro que ATM llegue a ser económicamente factible en un futuro próximo. Si las garantías no son requeridas, La calidad del servicio se puede realizar con solamente prioridades. Puesto que el ancho de banda de las LAN es relativamente económico, es probablemente más barato adicionar ancho de banda que tener un mecanismo complejo de reservación. Cuando suficiente ancho de banda esta disponible, un servicio de alta prioridad, sin garantías es tan bueno como una garantía cuantitativa. En resumen los administradores de red tendrán tres posibilidades para tratar con la calidad del servicio para el usuario final en el futuro. Primero, ellos podrían comprar nuevo hardware que soporte garantías de calidad del servicio. Segundo, ellos podrían actualizar sus LANs para soportar prioridad(y en este caso el estándar IEEE 802.1p, serían una estrategia para implementar prioridades a nivel de enlace, como se describió en la sección 1.5. 3) y desarrollar los mecanismos de reservación en la capa de enlace como lo propone el grupo de ISSLL(integrated services over specific link layers). Tercero, ellos podrían sobreaprovisionar sus redes y trabajar sin garantías.

110

Figura 43. Estrategias de Qos para intranets

3.2.2. Motivación a Qos.... no solo mas ancho de banda En el mundo nuevo de la convergencia(redes de voz, datos y video juntas),liderado por las nuevas aplicaciones como voz sobre IP y multimedia, los factores de mínima latencia y jitter se convierten en un elemento crítico; simplemente incrementar el tamaño del “pipe”(ancho de banda) de la red IP, para cumplir con estos requerimientos no siempre es suficiente. En este punto, los vendedores y los grupos de estándares están creando técnicas y tecnologías que permiten que IP mejore la calidad de servicio que puede proporcionar, mientras mantiene las características que le han permitido ser el protocolo dominante en la red. Lograr un nivel mas alto de Qos en redes IP es un objetivo que los administradores de red no podrán ignorar; la necesidad de mantener niveles de servicio adecuados mientras se implementan nuevas aplicaciones intensivas en ancho de banda nos conducirá a mayores esfuerzos dentro de la priorización y administración del tráfico de red. El simple “sobreaprovisionamiento de los enlaces”, es una estrategia que tiene un limitado potencial a largo plazo; por tanto los administradores de red deberían reconocer la importancia de entender las estrategias y tecnologías de Qos disponibles actualmente e iniciar los procesos de planeación e implementación, de tal forma que sus redes sean capaces de sostener niveles aceptables de desempeño, a medida que el trafico aumenta. Al tratarse de un conjunto de tecnologías nacientes, Qos presenta muchos retos a nivel técnico, organizacional y empresarial, que tomaran muy rápidamente un sitio prominente dentro de la lista de intereses de los administradores de red. Adicionalmente los administradores de red deberán ser conscientes de la falta de personal experimentado en el tema, teniendo que recurrir a firmas de consultoría que

111

les ayuden a desarrollar su estrategia de Qos(en sus fases de planeación, diseño e implementación ). Aun no podemos saber cuales estrategias, técnicas y tecnologías de Qos serán las mas ampliamente adoptadas; muchas de estas son complementarias y se pueden implementar distintas combinaciones dependiendo de las necesidades especificas. Mantener la mente abierta a todas las posibles soluciones de Qos que surjan, junto con las pruebas exhaustivas de productos potenciales generará a largo plazo los mejores resultados. Las redes ATM fueron diseñadas para responder a las necesidades de QoS, pero su progreso en redes de área local y de campus ha sido muy limitado.

Figura 44. Qos: Retos y motivaciones

Según un estudio realizado vía Internet, por International Network Services (Network Quality of Service) a finales del año 2000, con empresas de diversos sectores y de todos los continentes del mundo, los siguientes factores en su orden, que se muestran en la figura 45, son los elementos que mas motivan la implementación de una estrategia de calidad de servicio. Este estudio demuestra que al contrario de lo que podría pensarse, el factor que mas influye en la decisión de implementar Qos es la necesidad de tener un mecanismo de prioridad para las aplicaciones de datos de misión crítica(específicamente para las aplicaciones que soportan el corazón del negocio en la empresa). Las nuevas aplicaciones como multicasting, videostreaming y audiostreaming, por el contrario solo fueron importantes para un porcentaje muy pequeño de las empresas evaluadas en el estudio. El segundo factor mas importante es la “telefonía IP”; el rápido crecimiento de esta tecnología parece asegurado según las respuestas de las empresas. El tercer factor en importancia son los “SLA”(service level agreements), y constituyen el factor mas mencionado (por la suma de mayor y menor contribución), por tanto las empresas y sus “carriers” están en la búsqueda de Qos que les permita brindar niveles de servicio significativos y administrables, por tanto no son solo importantes las capacidades de Qos de la empresa sino la de su carrier o carriers y deben estar sincronizados en sus estrategias de desarrollo.

112

72

66

61

58

55

55

53

41

39

33

21

28

34

34

34

32

38

40

40

46

0 20 40 60 80 100

Aplicaciones de datos misión critica

Telefonia IP

Service level agreements

Proteccion contra downloadsintensivos en anchos de banda

Administracion de acceso al servidor

Teleconferencia

CTI(Computer telephony integrationapplications)

Multicasting

Videostreaming

Audiostreaming

Porcentaje de encuestados

mayor contribucion

menor contribucion

Figura 45. Factores que contribuyen a la importancia de QoS

Concretamente la estrategia de Qos puede estar amarrada principalmente a la solución de los siguientes 2 temas puntuales:

• Cuellos de botella en el ancho de banda de la ultima milla • Latencia(retardo) punto a punto

y los beneficios esperados de estas mejoras podrían estar centrados sobre distintos aspectos que se resumen en la siguiente tabla:

Tabla 13. Beneficios esperados de QoS

Beneficios esperados de QoS • Cumplir con las demandas de los usuarios de nuevas

aplicaciones corporativas • Usar Internet para VPNs, intranets o extranets • Mejorar el desempeño de las aplicaciones de misión crítica

existente • Mejorar la seguridad de la red(protección de ataques) • Satisfacer requerimientos de mejor desempeño para

algunos usuarios específicos • Minimizar la necesidad de ancho de banda

adicional(administración de costos) • Construir aplicaciones robustas de comercio electrónico

113

3.2.3. Barreras de implementación de QoS Las barreras de implementación de un estrategia de Qos parten inicialmente de las razones que aducen los administradores de red para no decidirse por una estrategia, dentro de las razones que normalmente se enuncian están las siguientes(tomado del estudio de International Network Services, Noviembre 2000):

Tabla 14. Razones para no implementar QoS

Razones para no implementar QoS • Otros proyectos de mayor prioridad • No es necesario en este momento • No se puede justificar la relación costo/beneficio a los

directivos de la organización • Posiblemente agregaran mas ancho de banda, en vez de

definir una estrategia de Qos(sobreaprovisionamiento) • Problemas organizacionales y/o de procesos • Falta de estándares para QoS • Costo de los productos QoS es demasiado alto • Falta de personal con experiencia en el tema • Complejidad para mantener e implementar las políticas de

QoS • Dificultad para determinar cuales usuarios deben obtener

prioridad vía QoS • Falta de herramientas de administración de políticas

Aun a pesar de la inmadurez de la productos de Qos, estos han tenido un buen nivel de aceptación dentro de las empresas, pero igualmente se requiere que los vendedores y proveedores de este tipo de soluciones, desarrollen una serie de mejoras a fin de que estas tecnologías sean ampliamente adoptadas e implementadas. Los siguientes factores, mostrados en la figura 46, son citados normalmente como las barreras mas significativas(en su orden) para lograr la implementación de un estrategia de Qos. (Tomado del estudio de International Network Services referente al tema de Calidad de servicio en redes). El costo elevado de los productos de Qos (unido a los problemas técnicos) constituye una importante barrera a la hora de implementar una estrategia de Qos. La ausencia de estándares contribuye a aumentar los temores de la organización, temores que se deben disipar a medida que las soluciones ganen credibilidad y disminuyan sus costos. Las empresas necesitan asistencia externa durante todas las fases de desarrollo de una estrategia de QoS(Dado la falta de personal capacitado y al desconocimiento del tema), especialmente en la planeación, diseño e implementación. La fase de operación de la estrategia de QoS debe ser mas fácilmente administrable dentro de la organización.

114

46

43

40

38

36

34

33

33

32

32

30

29

23

22

19

0 5 10 15 20 25 30 35 40 45 50

Costo de los productos de Qos es muy alto

Falta de estándares de Qos

Imposible determinar cual método de QoSdesarrollar

Falta de personal calificado

Problemas organizacionales o de procesos

Falta de herramientas de administración depolíticas

No se puede justificar la relación costo-beneficioante los directivos de la organización

Los productos Qos son muy complejos

Complejidad para implementar y mantener políticasde Qos

Incapacidad para determinar los requerimientos deQos

Otros proyectos de mayor prioridad

Dificultad en determinar cuales aplicacionesobtienen prioridad QoS

Inadecuada disponibilidad de entrenamiento

Dificultad para usar herramientas de administraciónde de políticas de Qos

Dificultad para determinar cuales usuarios obtienenprioridad QoS

Porcentaje encuestados

Figura 46. Barreras para no implementar QoS

3.2.4. Primero QoS, luego RSVP Aunque el énfasis de este documento no es definir una guía para la implementación de una estrategia de QoS en la organización, este trabajo debería preceder la decisión de implementación del protocolo RSVP o de cualquier otro esquema de señalización de Qos, particularmente porque se requiere hacer el balance de las alternativas disponibles en el mercado. Para efectos de tener una guía general, no separada de la estrategia de QoS, presentemos las recomendaciones para el estudio de QoS, que nos permitan tener un contexto adecuado para la implementación de RSVP. Estas recomendaciones de Qos requerirán un estudio mas exhaustivo pero los elementos

115

presentados en este trabajo deben ser la base que permita tener una guía completa del tema. Aunque las recomendaciones generadas están enfocadas principalmente sobre la infraestructura de red, una guía de Qos debe estar enfocada en cada uno de los elementos presentes dentro de la estrategia de Qos, esto es:

• La aplicación y el sistema operativo cliente/servidor • La tecnología del servidor • Los dispositivos de comunicación(routers,switches)

• Las tecnologías de red(protocolos)

La naturaleza de las aplicaciones y la jerarquía de estas dentro de la organización deben definir las prioridades dentro de la red e impactar sobre las funcionalidades esperadas en los dispositivos y en la infraestructura de red. La decisión de implementar nuevas aplicaciones, a su vez esta definida por el mercado, las necesidades especificas de los usuarios , los nuevos paradigmas y la madurez de las soluciones tecnológicas. Por tanto las directrices de una estrategia de QoS en la organización deberían enfocarse básicamente en 4 directrices principales(Diaz& Quintero,1997):

• Calidad de servicio: Este elemento define las necesidades especificas por aplicación en términos de elementos de comunicación, sistemas operativos, servidores, priorizacion y gestión de trafico, reservas de recursos. Estos factores definen las características que deben tener las soluciones en términos de aplicación y de parámetros de jitter, retardo, ancho de banda de la infraestructura de red, todo lo que desde el punto de vista técnico tiene impacto en lo que percibe el usuario. Por tanto, es el punto de partida para dimensionar los requerimientos y tomar las decisiones respecto al tipo de tecnología de QoS que se requiera implementar y a las necesidad de compra o actualización especificas. El índice QE(producto calidad/eficacia) referido en la sección 1.11.1.1 es un buen elemento de ayuda para decisión sobre una tecnología o combinación de tecnologías en particular.

• Plan estratégico de redes: Si bien las definiciones del planeación estratégica no

son del alcance de este documento, el plan estratégico de redes debe estar íntimamente ligado con el plan estratégico de la empresa, que debe definir las necesidades de intercambio de información planteadas por la organización. Por tanto el mapa de navegación de la empresa, debe estar ligado a la infraestructura de red que soporte los objetivos de la organización; es decir debe existir una sinergia entre la estrategia de la organización y la estrategia de la infraestructura de red. Se deben tener claros los objetivos a corto, mediano y largo plazo y la organización debe estar plenamente conciente de ellos, de sus implicaciones, sus alcances y sus beneficios. Las aplicaciones y la red están alineadas con este plan estratégico. Este plan estratégico también define las políticas y prioridades de Qos y las políticas de red.

116

• Costos : No solo se debe recomendar, evaluar y seleccionar los servidores aplicaciones y las tecnologías de red, que mejor satisfacen las necesidades de QoS que hacen parte del plan estratégico, sino que estas posibles soluciones deben estudiarse a la luz de los costos generados, no solo económicos sino en términos de impacto sobre la infraestructura y la cultura organizacional. Estos costos no son referidos únicamente a la implementación de la estrategia sino a sus tareas y herramientas posteriores de administración, configuración, escalabilidad y mantenimiento.

• Estándares : Este elemento se refiere a que se deben tener en cuenta los

estándares actualmente soportados por el mercado(dada la permanente la evolución del tema), las restricciones de aplicabilidad de estos estándares (tanto a nivel de recursos hardware como a nivel de recursos software) y se debería tener la posibilidad de hacer pruebas pilotos con productos que están en definición, para asegurar que un desarrollo a gran escala sea basado en productos maduros en el mercado y en sus implementaciones reales. Estos productos deben contener herramientas de monitoreo y administración adecuadas.

La siguiente figura resume las principales directrices o dimensiones en el desarrollo de una estrategia de Qo S para una organización.

Figura 47. Dimensiones de desarrollo de una estrategia de QoS

3.2.5. Las posibilidades de QoS Ya discutimos que la estrategia de “sobreaprovisionamiento”. como una solución de soporte de QoS, no es un planteamiento que siempre resuelva los problemas, una posibilidad de soporte de Qos es la tecnología ATM(ya discutimos previamente sus bondades con respecto al tema), pero en redes LAN, sus costos han impedido un desarrollo creciente, por tanto las posibilidades tecnologías están enfocados a los esfuerzos de Qos sobre el protocolo IP y dentro de estas, las estrategias posibles son las siguientes(capa 3):

• Label Switching(MPLS)

117

• Marcado de servicios(service marking)

• Marcado de prioridades (priority marking)

• Servicios Diferenciados(Diffserv)

• Servicios Integrados(Intserv y RSVP) Estas estrategias o combinaciones de ellas deben formar parte de los planes estratégicos de las organizaciones que consideren implementar QoS como elemento diferenciador y de soporte a sus necesidades especific as. La capa de enlace debería propagar la estrategia de QoS definida en la capa de red, independiente de la tecnología(ATM,frame relay, Ethernet), a este nivel surgen los mecanismos de prioridades definidos por el estándar 802.1.P y Q (vea sección 1.6.1.3 de este documento)y el protocolo SBM como administrador de ancho de banda(que directamente mapea RSVP a nivel de enlace, en la sección 1.5.3 de este documento se discute el protocolo). Adicionalmente es importante mencionar las bondades de la tecnología Gibabit Ethernet que proporcionan un respaldo a las estrategias de QoS(Esta tecnología surge como un alternativa dominante en la capa de enlace de redes LAN) Según el estudio realizado por la empresa International Network Services, a inicios del año 2001 , los siguiente protocolos debían ser implementados en el año siguiente por las empresas que hicieron parte del estudio, este dato constituye una referencia interesante sobre las decisiones que están tomando las empresas respecto a QoS y revela básicamente, que estas estrategias están muy relacionadas y han tenido aceptaciones similares dentro de las organizaciones, lo que explica la tendencia de que estos protocolos no solo se aplican individualmente sino de una manera complementaria que permite generar la solución requerida por las organizaciones. De los enunciados en el grafico, el protocolo COPS (Common Open Policy) no ha sido mencionado en este documento; este protocolo establece las políticas de administración de Qos, de tal forma que las tareas de configuración de mecanismos de QoS, no necesitan realizar dispositivo a dispositivo sino a través de una estrategia centralizada. Este protocolo permite que los dispositivos intercambien estos mensajes a fin de generar mecanismos sencillos que le faciliten la labor de implementación de políticas de QoS al administrador de la red. Las empresas deberían planear la implementación, de por lo menos, las siguientes técnicas especificas dentro de su infraestructura de red:

• control de tasa de trasmisión y conformación de trafico a nivel de TCP • el algoritmo PQ(encolamiento por prioridades, priority queuing)

• el algoritmo WFQ(Weighted Fair Queueing)

• el algoritmo de encolamiento basado en clases (Class-based quening)

118

3,1

2,9

2,9

2,8

2,8

2,8

0 5

SN

MP

RSVP-

Contr

olle

d load

serv

ice

Calificacion en la escala de 1-5 de la necesidad de implementar el protocolo

Figura 48. Implementación de una tecnología de QoS

Todas estas técnicas se detallaron en la sección 1.4. En el campo especifico de las aplicaciones, estas deben tener la capacidad de señalizar una determinada QoS requerida (para el caso del protocolo RSVP, deben poder señalizar un requerimiento RSVP).Estas necesidades deben ser comunicadas a la infraestructura de red vía una API y a través del soporte que permita el sistema operativo. Los sistemas operativos de Microsoft(los mas populares) ya soportan estas posibilidades desde las versiones de Windows 98 y Windows 200, lo mismo la mayoría de versiones UNIX(para el tema especifico de RSVP, aplica igual). Las aplicaciones que utilizan estas características están en pleno desarrollo y el área que mayores implementaciones ha generado es la telefonía IP. Existen diversos ejemplos comerciales disponibles desde hace aproximadamente 2 años de aplicaciones que soportan QoS(y RSVP específicamente) en redes LAN. Netmeeting es un ejemplo de este tipo de aplicaciones, junto con el soporte de Telefonía TAPI(Versión 3.0) para Windows o el núcleo del software SAP/R3. En sistemas UNIX existen también diversos ejemplos como por ejemplo VIC-RSVP(Herramienta de videoconferencia con RSVP, implementada sobre un plataforma Solaris 2.5.1). Es de anotar que el desarrollo de aplicaciones que señalicen Qos(o RSVP) debería ser la última fase dentro de una estrategia de QoS que una organización plantee(igualmente nuestro estudio esta enfocado principalmente en la infraestructura de red y no en el software de aplicación). En los últimos años diversas universidades y empresas han enfocado sus esfuerzos en las pruebas e implementación de los protocolos de señalización de reservas(estilo RSVP) en ambientes intranet, con aplicaciones especificas de audio y video. Estos

119

resultados se traducirán en un tiempo corto, en los estándares que finalmente deben ser la base de las decisiones que adopten las empresas. 3.2.6. Características de una solución de QoS En esta sección se resumen las principales características que definen una solución robusta de QoS, a la luz de estos factores, se deben evaluar las diferentes estrategias tecnológicas: 3.2.6.1. Forzamiento de políticas de QoS punto a punto La calidad de servicio debe aplicarse punto a punto, por lo tanto debe ser independiente de la plataforma, dispositivos y medios empleados; como este mecanismo opera en la capa 3, debe asegurarse la funcionalidad punto a punto, a través de múltiples dispositivos de red ( tales como enrutadores, switches, firewalls, servidores de acceso, gateways) y capas de enlace(por ejemplo: ATM,Frame Relay o Ethernet). Cisco, por ejemplo, ofrece estos mecanismos o herramientas, que interoperan para establecer Qos desde el core hasta las orillas de la red(como nuestro estudio esta limitado a redes LAN, es mas fácil cumplir con esta característica). 3.2.6.2. Múltiples parámetros Los dispositivos deben tener la flexibilidad para aplicar y garantizar calidad de servicio basada en múltiples parámetros que deben reflejar las políticas definidas por los administradores de red. Estos parámetros distinguen flujos de tráfico basada en las direcciones IP, direcciones MAC, aplicación, usuario, hora del día o localización dentro de la red. Los administradores definen las políticas usando combinaciones de estos parámetros. Un ejemplo de una política sofisticada diría: “ Se debe permitir trafico de videoconferencia dentro de un segmento especifico de la red LAN, todos los lunes entre las 3 y 5 de la tarde para los usuarios A,B,C y D solamente. En cualquier otro momento y parra los demás usuarios el trafico de videoconferencia no esta permitido”. Los dispositivos deben tener la inteligencia para reconocer las aplicaciones y aplicar QoS a fin de lograr las políticas definidas por la empresa. Estos dispositivos incluyen los enrutadores(dispositivos de la capa 3, como por ejemplo enrutadores cisco); los dispositivos de capas 2/3 como los switches(con capacidades de enrutamiento); por ejemplos los switches cisco series 8500 o catalyst 5500. 3.2.6.3. Clasificación Los administradores necesitan que la red tenga la habilidad para determinar niveles diferentes de Qos para clases de trafico específicos. En general existen dos técnicas de clasificación ya ampliamente descritas en este documento: Servicios Diferenciados (Diffserv) o Servicios Integrados(Intserv).

120

3.2.6.4. Control Centralizado Esta característica se refiere a que el cumplimiento de las politicas de Qos sean controladas de forma centralizada(en un único punto o puntos definidos por el administrador de red), de tal forma que se asegure los requerimientos para las aplicaciones de misión critica y para las demás aplicaciones. Muchos desarrolladores de software, defienden la habilidad de que una aplicación señale su prioridad de QoS a través de la red; de tal forma que las aplicaciones son las responsables de ajustarse o no a las políticas de Qos definidas por la organización; sin embargo este tipo de control “basado en la confianza en las aplicaciones” puede ser que atente contra las políticas generales de Qos de la organización, porque la aplicaciones no tienen la perspectiva total de como la red debe operar y cuales son las prioridades definidas en el negocio. Muchas redes implementan combinaciones de estos modelos, pero la estrategia ganadora esta del lado del “control centralizado”, igual las aplicaciones deben siempre exponer sus requerimientos y señalizarlos, pero el control se realiza de forma centralizada. 3.2.6.5. Herramientas de administración QoS Puesto que existen diversos elementos de red y se requieren muchos parámetros para desarrollar e implementar exitosamente una política de QoS punto a punto, el conjunto asociado de herramientas Qos son muy complejos por naturaleza. Estas herramientas deben ser correctamente configuradas para que se puedan construir las redes inteligentes que las organizaciones necesitan. Las herramientas que soporten estas configuraciones masivas de dispositivos son de gran utilidad para los administradores de red. 3.2.7. Áreas de aplicación Una estrategia de QoS esta soportada como lo enunciamos en la sección 3.2.4 por distintas áreas presentes en la experiencia que finalmente percibe el usuario de la red y de la aplicación. Identificaremos en esta sección las áreas de aplicación tanto para Qos, como específicamente para el protocolo RSVP. Para la estrategia de Qos las áreas donde se traduce mayormente el impacto de una estrategia serian las siguientes(obviamente la sinergia entre estas áreas es evidente):

• Servidores: En esta área especifica, los elementos que mayor influencia tienen son el sistema operativo(que debe soportar QoS) y las técnicas de buffer que este implemente, especialmente en el caso de aplicaciones de secuencias de video. Esta área especifica no se detalla a profundidad dentro de nuestro estudio. Para el caso de video sobre demanda u otro tipo de aplicaciones, el hardware y las características del servidor imponen restricciones adicionales de espacio, capacidad de procesamiento y demás, aunque estas aplicaciones son mas en ambientes abiertos como Internet.

121

• Estaciones: Como en el caso anterior los clientes deben tener la capacidad en sus sistemas operacionales de soportar Qos y dependiendo la aplicación especifica requerirá elementos adicionales en términos de hardware, software o procesamiento.

• Red: Esta área constituye nuestro tema de estudio principal. En la red es muy

importante el soporte de Qos en cada una de las capas del modelo y por ende en los dispositivos que las soportan. A su vez dentro de cada capa existen distintas herramientas; nuestro interés esta centrado particularmente en redes IP, permitiendo el soporte de Qos no solo a nivel de red(routers), sino adicionalmente a nivel de subred(capa de enlace).

• Aplicaciones: Las aplicaciones de clientes y servidores deben tener la

capacidad de interactuar con las API de los sistemas operativos a fin de indicar sus requerimientos específicos de QoS.

• Seguridad: las políticas de seguridad son muy importantes para poder identificar los usuarios y aplicaciones que son capaces de alterar o definir las prioridades de Qos identificadas por la organización. Un estudio a profundidad de esta característica esta fuera del alcance de este documento, puesto que los estándares aun no definen claramente el tema.

• Administración, Mantenimiento y Escalabilidad: Estas áreas son sensibles al tipo

de solución de Qos elegido; los planes que aseguren facilidad en la administración y mantenimiento de las políticas de Qos, deberían estar contemplados dentro de la estrategia seleccionada por la organización. Adicionalmente la solución planteada, debe permitir escalabilidad con el numero de aplicaciones que requieran el soporte de QoS.

Cada una de estas áreas, se examina según las dimensiones definidas en la figura 45 y estas áreas definen los frentes de trabajo en que debe enfocarse la organización La guía debe recordar que la implementación, esta relacionada con todos las áreas presentes en la estrategia de Qos, pero el objeto de estudio principal es la red y no los servidores o equipos clientes. Particularmente para el caso de implementación de RSVP, las áreas de estudio son las mismas que se definen para la estrategia de QoS. La siguiente figura resume las áreas sensibles a la implementación del protocolo RSVP.

122

Figura 49. Areas de implementación

3.2.8. Las variables o factores Nuestro objetivo es implementar una estrategia de Qos, basado en la definición de las variables que consideramos mas importantes a la hora de seleccionar una opción de implementación(y particularmente en el desarrollo de RSVP). Estas variables deben ser cuantificadas en lo posible o definidos muy claramente los factores que las conforman. Estas variables impactan el desarrollo de uno o varias áreas de las definidas en el apartado anterior. A continuación enunciamos las variables que consideramos se deben evaluar en la implementación de una estrategia de QoS: 3.2.8.1. Tipos de aplicaciones y usuarios Una de las variables mas importantes que determina la dirección de la estrategia de calidad de servicio, son las aplicaciones actuales y las futuras que estén definidas dentro del plan estratégico de la organización. Si bien como lo mencionamos en la sección 3.2.2 las empresas están particularmente interesadas en el soporte de priorizacion para las aplicaciones de datos de misión críticas; la telefonía IP y otro tipo de aplicaciones multimedia emergentes influyen positivamente en la implementación de QoS. Se deben listar las aplicaciones actuales y las requeridas y establecer las prioridades de estas dentro de la infraestructura de red, basadas en las políticas de la organización. Las prioridades también pueden requerir definir reglas para determinado tipo de usuario de una misma aplicación.

123

Estas aplicaciones determinan el tipo de trafico que finalmente se genera y que impactara la red. 3.2.8.2. Tipos de trafico Las aplicaciones generan trafico, que tendrá una características especificas de acuerdo a la naturaleza de la aplicación y que finalmente debe definir los factores determinantes a nivel de QoS(ancho de banda, retardo, througput, etc; finalmente la calidad de servicio es expresada por medio de parámetros que se negocian, las necesidades dependen del tipo de aplicación y pueden variar durante la transmisión). por ejemplo el primer requerimiento para cualquier trafico de tiempo real es que todos los niveles que conforman la arquitectura de la red deben garantizar unas prestaciones mínimas y deterministas(caso imposible de hacer en la capa de enlace Ethernet, a no ser de que se actualice, para soportar prioridades y reserva de ancho de banda). La calidad de servicio vendrá determinada por el punto de vista que se tome. Desde el punto de vista del emisor o receptor los requerimientos están relacionados casi exclusivamente con el tiempo de entrega de los paquetes de información(retraso), la tasa de perdida de información y el ancho de banda. Otros puntos de vista pueden ser la eficiencia en el uso de la red, la tasa de errores o retransmisiones. El trafico se puede dividir en distintas categorías, bien en función de la tolerancia a los parámetros indicados o bien por los requerimientos de los parámetros(Braden,Clark&Shenker,1994). En la figura 50(Hernández, 2001,cap. 1, p. 6) el trafico se clasifica en el producto cartesiano :(sensibilidad al retraso)X(sensibilidad a la perdida). Como se ve, el grado en que las prestaciones de una aplicación dependen de este retraso varía ampliamente y las podemos catalogar en aplicaciones de tiempo real y aplicaciones elásticas.

Figura 50. Tipos de tráfico en función de la sensibilidad al retraso o perdida

124

3.2.8.2.1. Aplicaciones de tiempo real Una clase importante de estas aplicaciones son las de reproducción. La fuente coge una señal, la convierte en paquetes y los transmite por la red. El retardo introducido por la red, debe ser tratado en el receptor; por tanto la aplicación necesita saber a priori, el máximo retraso que los paquetes pueden experimentar. Este retraso determina la latencia de la aplicación o bien puede hacer que la fidelidad decaiga (por que no se reciben a tiempo los paquetes y la aplicación retrasa su ejecución o bien simplemente porque se descartan paquetes y se generan señales incompletas). Dentro de este tipo de aplicaciones podemos distinguir 2 clases: aplicaciones intolerantes, que no se pueden adaptar a que un paquete se retrase más del limite predeterminado, estas requieren un servicio garantizado o determinista. El otro tipo son aplicaciones adaptivas, que pueden tolerar que lleguen paquetes con un mayor retraso, requieren un modelo de servicio denominado servicio predictivo o estadístico, que proporciona un servicio bastante fiable pero no seguro. Para proporcionar un limite en el retraso, el trafico debe ser caracterizado y la red tiene que ejercer un control de admisión sobre nuevos tráficos que asegure que una petición de flujo puede ser tratada con la calidad de servicio requerida. 3.2.8.2.2. Aplicaciones elásticas Estas aplicaciones esperan a que los datos lleguen; no se requiere ninguna caracterización del servicio para que puedan funcionar. Ejemplos de este tipo de aplicaciones son FTP, terminales(telnet,x-windows),etc. Estas aplicaciones no están sujetas a control de admisión, y suelen estar basadas en el modelo de servicio “best-effort”. Cabe anotar en este momento, que el interés es particularmente RSVP y el trafico multimedia. 3.2.8.3. Tipos de comunicación Las aplicaciones, al igual que en el caso anterior definen el tipo de comunicación , que en este caso pueden ser comunicaciones unicast, broadcast o multicast. Este tipo de comunicaciones plantea requerimientos específicos en términos de red y de aplicación; para el caso de IP, el protocolo IGMP se encarga de la administración de grupos de receptores o emisores; esta habilidad es muy importante en aplicaciones como videoconferencias, audiostreaming etc. 3.2.8.4. Inventario de la base instalada Identificar plenamente los recursos hardware y software presentes en la infraestructura de red actual de la empresa, ayuda a dimensionar adecuadamente el esfuerzo posterior requerido para la implementación de una estrategia de QoS. El inventario debe comprender por lo menos los siguientes elementos:

• Dispositivos de red: Se deben identificar cada uno de los dispositivos presentes en la infraestructura de red(enrutadores, switches, gateways, servidores de acceso, etc), se deben registrar sus marcas, modelos, capacidades, sistemas operativos y funcionalidades soportadas, protocolos,

125

interfaces y direcciones IP. Es necesario identificar el tipo de topología empleado, la estrategia de segmentación, las subredes definidas, las políticas de administración y mantenimiento de este tipo de dispositivos. Se debería poder obtener mapas detallados o generales dependiendo de la complejidad del modelo de red.

• Enlaces: Se debe determinar los enlaces existentes, propios o de terceros, las

características de ancho de banda, distancias, etc. Se debe ilustrar el tipo de tecnología o protocolos usados en estos enlaces

• Herramientas de administración: Es necesario identificar y conocer a detalle

las herramientas de administración y soporte usadas por los administradores de red, sus capacidades de monitoreo y administración remota, las políticas de backup, las estrategias de recuperación ante las fallas de dispositivos, el software empleado para configuración de dispositivos, resolución de nombres, asignación de direcciones IP.

• Clientes y Servidores: Se debe conocer la características hardware y software

de los recursos computacionales de la organización, estas características deben comprender sus capacidades en disco, memoria, procesamiento, los sistemas operativos y versiones(capacidades especificas de QoS) y las características de interfaces o tarjetas de red. Se deben identificar los sistemas operativos de red empleado por la organización y las funcionalidades de red que ofrecen en términos de: resolución de nombres, dominios, DHCP,SNMP,IGMP, politicas de acceso y seguridad, soporte de QoS, etc

3.2.8.5. Grado de utilización de la red Se debe identificar en horas pico y en horas promedio, el porcentaje de utilización de los enlaces actuales(en términos de ancho de banda). Para ello se debe caracterizar y conocer las tasas de trafico generadas por las aplicaciones presentes en la empresa y como el trafico de estas aplicaciones se mezcla en los distintos puntos de la red. Es necesario establecer áreas o segmentos críticos o representativos, donde se pueda hacer este estudio, apoyado en alguna herramienta de monitoreo de red que facilite esta labor. También es importante identificar el porcentaje de utilización de recursos en dispositivos como enrutadores, switches, etc. Esta variable, permitirá definir la estrategia que mejor soporte las necesidades actuales y futuras de la organización y su posible impacto en términos de ancho de banda y de recursos en los enlaces y dispositivos. 3.2.8.6. Parámetros de calidad de servicio Esta variable debe identificar los parámetros más importantes de calidad de servicio por aplicación(para las aplicaciones que lo requieren y en el orden de prioridad definido previamente). Se deben establecer los valores requeridos por aplicación y los acuerdos de niveles de servicio al respecto(SLA: Service Level Agreement). Los principales parámetros son:

• Retardo o latencia

126

• Jitter

• Perdida de paquetes

• ancho de banda(throughput) 3.2.8.7. Modelos de calidad de servicio Esta variable pretende que se defina el modelo de calidad de servicio o las combinaciones de modelos de calidad de servicio requeridas dentro de la estrategia de Qos planteada por la organización: Los modelos como lo hemos discutido en la sección 1.7 pueden ser los siguientes:

• “Sobreaprovisionamiento de la red” • Modelo “Best-effort”

• Modelo de servicios diferenciados “Diffserv”

• Modelo de servicios integrados(“Intserv”, normalmente RSVP se asocia a este

modelo) y variaciones o mejoras al modelo como agregación RSVP(RSVP aggregation)

• Estrategia planteada por MPLS

Es importante tener mente abierta a las nuevas estrategias que surgen , a las mejoras continuamente planteadas en cada modelo y a las soluciones que plantean la integración de estos modelos. Por ejemplo el modelo intserv-diffserv parece ser una estrategia ganadora punto a punto o la utilización de MPLS y diffserv de manera integrada o al hecho de emplear RSVP como protocolo de señalización para MPLS. Todas estas combinaciones deben observarse a la luz de los productos disponibles en el mercado(y su madurez), los estándares que soporten y a la acogida en general dentro de las organizaciones. 3.2.8.8. Mecanismos de calidad de servicio Esta variable hace relación a las técnicas especificas que permiten implementar QoS en los dispositivos de la infraestructura de red y de las distintas funcionalidades que se deben considerar(cada una implica una decisión particular sobre el mecanismo que se debe elegir).

• Administración de la congestión: Estas herramientas usan los algoritmos de encolamiento para ordenar el trafico y determinar un método de prioridades para enviar el trafico en los enlaces salientes. Cada algoritmo ha sido diseñado para resolver un problema especifico de tráfico y tiene un efecto particular sobre el desempeño de la red; las técnicas son: FIFO, Priority Queuing(PQ), Custom Queuing(CQ), Weighted Fair Queueing(WFQ).

127

• Prevención de la congestión: Estas técnicas proactivamente monitorean la carga generada por el trafico de red, en un esfuerzo por anticipar y evitar la congestión en puntos comúnmente considerados cuellos de botella. Algunas tecnicas son: Available Bit Rate (ABR), Weighted Random Early Detection(WRED)

• Especificación y conformación del tráfico: Estas herramientas administran

el tráfico y la congestión entre dominios que tienen políticas distintas de QoS, donde existen diferentes disponibilidades de ancho de banda. Ejemplos de estas herramientas incluyen: Generic Traffic Shaping(GTS), Frame Relay Traffic Shaping(FRTS), Commited Access Rate(CAR).

• Eficiencia del enlace: Estos mecanismos trabajan en conjunto con las

técnicas de encolamiento y conformación del trafico para mejorar el nivel de servicio a las aplicaciones en términos de eficiencia y comportamiento predictivo. Ejemplos: Compresión del encabezado del protocolo RTP(RTP-HC: Real Time Protocol Header Compression), Detección de actividad de voz (VAD: Voice Activity Detection), Voice/Data Compression( Compresión de voz y datos).

• Señalización QoS: La señalización como lo hemos estudiado, juega un papel

especial en la configuración de QoS punto a punto, especialmente para el modelo de servicios garantizados. La señalización debe hacerse a nivel de capa 3(IP) y debe ser independiente del medio. Las herramientas de señalización a nivel de capa 3, incluyen: RSVP(nuestro objeto de estudio) y precedencia IP(IP Precedence). La señalización de Qos de la capa 3 se debe mapear con los esquemas apropiados de señalización de la capa de enlace, por ejemplo: 802.1p sobre Ethernet y el protocolo SBM, Cell Loss priority(CLP), Minimum Cell Rate(MCR), Peak Cell Rate(PCR) sobre ATM; Discard Eligibility(DE), Forward Explicit Congestion Notification(FECN), Backward Explicit Congestion Notification(BECN), Commited Information Rate(CIR), Excess Information Rate(EIR) sobre Frame Relay.

• Planeadores(Schedulers) para servicios garantizados: ejemplos:

Weighted Round Robin(WRR), Rate Scheduling.

• Control de políticas de QoS: Estas características proporcionan clasificación de paquetes , el cual selecciona los paquetes apropiados de acuerdo a sus necesidades de QoS. Algunos ejemplos son: Enrutamiento basado en políticas(PBR: Policy-based Routing), Reconocimiento de aplicaciones basado en la red(NBAR:Network-based Application Recognition), listas de control de acceso(Access Control Lists).

Actualmente existen herramientas que sobreponen una capa adicional para facilidad de administración de las politicas de QoS, como es el caso de la solución: CiscoAssure Policy Networking, que dinámicamente permite establecer y configurar las políticas de Qos sobre todos los dispositivos de la red, ahorrando el trabajo de configuración manual por cada dispositivo, garantizando la coherencia de las políticas y minimizando la posibilidad de errores; este solución incluye naturalmente la definición de un “servidor de políticas de QoS”.

Cada técnica debe evaluarse en función de por lo menos los siguiente factores:

128

• sobrecarga de recursos que genera • madurez de los productos presentes en el mercado

• escalabilidad de la solución

• valor agregado de sus funcionalidades

• costos

• restricciones inherentes

• las facilidades de administración y configuración y

• las posibilidades de interacción con otras técnicas

3.2.8.9. Productos Esta variable hacen relación al listado de productos disponibles en el mercado, que soportan los mecanismos de QoS planteados en la variable anterior; se debe analizar la madurez de los productos y su grado de aceptación dentro de las organizaciones. Debe revisarse y probarse la funcionalidad de los productos de acuerdo al soporte de estándares internacionales, sus características y restricciones puntuales. 3.2.8.10. Costos Esta variable esta relacionada con los costos inherentes a la instalación, mantenimiento y administración de una estrategia de QoS. La cuantificación de esta variable es una labor difícil, puesto que se debe analizar uno a uno los items que impactan económicamente a la organización a fin de tener un presupuesto completamente detallado del tema. Se deben calcular los costos de la capacitación de los administradores de red; los costos de actualización o compra de nueva tecnología de red, los costos de herramientas de administración adicionales y los costos relacionados con las modificaciones a nivel de aplicación o sistema operativo requerida para clientes y servidores. Adicionalmente deben estar contemplados los costos de asesoráis en las fases de planeación y diseño de la estrategia de QoS, mas aun si la compañía no cuenta con el suficiente conocimiento. 3.2.8.11. Proveedores de servicios y Tecnología Esta variable muy importante, porque son los proveedores quienes pueden dar aportes valiosos sobre la implementación correcta de QoS, ellos conocen los productos y sus limitaciones, están al tanto de las nuevas versiones y de los estándares y preferiblemente deben demostrar la madurez y aceptación de las soluciones tecnológicas que plantean. Para dispositivos de red las marcas mundialmente conocidas deben ser parte del portafolio del proveedor: Cisco, 3COM, Bay Networks, Nortel,etc.

129

3.2.8.12. Recurso Humano Esta variable esta relacionado con las capacidades del recurso humano al interior de la organización, sus conocimientos y habilidades sobre el tema de calidad de servicio en redes. Esto define las estrategias de capacitación necesarias y las eventuales consultorías externas. El personal debe tener la capacidad de definir prioridades, instalar, configurar y mantener la estrategia de Qos definida por la organización. 3.2.8.13. Instalación y Mantenimiento El plan de instalación y el estudio de su posible impacto sobre el desempeño de la red, son variables que deben validarse plenamente al interior de la organización, por cada una de las áreas y usuarios afectados. El plan de instalación debe contener los prerrequisitos, los planes de contingencia, el check list de las tareas de configuración por cada uno de los nuevos o antiguos dispositivos y la documentación del procedimiento detallado de configuración(a nivel de comandos y demás), adicionalmente deben estar especificadas las actualizaciones o instalaciones de software requeridas en los dispositivos de red, con sus respectivos instructivos. También deben estar claros los roles de todos los participantes en el proceso de instalación y la asesoría externa que se requiera. Las políticas de mantenimiento y crecimiento deben estar definidas plenamente dentro de la estrategia de QoS, junto con las herramientas y la capacitación que se requiera para la operación de la solución planteada.

3.2.8.14. Servicios de soporte Esta variable contempla los servicios de soporte requeridos en la implementación de QoS, estos servicios normalmente están relacionadas con las siguientes funcionalidades :

• Administración de políticas (policy management): Estas tareas deberían estar soportadas por herramientas que automaticen muchas de las tareas de configuración y mantenimiento a bajo nivel(Ejemplo de este tipo de herramientas es el software CisCoAssure). Con estas herramientas, los administradores de red podrían definir políticas a través de una interfaz gráfica y el sistema automáticamente se encargaría de realizar todas las tareas de implementación a nivel de “bits y bytes”. Este método incrementa sustancialmente la integridad de la red y reduce dramáticamente los tiempos requeridos para implementar y mantener la calidad de servicio(QoS) en la red. Este tipo de herramientas usan protocolos estándares de la industria como COPS(Common Open Policy Service) para comunicar las políticas de QoS a todos los dispositivos de la red.

• Autenticación: Es importante definir el esquema de autorización y autenticación, es decir que usuarios o aplicaciones están en capacidad de requerir determinados recursos de red, esto a fin de poder implementar controles que aseguren la correcta utilización de dichos recursos

130

• Accounting: Se deben proporcionar herramientas que puedan generar estadísticas y funciones contables sobre las operaciones de red.

3.3. RECOMENDACIONES PARA LA IMPLEMENTACION DE QOS Y RSVP 3.3.1. Esquema planteado Cualquier plan que pretenda implementar una estrategia de calidad de servicio debería partir de un esquema incremental que iría desde la red hasta los ámbitos de la aplicación del usuario(por cada una de las áreas definidas previamente). Es decir a nivel general los grados de evolución de la estrategia de Qos implican los siguientes estados(según lo estudiado en la sección 1.10):

Figura 51. Evolución de una estrategia de QoS

Estos grados de evolución permiten refinar la estrategia general de QoS de la compañía, en las recomendaciones que planteamos se pretende cubrir por lo menos los 2 primero grados de evolución, el ultimo grado no esta dentro del alcance de las recomendaciones de este documento. El desarrollo de una estrategia de Qos es una tarea bastante compleja , debe partir de un análisis a profundidad de lo que realmente se requiere al definir una política de calidad de servicio y cual es el costo/beneficio de la implementación. Actualmente para muchas organizaciones el principal temor esta relacionado con los retos desde el punto de vista tecnológico y la ausencia de ejemplos reales de implementación oscurece aun mas el panorama; por tanto, el esquema que se deba plantear debe ser incremental, con posibilidades de experimentación de las diferentes alternativas técnicas, mas aun cuando la estrategia puede variar dependiendo del tipo de aplicaciones que se pretendan desarrollar o priorizar y normalmente las mejores soluciones involucran combinaciones de diversas tecnologías. Fuera del plano técnico, la estrategia tiene asociado unos costos particulares de instalación y mantenimiento y unos efectos claros sobre la base instalada y en general sobre la organización; es vital definir inicialmente lo que se requiere y tener en claro el norte definido por el plan estratégico de la organización.

La compañía debe examinar y evaluar todas sus aplicaciones presentes y futuras

consignadas en su plan estratégico, debe determinar cuales son más importante y configurar sus switches y enrutadores para reconocer y dar prioridad a ciertas

aplicaciones( previa evaluación de las opciones tecnológicas disponibles); esta tarea se repite por cada uno de los dispositivos de red; el próximo paso es permitir que las

aplicaciones señalen su necesidad particular de QoS, una vez el soporte en la red esta totalmente garantizado.

131

Las fases principales que se deben tener en cuenta, en la implementación del protocolo de señalización RSVP y mas aun dentro de una estrategia de calidad de servicio se resumen en:

Figura 52. Fases de una estrategia de QoS

Estas fases deben ser evaluadas teniendo como soporte las áreas, dimensiones y variables previamente definidas dentro del estudio de requerimientos. En general la evolución de la estrategia debería corresponder a los siguientes pasos específicos:

• Conocer los planes de la organización con respecto a calidad de servicio en la red, a corto, mediano y largo plazo. El soporte de calidad de servicio debe apuntar al plan estratégico de la compañía.

• Identificar las áreas de la compañía y las aplicaciones donde el soporte de Qos

es un elemento diferenciador y clave para la operación.

• Identificar las capacidades actuales de la empresa en manejo de audio, datos ,video, transacciones criticas, equipos y recursos humanos, establecer prioridades en la utilización de este tipo de datos y en las aplicaciones. Recolección de estadísticas sobre los patrones de trafico a través de la red y los cuellos de botella.

• Inventario de la base instalada y establecer los requerimientos que se requieren

por aplicación para soportar Qos(software e infraestructura de red). No solo a nivel de dispositivos sino además a nivel de configuración

• Establecer los niveles de Qos que la red debe proporcionar y el tipo de usuarios

identificados.

• Definir y seleccionar los modelos de QoS que se adapten a las necesidades especificas de las aplicaciones(ver sección 3.2.8.7 de este documento).

132

• Seleccionar las herramientas(técnicas) de QoS a implementar para responder a un conjunto de requerimientos; identificar productos y estándares presentes en el mercado actual (ver sección 3.2.8.8. de este documento).

• Evaluar las técnicas a la luz de las restricciones, costos de implementación ,

facilidad de mantenimiento y administración, impacto sobre la infraestructura de red.

• Definir un esquema incremental de aplicación de las técnicas de QoS: soporte

en la capa de red y soporte a nivel de subred(Igual aplicaría para la implementación del protocolo RSVP). El soporte en la aplicación correspondería a un estado final según los grados de evolución definidos.

• Consideraciones finales, restricciones y características esperadas de la

estrategia de QoS.

• Planes de administración, mantenimiento y seguridad de la solución.

• Establecer el plan de trabajo sobre como las aplicaciones deben señalizar QoS.(ultimo grado de evolución de la estrategia)

Sin embargo, es muy importante tener en cuenta que una estrategia de QoS no debe

considerarse como un desarrollo en un momento particular, la naturaleza de las aplicaciones implica constantes cambios, la estrategia de calidad de servicio debería

ser por tanto como una caja de herramientas que constantemente deben evaluarse y ajustarse a las necesidades de la organización. La combinación de las herramientas

que debe utilizar no es una formula predefinida y depende de los patrones de trafico; aun usando herramientas distintas de QoS el resultado podría ser el mismo.

Es muy importante recordar que Qos proporciona herramientas para administrar mejor el ancho de banda, pero este es siempre el factor limitante al final. A continuación detallamos cada una de las fases que deben hacer parte de la estrategia de QoS. 3.3.2. Definición de requerimientos de Qos En esta fase, se deben definir específicamente los requerimientos de calidad de servicio en la red, estos requerimientos deben estar alineados con el plan estratégico de la empresa y de acuerdo al análisis de la base instalada que posee la organización(costos y equipos).

• El plan estratégico debe definir el modelo ideal para la organización en términos de los recursos de red y del tipo de aplicaciones que deben soportarse a corto, mediano y largo plazo.

• El análisis de la infraestructura actual de red permite definir que tanto se

puede soportar el modelo ideal planteado en el plan estratégico de la organización con la base instalada actual de la empresa. La necesidad de lograr el modelo ideal implica que la infraestructura de red deba revisarse en términos de migración, actualización o implementación de nuevas tecnologías,

133

es importante conocer la inversión realizada en el modelo actual de la organización tanto en termino de equipos como en términos de aplicaciones, servicios y recursos humanos y esta inversión inicial debe protegerse en términos de la estrategia de Qos que se plantee. El inventario de la base instalada, también hace referencia a las aplicaciones y los patrones de trafico actuales generados por estas, por tanto, la recolección y determinación exacta de esta información en términos estadísticos permite inferir la realidad de utilización de los recursos de red y estimar como el modelo actual escalaría ante nuevas aplicaciones consignadas en el plan estratégico.

Esta comparación entre plan estratégico y base instalada permite definir los requerimientos generales de la estrategia de Qos que la organización requiere. Estos requerimiento deben ser lo mas concretos y específicos posibles en términos de aplicaciones a soportar y políticas de administración de recursos en cada una de las áreas(red, aplicación, servidores, etc).

Figura 53. Definición de requerimientos en una estrategia de QoS

Una estrategia de calidad de servicio debe ser ante todo incremental y continuada, un conjunto de aplicaciones especificas puede definir puntualmente un plan de implementación, el inventario general permitirá definir como responder a esas necesidades especificas, pero el análisis de una nueva aplicación o un nuevo requerimiento implica nuevamente un análisis de la infraestructura actual. Es por ello muy importante discriminar lo que se quiere a corto plazo, mediano y largo plazo, esto define la mejor estrategia a corto plazo que pueda escalar fácilmente con la proyección a largo plazo de la compañía. Usualmente se deberían empezar con pruebas pilotos en ambiente pequeños y controlados e ir incrementando el grado de complejidad y alcance de la estrategia. Este proceso iterativo de refinación del modelo de servicios se ilustra en la figura 54. Para el caso especifico de desarrollo del protocolo RSVP, este hace parte de las técnicas de Qos y una vez definidas los requerimientos y estudiados los diferentes planes de implementación, se seleccionan las técnicas de calidad de servicio, dentro de estas técnicas una de las herramientas a seleccionar es el uso de un protocolo de señalización de calidad de servicio como RSVP.

134

Figura 54. Definición de requerimientos en una estrategia de QoS

Las tareas principales que se deben realizar en esta fase son:

• Identificar las expectativas y antecedentes de la organización relacionadas con la implementación de una estrategia de calidad de servicio.

• Estudio de planes pilotos en otras organizaciones y ejemplos de productos y

estándares.

• Definición de un plan estratégico de calidad de servicio, con objetivos a corto, mediano y largo plazo.

• Identificar los potenciales, recursos y restricciones de la organización. Estudio

de la base instalada.

• Identificar y clasificar las aplicaciones actuales y requeridas por el plan estratégico.

• Identificar los usuarios de las aplicaciones y de las estrategias de QoS.

• Establecer los requerimientos generales de una estrategia de calidad de servicio

a corto, mediano y largo plazo.

• Definición de escenarios de aplicación de estos requerimientos, es decir segmentar los requerimientos de acuerdo a aplicaciones puntuales y ejemplos específicos que requieran de soporte de calidad de servicio: Un escenario, es por ejemplo soportar mecanismos de priorización de trafico, otro escenario es la implementación de Voz sobre IP en algunos partes de la red LAN. Estos escenarios en su conjunto definen toda la estrategia de calidad de servicio, pero la implementación de esta estrategia debe ser incremental, escalable y basada en escenarios.

La siguiente figura resume las tareas que se deben realizar en esta fase.

135

Figura 55. Tareas dentro de la fase de requerimientos

A continuación detallamos cada una de estas tareas. 3.3.2.1. Expectativas y antecedentes de QoS Se deben examinar cada una de las expectativas relacionadas con las estrategias de calidad de servicio en la organización; estas expectativas deben observarse en función de la factibilidad y los productor comerciales disponibles y aceptados en el mercado. Normalmente las expectativas están relacionadas con las redes de convergencia, aplicaciones multimedia y particularmente en definir esquemas para priorizar las aplicaciones de misión critica, es decir, que estas tengan anchos de banda garantizados. Dependiendo de la naturaleza de las organizaciones, sus expectativas estarán enfocadas de forma diferente, pero la mayoría de empresas buscan soportar adecuadamente las aplicaciones que son la base de su negocio y experimentar con aplicaciones como voz sobre IP, videoconferencias o todo lo que le represente un factor diferenciador o genere un valor agregado en el mercado. Ver la sección 3.2.2 que muestra los beneficios que espera una organización de una estrategia de QoS.

136

Los antecedentes con respecto a las técnicas utilizadas para provisión de calidad de servicio, proporcionan un punto de partida importante para definir el nuevo plan de implementación, es muy importante analizar los resultados de estas experiencias y sobre todo el conocimiento adquirido por el recurso humano, esto facilitara las posteriores tareas de selección e implementación. 3.3.2.2. Planes pilotos, ejemplos de productos y estándares Para poder definir un plan estratégico acorde a la realidad de la organización y al grado de desarrollo tecnológico del entorno, es muy importante revisar los planes pilotos de implementación realizados por empresas de características similares, los productos y estándares seleccionados, las técnicas y metodologías y sobre todos los resultados obtenidos. Esto evitara sobredimensionar las expectativas o proponer soluciones basadas en productos inmaduros, cuya factibilidad no esta del todo garantizada. Para el caso especifico de implementación de un protocolo de señalización de QoS, en el contexto nacional no existen claros ejemplos de desarrollo, lo que implica que se deben revisar los casos de estudio de empresas multinacionales y las características de las soluciones empleadas y si estas soluciones tienen el respaldo y conocimiento de los proveedores locales. 3.3.2.3. Plan estratégico de calidad de servicio El plan estratégico de la organización debe estar basado en la definición de sus aplicaciones prioritarias y las expectativas de implementación de nuevas aplicaciones multimedia o de tiempo real, es decir los casos de telefonía IP, videoconferencia, audiostreaming, etc (redes de convergencia). Otro elemento importante en la definición del plan estratégico, es la necesidad de tener un mejor control y uso eficiente de los recursos de red. Las aplicaciones deben ser priorizadas de acuerdo a los objetivos estratégicos de la organización; estas prioridades impactaran directamente las técnicas de Qos que se deban implementar. El plan define un modelo o modelos de servicios deseados(ver seccion 3.2.8.7 sobre modelos de calidad de servicio), con objetivos claros a corto, mediano y largo plazo. Estos modelos pueden combinarse para generar soluciones puntuales que apoyen algún objetivos especifico.

Figura 56. Tareas dentro de la fase de requerimientos

137

La figura anterior resume los insumos requeridos y los beneficios esperados por la definición de un plan estratégico de calidad de servicio, enfocado principalmente sobre las aplicaciones que hacen o harán uso de la infraestructura de red. 3.3.2.4. Inventario de la base instalada Esta variable ya fue estudiada en la sección 3.2.8.4 de este capitulo, es importante aclarar que en esta parte se debe definir además la variable de “Grado de utilización de la red” (estudiada en la sección 3.2.8.5), que hace referencia a obtener mediante métodos estadísticos los patrones de trafico actuales que puedan servir para determinar el posible impacto de las técnicas de calidad de servicio en los dispositivos de red utilizados por la organización. Existen herramientas que permiten hacer este tipo de recolección de información de forma automática, con un impacto mínimo sobre el desempeño de la red (por ejemplo, para el caso de dispositivos Cisco, esta recolección de datos se realiza a través de los servicios Netflow de los enrutadores serie 7500). El inventario de la base instalada debe realizarse como lo mencionamos en cada una de las áreas de impacto de la estrategia, es decir, red, subred, aplicación, cliente y servidor. La revisión de la base instalada permite generar un listado preliminar de las características actualmente no soportadas en la infraestructura de red, por cada una de las áreas. Esto permitirá que en la fase de análisis se consideren las estrategias de migración, instalación o actualización de tecnologías y dispositivos. Para el levantamiento de este tipo de información, dependiendo de las herramientas con las que cuente la empresa, se requiere mayor o menor esfuerzo, dado que existen utilidades que me permitan mostrar los mapas particulares y detallados de todos los dispositivos y enlaces presentes en la red local. Aun en el caso de que dichas herramientas no existan se deben tener los detalles de dispositivos, enlaces, técnicas soportadas por los dispositivos, configuraciones y mapas de redes generales o detallados. Como dato adicional en cada dispositivo o enlace debería reportarse el “grado de utilización de sus recursos” en horas pico o en horas promedio. Dentro de este inventario están también las aplicaciones actuales, la naturaleza del trafico generado y los recursos de red requeridos por cada una de ellas. Dentro del inventario de la infraestructura de red, se debe tener en cuenta si los dispositivos de red y las aplicaciones soportan señalización RSVP, en el evento de que no exista tal soporte, debe considerarse las implicaciones relacionadas con actualizaciones software y hardware requeridas para implementar el protocolo primero a nivel de red, luego a nivel de subred y en un grado a final, a nivel de clientes, sistemas operativos y aplicaciones(obviamente esto aplic a si se decide tener una estrategia de señalización de Qos con RSVP, que debe ser parte del análisis de las posibles alternativas de calidad de servicio que se deben hacer en la fase siguiente)

138

Figura 57. Definición de la base instalada dentro de la organización

3.3.2.5. Identificación de usuarios y aplicaciones Las aplicaciones(actuales y futuras) definidas dentro del plan estratégico de calidad de servicio deben caracterizarse en función de sus requerimientos, estas aplicaciones se detallan y se definen prioridades de acuerdo a los objetivos a corto , mediano y largo plazo definidos en el plan. También deben identificarse Los usuarios de estas aplicaciones , su ubicación geográfica y si se tienen requerimientos específicos para algunos de ellos. En general es importante definir los niveles de servicios requeridos por aplicación(best-effort, controlled-load, guaranteed). Un nivel de detalle mayor sobre las aplicaciones se elabora en la siguiente fase de análisis. Para el caso especifico de RSVP se debe mencionar si dentro de los requerimientos de las aplicaciones se necesita un protocolo de reserva de recursos en la red y si las aplicaciones deben señalizar sus requerimientos de QoS, usando este protocolo. Pero esta decisión debe hacerse posteriormente como resultado del análisis de las alternativas de QoS, en la fase siguiente del estudio. Sin embargo es importante reiterar que no esta dentro del alcance de las recomendaciones de esta tesis la posibilidad de que las aplicaciones señalicen QoS a través de RSVP, esto es un estado final, una vez implementado el protocolo totalmente en la red. 3.3.2.6. Definición de requerimientos de la estrategia de QoS Una vez definido el plan estratégico y evaluada la base instalada de la organización, se deben especificar detalladamente los requerimientos de calidad de servicio planteados

139

por la organización a corto mediano y largo plazo. Estos requerimientos implican por lo menos los siguientes elementos:

• Listado de aplicaciones actuales y futuras que la red debe soportar y prioridades de estas aplicaciones.

• Restricciones de las aplicaciones a implementar en términos de recursos de red:

Las aplicaciones deben estar clasificadas y definidos el tipo de trafico que se deben generar en horas pico y promedio.

• Características actuales de la infraestructura de red y mecanismos de calidad de

servicio a implementar. Se deben especificar las técnicas requeridas para: reserva de recursos, políticas de Qos, señalización de QoS, administración de la congestión, etc y demás herramientas de Qos. Estas herramientas en lo posible deben listarse asociada a cada tipo de aplicación. No se detalla la herramienta especifica pero si lo que se requiere como habilidad de la red o de los nodos de la red.

• Necesidades especific as de los usuarios de red. Se deben identificar las clases

de usuarios que la estrategia de QoS debe soportar y sus necesidades puntuales.

• Identificar las áreas especificas de la red o los segmentos que requerirán

tratamiento especiales (por constituir eventuales cuellos de botella).

• Lista de restricciones asociadas a cada aplicación y servicios adicionales requeridos para su funcionamiento, por ejemplo para el caso de voz sobre IP la necesidad de soportar H.323 y los gateways o nuevos dispositivos requeridos. Es decir, detallar productos y servicios adicionales que la red debe ofrecer po aplicación.

• Necesidades de control de recursos de red y eficiencia de recursos de red:

Deberá definirse el tipo de herramientas requeridas para controlar los recursos de red disponibles a fin de fijar prioridades y normas.

• Herramientas de administración de red y de políticas de QoS requeridas.

Para el caso especifico del protocolo RSVP se deben listar los nodos, servidores, aplicaciones y zonas de la red que deben soportar el protocolo y su posible impacto sobre los recursos que se requieren en cada uno de ellos, se deben identificar plenamente la sobrecarga que generará el protocolo y las restricciones inherentes. 3.3.2.7. Definición e escenarios de aplicación de la estrategia de QoS Los requerimientos definen una serie de aplicaciones a implementar dentro del marco del plan estratégico de calidad de servicio de la organización, estos requerimientos deben ser evaluados de una manera incremental, es decir primero los requerimientos a corto plazo, luego los de mediano plazo y luego los de largo plazo. A su vez los requerimientos de corto plazo, hacen relación a una serie de aplicaciones, en este caso el plan se debe definir para un conjunto pequeño de requerimientos, que para nuestro caso llamaremos “escenario de aplicación”, esto permite definir una

140

estrategia de calidad de servicio que sea escalable e incremental y reducir la complejidad de implementar el soporte de Qos a todo nivel de la infraestructura de red; si bien este es el objetivo final, la división por “escenarios” permite tener unidades de implementación más fácilmente administrables en términos de sus restricciones y sus impactos tecnológicos y organizacionales. Una estrategia de calidad de servicio debe partir de lo pequeño, aumentando de forma escalable su cobertura y permitiendo la implementación inicial de planes pilotos en dominios restringidos, que se pueden controlar mas fácilmente(escenarios de aplicación). Por tanto en esta tarea se definen los casos puntuales de calidad de servicio que serán objeto inicial de estudio; ejemplo: “definir un mecanismo para dar prioridades a las aplicaciones de misión critica sobre las demás aplicaciones”; este requerimiento constituye lo que llamamos un “escenario de aplicación”. En la figura 56 se ilustra como un objetivo especifico dentro de los requerimientos constituye un “escenario de aplicación” y la unidad mas pequeña dentro de la estrategia de calidad de servicio que la organización deba implementar. Esta unidad define una aplicación o implementación que requiere el soporte de calidad de servicio en la red. Si un escenario de aplicación fuera por ejemplo “Voz sobre IP”, este escenario podría requerir la implementación de un método de señalización QoS, tal como RSVP. Es decir el protocolo seria una herramienta que se podría usar o no, en cada uno de los eventuales escenarios de aplicación, definidos dentro del plan estratégico de Qos de la empresa.

Figura 58. Un objetivo especifico define un “escenario de aplicación”

Esta fase debe permitir, que la empresa realmente evalué si requiere una estrategia de calidad de servicio o si por el contrario considera que debe permanecer con el modelo de sobre-aprovisionamiento la red, es decir continuar simplemente agregando ancho de banda en su infraestructura de red. Debe haber listado sus aplicaciones actuales y futuras, haber establecido sus prioridades y estar segura del valor agregado que generara implementar calidad de servicio en su red. Las redes de convergencia de voz, datos y video, con nuevas aplicaciones para los usuarios, serán el objetivo que

141

debe estar plenamente identificado en un plan estratégico a largo plazo; la empresa debe examinar si realmente eso es lo que desea o si un modelo menos “complejo” es suficiente para sus necesidades.

En general un administrador de red en este caso debería realizarse por lo menos las siguientes preguntas básicas.

• Hace falta implementar una estrategia de Qos? • Cuanto tiempo se puede convivir sin una estrategia de Qos? • Cuales son las expectativas de crecimiento de la infraestructura de red, hacia

donde enfocar los esfuerzos? • Que modelo de servicios requiere la organización? • Cuales son las aplicaciones criticas y como la red actual brinda soporte a estas

aplicaciones? • Nuestras aplicaciones y herramientas de red cubren nuestras necesidades? • Integrar voz, datos y video? • Añadir simplemente ancho de banda? • Necesitaremos un método de señalización de QoS, como RSVP?

3.3.3. Análisis de los requerimientos de Qos, diseño y modelación Una vez definidos claramente los objetivos de la estrategia de calidad de servicio que debe soportar la organización y establecidos los requerimientos y escenarios, las aplicaciones especificas que se deben soportar ,los tipos de usuario y las restricciones, se entra a la fase de análisis de estos requerimientos. Esta fase debe generar las distintas estrategias posibles que aseguren la implementación de QoS, cada estrategia debe evaluarse en términos de sus implicaciones técnicas, calidad, cobertura, costos e impacto sobre la infraestructura actual . En esta fase se detalla específicamente cada aplicación en función de los parámetros y variables de QoS, las áreas de impacto (ver la sección 3.2.8 sobre las variables presentes en una estrategia de calidad de servicio y la sección 3.2.7 que detalla las áreas donde Qos es aplicable), la naturaleza de la aplicación, el tipo de trafico que genera y el tipo de datos que debe manejar.

Figura 59. La fase de análisis en una estrategia de calidad de servicio

142

Para el estudio de las implicaciones técnicas de cada alternativa propuesta puede ser de gran ayuda el uso de patrones de trafico y herramientas de análisis de trafico(existentes en el mercado) que permitan identificar las áreas que requieren cambios a nivel de QoS para optimizar el desempeño de la red. Estas herramientas de modelación son una guía para probar los efectos de los cambios en las configuraciones en las áreas de la red que se consideran criticas. Estas herramientas predicen los cambios en el desempeño, basados en modelos de simulación, sin que se requiera implementar el cambio directamente sobre la red, es decir son ideales para las pruebas del tipo “que pasa, si”, es decir como reacciona la red ante las modificaciones planteadas por las técnicas de calidad de servicio. Para el caso de la implementación del protocolo RSVP es determinante analizar el overhead que este puede llegar a generar a nivel de los recursos de red. Dentro de las tecnologías de calidad de servicio elegibles como soluciones a las preguntas planteadas en el plan estratégico de la organización se pueden tomar cualquiera de las opciones planteadas en la sección 3.2.5(las posibilidades de QoS), o una combinación de esta clase de tecnologías, dependiendo del grado de maduración de los productos en el mercado, los costos, las implicaciones, las restricciones y el grado de conocimiento de los administradores de red. El uso del protocolo de reserva de recursos RSVP, es una variable mas a analizar dentro de la estrategia general de calidad de servicio, la empresa bien podría optar por otro esquema diferente de señalización. En muchos casos se requerirá la asistencia de empresas consultoras externas, que conocen mucho mas a detalle los productos y sus posibilidades. En esta fase de análisis es muy importante dimensionar cada aplicación en función de las principales variables definidas en la sección 3.2.8, esto permitirá dar claridad sobre el tipo de solución planteada y que cumpla con los factores o variables mencionados Las principales tareas que deben realizarse en esta etapa son las siguientes

• Caracterizar las aplicaciones en cuanto al tipo de información que manejan, el grado de utilización de la red, grado de seguridad, tipo de comunicación, tipo de trafico que demandan y demás variables o factores definidos

• Definir las alternativas de Qos con uso o sin uso de RSVP para las aplicaciones

detectadas, comenzando desde el punto de vista del usuario de la red. Basado puntualmente en las tecnologías, productos , modelo de servicios y mecanismos de QoS(estos últimos se referenciaron en la sección 3.2.8.7 y 3.2.8.8 de este documento)

• Detallar la calidad de servicio que generara cada una de las posibles

estrategias y realizar una matriz comparativa de pros y contras en términos de red y de aplicación(aunque nuestro interés particular aquí es básicamente la red)

• Estudio de viabilidad y costos por cada una de las estrategias que se planteen.

143

3.3.3.1. Caracterización de las aplicaciones Las aplicaciones definidas en un escenario particular, que respondan a un conjunto de requerimientos específicos, se deben caracterizar en función de cada uno de las variables identificadas en la sección 3.2.8 , lo que implica detallar el tipo de datos que se va a generar , el tipo de trafico que demandan , el grado de seguridad que requieren , el tipo de comunicación, el grado de utilización de los recursos de red. en definitiva se debe detallar la calidad de servicio que espera cada aplicación y su impacto sobre cada una de las áreas(Red, Aplicaciones, Clientes, Servidores). La siguiente tabla resume los principales elementos a considerar en la caracterización de cada una de las aplicaciones:

Tabla 15. Caracterización de las aplicaciones

Aplicación 1: nombre de la aplicación

• Tipo de datos manejado: Voz y sonido, video, texto, imágenes estáticas, etc

• Grado de seguridad: Permisos y usuarios autorizados en la aplicación. Ubicación geográfica de los usuarios

• Grado de utilización de recursos de red: • ancho de banda requerido, calculado en horas pico y horas promedio.

Numero máximo de usuarios concurrentes • Usuarios especiales de la aplicación • Prioridad de la aplicación: definida previamente en la fase de

requerimientos • Tipo de trafico: tiempo real adaptivo, tiempo real intolerante, elásticas • Tipos de comunicación: unicast, multicast • Infraestructura de red que soporta hoy la aplicación: clientes, enlaces,

dispositivos de red, tipos-de-tecnología, servidores. • Parámetros de calidad de servicio: retardo o latencia, jitter, perdida de

paquetes, ancho de banda4 • Modelo de calidad de servicio requerido: Best-effort, Diffserv, Intserv,

MPLS, combinación de estos modelos. • Mecanismos de calidad de servicio requerido: en lo posible se debe

detallar cuales técnicas se requieran; administración de la congestión, prevención de la congestión, especificación y conformación del tráfico, eficiencia del enlace, señalización QoS, planeadores, control de políticas de QoS,etc.

• Funcionalidades a soportar: es decir la capacidad de la aplicación de manejo de buffers, o de señalización de una determinada calidad de servicio.

• Restricciones propias de la aplicación: servicios adicionales requeridos5

4 Se debe establecer cuantitativamente el ancho de banda, jitter, retardo, tiempos de respuesta exigidos, demoras máximas de transmisión permitidas y modos de transmisión por aplicación o sesión. 5 Aplicaciones de Voz sobre IP, deberían ser compatibles con H.323, ejecutarse en sistemas operativos windows y tener capacidad multicast.

144

El calculo de ancho de banda requerido se puede llevar a cabo a través de medidas de aplicaciones o situaciones semejantes, a través de la simulación o de modelos matemáticos. Esta recopilación de información es un tarea muy importante dentro del estudio y requiere grandes esfuerzos, ya que permite posteriormente definir de acuerdo a estas características las posibles alternativas de calidad de servicio. 3.3.3.2. Definición de alternativas de QoS En esta parte se debe trabajar en la definición de las alternativas de calidad de servicio, es decir se debe analizar los productos disponibles en el mercado que soporten las necesidades que la empresa requiere y detallar en términos de cada uno de los mecanismos de calidad de servicio , lo que cada alternativa puede ofrecer. De acuerdo a los modelos de servicio posibles se puede plantear una o varias alternativas que contemplen estos modelos o la integración de estos(Intserv, Diffserv, MPLS o integración de estos). Las estrategias generadas deben plantear la división de tareas que se debe realizar en los dispositivos de orilla y en los dispositivos del core o backbone y por cada clase dispositivo se debe examinar el tipo de herramientas o tecnologías que se deben soportar. En resumen cada estrategia posible debe listar por lo menos los siguientes elementos:

• Técnicas de Qos soportadas por los dispositivos del core a nivel de red. • Técnicas de Qos soportadas por los dispositivos de la orilla a nivel de red.

• Integración de tecnologías de backbone y de dispositivos de orilla.

• Técnicas de Qos soportadas a nivel de subred.

• Interfaces entre las estrategias de calidad de servicio de la capa 2 y de la capa

3

• Interfaces de las técnicas a aplicar y las tecnologías actuales de la empresa.

• Dispositivos, servicios o herramientas adicionales requeridas para la aplicación de la estrategia

• Necesidades en las aplicaciones(no están contempladas en este estudio)

La siguiente figura resume las técnicas de Qos, que se deben analizar en cada una de las estrategias planteadas tanto para los dispositivos del “core“ como los dispositivos de la orilla.

145

Figura 60. Técnicas presentes en una estrategia de QoS

Existen diversas herramientas que pueden apoyar el análisis de los efectos de las diferentes estrategias en la infraestructura de red, es decir, permiten definir escenarios del tipo “que pasa, si”, para analizar el impacto de una estrategia y los posibles cambios de configuración. Dentro de estas herramientas se encuentra el producto “CiscoAssure Policy Networking” que contiene una familia de herramientas software que permiten la administración centralizada de políticas de QoS, ingeniería de trafico y servicios Netflow para análisis de desempeño. Estas herramientas permiten realizar pruebas sin necesidad de implementar una política en particular. En el caso de la implementación del protocolo de RSVP, es importante determinar los requerimientos particulares de los dispositivos(core y de orilla) para soporte del protocolo y eventualmente los requerimientos en términos de aplicación. Se debe elaborar un resumen tabular que contenga todas las estrategias propuestas, sus métodos particulares de calidad de servicio, los requerimientos e interfaces requeridas con las tecnologías actuales , la calidad de servicio que puede ofrecer, los productos y estándares presentes en el mercado, los servicios adicionales que se requieren, el soporte por parte de consultores externos, etc.

Tabla 16. Consideraciones sobre la estrategia de QoS

Estrategia 1: Ejemplo de consideraciones

• Técnicas de Qos a implementar:(en todos los dispositivos) a nivel de red • Técnicas a implementar a nivel de subred • Impacto de las técnicas sobre la base instalada: migración, actualización o

convivencia de tecnologías. Definición de interfaces con tecnología del legado(impacto en la áreas definidas en 3.2.7)

• Modelo de servicio o modelo de servicios soportados. Nivel de calidad de servicio soportada por la solución

• Productos presentes en el mercado y ejemplos de implementación • Dispositivos adicionales y servicios requeridos en la red • Interfaces entre las técnicas de las capas 2 y 3 • Soporte de la estrategia a necesidades de crecimiento o escalabilidad • Sobrecarga de recursos de red generada por la estrategia • Restricciones de la solución a nivel de infraestructura de red

146

• Tipo de soporte y funciones de administración requeridas • Conocimiento necesario en el recurso humano para la implementación de la

estrategia • Necesidades de sobreaprovisionamiento o de ancho de banda adicional(es decir

si la solución plantea cambios o nuevos enlaces en términos de infraestructura de red)

• Redes de alta velocidad: es decir la estrategia puede considerar el sobreabastecimiento de la red, con tecnologías como por ejemplo ATM, Gigabit Ethernet y como estas tecnologías deben soportar las técnicas de QoS.

• Beneficios o valor agregado de la estrategia • Necesidades de consultoría externa o servicios externos como carriers • Plan de instalación o configuración • Cambios requeridos a nivel de aplicación o de clientes y servidores • Cobertura de la estrategia propuesta

3.3.3.3. Estudio de viabilidad y costos por estrategia Una vez definida cada una de las estrategias que se deben plantear y resumidas sus características principales se debe analizar la viabilidad y los costos que posiblemente generara cada una de las soluciones planteadas. El estudio de factibilidad de la estrategia debe evaluarse en función de los siguientes factores(algunos de ellos son tratados en el documento “Guía de redes multimedia”, Luis Carlos Díaz Ch.):

• A nivel de las alternativas tecnológicas emergentes ofrecidas en el mercado actual y de la maduración de estos productos.

• A nivel de la infraestructura de red requerida para soportar la

solución(hardware y software)

• A nivel de la facilidad de administración y capacidad de crecimiento(solución escalable)

• A nivel financiero de acuerdo a los costos que acarrea la estrategia(los costos

se detallan a continuación)

• A nivel de la calidad esperada por las aplicaciones(que tan viable son determinados niveles de servicio)

Los costos son un tema bastante importante dentro de la estrategia de calidad de servicio planteada por la organización, particularmente porque este tema es fundamental para que la empresa tome las decisiones correctas. Es importante anticiparse a las características nuevas que pueden exigir los usuarios ,a fin de poder planificar acertadamente los costos. Los costos deben ser lo mas detallado posibles en términos de infraestructura, recurso humano, consultoría externa, tiempos de implementación, mantenimiento y soporte de la solución una vez configurada. No se pueden generar estimativos demasiado tempranos de los costos , que puedan llegar a subestimar los reales costos de implementación de la estrategia. Los costos pueden ser costos fijos de desarrollo de la

147

red(implementación inicial), costos variables, costos de servicios a terceros(entiéndase consultorías o carriers). Es muy importante que dentro de la estructura de costos, este plenamente identificada los costos de mantenimiento y operación de la solución planteada. No estimar adecuadamente los costos puede implicar que el plan de implementación de la estrategia de calidad de servicio, falle. Los costos se deben estudiar una vez se tengan definidos y totalmente claros los alcances, restricciones e impactos de una estrategia específica. 3.3.4. Desarrollo de la estrategia de Qos Una vez discutidas las diferentes estrategias de calidad de servicio, en términos de sus características, costos y factibilidad, en esta etapa se busca definir las características finales de la solución que se debe plantear, que puede ser un resultado de la selección de una estrategia especifica o la combinación de estas, posteriormente se deben definir las pautas para el diseño, implantación e instalación de la estrategia y los planes de mantenimiento, seguridad y escalabilidad de la estrategia ganadora. la siguiente figura resume las tareas que se deben considerar en esta ultima etapa, partiendo del estudio de las estrategias propuestas en la fase anterior.

Figura 61. Desarrollo de la estrategia de calidad de servicio

Este proceso se debe repetir para cada uno de los “escenarios de aplicación” definidos y la estrategia final de calidad de servicio es la suma de la estrategias seleccionadas por cada “escenario de aplicación”; es decir la estrategia prosigue incrementalmente partiendo de los requerimientos a corto plazo, pero con la visión de lo que se desea a mediano y largo plazo. Este proceso se ilustra en la siguiente figura:

148

Figura 62. Definición de un plan de QoS

3.3.4.1. Selección de la estrategia y características de la solución

La decisión de escoger cualquiera de las alternativas o la combinación de cualquiera de ellas depende tanto de la calidad de servicio, de los costos asociados y de la factibilidad técnica del desarrollo de la estrategia.

Figura 63. Selección de la estrategia de calidad de servicio

Se deben consolidar las alternativas, no generar modelos generales sino un modelo particular, fraccionar para poder dimensionar adecuadamente la estrategia que aplique a un requerimiento especifico. Se deben plantear combinaciones de técnicas de Qos, interfaces distintas, subredes de comunicación distintas , dispositivos de diversos fabricantes, técnicas de señalización distintos, técnicas de soporte de Qos a nivel de subred, set de protocolos distintos que se adapten a los requerimientos iniciales, después de este análisis se debe finalmente decidir la estrategia a implementar(en esta etapa es importante, nuevamente el soporte que se pueda tener de modelos o herramientas de simulación que permitan evaluar las combinaciones de las alternativas). Las estrategias también se pueden combinar para que unas apliquen en determinadas zonas o regiones de la red, con la idea presente de aprovechar al máximo la actual capacidad instalada, es decir pensar en la necesidad de que puedan convivir las antiguas y nuevas tecnologías. En general en una estrategia de calidad de servicio, la división de tareas de los dispositivos se haría de la siguiente manera:

149

• Los dispositivos de la orilla de la red administrarían las actividades requeridas

para monitorear, reconocer y clasificar el tráfico.

• Los dispositivos de “core”(centro de la red) son optimizados en su desempeño para reenviar el trafico de alta prioridad sin congestión o retardo.

Por tanto los dispositivos de la orilla(o borde) de la red son responsables por:

• Control de admisión: permitir o denegar el trafico de las aplicaciones.

• Clasificación: Fijar un nivel de prioridad(alto, medio, bajo).

• Señalización(Proxy signaling): Señala precedencia IP/diffserv o requerimientos RSVP de ancho de banda a través de la ruta de entrega.

• Policing: verifica que se use solamente el ancho de banda asignado

• Especificación del trafico(traffic shaping): reaccionar ante la congestión.

• NBAR:permitir que la red tenga la habilidad de reconocer aplicaciones.

Los dispositivos del centro(core) de la red son responsables por:

• Planeación(Scheduling)

• Prevención de la congestión

• Propagación de la señalización QoS 3.3.4.2. Pautas de diseño, instalación e implantación En esta sección presentamos una serie de elementos, principios y criterios a considerar en la implementación de la estrategia de calidad de servicio seleccionada. En general se debe proponer un modelo de red que incorpore la estrategia seleccionada y los requerimientos solicitados, este modelo estará basado en toda la información recopilada en las fases anteriores; el modelo debió evaluarse en la fase anterior con diferentes combinaciones de subredes y tecnologías a utilizar y ajustado a las consideraciones de costos, calidad de servicio , elementos técnicos y objetivos del plan estratégico. Esta estrategia o modelo seleccionado debe ser aprobado por la organización y por los usuarios de la red, Es muy importante mantener claridad sobre la definición de los “escenarios de aplicación”, dado que es imposible generar un modelo completo de QoS cuando las dimensiones de la red son grandes, por ello es importante tener en cuenta la naturaleza incremental de la solución propuesta en este documento. Los “escenarios de aplicación” sirven para simplificar la complejidad del modelo general de la red y de la estrategia de QoS.

150

Los siguiente criterios y elementos deben ser tenidos en cuenta en la implementación del modelo de red seleccionado. 3.3.4.2.1. Segmentación Es posible que se requieran, dependiendo del tipo de aplicación y de los grupos de usuario, estrategias de segmentación de la red, a fin favorecer la aplicación de la estrategia de calidad de servicio seleccionada. La segmentación debe ir orientada a separar el trafico generado por aplicaciones criticas o aplicaciones de tiempo real intolerantes(que requieren un servicio garantizado) al trafico de otro tipo de aplicaciones, este tipo de estrategias debe ser escalable con el numero de aplicaciones que se requiera separar o clasificar. 3.3.4.2.2. Aplicaciones adaptivas El modelo de red seleccionado debe evitar las demoras innecesarias en las comunicaciones, estas demoras están asociadas bien al ensamble de paquetes de datos, a la transmisión misma de estos paquetes(que se supone esta garantizado con la estrategia particular seleccionada de calidad de servicio) y a su presentación. Es muy importante recordar que nuestras recomendaciones han estado enfocadas principalmente en la red y no en las aplicaciones, en general, estas deberían tener la capacidad de señalizar un nivel requerido de QoS y la habilidad de manejo de bufferes y sincronización de los datos recibidos desde la red. Estas habilidades permiten que las aplicaciones pueden de alguna manera adaptarse a ciertos retardos de red(El estudio de las características de estas aplicaciones esta fuera del alcance del este documento). Este punto impacta la definición de las características de los servidores y clientes de la red. 3.3.4.2.3. Consultoría externa y servicios de terceros Cuando se utilizan servicios de terceros (típicamente los enlaces de larga distancia), se debe tener en cuenta el efecto de esto sobre la estrategia general de calidad de servicio, son importantes los temas de acuerdos de niveles de servicio(SLA) y soporte, localización, cobertura y costos, así como en general su impacto sobre las áreas y variables de la estrategia seleccionada. Es importante que el esquema de Qos de la organización este íntimamente relacionado con lo que el carrier puede proveer, esto en determinadas circunstancias puede garantizar el éxito o el fracaso de la estrategia.

En general deberíamos responder a las siguientes preguntas:

• Se requiere del uso de carriers ?

• Que efectos tiene los servicios de terceros sobre la estrategia de Qos de la

organización?

• El carrier tiene definida una estrategia de Qos, alineada con mis objetivos y estrategias?

• Que tipo de canales o enlaces pueden ofrecer, es suficiente?

151

• Cual es el costo y disponibilidad de estos servicios?

• Que alternativas existen al uso de carriers?

Ahora bien, para la definición de los proveedores de equipos y de servicios(consultoría externa), es importante evaluar por lo menos las siguientes condiciones:

• Información técnica y financiera de la organización

• Capacidades técnicas de integración de tecnologías, experiencia y calificación en el tema, desarrollos anteriores de implementación de estrategias de Qos en escenarios similares(muy importante dado la inmadurez de los productos y estándares)

• Programas de aseguramiento de calidad

• Manejo de estándares y productos reconocidos a nivel mundial • Estrategia de transferencia de conocimiento hacia la organización, es decir,

como el recurso humano interno quedara capacitado.

• Documentación técnica y referencias • Programas de mantenimiento y respaldo a los productos y soluciones ofrecidas

• Servicio al cliente

Si la empresa requiere una consultoría externa referente al tema de calidad de servicio es muy importante asegurar la suficiente experiencia técnica del consultor y sus conocimientos de los estándares y productos actuales, dado que este factor será clave en las fases de planeación, análisis y diseño de la estrategia; mas aun cuando los productos están en constantes cambios y mejoras. Así mismo debe estar garantizada la estrategia de transferencia de conocimiento al interior de la empresa

La empresa debe definir claramente cuales serán los criterios para seleccionar un proveedor o una propuesta, basado principalmente en su experiencia en el tema de implementación de estrategias de calidad de servicio, 3.3.4.2.4. Alternativas hardware y de redes Básicamente la estrategia seleccionada define un conjunto de tecnologías y protocolos a aplicar tanto en los dispositivos de orilla con el dispositivos del centro de la red, en la medida de los posible estas estrategias deben considerar la convivencia con la base instalada de la organización y la forma de mapearse con los protocolos actuales. Las alternativas de redes de alta velocidad específicamente para redes LAN, deben evaluarse como estrategias de sobreabastecimiento de la red, que deben ser consideradas dentro de la estrategia general de calidad de servicio, por ello se deben estudiar las ventajas y desventajas de cada una de estas tecnologías y su fácil integración con las técnicas de Qos definidas en la estrategia.

152

Dentro de la estrategia planteada deben estar claras las características mínimas de los distintos equipos o dispositivos de red, esto permitirá evaluar fácilmente las propuestas presentadas por los proveedores, adicionalmente en la estrategia deben estar definidos los medios de transmisión(aunque particularmente para QoS, este tema se trata superficialmente, ya que QoS se implementa a nivel de la capa de red). En general deben estar claras las características, soporte de técnicas de QoS los proveedores, marcas de equipos, , configuración y soporte de dispositivos como:

• Concentradores • Repetidores • Enrutadores • Switches • Gateways

3.3.4.2.5. Adquisición, instalación y operación Se debe definir el plan de adquisición, instalación y operación de la estrategia planteada. Se deben estudiar las propuestas presentadas por los proveedores potenciales y realizar un análisis de las tareas definidas en el proceso de instalación. Debe estar claro para todo el equipo del proyecto los criterios de aceptación de propuestas, pruebas y confiabilidad de la estrategia presentada por el proveedor; de tal forma que se ajuste al plan de QoS definido y estudiado por la organización. En general la adquisición e instalación de la estrategia requiere un ejercicio detallado tanto de costos como de todos los elementos técnicos a considerar, es muy importante definir el plan de pruebas en conjunto con los consultores externos y los usuarios de la red . Deben estar discriminados y perfectamente detallados los documentos que soportan los procesos de configuración y puesta a punto de la solución, así como los posibles planes de contingencia. El personal de la empresa debe estar capacitado para realizar las labores de instalación y configuración de la solución planteada, previa transferencia de conocimiento. Se deben tener claros los riesgos en los procesos de instalación y operación de la solución y la forma como se pueden contrarrestar. 3.3.4.3. Planes de administración, seguridad y mantenimiento. Dentro de los servicios mas importantes requeridos al implementar una estrategia de calidad de servicio, esta la necesidad de contar con procedimientos de administración y mantenimiento adecuadamente definidos. La administración de políticas de calidad de servicio, debería estar soportada por alguna herramienta (Tipo CiscoAssure), que permitiera fácilmente realizar las tareas de configuración masiva de dispositivos. Este tipo de herramientas permite simular los cambios y una vez establecidos, los propaga automáticamente a cada uno de los dispositivos de red Dentro de los elementos que debemos considerar en un plan de administración y mantenimiento tenemos los siguientes:

153

• Herramientas de estadísticas de uso de la red y logs.

• Políticas de control de cambios.

• Administración de la configuración: componentes físicos y lógicos

• Procedimientos de monitoreo de la estrategia de calidad de servicio y

prevención de posibles cuellos de botella.

• Auditorias periódicas sobre las configuraciones y el esquema general de Qos

• Definición de un grupo de trabajo para las labores de administración y mantenimiento.

• Recomendaciones sobre tunning y dimensionamiento dentro de la estrategia de

calidad de servicio planteada.

• Procedimientos para las actualizaciones de software y/o hardware, definir en que momentos son requeridos.

• Pautas para la instalación, contratación y compra de equipos que soporten la

política de QoS.

• Escalabilidad de la estrategia: conocer la forma como la estrategia de QoS puede ampliar su cobertura o evolucionar, esto dado la naturaleza cambiante de los requerimientos de los usuarios.

La estrategia de calidad de servicio no es un desarrollo de un solo momento sino que debe estar en constante evaluación y evolución. La administración de Qos comprende las herramientas para fijar y evaluar las políticas de QoS, una metodología comúnmente usada comprende por lo menos los siguientes pasos:

• Determinar las características del trafico de la red. esto se puede realizar mediante el uso de pruebas o ensayos RMON. igualmente las aplicaciones deben ser evaluadas en términos de sus tiempos de respuesta

• Se desarrollan las técnicas de Qos definidas por la estrategia, cuando se han

obtenido las características del trafico y las aplicaciones “objetivo”(las que se definieron en el plan como aplicaciones prioritarias)

• Se evalúan los resultados por medio de pruebas del tiempo de respuesta de las

aplicaciones para examinar si los objetivos de QoS se han logrado. Como lo mencionamos, existen herramientas que pueden apoyar estas tareas, por ejemplo, para facilidad del desarrollo se puede usar el software “Cisco’s Quality of Service Policy Manager”(QPM) y “Quality Of Service Device Manager”(QDM). Para verificar los niveles de servicio se puede usar “Cisco’s Internetwork Perfomance Monitor”, esto son solo ejemplos de herramientas Cisco, pero existen otro tipo de herramientas de otros proveedores.

154

3.3.5. Desarrollo del protocolo RSVP. En esta sección discutiremos los elementos a tener en cuenta para la implementación del protocolo; RSVP es una técnica de señalización, o sea hace parte de las herramientas de QoS que la organización debe analizar y estudiar en su estrategia de calidad de servicio. En este apartado, asumimos que la empresa ha optado por implementar el protocolo dentro de su estrategia, para responder a algún requerimiento especifico. Esta sección pretende mostrar las fases a considerar dentro de la implementación del protocolo, estas fases se han definido basado en el estudio de las alternativas planteadas por empresas como Cisco, Nortel o 3COM: RSVP, al igual que la estrategia de calidad de servicio puede ser introducido por fases en la organización, esto permite que cada empresa realice su proceso de migración y soporte a su propio ritmo. Cada una de las 3 fases que se plantean en este apartado proporcionan mejoras incrementales, que extienden las capacidades de reserva dinámica de recursos desde los clientes o desktops6 pasando por enrutadores y eventualmente a través de switches de la capa 2. 3.3.5.1. RSVP en desktops, switches y enrutadores de la capa 3 Uno de los primeros elementos a considerar en una estrategia de desarrollo de RSVP, (aunque dependiendo de la aplicación especifica podría ser necesario o no y no siempre debería considerarse como la primera fase) es que el protocolo se instale en los sistemas finales(de tal forma que los clientes o desktops puedan hacer requerimientos de RSVP) y en los switches y enrutadores de la capa 3(de tal forma que estos dispositivos puedan responder a los requerimientos de los clientes). El soporte de software cliente/servidor para desktops lo proporcionan sistemas operativos como Windows NT, Windows 2000,Windows 98, Windows XP y diversas versiones de unix(como solaris) y linux. A nivel de switches y enrutadores existen diversos ejemplos comerciales de productos de familia Cisco, Bay Networks, Nortel, Santa Clara o 3Com(un ejemplo de esto es el switch CoreBuilder 3500). Finalmente los desarrolladores, necesitaran modificar sus aplicaciones de tal forma que ellas puedan informar al desktop, a través de una API del sistema operativo, sobre sus requerimientos específicos de recursos(ancho de banda). Para el caso de los sistemas operativos Windows esto se hace a través de la API winsock. La siguiente figura ilustra esta primera fase de desarrollo de RSVP en desktops, enrutadores y switches; se asume en este caso que las aplicaciones son capaces de señalizar RSVP y que se poseen todas las herramientas de administración en los servidores o clientes(desktops)

6 aunque como lo hemos mencionado no detallamos mucho el concepto de señalización de Qos desde las aplicaciones.

155

Figura 64. Instalación de RSVP en desktops y enrutadores de la capa 3

3.3.5.2. Soporte parcial en switches de la capa 2, usando priorización de

tráfico Uno de los cambios a implementarse en la primera fase de desarrollo de RSVP es que los switches de la capa 2, no soportan activamente el protocolo, lo que puede generar cuellos de botella imprevistos durante tiempos de congestión de la red. Durante la fase 2 se busca remediar este problema instalando switches que soportan 802.1p/Q a través de toda la ruta.

Figura 65. Switches 802.1p/Q que soportan RSVP por priorización de tráfico

La figura anterior ilustra la fase 2 de la estrategia de desarrollo de RSVP. En esta fase los sistemas finales etiquetan el paquete con una prioridad 802.1p (la cual mapea un nivel de servicio RSVP). Estos mapeos permiten que los switches de la capa 2 colaboren con RSVP implementando el reenvío de paquetes basado en prioridades a través de toda la infraestructura de la capa 2. El grupo de trabajo de IETF denominado “Integrated Services Over Specific Link Layers(ISSL)” desarrollo los mapeos entre las clases de servicios de RSVP y los valores de prioridad de 802.1p; así, por ejemplo, los flujos de voz interactivos podrían relacionarse con un valor de prioridad= 6 de 802.1p, mientas que los flujos de datos “best-effort”, podrían mapearse con un valor de proridad=0.

156

Esta capacidad esta presente en switches de diversos fabricantes desde el año 1999 aproximadamente. Soporte total en switches de la capa 2, usando SBM(Subnet Banwidth Manager) En la fase final, los switches de la capa 2 son participantes del proceso de reservación de ancho de banda. El protocolo SBM, es una extensión de RSVP que origina que los mensajes PATH y RESV visiten y actúen sobre los switches de la capa 2. De esta manera SBM, obliga que el control de admisión y las reservas de ancho de banda ocurran tanto en los switches de la capa 3 como en los switches de la capa 2. La siguiente figura ilustra este comportamiento.

Figura 66. RSVP y Subnet Bandwiidth Manager(SBM)

La implementación de SBM incrementa dramáticamente la complejidad de los switches de la capa 2, y su desarrollo es actualmente un área activa de investigación. Existen productos comerciales que soportan el protocolo desde el año 2001 aproximadamente En general para la implementación del protocolo RSVP es importante determinar los servicios que el protocolo puede ofrecer a futuro y los equipos que se deben seleccionar; así mismo se debe conocer la lista de aplicaciones software que soportan RSVP en clientes y servidores y que se requieren dentro de la estrategia de calidad de servicio seleccionada. Se deben examinar con detalle las estrategias de escalabilidad del protocolo, particularmente las mejoras que presentan los productos al respecto; un ejemplo de esto, es cisco y su familia de productos; en las nuevas versiones de su IOS presenta mejoras a los problemas de escalabilidad del protocolo.(Ver el documento RSVP Scalability Enhancements de Cisco IOS Release 12.2(2)T). En general, se debe seguir con atención la evolución de estos productos. Es importante que a partir de la experiencia y de las pruebas efectuadas con el protocolo, la organización gane confianza, para aplicarlo en ambientes similares.

157

3.3.6. Consideraciones sobre la implementación de RSVP Se debe hacer una planeación cuidadosa para configurar y usar exitosamente RSVP en la red ; como mínimo RSVP, debe reflejar su valoración de las necesidades de ancho de banda sobre las interfaces de los enrutadores. Se deben considerar los siguientes elementos en su plan de configuración de RSVP: Que tanto ancho de banda podría RSVP permitir a un flujo de una aplicación de usuario final? Se debe entender y conocer las necesidades particulares de cada aplicación. Por defecto la cantidad reservable para un único flujo puede ser la totalidad del ancho de banda reservable. Sin embargo, se puede limitar el tamaño de reservaciones individuales usando el parámetro de “ancho de banda del flujo”. El valor de ancho de banda reservado no puede exceder la cantidad reservable en la interface y ningún flujo puede reservar más de este valor.

• Que cantidad de ancho de banda esta disponible para RSVP? Por defecto , el 75 % del ancho de banda disponible sobre una interface es reservable.

• Que tanto ancho de banda se excluye de RSVP ?, de tal forma que se pueda

proporcionar los servicios requeridos para conversaciones de bajo volumen de datos. Los controles punto a punto, para el trafico de datos, asumen que todas las sesiones intentaran evitar la congestión dinámicamente.

RSVP no modela todos los tipos enlaces de datos presentes en la red. RSVP modela una interface como un sistema de encolamiento que determina completamente la mezcla de trafico sobre la interface; las características de ancho de banda o de retardos son determinísticas dentro de los límites planteados por el modelo. Desafortunadamente, los enlaces de datos son a menudo modelados imperfectamente por medio de esta estrategia; se debe usar las siguientes guías:

• Las interfaces de líneas seriales-PPP;HDLC;High-Speed Serial Interface son bien modeladas por RSVP. El dispositivo, puede, por tanto, hacer garantías sobre estas interfaces. Las interfaces NBMA(Nonbroadcast multiacces) casi siempre requieren reservaciones.

• Multiaccess LANs: Estos enlaces de datos no son bien modelados por las

interfaces RSVP , porque la LAN por si sola representa un sistema de encolamiento que no esta bajo el control del dispositivo que hace la garantía. El dispositivo garantiza la carga que generara pero no puede garantizar la carga generada por sus dispositivos vecinos. El administrador de red podría enfocarse en el uso de control de admisión en el diseño de la red, para usar RSVP de forma efectiva. SBM es una mejora a RSVP sobre redes LAN(como lo hemos discutido previamente). Un dispositivo sobre cada segmento se elige como el DSBM y este se encarga de administrar todas las reservaciones sobre el segmento; esto evita que múltiples dispositivos obtengan reservaciones y puedan exceder el ancho de banda compartido por la LAN. El DSBM puede informar a los servidores sobre que tanto trafico pueden enviar sin que pertenezca a reservaciones validas de RSVP.

• Redes públicas X.25: no es claro el soporte de reservaciones sobre redes

publicas X.25.

158

• En redes Frame Relay o ATM, se requiere para el soporte de RSVP, un tipo de configuración especial

3.4. EJEMPLO DE ESTUDIO: IMPLEMENTACION DE RSVP PARA VoIP

EN UN CENTRO DE VENTAS Y SERVICIOS DE BELLSOUTH COLOMBIA

En esta sección incluimos un ejemplo de implementación real del protocolo RSVP en un ambiente bastante sencillo, pero sirve para ilustrar algunos elementos adicionales y recomendaciones no cubiertas dentro de este estudio. Ahora bien, no se realizo un estudio exhaustivo de la estrategia de calidad de servicio para la organización, pero si se definió un “escenario de aplicación”, para algunos requerimientos planteados por la empresa. La empresa esta pensando en definir claramente su estrategia de calidad de servicio, pero su visión a corto plazo es las pruebas del protocolo en ambientes pequeños y controlados, que de alguna forma les ayuden a dimensionar como pueden usar el protocolo en otro tipo de aplicaciones; de todas formas esta claramente expresado el interés de la organización en una estrategia global de calidad de servicio, pero también sus temores por los riesgos de implementación, particularmente por la falta de conocimiento sobre el tema y la ausencia de productos y consultores externos que conozcan o hallan desarrollado soluciones practicas de QoS. A largo plazo la empresa piensa en una estrategia que les permita la total convergencia de sus redes de voz, datos y video(soporte de videoconferencias) y sus esfuerzos han estado centrados en escenarios o aplicaciones pequeñas que les permitan ganar confianza con el planteamiento de QoS, las soluciones o desarrollos actuales de la empresa están basados principalmente en el sobreaprovisionamiento de sus enlaces, de tal forma que “por ahora”, las necesidades de la organización parecieran cubiertas y los experimentos con calidad de servicio, bastante restringidos y controlados. Una preocupación de los administradores de red es la necesidad de definir esquemas que les permitan dar prioridades a las aplicaciones críticas del negocio, como ELITE(este es el software de facturación y gestión de clientes de la organización)o SAP. como resumen, el orden de prioridades inicialmente definido por la organización es el siguiente:

• Experimentos con el protocolo en una solución de VoIP para la organización a pequeña escala(este es nuestro ejemplo especifico)

• Experimentos del protocolo con una solución de VoIP para la organización, a

mediana y gran escala.

• Experimento de soluciones de videoconferencia sobre IP.

• Estrategias de priorizacion de aplicaciones de misión critica.

159

3.4.1. Requerimientos La necesidad inicialmente planteada, era la posibilidad de definir un esquema de reserva de recursos para una solución de VoIP, acá es importante aclarar que con respecto al tema de Voz sobre IP, la organización tenia suficientes adelantos en términos de los costos, productos y la manera de implementar la solución(no siendo esto nuestro objeto de estudio),pero evidenciaba sus necesidades de como establecer la reserva de recursos en los enlaces, para garantizar el ancho de banda y el retardo requerido por la solución. Nuestro “escenario de aplicación” esta restringido a un centro de ventas y servicios 7 ubicado en la ciudad de Cartago. La empresa actualmente posee sus redes de voz y datos separadas, pero la alternativa de Voz sobre IP, es mucho menos costosa que la anterior estrategia; particularmente para una ciudad de tamaño medio como Cartago, por ello la necesidad de experimentar un esquema de Voz sobre IP que aproveche mejor la infraestructura actual de la red de datos. El siguiente grafico muestra un ejemplo del esquema general de la red telefónica de la organización, de una región del país,(aumentar esta red a un sitio como Cartago, requiere costos bastante significativos). Esta red es totalmente aparte de la red de datos, los PBX se interconectan por enlaces dedicados E1s (cada E1 soporta 30 llamadas simultaneas). En la figura se muestra el esquema para la ciudad de Cali y la conexión de los CVS de Centenario, Emporio y Colón, de esa ciudad.

7 Un centro de ventas y servicios(CVS),es un lugar donde se realizan las operaciones principales de ventas y se atienden los servicios requeridos por los clientes de la compañía; es atendido por personal directo de la empresa y constituyen los puntos principales de operación de la empresa. Los CVS están unidos a nivel nacional por la red telefónica y de datos de la organización.

160

Figura 67. Fragmento red telefónica Bellsouth.(Ciudad de Cali)

3.4.2. Alternativas Para este caso particular la solución de VoIP tenia cierto grado de maduración y la empresa tenia definidos productos y esquemas a implementar. En la solución planteada no estaba la posibilidad de que las llamadas se generaran desde los PC. Se habían investigado los mecanismos a usar para reservar un determinado ancho de banda y se decidió el uso del protocolo RSVP, dado el soporte de este en los enrutadores cisco de la compañía y la confianza en estos productos. Particularmente no se investigo otro mecanismo de señalización como Precedencia IP, por requerirse en este caso, de un nivel de servicio garantizado. Básicamente las áreas de desarrollo de la estrategia estaban centradas específicamente en la red y en el soporte de VoIP en dispositivos como switches y enrutadores, el punto de vista de las aplicaciones no era un tema inicial de preocupación. El soporte en la subred del protocolo tampoco estaba cubierto en la estrategia inicial(particularmente porque los anchos de banda eran suficientes y garantizaban que no existieran problemas de congestión). La interface RSVP-ATM se planteo como una posibilidad a explorar dentro de la solución, sin que se convirtiera en un requerimiento específico. Las restricciones impuestas por la aplicación, son las relacionadas con VoIP, es decir: perdida de paquetes menor del 1%,retraso extremo a extremo menor que 150 ms,

161

ancho de banda de 64+16 kbps, lo que afianzaba la idea de un modelo de servicio garantizado( al estilo de los que puede proporcionar RSVP). Dentro de los mecanismos específicos de calidad de servicio, estaba el protocolo de señalización QoS que en este caso era RSVP y un mecanismo de cola como fair-queue(WFQ) que hacían parte integral de la solución planteada por los proveedores a la empresa. Los mecanismos específicos de RSVP, VoIP y fair-queue hacían parte del IOS de los switches y enrutadores ya estudiados por la organización(en términos de los productos puntuales ofrecidos por los proveedores) y que sustentaban la selección de la estrategia para Voz sobre IP. Realmente no existían muchas propuestas distintas a las planteadas por los proveedores de equipos cisco. 3.4.3. Esquema La figura 68 ilustra el esquema planteado y la solución puntual definida para VoIP y RSVP. RSVP básicamente se declara a nivel de las interfaces de los dispositivos y debe estar soportado en la IOS de los enrutadores y switches . En Cisco IOS cada interfaz para la que se quiere habilitar RSVP debe estar explícitamente configurada con RSVP. Asimismo, el administrador de la red debe configurar la cantidad de ancho de banda que se asigna a RSVP en esa interfaz. Para habilitar RSVP para IP en una interfaz, se debe utilizar el comando de configuración de interfaz ip rsvp bandwidth. Para inhabilitar RSVP, se debe utilizar la forma “no” de ese comando(Tomado de Fundamentos de Voz Sobre IP, Pagina 198): ip rsvp bandwidth [interface-kbps][single-flow-kbps] no ip rsvp bandwidth [interface-kbps] [single-flow-kbps] Las opciones del comando son:

• interface-kbps(Opcional). Cantidad de ancho de banda (en kbps) en la interfaz que hay que reservar ; el intervalo va de 1 a 10000000

• single-flow-kbps(Opcional). Cantidad de ancho de banda(en kbps) asignado

a un único flujo; el intervalo va de 1 a 10000000

• Predeterminado. 75% de ancho de banda disponible en la interfaz si no se especifica ningún ancho de banda .

162

Cat 6509Cat 6509

VoIP_CT

CISCO7513CT

SW_ENTRERRIOS

ATM

ETHERNET

ETHERNET

MERIDIAM

PEREIRA

CARTAGO

E1

E1

E1

Figura 68. Un esquema de VoIP y RSVP

El esquema anterior muestra la solución planteada para VoIP y RSVP, estamos asumiendo el ejemplo de la ruta de datos que tomaría una conversación entre una persona de Cartago y otra ubicada en Bogota. De Cartago se tiene un enlace E1 hasta Pereira y de este, otro E1 hasta el Switch entreríos(Ubicado en la ciudad de Bogota) y de este, una vez mas, otro E1 hasta el Cisco 7513CT ubicado en el Edificio Capital Tower, (El edificio de las oficinas centrales de Bellsouth Colombia en Bogota, ubicado en la calle 100 con carrera 7). Los enlaces etiquetados como ETHERNET son las conexiones dentro de la red local del edificio Capital Tower. Los anchos de banda de los enlaces E1 son de 2048 kbps, es decir capacidad de 2 Mbps(ha esto nos referíamos con el sobreaprovisionamiento de la red, y la visión de la empresa de no correr riesgos con el tema, en este caso el año de banda es suficiente y adicionalmente sobre este ancho de banda se plantea la reserva de recursos) Las líneas punteadas son enlaces en donde se aplicó RSVP para reserva de ancho de banda que usan los paquetes VoIP. Los equipos usados son marca Cisco y los que se usan en los extremos(como en el caso de Cartago), son enrutadores Cisco 2611, con tarjetas FXS(Foreign exchange station), las cuales producen un tono para el teléfono que se conecte a ellas. La siguiente tabla resume las características de los dispositivos que hacen parte de la solución VoIP y RSVP(Todos marca Cisco).

163

Tabla 17. Dispositivos de la solución VoIP y RSVP

Dispositivo Características

CARTAGO Procesador Cisco 2611(MPC 860) (revisión 0x203) con 39936K/9216K bytes de memoria.

PEREIRA Procesador Cisco 4500(R4K) (revisión 0x00) con 32768K/16384 bytes de memoria.

SW-ENTRERRIOS Procesador Cisco RSP2(R4700) con 65536K/2072K bytes de memoria. CPU R4700 a 100 Mhz, implementación 33, Revisión 1.0

CISCO7513CT Enrutador de características similares al enrutador de Pereira. CAT 6509 Switch Cisco referencia 6509, es el sitio donde convergen todas

las conexiones de datos del edificio Capital Tower. VoIP_CT Procesador Cisco 2611XM(MPC860P) (revisión 0x100) con

59392K/6144K bytes de memoria. MERIDIAM Central telefónica interna del edificio Capital Tower. A este se le

entrega un enlace para que lo conmute hacia el resto de extensiones.

En la solución, no fue motivo de preocupación la sobrecarga del protocolo RSVP sobre los enrutadores. Es importante anotar que los enrutadores deben tener una imagen del sistema operativo(IOS) que soporte VoIP. Presentamos un ejemplo de la descripción de la imagen del sistema operativo utilizado en los enrutadores: Cisco Internetwork Operating System Software IOS(tm) C2600 Software(C2600-IS-M) Versión 12.0(5)T1, RELEASE SOFTWARE(fc1) Copyright(c) 1986-1999 por cisco Systems ,Inc. Compiled Tue 17-Aug-99 14:39 Image text-base: 0x80008088, data-base: 0x80B5E15C A continuación mostramos el ejemplo de configuración del enrutador de la ciudad de Cartago para soporte de RSVP, la reserva de ancho de banda utilizada y los parámetros de fair-queue(WFQ)(cabe anotar que no existió un método ”científico” para establecer los parámetros correctos del algoritmo WFQ, y los valores se generaron a prueba y error y observando el comportamiento de la solución; esto reitera la necesidad de una herramienta de simulación para estos casos, y es vital dentro de un proyecto de mayor envergadura). Sobre la interface serial del enrutador de la ciudad de Cartago , los parámetros mas importantes se resumen acá:

164

Figura 69. Configuración de enrutador para soporte de RSVP

La parte anterior define la reserva de ancho de banda sobre el enlace E1 y los parámetros de WFQ. La configuración siguiente sobre el mismo enrutador define quienes usaran la reserva de ancho de banda propuesta en la interface. En este caso las llamadas entrantes por el puerto de voz del enrutador(dial-peer voice) solicitaran esa reserva, esta petición se hace a través del comando req-qos guaranteed-delay(solicitud de Qos, de retardo garantizado). La reserva de ancho de banda (128 kbps)se propaga en todos los enrutadores del camino de la llamada entre Cartago y Bogota. 3.4.4. Enseñanzas Esta practica sirvió para ilustrar algunos elementos y reforzar otros que ya se habían considerado, entre ellos: Los temores de implementar una política de QoS a gran escala en una organización, están relacionados puntualmente con la falta de productos consolidados, el desconocimiento del tema y el aparente poco interés por una visión a mas largo plazo. Deben transcurrir algunos años para que las aplicaciones nos obliguen a pensar realmente en las necesidades de implementar este tipo de estrategias. Las pruebas que las empresas efectúan relacionadas con QoS están centradas en la estrategia de sobreaprovisonamiento, que es suficiente para las necesidades actuales. RSVP o cualquier técnica adicional de Qos se observan principalmente como un valor agregado, que por ahora, no ha ganado suficiente aceptación en el mercado. Las soluciones que implementan están basadas en productos ampliamente aceptados y normalmente no se disponen de ambientes apropiados para la experimentación de políticas de QoS. Aunque en la documentación se define la forma de mapear RSVP y ATM, esto en la practica resulto complicado(por eso no se uso el enlace ATM), ya que no se pudo

165

declarar RSVP en las interfaces ATM. Se necesita mayor experimentación practica sobre este caso puntual y la documentación no era lo suficientemente clara. Esto esta sujeto a las versiones de los sistemas operativos que soporten estas características. Los temas relacionados con el protocolo SBM y la señalización RSVP desde las aplicaciones, actualmente no tiene la difusión ni el respaldo de productos aceptados en nuestra realidad nacional. Aunque los sistemas operativos como Windows 2000 proveen las API para que las aplicaciones requieran RSVP y QoS, estas características no son muy conocidas, ni explotadas dentro del mercado local. En general no encontramos herramientas adecuadas que pudieran servirnos para medir el efecto del protocolo y los cambios en los parámetros de técnicas como WFQ, sobre la red. Aunque existen simuladores del protocolo, no pudimos usarlos en la practica.

166

4. CONCLUSIONES

4.1. SOBRE LA ESTRATEGIA DE CALIDAD DE SERVICIO Aunque inicialmente este trabajo estaba orientado sobre la necesidad de conocer las técnicas de un protocolo de reserva de recursos en la red(RSVP) y como este mecanismo podría ayudar a que las aplicaciones de tiempo real obtuvieran los recursos que necesitaban, durante el transcurso me di cuenta que era mas importante aún, tratar el tema de “calidad de servicio”; particularmente porque las estrategias de calidad de servicio están relacionados con la evolución que debe tener la red en una empresa y las nuevas necesidades planteadas por los usuarios. Este aprovechamiento de la red, va a constituir un “elemento diferenciador” que le permita a la empresa aumentar su valor y disminuir costos; todo enfocado a la visión de una red convergente inteligente, que administre adecuadamente los recursos que posee. Desarrollar una guía de calidad de servicio para las organizaciones es un trabajo que requiera una amplia experimentación; se pueden definir algunos elementos como los que se consideran en este estudio, pero se requiere un nivel de detalle mucho mas amplio, particularmente porque las aplicaciones dentro de la estrategia pueden ser de naturalezas muy distintas y con una amplia diversidad de productos, no es lo mismo desarrollar Qos para una aplicación de VoIP o como estrategia para definir reglas de prioridades sobre las aplicaciones de la empresa; en ambos casos cada solución aporta nuevas consideraciones y productos. Las recomendaciones que se generaron en esta tesis se deben observar como un punto de partida o de referencia que de alguna forma ayuda a reducir la complejidad del tema de QoS, sin ser este un producto final, sino que debe estar en constante revisión para ajustarlo a los nuevos requerimientos y necesidades, particularmente son criticas la revision de los requerimientos y la herramientas que permitan hacer mejores analisis de la estrategia adecuada a implementar. Qos es una necesidad y eso esta totalmente manifiesto, pero desde este concepto a la implementación hay un largo recorrido, aun en ambientes controlables como intranets, intervienen no solo los inconvenientes técnicos sino las barreras desde el punto de vista de la organización y de lo que realmente requiere. No existe un modelo de servicio o la panacea que deba aplicarse puntualmente en una empresa, precisamente porque los modelos están en continua evolución(intserv,diffserv,mpls) y las mejoras en los productos ocurren a diario; o sea que cada nueva técnica debe observarse con ojo clínico e implementar lo que tenga el respaldo de estándares y de ejemplos de otras organizaciones. Posiblemente se pueda sobrevivir agregando mas ancho de banda, pero no por siempre, mas aun cuando tenemos una presión creciente de nuevos servicios desde los usuarios, Qos estará en la agenda de las organizaciones en los próximos años, o por lo menos, eso lo demuestran los ejemplos de implementación a nivel mundial,

167

particularmente el tema es muy activo en Internet, donde se requiere un esquema escalable, que proporcione mejor servicio a algunas aplicaciones especiales. Las tecnologías se están desarrollando, no solo en la red sino en las aplicaciones, evolucionan a diario, se integran, se hacen consistentes a través de todos los niveles para ofrecer la calidad de servicio que el usuario requiere. Un área particularmente incipiente y que puede constituir un elemento clave mas adelante es la señalización QoS desde las aplicaciones, no encontramos amplia divulgación sobre esta clase de experimentos, la mayoría de ejemplos de QoS estaban centrados en la red y no en el software de las aplicaciones; esto ha impedido que el tema evolucione mas rápidamente, cuando el software de aplicación tiene esta habilidad de aprovechar las capacidades de la red, el usuario puede experimentar los beneficios de QoS y presionar el crecimiento de la estrategia. En general, el conocimiento de las herramientas de Qos es una limitante en las empresas y uno de los orígenes de sus temores sobre la implementación, se debe trabajar ampliamente en los temas que permitan que el recurso humano tenga las capacidades suficientes que le permitan diseñar e implementar una estrategia de calidad de servicio. Otro factor importante es disponer de herramientas sencillas que permitan administrar las políticas de QoS de forma efectiva, no solo es complejo seleccionar el modelo y la técnica de Qos adecuada para una aplicación(porque puede involucrar distintas tecnologías), sino que se debe lidiar con la falta de herramientas que permitan propagar fácilmente las políticas de Qos en todos los dispositivos de la red. Dado que se trata de un tema evolutivo las empresas deberían disponer de herramientas que les permitieran validar las pruebas de un modelo de QoS. Por ahora en intranets no existe una marcada preocupación por el tema de QoS, puesto que las tecnologías como GigabitEthernet proporcionan suficientes anchos de banda y están orientadas a brindar soporte QoS. A medida que se gane confianza, deben proliferar naturalmente las soluciones y el desarrollo de un plan de calidad de servicio será un requisito indispensable de cualquier empresa que desee ser competitiva en el mercado. El desarrollo de una metodología que permita generar las estrategias de calidad de servicio para una organización, debe ser un área particularmente importante en términos prácticos, ya que debe estar alineada con el plan estratégico de la organización sobre como aumentar sus servicios de valor agregado tanto para sus clientes internos como para sus clientes externos; este trabajo es un punto de partida, que debe servir para que se desarrolle y se refine una metodología de aplicación de QoS en intranets(el tema en Internet resulta aun mas complejo). 4.2. SOBRE RSVP Desde el momento en que se inicio este estudio(1999) a la fecha, el protocolo que era muy poco conocido ha ganado popularidad y se ha desarrollado en diversos productos; se han diseñado soluciones para integrarlo con tecnologías diversas como ATM, Frame Relay, Ethernet,etc ; estos productos están alcanzado rápidamente su nivel de maduración y las empresas empiezan a desarrollar estrategias basadas en su capacidad.

168

Los temas restrictivos con respecto a sus aplicabilidad relacionados con la escabilidad y el tiempo para propagar una petición de reserva se han ido superando en el transcurso de los años y la experiencia y todo parece indicar que es un esquema de señalización QoS que será ampliamente aplicado aun en tecnologías como MPLS. Se han desarrollado técnicas que mejoran sus propiedades de escalabilidad y aunque en Internet el protocolo parece haber perdido su papel que se creyó inicialmente protagónico, dentro de ambientes intranets su rol parece asegurado, o por lo menos eso lo demuestran el numero nuevo de implementaciones y el interés en poder utilizarlo. En Internet parece ser que las estrategias de Diffserv y MPLS superan el modelo planteado por Intserv y RSV, la solución final parece estar del lado de la integración y uso de estas tecnologías en ciertos segmentos de la red. En la orilla de la red posiblemente RSVP sea el esquema de señalización preferido. Un factor importante a considerar con respecto al estudio del protocolo fue la imposibilidad de usar un simulador de red adecuado, y aunque existen implementaciones(la mayoría de ellas propietarias) no se conoció una que fuera fácil de manipular desde el punto de vista del usuario y del administrador de red. Quizás el simulador mas conocido que tenga un modulo especifico para RSVP, sea el software NS2(Network Simulator versión 2.0) desarrollado entre otros por las siguiente entidades(Laboratorio nacional de Berkeley, AT&T, USC/ISI, Xerox, ETH TIK), pero es complejo su uso y las versiones solo están disponibles para UNIX, la versión para Windows tiene bastantes deficiencias . Es vital en cualquier trabajo futuro, explorar y conocer al detalle una herramienta de este estilo, principalmente en la fase de análisis de las estrategias de calidad de servicio. 4.3. CONSIDERACIONES FINALES En lo referente a la guía se debe lograr un nivel de detalle mucho mas cercano a la realidad de las empresas, se debería trabajar en un enfoque por tipos de aplicaciones y dentro de estos tipos de aplicaciones mostrar específicamente los productos y herramientas puntuales(una especie de inventario), esta estrategia de agregación por tipo de funcionalidad, permitirá a las empresas tomar decisiones mucha mas acertadas y reducir el riesgo de usar soluciones que no tengan respaldo suficiente de la industria. Como es imposible que QoS sea un desarrollo de un único momento, así mismo la guía debe estarse revaluando periódicamente en función del crecimiento de los productos y de las necesidades de las aplicaciones Con respecto a la protocolo RSVP y a la estrategia de calidad de servicio se deben contar con herramientas y dispositivos que permitan hacer los set de pruebas respectivos que faciliten los análisis comparativos(laboratorios y planes pilotos de implementación). Es muy interesante el desarrollo de proyectos que muestren como las aplicaciones señalizan o solicitan a la red una determinada calidad de servicio, este tipo de aplicaciones, están poco desarrolladas y existen contados ejemplos(aunque la mayoría de sistemas Operativos poseen la API para QoS); constituyéndose esta en una muy importante área de investigación. Las aplicaciones software en este sentido deben informarse mejor de lo que ocurre en la red y aprovechar sus capacidades QoS.

169

Otra área de investigación activa es el soporte del protocolo RSVP a nivel de la capa de enlace, específicamente a nivel de Ethernet, las técnicas para mapear los mecanismos y mensajes de RSVP, son objeto de especial interés para los grupos de investigación y la industria.

170

REFERENCIAS Agarwal Anjali,(2000) .Quality of service(QoS) in the New Public Network Architecture.IEEE Canadian Review. Blum Rick,(2000),”Network Quality Of Service”, International Network Services. Braden,Berson, Herson,Jamin& Zhang, (Septiembre 1997),Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification,RFC 2205 Braden,Clark&Shenker (Julio 1994) “Integrated services in the Internet Architecture : An Overview”. Internet RFC 1633.. Burguillos &López (1999),Simulador del protocolo de reserva de recursos Calidad de servicio en redes IP. Anonimo Cisco Press, (Junio 1999),Internetworking Technology Overview Cisco Press,(Junio 1999), Internetworking Technologies Handbook Cisco Systems inc ,CiscoAssure Policy Networking End-to_end Quality Of Service, (1998), White Paper, Cisco Systems inc ,Configuring RSVP. Cisco IOS Quality of Service Solution Configuration Guide Cisco Systems inc. ,(2000)Cisco IOS Quality of Service Solutions Configuration Guide,Signalling Overview Cisco Systems inc,RSVP Scalability Enhancements de Cisco IOS Release 12.2(2)T Diaz & Quintero,(1997), Guía para el desarrollo de redes que involucran multimedia, Tesis de maestria de la Universidad de los andes. Evaluación de mecanismos de calidad de servicio en los enrutadores para servicios multimedia. Hernández,(2001).Reserva eficiente de recursos en redes de tiempo real, Tesis de Doctorado, Universidad Politecnica de Valencia. Microsoft Corporation (1999),”Build a better network with QoS”. White Paper, recuperado el 1 de mayo 2003 http://wwww.winnetmag.com/articles/index.cfm?ArticleID=3932

171

Microsoft Corporation,(2001),Introducción a Microsoft Windows 2000 Server,: “Introducción a la infraestructura de red”, publicado por Microsoft Press. Microsoft Corporation,(2000), Resumen de los mecanismos de QoS y como ínteroperan White Paper. Nichols , Jacobson& Zhang, (Jul 99), "A Two-bit differentiated Services Architecture for the Internet". IETF RFC2638, Shenker&Wroclawsky, (Septiembre de 1997), “General characterization parameters of Integrated Service network elements”,RFC 2215

172

BIBLIOGRAFIA [ANJ20]. Agarwal Anjali,. “Quality of service(QoS) in the New Public Network Architecture”. IEEE Canadian Review. [BER00] Bernet et al.,"A Framework for Integrated Services Operation over DiffServ Networks", IETF draft, May. 2000. En: http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-05.txt . [BHU97].Bhumip Khasnabish, Roberto Saracco. “Intranets: Technologies,Service, and Management”. Articulo de Internet. IEEE Communications Magazine. Octubre 1997. [BLAK98] S. Blake, D. Black, M. Carlson, E. Davis, Z. Wang and W. Weiss. “An architecture for Differenciated Services”, IETF RFC2475, Dec. 1998. [BLU20]. Rick Blum. “Network Quality of service”. International Network Services. [BRA94] R.Braden, D.Clark, S.Shenker, “Integrated services in the Internet Architecture : An Overview”. Internet RFC 1633. Julio de 1994. [BRA97].R. Branden, L. Zhang, S. Berson, S. Herzog, S. Jamin.Resource Reservation Protocol (RSVP) Version 1 Functional Specification. RFC 2205. RFC 2205. Septiembre 1997. Recuperado de http://www.ietf.org/rfc/rfc2205.txt [BRA97] R. Branden, L. Zhang. Resource Reservation Protocol (RSVP) Version 1 Message Processing Rules. RFC 2209. Septiembre 1997. [BUR99].Daniel Adán Burguillos y Juan José López Mellado. Simulador del protocolo de reserva de recursos RSVP. FIB (UPC). Curso 1999/2000. [CIS98].Cisco Systems. “CiscoAssure Policy Networking End-to-End Quality of Service”. Articulo publicado por Cisco Systems,1998 [CIS98].Cisco Systems. Internetworking Technology Overview. “Quality of Service(QoS) Networking ”. Publicado por Cisco Systems, Junio 1999 [CIS99].Cisco Press. Internetworking Technologies Handbook. “Resource Reservation Protocol”. Recuperado de http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rsvp.htm [CIS00].Cisco Press. Cisco IOS Release 12.2(2)T. “RSVP Scalability Enhancements”. [CIS00].Cisco Press.Cisco IOS Quality of Service Solutions Configuration Guide. Capitulos:“Configuring RSVP” y “Signalling Overview”. [DAV20]. Jonathan Davison. James Peters. Fundamentos de Voz sobre IP. Cisco Press. España 2000.

173

[DIA98] Luis Carlos Diaz Ch. Guía para el desarrollo de redes que involucran multimedia. [GON95] Goncalves, K. Cooper, S. Vuong, and M.Ito. “ A classification of multimedia Applications requirements “, 1995 Pacific Workshop on Distributed Multimedia Systems, Honolulu, Hawai, Marzo 31-Abril 2 , 1995. [HER01]. Enrique Hernández Orallo. Reserva Eficiente de Recursos en Redes, para Transmisión en Tiempo Real. Tesis de Doctorado. Universidad Politecnica de Valencia. Departamento de Informática de Sistemas y de Computadores.Valencia, Enero de 2001. [KOR98].Paul Korzeniowski. “Intranets Still Not Ready For Video”. SunExpert Magazine. Junio 1998 [MIC99] “An overview of QoS”. White Paper. Windows 2000 Server Technical Notes. Microsoft TechNet – December 1999. [MIC99] Microsoft Press. Introducción a Microsoft Windows 2000 Server. “Introduccion a la infraestructura de red”. Articulo de Internet. 1999. [MIC00] Microsoft Press. “ Resumen de los mecanismos de Qos y Como Interoperan”. Articulo de Internet. 2000. [RFC 2210] J. Wroclawski. “The use of RSVP with IETF Integrated services”. RFC 2210. Septiembre 1997. [RFC 2211] J. Wroclawski. “Specification of the controlled_load network element service ”. RFC 2211. Septiembre 1997. [RFC 2212] S.Shenker, C.partriadge,R.Guerin. “ Specification of guaranteed Quality of service”. RFC 2212. Septiembre 1997. [RFC 2215] S.Shenker, J.wroclawski. “General characterization parameters of Integrated services Network elements”. RFC 2215. Septiembre 1997. [STAR99]. Stardust Forums. “IP QoS FAQ”. Articulo de Internet, recuperado de: http://www.inf.ufrgs.br/granvile/QoS/Imprimir/faq.pdf Septiembre de 1999. [SABA] J. Corvacho, J. Domingo Pascual, D. Larrabiti, A.Luna,J. Quemada, J. Solé y H.Velayos. “Liberado 4: Evaluacion de experiencias, proyecto SABA” [UR97] Ursula Schwantang. An analysis of the applicability of RSVP. 1997. University of Oregon and Institute of Telematics. [TAN96] Andrew S.Tanenbaum, Computer Networks .Tercera Edicion. Prentice Hall 1996. [3COM98].3com. 3com’s strategy for Delivering Differentiated Service Levels. Articulo de Internet. Febrero 6 de 1998.

RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL PROTOCOLO …

Documents

Transcript of RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL PROTOCOLO …