Descripción general de RSVP

Los enrutadores utilizan el protocolo RSVP para entregar 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 RSVP generalmente resultan en reservas de recursos en cada nodo a lo largo de la ruta de datos. RSVP tiene los siguientes atributos:

• Hace reservas de recursos para flujos de datos unidireccionales.

• Permite al receptor de un flujo de datos iniciar y mantener la reserva de recursos utilizada para ese flujo, como se muestra en Figura 1.

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

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

• Proporciona 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ñalados 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 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 es un protocolo de señalización que maneja la asignación de ancho de banda y la verdadera ingeniería de tráfico a través de una red MPLS. Al igual que LDP, RSVP utiliza mensajes de descubrimiento y anuncios para intercambiar información de ruta de LSP entre todos los hosts. Sin embargo, RSVP también incluye un conjunto de características que controlan el flujo de tráfico a través de una red MPLS. Mientras que LDP está restringido a usar la ruta más corta del IGP configurado como la ruta de tránsito a través de la red, RSVP usa una combinación del algoritmo Restricted Shortest Path First (CSPF) y objetos de ruta explícitos (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 que se establecen las sesiones LDP. Al configurar MPLS y RSVP en las interfaces de tránsito adecuadas, se 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, rutas LSP explícitas y colorear vínculos.

Este tema contiene las siguientes secciones:

• Fundamentos de RSVP
• Requisito de reserva de ancho de banda
• Objetos de ruta explícitos
• Primero el camino más corto restringido
• Colorear enlaces

Objetos de ruta explícitos

Los objetos de ruta explícitos (ERO) limitan el enrutamiento de 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 red. Sin embargo, en presencia de una ERO configurada, los mensajes RSVP siguen la ruta especificada.

Las ERO constan de dos tipos de instrucciones: lúpulo suelto y lúpulo estricto. Cuando se configura un salto suelto, identifica uno o más LSR de tránsito a través de los cuales se debe enrutar el LSP. El IGP de red determina la ruta exacta desde el enrutador entrante hasta el primer salto suelto, o de un salto suelto al siguiente. El salto suelto especifica sólo que un LSR determinado se incluya 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 EROOs de salto suelto y salto estricto 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 de LSP específicos.

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

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

En la topología mostrada en , el tráfico se enruta del host C1 al host C2.Figura 2 El LSP puede pasar a través de los enrutadores R4 o R7. Para forzar al LSP a utilizar R4, puede configurar una ERO de salto suelto o de salto estricto que especifique R4 como un salto en el LSP. Para forzar una ruta específica a través de los enrutadores 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 extensiones de protocolo de ingeniería de tráfico (TE) RSVP para admitir RFC 8370 definida por RSVP independiente (RSVP) de intervalo de actualización para la protección de instalaciones de reenrutamiento rápido (FRR), a fin de permitir una mayor escalabilidad de las rutas conmutadas por etiquetas (LSP), tiempos de convergencia más rápidos y disminuir la sobrecarga de mensajes de señalización RSVP de actualizaciones periódicas. Junos RSVP-TE se ejecuta de forma predeterminada en el modo FRR mejorado, también conocido como RI-RSVP, que incluye extensiones de protocolo para admitir RI-RSVP para la omisión de instalaciones FRR especificada originalmente en RFC 4090.

Las extensiones de protocolo RI-RSVP implementadas en Junos son totalmente compatibles con versiones anteriores. En entornos mixtos, donde un subconjunto de LSP atraviesa nodos que no incluyen esta característica, el RSVP-TE de Junos 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 admitan las nuevas extensiones.

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

• RSVP-TE ejecuta el modo FRR "mejorado", o RI-RSVP, de forma predeterminada, lo que incluye mejoras para facilitar escenarios de escalabilidad vertical. 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 de RSVP definidas en RFC 2961 están habilitadas de forma predeterminada. El usuario puede deshabilitarlos con el comando no confiable (ver más abajo).

  Nota:

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

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

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

• La reversión local está deshabilitada de forma predeterminada. La configuración de CLI existente para el nodo Hellos, , todavía está disponible, pero la acción es redundante.[edit protocols rsvp node-hello] 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 de los mensajes ahora se usan para deshabilitar la reducción de actualización de RSVP. Para volver a la reducción de actualización predeterminada anterior, utilice la versión de los siguientes comandos:delete

  • Establezca en una interfaz determinada para deshabilitar automáticamente las mejoras de escalabilidad de FRR para todos los LSP que atraviesan la interfaz.no-reliable 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, deshabilite 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 correcto 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 porque el cambio GR o NSR durante la reparación local de FRR crea un escenario de falla múltiple.

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

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

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

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

  • show rsvp statistics muestra 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 combinación y, si lo es, muestra la dirección del punto de reparación local (PLR).

• Las opciones de configuración de CLI anteriores para habilitar o deshabilitar la agrupación de mensajes han quedado obsoletas (se aceptan las configuraciones existentes, pero se muestra una advertencia en la salida 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]

• Las siguientes opciones de configuración de CLI se han vuelto redundantes debido a los cambios actuales (se aceptan las configuraciones existentes, pero se muestra una advertencia en la salida 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 la versión 1 de RSVP. El software incluye soporte para todos los objetos obligatorios y tipos de mensajes RSVP, y admite integridad de mensajes y autenticaciones de nodo a través del objeto Integrity.

El objetivo principal del software RSVP de Junos es admitir la señalización dinámica dentro de las rutas de conmutación de etiquetas (LSP) de MPLS. La compatibilidad con reservas de recursos a través de Internet es solo un propósito secundario de la implementación de Junos OS. Dado que la compatibilidad con reservas de recursos es secundaria, el software RSVP de Junos 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 tanto el estilo de autenticación RSVP descrito en RFC 2747 (que permite la compatibilidad con varios proveedores) como el estilo de autenticación RSVP descrito en el borrador de Internet draft-ietf-rsvp-md5-03.txt. Junos OS utiliza 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 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. 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. Cuando se produce un error en el nodo o se detecta un error en el nodo, se genera un mensaje de error de ruta y, aunque la sesión RSVP deja de funcionar, los vecinos del IGP permanecen activos.

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.

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
• Mensajes Resv
• Mensajes de PathTear
• Mensajes de ResvTear
• Mensajes de PathErr
• Mensajes de ResvErr
• Mensajes de ResvConfirm

Los proveedores de servicios a menudo usan VPN BGP y MPLS para escalar la red de manera eficiente mientras ofrecen servicios que generan ingresos. En estos entornos, BGP se usa para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras que MPLS se usa para reenviar ese tráfico VPN de un sitio VPN a otro. Las VPN 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 PE conectado al enrutador CE. No es necesario modificar la configuración de todos los demás enrutadores PE que participan en la VPN. Los otros enrutadores PE aprenden automáticamente acerca de 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 PE a la red. Una VPN de BGP y MPLS requiere que la sesión de BGP esté completamente mallada y que también haya una malla completa de rutas de conmutación de etiquetas MPLS (LSP) de enrutador PE a enrutador PE entre todos los enrutadores de PE de la red. Cuando se agrega un nuevo enrutador de PE a la red, todos los enrutadores de PE existentes deben reconfigurarse para emparejarse 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 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 con señal RSVP, debe volver a configurar 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 se habilita la malla automática RSVP, los LSP RSVP se crean dinámicamente entre un nuevo enrutador PE y los enrutadores PE existentes, lo que elimina la necesidad de volver a configurar todos los enrutadores PE manualmente. Para que la creación de LSP dinámico funcione correctamente, BGP debe configurarse para intercambiar rutas entre todos los enrutadores PE participantes. Si dos pares BGP no intercambian rutas, no es posible configurar un LSP dinámico entre ellos. La tabla de enrutamiento inet.3 del router local debe incluir una ruta etiquetada a cada posible próximo salto 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 punto final 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 hace posible implementar RSVP en redes más grandes y complicadas.

Cada enrutador PE puede llegar a todos los demás enrutadores PE de la red, ya que esta información es distribuida por el IGP. Un enrutador PE puede configurar un LSP RSVP punto a punto para cualquier otro enrutador PE de la red, siempre y cuando sepa que se requiere dicho LSP. Para construir una malla completa de LSP entre los enrutadores de PE, es necesario que cada enrutador de PE sepa cuál de los otros enrutadores de PE constituye 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 destinatarios realizan una única 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: seleccione todos los remitentes que, a continuación, participarán 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 filtro fijo son las aplicaciones de vídeo 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 RSVP de forma predeterminada.

• Filtro comodín (WF): este estilo de reserva consiste en reservas compartidas entre remitentes comodín. Este tipo de reserva reserva 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 nuevos remitentes a medida que aparecen. Una aplicación de ejemplo para reservas de filtros comodín es una aplicación de audio en la que cada remitente transmite un flujo de datos distinto. Normalmente, solo unos pocos remitentes transmiten al mismo tiempo. 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 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 las reservas de filtros comodín.

RSVP se basa en el 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, los estados eventualmente agotan el tiempo de espera y las reservas se eliminan. RSVP también envía sus mensajes de control como datagramas IP sin garantía de confiabilidad. Se basa en mensajes de actualización periódicos para controlar la pérdida ocasional de mensajes Path o Resv.

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

• Escalabilidad: el problema de escalado surge de la sobrecarga periódica de transmisión y 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 que no se actualizan o de mensajes RSVP de una sola vez, como PathTear o PathErr. El tiempo para recuperarse de tal pérdida generalmente está vinculado al intervalo de actualización y al temporizador keepalive.

La capacidad de reducción de actualización de 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 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 usando Message ID, 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 utilizar 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 es compatible con el ID de mensaje y, por lo tanto, solo puede realizar una entrega confiable de mensajes para mensajes Path y Resv.

Para obtener información acerca de cómo configurar la reducción de actualización de RSVP, consulte Configuración de 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 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. Para obtener información acerca de cómo configurar esta característica, consulte Configuración de la señalización MTU en RSVP.

En las siguientes secciones se describe cómo funciona la señalización MTU en RSVP:

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

• Determinación de un valor de MTU saliente

• Señalización MTU en las 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 MTU en RSVP o no.

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

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

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

• Cuando el objeto Adspec llega al enrutador de salida, el valor 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 MTU del objeto Adspec con el valor MTU del objeto Tspec. Señala la MTU más pequeña mediante el objeto Flowspec en el mensaje Resv.

• Cuando el objeto Resv llega al enrutador de entrada, el valor MTU de este objeto se utiliza como MTU para los siguientes saltos que utilizan el LSP.

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

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

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

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

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

• Si no configura una MTU, la MTU recibe una señal.inet

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 comandos es el valor señalado por RSVP.show Sin embargo, este valor MPLS se omite y se utiliza el valor IP correcto.