stringtranslate.com

Principio de extremo a extremo

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 Paul Baran y 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 por 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 extremo a extremo 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 que capturan la esencia del posterior principio de extremo a extremo. Para citar un artículo de Baran de 1964, "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  De manera similar, Davies señala sobre el control de errores de extremo a extremo: "Se cree que todos los usuarios de la red se proporcionarán algún tipo de control de errores y que sin dificultad esto podría lograrse para mostrar un error faltante". 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 varias de las nociones básicas previamente abordadas por Baran y Davies.

Davies había trabajado en la simulación de redes de datagramas . [11] [12] Partiendo de esta idea, la red CYCLADES de Louis Pouzin fue la primera en implementar datagramas y hacer que los hosts fueran responsables de la entrega confiable de datos, en lugar de ser un servicio centralizado de la red misma. [1] Los conceptos implementados en esta red influyeron en la arquitectura TCP/IP . [13]

Aplicaciones

ARPANET

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:
  1. 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
  2. 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." [16] : 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 argumento sólido 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 . [24] 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. [25]

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 . [26] 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. [27]

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 [28] 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.

Ver también

Notas

  1. ^ El artículo de 1981 [2] se publicó en TOCS de ACM en una versión actualizada en 1984. [3] [4]
  2. ^ 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 desempeño 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 característica del desempeño). 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).
  3. ^ 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]
  4. ^ 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)".
  5. ^ 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.
  6. ^ 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).
  7. ^ De acuerdo con la RFQ de ARPANET [14] (págs. 47 y siguientes), ARPANET separó conceptualmente ciertas funciones. Como señala BBN en un artículo de 1977: [15] "[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 varios mensajes sean 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 línea interrumpida, puede haber duplicados. El procedimiento de transmisión de origen a destino de la red ARPA consiste en reordenar los 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. acuse de finalización. (p. 284) ".
  8. ^ 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 de otra manera 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". [14] : 25 
  9. ^ 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". [17] : 11 
  10. ^ 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 verificació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. Hemos tenido que reevaluar esta posición a la luz de nuestra experiencia. [18] : 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. " [19] : 7–28  Véase también el Informe BBN 2816 [20] : 10 y siguientes  para obtener más información sobre las experiencias adquiridas en los primeros años de funcionamiento de ARPANET.
  11. ^ 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 obtienen 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 dichos mecanismos por sí mismos). Para un recuento del debate de aquel momento, véase Bärwolff 2010, [21] págs. 56-58 y las notas allí contenidas, especialmente las notas 151 y 163.
  12. ^ 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), [22] 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 [23] en págs. 55 y siguientes). Véase también Bärwolff 2010, [21] págs. 80-84 y las copiosas notas que contiene.

Referencias

  1. ^ 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 .
  2. ^ 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.
  3. ^ abcdef JH Saltzer ; Caña DP ; DD Clark (1 de noviembre de 1984). "Argumentos de un extremo a otro en el diseño de sistemas" (PDF) . Transacciones ACM en sistemas informáticos . 2 (4): 277–288. doi :10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Wikidata  Q56503280 . Consultado el 5 de abril de 2022 .
  4. ^ 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).
  5. ^ 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.
  6. ^ 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).
  7. ^ 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).
  8. ^ 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.
  9. ^ Barán, P. (1964). "Sobre redes de comunicaciones distribuidas". En: IEEE Transactions on Communications 12.1, págs. 1–9.
  10. ^ 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.
  11. ^ C. Hempstead; W. Worthington (2005). Enciclopedia de la tecnología del siglo XX. Rutledge . ISBN 9781135455514. El grupo NPL también llevó a cabo trabajos de simulación en redes de paquetes.
  12. ^ 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 . Había realizado algunas simulaciones de redes de datagramas, aunque no había construido ninguna, y parecía técnicamente viable.
  13. ^ "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.
  14. ^ 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 ).
  15. ^ 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.
  16. ^ 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).
  17. ^ 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).
  18. ^ McQuillan, JM (1973). Suma de comprobación de software en el IMP y confiabilidad de la red. RFC  528. Histórico. NWG.
  19. ^ 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.
  20. ^ 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 and Newman Inc. (BBN). (Copia privada, cortesía de BBN).
  21. ^ 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.)
  22. ^ Walden, DC (1974) Algunos cambios en IMP y en la interfaz IMP/Host. RFC  660. Histórico. NWG.
  23. ^ 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).
  24. ^ 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.
  25. ^ "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 .
  26. ^ 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 .
  27. ^ 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 .
  28. ^ "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 .