RFC 5786-2010
Publicidad de las direcciones locales de un enrutador en las extensiones OSPF Traffic Engineering (TE) (Actualizaciones: 3630)

Estándar No.
RFC 5786-2010
Fecha de publicación
2010
Organización
IETF - Internet Engineering Task Force
Ultima versión
RFC 5786-2010
Alcance
Introducción Motivación En algunos casos@, es deseable configurar primero la ruta más corta restringida (CSPF), conmutación de etiquetas multiprotocolo (MPLS) calculada, rutas conmutadas por etiquetas diseñadas para el tráfico (TE LSP) a direcciones locales de un enrutador que actualmente no se anuncian en los TE LSA. @ es decir, direcciones de interfaz loopback y no TE. Por ejemplo, en una red que transporta tráfico VPN y no VPN, a menudo es deseable utilizar diferentes MPLS TE LSP para el tráfico VPN y el tráfico no VPN. En este caso, se puede usar una dirección de bucle invertido como siguiente salto BGP para el tráfico VPN, mientras que otra puede usarse como siguiente salto BGP para el tráfico que no es VPN. También es posible que se utilicen diferentes sesiones BGP para servicios VPN y no VPN. Por lo tanto, son deseables dos MPLS TE LSP separados, uno para cada dirección de loopback. Sin embargo, los enrutadores actuales en una red OSPF solo pueden usar CSPF para calcular MPLS TE LSP para el ID del enrutador o las direcciones locales de los enlaces habilitados para TE de un enrutador remoto. Esta restricción surge porque las extensiones OSPF TE [RFC3630@ RFC5329] solo anuncian el ID del enrutador y las direcciones locales de los enlaces habilitados para TE de un enrutador determinado. Otros enrutadores de la red pueden completar su base de datos de ingeniería de tráfico (TED) con estas direcciones locales que pertenecen al enrutador publicitario. Sin embargo, no pueden llenar el TED con otras direcciones locales del enrutador publicitario, es decir, direcciones de loopback y de interfaz que no sean TE. Los enlaces de código auxiliar OSPFv2 en el enrutador LSA [RFC2328] proporcionan información de accesibilidad del código auxiliar al enrutador, pero no son suficientes para conocer todas las direcciones locales de un enrutador. En particular, para una interfaz punto a punto (P2P) en subredes, el ID del enlace stub@ es la dirección de subred. Mientras que para una interfaz @ sin subredes, el ID del enlace auxiliar es la dirección del vecino. Los LSA intraprefijo en OSPFv3 [RFC5340] tampoco son suficientes para aprender las direcciones locales. Por las razones anteriores, este documento define una mejora de las extensiones OSPF TE para anunciar las direcciones locales de un nodo.

RFC 5786-2010 Historia

  • 2010 RFC 5786-2010 Publicidad de las direcciones locales de un enrutador en las extensiones OSPF Traffic Engineering (TE) (Actualizaciones: 3630)



© 2023 Reservados todos los derechos.