El principio de extremo a extremo es un marco de diseño en redes de computadoras . En redes diseñadas según este principio, garantizar ciertas características específicas de la aplicación, como confiabilidad y seguridad, requiere que residan en los nodos finales comunicantes de la red. Los nodos intermediarios, como puertas de enlace y enrutadores , que existen para establecer la red, pueden implementarlos para mejorar la eficiencia, pero no pueden garantizar la corrección de un extremo a otro.
La esencia de lo que más tarde se llamaría el principio de extremo a extremo estaba contenida en el trabajo de Donald Davies sobre redes de conmutación de paquetes en la década de 1960. Louis Pouzin fue pionero en el uso de la estrategia de extremo a extremo en la red CYCLADES en los años 1970. [1] El principio fue articulado explícitamente por primera vez en 1981 por Saltzer , Reed y Clark . [2] [a] El significado del principio de extremo a extremo ha sido reinterpretado continuamente desde su articulación inicial. Además, se pueden encontrar formulaciones notables del principio de extremo a extremo antes del artículo fundamental de Saltzer, Reed y Clark de 1981. [3]
Una premisa básica del principio es que los beneficios de agregar ciertas características requeridas por la aplicación final al subsistema de comunicación disminuyen rápidamente. Los hosts finales deben implementar estas funciones para que sean correctas. [b] La implementación de una función específica genera algunas penalizaciones de recursos independientemente de si la función se utiliza o no, y la implementación de una función específica en la red agrega estas penalizaciones a todos los clientes, ya sea que necesiten la función o no.
Concepto
Según el principio de extremo a extremo, la red sólo es responsable de proporcionar a los terminales las mejores conexiones. Características como confiabilidad y seguridad deben ser proporcionadas por mecanismos y protocolos ubicados en las terminales.
La noción fundamental detrás del principio de extremo a extremo es que para dos procesos que se comunican entre sí a través de algún medio de comunicación, no se puede esperar que la confiabilidad obtenida de ese medio esté perfectamente alineada con los requisitos de confiabilidad de los procesos. En particular, cumplir o superar los requisitos de confiabilidad muy alta de los procesos de comunicación separados por redes de tamaño no trivial es más costoso que obtener el grado requerido de confiabilidad mediante acuses de recibo y retransmisiones positivas de extremo a extremo (denominadas PAR o ARQ ). [c] Dicho de otra manera, es mucho más fácil obtener confiabilidad más allá de un cierto margen mediante mecanismos en los hosts finales de una red que en los nodos intermediarios , [d] especialmente cuando estos últimos están fuera del control y no son responsables de , el primero. [e] Los acuses de recibo positivos de un extremo a otro con infinitos reintentos pueden obtener una confiabilidad arbitrariamente alta de cualquier red con una probabilidad superior a cero de transmitir datos exitosamente de un extremo a otro. [F]
El principio de extremo a extremo no se extiende a funciones más allá del control y la corrección de errores y la seguridad de un extremo a otro. Por ejemplo, no se pueden presentar argumentos sencillos de extremo a extremo para parámetros de comunicación como la latencia y el rendimiento . En un artículo de 2001, Blumenthal y Clark señalan: "[Des]de el principio, los argumentos de un extremo a otro giraban en torno a los requisitos que podrían implementarse correctamente en los puntos finales; si la implementación dentro de la red es la única manera de cumplir el requisito , entonces, en primer lugar, un argumento de un extremo a otro no es apropiado". [7] : 80
El principio de extremo a extremo está estrechamente relacionado, y en ocasiones se considera un precursor directo, del principio de neutralidad de la red . [8]
Historia
En la década de 1960, Paul Baran y Donald Davies , en sus elaboraciones de redes anteriores a ARPANET , hicieron comentarios sobre la confiabilidad. El artículo de Baran de 1964 afirma: "La confiabilidad y las tasas de error brutas son secundarias. La red debe construirse con la expectativa de sufrir graves daños de todos modos. Existen poderosos métodos de eliminación de errores". [9] : 5 Yendo más allá, Davies capturó la esencia del principio de extremo a extremo; en su artículo de 1967 afirmó que los usuarios de la red se proporcionarán a sí mismos un control de errores: "Se cree que todos los usuarios de la red se proporcionarán algún tipo de control de errores y que sin dificultad se podría hacer que esto mostrara un error paquete. Debido a esto, la pérdida de paquetes, si es lo suficientemente rara, puede ser tolerada". [10] : 2.3
ARPANET fue la primera red de conmutación de paquetes de propósito general a gran escala, implementando varios de los conceptos previamente articulados por Baran y Davies. [11] [12]
ARPANET demostró varios aspectos importantes del principio de extremo a extremo.
La conmutación de paquetes impulsa algunas funciones lógicas hacia los puntos finales de comunicación
Si la premisa básica de una red distribuida es la conmutación de paquetes, entonces inevitablemente se deben implementar funciones como el reordenamiento y la detección de duplicados en los puntos finales lógicos de dicha red. En consecuencia, ARPANET presentaba dos niveles distintos de funcionalidad:
un nivel inferior que se ocupa del transporte de paquetes de datos entre nodos de red vecinos (llamados procesadores de mensajes de interfaz o IMP), y
un nivel superior que se ocupa de diversos aspectos de extremo a extremo de la transmisión de datos. [gramo]
Dave Clark, uno de los autores del artículo sobre el principio de extremo a extremo, concluye: "El descubrimiento de paquetes no es una consecuencia del argumento de extremo a extremo. Es el éxito de los paquetes lo que hace que el final del argumento relevante." [19] : diapositiva 31
No hay transferencia de datos arbitrariamente confiable sin mecanismos de retransmisión y reconocimiento de extremo a extremo
ARPANET fue diseñado para proporcionar transporte de datos confiable entre dos puntos finales cualesquiera de la red, muy parecido a un simple canal de E/S entre una computadora y un dispositivo periférico cercano. [h] Para remediar cualquier posible falla en la transmisión de paquetes, los mensajes ARPANET normales se pasaban de un nodo al siguiente con un acuse de recibo positivo y un esquema de retransmisión; después de una transferencia exitosa, fueron descartados, [i] no se preparó ninguna retransmisión de origen a destino en caso de pérdida de paquetes. Sin embargo, a pesar de importantes esfuerzos, resultó imposible proporcionar la confiabilidad perfecta prevista en la especificación inicial de ARPANET, una realidad que se hizo cada vez más obvia una vez que ARPANET creció mucho más allá de su topología inicial de cuatro nodos. [j] Por lo tanto, ARPANET proporcionó un sólido argumento a favor de los límites inherentes de los mecanismos de confiabilidad salto a salto basados en la red en la búsqueda de una verdadera confiabilidad de extremo a extremo. [k]
Compensación entre confiabilidad, latencia y rendimiento
La búsqueda de una confiabilidad perfecta puede perjudicar otros parámetros relevantes de una transmisión de datos, sobre todo la latencia y el rendimiento. Esto es particularmente importante para aplicaciones que valoran el rendimiento predecible y la baja latencia por encima de la confiabilidad; el ejemplo clásico son las aplicaciones de voz interactivas en tiempo real. Este caso de uso fue atendido en ARPANET al proporcionar un servicio de mensajes sin procesar que prescindió de varias medidas de confiabilidad para brindar un servicio de transmisión de datos más rápido y con menor latencia a los hosts finales. [l]
TCP/IP
El Protocolo de Internet (IP) es un servicio de datagramas sin conexión y sin garantías de entrega . En Internet, el IP se utiliza para casi todas las comunicaciones. El reconocimiento y la retransmisión de un extremo a otro son responsabilidad del Protocolo de control de transmisión (TCP) orientado a la conexión que se encuentra por encima de IP. La división funcional entre IP y TCP ejemplifica la aplicación adecuada del principio de extremo a extremo al diseño de protocolos de transporte.
Transferencia de archivos
Un ejemplo del principio de extremo a extremo es el de una transferencia de archivos arbitrariamente confiable entre dos puntos finales en una red distribuida de un tamaño variable y no trivial: [3] La única forma en que dos puntos finales pueden obtener una transferencia completamente confiable es transmitiendo y reconocer una suma de comprobación para todo el flujo de datos; En tal entorno, los protocolos de suma de comprobación y reconocimiento ( ACK /NACK) menores se justifican únicamente con el fin de optimizar el rendimiento; son útiles para la gran mayoría de los clientes, pero no son suficientes para cumplir con el requisito de confiabilidad de esta aplicación en particular. Por lo tanto, es mejor realizar una suma de verificación exhaustiva en los puntos finales, y la red mantiene un nivel relativamente bajo de complejidad y un rendimiento razonable para todos los clientes. [3]
Limitaciones
La limitación más importante del principio de extremo a extremo es que su premisa básica, colocar funciones en los puntos finales de la aplicación en lugar de en los nodos intermediarios, no es fácil de implementar.
Un ejemplo de las limitaciones del principio de extremo a extremo existe en los dispositivos móviles, por ejemplo con IPv6 móvil . [27] Impulsar la complejidad específica del servicio a los puntos finales puede causar problemas con los dispositivos móviles si el dispositivo tiene acceso poco confiable a los canales de red. [28]
Se pueden ver más problemas con una disminución en la transparencia de la red debido a la adición de la traducción de direcciones de red (NAT), en la que se basa IPv4 para combatir el agotamiento de las direcciones . [29] Con la introducción de IPv6 , los usuarios vuelven a tener identificadores únicos, lo que permite una verdadera conectividad de extremo a extremo. Los identificadores únicos pueden basarse en una dirección física o pueden ser generados aleatoriamente por el host. [30]
El principio de extremo a extremo aboga por impulsar la funcionalidad relacionada con la coordinación cada vez más alto, en última instancia hasta la capa de aplicación. La premisa es que la información a nivel de aplicación permite una coordinación flexible entre los puntos finales de la aplicación y produce un mejor rendimiento porque la coordinación sería exactamente lo que se necesita. Esto lleva a la idea de modelar cada aplicación a través de su propio protocolo específico de la aplicación que admita la coordinación deseada entre sus puntos finales, asumiendo solo un simple servicio de comunicación de capa inferior. En términos generales, esta idea se conoce como semántica de aplicación (significado).
Los sistemas multiagente ofrecen enfoques basados en la semántica de aplicaciones que permiten implementar convenientemente aplicaciones distribuidas sin requerir pedidos de mensajes ni garantías de entrega de los servicios de comunicación subyacentes. Una idea básica en estos enfoques es modelar la coordinación entre los puntos finales de la aplicación a través de un protocolo de información [31] y luego implementar los puntos finales (agentes) basados en el protocolo. Se pueden implementar protocolos de información a través de servicios de comunicación desordenados y con pérdidas. Un middleware basado en protocolos de información y el modelo de programación asociado abstrae las recepciones de mensajes de la red subyacente y permite a los programadores de terminales centrarse en la lógica empresarial para enviar mensajes.
^ El artículo de 1981 [2] se publicó en TOCS de ACM en una versión actualizada en 1984. [3] [4]
^ La cita completa del artículo de Saltzer, Reed y Clark dice: [3] "En un sistema que incluye comunicaciones, generalmente se traza un límite modular alrededor del subsistema de comunicación y se define una interfaz firme entre este y el resto del sistema. Cuando Al hacerlo, resulta evidente que hay una lista de funciones, cada una de las cuales podría implementarse de varias maneras: por el subsistema de comunicación, por su cliente, como una empresa conjunta o quizás de manera redundante, cada uno haciendo su propia versión. Al razonar sobre esta elección, los requisitos de la aplicación proporcionan la base para la siguiente clase de argumentos: La función en cuestión puede implementarse completa y correctamente sólo con el conocimiento y la ayuda de la aplicación situada en los puntos finales del sistema de comunicación. proporcionar esa función cuestionada como una característica del sistema de comunicación en sí no es posible y, además, produce una penalización en el rendimiento para todos los clientes del sistema de comunicación (a veces, una versión incompleta de la función proporcionada por el sistema de comunicación puede ser útil como rendimiento). mejora.) A esta línea de razonamiento contra la implementación de funciones de bajo nivel la llamamos argumento de extremo a extremo". (pág. 278).
^ De hecho, incluso en las redes de área local existe una probabilidad distinta de cero de falla de comunicación: "se requiere atención a la confiabilidad en niveles superiores, independientemente de la estrategia de control de la red". [5]
^ Dicho en términos económicos, el costo marginal de confiabilidad adicional en la red excede el costo marginal de obtener la misma confiabilidad adicional mediante medidas en los hosts finales. El nivel económicamente eficiente de mejora de la confiabilidad dentro de la red depende de las circunstancias específicas; sin embargo, ciertamente no está cerca de cero: [3] "Claramente, algún esfuerzo en los niveles inferiores para mejorar la confiabilidad de la red puede tener un efecto significativo en el rendimiento de la aplicación (p. 281)".
^ A pesar de la posibilidad de soluciones contractuales ejecutables, es imposible que cualquier red en la que los recursos intermediarios se compartan de forma no determinista garantice una confiabilidad perfecta. Como máximo, podrá citar promedios estadísticos de desempeño.
^ Más precisamente: [6] "THM 1: un protocolo PAR que funciona correctamente con un recuento de reintentos infinito nunca deja de entregar, pierde o duplica mensajes. COR 1A: un protocolo PAR que funciona correctamente con un recuento de reintentos finito nunca pierde ni duplica mensajes, y la probabilidad de no entregar un mensaje puede ser arbitrariamente pequeña por parte del remitente." (pág. 3).
^ De acuerdo con la RFQ de ARPANET [17] (págs. 47 y siguientes), ARPANET separó conceptualmente ciertas funciones. Como señala BBN en un artículo de 1977: [18] "[L]a implementación de la red ARPA utiliza la técnica de dividir mensajes en paquetes para minimizar el retraso observado en transmisiones largas en muchos saltos. La implementación de la red ARPA también permite que se envíen varios mensajes. en tránsito simultáneamente entre un par determinado de hosts. Sin embargo, los diversos mensajes y los paquetes dentro de los mensajes pueden llegar al IMP de destino desordenados y, en el caso de un IMP o una línea interrumpida, puede haber duplicados. El procedimiento de transmisión de origen a destino de la red ARPA consiste en reordenar paquetes y mensajes en su destino, seleccionar duplicados y, una vez que hayan llegado todos los paquetes de un mensaje, pasar el mensaje al host de destino y devolver un mensaje de extremo a extremo. finalizar el reconocimiento (p. 284).
^ Este requisito se detalla en la RFQ de ARPANET : "Desde el punto de vista de los contratistas de ARPA como usuarios de la red, la subred de comunicación es una instalación autónoma cuyo software y hardware es mantenido por el contratista de la red. Al diseñar la interconexión Software que solo deberíamos necesitar para usar las convenciones I/0 para mover datos dentro y fuera de la subred y no involucrarnos en los detalles de la operación de la subred. Específicamente, verificación de errores, detección de fallas, conmutación de mensajes, recuperación de fallas, conmutación de líneas. Las fallas del operador y la evaluación de la calidad del operador, según se requiere para garantizar un rendimiento confiable de la red, son responsabilidad exclusiva del contratista de la red". [17] : 25
^ Señala Walden en un artículo de 1972: "Cada IMP retiene un paquete hasta que recibe un reconocimiento positivo del siguiente IMP de que el paquete se ha recibido correctamente. Si recibe el reconocimiento, todo está bien; el IMP lo sabe que el próximo IMP ahora tiene la responsabilidad del paquete y el IMP transmisor puede descartar su copia del paquete". [20] : 11
^ En 1973, BBN reconoció que el objetivo inicial de una confiabilidad perfecta dentro de ARPANET no era alcanzable: "Inicialmente, se pensó que los únicos componentes en el diseño de la red que eran propensos a errores eran los circuitos de comunicaciones y las interfaces del módem en el Los IMP están equipados con una suma de comprobación CRC para detectar "casi todos" estos errores. Se consideró que el resto del sistema, incluidas las interfaces del host, los procesadores IMP, las memorias y las interfaces, estaban libres de errores. esta posición a la luz de nuestra experiencia [21] : 1 De hecho, como resume Metcalfe en 1973, "ha habido suficientes bits erróneos en ARPANET para llenar esta cuota [un error de bit de transmisión no detectado por año] durante siglos. " [22] : 7–28 Véase también el Informe BBN 2816 [23] : 10 y siguientes para obtener más información sobre las experiencias adquiridas en los primeros años de funcionamiento de ARPANET.
^ Por cierto, ARPANET también proporciona un buen argumento para las compensaciones entre el costo de los mecanismos de confiabilidad de extremo a extremo y los beneficios que se obtendrán de ese modo. Tenga en cuenta que los verdaderos mecanismos de confiabilidad de extremo a extremo habrían sido prohibitivamente costosos en ese momento, dado que la especificación sostenía que podría haber hasta 8 mensajes a nivel de host en tránsito al mismo tiempo entre dos puntos finales, cada uno con un máximo de Más de 8000 bits. La cantidad de memoria que se habría requerido para guardar copias de todos esos datos para una posible retransmisión en caso de que no llegara ningún reconocimiento del IMP de destino era demasiado costosa para que valiera la pena. En cuanto a los mecanismos de confiabilidad de extremo a extremo basados en host, habrían agregado una complejidad considerable al protocolo común a nivel de host ( Protocolo Host-Host ). Si bien la conveniencia de los mecanismos de confiabilidad host-host se articuló en RFC 1, después de cierta discusión se prescindió de ellos (aunque los protocolos o aplicaciones de nivel superior eran, por supuesto, libres de implementar tales mecanismos por sí mismos). Para un recuento del debate de aquel momento, véase Bärwolff 2010, [24] págs. 56-58 y las notas allí contenidas, especialmente las notas 151 y 163.
^ Los primeros experimentos con paquetes de voz se remontan a 1971, y en 1972 comenzó una investigación ARPA más formal sobre el tema. Como se documenta en RFC 660 (p. 2), [25] en 1974 BBN introdujo el servicio de mensajes sin formato (Raw Message Interface, RMI) en ARPANET, principalmente para permitir a los hosts experimentar con aplicaciones de voz por paquetes, pero también reconociendo la uso de dicha instalación en vista de una posible comunicación entre redes (cf. Informe BBN 2913 [26] en págs. 55 y siguientes). Véase también Bärwolff 2010, [24] págs. 80-84 y las copiosas notas que contiene.
Referencias
^ ab Bennett, Richard (septiembre de 2009). "Diseñado para el cambio: argumentos de un extremo a otro, innovación en Internet y el debate sobre la neutralidad de la red" (PDF) . Fundación Tecnologías de la Información e Innovación. págs.7, 11 . Consultado el 11 de septiembre de 2017 .
^ ab Saltzer, JH, DP Reed y DD Clark (1981) "Argumentos de un extremo a otro en el diseño de sistemas". En: Actas de la Segunda Conferencia Internacional sobre Sistemas Computacionales Distribuidos. París, Francia. 8 al 10 de abril de 1981. IEEE Computer Society, págs.
^ Saltzer, JH (1980). Argumentos de un extremo a otro en el diseño de sistemas. Solicitud de comentarios No. 185, Laboratorio de Ciencias de la Computación del MIT, División de Investigación de Sistemas Computacionales. (Copia en línea).
^ Clark, DD, KT Pogran y DP Reed (1978). “Introducción a las redes de área local”. En: Actas del IEEE 66.11, págs. 1497-1517.
^ Sol, California (1975). Problemas en el diseño de protocolos de comunicación: corrección formal. Borrador. Nota 5 del protocolo INWG. IFIP WG 6.1 (INWG). (Copia del CBI).
^ Blumenthal, MS y DD Clark (2001). "Repensar el diseño de Internet: los argumentos de un extremo a otro frente al mundo valiente". En: Transacciones ACM sobre tecnología de Internet 1.1, págs. 70-109. (Versión previa a la publicación en línea).
^ Alexis C. Madrigal y Adrienne LaFrance (25 de abril de 2014). "Neutralidad de la red: una guía (y una historia de) una idea controvertida". El Atlántico . Consultado el 5 de junio de 2014 . Esta idea de neutralidad de la red... [Lawrence Lessig] solía llamar al principio e2e, de extremo a extremo.
^ Barán, P. (1964). "Sobre redes de comunicaciones distribuidas". En: IEEE Transactions on Communications 12.1, págs. 1–9.
^ Davies, DW, KA Bartlett, RA Scantlebury y PT Wilkinson (1967). "Una red de comunicación digital para computadoras que brinda respuesta rápida en terminales remotas". En: SOSP '67: Actas del primer simposio ACM sobre principios de sistemas operativos. Gatlinburg, Tennessee. 1 al 4 de octubre de 1967. Nueva York, NY: ACM, págs. 2.1 a 2.17.
^ "La verdadera historia de cómo Internet se volvió tan vulnerable". Correo de Washington . Archivado desde el original el 30 de mayo de 2015 . Consultado el 18 de febrero de 2020 . Los historiadores atribuyen sus conocimientos fundamentales al científico galés Donald W. Davies y al ingeniero estadounidense Paul Baran.
^ Una historia de ARPANET: la primera década (PDF) (Reporte). Bolt, Beranek & Newman Inc. 1 de abril de 1981. págs. 13, 53 de 183. Archivado desde el original el 1 de diciembre de 2012. Aparte de los problemas técnicos de interconectar computadoras con circuitos de comunicaciones, la noción de redes informáticas se había considerado en un número de plazas desde un punto de vista teórico. De particular interés fue el trabajo realizado por Paul Baran y otros en Rand Corporation en un estudio "Sobre las comunicaciones distribuidas" a principios de los años 1960. También es digno de mención el trabajo realizado por Donald Davies y otros en el Laboratorio Nacional de Física de Inglaterra a mediados de los años sesenta. ... Otro desarrollo importante de la red que afectó el desarrollo de ARPANET se llevó a cabo en el Laboratorio Nacional de Física en Middlesex, Inglaterra, bajo el liderazgo de DW Davies.
^ C. Hempstead; W. Worthington (2005). Enciclopedia de la tecnología del siglo XX. Rutledge . ISBN9781135455514. El grupo NPL también llevó a cabo trabajos de simulación en redes de paquetes.
^ Clarke, Peter (1982). Redes de datos con conmutación de circuitos y paquetes (PDF) (tesis doctoral). Departamento de Ingeniería Eléctrica, Imperial College of Science and Technology, Universidad de Londres."Además de la red de conmutación de paquetes construida en NPL para la comunicación entre sus instalaciones informáticas locales, se han realizado algunos experimentos de simulación en redes más grandes. Un resumen de este trabajo se presenta en [69]. El trabajo se llevó a cabo para investigar redes de un tamaño capaz de proporcionar instalaciones de comunicación de datos a la mayor parte del Reino Unido... Luego se llevaron a cabo experimentos utilizando un método de control de flujo ideado por Davies [70] llamado control de flujo "isarítmico"... El trabajo de simulación se llevó a cabo en. NPL ha sido, en muchos aspectos, más realista que la mayoría de los estudios teóricos de la red ARPA."
^ ab Pelkey, James. "Red 6.3 CYCLADES y Louis Pouzin 1971-1972". Capitalismo empresarial e innovación: una historia de las comunicaciones informáticas 1968-1988. Archivado desde el original el 17 de junio de 2021 . Consultado el 21 de noviembre de 2021 . Pouzin volvió a su tarea de diseñar una red de conmutación de paquetes más simple que Arpanet. ... [Davies] había realizado algunas simulaciones de redes de datagramas [de área amplia], aunque no había construido ninguna, y parecía técnicamente viable.
^ "El quinto hombre de Internet". Economista . 13 de diciembre de 2013 . Consultado el 11 de septiembre de 2017 . A principios de la década de 1970, Pouzin creó una red de datos innovadora que conectaba ubicaciones en Francia, Italia y Gran Bretaña. Su simplicidad y eficiencia señalaron el camino hacia una red que podría conectar no sólo docenas de máquinas, sino millones de ellas. Capturó la imaginación del Dr. Cerf y el Dr. Kahn, quienes incluyeron aspectos de su diseño en los protocolos que ahora alimentan Internet.
^ ab Scheblik, TJ, DB Dawkins y Agencia de Proyectos de Investigación Avanzada (1968). Solicitud de cotización para la red informática ARPA. Solicitud de Cotizaciones. Agencia de Proyectos de Investigación Avanzada (ARPA), Departamento de Defensa (DoD). (Copia en línea Archivada el 15 de agosto de 2011 en Wayback Machine ).
^ McQuillan, JM y DC Walden (1977). "Las decisiones de diseño de la red ARPA". En: Redes de computadoras 1.5, págs. 243–289. (Copia en línea). Basado en Crowther et al. (1975), que se basa en el Informe BBN 2918, que a su vez es un extracto del Informe BBN 2913, ambos de 1974.
^ Clark, DD (2007). Diseño de aplicaciones y argumentos de un extremo a otro. Reunión bianual del Programa Futuros de las Comunicaciones del MIT. Filadelfia, Pensilvania. 30 y 31 de mayo de 2007. Diapositivas de presentación. (Copia en línea).
^ Walden, CC (1972). "El procesador de mensajes de interfaz, sus algoritmos y su implementación". En: AFCET Journées d'Études: Réseaux de Calculateurs (Taller AFCET sobre redes informáticas). París, Francia. 25 y 26 de mayo de 1972. Association Française pour la Cybernétique Économique et Technique (AFCET). (Copia en línea).
^ McQuillan, JM (1973). Suma de comprobación de software en el IMP y confiabilidad de la red. RFC 528. Histórico. NWG.
^ Metcalfe, RM (1973). "Comunicación de paquetes". Tesis doctoral. Cambridge, MA: Universidad de Harvard. Copia en línea (edición revisada, publicada como MIT Laboratory for Computer Science Technical Report 114). Escrito principalmente en MIT Project MAC y Xerox PARC.
^ Bolt, Beranek y Newman Inc. (1974). Procesadores de mensajes de interfaz para la red informática Arpa. Informe BBN 2816. Informe técnico trimestral n.º 5, 1 de enero de 1974 al 31 de marzo de 1974. Bolt, Beranek y Newman Inc. (BBN). (Copia privada, cortesía de BBN).
^ ab Bärwolff, M. (2010). "Argumentos de un extremo a otro en Internet: principios, prácticas y teoría". Autoeditado en línea y a través de Createspace/Amazon (PDF, erratas, etc.)
^ Walden, DC (1974) Algunos cambios en IMP y en la interfaz IMP/Host. RFC 660. Histórico. NWG.
^ BBN (1974). Procesadores de mensajes de interfaz para la red informática Arpa. Informe BBN 2913. Informe técnico trimestral n.º 7, 1 de julio de 1974 al 30 de septiembre de 1974. Bolt, Beranek and Newman Inc. (BBN).
^ J. Kempf; R. Austein (marzo de 2004). El auge del medio y el futuro del extremo a extremo: reflexiones sobre la evolución de la arquitectura de Internet. Grupo de Trabajo de Red, IETF . doi : 10.17487/RFC3724 . RFC 3724.
^ "Arquitectura del protocolo CNF". Proyectos de enfoque . Winlab, Universidad de Rutgers. Archivado desde el original el 23 de junio de 2016 . Consultado el 23 de mayo de 2016 .
^ Ward, Mark (14 de septiembre de 2012). "Europa alcanza los antiguos límites de direcciones de Internet". Noticias de la BBC . Consultado el 28 de febrero de 2017 .
^ Steve Deering y Bob Hinden, copresidentes del grupo de trabajo de próxima generación de propiedad intelectual del IETF (6 de noviembre de 1999). "Declaración sobre la privacidad de las direcciones IPv6" . Consultado el 28 de febrero de 2017 .
^ "Programación orientada a la interacción basada en información: BSPL, el lenguaje de protocolo increíblemente simple" (PDF) . Consultado el 24 de abril de 2013 .