Resumen

  • RFC 3038 resolvió una discordancia concreta: VPI/VCI identificaba un enlace ATM y podía cambiar en el siguiente salto, mientras dos ATM-LSR vecinos necesitaban reconocer el mismo VC al intercambiar información LDP.
  • En el procedimiento punto a punto intrabanda, PROPOSE no bastaba. Un ACK que coincidiera y la posterior petición LDP cerraban el intercambio de tres mensajes antes de que el mapeo llevara el VCID.

Un circuito; varios nombres locales

En enero de 2001, el conjunto de estándares MPLS buscaba incorporar conmutadores ATM como routers de conmutación por etiquetas. El hardware ya encaminaba celdas mediante los campos VPI y VCI. Sin embargo, esos campos identificaban el salto local, no necesariamente un circuito con un nombre invariable de extremo a extremo: cada conmutador podía sustituirlos al reenviar las celdas al siguiente enlace. Para LDP, por tanto, el VPI/VCI que veía un vecino no era siempre una identidad suficiente para asociar el circuito virtual que ambos coordinaban.

RFC 3038 añadió un segundo nombre: el identificador de conexión virtual, VCID. La condición central era que ambos extremos del VC usaran el mismo valor. No reemplazaba los labels ATM usados para transportar celdas ni convertía cada VPI/VCI en un identificador global. Permitía que dos ATM-LSR adyacentes vincularan sus respectivos labels locales de entrada o salida con una identidad compartida y luego la incluyeran en la información de LDP.

El orden importa. El documento parte de un VC que ya se estableció mediante señalización o administración. La notificación no crea el circuito: sincroniza cómo lo reconocen los dos nodos vecinos. Después pueden venir la petición y el mapeo LDP. El establecimiento del VC, el label local, la asociación al VCID, el mapeo distribuido y el tráfico que efectivamente atraviesa el camino son hechos diferentes. Ninguno, por sí solo, demuestra recepción por una aplicación.

Por qué el ACK no cerraba la negociación

Para un VC punto a punto intrabanda, el nodo upstream elegía un VCID y enviaba un mensaje VCID PROPOSE con un identificador de mensaje por el circuito recién establecido. Cada extremo asociaba ese VCID con su label local. El downstream devolvía un ACK con el VCID y el identificador que había recibido; el upstream debía comprobar que ambos coincidían. Si no llegaba la confirmación esperada dentro del intervalo previsto, retransmitía la propuesta.

Después del ACK venía un tercer mensaje: el upstream enviaba una petición LDP que contenía el identificador de mensaje. El downstream tomaba esa petición como prueba de que el upstream había recibido su ACK. RFC 3038 explica que hacen falta los tres mensajes porque PROPOSE viaja de manera no fiable. El downstream puede saber que envió el ACK, pero no que el otro extremo lo recibió. Hasta que llegara REQUEST, debía descartar por ese VC los paquetes que no fueran el propio VCID PROPOSE.

Concluido el intercambio, el mensaje LDP Mapping podía incluir el VCID en el Label TLV. La secuencia establece una asociación de plano de control entre vecinos; no es una confirmación de éxito de aplicación. Tampoco muestra que cada conmutador de un trayecto más largo acordara la misma asociación ni que hubiera pasado tráfico de usuario.

El tipo de conexión cambiaba el procedimiento

RFC 3038 no ordenó la misma ceremonia para todos los casos. Un enlace punto a punto transparente, con el mismo VPI/VCI en ambos extremos, no necesitaba notificación. Un virtual path podía usar notificación intrabanda o el procedimiento VPID; en el caso limitado de un único VP hacia el vecino, un VCI común podía bastar. Un PVC usaba la vía intrabanda. Para un SVC, la señalización podía incluir el VCID en un campo suficientemente amplio, recurrir a un campo temporal menor o utilizar un mensaje intrabanda.

La dirección también era relevante. El extremo upstream iniciaba la notificación. Una conexión bidireccional requería una secuencia para cada sentido; una unidireccional, solo para el sentido permitido. La norma trataba la identidad como una relación que debía acordarse entre cada par de vecinos pertinente, no como un nombre mágico visible en toda la nube ATM.

El campo pequeño muestra la diferencia entre correlación temporal y asociación duradera. El campo específico de usuario de BLLI podía identificar provisionalmente un circuito durante la señalización. No se debía reutilizar con otra transacción incompleta frente al mismo vecino; después de completar la asociación VCID, el BLLI quedaba disponible de nuevo. En multipunto, BLLI era único en el emisor, no necesariamente en el receptor, que además debía usar la dirección ATM del emisor para distinguirlo. El token escaso solo se podía reciclar después de una transición verificable.

El procedimiento VPID ofrecía otra opción para un virtual path: formar el VCID a partir del VPID y el VCI, sin negociar un VCID por separado para cada VC. El estándar mencionaba el uso multipunto como algo futuro y decía que la especificación LDP de entonces no admitía multicast. También advertía que, en un switch sin VC-merge, añadir una hoja podía exigir dividir temporalmente un LSP para enviar el mensaje intrabanda, con posibles efectos de rendimiento y QoS. Son restricciones de diseño descritas, no mediciones de despliegue.

Una frontera histórica precisa

RFC 3033, publicado ese mismo mes, definía identificadores tipados de recursos y sesiones para la señalización ATM. Su objeto era distinto del VCID de RFC 3038, que conciliaba labels locales entre vecinos LDP una vez establecido el VC. Las FEC de RFC 3036 y la arquitectura MPLS general pertenecían a otras capas. Mantener esa separación evita convertir la palabra «identificador» en sinónimo de establecimiento, clasificación, reenvío y entrega.

El RFC Editor clasifica RFC 3038 como Proposed Standard e indica que RFC 7274 lo actualiza. Este último trata la asignación y retirada de labels MPLS de propósito especial y actualiza el uso terminológico antiguo de «reserved label»; no borra la negociación VCID. Ninguno de esos documentos nombra una implementación operativa, cuenta adopciones ni publica pruebas de interoperabilidad. La conclusión defendible es más estrecha: si la etiqueta ATM podía ser local a un salto, el plano de control MPLS necesitaba una identidad común entre pares y la norma hacía observable el acuerdo mediante un intercambio explícito.

Fuentes

Los ensayos de Heng Lu se identifican únicamente como marcos analíticos; Lu no escribió ni respaldó RFC 3038.