Descripción general de RSVP

Los enrutadores utilizan el protocolo RSVP para ofrecer solicitudes de calidad de servicio (QoS) a todos los nodos a lo largo de las rutas de flujo de datos y para establecer y mantener el estado del servicio solicitado. Las solicitudes de RSVP generalmente dan lugar a reservas de recursos en cada nodo a lo largo de la ruta de datos. RSVP tiene los siguientes atributos:

• Reserva recursos para flujos unidireccionales de datos.

• Permite que el receptor de un flujo de datos inicie y mantenga la reserva de recursos utilizada para ese flujo, como se muestra en Figura 1.

• Mantiene un estado suave en enrutadores y hosts, proporcionando soporte agraciado para cambios de membresía dinámicos y adaptación automática a los cambios de enrutamiento.

• Depende de protocolos de enrutamiento presentes y futuros, pero no es un protocolo de enrutamiento en sí mismo.

• Ofrece varios modelos o estilos de reserva para adaptarse a una variedad de aplicaciones.

• Admite paquetes IPv4 e IPv6 que se pueden enviar a través de LSP señalizadas por RSVP.

Figura 1: Solicitud de reserva RSVP y flujo de datos

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 una comunicación humana, se utiliza para comunicar el identificador de sesión a todos los remitentes y receptores.

Una sesión RSVP típica 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 que desee unirse a la sesión, se registra si es necesario. Por ejemplo, un receptor de 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 de Resv adecuados al remitente. Estos mensajes llevan un descriptor de flujo, que los enrutadores utilizan a lo largo de la ruta para hacer reservas en sus medios de capa de vínculo.

5. El remitente recibe el mensaje de Resv y, a continuación, comienza a enviar datos de la 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 de Resv. Los datos de la aplicación que se entregan antes de la reserva real contenida en el mensaje de Resv generalmente se tratan como el mejor esfuerzo, tráfico no en tiempo real sin garantía de CoS.

RSVP es un protocolo de señalización que maneja la asignación de ancho de banda y la ingeniería de tráfico real a través de una red MPLS. Al igual que LDP, RSVP usa mensajes de descubrimiento y anuncios para intercambiar información de ruta LSP entre todos los hosts. Sin embargo, RSVP también incluye un conjunto de funciones que controlan el flujo de tráfico a través de una red MPLS. Mientras que el LDP se limita a usar la ruta más corta del IGP configurada como la ruta de tránsito a través de la red, RSVP usa una combinación del algoritmo primero de ruta corta restringida (CSPF) y objetos de ruta explícita (ERO) para determinar cómo se enruta el tráfico a través de la red.

Las sesiones básicas de RSVP se establecen exactamente de la misma manera en que se establecen las sesiones de LDP. Al configurar MPLS y RSVP en las interfaces de tránsito adecuadas, habilita el intercambio de paquetes RSVP y el establecimiento de LSP. Sin embargo, RSVP también le permite configurar la autenticación de vínculos, las rutas LSP explícitas y la coloración de vínculos.

Este tema contiene las siguientes secciones:

• Fundamentos de RSVP
• Requisito de reserva de ancho de banda
• Objetos de ruta explícita
• Primero la ruta más corta restringida
• Coloración de vínculos

Objetos de ruta explícita

Los objetos de ruta explícita (EROS) limitan el enrutamiento LSP a una lista especificada de LSR. De forma predeterminada, los mensajes RSVP siguen una ruta determinada por la ruta más corta del IGP de la red. Sin embargo, en presencia de una ERO configurada, los mensajes RSVP siguen la ruta especificada.

Los EROs constan de dos tipos de instrucciones: saltos sueltos y saltos estrictos. Cuando se configura un salto suelto, identifica uno o más LSR de tránsito a través del cual se debe enrutar el LSP. El IGP de red determina la ruta exacta desde el enrutador de entrada al primer salto suelto o de un salto suelto al siguiente. El salto suelto especifica solo que se incluya una LSR determinada en el LSP.

Cuando se configura un salto estricto, identifica una ruta exacta a través de la cual se debe enrutar el LSP. Los ERO de salto estricto especifican el orden exacto de los enrutadores a través de los cuales se envían los mensajes RSVP.

Puede configurar ERE de saltos sueltos y estrictos simultáneamente. En este caso, el IGP determina la ruta entre saltos sueltos y la configuración de salto estricto especifica la ruta exacta para segmentos de ruta LSP particulares.

Figura 2 muestra un LSP típico con señal de RSVP que usa ERE.

Figura 2: LSP señal de RSVP típico con EROs

En la topología que se muestra en Figura 2, el tráfico se enruta desde el host C1 al host C2. El LSP puede pasar a través de los enrutadores R4 o R7. Para forzar el LSP a usar R4, puede configurar un ERO de salto flexible o estricto que especifique R4 como salto en el LSP. Para forzar una ruta específica a través del enrutador R4, R3 y R6, configure un ERO de salto estricto a través de los tres LSR.

A partir de junos OS versión 16.1, se introdujeron las extensiones del protocolo de ingeniería de tráfico (TE) de RSVP (TE) para admitir el intervalo de actualización RSVP independiente (RI-RSVP) definido por RFC 8370 para la protección de las instalaciones de reenrutamiento rápido (FRR) para permitir una mayor escalabilidad de las rutas conmutadas por etiquetas (LSP), tiempos de convergencia más rápidos y reducir la sobrecarga de mensajes de señalización de RSVP a partir de actualizaciones periódicas. Junos RSVP-TE se ejecuta en FRR mejorado, también conocido como modo RI-RSVP de forma predeterminada, que incluye extensiones de protocolo para admitir RI-RSVP para omisión de instalaciones de FRR especificadas originalmente en RFC 4090.

Las extensiones de protocolo RI-RSVP implementadas en Junos son totalmente compatibles con versiones anteriores. En entornos mixtos, en los que un subconjunto de LSP atraviesa nodos que no incluyen esta función, Junos RSVP-TE que se ejecuta en modo FRR mejorado desactivará automáticamente las nuevas extensiones de protocolo en sus intercambios de señalización con nodos que no admiten las nuevas extensiones.

Como parte del perfil FRR mejorado, se realizaron una serie de cambios y se adoptaron nuevos valores predeterminados. Estas se enumeran aquí.

• RSVP-TE ejecuta FRR "mejorado" o modo RI-RSVP, de forma predeterminada, que incluye mejoras para facilitar escenarios escalados. Estas nuevas extensiones de protocolo se pueden deshabilitar en un enrutador con el comando no-enhanced-frr-bypass .

• Las extensiones de reducción de actualización RSVP definidas en RFC 2961 están habilitadas de forma predeterminada. El usuario puede deshabilitarlos con el comando no confiable (consulte a continuación).

  Nota:

  Los Saludos basados en node-id están habilitados de forma predeterminada, ya que las extensiones mejoradas de FRR o RI-RSVP requieren el intercambio de mensajes de Saludo basados en id de nodo. Los saludos basados en id de nodo se pueden deshabilitar con node-hello un comando. Dado que las extensiones de actualización-reducción y los mensajes de Saludo basados en id de nodo son esenciales para las extensiones de FRR o RI-RSVP mejoradas, deshabilitar cualquiera de ellas desactivará automáticamente las extensiones de FRR mejoradas en el nodo.

• El tiempo de actualización predeterminado de los mensajes RSVP ha aumentado de 30 segundos a 20 minutos.

• El valor predeterminado del multiplicador de mantención, que es 3, se aplica al nuevo tiempo de actualización predeterminado.

• La reversión local está deshabilitada de forma predeterminada. La configuración existente de la CLI para el nodo Hola, , sigue disponible, [edit protocols rsvp node-hello]pero la acción es redundante. Si está habilitado, se muestra un mensaje para indicar que la configuración no es necesaria junto con FRR mejorado.

• Los comandos existentes para deshabilitar la confiabilidad del mensaje ahora se utilizan para deshabilitar la reducción de actualización de RSVP. Para revertir a la opción predeterminada anterior que habilitaba la reducción de actualización, utilice la delete versión de los siguientes comandos:

  • Configure no-reliable una interfaz determinada para deshabilitar automáticamente las mejoras de escalabilidad de FRR para todos los LSP que atraviesan la interfaz. Del mismo modo, para ejecutar RSVP-TE sin mejoras en la protección de las instalaciones de FRR, y sin reducción de actualización, desactive la reducción de actualización en cada interfaz. Utilice uno de los comandos que se muestran aquí:

    • [edit protocols rsvp interface name no-reliable]

    • [edit logical-systems name protocols rsvp interface name no-reliable]

• El reinicio elegante y el enrutamiento activo sin interrupciones (NSR) no se admiten mientras el LSP se somete a una reparación local o mientras el LSP se actualiza durante la señalización de LSP de respaldo. Esta limitación ya existe en la implementación, ya que el cambio de GR o NSR durante la reparación local de FRR hace que haya varios escenarios de falla.

• Los siguientes comandos operativos se han actualizado para incluir nueva información sobre los nuevos procedimientos introducidos para las extensiones de protocolo TE RSVP para la protección de instalaciones de FRR.

  • show rsvp version muestra si los procedimientos de FRR mejorados están habilitados.

  • show rsvp neighbor detail muestra si los procedimientos de FRR mejorados están habilitados en el vecino.

  • show rsvp interface detail muestra estadísticas de PathTear condicionales.

  • show rsvp statistics muestra las estadísticas enviadas y recibidas para PathTear condicional, junto con otras estadísticas.

  • show rsvp session extensive muestra si el nodo es un punto de fusión y, si lo es, muestra la dirección del punto de reparación local (PLR).

• Las opciones de configuración de la CLI anteriores para habilitar o deshabilitar la agrupación de mensajes han quedado en desuso (se aceptan las configuraciones existentes, pero se muestra una advertencia en el resultado de mostrar configuración). Estos comandos son los siguientes:

  • [edit protocols rsvp interface name aggregate]

  • [edit logical-systems name protocols rsvp interface name aggregate]

  • [edit protocols rsvp interface name no-aggregate]

  • [edit logical-systems name protocols rsvp interface name no-aggregate]

• Los cambios actuales han hecho redundantes las siguientes opciones de configuración de CLI (se aceptan las configuraciones existentes, pero se muestra una advertencia en el resultado de mostrar configuración):

  • [edit protocols rsvp interface name reliable]

  • [edit logical-systems name protocols rsvp interface name reliable]

La implementación de Junos de RSVP admite RSVP versión 1. El software incluye compatibilidad con todos los objetos obligatorios y tipos de mensajes RSVP, y admite la integridad del mensaje y las autenticaciones de nodos a través del objeto Integrity.

El objetivo principal del software Junos RSVP es admitir la señalización dinámica dentro de rutas conmutadas por etiquetas (LSP) de MPLS. El respaldo de reservas de recursos a través de Internet es solo un propósito secundario de la implementación de Junos OS. Dado que las reservas de recursos compatibles son secundarias, el software Junos RSVP no admite las siguientes funciones:

• Sesiones de multidifusión IP.

• Control de tráfico. El software no puede hacer reservas de recursos para sesiones de video o audio en tiempo real.

Con respecto al mecanismo de protocolo, el procesamiento de paquetes y los objetos RSVP admitidos, la implementación de Junos OS del software es interoperable con otras implementaciones de RSVP.

Junos OS admite el estilo de autenticación RSVP descrito en RFC 2747 (que permite la compatibilidad con varios proveedores) y el estilo de autenticación RSVP descrito en el borrador de Internet draft-ietf-rsvp-md5-03.txt. Junos OS usa el estilo de autenticación descrito en el borrador de Internet draft-ietf-rsvp-md5-08.txt de forma predeterminada. Si el enrutador recibe una autenticación RSVP de estilo RFC 2747 de un vecino, cambia a este estilo de autenticación para ese vecino. El estilo de autenticación RSVP para cada enrutador vecino se determina por separado.

RSVP monitorea el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS u OSPF) y confía en los protocolos IGP para detectar cuando un nodo falla. Si un protocolo IGP declara a un vecino inactivo (porque ya no se reciben paquetes de saludo), RSVP también hace descender a ese vecino. Sin embargo, los protocolos IGP y RSVP aún actúan de forma independiente cuando se acerca a un vecino.

En Junos OS, RSVP normalmente depende de la detección de paquetes de saludo del IGP para comprobar si hay errores de nodo. Configurar un tiempo corto para los temporizadores de saludo IS-IS u OSPF permite que estos protocolos detecten fallas de nodos rápidamente. Cuando el nodo falla o se detecta un error de nodo, se genera un mensaje de error de ruta y, aunque la sesión RSVP falla, los vecinos del IGP permanecen inactivos.

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

No recomendamos configurar un temporizador de saludo RSVP corto. Si es necesario descubrir rápidamente un vecino fallido, configure los temporizadores de saludo de IGP cortos (OSPF o IS-IS).

OSPF e IS-IS tienen infraestructura para gestionar el envío y la recepción rápidas de mensajes de saludo de manera confiable, incluso si los protocolos de enrutamiento o algún otro proceso están sobrecargando la capacidad de procesamiento del enrutador. En las mismas circunstancias, los saludos de RSVP podrían tener un tiempo de descanso antes de tiempo, aunque el vecino esté funcionando normalmente.

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

• Mensajes de ruta
• Mensajes de resv
• Mensajes pathTear
• Mensajes de ResvTear
• Mensajes de PathErr
• Mensajes de ResvErr
• Mensajes de ResvConfirm

Los proveedores de servicios a menudo usan VPN de BGP y MPLS para escalar la red de manera eficiente mientras ofrecen servicios que generan ingresos. En estos entornos, BGP se utiliza para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras que MPLS se utiliza para reenviar ese tráfico VPN de un sitio VPN a otro. Las VPN de BGP y MPLS se basan en un modelo par. Para agregar un nuevo dispositivo CE (sitio) a una VPN existente, debe configurar el enrutador CE en el nuevo sitio y el enrutador de PE conectado al enrutador CE. No es necesario modificar la configuración de todos los demás enrutadores de PE que participan en la VPN. Los otros enrutadores de PE aprenden automáticamente sobre las rutas asociadas con el nuevo sitio, un proceso llamado descubrimiento automático (AD).

Los requisitos son un poco diferentes si necesita agregar un nuevo enrutador de PE a la red. Una VPN de BGP y MPLS requiere que la sesión del BGP esté completamente mallada y que también haya una malla completa de rutas de conmutación de etiquetas (LSP) del enrutador de PE a enrutador de PE MPLS entre todos los enrutadores de PE en la red. Cuando agregue un nuevo enrutador de PE a la red, todos los enrutadores de PE existentes se deben reconfigurar para que se paren con el nuevo enrutador de PE. Gran parte del esfuerzo de configuración se puede reducir si configura reflectores de ruta BGP (mitigando el requisito de malla completa para el BGP) y si configura (LDP) como protocolo de señalización para MPLS.

Sin embargo, si necesita agregar un nuevo enrutador de PE a una red configurada con una malla completa de LSP señalizadas por RSVP, debe reconfigurar cada uno de los enrutadores de PE para que tengan una relación par con el nuevo enrutador de PE. Puede configurar la malla automática RSVP para abordar este escenario operativo en particular. Cuando habilita la malla automática RSVP, los LSP de RSVP se crean dinámicamente entre un enrutador de PE nuevo y los enrutadores de PE existentes, lo que elimina la necesidad de reconfigurar todos los enrutadores de PE manualmente. Para que la creación dinámica de LSP funcione correctamente, el BGP debe configurarse para intercambiar rutas entre todos los enrutadores de PE participantes. Si dos pares del BGP no intercambian rutas, no es posible configurar un LSP dinámico entre ellos. La tabla de enrutamiento inet.3 del enrutador local debe incluir una ruta etiquetada para cada posible salto siguiente de IBGP (futuros enrutadores PE potenciales o destinos LSP).

RSVP incluye numerosas capacidades que no están disponibles en LDP, incluyendo reenrutamiento rápido, control de puntos de conexión y administración de vínculos. La malla automática RSVP ayuda a reducir los requisitos de operación y mantenimiento para RSVP, lo que permite implementar RSVP en redes más grandes y complicadas.

Cada enrutador de PE puede llegar a todos los demás enrutadores de PE de la red, ya que esta información la distribuye el IGP. Un enrutador de PE puede configurar un LSP RSVP punto a punto a cualquier otro enrutador de PE en la red, siempre y cuando sepa que se requiere un LSP de este tipo. Para crear una malla completa de LSP entre los enrutadores de PE, es necesario que cada enrutador de PE sepa cuáles de los otros enrutadores de PE conforman la malla completa.

Una solicitud de reserva incluye opciones para especificar el estilo de reserva. Los estilos de reserva definen cómo se tratan las reservas para diferentes remitentes dentro de la misma sesión y cómo se seleccionan los remitentes.

Dos opciones especifican cómo se tratan las reservas para diferentes remitentes dentro de la misma sesión:

• Reserva distinta: cada receptor establece su propia reserva con cada remitente ascendente.

• Reserva compartida: todos los receptores hacen una sola reserva que se comparte entre muchos remitentes.

Dos opciones especifican cómo se seleccionan los remitentes:

• Remitente explícito : enumera todos los remitentes seleccionados.

• Remitente comodín :permite seleccionar todos los remitentes y, a continuación, participar en la sesión.

Actualmente se definen los siguientes estilos de reserva, formados por una combinación de estas cuatro opciones:

• Filtro fijo (FF): este estilo de reserva consta de distintas reservas entre remitentes explícitos. Ejemplos de aplicaciones que utilizan reservas de estilo de filtro fijo son las aplicaciones de video y las aplicaciones de unidifusión, que requieren flujos que tienen una reserva independiente para cada remitente. El estilo de reserva de filtro fijo está habilitado en los LSP de RSVP de forma predeterminada.

• Filtro de comodín (WF): este estilo de reserva consiste en reservas compartidas entre remitentes comodín. Este tipo de reserva reserva el ancho de banda para todos y cada uno de los remitentes, y se propaga aguas arriba hacia todos los remitentes, extendiéndose automáticamente a los nuevos remitentes a medida que aparecen. Una aplicación de ejemplo para reservas de filtro de comodín es una aplicación de audio en la cual cada remitente transmite un flujo de datos distinto. Por lo general, solo unos pocos remitentes transmiten a la vez. Dicho flujo no requiere una reserva separada para cada remitente; una sola reserva es suficiente.

• Explícito compartido (SE): este estilo de reserva consiste en reservas compartidas entre remitentes explícitos. Este tipo de reserva reserva el ancho de banda para un grupo limitado de remitentes. Una aplicación de ejemplo es una aplicación de audio similar a la descrita para reservas de filtro comodín.

RSVP depende del estado suave para mantener los estados de ruta y reserva en cada enrutador. Si los mensajes de actualización correspondientes no se envían periódicamente, eventualmente los estados de tiempo de espera y las reservas se eliminarán. RSVP también envía sus mensajes de control como datagramas IP sin garantía de confiabilidad. Se basa en los mensajes de actualización periódicos para manejar la pérdida ocasional de mensajes de ruta o Resv.

Las extensiones de reducción de actualización RSVP, basadas en RFC 2961, abordan los siguientes problemas que resultan de confiar en mensajes de actualización periódicos para controlar la pérdida de mensajes:

• Escalabilidad: el problema de la escalabilidad surge de la transmisión periódica y la sobrecarga de procesamiento de los mensajes de actualización, que aumenta a medida que aumenta el número de sesiones RSVP.

• Confiabilidad y latencia: el problema de confiabilidad y latencia se deriva de la pérdida de mensajes RSVP sin respuesta o de mensajes RSVP únicos, como PathTear o PathErr. El tiempo para recuperarse de dicha pérdida suele estar relacionado con el intervalo de actualización y el temporizador de mantenimiento.

La capacidad de reducción de actualización RSVP se anuncia habilitando el bit compatible con reducción de actualización (RR) en el encabezado común RSVP. Este bit solo es significativo entre los vecinos de RSVP.

La reducción de actualización de RSVP incluye las siguientes características:

• Agrupación de mensajes RSVP mediante el mensaje de paquete

• ID de mensaje RSVP para reducir la sobrecarga de procesamiento de mensajes

• Entrega confiable de mensajes RSVP mediante el ID de mensaje, Message Ack y Message Nack

• Actualización de resumen para reducir la cantidad de información transmitida en cada intervalo de actualización

La especificación de reducción de actualización RSVP (RFC 2961) le permite habilitar algunas o todas las capacidades anteriores en un enrutador. También describe varios procedimientos que un enrutador puede usar para detectar las capacidades de reducción de actualización de su vecino.

Junos OS admite todas las extensiones de reducción de actualización, algunas de las cuales se pueden habilitar o deshabilitar de forma selectiva. Junos OS admite el ID de mensaje y, por lo tanto, puede realizar una entrega de mensajes confiable solo para los mensajes de Ruta y Resv.

Para obtener más información acerca de cómo configurar la reducción de actualización de RSVP, consulte Configurar la reducción de actualización de 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 podría causar retransmisiones. Una MTU demasiado pequeña podría hacer que el enrutador envíe y maneje relativamente más sobrecarga de encabezados y reconocimientos. Hay valores predeterminados para las TDU asociados 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 LSP. De forma predeterminada, la MTU para un LSP es de 1500 bytes.

Si esta MTU es mayor que la MTU de uno de los vínculos intermedios, es posible que se caiga 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 del LSP seguiría funcionando con normalidad.

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

Para evitar la pérdida de paquetes debido a discordancias 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 discordancia de MTU, el enrutador de entrada debe saber cuál es el valor de MTU más pequeño que se encuentra a lo largo de la ruta tomada por el LSP. Una vez que se obtiene este valor de MTU, el enrutador de entrada puede asignarlo al LSP.

• Fragmentos de paquetes: mediante el valor asignado de la MTU, los paquetes que superen el tamaño de la MTU se pueden fragmentar en paquetes más pequeños en el enrutador de entrada antes de que se encapsulan en MPLS y se envíen a través del LSP señalado por 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 a un LSP RSVP en este enrutador utiliza el valor de MTU señal. Para obtener más información acerca de cómo configurar esta característica, consulte Configurar señalización de MTU en RSVP.

Las siguientes secciones describen cómo funciona la señalización de MTU en RSVP:

• Cómo se señala la MTU correcta en RSVP

• Determinación de un valor de MTU de salida

• Señalización de MTU en limitaciones de RSVP

La forma en que se señala la MTU correcta en RSVP varía dependiendo de si los dispositivos de red (por ejemplo, enrutadores) admiten explícitamente la señalización de MTU en RSVP o no.

Si los dispositivos de red admiten señalización de MTU en RSVP, ocurre lo siguiente cuando habilita la señalización de MTU:

• La MTU se señala desde el enrutador de entrada al enrutador de salida mediante el objeto Adspec. Antes de reenviar este objeto, el enrutador de entrada introduce el valor de MTU asociado con la interfaz a través de la cual se envía el mensaje de ruta. En cada salto de la ruta, el valor MTU del objeto Adspec se actualiza al mínimo del valor recibido y del valor de la interfaz de salida.

• El enrutador de entrada usa el objeto de especificación de tráfico (Tspec) para especificar los parámetros para el tráfico que va a enviar. El valor de MTU señalado para el objeto Tspec en el enrutador de entrada es el valor máximo de MTU (9192 bytes para enrutadores serie M y T, 9500 bytes para enrutadores de transporte de paquetes serie PTX). Este valor no cambia en la ruta al enrutador de salida.

• Cuando el objeto Adspec llega al enrutador de salida, el valor de MTU es correcto para la ruta (lo que significa que es el valor MTU más pequeño descubierto). El enrutador de salida compara el valor de MTU en el objeto Adspec con el valor de MTU en el objeto Tspec. Señala la MTU más pequeña mediante el objeto Flowspec en el mensaje de Resv.

• Cuando el objeto Resv llega al enrutador de entrada, el valor MTU de este objeto se utiliza como MTU para los próximos saltos que usan el LSP.

En una red en la que hay dispositivos que no admiten la señalización de MTU en RSVP, es posible que tenga los siguientes comportamientos:

• Si el enrutador de salida no admite la señalización de MTU en RSVP, la MTU se establece en 1500 bytes de forma predeterminada.

• Un enrutador de tránsito de Juniper Networks que no admite la señalización de MTU en RSVP establece un valor de MTU de 1500 bytes en el objeto Adspec de forma predeterminada.

El valor de MTU de salida es el menor de los valores recibidos en el objeto Adspec en comparación con el valor de MTU de la interfaz de salida. El valor de MTU de la interfaz de salida se determina de la siguiente manera:

• Si configura un valor de MTU en el [family mpls] nivel de jerarquía, se indica este valor.

• Si no configura una MTU, se indica la inet MTU.

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

• Los cambios en el valor de MTU pueden causar 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 de la derivación solo se señala en el momento en que la omisión se activa. Durante el tiempo que tarda en propagarse la nueva ruta de MTU, puede producirse una pérdida de paquetes debido a una discordancia de MTU.

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

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

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

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

• Para LSP de un salto, el valor de MTU que muestran los show comandos es el valor señaldo de RSVP. Sin embargo, este valor MPLS se ignora y se utiliza el valor ip correcto.