Resumen
- RFC 2105 documentó una arquitectura Informational de Cisco: una etiqueta corta y fija indexaba la Tag Information Base, se cambiaba en cada salto y determinaba la interfaz y la información de enlace de salida.
- OSPF, BGP u otros protocolos formaban primero la FIB; la asignación y distribución convertían ese resultado en estado ejecutable, incluso antes de que llegara tráfico.
- La misma primitiva servía al encaminamiento por destino, multicast, jerarquía, rutas explícitas, ATM y QoS, pero la etiqueta solo acreditaba una asociación local, no consenso normativo, identidad, autorización, entrega ni verdad de extremo a extremo.
La operación más visible era la última
El mecanismo básico de RFC 2105 era deliberadamente pequeño. Ante un paquete etiquetado, el equipo buscaba una coincidencia exacta en la TIB. La entrada contenía la etiqueta de llegada y una o varias ternas de etiqueta de salida, interfaz e información de nivel de enlace. El conmutador reemplazaba esos valores y transmitía.
Una comparación corta resultaba más sencilla que repetir una búsqueda de prefijo más largo. Podía implementarse en hardware y funcionar igual para una salida unicast o varias salidas multicast. La velocidad no nacía de saber más, sino de reutilizar una decisión anterior.
Por eso un cambio correcto de etiqueta tiene un alcance probatorio reducido. No revela qué ruta originó la entrada, qué vecino la anunció, si ese vecino sigue siendo el siguiente salto, quién autorizó una ruta explícita ni si el paquete llegó. La etiqueta era un identificador de ejecución local, no una crónica del camino.
El plano rápido quedó separado del control que evoluciona
Tag Switching distinguía dos componentes. El de reenvío repetía la búsqueda, sustitución y salida. El de control creaba asociaciones y las distribuía. Añadir una función de encaminamiento podía significar añadir un módulo de control sin rediseñar la maquinaria de reenvío.
La decisión protegía la inversión en el camino rápido y permitía incorporar destino, multicast, jerarquía o ingeniería de tráfico. También impedía confundir recibos. Que el hardware ejecute una TIB con precisión no demuestra que el módulo creador tuviera información reciente, que la distribución hubiera convergido o que la política fuera legítima. El plano de datos puede ejecutar fielmente una intención caducada.
El encaminamiento construía primero el objeto
Para el tráfico basado en destino, un tag switch seguía participando en OSPF y BGP y construía una FIB. La RFC ofrecía asignación aguas abajo, aguas abajo bajo demanda y aguas arriba. En el modo ordinario aguas abajo, cada ruta de la FIB provocaba una etiqueta, una entrada TIB y el anuncio de la asociación a los vecinos.
Un equipo que recibía la asociación originada por el siguiente salto colocaba esa etiqueta en el campo de salida correspondiente. El intercambio podía viajar junto a un protocolo de encaminamiento o mediante el TDP propuesto. Cuando la entrada y la salida estaban completas, el algoritmo de sustitución podía reenviar.
El orden evita una inferencia tentadora: la etiqueta no anunciaba por sí sola una ruta. Era la proyección local de una alcanzabilidad ya calculada. Tampoco TDP era LDP anticipado en todos sus detalles. RFC 5036 especificó después otro protocolo, con descubrimiento, sesión, mensajes y fallos propios.
La topología podía llenar la TIB antes del tráfico
En vez de esperar a detectar un flujo, RFC 2105 permitía que la existencia de una ruta en la FIB desencadenara la asignación. La propia RFC llamaba al proceso impulsado por la topología y no por el tráfico.
Así, el estado crecía con las rutas y no con cada conversación. Una etiqueta podía representar un prefijo o un conjunto de rutas. No era necesario clasificar todos los flujos ni permitir que una ráfaga creara una explosión de estado de control.
La precomputación no garantizaba vigencia. La asociación seguía ligada a una versión de ruta, a un siguiente salto, a una vecindad y a una época de distribución. Una TIB obsoleta podía contestar con gran eficiencia a una pregunta que la topología ya había cambiado.
La capa de red seguía apareciendo donde faltaba contexto
Un paquete sin etiqueta necesitaba un reenvío ordinario de red antes de recibir la primera. La tarea correspondía al primer router o al primer nodo del trayecto capaz de participar en Tag Switching.
La agregación también imponía una excepción. Si varias rutas comprimidas bajo una etiqueta no compartían el siguiente salto, el equipo debía volver a examinar el destino. La etiqueta común había borrado una diferencia necesaria para la decisión siguiente.
El camino rápido, por tanto, no eliminaba la interpretación. Evitaba repetirla mientras el contexto siguiera siendo suficiente. En el ingreso y en determinados puntos de agregación, la cabecera de red volvía a ser la fuente de la pregunta.
Una pila trasladaba el conocimiento exterior a los bordes
RFC 2105 propuso una pila de etiquetas para que los nodos interiores no conservaran toda la información exterior. Al entrar en un dominio, el conmutador de borde empujaba una etiqueta interior encima de la que ya llevaba el paquete. El núcleo usaba la superior para llegar a la salida; la inferior quedaba preparada para la decisión en el borde. La etiqueta superior se retiraba allí o en el penúltimo salto.
La pila distribuía conocimiento de forma selectiva. Sin embargo, no era un registro de viaje. Cada valor tenía significado en un ámbito local distinto. Ver ambos no mostraba los mensajes de control, las alternativas descartadas ni las convergencias que precedieron al paquete.
El mismo reenvío admitía controles distintos
En multicast, un protocolo como PIM construía primero un árbol compartido o de fuente. El módulo asociaba después etiquetas locales a las interfaces de salida y creaba una entrada TIB con varias salidas. La etiqueta ejecutaba el árbol; no descubría receptores ni acreditaba entrega.
Las rutas explícitas permitían instalar asociaciones que no seguían el camino normal por destino. La ingeniería de tráfico no necesitaba una nueva primitiva, aunque la justificación, la capacidad y la aprobación de ese desvío quedaban fuera del paquete.
ATM ofrecía VPI y VCI como campos adecuados para transportar etiquetas. Aun así, un conmutador ATM debía participar en el encaminamiento de red y ejecutar el control de Tag Switching; la agregación podía exigir reenvío de red. Un plano ATM tradicional podía convivir con recursos separados sin validar al otro.
En QoS, una clasificación inicial aplicaba una etiqueta de clase y permitía que los siguientes equipos localizaran el estado de planificación sin reclasificar. Las colas y la planificación seguían siendo ortogonales. La etiqueta de clase no demostraba reserva de ancho de banda, pérdidas, retardo ni resultado contractual.
Informational no significaba estándar ni despliegue
RFC 2105 no fue producto de un grupo de trabajo IETF, no estaba en la vía de estándares y no definía un estándar de Internet. Datatracker la clasifica hoy como Legacy, sin aval de la IETF ni posición formal en su proceso. La sección de seguridad dice que esos asuntos no se discuten, y la sección de propiedad intelectual registra la posible posición de Cisco.
RFC 3031 especificó en 2001 la arquitectura MPLS con etiquetas de significado local, FEC, pilas y sustitución por salto. La continuidad estructural existe, pero RFC 3031 no cita a RFC 2105 por número o título. Tag Switching mostró una vía hacia la arquitectura posterior; esa semejanza no demuestra causalidad directa, linaje de implementación ni adopción universal.
La perspectiva de Lu Heng separa con precisión estas capas: una publicación describe, mientras que la implementación y la operación crean realidad ejecutable. La especificación mínima no debe apropiarse de decisiones futuras y la legitimidad simbólica no puede fingir ejecución. El documento, la asociación de control, la TIB instalada y la entrega observada eran cuatro recibos diferentes.
Fuentes
- RFC 2105, Cisco Systems' Tag Switching Architecture Overview
- Registro de RFC Editor para RFC 2105
- Registro de IETF Datatracker para RFC 2105
- Búsqueda de erratas de RFC 2105
- RFC 3031, Multiprotocol Label Switching Architecture
- RFC 5036, LDP Specification
- RFC 1953, Ipsilon Flow Management Protocol Specification for IPv4
- RFC 1954, Transmission of Flow Labelled IPv4 on ATM Data Links
- RFC 2098, Toshiba's Router Architecture Extensions for ATM
- Running-Code Primacy
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
