Resumen

  • En el modo de barajado de RFC 5251, el PE de entrada cambia los CPI por PPI dentro de Session y Sender Template, y el PE de salida restituye los CPI.
  • El cliente puede ver una única sesión correcta sin saber qué versión de la PIT decidió el mapeo, qué puerto interno se programó ni si los datos alcanzaron el destino previsto.

Una continuidad fabricada a propósito

El cliente pide una conexión entre dos puertos expresados en su propio lenguaje. La solicitud entra en una red que opera con otra autoridad de nombres y reaparece al otro lado en el lenguaje original. Si se mira solo desde los CE, parece una única sesión punto a punto que nunca abandonó su identidad.

Eso es precisamente lo que persigue el shuffling de RFC 5251. El borde de entrada modifica los objetos RSVP-TE que nombran el origen y el destino. Donde había CPI, identificadores de puerto de cliente, coloca PPI, identificadores de puerto del proveedor. El borde de salida invierte la operación. La sesión lógica permanece; los nombres que la sostienen cambian dos veces.

El mecanismo no es un truco. Evita que el direccionamiento del cliente gobierne la red interna y permite ocultar topología. El error aparece cuando una organización transforma esa continuidad útil en una conclusión más amplia: «la sesión siguió igual, por tanto la conexión física y su resultado también». El protocolo no hace esa promesa.

El mismo número no es la misma identidad

Un CPI nombra el lado del cliente. Un PPI nombra el lado del proveedor. El VPN-PPI representa el puerto del PE dentro del dominio de direcciones que conoce el L1VPN. La asignación de PPI corresponde al proveedor; los administradores del L1VPN gobiernan los CPI y VPN-PPI.

En puertos no numerados se puede reutilizar el mismo índice para PPI y VPN-PPI. La igualdad del número es una comodidad, no una fusión jurídica ni operativa de los espacios. Guardar «puerto 17» sin el tipo, el VPN y el punto de observación produce un dato cómodo e inútil: ya no permite saber qué lado de la traducción se registró.

Las direcciones del canal de control también son locales a un contexto. Deben ser únicas dentro de un L1VPN, pero no entre todos los L1VPN. Por eso la asociación inequívoca entre canal y VPN es parte del hecho. Una dirección aislada no demuestra la identidad global del participante.

La versión de PIT que tomó la decisión

El PE mantiene una Port Information Table específica del VPN. Allí relaciona CPI y PPI, y para sus puertos locales conserva también VPN-PPI. Esa tabla puede proceder de aprovisionamiento o incorporar información descubierta mediante BGP u OSPF según RFC 5195 y RFC 5252.

Sin embargo, descubrir un dato no equivale a usarlo bien. Cuando llega la petición, el PE de entrada selecciona la PIT del L1VPN y resuelve el CPI remoto. Después reescribe Session y Sender Template. El PE de salida consulta su estado y traduce de vuelta antes de entregar la señalización al CE objetivo.

Un recibo que omite la generación de la PIT pierde el punto de decisión. Una fila antigua, un contexto VPN equivocado o un aprovisionamiento defectuoso pueden producir una reescritura perfectamente válida en sintaxis y equivocada en realidad. Por eso la seguridad de la gestión y la configuración sigue siendo decisiva. RFC 5251 aconseja considerar la comprobación del plano de datos ante errores accidentales: el protocolo sabe dónde termina su evidencia.

Ocultar el trayecto no lo hace inexistente

Dentro del proveedor, la señalización lleva PPI. En los extremos, el shuffling debe aplicarse a todos los mensajes RSVP-TE para no crear estados incompatibles. El cliente contempla un LSP y un enlace virtual entre PE. El proveedor contempla los segmentos y recursos que hacen posible esa imagen.

La vista del cliente puede omitir la topología. Record Route y Notification pueden editarse o eliminarse en el borde. No hay nada impropio en proteger la arquitectura interna. Lo impropio sería utilizar la ausencia deliberada de detalles como evidencia de un trayecto simple. Una sesión no significa un salto, una fibra, una longitud de onda ni una ruta inmutable.

Además, shuffling no es la única construcción posible. Los modos de cosido y anidación pueden asociar una sesión PE-a-PE, un LSP existente o una forwarding adjacency con la petición del cliente. RFC 5150 y RFC 4206 describen esas técnicas. Dos servicios con la misma apariencia exterior pueden dejar huellas internas distintas. El modo operativo debe formar parte del expediente.

El Resv confirma menos de lo que parece

El CE originador selecciona un destino que conoce. La política del proveedor limita las topologías permitidas. El PE traduce los identificadores y calcula o completa el camino interno. El CE distante acepta o rechaza. Son decisiones importantes, pero cada una tiene un alcance preciso.

Ni Path ni Resv observan por sí solos la matriz de conexión física. La reserva, el label o la longitud de onda programados, el estado de protección, la continuidad óptica y el tráfico transportado pertenecen a escalones posteriores. Aun una prueba CE-a-CE demuestra solo el patrón enviado y recibido; la latencia, la pérdida, el SLA y el resultado de la aplicación requieren observaciones propias.

Tampoco un Explicit Route Object del cliente lo convierte en autoridad sobre la ruta interna. El PE puede rechazarlo, y cuando acepta una forma laxa sigue calculando e insertando el recorrido del proveedor. La intención del cliente condiciona la prestación; no firma cada decisión de ingeniería.

Un expediente que sobreviva al siguiente cambio

La evidencia debería empezar con L1VPN, canal de control, CPI de origen y destino y solicitud original. Después debe fijar la versión y procedencia de la PIT, los PPI resueltos y los valores de los objetos antes y después de la sustitución. En el otro borde debe conservar la consulta inversa, los CPI restituidos y la respuesta del CE remoto.

En registros separados aparecen el estado RSVP, la programación de recursos, el cruce físico, la prueba del plano de datos y el resultado observado. Un único campo «up» aplana hechos que tienen autoridades distintas. Cuando cambia el aprovisionamiento, ya no permite explicar qué mapeo sostenía una sesión anterior.

El proveedor puede reservar la traza interna a un dominio protegido. Topología oculta no significa evidencia destruida. Tiene que existir una correlación capaz de unir la abstracción comercial con el segmento interno sin exponerlo a quien no corresponde.

La disciplina de capas de realidad de Lu Heng ofrece una prueba sencilla: cada frontera debe decir qué transformó y qué observó. Un CPI no es un PPI. Una traducción aceptada no es un cruce verificado. Una sesión coherente no es todavía la entrega del servicio. La infraestructura se vuelve gobernable cuando deja de pedir a un recibo que hable por todas las capas posteriores.

Fuentes