La innovación en Internet, una historia de adaptación constante y soluciones a medida
05/06/2024

Por Carlos Martinez Cagnazzo, Gerente de Tecnología de LACNIC
Existe un interesante punto en cómo se ha gestado la innovación y la evolución de Internet a lo largo de su historia que difiere sustancialmente de lo que ha ocurrido en otros casos: en Internet se han ido inventando las soluciones a medida que hicieron falta, a diferencia por ejemplo de cómo trabajan otras disciplinas de diseño o de cómo se han construido otras tecnologías -como las redes telefónicas- donde el paradigma predominante es “de arriba hacia abajo” y las especificaciones o marcos generales son los que determinan las funcionalidades, los recorridos o los entornos que se van a utilizar.
En este sentido, me gustaría tomar el caso de la arquitectura más famosa de las redes de computadoras: el modelo de “siete capas” o “Modelo OSI” (Interconexión de Sistemas Abiertos, por sus siglas en inglés). A fines de los años 70s, ya se empezaba a advertir que las computadoras necesitaban interconectarse. En ese momento, lo único que existía eran los mecanismos propietarios definidos por los grandes fabricantes de las micro y de las mini computadoras (por ejemplo los entornos de IBM, entre otros). Lo importante a destacar es que cada fabricante tenía su estándar de comunicación entre computadoras.
Progresivamente la discusión empezó a girar en torno a la sostenibilidad de dicho modelo, que ni siquiera era funcional para los propios fabricantes. Emergía la necesidad de definir una estructura estándar de redes y el resultado fue la definición del modelo OSI. Para entonces, los fabricantes más tradicionales recurrieron a un organismo de estandarización (International Organization for Standardization) y partieron de una serie de requerimientos base. Desde allí fueron hacia abajo y definieron un variedad de instancias y parámetros para el funcionamiento del modelo (de hecho, el documento completo constaba de unas 2000 páginas)
Lo más interesante que derivó de ese modelo fue el concepto de “capa”: si los datos entre dos dispositivos viajan por alguna forma de medio físico (conexión eléctrica) ¿cómo esas señales se convierten efectivamente en una página de Internet?. La respuesta es que van recorriendo una serie de capas y cada una de esas capas va sumando una funcionalidad. La capa física (responsable de los equipos físicos y la que posibilita la transferencia de datos, como cables y routers y donde los datos se convierten en un flujo de bits). Luego la capa de enlace de datos (responsable de la transferencia de información en la misma red y del control de los errores y el flujo de datos) y la capa de red (encargada de dividir los datos en el dispositivo del remitente y de recomponerlos en el dispositivo del destinatario cuando la transmisión ocurre entre dos redes diferentes). El modelo se completa con la capa de transporte, la capa de sesión, la capa de presentación y la de aplicación.
Si bien conceptualmente el modelo OSI es muy relevante, lo que ocurrió con su implementación concreta tiene más que ver con algo del orden de lo práctico: les llevó muchísimo tiempo escribir y definir todos los parámetros, pero una vez que el stack estuvo completo y todas las definiciones estuvieron listas, ya todo el mundo utilizaba el protocolo TCP/IP.
Me interesa destacar que OSI fue más allá e incluso definió protocolos de enlace y protocolos de red, sin embargo, si bien se invirtió mucho tiempo y dinero en definir esos protocolos, no se utilizan por más que funcionen correctamente. El único que tiene cierta utilidad entre los usuarios -los puristas suelen decir que se utiliza en redes de telefonía- es el protocolo IS-IS, un protocolo de puerta de enlace interior (IGP) que utiliza información de estado de vínculo para tomar decisiones de enrutamiento.
(Acceso libre, no requiere suscripción)
¿Qué quiero decir con todo esto? Que a veces lo perfecto es enemigo de lo bueno. ¿TCP/IP es el mejor protocolo que existe? Definitivamente no, tiene problemas y contras, pero lo cierto es que estuvo disponible cuando la gente lo precisó. Imaginemos en los tiempos de entonces -cuando emergió la necesidad de interconexión entre computadoras- que la solución era urgente, no podía esperar a que un estándar estuviera listo. Si yo necesito conectar 20 ministerios o 20 oficinas o las computadoras de una universidad, es mi necesidad la que marca el ritmo.
Otro ejemplo que ilustra este punto es que a mediados de los 90s, cuando el IETF se dio cuenta que el IPv4 no era sostenible, organizó una suerte de concurso de ideas de cómo debería evolucionar IPV4. Una de las propuestas era utilizar ConnectionLess Network Protocol (CLNP), un protocolo utilizado por OSI para transportar datos e indicación de errores en el nivel de red. En su funcionamiento es muy parecido al IP pero aloja direcciones más grandes, de manera que permitía resolver esa coyuntura. Sin embargo, lo que ocurrió es que si bien existía algo de experiencia de trabajo con ese protocolo, prácticamente no existían implementaciones.
Además, en la cuestión de CLNP influyó definitivamente la ausencia de un estándar abierto. La existencia de procesos abiertos es fundamental en toda la historia de innovación de Internet. A diferencia de los entornos cerrados y definidos, los abiertos permiten que mucha más gente participe en las decisiones, está disponible gratuitamente para su adopción, implementación y actualizaciones. Las empresas dentro de una industria comparten estándares abiertos porque aportan gran valor a ellas mismas y a sus clientes. Las normas suelen ser gestionadas conjuntamente por una base de partes interesadas. Por lo general, existen reglas sobre qué tipo de ajustes o actualizaciones pueden realizar los usuarios para garantizar que el estándar mantenga la interoperabilidad y la calidad.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
Menos mal que los incentivos apuntan hacia estándares abiertos. Parece que esquivamos una bala con eso del CLNP…
Es un análisis contrafáctico interesante. CLNP no es un mal protocolo, y quizás se pudiera haber “adoptado” y hacer abierto, pero no hay garantía de eso hubiera sido posible.