Resumen

  • RFC 5212 define requisitos para ver y calcular sobre múltiples capas y regiones bajo un plano de control GMPLS. La ruta resultante puede depender de una conexión inferior que todavía debe crearse en la frontera.
  • Un ISCD, un enlace TE virtual o una identidad estable describen posibilidades de control. La evidencia de servicio necesita además asignación de adaptación, LSP servidor, herencia trazable de riesgo, verificación, OAM correlacionado y tráfico cliente observado.

Ver más no significa poseer más

RFC 5212 es informativo: organiza conceptos y requisitos, no prescribe una única solución. Una región corresponde a un tipo de conmutación; una capa, a una granularidad del plano de datos. Puede haber varias capas en una región, mientras que una red multirregión utiliza más de un tipo de conmutación.

La promesa de una TED unificada consiste en reunir enlaces de ingeniería de tráfico de todas esas capas. El cálculo puede elegir recursos de paquetes, capa 2, TDM, longitud de onda o fibra como partes de una decisión conjunta. La fragmentación visual disminuye. Las dependencias materiales no desaparecen.

El propio RFC exige que cálculo y señalización puedan trabajar con información TE parcial. Además, cuando se admite señalización disparada, una ruta puede cruzar capas sin estar todavía conectada en la capa de sus extremos. Se presupone que el nodo fronterizo creará un FA-LSP inferior o elegirá uno existente cuando llegue la solicitud superior.

Por tanto, “ruta calculada” describe una intención viable bajo condiciones. No afirma que esas condiciones hayan ocurrido.

La capacidad anunciada no consume el adaptador

El descriptor ISCD informa de capacidad de conmutación, codificación y características de ancho de banda. En un nodo híbrido, el tráfico también necesita enlaces internos y recursos de terminación o ajuste para pasar de una capa a otra. RFC 5212 pide que su disponibilidad forme parte de las restricciones, precisamente para reducir bloqueos durante el establecimiento.

Conviene conservar cuatro recibos distintos: capacidad funcional, disponibilidad actual, asignación a la solicitud y verificación del enlace creado. Si la frontera separa administraciones, hay un quinto: permiso de política. Un equipo puede soportar la función pero estar lleno; puede tener recursos pero reservarlos para otro cliente; puede asignarlos y aun producir una conexión defectuosa.

La base de datos no ejerce por sí sola ninguna de esas acciones. Da al calculador una representación útil, con la autoridad limitada de su fuente y su instante.

El enlace virtual es una opción explícita

La virtualización evita reservar por adelantado todos los LSP inferiores. RFC 5212 permite anunciar un enlace TE que representa la posibilidad de un LSP subyacente aún no establecido. Al seleccionarlo para un LSP superior, la red debe señalizar inmediatamente la conexión inferior.

Ese diseño no es un engaño. Lo sería borrar la transición entre estados. “Anunciado”, “seleccionado”, “en señalización”, “establecido”, “verificado” y “transportando tráfico” no son sinónimos. Un inventario que los comprime produce una certeza que el protocolo nunca entregó.

La identidad estable tampoco congela la infraestructura. Un FA-LSP puede cambiar de ruta manteniendo el identificador de interfaz del enlace TE. Así se protege a la capa cliente frente al detalle, pero también se altera el conjunto físico de riesgos detrás de un nombre invariable.

Heredar atributos también es gobernar información

Cuando un LSP inferior se presenta como enlace superior, deben heredarse capacidades, métricas, anchos de banda, protección y SRLG. El RFC advierte que la herencia obedece a políticas y que la métrica superior no tiene por qué ser una suma. Ocultar el trayecto inferior puede eliminar información necesaria para juzgar la fiabilidad; el mecanismo detallado de herencia SRLG queda fuera de alcance.

Dos caminos que parecen disjuntos pueden compartir conducto, alimentación o dependencia administrativa. La marca de protección no demuestra independencia si no se conoce la procedencia de sus atributos. La abstracción sigue siendo útil, pero su promesa debe limitarse a lo que realmente conserva.

La reconfiguración de la VNT añade riesgo temporal. Liberar un FA-LSP poco usado o mover tráfico anidado mejora utilización y puede interrumpir la capa superior. Make-before-break reduce la perturbación; no prueba continuidad de la aplicación.

Establecer y verificar responden preguntas diferentes

La sección 5.9 permite verificar conectividad correcta e integridad de datos del LSP inferior antes de ofrecerlo como enlace superior. La prueba concreta depende de la tecnología y queda fuera del RFC, pero GMPLS debería coordinarla.

La separación es decisiva. La señalización acredita el estado de una transacción de control. La verificación acredita propiedades del enlace servidor. El OAM debe mantener significado al cruzar la parte oculta y trasladar hacia arriba alarmas pertinentes. Después, una observación cliente con punto y ventana declarados acredita el resultado del servicio.

Un recibo multicapa debe enlazar generación de solicitud, extremos, transiciones, decisión fronteriza, recursos de ajuste, conversión virtual-real, identidad y reserva del LSP inferior, procedencia de métricas/protección/SRLG, prueba de integridad, alarmas y tráfico cliente. Es una propuesta editorial de BTW, no una obligación inventada para RFC 5212.

El registro no obtiene el poder del sistema

La doctrina de Heng Lu distingue la inscripción administrativa de la realidad operativa y la visibilidad de la autoridad. Una TED puede ser fuente legítima para calcular; no autoriza a otro dominio, no asigna un recurso escaso, no reconstruye riesgos ocultos y no entrega paquetes.

La automatización mejora cuando cada éxito conserva su alcance: cálculo propone, política permite, señalización cambia estado, verificación prueba el enlace y observación mide el servicio. El tablero peligroso celebra el primer verbo como si hubiera conjugado todos los demás.

Fuentes

  1. RFC 5212
  2. Datatracker: RFC 5212
  3. Información de RFC 5212
  4. RFC 5339
  5. Datatracker: RFC 5339
  6. RFC 6001
  7. Datatracker: RFC 6001
  8. RFC 5623
  9. RFC 4202
  10. RFC 4206
  11. RFC 3945
  12. RFC 5146
  13. RFC 4847
  14. RFC 4726
  15. RFC 4802
  16. RFC 4803
  17. RFC 4377
  18. Historial de RFC 5212
  19. Heng Lu — primacía del código en ejecución