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 de RSVP generalmente generan reservas de recursos en cada nodo a lo largo de la ruta de datos. El 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 la Figura 1.

• Mantiene un estado suave en enrutadores y hosts, lo que brinda soporte elegante para cambios de membresía dinámicos 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í mismo.

• 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ñalizados RSVP.

Figura 1: Solicitud de reserva de 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 por 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 de RSVP a la dirección de la sesión.

2. Un receptor, que desea unirse a la sesión, se registra si es necesario. Por ejemplo, un receptor en una aplicación de multidifusión se registraría en 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 utilizan 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 luego 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 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 máximo esfuerzo sin garantía de CoS.

RSVP es un protocolo de señalización que gestiona la asignación de ancho de banda y la ingeniería de tráfico real en una red MPLS. Al igual que LDP, RSVP utiliza mensajes de detección 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 ruta de tránsito a través de la red, RSVP utiliza una combinación del algoritmo de ruta restringida más corta primero (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 de 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, las rutas de LSP explícitas y el color de vínculos.

Este tema contiene las siguientes secciones:

• Fundamentos de RSVP
• Requisito de reserva de ancho de banda
• Objetos de ruta explícitos
• El camino restringido más corto primero
• 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 de 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 de RSVP siguen la ruta especificada.

Las ERO constan de dos tipos de instrucciones: lúpulos sueltos y lúpulos estrictos. 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 al primer salto suelto o de un salto suelto al siguiente. El salto suelto especifica solo que se incluya un LSR determinado en el LSP.

Cuando se configura un salto estricto, identifica una ruta exacta a través de la cual se debe enrutar el LSP. Las 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 ERO 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 particulares.

La Figura 2 muestra un LSP típico señalizado por RSVP que usa ERO.

Figura 2: LSP típico con señalización RSVP con ERO

En la topología mostrada en la Figura 2, el tráfico se enruta del host C1 al host C2. El LSP puede pasar a través de los enrutadores R4 o R7. Para forzar al LSP a usar R4, puede configurar un ERO de salto suelto o estricto que especifique R4 como un 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 extensiones del protocolo de ingeniería de tráfico (TE) de RSVP para admitir el RSVP independiente del intervalo de actualización (RI-RSVP) definido por el RFC 8370 para la protección de las instalaciones de reenrutamiento rápido (FRR) con el 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 de RSVP de las actualizaciones periódicas. El RSVP-TE de Junos se ejecuta en modo FRR mejorado, también conocido como RI-RSVP, de forma predeterminada que incluye extensiones de protocolo para admitir RI-RSVP para la derivación de instalaciones de FRR especificada originalmente en RFC 4090.

Las extensiones del 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 admiten 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í.

• El RSVP-TE ejecuta el modo FRR "mejorado", o RI-RSVP, de forma predeterminada, lo que incluye mejoras para facilitar la ampliación 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-reliable (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 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 reducción de actualización y los mensajes de saludo 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 de keep-multiplier, que es 3, se aplica al nuevo tiempo de actualización predeterminado.

• La reversión local está deshabilitada de forma predeterminada. La configuración de la CLI existente para el nodo Holas, , todavía está 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 usan para deshabilitar la reducción de actualización de RSVP. Para volver a la habilitación predeterminada anterior de la reducción de actualización, utilice la delete versión de los siguientes comandos:

  • Se establece no-reliable en una interfaz dada 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 de protección de las instalaciones de FRR y sin reducción de actualización, deshabilite la reducción de actualización en cada interfaz. Use 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 agraciado y el enrutamiento activo sin detención (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 del LSP de respaldo. Esta limitación ya existe en la implementación, ya que la conmutación de GR o NSR durante la reparación local de FRR da lugar a un escenario de fallas múltiples.

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

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

  • 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 las estadísticas enviadas y recibidas para el 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 obsoletas (se aceptan las configuraciones existentes, pero se muestra una advertencia en el resultado show configuration). 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 por los cambios actuales (se aceptan las configuraciones existentes, pero se muestra una advertencia en el resultado show configuration):

  • [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 la integridad del mensaje y las autenticaciones de nodos a través del objeto Integrity.

El propósito 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. El soporte de reservas de recursos a través de Internet es solo un propósito secundario de la implementación de Junos OS. Dado que el soporte de reservas de recursos es secundario, el software RSVP de Junos no admite las siguientes características:

• 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 compatibles, la implementación de Junos OS del software es interoperable con otras implementaciones de RSVP.

El 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. El Junos OS utiliza el estilo de autenticación descrito en Borrador de draft-ietf-rsvp-md5-08.txt de Internet de forma predeterminada. Si el enrutador recibe una autenticación RSVP 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) (SI-SI o OSPF) y se basa en los protocolos IGP para detectar cuándo falla un nodo. Si un protocolo IGP declara que un vecino está caído (porque ya no se reciben paquetes de saludo), RSVP también derriba a ese vecino. Sin embargo, los protocolos IGP y RSVP aún actúan de forma independiente al mencionar a un vecino.

En Junos OS, RSVP normalmente se basa en la detección de paquetes de saludo IGP para comprobar si hay errores en los nodos. Configurar un tiempo breve para los temporizadores de saludo SI-SI u OSPF permite que estos protocolos detecten errores de nodos 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 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 SI-SI ni OSPF). Además, el equipo de otros proveedores puede configurarse para supervisar las sesiones de RSVP en función de los paquetes de saludo de RSVP. Este equipo también puede desactivar una sesión de RSVP debido a una pérdida de paquetes de saludo de RSVP.

No recomendamos configurar un temporizador de saludo RSVP corto. Si necesita detectar rápidamente un vecino con errores, configure temporizadores de saludo IGP cortos (OSPF o SI-SI).

OSPF e SI-SI tienen infraestructura para administrar el envío y la recepción rápidos 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, es posible que se agote el tiempo de espera de los saludos de RSVP antes de tiempo, aunque el vecino esté funcionando normalmente.

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

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

Los proveedores de servicios a menudo usan VPN BGP y VPN de 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 VPN de MPLS se basan en un modelo par. Para agregar un nuevo dispositivo (sitio) CE 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 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 detección automática (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 de BGP esté completamente mallada y que también haya una malla completa de enrutador de enrutador a PE MPLS rutas conmutadas por etiquetas (LSP) entre todos los enrutadores de PE de la red. Cuando agregue 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 de BGP (mitigando el requisito de malla completa para BGP) y si configura (LDP) como el 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ñalizados por 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 de RSVP para abordar este escenario operativo en particular. Cuando se habilita la malla automática de RSVP, los LSP de RSVP se crean dinámicamente entre un nuevo enrutador de PE y los enrutadores de PE existentes, lo que elimina la necesidad de reconfigurar todos los enrutadores de PE manualmente. Para que la creación de LSP dinámica funcione correctamente, el BGP debe configurarse para intercambiar rutas entre todos los enrutadores de PE participantes. Si dos pares de 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 a cada próximo salto potencial de IBGP (futuros posibles enrutadores de PE o destinos de LSP).

RSVP incluye numerosas capacidades que no están disponibles en LDP, como el reenrutamiento rápido, el control de punto final y la administración de vínculos. La malla automática de 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 de PE puede llegar a todos los demás enrutadores de PE en la red porque esta información es distribuida por el IGP. Un enrutador de PE puede configurar un LSP RSVP punto a punto a cualquier otro enrutador de PE en la red, siempre que sepa que se requiere dicho LSP. Para crear una malla completa de LSP entre los enrutadores de PE, se requiere 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 emisor ascendente.

• Reserva compartida: todos los destinatarios hacen 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, participan 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 reservas distintas entre remitentes explícitos. Ejemplos de aplicaciones que utilizan reservas de estilo de 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 de 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 el ancho de banda para todos y cada uno de los remitentes, y se propaga hacia 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 comodín es una aplicación de audio en la que cada remitente transmite un flujo de datos distinto. Por lo general, solo unos pocos remitentes transmiten a la vez. Tal flujo no requiere una reserva separada para cada remitente; una sola reserva es suficiente.

• Explícito compartido (SE): este estilo de reserva consta de 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 las reservas de filtros comodín.

El 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 finalmente agotan el tiempo de espera y se eliminan las reservas. 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ódica para manejar la pérdida ocasional de mensajes Path o Resv.

Las extensiones de reducción de actualización de RSVP, basadas en RFC 2961, solucionan los siguientes problemas que se producen al depender de mensajes de actualización periódica para controlar la pérdida de mensajes:

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

• Confiabilidad y latencia: el problema de confiabilidad y latencia se deriva de la pérdida de mensajes RSVP que no se actualizan o 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 de mantenimiento.

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

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

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

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

• Entrega confiable de mensajes RSVP mediante 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 de RSVP (RFC 2961) le permite habilitar todas o algunas de 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 admite el ID de mensaje y, por lo tanto, puede realizar una entrega de mensajes confiable solo para mensajes de ruta y Resv.

Para obtener información sobre cómo configurar la reducción de actualización de RSVP, consulte Configurar la reducción de Actualizar de RSVP.

La unidad máxima de transmisión (UMT) es el paquete o trama de mayor tamaño, en bytes, que se puede enviar en una red. Una UMT demasiado grande puede provocar retransmisiones. Una UMT 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 UMT en una interfaz.

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

Si esta UMT es mayor que la UMT de uno de los vínculos intermedios, es posible que se pierda 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 normalmente.

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

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

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

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

Una vez habilitadas la señalización de UMT y la fragmentación de paquetes en un enrutador de entrada, cualquier ruta que se resuelva en un LSP de RSVP en este enrutador utiliza el valor de UMT señalado. Para obtener información acerca de cómo configurar esta característica, consulte Configurar la señalización de UMT en RSVP.

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

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

• Determinar un valor de UMT saliente

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

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

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

• La UMT 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 UMT asociado con la interfaz a través de la cual se envía el mensaje de ruta de acceso. En cada salto de la ruta, el valor de UMT en el objeto Adspec se actualiza al mínimo entre el valor recibido y el valor de la interfaz saliente.

• 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 UMT señalado para el objeto Tspec en la enrutador de entrada es el valor máximo de UMT (9192 bytes para enrutadores serie M y serie T, 9500 bytes para serie PTX Enrutadores de transporte de paquetes). Este valor no cambia en el camino hacia el enrutador de salida.

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

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

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

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

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

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

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

• Si no configura una UMT, la inet UMT se señaliza.

A continuación, se muestran las limitaciones de la señalización de UMT en RSVP:

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

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

  • Para el reenrutamiento rápido, la UMT de la ruta se actualiza solo después de que el desvío se activa, lo que provoca un retraso en una actualización de la UMT en el enrutador de entrada. Hasta que se actualice la UMT, puede producirse 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 UMT de desvío o bypass.

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

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

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