Resumen

  • RFC 2215 separó la aportación local de cada elemento del valor compuesto a lo largo de la ruta y definió la caracterización en función del siguiente salto.
  • Aplicó OR a una ruptura de soporte, incremento al número de saltos conscientes, mínimo al ancho de banda y al MTU, y suma acotada a la latencia mínima.
  • El valor final era una descripción condicionada, no una reserva, una decisión de admisión, una medición de rendimiento ni una constancia de entrega.

El mismo camino planteaba preguntas diferentes

Un router podía recibir cuatro datos sobre lo recorrido: si había aparecido un elemento incapaz de prestar el servicio, cuántos nodos entendían Integrated Services, cuál era la menor disponibilidad de ancho de banda y cuánta latencia mínima se había acumulado. Promediarlos habría destruido su significado.

RFC 2215 asignó una operación a cada afirmación. Una sola ruptura basta, de modo que usa OR. Un participante añade uno. Un cuello de botella sólo puede mantener o reducir el valor. Un retardo local se suma. La forma de composición era parte de la semántica, no un detalle de implementación.

La caracterización servía para conocer el entorno QoS de una ruta candidata y orientar una solicitud. No decía que los recursos ya estuvieran reservados ni que los paquetes hubieran recibido el servicio.

Lo local no era lo compuesto

Cada parámetro distinguía un valor local de otro compuesto. El primero describía un elemento; el segundo combinaba la ruta previa con esa aportación y seguía hacia el siguiente nodo. El cálculo podía avanzar hacia el receptor o hacia el emisor.

El RFC hablaba de valores conceptualmente per-next-hop. En una nube o medio compartido, dos salidas podían exigir datos distintos. Guardar una propiedad única del dispositivo borraría la decisión de encaminamiento que hacía verdadero el dato. Los identificadores separados permitían observar tanto el aporte local como el estado compuesto.

La pérdida de las entradas era irreversible. Un mínimo no identifica el cuello de botella; una suma no muestra sus términos; un OR no localiza la ruptura.

El valor global no anulaba el override

El número de servicio 1 representaba la rama global. Un servicio concreto podía publicar un valor más restrictivo. Si llegaba una rama específica, se combinaba con el override local cuando existía y, en caso contrario, con el valor global local sin perder su identidad. Si llegaba una rama global y aparecía un override, nacía una rama específica adicional mientras la global seguía su curso.

Así, un router podía admitir un MTU general de 1.500 bytes pero limitar Guaranteed Service a 250. No eran dos opiniones sobre la misma realidad física. Eran dos superficies de ejecución. Fundirlas engañaría a uno de los consumidores.

La ruptura contaminaba el resto de la descripción

NON_IS_HOP era verdadero cuando faltaba el servicio pertinente o se conocía un corte en la cadena. El OR hacía que una sola marca sobreviviera hasta el extremo. Un túnel debía tratarse como no compatible mientras no existiera prueba de lo contrario.

Existe una dificultad reveladora: el elemento que no entiende la especificación tampoco sabe marcar su incumplimiento. La responsabilidad podía recaer en un vecino, el protocolo de señalización o la configuración. El break bit no era una confesión autenticada.

Cuando la ruptura era global, los demás parámetros podían ser inexactos. Si era específica de un servicio, debilitaba los datos asociados a ese servicio. RFC 2210 definió su transporte en ADSPEC; transportar bien una advertencia no elimina su contenido.

El contador registraba participantes, no ausencias

NUMBER_OF_IS_HOPS aumentaba en uno por cada elemento consciente. Registraba contribuyentes conocidos, no el número total de segmentos. Un nodo ajeno al sistema no se sumaba.

Por eso el contador necesitaba el break bit. Cinco saltos registrados no prueban que la ruta sólo tenga cinco saltos. “No contado” no significa “inexistente”.

El ancho de banda era un mínimo anterior a la petición

Cada elemento estimaba la disponibilidad según recursos físicos, controles administrativos y política. La ruta conservaba el mínimo. Ese resultado no localizaba el cuello ni reservaba capacidad.

La estimación se producía antes de una solicitud QoS concreta. Destino, servicio y reglas de reserva podían seguir sin conocerse. RFC 2215 permitía por ello una sobreestimación importante cuando no era posible mayor precisión. Un servicio restringido podía añadir un override menor.

El cero significaba desconocido. Al aplicar MIN, permanecía cero aunque todos los nodos posteriores anunciasen cifras positivas. La ausencia de evidencia no podía transformarse en recurso por acumulación de optimismo.

La latencia sumaba hasta declarar ignorancia

La latencia local era el mínimo posible de propagación y procesamiento, sin cola variable. Servía como base para servicios como el de RFC 2212, pero no era RTT observado ni la cota C/R + D.

En una nube con varias salidas, lo ideal era un valor por siguiente salto. Un valor compartido debía usar la ruta mínima y podía subestimar la ruta real. También podía declararse indeterminado.

Los microsegundos se sumaban con límite (2**32)-1. Ese máximo indicaba indeterminación, por una contribución desconocida o por desbordamiento. La composición lo preservaba. No representaba una medición enorme y exacta.

El MTU tomaba el mínimo con una obligación más fuerte

El MTU local era el mayor paquete IP transportable sin fragmentación, incluidos los encabezados IP y superiores pero no los de enlace. Todos los elementos conscientes debían aportar un valor correcto. Un override de servicio podía reducirlo, nunca aumentarlo.

El mínimo describía un techo para una ruta y una rama de servicio. No demostraba que el emisor lo usara, que ningún túnel hubiera quedado oculto, que la ruta siguiera igual ni que el paquete llegara.

TSpec no era una quinta álgebra

El parámetro 127 definía el token-bucket TSpec. Describía tráfico esperado, pero los nodos intermedios no exportaban valores locales para componerlo. Compartir RFC no convertía un contrato de entrada en una caracterización del camino. Tampoco probaba conformidad real, admisión o tratamiento.

La cifra compuesta ocupaba una etapa intermedia

RFC 1633 establecía la arquitectura; RFC 2205, RSVP; RFC 2211 y RFC 2212, servicios; RFC 2216, la plantilla. La composición de RFC 2215 no absorbía ninguna de esas etapas.

Un registro serio conserva identificador, rama, siguiente salto, época de ruta, fuente local, método, regla, estado desconocido, petición, admisión, instalación, observación, entrega y resultado. Ninguna fila reemplaza a la siguiente.

Fuentes y límites

La fuente principal es RFC 2215, con registros del RFC Editor y del IETF Datatracker. RFC 2815 ilustra una aplicación posterior en IEEE 802 y conserva la diferencia entre MTU exacto y ancho de banda aproximado. Los textos no prueban despliegue actual, producto, reserva viva, rendimiento medido ni incidente.

Los ensayos de Heng Lu sobre primacía del código en ejecución, regla mínima y decisión local y capas de realidad aportan el marco editorial: una declaración puede orientar, pero la realidad ejecutable exige implementación y observación. No constituyen una afirmación causal sobre 1997.