Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción general de la operación de RSVP

Un túnel de ruta de conmutación de etiquetas (LSP) del Protocolo de reserva de recursos (RSVP) le permite enviar LSP de RSVP dentro de otros LSP de RSVP. Esto permite que un administrador de red proporcione ingeniería de tráfico de un extremo a otro de la red. Una aplicación útil para esta característica es conectar enrutadores perimetrales de cliente (CE) con enrutadores perimetrales de proveedor (PE) mediante un LSP RSVP y, a continuación, tunelizar este LSP de borde dentro de un segundo LSP RSVP que viaja a través del núcleo de la red.

Debe tener una comprensión general de los conceptos de MPLS y conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones MPLS de Junos.

Un túnel RSVP LSP agrega el concepto de una adyacencia de reenvío, similar a la que se usa para la conmutación de etiquetas multiprotocolo generalizada (GMPLS).

La adyacencia de reenvío crea una ruta tunelizada para enviar datos entre dispositivos pares en una red RSVP LSP. Una vez que se ha establecido un LSP de adyacencia de reenvío (FA-LSP), se pueden enviar otros LSP a través del FA-LSP utilizando primero la ruta restringida más corta (CSPF), el Protocolo de administración de vínculos (LMP), la ruta abierta más corta primero (OSPF) y RSVP.

Para habilitar un túnel RSVP LSP, Junos OS utiliza los siguientes mecanismos:

  • LMP: originalmente diseñado para GMPLS, LMP establece adyacencias de reenvío entre pares de túnel RSVP LSP, y mantiene y asigna recursos para enlaces de ingeniería de tráfico.

  • Extensiones OSPF: OSPF fue diseñado para enrutar paquetes a interfaces físicas y lógicas relacionadas con una tarjeta de interfaz física (PIC). Este protocolo se ha extendido para enrutar paquetes a interfaces virtuales del mismo nivel definidas en una configuración LMP.

  • Extensiones RSVP-TE: RSVP-TE fue diseñado para señalar la configuración de LSP de paquetes en interfaces físicas. El protocolo se ha extendido para solicitar la configuración de rutas para paquetes LSP que viajan a interfaces virtuales del mismo nivel definidas en una configuración LMP.

Existen las siguientes limitaciones para las jerarquías de LSP:

  • No se admiten los LSP basados en conexión cruzada de circuitos (CCC).

  • No se admite el reinicio correcto.

  • La protección de vínculo no está disponible para FA-LSP ni en el punto de salida de la adyacencia de reenvío.

  • Los LSP de punto a multipunto no son compatibles con los FA-LSP.

RSVP crea sesiones independientes para manejar cada flujo de datos. Una sesión se identifica mediante una combinación de la dirección de destino, un puerto de destino opcional y un protocolo. Dentro de una sesión, puede haber uno o más remitentes. Cada remitente se identifica mediante una combinación de su dirección de origen y puerto de origen. Un mecanismo fuera de banda, como un protocolo de anuncio de sesión o comunicación humana, se utiliza para comunicar el identificador de sesión a todos los remitentes y receptores.

Una sesión típica de RSVP implica la siguiente secuencia de eventos:

  1. Un remitente potencial comienza a enviar mensajes de ruta RSVP a la dirección de sesión.

  2. Un receptor, queriendo unirse a la sesión, se registra si es necesario. Por ejemplo, un receptor en una aplicación de multidifusión se registraría con IGMP.

  3. El receptor recibe los mensajes de ruta.

  4. El receptor envía los mensajes Resv apropiados hacia el remitente. Estos mensajes llevan un descriptor de flujo, que es utilizado por los enrutadores a lo largo de la ruta para hacer reservas en sus medios de capa de vínculo.

  5. El remitente recibe el mensaje Resv y, a continuación, comienza a enviar datos de aplicación.

Esta secuencia de eventos no está necesariamente estrictamente sincronizada. Por ejemplo, los receptores pueden registrarse antes de recibir mensajes de ruta del remitente, y los datos de la aplicación pueden fluir antes de que el remitente reciba mensajes Resv. Los datos de la aplicación que se entregan antes de la reserva real contenida en el mensaje Resv normalmente se tratan como tráfico no en tiempo real de mejor esfuerzo sin garantía de CoS.

RSVP Hello Packets y Timers

RSVP supervisa el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS u OSPF) y se basa en los protocolos IGP para detectar cuándo falla un nodo. Si un protocolo IGP declara a un vecino caído (porque ya no se reciben paquetes de saludo), RSVP también derriba ese vecino. Sin embargo, los protocolos IGP y RSVP todavía actúan independientemente cuando se acerca a un vecino.

En Junos OS, RSVP normalmente se basa en la detección de paquetes de saludo IGP para comprobar si hay errores de nodo. Las sesiones RSVP se mantienen activas incluso si los paquetes de saludo RSVP ya no se reciben, siempre y cuando el enrutador continúe recibiendo paquetes de saludo IGP. Las sesiones RSVP se mantienen hasta que el enrutador deja de recibir paquetes de saludo IGP o se agota el tiempo de espera de la ruta RSVP y los mensajes RESV. La configuración de un corto tiempo para los temporizadores de saludo IS-IS u OSPF permite que estos protocolos detecten fallas de nodo rápidamente.

Se puede confiar en los saludos de RSVP cuando el IGP no reconoce a un vecino en particular (por ejemplo, si IGP no está habilitado en la interfaz) o si el IGP es RIP (no IS-IS u OSPF). Además, el equipo de otros proveedores puede configurarse para supervisar las sesiones de RSVP basadas en paquetes de saludo RSVP. Este equipo también puede interrumpir una sesión de RSVP debido a la pérdida de paquetes de saludo RSVP.

No recomendamos configurar un temporizador de saludo RSVP corto. Si se necesita un descubrimiento rápido de un vecino fallido, configure temporizadores de saludo cortos de IGP (OSPF o IS-IS).

OSPF e IS-IS tienen infraestructura para administrar el envío y recepción rápida de mensajes de saludo de manera confiable, incluso si los protocolos de enrutamiento o algún otro proceso están forzando la capacidad de procesamiento del enrutador. En las mismas circunstancias, los saludos de RSVP pueden agotar el tiempo de espera prematuramente aunque el vecino esté funcionando normalmente.

Tipos de mensajes RSVP

RSVP utiliza los siguientes tipos de mensajes para establecer y eliminar rutas para flujos de datos, establecer y eliminar información de reservas, confirmar el establecimiento de reservas e informar de errores:

Mensajes de ruta

Cada host remitente transmite mensajes de ruta descendentes a lo largo de las rutas proporcionadas por los protocolos de enrutamiento de unidifusión y multidifusión. Los mensajes de ruta siguen las rutas exactas de los datos de la aplicación, creando estados de ruta en los enrutadores a lo largo del camino, lo que permite a los enrutadores aprender el nodo de salto anterior y siguiente para la sesión. Los mensajes de ruta se envían periódicamente para actualizar los estados de ruta.

El intervalo de refresh-timeactualización se controla mediante una variable denominada , que es el temporizador de actualización periódica expresado en segundos. Se agota el tiempo de espera de un estado de ruta si un enrutador no recibe un número especificado de mensajes de ruta consecutivos. Este número se especifica mediante una variable denominada keep-multiplier. Los estados de ruta se mantienen durante ( (keep-multiplier + 0,5) x 1,5 x refresh-time ) segundos.

Mensajes Resv

Cada host receptor envía mensajes de solicitud de reserva (Resv) ascendentes hacia los remitentes y las aplicaciones de remitente. Los mensajes resv deben seguir exactamente la ruta inversa de los mensajes de ruta. Los mensajes resv crean y mantienen un estado de reserva en cada enrutador a lo largo del camino.

Los mensajes resv se envían periódicamente para actualizar los estados de reserva. El intervalo de actualización se controla mediante la misma variable de tiempo de actualización y los estados de reserva se mantienen durante ( (keep-multiplier + 0,5 ) x 1,5 x    refresh-time)  segundos.

Mensajes de PathTear

Los mensajes PathTear eliminan (desmontan) los estados de ruta, así como los estados de reserva dependientes en cualquier enrutador a lo largo de una ruta. Los mensajes PathTear siguen la misma ruta que los mensajes de ruta. Un PathTear normalmente es iniciado por una aplicación remitente o por un enrutador cuando se agota el tiempo de espera de su estado de ruta.

Los mensajes PathTear no son obligatorios, pero mejoran el rendimiento de la red porque liberan recursos de red rápidamente. Si los mensajes de PathTear se pierden o no se generan, los estados de ruta de acceso agotan el tiempo de espera cuando no se actualizan y se liberan los recursos asociados con la ruta de acceso.

Mensajes de ResvTear

Los mensajes ResvTear eliminan los estados de reserva a lo largo de una ruta. Estos mensajes viajan aguas arriba hacia los remitentes de la sesión. En cierto sentido, los mensajes ResvTear son lo contrario de los mensajes Resv. Los mensajes de ResvTear suelen ser iniciados por una aplicación receptora o por un enrutador cuando se agota el tiempo de espera de su estado de reserva.

Los mensajes ResvTear no son obligatorios, pero mejoran el rendimiento de la red porque liberan recursos de red rápidamente. Si los mensajes de ResvTear se pierden o no se generan, los estados de reserva agotan el tiempo de espera cuando no se actualizan y se liberan los recursos asociados con la reserva.

Mensajes de PathErr

Cuando se producen errores de ruta de acceso (normalmente debido a problemas de parámetros en un mensaje de ruta de acceso), el enrutador envía un mensaje PathErr de unidifusión al remitente que emitió el mensaje de ruta de acceso. Los mensajes de PathErr son informativos; Estos mensajes no alteran ningún estado de ruta de acceso a lo largo del camino.

Mensajes de ResvErr

Cuando se produce un error en una solicitud de reserva, se entrega un mensaje de error ResvErr a todos los receptores involucrados. Los mensajes de ResvErr son informativos; Estos mensajes no alteran ningún estado de reserva en el camino.

Mensajes de ResvConfirm

Los destinatarios pueden solicitar la confirmación de una solicitud de reserva, y esta confirmación se envía con un mensaje ResvConfirm. Debido a las complejas reglas de combinación de flujo de RSVP, un mensaje de confirmación no proporciona necesariamente una confirmación de extremo a extremo de toda la ruta. Por lo tanto, los mensajes de ResvConfirm son una indicación, no una garantía, de un éxito potencial.

Los enrutadores de Juniper Networks nunca solicitan confirmación mediante el mensaje ResvConfirm; sin embargo, un enrutador de Juniper Networks puede enviar un mensaje ResvConfirm si recibe una solicitud del equipo de otro proveedor.

Señalización MTU en RSVP

La unidad máxima de transmisión (MTU) es el paquete o trama de mayor tamaño, en bytes, que se puede enviar en una red. Una MTU demasiado grande puede causar retransmisiones. Una MTU demasiado pequeña puede hacer que el enrutador envíe y maneje relativamente más sobrecarga de encabezado y confirmaciones. Hay valores predeterminados para las MTU asociadas con varios protocolos. También puede configurar explícitamente una MTU en una interfaz.

Cuando se crea un LSP en un conjunto de vínculos con diferentes tamaños de MTU, el enrutador de entrada no sabe cuál es la MTU más pequeña en la ruta de LSP. De forma predeterminada, la MTU para un LSP es de 1.500 bytes.

Si esta MTU es mayor que la MTU de uno de los vínculos intermedios, es posible que se interrumpa el tráfico, ya que los paquetes MPLS no se pueden fragmentar. Además, el enrutador de entrada no es consciente de este tipo de pérdida de tráfico, ya que el plano de control para el LSP seguiría funcionando normalmente.

Para evitar este tipo de pérdida de paquetes en los LSP MPLS, puede configurar la señalización MTU en RSVP. Esta característica se describe en RFC 3209. Juniper Networks admite el objeto de servicios integrados para la señalización MTU en RSVP. El objeto Servicios integrados se describe en las RFC 2210 y 2215. La señalización MTU en RSVP está deshabilitada de forma predeterminada.

Para evitar la pérdida de paquetes debido a desajustes de MTU, el enrutador de entrada debe hacer lo siguiente:

  • Señale la MTU en el LSP RSVP: para evitar la pérdida de paquetes por una discrepancia de MTU, el enrutador de entrada necesita saber cuál es el valor de MTU más pequeño a lo largo de la ruta tomada por el LSP. Una vez obtenido este valor MTU, el router de entrada puede asignarlo al LSP.

  • Paquetes de fragmento: con el valor de MTU asignado, los paquetes que superan el tamaño de la MTU se pueden fragmentar en paquetes más pequeños en el enrutador de entrada antes de encapsularlos en MPLS y enviarse a través del LSP con señal RSVP.

Una vez que se han habilitado tanto la señalización de MTU como la fragmentación de paquetes en un enrutador de entrada, cualquier ruta que se resuelva en un LSP RSVP en este enrutador utiliza el valor MTU señalizado.

Las siguientes son limitaciones de la señalización MTU en RSVP:

  • Los cambios en el valor de MTU pueden provocar una pérdida temporal de tráfico en las siguientes situaciones:

    • Para la protección de vínculos y la protección de nodos, la MTU del bypass solo se señala en el momento en que el bypass se activa. Durante el tiempo que tarda la nueva ruta de acceso de MTU en propagarse, puede producirse una pérdida de paquetes debido a una discrepancia de MTU.

    • Para un reenrutamiento rápido, la MTU de la ruta se actualiza solo después de que el desvío se active, lo que provoca un retraso en la actualización de la MTU en el enrutador de entrada. Hasta que se actualice la MTU, es posible que se produzca una pérdida de paquetes si hay una discrepancia de MTU.

      En ambos casos, solo se pierden los paquetes que son más grandes que la MTU de desvío o derivación.

  • Cuando se actualiza una MTU, se activa un cambio en el siguiente salto. Cualquier cambio en el siguiente salto hace que se pierdan las estadísticas de la ruta.

  • La MTU mínima admitida para la señalización MTU en RSVP es de 1.488 bytes. Este valor impide que se utilice un valor falso o configurado incorrectamente.

  • Para los LSP de un solo salto, el valor MTU que muestran los show comandos es el valor señalado por RSVP. Sin embargo, este valor MPLS se omite y se utiliza el valor IP correcto.

Documentación relacionada