Resumen

  • RFC 3472 plasmó GMPLS en REQUEST, MAPPING y TLV de CR-LDP; la dirección ascendente podía quedar utilizable antes de volver el mapeo descendente.
  • Una REQUEST reenviada, un Upstream Label válido o tráfico en un sentido eran recibos parciales, no prueba de que el servicio bidireccional estuviera terminado.

La palabra «bidireccional» parece describir una cosa indivisible. RFC 3472 mostró que, durante el establecimiento, sus dos sentidos podían pertenecer a tiempos distintos.

Publicado en enero de 2003 en el cauce de estándares, el documento codificó para CR-LDP las funciones generales de RFC 3471. Definió TLV y procedimientos para solicitudes, etiquetas, bandas, sugerencias, conjuntos, protección, estado e interfaces. RFC 3473 hizo el trabajo paralelo para RSVP-TE.

La REQUEST llevaba un Upstream Label cuando se pedía un LSP bidireccional. Esa etiqueta debía ser válida para reenviar en el instante del envío. Cada receptor comprobaba si podía aceptarla. Antes de propagar la solicitud, cada nodo intermedio tenía que asignar una etiqueta de salida ascendente y establecer el camino interno que unía sus segmentos.

Al alcanzar el terminador, este podía usar inmediatamente la etiqueta y enviar tráfico hacia el iniciador. El otro sentido aún no estaba necesariamente completo. Sus etiquetas generalizadas debían regresar mediante MAPPING, ser aceptadas e instalarse salto por salto.

Por tanto, un estado parcial podía ser correcto: existía tráfico de vuelta, pero el último MAPPING no había llegado al origen. «La REQUEST bidireccional llegó» no demostraba dos direcciones instaladas, continuidad física ni una conversación de aplicación exitosa.

La solicitud generalizada también distribuía controles diferentes. El ingreso fijaba codificación y G-PID; Switching Type podía cambiar en cada salto. Cada nodo comprobaba entrada, capacidad propia y salida o túnel. La política local decidía si podía crear una Forwarding Adjacency. Que el mensaje avanzara no resumía una validación universal.

G-PID se examinaba normalmente en el egreso, salvo el caso PSC/PHP. El silencio de nodos anteriores no era prueba de que la carga cliente ya estuviese admitida.

Suggested Label era deliberadamente débil. Sus errores se ignoraban. Si el receptor devolvía otra etiqueta, el emisor debía reconfigurarse o rechazar. El ingreso no debía enviar datos sobre la mera sugerencia antes de recibir la etiqueta correspondiente. Preparación temprana no equivalía a asignación.

Los Label Sets marcaban opciones, no inventario. Podían incluir o excluir valores y rangos; su ausencia hacía aceptables todas las etiquetas, no disponibles. Cada salto intersectaba el conjunto con sus recursos. Una intersección vacía detenía el procedimiento.

La comparación se hacía sobre recursos físicos. La misma longitud de onda podía tener números lógicos distintos en enlaces diferentes; el nodo debía traducirlos o eliminar la opción. Si podía convertir etiquetas, también podía retirar el conjunto antes de reenviar, de modo que el mensaje final no conservaba todas las restricciones anteriores.

Una banda reflejada exigía intercambiar etiquetas inicial y final. En un túnel bidireccional el cambio se hacía en ambos sentidos. Un intervalo aparentemente idéntico no certificaba idéntica asociación de longitudes de onda.

Explicit Label Control exigía que Label ER-Hop siguiera a su dirección o identificador de interfaz. Orden o bits incoherentes producían errores. Cómo obtenía el extremo esa información quedaba fuera del alcance.

Con control y datos separados, IF_ID nombraba canales físicos y volvía en MAPPING. La pérdida de señalización fuera de fibra no debía afectar conexiones ópticas existentes. Recuperar la sesión tampoco probaba que el cruce antiguo fuese correcto.

CR-LDP carecía de la notificación rápida propia de RSVP. RELEASE y WITHDRAW se expandían desde el fallo y liberaban recursos. Al eliminar el LSP, ambas etiquetas quedaban inválidas; tráfico posterior sería estado obsoleto, no continuidad autorizada.

RFC 3468 registró después la decisión del IETF de abandonar el desarrollo estándar de CR-LDP en favor de RSVP-TE. La decisión explica la trayectoria institucional, no borra la mecánica ni demuestra una retirada instantánea.

La primacía del código de Heng Lu exige observar el efecto. La especificación mínima deja política y tecnología donde corresponden. Las capas de realidad separan admisión, asignación, conexión interna, mapeo, tráfico y aplicación.

El registro completo conserva REQUEST, la decisión de cada salto, las asignaciones ascendentes, la aceptación terminal, el primer tráfico, cada MAPPING descendente, mediciones en ambos sentidos y la retirada. Solo esa secuencia convierte «bidireccional» de intención protocolaria en servicio comprobado.

Fuentes