Configuración de PCEP

Descripción de MPLS RSVP-TE

La ingeniería de tráfico (ING-T) se ocupa de la optimización del rendimiento de las redes operativas, principalmente de mapear los flujos de tráfico en una topología física existente. La ingeniería de tráfico brinda la capacidad de mover el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) a una ruta física potencialmente menos congestionada a través de una red.

Para la ingeniería de tráfico en redes grandes y densas, se pueden implementar capacidades de MPLS porque potencialmente proporcionan la mayor parte de la funcionalidad disponible a partir de un modelo superpuesto, de manera integrada y a un costo menor que las alternativas de la competencia actualmente. La razón principal para implementar la ingeniería de tráfico MPLS es controlar las rutas a lo largo de las cuales el tráfico fluye a través de una red. La principal ventaja de implementar la ingeniería de tráfico MPLS es que proporciona una combinación de las capacidades de ingeniería de tráfico de ATM, junto con la diferenciación de clase de servicio (CoS) de IP.

En una red MPLS, la información del plano de datos se reenvía mediante la conmutación de etiquetas. Un paquete que llega a un enrutador perimetral de proveedor (PE) desde el enrutador perimetral de cliente (CE) tiene etiquetas aplicadas y, luego, se reenvía al enrutador de PE de salida. Las etiquetas se eliminan en el enrutador de salida y, a continuación, se reenvían al destino adecuado como un paquete IP. Los enrutadores de conmutación de etiquetas (LSR) en el dominio MPLS utilizan protocolos de distribución de etiquetas para comunicar el significado de las etiquetas utilizadas para reenviar el tráfico entre y a través de los LSR. RSVP-TE es uno de esos protocolos de distribución de etiquetas que permite a un par LSR aprender sobre las asignaciones de etiquetas de otros pares.

Cuando MPLS y RSVP están habilitados en un enrutador, MPLS se convierte en cliente de RSVP. El propósito principal del software RSVP de Junos OS es admitir la señalización dinámica dentro de rutas conmutadas por etiquetas (LSP). El RSVP reserva recursos, como los flujos de unidifusión y multidifusión IP, y solicita parámetros de calidad del servicio (QoS) para las aplicaciones. El protocolo se extiende en la ingeniería de tráfico MPLS para permitir que RSVP configure LSP que se pueden usar para la ingeniería de tráfico en redes MPLS.

Cuando se combinan MPLS y RSVP, las etiquetas se asocian con flujos de RSVP. Una vez que se establece un LSP, el tráfico que pasa por la ruta se define mediante la etiqueta aplicada en el nodo de entrada del LSP. La asignación de la etiqueta al tráfico se realiza utilizando diferentes criterios. El conjunto de paquetes a los que un nodo específico asigna el mismo valor de etiqueta pertenece a la misma clase de equivalencia de reenvío (FEC) y define efectivamente el flujo de RSVP. Cuando el tráfico se asigna a un LSP de esta manera, el LSP se denomina túnel LSP.

Los túneles LSP son una forma de establecer rutas unidireccionales conmutadas por etiquetas. RSVP-TE se basa en el protocolo de núcleo de RSVP mediante la definición de nuevos objetos y la modificación de los objetos existentes utilizados en los objetos PATH y RESV para el establecimiento de LSP. Los nuevos objetos (objeto LABEL-REQUEST (LRO), objeto RECORD-ROUTE (RRO), objeto LABEL y objeto EXPLICIT-ROUTE (ERO)) son opcionales con respecto al protocolo RSVP, excepto los objetos LRO y LABEL, que son obligatorios para establecer túneles LSP.

En general, el RSVP-TE establece una ruta conmutada por etiqueta que garantiza la entrega de tramas desde el enrutador de entrada al enrutador de salida. Sin embargo, con las nuevas capacidades de ingeniería de tráfico, se admiten las siguientes funciones en un dominio MPLS:

• Posibilidad de establecer una ruta conmutada por etiquetas utilizando una ruta explícita completa o parcial (RFC 3209).

• Establecimiento de LSP basado en restricciones sobre vínculos que cumplen requisitos, como el ancho de banda y las propiedades del vínculo.

• Control de punto de conexión, que se asocia con el establecimiento y la administración de túneles LSP en los enrutadores de entrada y salida.

• Administración de vínculos, que administra los recursos de vínculos para realizar un enrutamiento con reconocimiento de recursos de los LSP de ingeniería de tráfico y para programar etiquetas de MPLS.

• Reenrutamiento rápido (FRR) de MPLS, que administra los LSP que necesitan protección y asigna información de túnel de respaldo a estos LSP.

Limitaciones actuales de RSVP-TE de MPLS

Aunque las extensiones de RSVP para ingeniería de tráfico permiten una mejor utilización de la red y cumplen con los requisitos de las clases de tráfico, el conjunto de protocolos RSVP-TE de MPLS actual tiene varios problemas inherentes a su naturaleza distribuida. Esto causa una serie de problemas durante la contención por la capacidad de bisección, especialmente dentro de una clase de prioridad de LSP donde un subconjunto de LSP comparte una configuración común y mantiene valores de prioridad. Las limitaciones de RSVP-TE incluyen:

• Falta de visibilidad de las demandas individuales de ancho de banda por LSP y por dispositivo: los enrutadores de entrada en una red RSVP-TE de MPLS establecen LSP sin tener una vista global de la demanda de ancho de banda en la red. La información sobre el uso de los recursos de red solo está disponible como capacidad total reservada por clase de tráfico y por interfaz. El estado de LSP individual está disponible localmente en cada etiqueta de enrutador de borde (LER) solo para sus propios LSP. Como resultado, surgen una serie de problemas relacionados con el patrón de demanda, particularmente dentro de una configuración común y tener prioridad.

• Naturaleza asíncrona e independiente de la señalización de RSVP: en RSVP-TE, las restricciones para el establecimiento de rutas las controla un administrador. Como tal, el ancho de banda reservado para un túnel LSP lo establece el administrador y no implica automáticamente ningún límite en el tráfico enviado a través del túnel. Por lo tanto, el ancho de banda disponible en un vínculo de ingeniería de tráfico es el ancho de banda configurado para el vínculo, excluyendo la suma de todas las reservas realizadas en el vínculo. Por lo tanto, las demandas no señalizadas en un túnel de LSP conducen a la degradación del servicio del LSP que requiere exceso de ancho de banda, así como de los otros LSP que cumplen con los requisitos de ancho de banda del vínculo de ingeniería de tráfico.

• LSP establecidos según opciones de ruta explícita o dinámica en el orden de preferencia: los enrutadores de entrada en una red RSVP-TE de MPLS establecen LSP para demandas según el orden de llegada. Dado que los enrutadores de entrada no tienen una vista global de la demanda de ancho de banda en la red, usar el orden de preferencia para establecer los LSP puede hacer que el tráfico se caiga o que los LSP no se establezcan en absoluto cuando hay un exceso de demanda de ancho de banda.

Como ejemplo, la figura 2 está configurada con MPLS RSVP-TE, en el que A y G son los enrutadores de borde de etiqueta (LER). Estos enrutadores de entrada establecen LSP de forma independiente según el orden de las demandas y no tienen conocimiento ni control sobre los LSP de los demás. Los enrutadores B, C y D son enrutadores intermedios o de tránsito que se conectan a los enrutadores de salida E y F.

Figura 2: Ejemplo de ingeniería de tráfico MPLS

Los enrutadores de entrada establecen LSP según el orden en que llegan las demandas. Si el enrutador G recibe dos demandas de capacidad 5 cada una para G-F, G señala a dos LSP (LSP1 y LSP2) a través de G-B-D-F. De la misma manera, cuando el enrutador A recibe la tercera demanda de capacidad 10 para A-E, entonces envía una señal a un LSP, LSP3, a través de A-B-C-E. Sin embargo, si la demanda del LSP A-E aumenta de 10 a 15, el enrutador A no puede señalar LSP3 utilizando la misma ruta (A-B-C-E), ya que el vínculo B-C tiene una capacidad menor.

El enrutador A debería haber señalado el aumento de la demanda en LSP3 mediante la ruta A-B-D-C-E. Dado que LSP1 y LSP2 han utilizado el vínculo B-D según el orden de las demandas recibidas, LSP3 no se señaliza.

Por lo tanto, aunque se dispone de un ancho de banda de flujo máximo adecuado para todos los LSP, LSP3 está sujeto a una degradación del servicio potencialmente prolongada. Esto se debe a la falta de visibilidad de la demanda global del enrutador A y a la falta de coordinación sistémica en la colocación de la demanda por parte de los enrutadores de entrada A y G.

Uso de una entidad de computación de ruta externa

Como solución a las limitaciones actuales que se encuentran en el cálculo de la ruta RSVP-TE de MPLS, se requiere una entidad de computación de ruta externa con una visión global de la demanda por LSP y por dispositivo en la red, independientemente de la capacidad disponible.

Actualmente, en una red MPLS RSVP-TE solo se proporciona el cálculo de ruta de enrutamiento basado en restricciones en línea y en tiempo real. Cada enrutador realiza cálculos de enrutamiento basados en restricciones independientemente de los demás enrutadores de la red. Estos cálculos se basan en la información de topología disponible actualmente, información que suele ser reciente, pero no completamente precisa. Las ubicaciones de los LSP se optimizan localmente, según el estado actual de la red. Los túneles RSVP-TE de MPLS se configuran mediante la CLI. Un operador configura el LSP de TE, que luego es señalado por el enrutador de entrada.

Además de las capacidades de ingeniería de tráfico existentes, la funcionalidad RSVP-TE de MPLS se extiende para incluir una entidad de computación de ruta externa, llamada Elemento de cálculo de ruta (PCE). El PCE calcula la ruta de los LSP de TE de los enrutadores de entrada que se configuraron para el control externo. El enrutador de entrada que se conecta a un PCE se denomina cliente de cálculo de ruta (PCC). El PCC está configurado con el protocolo de cliente de cálculo de ruta (PCEP) para facilitar la computación de ruta externa por parte de un PCE.

Para obtener más información, consulte Componentes de la computación de ruta externa.

Para habilitar la computación de ruta externa para los LSP de TE de una PCC, incluya la lsp-external-controller pccd instrucción en los [edit mpls] niveles y [edit mpls lsp lsp-name] jerarquía.

Componentes de la computación de ruta externa

Los componentes que componen un sistema informático de ruta externa son:

• Elemento de cálculo de ruta
• Cliente de cálculo de ruta
• Protocolo de elementos de computación de ruta

Interacción entre un PCE y un PCC usando PCEP

La Figura 3 ilustra la relación entre un PCE, PCC y el rol de PCEP en el contexto de MPLS RSVP-TE.

Figura 3: PCC y RSVP-TE

La comunicación PCE a PCC está habilitada por el PCEP basado en TCP. El PCC inicia la sesión PCEP y permanece conectado a un PCE mientras dure la sesión PCEP.

Una vez establecida la sesión de PCEP, el PCC realiza las siguientes tareas:

1. Sincronización de estado de LSP: el PCC envía información sobre todos los LSP (locales y externos) a todos los PCE conectados. En el caso de los LSP externos, el PCC envía información sobre cualquier cambio de configuración, cambio de RRO, cambio de estado, etc., al PCE.

   Para los LSP iniciados por PCE, no hay ninguna configuración de LSP presente en el PCC. El PCE que inicia el LSP envía los parámetros del LSP al PCC que indicó su capacidad para admitir LSP iniciados por PCE.

   Nota:

   El soporte para LSP iniciados por PCE se proporciona en la versión 13.3 y versiones posteriores de Junos OS.

2. Delegación de LSP: después de sincronizar la información de estado del LSP, el PCC delega los LSP externos a un PCE, que es el principal PCE de estado activo. Solo el PCE principal puede establecer parámetros para el LSP externo. Los parámetros que modifica el PCE principal incluyen el ancho de banda, la ruta (ERO) y la prioridad (configuración y retención). Los parámetros especificados en la configuración local se anulan mediante los parámetros establecidos por el PCE principal.

   Nota:

   Cuando finaliza la sesión de PCEP con el PCE principal, el PCC elige un nuevo PCE principal y todos los LSP delegados al PCE principal anterior se delegan al PCE principal recientemente disponible.

   En el caso de los LSP iniciados por PCE, el PCC crea el LSP utilizando los parámetros recibidos del PCE. El PCC asigna al LSP iniciado por PCE un ID de LSP único y lo delega automáticamente al PCE. Un PCC no puede revocar la delegación de los LSP iniciados por PCE para una sesión PCEP activa.

   Cuando finaliza una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar inmediatamente los LSP iniciados por PCE, delegation cleanup timeout y lsp cleanup timer para evitar la interrupción de los servicios. Durante este tiempo, un PCE con estado activo puede adquirir el control de los LSP aprovisionados por el PCE con errores mediante el envío de una solicitud de creación para el LSP.

   El control sobre los LSP iniciados por PCE se revierte al PCC cuando expira el delegation cleanup timeout. Cuando el delegation cleanup timeout caduca y ningún otro PCE ha adquirido el control sobre el LSP del PCE con errores, el PCC toma el control local del LSP no delegado iniciado por PCE. Más adelante, cuando el PCE de estado activo original o uno nuevo desea adquirir el control de los LSP iniciados por PCE controlados localmente, el PCC delega estos LSP al PCE y el lsp cleanup timer temporizador se detiene.

   Un PCE puede devolver la delegación del LSP iniciado por PCE al PCC para permitir la transferencia de LSP entre PCE. Esto activa el lsp cleanup timer LSP iniciado por PCE. El PCC espera a que caduque el temporizador de limpieza del LSP antes de quitar los LSP iniciados por PCE no delegados del PCE con errores.

   Cuando caduca lsp cleanup timer y ningún otro PCE ha adquirido el control sobre los LSP del PCE con errores, el PCC elimina todos los LSP aprovisionados por el PCE con errores.

   Nota:

   De conformidad con draft-ietf-pce-stateful-pce-09, la revocación de las delegaciones de LSP iniciadas por PCE por parte de un PCC se produce de forma previa a la desconexión antes de que los LSP se vuelvan a delegar a un PCE alternativo. A partir de la versión 18.1R1 de Junos OS, el lsp-cleanup-timer debe ser mayor o igual que el delegation-cleanup-timeout para que el PCC revoque las delegaciones del LSP. De lo contrario, el intervalo de tiempo de espera de redelegación para el PCC se puede establecer en infinito, donde las delegaciones de LSP a ese PCE permanecen intactas hasta que el PCC realice una acción específica para cambiar los parámetros establecidos por el PCE.

3. Señalización de LSP: al recibir uno o más parámetros de LSP del PCE de estado activo principal, el PCC vuelve a enviar una señal al LSP de TE según la ruta proporcionada por el PCE. Si el PCC no puede configurar el LSP, notifica al PCE del error de configuración y espera a que el PCE principal proporcione nuevos parámetros para ese LSP y, luego, vuelve a señalizarlo.

   Cuando el PCE especifica una ruta que está incompleta o tiene saltos sueltos en los que solo se especifican los puntos finales de la ruta, el PCC no realiza un enrutamiento local basado en restricciones para averiguar el conjunto completo de saltos. En su lugar, el PCC proporciona RSVP con la ruta proporcionada por PCE, tal cual, para la señalización, y la ruta se configura mediante el enrutamiento salto a salto de IGP.

Teniendo en cuenta la topología utilizada en la Figura 2, la Figura 4 ilustra la implementación parcial de PCE del lado del cliente en la red habilitada para MPLS RSVP-TE. Los enrutadores de entrada A y G son los PCC que están configurados para conectarse al PCE de estado externo a través de una conexión TCP.

El PCE tiene una visión global de la demanda de ancho de banda en la red y realiza cálculos de rutas externas después de buscar la base de datos de ingeniería de tráfico. A continuación, el PCE de estado activo modifica uno o varios atributos del LSP y envía una actualización al PCC. El PCC utiliza los parámetros que recibe del PCE para volver a señalar el LSP.

Figura 4: Ejemplo de PCE para MPLS RSVP-TE

De esta manera, el PCE con estado proporciona una operación cooperativa de funcionalidad distribuida que se utiliza para abordar desafíos específicos del cálculo de la ruta restringida entre dominios más corta. Elimina los escenarios de congestión en los que los flujos de tráfico se asignan de manera ineficiente a los recursos disponibles, lo que provoca la sobreutilización de algunos subconjuntos de recursos de red, mientras que otros recursos permanecen subutilizados.

Comportamiento de LSP con computación externa

• Tipos de LSP
• Modo de control de LSP

Instrucciones de configuración admitidas para computación externa

En la tabla 1 se enumeran los MPLS y las instrucciones de configuración de LSP existentes que se aplican a un LSP controlado por PCE.

El resto de las instrucciones de configuración del LSP son aplicables de la misma manera que para los LSP existentes. Al configurar cualquiera de las instrucciones de configuración anteriores para un LSP controlado por PCE, se genera un mensaje de registro de MPLS para indicar cuándo se aplican los parámetros configurados.

Protección LSP controlada por PCE

Las rutas de protección, incluidos los LSP de reenrutamiento rápido y de omisión, son calculadas localmente por la PCC mediante enrutamiento basado en restricciones. Un PCE con estado especifica solo la ruta principal (ERO). Un PCE también puede activar una ruta secundaria no en espera, incluso si la configuración local no tiene una ruta secundaria no en espera para la protección del LSP.

LSP ERO controlado por PCE

En el caso de los LSP controlados por PCE (LSP delegados por PCC y LSP iniciados por PCE), solo se debe enviar un objeto de ruta explícita (ERO) completo desde el PCE al PCC; de lo contrario, el PCC rechaza el mensaje PCUpdate o PCCreate para esa sesión de PCEP.

A partir de la versión 17.2 de Junos OS, además de external cspf, se introducen dos nuevos tipos de cálculo de ruta para los LSP controlados por PCE: local cspf y no cspf.

• local cspf—Un PCC utiliza el local cspf tipo de cálculo solo cuando el PCE envía un TLV de proveedor Juniper (número de empresa: 0x0a4c) de tipo 5.

• no cspf—Ni el PCE ni el PCC realizan un cálculo de ruta restringida. Los puntos de conexión y las restricciones se proporcionan al módulo RSVP para configurar el LSP con la ruta del IGP.

  Un PCC utiliza no cspf el tipo de cálculo en los siguientes casos:

  • Cuando el PCE envía local cspf el TLV y cuando la configuración de Junos OS o la plantilla coincidente para este LSP se incluyen no-cspf en el LSP delegado por PCC.

  • Cuando el PCE envía local cspf TLV y cuando la plantilla de configuración de Junos OS para este LSP se incluye no-cspf en el LSP iniciado por PCE.

  • Cuando el PCE no envía local cspf TLV con un ERO vacío o un ERO suelto (con un bit suelto establecido en el objeto ERO).

Con estos nuevos tipos de cálculo, un PCC puede aceptar un objeto ERO como un ERO suelto o como un ERO vacío. Una entidad de informática de ruta externa que no es capaz de calcular una ruta puede modificar parámetros como el ancho de banda y el color, en función de los análisis. En tales casos, se utiliza un objeto ERO vacío o un ERO suelto y el PCC decide el camino a seguir.

LSP de RSVP-TE de punto a multipunto controlado por PCE

Después de establecer una sesión PCEP entre un PCE y un PCC, el PCC informa de todos los LSP del sistema al PCE para la sincronización del estado del LSP. Esto incluye LSP punto a punto controlados por PCC, delegados por PCE e iniciados por PCE. A partir de Junos OS versión 15.1F6 y 16.1R1, esta capacidad se extiende para informar también de LSP de punto a multipunto. Para un PCE, el LSP de punto a multipunto es similar al del LSP de punto a multipunto RSVP, donde el LSP de punto a multipunto se trata como una colección de LSP de punto a punto agrupados bajo un identificador de punto a multipunto.

De forma predeterminada, el control PCE de LSP punto a multipunto no se admite en una PCC. Para agregar esta capacidad, incluya la p2mp-lsp-report-capability instrucción en los niveles o [edit protocols pcep pce-group group-id] [edit protocols pcep pce pce-name] jerarquía. Después de configurar la capacidad de informe punto a multipunto en un PCC, el PCC anuncia esta capacidad al PCE. Si el PCE anuncia la misma capacidad de informe punto a multipunto a cambio, el PCC informa del árbol LSP punto a multipunto completo al PCE para la sincronización del estado del LSP.

Un PCC con la capacidad de LSP de TE de punto a multipunto admite la generación de informes de LSP de TE de punto a multipunto para PCE de estado, actualización de punto a multipunto y base de datos de LSP que admita el nombre de LSP de punto a multipunto como clave. Sin embargo, las siguientes características y funciones no son compatibles con Junos OS versión 15.1F6 y 16.1:

• LSP estáticos de punto a multipunto

• LSP de punto a multipunto delegados por PCE e iniciados por PCE

• Ancho de banda automático

• TE++

• Mensaje de solicitud y respuesta de PCE

• Creación de LSP de punto a multipunto mediante plantillas

• Configuración de la entrada directa en los LSP de punto a multipunto iniciados por PCE

• Configuración de la entrada directa en el enrutador que apunta a un LSP aprovisionado.

LSP punto a punto iniciados por PCE

A partir de Junos OS versión 16.1, la funcionalidad PCEP se extiende para permitir que un PCE con estado inicie y aprovisione LSP de ingeniería de tráfico a través de un PCC. Anteriormente, los LSP se configuraban en la PCC y la PCC delegaba el control sobre los LSP externos a una PCE. La propiedad del estado LSP fue mantenida por el PCC. Con la introducción de los LSP iniciados por PCE, un PCE puede iniciar y aprovisionar un LSP punto a punto de ingeniería de tráfico dinámicamente sin la necesidad de un LSP configurado localmente en el PCC. Al recibir un mensaje PCCreate de un PCE, el PCC crea el LSP iniciado por PCE y lo delega automáticamente al PCE.

De forma predeterminada, una PCC rechaza la solicitud de aprovisionamiento de LSP punto a punto iniciados por PCE desde una PCE. Para habilitar la compatibilidad de los LSP iniciados por PCE en la PCC, incluya la instrucción lsp-provisioning en los [edit protocols pcep pce pce-id] niveles de jerarquía o [edit protocols pcep pce-group group-id] .

Un PCC indica su capacidad de admitir LSP punto a punto iniciados por PCE mientras establece la sesión del Protocolo de elemento de cálculo de ruta (PCEP) con el PCE. Un PCE selecciona un PCC con esta capacidad para iniciar un LSP. El PCE proporciona al PCC los parámetros LSP iniciados por PCE. Al recibir los parámetros del LSP punto a punto iniciados por PCE, el PCC configura el LSP, asigna un ID de LSP y lo delega automáticamente al PCE.

Cuando el PCE que inicia el LSP no proporciona los parámetros del LSP punto a punto iniciados por PCE, el PCC utiliza los parámetros predeterminados. También se puede configurar una plantilla de LSP opcional para especificar valores para el LSP punto a punto iniciado por PCE cuando el PCE no proporciona los parámetros del LSP. Para configurar una plantilla de LSP para LSP punto a punto iniciados por PCE en el PCC, incluya la instrucción label-switched-path-template en el nivel de [edit protocols mpls lsp-external-controller lsp-external-controller] jerarquía.

Cuando finaliza una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar inmediatamente los LSP iniciados por PCE,delegation cleanup timeout y lsp cleanup timerpara evitar la interrupción de los servicios. Durante este tiempo, un PCE con estado activo puede adquirir el control de los LSP aprovisionados por el PCE con errores.

Un PCE puede devolver la delegación del LSP punto a punto iniciado por PCE al PCC para permitir la transferencia de LSP entre PCE. El control sobre los LSP iniciados por PCE se revierte al PCC cuando expira el tiempo de espera de limpieza de delegación. Cuando caduca el tiempo de espera de limpieza de delegación y ningún otro PCE ha adquirido el control sobre el LSP del PCE con errores, el PCC toma el control local del LSP no delegado iniciado por PCE. Más adelante, cuando el PCE de estado activo original o uno nuevo desee adquirir el control de los LSP punto a punto iniciados por PCE controlados localmente, el PCC delega estos LSP al PCE y se detiene el temporizador de limpieza de LSP.

El PCC espera a que caduque el temporizador de limpieza del LSP antes de eliminar los LSP punto a punto iniciados por PCE no delegados del PCE con errores. Cuando caduca el temporizador de limpieza del LSP y ningún otro PCE ha adquirido el control sobre los LSP del PCE con errores, el PCC elimina todos los LSP aprovisionados por el PCE con errores.

A partir de Junos OS versión 21.1R1, admitimos el enrutamiento activo sin paradas (NSR) para los LSP punto a punto y punto a multipunto basados en RSVP iniciados por PCE. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP de RSVP iniciados por PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciado por PCE, con el motor de enrutamiento de respaldo. Durante una conmutación, la sesión PCEP deja de funcionar y se restablece cuando el motor de enrutamiento de respaldo se convierte en el motor de enrutamiento principal. Esto reduce la pérdida de tráfico para el tráfico transportado a través de los LSP de RSVP iniciados por PCE durante los cambios de motor de enrutamiento. Esta función se habilita cuando NSR está configurado.

LSP de bypass iniciado por PCE

• Descripción de los LSP de omisión iniciados por PCE
• Beneficios del LSP de derivación iniciado por PCE
• Comportamiento de los LSP de omisión iniciados por PCE durante un error de sesión de PCEP

LSP de punto a multipunto iniciados por PCE

Con la introducción de los LSP de punto a multipunto iniciados por PCE, un PCE puede iniciar y aprovisionar un LSP de punto a multipunto dinámicamente sin la necesidad de una configuración de LSP local en el PCC. Esto permite al PCE controlar la temporización y la secuencia de los cálculos de ruta punto a multipunto dentro y a través de las sesiones del Protocolo de elemento de computación de ruta (PCEP), creando así una red dinámica que se controla y despliega de forma centralizada.

Para obtener más información, consulte Descripción del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con compatibilidad con LSP de punto a multipunto iniciados por PCE.

LSP SRv6 en PCEP

El enrutamiento por segmentos se puede aplicar tanto al plano de reenvío MPLS como a IPv6. El elemento de cálculo de ruta (PCE) calcula las rutas de SR para el plano de reenvío MPLS y IPv6. El enrutamiento por segmentos para PCEP admite LSP de SR, como LSP de SR iniciados por PCE, creados localmente y delegados en el plano de reenvío IPv6.

Beneficios de los LSP SRv6 en PCEP

• Le permite crear LSP SRv6 iniciados por PCE.
• Delegue los LSP de SRv6 creados en el enrutador al controlador.
• Informe al controlador de los LSP que se crean localmente en el enrutador.
• La programación de red SRv6 ofrece la flexibilidad para aprovechar el enrutamiento por segmentos sin implementar MPLS.

PCEP admite la creación, actualización y eliminación de LSP SRv6 de color y sin color iniciados por PCE. Cuando el LSP SRv6 iniciado por PCE coexiste junto con un LSP SRv6 estático para la misma IP o IP basada en colores, se prefiere la ruta de contribución del LSP de TE SRv6 estático a la ruta de contribución del LSP de TE iniciado por PCE.

Para configurar una sesión PCEP para que sea compatible con SRv6, debe habilitar la srv6-capability instrucción de configuración en los niveles de jerarquía [edit protocols pcep pce pce-id] o [edit protocols pcep pce-group pce-id]. Si la instrucción de srv6-capability configuración está habilitada, también debe habilitar la instrucción de configuración srv6 en el nivel de jerarquía [edit protocols source-packet-routing], de lo contrario, durante la confirmación y el error se mostrarán.

Para configurar SRv6 para SR-TE, debe agregar la instrucción de configuración srv6 en el nivel de jerarquía [edit protocols source-packet-routing].

[Consulte Descripción de la política de SR-TE para túnel SRv6 para obtener más información.

Para configurar la profundidad máxima de la lista de segmentos para el LSP SRv6, debe habilitar la instrucción de maximum-srv6-segment-list-depth configuración en el nivel de jerarquía [edit protocols pcep].

Ancho de banda automático y LSP controlado por PCE

A partir de la versión 14.2R4 de Junos OS, se proporciona compatibilidad con el ancho de banda automático para los LSP controlados por PCE. En versiones anteriores, la opción de ancho de banda automático no se aplicaba a los LSP controlados por PCE, aunque los LSP bajo el control del enrutamiento basado en restricciones y el ancho de banda automático podían coexistir con los LSP controlados por PCE. La recopilación de estadísticas para el ancho de banda automático solo surtía efecto cuando el modo de control de un LSP controlado por PCE cambiaba de externo a local. Esto ocurría en casos como la falta de conectividad con un PCE o cuando un PCE devuelve la delegación de LSP al PCC.

Autenticación TCP-MD5 para sesiones PCEP

Un servidor PCE con estado automatiza la creación de rutas de ingeniería de tráfico en toda la red, lo que aumenta la utilización de la red y permite una experiencia de red programable personalizada con el uso de la comunicación PCEP con un PCC. Un PCC envía informes de LSP a un servidor PCE, y el PCE actualiza o aprovisiona LSP de vuelta al PCC. Los datos enviados a través de una sesión PCEP son cruciales para que un servidor PCE realice computación de ruta externa. Como resultado, un ataque a la comunicación PCEP puede interrumpir los servicios de red. Si se envían mensajes PCEP modificados a un PCC, se pueden configurar LSP inapropiados. De manera similar, si se envían mensajes PCEP alterados a un PCE, el PCE aprende una vista incorrecta de la red.

Teniendo en cuenta la importancia de la comunicación PCEP entre un PCE y un PCC en la ejecución efectiva de las funcionalidades de PCE, la versión 16.1 de Junos OS introduce la característica de proteger una sesión PCEP mediante la autenticación TCP-MD5 según RFC 5440. Esta función protege la comunicación entre un PCE y un PCC a través de una sesión PCEP, que podría estar sujeta a un ataque y puede interrumpir los servicios de red.

Para habilitar el mecanismo de seguridad MD5 para una sesión PCEP, se recomienda definir y enlazar la clave de autenticación MD5 en el nivel de [edit protocols pcep pce pce-id] jerarquía para una sesión PCEP. Sin embargo, también puede usar un llavero predefinido del nivel de [edit security authentication-key-chains key-chain] jerarquía para proteger una sesión PCEP. En este caso, debe enlazar el llavero predefinido a la sesión PCEP en el [edit protocols pcep pce pce-id] nivel jerárquico.

La siguiente configuración se ejecuta en el PCC para establecer una sesión PCEP segura con un PCE:

• Uso de la clave de autenticación MD5:

• Uso del llavero de autenticación predefinido:

Para que las sesiones PCEP seguras se establezcan con éxito, la autenticación MD5 debe configurarse con la clave de autenticación previamente compartida tanto en el servidor PCE como en el PCC. El PCE y el PCC utilizan la misma clave para verificar la autenticidad de cada segmento enviado en la conexión TCP de la sesión PCEP.

Impacto de la implementación de PCE del lado del cliente en el rendimiento de la red

El mantenimiento de una base de datos con estado puede no ser trivial. En un único entorno de PCE centralizado, un PCE con estado simplemente necesita recordar todos los LSP de TE que ha calculado, los LSP de TE que se configuraron realmente (si esto se puede saber) y cuándo se derribaron los LSP de TE. Sin embargo, estos requisitos provocan una sobrecarga sustancial del protocolo de control en términos de estado, uso y procesamiento de red, y optimización de vínculos globalmente en toda la red. Por lo tanto, las preocupaciones de una implementación de PCE con estado incluyen:

• Cualquier mecanismo de sincronización confiable genera una sobrecarga significativa del plano de control. Es posible que los PCE sincronicen el estado comunicándose entre sí, pero cuando los LSP de TE se configuran mediante cálculos distribuidos realizados entre varios PCE, los problemas de sincronización y evitación de condiciones de carrera se hacen más grandes y complejos.

• La sincronización de bases de datos de ingeniería de tráfico fuera de banda puede ser compleja con múltiples PCE configuradas en un modelo de cálculo de PCE distribuido y puede ser propensa a condiciones de carrera, problemas de escalabilidad, etc.

• Los cálculos de rutas que incorporan el estado total de la red son muy complejos, incluso si el PCE tiene información detallada sobre todas las rutas, prioridades y capas.

A pesar de las preocupaciones anteriores, la implementación parcial del lado del cliente del PCE con estado es extremadamente efectiva en grandes sistemas de ingeniería de tráfico. Proporciona una convergencia rápida y beneficios significativos en términos de uso óptimo de recursos, ya que proporciona el requisito de visibilidad global del estado de un LSP de TE y de control ordenado de las reservas de rutas en todos los dispositivos dentro del sistema que se controla.

Beneficios de los LSP de punto a multipunto iniciados por PCE

Cumple con los requisitos de la ingeniería de tráfico de punto a multipunto Colocación de LSP en respuesta a las demandas de aplicaciones a través de la creación y eliminación dinámica de LSP de punto a multipunto, creando así una red dinámica que se controla y despliega de forma centralizada.

Señalización de LSP de punto a multipunto iniciados por PCE

La señalización de los LSP punto a multipunto iniciados por PCE es la siguiente:

• When a new branch is added (Grafting): solo se señala el nuevo sub-LSP de rama y no da como resultado la reseñalización de todo el árbol punto a multipunto.

  Si se produjo algún cambio de topología antes del aprovisionamiento del nuevo sub-LSP, el servidor de computación de ruta (PCS) vuelve a calcular todo el árbol de punto a multipunto y actualiza el LSP de punto a multipunto mediante un mensaje de actualización de PC.

• When a branch is deleted (Pruning): el sub-LSP de rama eliminado se desactiva y no da como resultado la reseñalización de todo el árbol punto a multipunto.

• When a branch sub-LSP parameter is changed—El cambio en los parámetros del sub-LSP, como el objeto de ruta explícito (ERO), el ancho de banda o la prioridad, puede ocurrir debido a la optimización o a petición del usuario. Si hay una solicitud de reseñalización para un sub-LSP, se vuelve a señalar todo el árbol de punto a multipunto y, luego, se produce el cambio a la nueva instancia una vez que las nuevas instancias de todas las ramas están activas.

• When a branch sub-LSP path fails: se notifica un error al PCS para el subLSP de rama con errores. Al recibir el nuevo ERO del PCS, se vuelve a señalar todo el árbol de punto a multipunto junto con el subLSP de rama con errores, y el cambio a la nueva instancia se produce de forma simultánea (MBB).

Comportamiento de los LSP de punto a multipunto iniciados por PCE después de un error de sesión de PCEP

Cuando se produce un error en una sesión de PCEP, los LSP de punto a multipunto iniciados por PCE quedan huérfanos hasta que expire el state timeout temporizador. Una vez que caduca el state timeout temporizador, se limpian los LSP iniciados por PCE.

Para obtener el control de un LSP de punto a multipunto iniciado por PCE después de un fallo de sesión PCEP, el PCE principal o secundario envía un PCInitiate mensaje antes de que caduque el state timeout temporizador.

Configuración de la capacidad de LSP de punto a multipunto iniciada por PCE

De forma predeterminada, la creación y el aprovisionamiento de LSP de punto a multipunto por parte de una PCE no se admiten en una PCC. Para habilitar esta capacidad, incluya las p2mp-lsp-init-capability instrucciones y p2mp-lsp-update-capability en los [edit protocols pcep pce pce-name] niveles de jerarquía o [edit protocols pcep pce-group group-id] .

La p2mp-lsp-init-capability instrucción proporciona la capacidad de aprovisionar LSP RSVP-TE de punto a multipunto mediante un PCE. La p2mp-lsp-update-capability instrucción proporciona la capacidad de actualizar los parámetros LSP de RSVP-TE de punto a multipunto mediante un PCE.

Funciones compatibles y no compatibles para LSP de punto a multipunto iniciados por PCE

Las siguientes características son compatibles con los LSP de punto a multipunto iniciados por PCE:

• Cumplimiento parcial del borrador en Internet draft-ietf-pce-stateful-pce-p2mp (caduca en octubre de 2018), Extensiones de protocolo del elemento de computación de ruta (PCE) para el uso de PCE con estado para rutas conmutadas con etiquetas de ingeniería de tráfico punto a multipunto.

• A partir de Junos OS versión 21.1R1, admitimos el enrutamiento activo sin paradas (NSR) para LSP de punto a multipunto basados en RSVP iniciados por PCE. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP de RSVP iniciados por PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciado por PCE, con el motor de enrutamiento de respaldo. Durante una conmutación, la sesión PCEP deja de funcionar y se restablece cuando el motor de enrutamiento de respaldo se convierte en el motor de enrutamiento principal. Esto reduce la pérdida de tráfico para el tráfico transportado a través de los LSP de RSVP iniciados por PCE durante los cambios de motor de enrutamiento. Esta función se habilita cuando NSR está configurado.

Las siguientes características no son compatibles con los LSP de punto a multipunto iniciados por PCE:

• Delegación de LSP de punto a multipunto controlado localmente.

• Delegación de control de LSP.

• Extensión del protocolo de puerta de enlace interior (IGP) para la detección de PCE dentro de un dominio de enrutamiento IGP.

• Mensajes de solicitud/respuesta.

• Movimiento directo del sub-LSP de rama de un árbol de punto a multipunto a otro.

  Lo mismo se puede lograr eliminando un subLSP de rama del primer árbol punto a multipunto y volviéndolo a agregarlo a otro después de que el mensaje indique la PCReport eliminación del LSP del dispositivo.

• IPv6 no es compatible.

• No se admite la señalización basada en SERO.

• No se admite la función Empty-ERO.

• No se admite la protección de vínculos.

Asignación de LSP de punto a multipunto iniciados por PCE a MVPN

Puede asociar uno o varios flujos de multidifusión MVPN (S,G) a una ruta de conmutación de etiquetas (LSP) de punto a multipunto iniciada por PCE creada dinámicamente. Solo puede especificar tipos selectivos de flujos para que esta característica funcione. Esto incluye:

• Distinguidor de ruta (RD) que se asigna a la instancia de enrutamiento de MVPN.

• (S,G), que es el origen de un paquete de multidifusión y una dirección de grupo de multidifusión de destino. Se utiliza para filtrar el tráfico entrante y asignarlo al túnel.

• LSP punto a multipunto que se utiliza para enviar tráfico que coincide con la especificación de flujo mencionada anteriormente.

Para obtener más información, consulte el borrador de Internet draft-ietf-pce-pcep-flowspec-05 (caduca el 16 de febrero de 2020) Extensión de PCEP para especificación de flujo.

La implementación actual de esta característica no implementa las siguientes secciones del borrador:

• Sección 3.1.2—Publicidad de las capacidades de PCE en el IGP

• Sección 3.2: Mensajes PCReq y PCRep

• Sección 7: La mayoría de las especificaciones de flujo, excepto la distinción de rutasLa implementación actual de esta función no es compatible con las especificaciones de flujo de multidifusión IPv4 no son compatibles.

Para habilitar la asignación de LSP de punto a multipunto iniciados por PCE a MVPN:

• Incluya la pce_traffic_steering instrucción en el nivel de [edit protocols pcep pce pce-id] jerarquía para indicar el soporte de la capacidad de especificación de flujo (también denominada dirección de tráfico) por parte de la PCC.

• Incluya la external-controller instrucción en el [edit routing-instances routing-instance-name provider-tunnel] nivel de jerarquía.

  La presencia de en la configuración de túnel del proveedor para MVPN indica que el controlador externo puede proporcionar el LSP punto external-controller a multipunto y (S,G) para esta instancia de MVPN. Esto permite que el controlador externo configure dinámicamente (S,G) y LSP de punto a multipunto para MVPN.

Tenga en cuenta lo siguiente para asignar LSP de punto a multipunto iniciados por PCE a MVPN:

• Si no habilita la external-controller pccd instrucción para una instancia de MVPN determinada, el proceso PCCD no se configura (S,G) dinámicamente.

• Si deshabilita la external-controller pccd configuración desde la CLI, los flujos de multidifusión aprendidos dinámicamente (S,G) para esa instancia de MVPN en particular se eliminarán y se notificarán al controlador externo.

• Cuando (S,G) ya está configurado desde la CLI, el PCC no puede configurar (S,G) dinámicamente, ya que la configuración local tiene una prioridad más alta.

• Si se aprende dinámicamente un determinado (S,G) del controlador externo y, luego, se configura el mismo (S,G) para la misma instancia de MVPN, se elimina el aprendizaje dinámico (S,G) y se notifica al controlador externo a través del PCC.

• Si el proceso del protocolo de enrutamiento se reinicia, el proceso PCCD vuelve a configurar todos los (S,G).

• Si el proceso PCCD se reinicia, MVPN informa de todos los PCCD configurados (S,G) al controlador externo.

• Si el usuario habilita external-controller pccd para una instancia de MVPN determinada, MVPN solicita el proceso PCCD para configurar (S,G), si está presente.

• Si hay cambios importantes de configuración en una instancia de MPVN determinada, MVPN solicita al proceso PCCD que vuelva a configurar todo (S,G) para esa instancia de MVPN en particular.

• Todas las especificaciones de flujo asociadas con cualquier LSP de punto a multipunto iniciado por PCE deben tener el mismo RD. Durante el inicio de PC, si todas las especificaciones de flujo no tienen el mismo RD, el mensaje de inicio de PC se descarta con un error.

• Puede asociar un LSP punto a multipunto solo con especificaciones de flujo de tipo selectivo; de lo contrario, el mensaje de inicio de PC se elimina con un error.

• Durante la actualización de PC, si todas las especificaciones de flujo no tienen el mismo RD, ya sea debido a una nueva adición de especificación de flujo o debido a una actualización de especificación de flujo existente, entonces el PCC elimina el mensaje de actualización.

• Durante la actualización de PC, si todas las especificaciones de flujo no cumplen con la condición selectiva, ya sea debido a una nueva adición de especificación de flujo o debido a una actualización de especificaciones de flujo existente, el PCC elimina el mensaje de actualización.

• El comportamiento para la asignación de LSP de punto a multipunto iniciado por PCE con la instancia de enrutamiento de MVPN y la asignación de LSP de punto a multipunto estático (configurado localmente) con instancia de MVPN es el mismo a nivel de usuario.

• Un ID de especificación de flujo solo se puede asociar a un LSP de punto a multipunto. Para asociar el mismo RD y (S,G) a varios LSP punto a multipunto, puede agregar varias especificaciones de flujo con diferentes ID y el mismo RD & (S,G).

• Para la dinámica mapeada con PCEP (S,G), el valor de umbral es siempre el valor predeterminado de 0.

• No hay límite en el número de especificaciones de flujo asignadas a un único LSP de punto a multipunto iniciado por PCE.

• La implementación actual de esta función no admite:

  • Informes de estados de reenvío asociados con el LSP de punto a multipunto.

  • Configuración dinámica de túnel de proveedor inclusivo

  • Mapeo para túnel de replicación de entrada MVPN

  • Proceso de protocolo de enrutamiento programable (prpd)

  • Informes de LSP punto a multipunto configurado por la CLI que está asignado a los flujos de multidifusión MVPN (S,G).

Restricciones de computación CSPF distribuidas

Las rutas de LSP de enrutamiento por segmentos se calculan cuando se cumplen todas las restricciones configuradas.

La función de cálculo de CSPF distribuido admite el siguiente subconjunto de restricciones especificadas en el borrador de Internet, draft-ietf-spring-segment-routing-policy-03.txt Enrutamiento por segmentos Política para ingeniería de tráfico:

• Inclusión y exclusión de grupos administrativos.

• Inclusión de direcciones IP de salto sueltas o estrictas.

  Nota:

  Solo puede especificar ID de enrutador en las restricciones de salto sueltas o estrictas. Las etiquetas y otras direcciones IP no se pueden especificar como restricciones de salto sueltas o estrictas en Junos OS versión 19.2R1-S1.

• Número máximo de ID de segmento (SID) en la lista de segmentos.

• Número máximo de listas de segmentos por ruta de enrutamiento de segmentos candidata.

La función de cálculo de CSPF distribuido para LSP de enrutamiento por segmentos no admite los siguientes tipos de restricciones ni escenarios de despliegue:

• LSP de enrutamiento de segmentos entre dominios e ingeniería de tráfico (SR-TE).

• Interfaces no numeradas.

• Múltiples protocolos de enrutamiento, como OSPF, SI-SI y BGP-LS, habilitados al mismo tiempo.

• Cálculo con prefijos o direcciones anycast como destinos.

• Incluir y excluir direcciones IP de interfaz como restricciones.

Algoritmo de cálculo de CSPF distribuido

La función de cálculo de CSPF distribuido para los LSP de enrutamiento por segmentos utiliza el algoritmo de compresión de pila de etiquetas con CSPF.

• Compresión de pila de etiquetas habilitada
• Compresión de pila de etiquetas deshabilitada

Base de datos de computación CSPF distribuida

La base de datos utilizada para el cálculo de SR-TE tiene todos los enlaces, nodos, prefijos y sus características, independientemente de si la ingeniería de tráfico está habilitada en esos nodos de publicidad. En otras palabras, es la unión de la base de datos de ingeniería de tráfico (TED) y la base de datos de estado del enlace IGP de todos los dominios de los que el nodo informático ha aprendido. Como resultado, para que CSPF funcione, debe incluir la igp-topology instrucción en el nivel de [edit protocols isis traffic-engineering] jerarquía.

Configuración de restricciones informáticas de CSPF distribuidas

Puede utilizar un perfil informático para agrupar lógicamente las restricciones informáticas. Las rutas de enrutamiento de segmentos hacen referencia a estos perfiles informáticos para calcular los LSP de enrutamiento de segmentos primario y secundario.

Para configurar un perfil informático, incluya la instrucción compute-profile en el [edit protocols source-packet-routing] nivel jerárquico.

La configuración de las restricciones de cálculo admitidas incluye lo siguiente:

• Administrative groups

  Puede configurar admin-groups en el nivel de [edit protocols mpls] jerarquía. Junos OS aplica la configuración del grupo administrativo a las interfaces de ingeniería de tráfico de enrutamiento de segmentos (SR-TE).

  Para configurar las restricciones informáticas, puede especificar tres categorías para un conjunto de grupos administrativos. La configuración de restricción de cálculo puede ser común a todas las rutas de enrutamiento de segmentos candidatos o puede estar en rutas candidatas individuales.

  • include-any: especifica que cualquier vínculo con al menos uno de los grupos administrativos configurados en la lista es aceptable para que la ruta lo atraviese.

  • include-all: especifica que cualquier vínculo con todos los grupos administrativos configurados en la lista es aceptable para la ruta que se va a atravesar.

  • exclude: especifica que cualquier vínculo que no tenga ninguno de los grupos administrativos configurados en la lista es aceptable para que la ruta lo atraviese.

  Nota: Los grupos administrativos solo se anuncian si:

  • Habilite RSVP en las interfaces.

  • Configure edit protocols isis traffic-engineering advertisement always si no desea habilitar el RSVP.

• Explicit path

  Puede especificar una serie de ID de enrutador en el perfil informático como restricción para calcular las rutas candidatas de SR-TE. Cada salto debe ser una dirección IPv4 y puede ser de tipo estricto o flexible. Si el tipo de salto no está configurado, se utiliza strict. Debe incluir la compute opción bajo la instrucción segment-list al especificar la restricción de ruta explícita.

• Maximum number of segment lists (ECMP paths)

  Puede asociar una ruta de candidato con varias listas de segmentos dinámicas. Las rutas son rutas ECMP, donde cada lista de segmentos se traduce en una puerta de enlace de salto siguiente con peso activo. Estas rutas son el resultado de la computación de rutas con o sin compresión.

  Puede configurar este atributo mediante la maximum-computed-segment-lists maximum-computed-segment-lists opción que se encuentra en la instrucción de configuración compute-profile . Esta configuración determina el número máximo de listas de segmentos de este tipo que se calculan para un LSP principal y secundario determinados.

• Maximum segment list depth

  El parámetro de cálculo de profundidad máxima de lista de segmentos garantiza que, entre las rutas ECMP que satisfagan todas las demás restricciones, como el grupo administrativo, solo se utilicen las rutas que tengan listas de segmentos menores o iguales que la profundidad máxima de lista de segmentos. Cuando se configura este parámetro como una restricción en el perfil de proceso, anula la maximum-segment-list-depth configuración en el nivel de [edit protocols source-packet-routing] jerarquía, si está presente.

  Puede configurar este atributo mediante la maximum-segment-list-depth maximum-segment-list-depth opción que se encuentra en la instrucción de configuración compute-profile .

• Protected or unprotected adjacency SIDs

  Puede configurar el SID de adyacencia protegido o no protegido como una restricción en el perfil informático para evitar vínculos con el tipo de SID especificado.

  Los SID de adyacencia protegida se configuran para indicar que el SID de adyacencia tiene una ruta de respaldo para protección. Esta configuración permite que la red admita un reenrutamiento rápido sin bucles y sin dependencia de topología (TI-LFA) para errores de vínculo o nodo.

  La adyacencia desprotegida indica que no hay rutas de respaldo disponibles, por lo que no se puede garantizar la protección contra fallas de vínculo o nodo. Si existen SID protegidos y no protegidos en un vínculo IGP y no se aplica ninguna protected restricción o unprotected , el cálculo de forma predeterminada usa el SID no protegido.

  Nota: Admitimos la computación local de SR-TE con OSPF como el IGP subyacente para protected los SID de adyacencia y unprotected ADYACENCIA.

• Metric type

  Puede especificar el tipo de métrica en el vínculo que se utilizará para el cálculo. De forma predeterminada, los LSP de SR-TE utilizan métricas de ingeniería de tráfico de los vínculos para el cálculo. La métrica de ingeniería de tráfico para los enlaces se anuncia mediante extensiones de ingeniería de tráfico de los protocolos IGP. Sin embargo, también puede optar por usar la métrica IGP para el cálculo mediante la configuración de tipo de métrica en el perfil de cálculo.

  Puede configurar este atributo mediante la metric-type (igp | te) opción que se encuentra en la instrucción de configuración compute-profile .

Computación de CSPF distribuida

Las rutas candidatas de SR-TE se calculan localmente de manera que satisfagan las restricciones configuradas. Cuando se deshabilita la compresión de pila de etiquetas, el resultado del cálculo de CSPF de múltiples rutas es un conjunto de pilas de SID de adyacencia. Cuando se habilita la compresión de pila de etiquetas, el resultado es un conjunto de pilas de etiquetas comprimidas (compuestas por SID adyacentes y SID de nodo).

Cuando se calculan las rutas secundarias, los vínculos, nodos y SRLG tomados por las rutas primarias no se evitan para el cálculo. Para obtener más información sobre las rutas principales y secundarias, consulte Configurar LSP principales y secundarios.

Para cualquier LSP con un resultado de cálculo incorrecto, el cálculo se vuelve a intentar a medida que cambia la base de datos de ingeniería de tráfico (TED).

Computación Anycast

Puede configurar cualquier IP de difusión como un punto de conexión SR-TE y una restricción de salto de segmento. Para los escenarios de compresión, el cálculo debe incluir un SID de cualquier difusión en el resultado, mientras que para los escenarios sin compresión, debe incluir un SID de adyacencia a todos los nodos de salida.

Interacción entre la computación distribuida de CSPF y las funciones de SR-TE

• Ponderaciones asociadas con las rutas de una política de SR-TE
• Detección de vivacidad BFD
• heredar-etiqueta-de-próximos saltos
• Función de traducción automática

Configuraciones de ejemplo de cálculo de CSPF distribuidas

• Ejemplo 1
• Ejemplo 2
• Ejemplo 3

Beneficios de múltiples rutas para PCEP SR-TE LSP

• Los LSP pueden tener varios conjuntos de ERO en un destino

• Proporciona capacidades de equilibrio de carga mediante la configuración de pesos para ERO individuales

• Se alinea con el borrador de la arquitectura de SR-TE para definir las rutas candidatas

Se admiten las siguientes capacidades de ruta múltiple de PCEP:

• Cuando PCEP para varias rutas está habilitado (predeterminado), puede configurar varias rutas principales (o una secundaria) en una ruta candidata configurada y controlada por PCC.

• Cuando PCEP para varias rutas está deshabilitado, solo puede configurar una ruta principal en una ruta candidata. No se permite la configuración de ruta secundaria.

Si habilita las múltiples rutas PCEP, compute-profile ahora se puede configurar con un número máximo de listas de segmentos (maximum-computed-segment-lists) mayor que 1.

Cuando se habilita la capacidad multirruta PCEP, se permite la configuración de ruta secundaria para una ruta candidata PCC no delegada, el objeto EXPLICIT-ROUTE (EROs) específico de la ruta secundaria se envía al PCE con un indicador de respaldo establecido para la ERO. Las rutas principales no incluyen MULTIPATH-BACKUP-TLV en el mensaje PCRpt. La ruta secundaria incluye MULTIPATH-BACKUP-TLV con un indicador de respaldo establecido.

Se admiten las siguientes funcionalidades de multirruta PCEP:

• Peso multiruta TLV (MULTIPATH-WEIGHT-TLV) en objeto de atributo de ruta (PATH-ATTRIB)

• MULTIPATH-BACKUP TLV en el objeto de atributo de ruta (PATH-ATTRIB) solo para LSP de SR-TE controlados por PCC

• MULTIPATH-CAP TLV en objeto LSP PCEP

• Restringe varias rutas principales y secundarias en la ruta candidata de SR cuando la multirruta PCEP está deshabilitada

• Varias rutas principales y secundarias en la ruta candidata de SR cuando la multirruta PCEP está habilitada para LSP controlados por PCC

• Listas de segmentos calculados máximos (max-computed-segment-lists) más de 1 en perfil de cálculo de SR-TE para LSP delegados e iniciados por PCE

• Múltiples ERO para la ruta candidata iniciada por PCE en SR-TE y en PCCD

• LSP de SRv6

• SR MPLS (IPv4)

• Túneles dinámicos SR MPLS (IPv4)

• Compatibilidad con varios controladores

• Múltiples rutas de ERO para rutas candidatas de color y sin color iniciadas por PCE, configuradas y controladas por PCC, y delegadas con y sin color

• Compatible con versiones anteriores de Paragon Pathfinder. Para que sea compatible con versiones anteriores, debe configurar disable-multipath-capability la instrucción de configuración en el nivel de jerarquía [edit protocols pcep].

• Compatibilidad con código de error por error en la validación de rutas candidatas iniciadas por PCE

  • El total de rutas de subcandidatos por ruta candidata está limitado a 127. En el caso de los LSP iniciados por PCE, si el número de rutas de ERO supera los 127, SR-TE genera ERROR a PCCD (y PCCD envía un mensaje de error de PCEP a PCE) y se rechazan las rutas de ERO correspondientes.

Se admiten los siguientes mensajes de error de PCEP:

Limitaciones

Se aplican las siguientes limitaciones de PCEP:

• No se admiten los siguientes TLV mencionados en el draft-ietf-pce-multirruta-06 :

  • Copia de seguridad de múltiples rutas TLV

  • Ruta de dirección opuesta multirruta TLV

  • Ruta candidata compuesta

• Cuando la capacidad de multirruta está deshabilitada en PCEP, no se permite configurar varias rutas de subcandidato. Sin embargo, en dispositivos Junos sin capacidad de multirruta (versiones de Junos OS anteriores a 22.4R1), se permite la configuración de rutas de subcandidatos múltiples. Cuando el multisegmento PCEP está habilitado (de forma predeterminada), se permiten varias rutas principales para los LSP controlados por PCC con fines de generación de informes. Sin embargo, solo se admite una ruta principal para la ruta de candidato delegado cuando el multisegmento PCEP está habilitado.

• Los grupos de administradores y cualquier otra restricción no recibirán notificaciones a PCE para las rutas candidatas SR-MPLS y SRv6 configuradas y controladas por PCC (con una o varias configuraciones principales). Las rutas de candidatos delegadas e iniciadas por PCE no tienen ningún impacto.

• Cuando la capacidad de multirruta PCEP está habilitada, se permite la configuración de rutas secundarias para rutas candidatas no delegadas. Cuando la capacidad de multirruta PCEP está deshabilitada, no se permite la configuración de ruta secundaria.

• Las rutas candidatas no pueden tener una combinación de LSP delegados e iniciados por PCE.

• No se admiten varias rutas de subcandidatos para una ruta candidata de color iniciada por PCE.

• No se admiten entidades delegadas con varias rutas de subcandidatos en una ruta de candidato.

Configuración

Para permitir que PCCD envíe TLV de capacidad de multirruta en objeto LSP para notificar la lista máxima de segmentos calculados para una ruta candidata específica, incluya la propagate-max-segmentlist instrucción de configuración en el nivel de jerarquía [edit protocols pcep]. De forma predeterminada, el TLV no se envía en el objeto LSP.

Para deshabilitar la sesión de capacidades múltiples de PCEP para todas las PCE, incluya la disable-multipath-capability instrucción de configuración en el nivel de jerarquía [edit protocols pcep].

Puede habilitar las siguientes traceoptions de protocolo para diagnósticos:

• user@host# set protocols pcep traceoptions …

• user@host# set protocols pcep pce pce1 traceoptions …

• user@host# set protocols source-packet-routing traceoptions

Puede utilizar los siguientes comandos show para mostrar el estado de los LSP en PCC:

• user@host> show path-computation-client lsp: muestra el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de cálculo de rutas (PCC).

• user@host> show path-computation-client lsp extensive: muestra un nivel amplio de salida sobre cada LSP conocido: LSP de punto a punto y de punto a multipunto.

• user@host> show path-computation active-pce: muestra el estado de la multirruta en las sesiones.

• user@host> show spring-traffic-engineering lsp detail—Muestra los detalles de entrada de la ingeniería de tráfico de SPRING.

Beneficios de habilitar TLS para sesiones PCEP

• Protege las sesiones de PCEP de ataques como suplantación de identidad (suplantación de identidad PCC o PCE), espionaje (interceptación de mensajes), falsificación y denegación de servicio.

• Aprovecha los beneficios de seguridad de TLS.

Habilitación de TLS en el cliente de computación de ruta (PCC)

Para habilitar TLS en PCC y establecer la sesión PCEPS, establezca la tls-strict instrucción CLI en el nivel de jerarquía [edit protocols pcep].

Después de habilitar la instrucción de configuración tls-strict, se producen los siguientes eventos:

1. Flaps de sesión PCEP. Cualquier conexión TCP existente finaliza y se realiza una reconexión utilizando TLS.

2. PCC establece conexión TCP con el PCE.

3. Los procedimientos TLS se inician mediante el mensaje StartTLS de PCE a PCC y de PCC a PCE. PCC envía el mensaje StartTLS y se inicia el temporizador StartTLSWait . Puede configurar el temporizador StartTLSWait configurando la start-tls-wait-timer seconds instrucción CLI en el nivel de jerarquía [edit protocols pcep pce pce-id].

   Nota:

   El valor recomendado para el temporizador StartTLSWait es de 60 segundos y no debe ser inferior al del temporizador OpenWait . El valor predeterminado del temporizador de OpenWait se establece en 60 segundos.

   • Si PCC recibe el mensaje Abierto en lugar del mensaje StartTLS , el mensaje PCErr con el tipo de error establecido en 1 (error de establecimiento de sesión PCEP) y el valor de error establecido en 1 (recepción de un mensaje abierto no válido o un mensaje no abierto), y la sesión TCP se cierra.

   • Si no se recibe el mensaje StartTLS de PCE, después de que expire el temporizador StartTLSWait , PCC envía un mensaje PCErr con el tipo de error establecido en 25 (falla de PCEP StartTLS ) y el valor de error establecido en 5 (sin mensaje StartTLS (ni PCErr/Open) antes de la expiración del temporizador StartTLSWait ), y la sesión TCP se cierra.

4. Se produce la negociación y el establecimiento de la conexión TLS.

5. El intercambio de mensajes PCEP se inicia según RFC5440.

Actualización de certificados mediante la infraestructura de clave pública (PKI)

La PKI no notifica a PCC sobre la caducidad del certificado. Debe actualizar manualmente el certificado mediante el siguiente comando de la CLI. En este método, debe realizar un seguimiento de la fecha de caducidad del certificado.

Establecer conexión TLS

En los pasos siguientes se describe cómo se establece una conexión TLS (mediante TLS v1.2):

1. Genere certificados para los nodos (dispositivos Junos OS/servidor pce). Puede generar los certificados mediante uno de los siguientes métodos:

   • Método 1: genere el par de claves y la CSR en el dispositivo y envíe esta CSR a la AC para obtener el certificado. Una vez emitido el certificado, se copia en la caja y se instala.

   • Método 2: genere el par de claves y el certificado listo para usar. Tanto el certificado como la clave privada se copian en el dispositivo y se instalan juntos.

2. Cargue la autoridad de certificación (AC) en el PCC para que el certificado del servidor PCE se pueda validar con la AC cargada.

   Nota:

   Las CA se pueden cargar en una jerarquía plana como una AC independiente. Si una AC es una sub-AC de otra AC, la cadena se construye internamente mediante PKI.

   Nota:

   El certificado del servidor debe estar firmado por una AC. No se permiten certificados autofirmados.

3. Active TLS en PCC.

4. La sesión PCEP se establece a través de TLS con el mecanismo de apretón de manos TLS.

5. El servidor PCE escucha el puerto 4189 para las solicitudes de conexión PCC entrantes a través de TLS.

6. PCC inicia la solicitud de conexión al puerto de destino 4189.

7. Al finalizar un apretón de manos de tres vías, el apretón de manos TLS comienza con el uso de los certificados y se realiza la autenticación unidireccional (PCC autentica el certificado de servidor). Tanto el servidor como el cliente esperan el tiempo de StartTLSait para recibir el mensaje de StartTLS . Puede configurar el temporizador StartTLSWait configurando la start-tls-wait-timer seconds instrucción CLI en el nivel de jerarquía [edit protocols pcep pce pce-id].

   Nota:

   El valor recomendado para el temporizador StartTLSWait es de 60 segundos y no debe ser inferior al del temporizador OpenWait . El valor predeterminado del temporizador de OpenWait se establece en 60 segundos.

8. Después de la sesión de apretón de manos TLS correcta, PCC y PCE inician el establecimiento de la sesión PCEP a través de TLS durante la cual se negocian los parámetros de sesión.

   • Si se produce un error en la validación del certificado, PCC finaliza la conexión TCP.

9. El mensaje PCEP se envía a través de una conexión TLS como datos de aplicación.

10. El cifrado y el descifrado se producen tanto en PCC como en PCE después de un apretón de manos TLS exitoso.

11. Cuando se cierra la sesión PCEP, se elimina la sesión TLS.

Descripción del mecanismo básico de protocolo de enlace TLS

El apretón de manos es una serie de mensajes intercambiados entre un servidor y un cliente. Los pasos exactos en el apretón de manos varían según el algoritmo de intercambio de claves, el conjunto de cifrado, etc. Los siguientes son los pasos básicos del mecanismo de apretón de manos TLS:

1. Saludo del cliente: el cliente inicia el apretón de manos enviando este mensaje. Este mensaje contiene la versión de TLS, una lista de algoritmos criptográficos compatibles o un conjunto de cifrado y otros detalles del cliente.

2. Saludo del servidor: el servidor responde al saludo del cliente enviando un mensaje de saludo de Sever. Este mensaje contiene el certificado del servidor, el algoritmo criptográfico seleccionado, el ID de sesión y la clave pública del servidor.

3. Autenticación: el cliente en segundo plano verifica el certificado del servidor con la autoridad de certificación configurada que había emitido el certificado. Tras una verificación exitosa, el cliente confirma que el servidor es genuino y continúa interactuando.

4. Certificado de cliente opcional: si el servidor ha solicitado un certificado al cliente en el mensaje de saludo del servidor, el cliente envía el certificado de cliente (solo en caso de TLS mutuo).

5. Intercambio de claves de cliente: el cliente envía una clave secreta cifrada con la clave pública del servidor (adquirida en el mensaje de saludo del servidor).

6. Descifrar clave secreta: el servidor descifra la clave secreta mediante la clave privada.

7. Client Finished: el cliente envía un mensaje de finalización cifrado con la clave secreta compartida y señala que el apretón de manos se ha completado.

8. Servidor finalizado: el servidor responde con un mensaje de finalización cifrado con la clave secreta compartida y señala que el apretón de manos se ha completado.

9. Intercambiar mensajes: los mensajes después de completar el apretón de manos se cifran simétricamente.

Diagnóstico y validación de TLS para sesiones PCEP

Para diagnósticos, utilice las siguientes instrucciones de CLI traceoptions:

Habilite los registros de PKI con la siguiente configuración y capture el mismo archivo desde /var/log/<filename>

Compruebe el certificado de AC cargado mediante el siguiente comando:

Salida de muestra

A continuación se muestra un ejemplo de salida de show path-computation-client statistics comando:

Este resultado de ejemplo proporciona la siguiente información:

• TLS está habilitado en PCC.

• PCE es compatible con TLS.

• Se establece la sesión TLS. Esto también indica que el certificado del servidor PCE es válido.

• El estado de la sesión de PCEPS está activo y funcionando.

Beneficios de informar sobre la optimización de rutas y las métricas calculadas en PCEP

• Los informes de métricas de optimización de rutas configuradas en PCC ayudan a PCE a ser consciente de las restricciones que se utilizan para el cálculo de rutas.

• Reporte de métricas computadas al PCE. Esto ayuda a PCE a analizar si el LSP requiere una mayor optimización.

Descripción de las métricas de optimización

En la siguiente sección, se describen las métricas de optimización reales y prediseñadas para RSVP y los LSP de SR-TE (SR MPLS) en PCEP.

• LSP RSVP creado localmente
• RSVP delegado LSP
• LSP RSVP iniciado por PCE
• LSP de SR-TE delegado
• LSP de SR-TE iniciado por PCE
• Envío de métricas de optimización en mensajes PCRpt
• Envío de métrica calculada en un mensaje PCRpt
• Incompatibilidad con versiones anteriores para métrica de ruta

Configuración de métricas de optimización para LSP

Puede configurar métricas de optimización (IGP, TE y retraso de ruta) para LSP de RSVP y LSP de SR-TE.

Para configurar las métricas de optimización de IGP, TE y retraso de ruta para LSP de RSVP, incluya la metric-type <igp|te|delay|delay minimum> instrucción CLI en el nivel de jerarquía [edit protocols mpls label-switched-path <lsp-name>].

Para configurar las métricas de optimización de IGP, TE y retraso de ruta para LSP de SR-TE, incluya la metric-type <igp|te|delay|delay minimum> instrucción CLI en el nivel de jerarquía [edit protocols source-packet-routing compute-profile <compute-profile-name>].

Salida de muestra

Puede utilizar los comandos y show path-computation-client lsp extensive la show path-computation-client lsp CLI para mostrar el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de computación de ruta (PCC).

A continuación se muestra un ejemplo de salida de show path-computation-client lsp extensive:

El resultado muestra que el LSP está optimizado con el tipo de métrica IGP. El valor calculado de la métrica IGP es 50. La métrica de ruta instalada en la tabla de rutas es 50.

Beneficios de los túneles SRv6-TE con soporte de microSID en PCEP

• Mejore la ingeniería de tráfico al permitir que el PCE cree y administre túneles SRv6-TE con micro-SID, optimizando el rendimiento de la red y la utilización de recursos.

• Ofrezca un mejor control y visibilidad de red mediante la generación de informes y la delegación de túneles estáticos de SRv6-TE con configuraciones de micro-SID al PCE.

Descripción general

Con la integración de túneles SRv6-TE con soporte para micro-SIDs en PCEP, puede mejorar significativamente las capacidades de ingeniería de tráfico de su red. Esta función le permite informar, delegar y crear túneles SRv6-TE con micro-SID, aprovechando el elemento de cómputo de ruta (PCE) para una mejor optimización y administración de red. Cuando se reportan túneles SRv6-TE estáticos con configuraciones de micro-SID al PCE, se incluyen detalles completos, como la estructura del SID y el comportamiento del punto de conexión, lo que permite al PCE administrar estos túneles eficazmente.

La delegación de túneles SRv6-TE con microSID al PCE permite un control mejorado, ya que el PCE puede administrar las configuraciones de los túneles y optimizar las rutas de enrutamiento dinámicamente. Esta delegación se puede configurar para que ocurra después de la creación, o puede configurarla para combinar la creación y la delegación en una sola confirmación, lo que agiliza el proceso de configuración. Además, el PCE puede iniciar túneles SRv6-TE con micro-SID, lo que garantiza que se realicen comprobaciones adecuadas de la estructura de SID y del comportamiento del punto de conexión, lo que mantiene la integridad y el rendimiento del enrutamiento de su red.

Puede usar los siguientes comandos show para monitorear túneles SRv6-TE:

Estos comandos proporcionan información detallada sobre el estado y la configuración de sus túneles SRv6-TE, lo que le permite solucionar problemas y optimizar según sea necesario. Puede aprovechar completamente las capacidades mejoradas de los túneles SRv6-TE con soporte para microSID en PCEP.