Modelo IntServ/ Protocolo RSVP

Modelo IntServ/ Protocolo RSVP Cláudia Jacy Barenco Abbas INTERNET DE SERVICIOS INTEGRADOS Objetivo de la Internet de Servicios Integrados: Disponer de una sola red IP que transporte tráfico best effort y multimedia de tiempo real. Idea la Internet de Servicios Integrados FLUJOS Como identifico a este datagrama

LO BÁSICO EN IntServ Que necesita la red IntServ?. Que los host soliciten una QoS específica de la red para una aplicación o flujo de datos en particular. Que los routers envíen las solicitudes de QoS a todos los nodos de la red, a lo largo de la trayectoria del dato. Quien hace esto? El protocolo de Reserva de Recursos, RSVP. Cual es la clave de RSVP? Reservar recursos en cada nodo por donde transitarán los paquetes o flujos de datos. Concepto de soft state. SEGUNDA ESCUELA DE VERANO EN CIENCIAS DE LA COMPUTACION PRIMEROS COMENTARIOS DE RSVP Cual es lo más característico del Protocolo RSVP? En RSVP, los receptores hacen las reservas de QoS. La reserva es realizada por flujo. RSVP es un protocolo de señalización. RSVP debe mantener en cada nodo los requerimientos de reserva. Se define el Soft State RSVP utiliza un conjunto de mensaje de señalización para mantener el soft state.

IDEA BÁSICA DE RESERVA Control de admisión Clasificador de paquetes Planificador de paquetes Determina si existen recursos Flujo de datos Control de tráfico Identifica a los flujos admitidos Que cola se transmite primero QoS A la red RESERVA EN IntServ Envío de dato 4 Aplicación Sender Datos Router Reservation State Router Router Router Se define Soft State Router 3 Reservation messages inicia la reserva Receiver messages definirá el path State definido 3

Data PHOP state Router SOFT STATE MENSAJES BÁSICOS EN RSVP Reservation state Data Incoming Interfaces NHOP state Router SOFT STATE Outgoing Interfaces Reservation state Data Data state Router state Router SOFT STATE Por qué es necesario Soft State : Debido a que internet es una red dinámica: Nuevos routers pueden ingresar a la red o algunos dejar de funcionar. En realidad, que es el Soft State?. Son los estados en los router y hosts extremos, refrescados por los mensajes y. Para mantener el soft state es necesario refrescar cada nodo de manera periódica. 4

TEMPORIZACIÓN DEL SOFT-STATE STATE Cada R t=t t=t State L Reservation State L State L Reservation State L t=t4 K- mensajes pueden perderse sin que el estado sea borrado L (K + 0,5),5R t=t3 Para: K=, R=30 seg. L 67.5 se asume, L=90 seg. Mensaje de borrado Tear Estado de Aplicación trayectoria, 7 state Sender Mensage de trayectoria, Router MENSAJES EN RSVP Router Router Router Error Mensaje de error Err Mensaje de confirmación, Conf 5 Reserva aceptada Error Estado de reserva, Reservation state 3 Mensaje de error Err Router Router Mensaje de borrado Tear 6 Rcv Mensaje de 4 reserva, Rcv 5

RSVP EN HOST Y ROUTER Host Router Aplicación Proceso RSVP Política de control RSVP Proceso de enrutamiento Proceso RSVP Política de control TC Clasificador Planificador de paquetes Control admisión Datos TC Clasificador Planificador de paquetes Control admisión Datos El Clasificador(packet Control QoS control es implementado de de Admisión(admissión tráficoclassifier) está para formado un flujo determina control) por: datos la determina QoS en particular. para si cada el nodo flujo. Cada Clasificador, tiene QoS es suficientes flujo implementado es separado control recursos de por en admisión para colas un control suministrar individuales. y planificador. de tráfico(traffic QoS requerida. Control) ESTILOS DE RESERVAS Videoconferencia Varios señales de audio Todo flujo que va al puerto 34 FF SE WF FF( S{Q}, S{Q},.) SE ( ( S, S,) {Q} ) WF ( * {Q} ) 6

MODELO TOKEN BUCKET Token bucket no enviará más que (b+rxt) bytes en un intervalo t r bytes/seg byte byte byte Velocidad constante de los Tokens Velocidad de transmisión promedio de los flujos es: r bytes/seg. b bytes Profundidad del Token Bucket Datos de entrada de velocidad variable Cola de entrada d bytes Datos de salida de velocidad variable controlada FORMATO DEL PROTOCOLO RSVP 0 4 8 6 4 3 0 4 8 6 4 3 Cabecera IPv6 Cabecera RSVP Ver Flags Send_TTL Cabecera IPv6 Msg Type Reservado Chequeo suma RSVP Longitud RSVP Ver Prioridad Etiqueta de flujo Cabec.sigte Longitud de carga útil Límite salto 46 Dirección de origen Contenido del objeto Dirección de destino Objetos RSVP Mensaje RSVP (40 bytes) Contenido del objeto 7

CAMPOS DE LA CABECERA RSVP Campo Ver.-Indica la versión de RSVP. En. Campo Flag.-Inicialmente sin definir. Campo Msg Type.-Indica el tipo de mensaje. Msg Type 3 4 5 6 7 Tipo de reserva Err Err tear tear Conf Están definiéndose nuevos mensajes Campo Longitud RSVP.-Tamaño total en bytes. FORMATO DE LOS OBJETOS RSVP 0 4 8 6 4 3 Cabecera del objeto Contenido del objeto Campo.- Longitud total del objeto expresado en bytes. Campo y.- Identifican los diferentes tipos de objetos 8

OBJETO RSVP_HOP 0 4 8 6 4 3 bytes 3 Dirección IPv4 del salto siguiente/previo Manejador de Interfaz Lógica (LIH, Logical Interface Handle) 0 4 8 6 4 3 4 bytes 3 Dirección IPv6 del salto siguiente/previo Manejador de Interfaz Lógica (LIH, Logical Interface Handle) OBJETO TIME_VALUES 0 4 8 6 4 3 8 bytes 5 Período de Refresco R R especifica el periodo de refresco del soft state. Mensajes y. En la definición inicial de RSVP [RFC 05], se establece periodos de refrescos uniforme. El tiempo de vida L de un estado es. L (K + 0,5),5R 9

OBJETO ERROR_SPEC 0 4 8 6 4 3 Dirección del nodo de error IPv4 (3 bits) Indicador Código de error 6 Valor de error 0 4 8 6 4 3 4 6 Dirección del nodo de error IPv6 (8 bits) Código de Indicador error Código error= Falla de control de admisión. No hay recursos disponibles. Valor de error Código error=3 Desconocido clase de objeto. El campo Valor de error contiene el y del objeto desconocido. OBJETO STYLE 0 4 8 6 4 3 8 Indicador Vector de opción Reservados para usos futuros Sharing Control Sender Selection x x x x x x x x x x x x x x x x x x x SC SC SS SS SS WF = Wildcard-Filter FF = Fixed-Filter SE = Shared-Explicit 0 0 0 0 0 0 0 0 0 0

OBJETO FLOWSPEC CARGA CONTROLADA 3 4 3 6 5 8 7 0 Cabecera de mensajes Cabecera de parámetros 36 V=0 Reservado Longitud Total=7 SVC_Num=5 B Reservado PARAM_Num =7 Indicador=0 9 Token Bucket Rate (r) Token Bucket Size (b) Peak Data Rate (p) SVC_Longitud=6 PARAM_Longitud=5 Minimum Policed Unit (m) Maximum Packet Size (M) Cabecera de de datos por servicio Parámetro TSpec OBJETO FLOWSPEC CARGA GARANTIZADA 3 4 3 6 5 8 7 0 Cabecera de mensajes Cabecera de parámetros 36 SVC_Num= B Reservado PARAM_Num =7 Indicador=0 Token Bucket Rate (r) Token Bucket Size (b) Peak Data Rate (p) Minimum Policed Unit (m) Maximum Packet Size (M) ID=30 Indicador=0 Longitud= Rate (R) 9 V=0 Reservado Longitud Total=0 Slack Term (S) SVC_Longitud=9 PARAM_Longitud=5 Cabecera de de datos por servicio Parámetro TSpec Parámetro RSpec

OBJETO RESV_CONFIRM 0 4 8 6 4 3 0 4 8 6 4 3 8 5 Dirección del receptor IPv4 (3 bits) 8 5 Dirección del receptor IPv6 (8 bits) La dirección IP es del receptor que requiere una confirmación. 4 Datos PROCESO DE RESERVA IntServ/RSVP Routing Agent Como identificar a los paquetes de 3 Mensaje RSVP Se extrae su contenido RESV Setup Agent Parámetro IntServ Tipo de servicio Recurso aceptado FLOWSPEC Admission Control Mgmt Agent Recursos disponibles un flujo 3 FLOWSPEC (token bucket) Packet 5 6 Packet Classifier Scheduler 7 Interfaz de Base salida de datos Datos Determina el tipo de QoS de los flujos recibido

CONFIABILIDAD EN RSVP MESSAGE_ID MESSAGE_ID_ACK MESSAGE_ID_NACK Refrescar estados i, j, n Mensaje Refresh o Srefresh i Nodo Mensaje Ack Nodo j n Estados Estado n no encontrado Mensaje Ack Estados i,,j refrescado i j k Estados OBSERVACIONES Escalabilidad: La red se satura con mensajes RSVP. Para reducir la sobrecarga, se propone agrupar los mensajes RSVP estándar en mensaje Bundle. Confiabilidad y Latencia: La pérdida de mensajes de refresco RSVP origina un problema de sincronismo entre estados. Se propone el uso de mensaje Ack. Resumen de refrescos: Se propone refrescar el soft state sin enviar el mensaje de refresco completo. Se define el mensaje Srefresh. 3

COMENTARIOS FINALES Existe un consenso en la comunidad científica de introducir mecanismos de acuse de recibo. Una nueva tecnología hace uso de este Protocolo, es MPLS. Se espera mejorar el problema de escalabilidad para un mejor usos en MPLS. 4