Reglas clave

Cuatro fueron las reglas fundamentales en las primeras ideas de Kahn:

 Cada red distinta debería mantenerse por sí misma y no deberían requerirse cambios internos a ninguna de ellas para conectarse a Internet.

 Las comunicaciones deberían ser establecidas en base a la filosofía del "best-effort" (lo mejor posible). Si un paquete no llegara a su destino debería ser en breve retransmitido desde el emisor.

 Para interconectar redes se usarían cajas negras, las cuales más tarde serían denominadas gateways (pasarelas) y routers (enrutadores). Los gateways no deberían almacenar información alguna sobre los flujos individuales de paquetes que circulasen a través de ellos, manteniendo de esta manera su simplicidad y evitando la complicada adaptación y recuperación a partir de las diversas modalidades de fallo.

 No habría ningún control global a nivel de operaciones.

Otras cuestiones clave que debían ser resueltas eran:

 Algoritmos para evitar la pérdida de paquetes en base a la invalidación de las comunicaciones y la reiniciación de las mismas para la retransmisión exitosa desde el emisor.

 Provisión de pipelining ("tuberías") host a host de tal forma que se pudieran enrutar múltiples paquetes desde el origen al destino a discreción de los hosts participantes, siempre que las redes intermedias lo permitieran.

 Funciones de pasarela para permitir redirigir los paquetes adecuadamente. Esto incluía la interpretación de las cabeceras IP para enrutado, manejo de interfaces y división de paquetes en trozos más pequeños si fuera necesario.

 La necesidad de controles (checksums) extremo a extremo, reensamblaje de paquetes a partir de fragmentos, y detección de duplicados si los hubiere.

 Necesidad de direccionamiento global.

 Técnicas para el control del flujo host a host.

 Interacción con varios sistemas operativos.

 Implementación eficiente y rendimiento de la red, aunque en principio éstas eran consideraciones secundarias.

Kahn empezó a trabajar en un conjunto de principios para sistemas operativos orientados a comunicaciones mientras se encontraba en BBN y escribió algunas de sus primeras ideas en un memorándum interno de BBN titulado "Communications Principles for Operating Systems". En ese momento, se dió cuenta de que le sería necesario aprender los detalles de implementación de cada sistema operativo para tener la posibilidad de incluir nuevos protocolos de manera eficiente. Así, en la primavera de 1973, después de haber empezado el trabajo de "Internetting", le pidió a Vinton Cerf (entonces en la Universidad de Stanford) que trabajara con él en el diseño detallado del protocolo. Cerf había estado íntimamente implicado en el diseño y desarrollo original del NCP y ya tenía conocimientos sobre la construcción de interfaces con los sistemas operativos existentes. De esta forma, valiéndose del enfoque arquitectural de Kahn en cuanto a comunicaciones y de la experiencia en NCP de Cerf, se asociaron para abordar los detalles de lo que acabaría siendo TCP/IP.

El trabajo en común fue altamente productivo y la primera versión escrita (7)bajo este enfoque fue distribuida en una sesión especial del INWG (International Network Working Group, Grupo de trabajo sobre redes internacionales) que había sido convocada con motivo de una conferencia de la Universidad de Sussex en Septiembre de 1973. Cerf había sido invitado a presidir el grupo y aprovechó la ocasión para celebrar una reunión de los miembros del INWG, ampliamente representados en esta conferencia de Sussex.

Estas son las directrices básicas que surgieron de la colaboración entre Kahn y Cerf:

 Las comunicaciones entre dos procesos consistirían lógicamente en un larga corriente de bytes; ellos los llamaban "octetos". La posición de un octeto dentro de esta corriente de datos sería usada para identificarlo.

 El control del flujo se realizaría usando ventanas deslizantes y acks (N. del T.: abreviatura de acknowledgement, acuse de recibo). El destinatario podría decidir cuando enviar acuse de recibo y cada ack devuelto correspondería a todos los paquetes recibidos hasta el momento.

 Se dejó abierto el modo exacto en que emisor y destinatario acordarían los parámetros sobre los tamaños de las ventanas a usar. Se usaron inicialmente valores por defecto.

Aunque en aquellos momentos Ethernet estaba en desarrollo en el PARC de Xerox, la proliferación de LANs no había sido prevista entonces y mucho menos la de PCs y estaciones de trabajo. El modelo original fue concebido como un conjunto, que se esperaba reducido, de redes de ámbito nacional tipo ARPANET. De este modo, se usó una dirección IP de 32 bits, de la cual los primeros 8 identificaban la red y los restantes 24 designaban el host dentro de dicha red. La decisión de que 256 redes sería suficiente para el futuro previsible debió empezar a reconsiderarse en cuanto las LANs empezaron a aparecer a finales de los setenta.

El documento original de Cerf y Kahn sobre Internet describía un protocolo, llamado TCP, que se encargaba de proveer todos los servicios de transporte y reenvío en Internet. Kahn pretendía que TCP diera soporte a un amplio rango de servicios de transporte, desde el envío secuencial de datos, totalmente fiable (modelo de circuito virtual) hasta un servicio de datagramas en el que la aplicación hiciera un uso directo del servicio de red subyacente, lo que podría implicar pérdida ocasional, corrupción o reordenación de paquetes.

Sin embargo, el esfuerzo inicial de implementación de TCP dio lugar a una versión que sólo permitía circuitos virtuales. Este modelo funcionaba perfectamente en la transferencia de ficheros y en las aplicaciones de login remoto, pero algunos de los primeros trabajos sobre aplicaciones avanzadas de redes (en particular el empaquetamiento de voz en los años 70) dejó bien claro que, en ciertos casos, el TCP no debía encargarse de corregir las pérdidas de paquetes y que había que dejar a la aplicación que se ocupara de ello. Esto llevó a la reorganización del TCP original en dos protocolos: uno sencillo, IP, que se encargara tan sólo de dar una dirección a los paquetes y de reenviarlos; y un TCP que se dedicara a una serie de funcionalidades como el control del flujo y la recuperación de los paquetes perdidos. Para aquellas aplicaciones que no precisan los servicios de TCP, se añadió un protocolo alternativo llamado UDP (User Datagram Protocol, protocolo de datagramas de usuario) dedicado a dar un acceso directo a los servicios básicos del IP.

Una de las motivaciones iniciales de ARPANET e Internet fue compartir recursos, por ejemplo, permitiendo que usuarios de redes de paquetes sobre radio pudieran acceder a sistemas de tiempo compartido conectados a ARPANET. Conectar las dos redes era mucho más económico que duplicar estos carísimos ordenadores. Sin embargo, mientras la transferencia de ficheros y el login remoto (Telnet) eran aplicaciones muy importantes, de todas las de esta época probablemente sea el correo electrónico la que haya tenido un impacto más significativo. El correo electrónico dio lugar a un nuevo modelo de comunicación entre las personas y cambió la naturaleza de la colaboración. Su influencia se manifestó en primer lugar en la construcción de la propia Internet (como veremos más adelante), y posteriormente, en buena parte de la sociedad.

Se propusieron otras aplicaciones en los primeros tiempos de Internet, desde la comunicación vocal basada en paquetes (precursora de la telefonía sobre Internet) o varios modelos para compartir ficheros y discos, hasta los primeros "programas-gusano" que mostraban el concepto de agente (y, por supuesto, de virus). Un concepto clave en Internet es que no fue diseñada para una única aplicación sino como una infraestructura general dentro de la que podrían concebirse nuevos servicios, como con posterioridad demostró la aparición de la World Wide Web. Este fue posible solamente debido a la orientación de propósito general que tenía el servicio implementado mediante TCP e IP.

Notas:


(7) Esta fue más tarde publicada como: V.G. Cerf y R.E. Kahn, "A Protocol for Packet Network Interconnection", IEEE Trans. Comm. Tech., vol. COM-22, V5, May 1974, pp. 627-641

San Judas Tadeo