Resumen
- La RFC 795 tradujo los campos originales de Tipo de Servicio IP —precedencia, demora, rendimiento y fiabilidad— a las opciones particulares de AUTODIN II, ARPANET, PRNET y SATNET.
- Las equivalencias nunca fueron perfectas: PRNET no indicaba prioridad; ARPANET contaba con un solo bit para ella; diversas peticiones terminaban en la misma opción local y
111era un error en dos tablas.
Un remitente marca «rápido», «fiable» y «preferente» en una pequeña ficha IP. El paquete llega a PRNET y descubre que allí no existe la ventanilla de prioridad. En septiembre de 1981, Jon Postel convirtió esos desencuentros en la RFC 795, una serie de correspondencias para cuatro redes con hábitos propios. La historia del Internet cabe a veces en el espacio entre lo que permite pedir un encabezado y lo que el siguiente sistema sabe hacer.
La ficha de la época era el octeto Type of Service del IP original. Tres bits representaban la precedencia; otros tres señalaban preferencia por menor demora, más rendimiento y mayor fiabilidad; dos quedaban reservados. Había rangos desde «routine» hasta «network control», pasando por «flash override». Era un idioma compartido para describir lo deseable. Postel advirtió que las redes examinadas tenían opciones de servicio muy diferentes y pasó a ponerlas en tablas.
AUTODIN II separaba las categorías de aceptación del tráfico de los tipos de aplicación. Las primeras podían llevarse a la precedencia IP con relativa facilidad. Los segundos ofrecían perfiles concretos: I/A para baja demora, B1 para rendimiento, B2 para rendimiento junto a fiabilidad y Q/R para el caso ordinario. La vuelta de los bits de demora, rendimiento y fiabilidad al servicio local tenía pérdidas: varios patrones desembocaban en Q/R o I/A; 111 devolvía «error». El cliente podía marcar tres casillas, pero el menú no inventaba un plato nuevo.
ARPANET disponía de un único bit de prioridad, convertible al bit superior de precedencia IP. Tenía además mensajes normales de tipo 0 o no controlados de tipo 3, y tamaños de uno o varios paquetes. El tipo 3 no admitía multipaquete. Varios patrones DTR acababan como tipo 0 multipaquete; 100 y 110 conducían al tipo 3 de un paquete; 101, al tipo 0 de uno; 111, a otro error. El formulario distinguía peticiones que la red resolvía del mismo modo.
PRNET permitía elegir entre encaminamiento por estaciones o punto a punto, con acuse de recibo o sin él. No tenía indicación de prioridad. El bit de demora se traducía al modo de encaminamiento y el de fiabilidad al acuse; cambiar el bit de rendimiento no alteraba el par resultante en la tabla. Podía llegar un paquete con alta precedencia y continuar sin una palanca local equivalente para aplicarla.
SATNET tampoco indicaba prioridad, aunque abundaba en otros mandos: bloque o flujo, cuatro categorías de demora, dos estrategias de retención y tres niveles de fiabilidad. El producto daba 48 combinaciones. Los tres bits DTR de IP expresaban poco frente a esa variedad. Una pasarela necesitaría una regla para escoger entre los ajustes existentes; la palabra «fiable» por sí sola no fijaba los cuatro mandos.
La RFC es un antídoto contra la magia de los nombres. «Tipo de servicio» parecía una promesa uniforme hasta que aparecieron las filas con errores, opciones duplicadas y controles ausentes. Postel dejó constancia de que el trabajo del Internet consistía en pasar entre máquinas distintas sin declarar idénticas sus capacidades. El último tramo de una solicitud siempre dependía del menú de la red que iba a servirla.
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





