La filosofía de diseño de los protocolos de Internet de DARPA

David D. Clark * Instituto de

Tecnología de Massachusetts
Laboratorio de Ciencias de la Computación
Cambridge, MA. 02139

(Publicado originalmente en Proc. SIGCOMM '88, Computadora Comunicación sobre la revisión Vol. 18, No. 4,
Agosto de 1988 pp. 106-114)

Resumen
El conjunto de protocolos de Internet, TCP / IP, se propuso por primera vez
hace quince años. Fue desarrollado por la Agencia de Proyectos de
Investigación Avanzada de Defensa (DARPA), y se ha utilizado ampliamente
en los sistemas militares y comerciales. Mientras
ha habido papeles y
Arquitectura en las capas IP y TCP. Esto parece básico para el diseño,
sino que también no era una parte de la propuesta original. Estos
cambios en el diseño de Internet surgieron a través del patrón repetido
de implementación y las pruebas que se produjo antes de que se
establecen las normas. La arquitectura de Internet está todavía en
evolución. A veces, una nueva extensión desafía uno de los principios

especificaciones que describen el funcionamiento de los protocolos, a veces de diseño, pero en cualquier caso una comprensión de la historia del

es difícil deducir de éstas por eso que el protocolo es como es. Por ejemplo, diseño proporciona un contexto necesario para las extensiones de
el protocolo de Internet se basa en un modo sin conexión o datagrama de diseño actuales. La configuración de conexión de protocolos ISO
servicio. La motivación de esta ha sido mal interpretado en gran medida. también ha sido coloreado por la historia de la suite de Internet, por lo
Este documento intenta capturar algunos de los principios de razonamiento que la comprensión de la filosofía de diseño de Internet puede ser útil
que dio forma a los protocolos de Internet. para aquellos que trabajan con la norma ISO. En este trabajo se
cataloga un punto de vista de los objetivos originales de la arquitectura
de Internet,
1. Introducción
Durante los últimos 15 años 1 , la Advanced Research Projects Agency del
Departamento de Defensa de Estados Unidos ha sido el desarrollo de un
conjunto de protocolos para redes de conmutación de paquetes. Estos
protocolos, que incluyen el Protocolo de Internet (IP), y el Protocolo de 2. Objetivo Fundamental
Control de Transmisión (TCP), ahora son estándares del Departamento de
El objetivo de nivel superior para la Arquitectura de Internet DARPA fue
Defensa de Estados Unidos para la interconexión de redes, y son de uso
desarrollar una técnica eficaz para la utilización de multiplexado de redes
generalizado en el entorno de red comercial. los
interconectadas existentes. Algunos de elaboración es conveniente aclarar
Ideas
el significado de ese objetivo.
desarrollado en este esfuerzo han influido también en otros conjuntos de
protocolos, lo más importante es la configuración sin conexión de los
protocolos ISO 2,3,4. Los componentes de la Internet eran las redes, que iban a ser
interconectados para proporcionar algún servicio más grande. El objetivo
Si bien la información específica sobre los protocolos del Departamento de
original era conectar entre sí la original ARPANET 8 con la red de radio
Defensa es bastante generalizada 5,6,7, a veces es difícil determinar la
por paquetes ARPA 9,10, con el fin de dar a los usuarios en el acceso a la
motivación y la razón que ha llevado al diseño.
red de radio por paquetes a las grandes máquinas de servicio en la
ARPANET. En el momento en que se suponía que no habría otros tipos
De hecho, la filosofía de diseño ha evolucionado considerablemente de redes para la interconexión, aunque la red de área local aún no había
desde la primera propuesta a los estándares actuales. Por ejemplo, la surgido. Una alternativa a la interconexión de las redes existentes habría
idea de los datagramas o servicio sin conexión, no recibe un énfasis sido el diseño de un sistema unificado que incorpora una variedad de
particular en la primera
diferentes medios de transmisión, una
papel, pero ha llegado a ser el defin ing característica del protocolo.
Otro ejemplo es la estratificación de la
* Este trabajo fue apoyado en parte por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) bajo el Contrato No. N00014-83-K-0125

ACM SIGCOMM - 1- Revisión Comunicación ordenador

red multi-medios de comunicación. Si bien esto podría haber permitido un mayor
grado de integración, y por lo tanto mejor
rendimiento, se consideró que era necesario incorporar las
arquitecturas de red existentes entonces si Internet iba a ser útil en un
sentido práctico. Además, las redes representan
límites administrativos de
control, y era una ambición de este proyecto para enfrentarse con el problema
de la integración de una serie de entidades administradas por separado en
una utilidad común. La técnica seleccionada para la multiplexación era
conmutación de paquetes. Una alternativa tal como la conmutación de
circuitos se podría haber considerado, pero las aplicaciones que se
compatible, como inicio de sesión remoto, fueron naturalmente servido por el
paradigma de conmutación de paquetes, y las redes que iban a ser integrados
juntos en este proyecto fueron las redes de conmutación de paquetes. Así
conmutación de paquetes fue aceptada como un componente fundamental de
la arquitectura de Internet.
El aspecto final de este objetivo fundamental era el supuesto de la técnica
en particular para la interconexión de estas redes. Dado que la técnica de
tienda y de conmutación de paquetes hacia adelante, como se demuestra
en el proyecto DARPA anterior, el ARPANET, se entiende bien, la
hipótesis de nivel superior era que las redes se pueden interconectar por
una capa de conmutadores de paquetes de Internet, que fueron llamados
puertas de enlace.
A partir de estos supuestos viene la estructura fundamental de Internet: una
facilidad de comunicaciones de conmutación de paquetes en el que una serie
de redes distinguibles están conectados entre sí mediante procesadores de
comunicaciones de paquetes llamados pasarelas que implementan una tienda
y el algoritmo de reenvío de paquetes hacia adelante.
3. Objetivos de segundo nivel
El objetivo de nivel superior se indica en la sección anterior contiene la
palabra "eficaz", sin ofrecer ninguna definición de lo que una
interconexión eficaz debe lograr. La siguiente lista resume un conjunto
más detallado de los objetivos que se establecieron para la
arquitectura de Internet.
1. La comunicación por Internet debe continuar a pesar de la pérdida de las redes o
puertas de enlace.
2. Internet debe soportar múltiples tipos de
servicio de comunicaciones.
3. La arquitectura de Internet debe dar cabida a una
variedad de redes.
4. La arquitectura de Internet debe permitir distribuido
la gestión de sus recursos.
5. La arquitectura de Internet debe ser rentable.
ACM SIGCOMM
6. La arquitectura de Internet debe permitir anfitrión
adjunto con un bajo nivel de esfuerzo.
7. Los recursos utilizados en la arquitectura de Internet debe
se responsable.
Este conjunto de objetivos podría parecer ser nada más que una lista de
todas las características de la red deseables. Es importante entender que
estos objetivos son en orden de importancia,
y una red completamente diferente
arquitectura resultaría si la orden se cambió. Por ejemplo, desde esta red
fue diseñado para operar en un contexto militar, lo que implicaba la
posibilidad de un ambiente hostil, la supervivencia fue puesto como primer
objetivo, y la rendición de cuentas como un último gol. En tiempos de
guerra, uno es menos que ver con la contabilidad detallada de los recursos
utilizados que con reunir todos los recursos disponibles y de rápido
despliegue de ellas de una manera operativa. Mientras que los arquitectos
de Internet eran conscientes de la rendición de cuentas, el problema
recibido muy poca atención durante las primeras etapas del diseño, y sólo
ahora se está considerando. Una arquitectura principalmente para su
despliegue comercial colocaría claramente estos objetivos en el extremo
opuesto de la lista. Del mismo modo, el objetivo de que la arquitectura sea
rentable es claramente en la lista, pero por debajo de ciertos otros
objetivos, como la gestión distribuida, o el apoyo de una amplia variedad
de redes. Otros conjuntos de protocolos, incluyendo algunas de las
arquitecturas comerciales más populares, han sido optimizados para un
determinado tipo de red, por ejemplo una larga tienda de recorrido y la red
hacia adelante construida de líneas telefónicas de velocidad media, y
ofrecer una solución muy rentable en este contexto, a cambio de que se
trata un poco mal con otros tipos de redes, tales como redes de área local.
El lector debe considerar cuidadosamente la anterior lista de objetivos, y
reconocer que esto no es una lista "maternidad", sino un conjunto de
prioridades que colorean fuertemente las decisiones de diseño dentro de la
arquitectura de Internet. Las siguientes secciones discuten la relación entre
esta lista y las características de Internet.
4. Capacidad de supervivencia en la cara del fracaso
El objetivo más importante de la lista es que Internet debería seguir
suministrando servicio de comunicaciones, a pesar de que las redes y
pasarelas están fallando. En particular, este objetivo se interpreta en el
sentido de que si dos entidades se comunican a través de Internet, y un
poco de error hace que Internet sea interrumpida temporalmente y
reconfigurados para reconstituir el servicio, entonces las entidades
comunicantes debe ser capaz de continuar sin tener que restablecer o
restablecer el estado de alto nivel de la conversación. Más concretamente,
en la interfaz de servicio de la capa de transporte, esta arquitectura no
proporciona ninguna
- 2- Revisión Comunicación ordenador
facilidad para comunicarse con el cliente del servicio de transporte que
la sincronización entre el emisor y el receptor se puede haber perdido.
Era una suposición en esta arquitectura que la sincronización no se
perdería a menos que hubiera ninguna ruta física sobre la que se podría
conseguir cualquier tipo de comunicación. En otras palabras, en la parte
superior de transporte, sólo hay un fallo, y es partición total. La
arquitectura era para enmascarar por completo cualquier error
transitorio.
Para lograr este objetivo, la información de estado que describe el debe
protegerse conversación en curso. Los ejemplos específicos de la
información de estado serían el número de paquetes transmitidos, el
número de paquetes reconocido, o el número de pendientes permisos de
control de flujo. Si las capas inferiores de la arquitectura pierden esta
información, que no será capaz de saber si los datos se han perdido, y la
capa de aplicación tendrán que hacer frente a la pérdida de sincronía.
Esta arquitectura insistido en que esta interrupción se produce, lo que
significaba que la información de estado debe protegerse de la pérdida.
En algunas arquitecturas de red, este estado se almacena en los nodos
de conmutación de paquetes intermedios de la red. En este caso, para
proteger la información de pérdidas, se debe replicar. Debido a la
naturaleza distribuida de la replicación, algoritmos para asegurar la
replicación robusta son en sí mismos difíciles de construir, y pocas redes
con información de estado distribuido proporcionan ningún tipo de
protección contra el fracaso. La alternativa, que eligió esta arquitectura,
es tomar esta información y recogerlo en el punto final de la red, a la
entidad que está utilizando el servicio de la red. Yo llamo a este enfoque
de la fiabilidad "destino compartido." El modelo de compartición de
destino sugiere que
eso es aceptable perder el estado
La información asociada con una entidad si, al mismo tiempo, la propia
entidad se pierde. Específicamente, la información acerca de la
sincronización a nivel de transporte se almacena en el huésped que está
unido a la red y el uso de su servicio de comunicación.
Hay dos ventajas importantes para el destino de intercambio sobre la replicación. En
primer lugar, el destino de intercambio protege contra cualquier número de fallos
intermedios, mientras que la replicación sólo puede proteger contra un cierto número
(menor que el número de copias replicadas). En segundo lugar, el destino
compartido es mucho más fácil de diseñar que la replicación.
Hay dos consecuencias para el enfoque de destino de intercambio de
supervivencia. nodos En primer lugar, el paquete intermedio de conmutación,
o puertas de enlace, no debe tener ninguna información de estado esencial
acerca de las conexiones en curso. En cambio, son conmutadores de
paquetes sin estado, una clase de diseño de la red a veces llamado un
"datagrama" red. En segundo lugar, en vez más la confianza se coloca en la
máquina host que en una arquitectura donde la red asegura la entrega fiable
de datos. Si el residente de acogida
ACM SIGCOMM
algoritmos ese asegurar la secuenciación y
acuse de recibo de los datos fallan, se impide que las aplicaciones de la
máquina de la operación. A pesar del hecho de que la supervivencia es el
primer objetivo en la lista, sigue siendo en segundo lugar a la meta de nivel
superior de la interconexión de las redes existentes. Una tecnología más
capacidad de supervivencia podría ser el resultado de un único diseño de redes
multimedia. Por ejemplo, la Internet hace suposiciones muy débiles sobre la
capacidad de una red para informar que ha fallado. Internet está por lo tanto
obligado a detectar fallos en la red a través de mecanismos de nivel de
Internet, con el potencial para una detección de errores más lento y menos
específico.
5. Tipos de Servicio
El segundo objetivo de la arquitectura de Internet es que se debe apoyar, a
nivel de servicio de transporte, una variedad de tipos de servicio. Diferentes
tipos de servicio se distinguen por diferencias en los requisitos para cosas
tales como la velocidad, la latencia y fiabilidad. El tipo tradicional de servicio
es la entrega fiable bidireccional de datos. Este servicio, que a veces se
llama un servicio de "circuito virtual", es adecuada para aplicaciones tales
como acceso remoto o transferencia de archivos. Fue el primer servicio
prestado en la arquitectura de Internet, utilizando el protocolo de control de
transmisión (TCP) 11. Se reconoció pronto que incluso este servicio tenía
múltiples variantes, ya que el acceso remoto requiere un servicio con bajo
retardo en la entrega, pero bajos requerimientos de ancho de banda,
mientras que la transferencia de archivos estaba menos preocupado con
retraso, pero muy preocupados con un alto rendimiento. TCP intentó
proporcionar estos dos tipos de servicio. El concepto inicial de TCP era que
podía ser lo suficientemente general como para soportar cualquier tipo de
servicio necesaria. Sin embargo, como toda la gama de servicios necesarios
quedó claro, parecía demasiado difícil de conseguir apoyo para todos ellos
en un solo protocolo.
El primer ejemplo de un servicio fuera de la gama de TCP era soporte para
XNET 12, el depurador a través del Internet. TCP no parecía un transporte
adecuado para XNET por varias razones. En primer lugar, un protocolo
depurador no debe ser fiable. Esta conclusión puede parecer extraño, pero
en condiciones de estrés o el fracaso (que puede ser exactamente cuando
se necesita un depurador) pidiendo una comunicación fiable puede impedir
cualquier comunicación en absoluto. Es mucho mejor para construir un
servicio que puede hacer frente a lo recibe a través de, en lugar de insistir
en que cada byte enviado sea entregado en orden. En segundo lugar, si
TCP es lo suficientemente general para hacer frente a una amplia gama de
clientes, es de suponer algo complejo. Una vez más, parecía erróneo
esperar apoyo a esta complejidad en un entorno de depuración, que pueden
carecer incluso básica
- 3- Revisión Comunicación ordenador
servicios que se esperan en un sistema operativo (por ejemplo, apoyo
para los temporizadores.) Así XNET fue diseñado para funcionar
directamente en la parte superior del servicio de datagramas
proporcionada por Internet. Otro de los servicios que no encaja TCP
fue la entrega en tiempo real de voz digitalizada, que se necesita para
apoyar el aspecto de teleconferencia de aplicaciones de comando y
control. En voz digital en tiempo real, el requisito principal no es un
servicio fiable, sino un servicio que minimiza y alisa la demora en la
entrega de paquetes. La capa de aplicación está digitalizando la voz
analógica, empaquetar los bits resultantes, y enviarlos a través de la
red sobre una base regular. Ellos deben llegar al receptor en una base
regular con el fin de ser convertido de nuevo a la señal analógica. Si
los paquetes no llegan cuando se esperaba, es imposible volver a
montar la señal en tiempo real. Un sorprendente observación sobre el
control de la variación en el retardo es que la fuente más grave de
retraso en las redes es el mecanismo para proporcionar una entrega
fiable. Un protocolo típico de transporte fiable responde a un paquete
faltante solicitando una retransmisión y retrasar la entrega de los
paquetes subsiguientes hasta que el paquete perdido ha sido
retransmitido. Se suministra entonces ese paquete y todos los
restantes en la secuencia. El retraso mientras esto ocurre puede ser
muchas veces el tiempo de entrega de ida y vuelta de la red, y puede
alterar por completo el algoritmo de reensamblaje discurso. Por el
contrario, es muy fácil de hacer frente a un paquete que falta
ocasional. El discurso faltante simplemente se puede sustituir por un
corto período de silencio, que en la mayoría de los casos no perjudica
la inteligibilidad del discurso a la escucha humana. Si lo hace,
por lo tanto, se decidió, bastante temprano en el desarrollo de la
arquitectura de Internet, que sería necesario más de un servicio de
transporte, y la arquitectura debe estar preparado para tolerar
simultáneamente transportes que deseen limitar la fiabilidad, retardo, o
ancho de banda, como mínimo.
Este objetivo causada TCP e IP, que había sido originalmente un único
protocolo en la arquitectura, que se separó en dos capas. TCP
proporciona un tipo particular de servicio, el flujo de datos fiable
secuenciado, mientras que IP intentó proporcionar un bloque de
construcción básico de los cuales una gran variedad de tipos de servicio
podría ser construido. Este bloque de construcción fue el datagrama, que
también había sido adoptada para apoyar la supervivencia. Desde la
fiabilidad asociado con la entrega de un datagrama no estaba garantizada,
pero "mejor esfuerzo", que era posible construir fuera del datagrama un
servicio que era fiable (por reconocer y retransmitir a un nivel superior), o
un servicio que negocia fiabilidad para las características de retardo de
primitivas del sustrato red subyacente. El User Datagram
ACM SIGCOMM
Protocolo (UDP) 13 fue creado para proporcionar una interfaz applicationlevel al servicio de
datagramas básico de Internet. La arquitectura no deseaba asumir que las propias redes
subyacentes soportan múltiples tipos de servicios, ya que esto violaría el objetivo de utilizar
las redes existentes. En cambio, la esperanza era que varios tipos de servicio podrían ser
construidos fuera del bloque de construcción básico de datagramas usando algoritmos dentro
del huésped y la puerta de entrada. Por ejemplo, (aunque esto no se hace en la mayoría de
las implementaciones actuales) es posible tomar los datagramas que se asocian con un
retraso controlado pero el servicio no fiable y colocarlos a la cabeza de las colas de
transmisión a menos que su vida útil ha expirado, en cuyo caso se sería desechado; mientras
que los paquetes asociados con los flujos fiables serían colocados en la parte posterior de las
colas, pero nunca descartada, no importa cuánto tiempo habían estado en la red. Resultó más
difícil que la primera esperanza de proporcionar múltiples tipos de servicio sin el apoyo
explícito de las redes subyacentes. El problema más grave es que las redes diseñadas con un
tipo particular de servicio en mente no eran lo suficientemente flexible como para soportar
otros servicios. Por lo general, una red se han diseñado bajo el supuesto de que debería
ofrecer un servicio fiable, e inyectará retrasos como parte de la producción de un servicio
confiable, si no se desea este fiabilidad. El comportamiento de la interfaz definida por El
problema más grave es que las redes diseñadas con un tipo particular de servicio en mente
no eran lo suficientemente flexible como para soportar otros servicios. Por lo general, una red
se han diseñado bajo el supuesto de que debería ofrecer un servicio fiable, e inyectará
retrasos como parte de la producción de un servicio confiable, si no se desea este fiabilidad.
El comportamiento de la interfaz definida por El problema más grave es que las redes
diseñadas con un tipo particular de servicio en mente no eran lo suficientemente flexible como
para soportar otros servicios. Por lo general, una red se han diseñado bajo el supuesto de que
debería ofrecer un servicio fiable, e inyectará retrasos como parte de la producción de un
servicio confiable, si no se desea este fiabilidad. El comportamiento de la interfaz definida por
X.25, por ejemplo, implica una entrega fiable, y no hay manera de
desactivar esta función. Por lo tanto, aunque Internet funciona con éxito a
través de redes X.25 no puede entregar la variabilidad de servicio
deseado tipo en ese contexto. Otras redes que tienen un servicio de
datagramas intrínseca son mucho más flexibles en el tipo de servicio que
van a permitir, pero estas redes son mucho menos comunes,
especialmente en el contexto de largo recorrido.
6. Variedades de Redes
Era muy importante para el éxito de la arquitectura de Internet que sea
capaz de incorporar y utilizar una amplia variedad de tecnologías de red,
incluidas las instalaciones militares y comerciales. La arquitectura de
Internet ha tenido mucho éxito en el cumplimiento de este objetivo; que es
operado a través de una amplia variedad de redes, incluyendo redes de
larga distancia (la propia ARPANET y varias redes X.25), redes de área
local (Ethernet, ringnet, etc.), redes de radiodifusión por satélite
(El satélite DARPA Atlántico
Red 14,15 operando a 64 kilobits por segundo y la red vía satélite DARPA
Experimental Wideband, dieciséis
operando dentro de los Estados Unidos a los 3 megabits por segundo), redes de
radio por paquetes (la red DARPA radio por paquetes, así como un
experimental británica netas de radio por paquetes y una red desarrollada por
los operadores de radio aficionados), una variedad de enlaces en serie, que van
desde 1200
- 4- Revisión Comunicación ordenador
bit por segundas conexiones asíncronas a enlaces T1, y una variedad de
otras instalaciones ad hoc, incluyendo intercomputer autobuses y el
servicio de transporte proporcionado por las capas superiores de otras
suites de red, como HASP de IBM.
La arquitectura de Internet alcanza esta flexibilidad al hacer un
conjunto mínimo de suposiciones acerca de la función que ofrecerá la
red. El supuesto básico es que la red puede transportar un paquete o
datagrama. El paquete debe ser de un tamaño razonable, tal vez 100
bytes mínimo, y debe ser entregado con fiabilidad razonable pero no
perfecta. La red debe tener alguna forma adecuada de abordar si se
trata de más de un punto a punto de enlace.
Hay una serie de servicios que no están explícitamente asumida
desde la red. Estos incluyen la entrega fiable o se secuencian, difusión
o multidifusión a nivel de red, la clasificación de prioridades de
paquete transmitido, soporte para múltiples tipos de servicio, y el
conocimiento interno de los fallos, velocidades, o retrasos. Si ha sido
necesario estos servicios,
a continuación, con el fin
cabida a una red dentro de la Internet, sería necesario, ya sea que la
red soporta estos servicios directamente, o que el software de interfaz
de red proporciona mejoras para simular estos servicios en el punto
final de la red. Se consideró que esto era un enfoque indeseable, ya
que estos servicios tendrían que ser rediseñado y reimplantado para
cada red y cada interfaz de host único para todas las redes. Mediante
el diseño de estos servicios en el transporte, por ejemplo, la entrega
fiable a través de TCP, la ingeniería debe hacerse sólo una vez, y la
puesta en práctica debe hacerse sólo una vez para cada huésped.
Después de eso, la implementación de software de interfaz para una
nueva red suele ser muy simple.
7. Otros objetivos
Los tres objetivos discutidos hasta ahora eran los que tenían el impacto
más profundo en el diseño de la arquitectura. Los objetivos restantes, ya
que fueron menores en importancia, fueron tal vez menos efectiva
cumplidos o no tan completamente diseñados. El objetivo de permitir la
gestión distribuida de Internet sin duda se ha cumplido en ciertos aspectos.
Por ejemplo, no todas las puertas de enlace de Internet están
implementado y administrado por la misma agencia. Hay varios centros de
gestión diferentes dentro de Internet desplegada, cada uno operando un
subconjunto de las puertas de enlace, y hay un algoritmo de
encaminamiento divide en dos fases que permite pasarelas de diferentes
administraciones para intercambiar tablas de enrutamiento, a pesar de que
no confían completamente entre sí, y una variedad de algoritmos de
enrutamiento privadas utilizadas entre las puertas de enlace en una sola
administración. Del mismo modo, la
ACM SIGCOMM
diversas organizaciones que gestionan las pasarelas no son necesariamente las mismas
organizaciones que gestionan las redes a las que se unen las pasarelas. Por otro lado,
algunos de los problemas más importantes hoy en día Internet se refieren a la falta de
suficientes herramientas para la gestión distribuida, especialmente en el área de
enrutamiento. En la gran Internet está operando actualmente, las decisiones de
encaminamiento deben ser limitados por las políticas de uso de recursos. Hoy en día esto se
puede hacer sólo de manera muy limitada, lo que requiere la configuración manual de tablas.
Esto es propenso a errores y, al mismo tiempo no es suficientemente potente. El cambio más
importante en la arquitectura de Internet en los próximos años será probablemente el
desarrollo de una nueva generación de herramientas para la gestión de los recursos en el
contexto de múltiples administraciones. Está claro que, en ciertas circunstancias, la
arquitectura de Internet no produce tan rentable una utilización de los recursos de
comunicación costosos como una arquitectura más a la medida haría. Las cabeceras de los
paquetes de Internet son bastante largo (un encabezado típico es de 40 bytes), y si se envían
paquetes cortos, esta sobrecarga es evidente. El peor de los casos, por supuesto, es el single
paquetes de inicio de sesión remoto de caracteres, que llevan 40 bytes de cabecera y un byte
de datos. En realidad, es muy difícil para cualquier conjunto de protocolos para afirmar que
este tipo de intercambios se llevan a cabo con una eficiencia razonable. En el otro, grandes
paquetes extremas para la transferencia de archivos, tal vez con 1000 bytes de datos, tener
una sobrecarga para la cabecera de solamente cuatro por ciento. Otro la arquitectura de
a Internet no produce tan rentable una utilización de los recursos de comunicación costosos
como una arquitectura más a la medida haría. Las cabeceras de los paquetes de Internet son
bastante largo (un encabezado típico es de 40 bytes), y si se envían paquetes cortos, esta
sobrecarga es evidente. El peor de los casos, por supuesto, es el single paquetes de inicio de
sesión remoto de caracteres, que llevan 40 bytes de cabecera y un byte de datos. En realidad,
es muy difícil para cualquier conjunto de protocolos para afirmar que este tipo de intercambios
se llevan a cabo con una eficiencia razonable. En el otro, grandes paquetes extremas para la
transferencia de archivos, tal vez con 1000 bytes de datos, tener una sobrecarga para la
cabecera de solamente cuatro por ciento. Otro la arquitectura de Internet no produce tan
rentable una utilización de los recursos de comunicación costosos como una arquitectura más
posible
a la medida haría. Las cabeceras de losfuente de sonineficacia
paquetes de Internet bastante largo (un encabezado
es típico es de 40 byte
la retransmisión de paquetes perdidos. Dado que Internet no insiste en que
pueden recuperar la pérdida de paquetes a nivel de red, puede ser
necesario retransmitir un paquete perdido desde un extremo de la Internet
para el otro. Esto significa que
el paquete retransmitido puede atravesar varias redes que
intervienen un segundo tiempo, mientras que la recuperación a nivel
de red no generaría este tráfico de la repetición. Este es un ejemplo de
la compensación resultante de la decisión, se discutió anteriormente,
de la prestación de servicios a partir de los puntos finales. El código de
interfaz de red es mucho más simple, pero la eficiencia global es
potencialmente menos. Sin embargo, si la tasa de retransmisión es lo
suficientemente bajo (por ejemplo, 1%), entonces el coste incremental
es tolerable. Como regla básica para las redes incorporadas en la
arquitectura, la pérdida de un paquete de cada cien es bastante
razonable, pero una pérdida de un paquete de cada diez sugiere que
las mejoras de fiabilidad se añadirán a la red si se requiere ese tipo de
servicio. El costo de la fijación de un anfitrión de Internet es tal vez
algo mayor que en otras arquitecturas,
- 5- Revisión Comunicación ordenador
estrategias, se deben implementar en el huésped en lugar de en la
red. Inicialmente, a los programadores que no estaban familiarizados
con la implementación del protocolo, el esfuerzo de hacer esto parecía
un tanto desalentador. Los implementadores trataron tales cosas como
mover los protocolos de transporte a un procesador frontal, con la idea
de que los protocolos se implementan sólo una vez, en lugar de nuevo
para cada tipo de huésped. Sin embargo, esto requiere la invención de
un anfitrión con el protocolo de extremo delantero que algunos
pensaron casi tan complicado de implementar como el protocolo de
transporte original. A medida que aumenta la experiencia con los
protocolos, las ansias asociadas con la implementación de un conjunto
de protocolos dentro del huésped parecen estar disminuyendo, y las
implementaciones están ahora disponibles para una amplia variedad
de máquinas, incluyendo ordenadores personales y otras máquinas
con recursos informáticos muy limitadas. Un problema relacionado
derivados de la utilización de los mecanismos de acogida residente es
que la mala aplicación del mecanismo puede perjudicar a la red, así
como el anfitrión. Este problema se tolera, debido a que los
experimentos iniciales implicados un número limitado de
implementaciones huésped que podrían ser controlados. Sin embargo,
como el uso de Internet ha crecido, este problema ha aparecido de vez
en cuando de una manera seria. En este sentido, el objetivo de la
robustez, lo que llevó al método de fatesharing, lo que llevó a la sede
de residentes algoritmos, contribuye a una pérdida de solidez si el
anfitrión se comporta mal. El último gol fue la rendición de cuentas. De
hecho, la contabilidad se discutió en el primer artículo de Cerf y Kahn
como una función importante de los protocolos y gateways. Sin
embargo, en la actualidad, la arquitectura de Internet contiene algunas
herramientas para la contabilización de los flujos de paquetes.
8. arquitectura e implementación
La discusión anterior sugiere claramente que una de las metas de la
arquitectura de Internet fue proporcionar una amplia flexibilidad en el
servicio ofrecido. protocolos de transporte diferentes se podrían utilizar
para proporcionar diferentes tipos de servicio, y diferentes redes
podrían incorporarse. Dicho de otra manera, la arquitectura trató muy
duro para no limitar la gama de servicio que Internet podría ser
diseñada para ofrecer. Esto, a su vez, significa que para entender el
servicio que puede ser ofrecido por una aplicación particular de un
Internet, uno debe mirar no a la arquitectura, sino a la ingeniería real
del software dentro de los hosts y gateways particulares, y a lo
particular redes que han sido incorporadas. Voy a utilizar el término
"realización" de
ACM SIGCOMM
describir un conjunto particular de las redes, las pasarelas y los anfitriones
que han sido conectadas entre sí en el contexto de la arquitectura de
Internet. Realizaciones pueden diferir en varios órdenes de magnitud en el
servicio que ofrecen. Realizaciones se han construido a partir de 1200 bits
por segundo líneas telefónicas, y fuera de las redes únicamente con
velocidades superiores a 1 megabit por segundo. Claramente,
la
expectativas de rendimiento, que uno puede tener una de estas realizaciones difieren en
varios órdenes de magnitud. Del mismo modo, algunas realizaciones de Internet tienen
retrasos se miden en decenas de milisegundos, donde otros han retardos medidos en
segundos. Ciertas aplicaciones tales como el trabajo de voz en tiempo real fundamentalmente
diferente a través de estas dos realizaciones. Algunos Internets han sido diseñados de
manera que hay una gran redundancia en las pasarelas y caminos. Estos son Internets de
supervivencia, ya que existen recursos que pueden ser reconfigurado después de un fallo.
Otras realizaciones de Internet, para reducir el coste, tienen puntos únicos de conectividad a
través de la realización, de modo que un fallo puede particionar el Internet en dos mitades. La
arquitectura de Internet tolera esta variedad de realización por diseño. Sin embargo, que deja
el diseñador de una realización particular con una gran cantidad de ingeniería para hacer. Una
de las principales luchas de este desarrollo arquitectónico fue entender cómo dar orientación
al diseñador de una realización, la orientación que relacionar la ingeniería de la realización de
los tipos de servicio que resultarían. Por ejemplo, el diseñador debe responder a la siguiente
clase de pregunta. ¿Qué tipo de anchos de banda debe estar en las redes subyacentes, si el
servicio en general es entregar un rendimiento de un determinado índice? Dado un cierto
modelo de posibles fallos dentro de esta realización, qué tipo de redundancia debe ser por
ingeniería genética en la realización? La mayor parte de las ayudas de diseño de red
conocidas no parecía útil para responder a este tipo de preguntas. verificadores de protocolo,
Una de las principales luchas de este desarrollo arquitectónico fue entender cómo dar
orientación al diseñador de una realización, la orientación que relacionar la ingeniería de la
realización de los tipos de servicio que resultarían. Por ejemplo, el diseñador debe responder
a la siguiente clase de pregunta. ¿Qué tipo de anchos de banda debe estar en las redes
subyacentes, si el servicio en general es entregar un rendimiento de un determinado índice?
Dado un cierto modelo de posibles fallos dentro de esta realización, qué tipo de redundancia
debe ser por ingeniería genética en la realización? La mayor parte de las ayudas de diseño de
red conocidas no parecía útil para responder a este tipo de preguntas. verificadores de
protocolo, Una de las principales luchas de este desarrollo arquitectónico fue entender cómo
dar orientación al diseñador de una realización, la orientación que relacionar la ingeniería de
por
la realización de los ejemplo,
tipos de servicioayudar al confirmar
que resultarían. Por ejemplo, quedebe responder a la siguiente clase de pregu
el diseñador
protocolos cumplen con las especificaciones. Sin embargo, estas
herramientas casi nunca se ocupan de los problemas de rendimiento,
que son esenciales para la idea del tipo de servicio. En su lugar, se
ocupan de la idea mucho más restringido de corrección lógica del
protocolo con respecto a la especificación. Mientras que las
herramientas para verificar corrección lógica son útiles, tanto en la fase
de especificación e implementación, que no ayudan a los graves
problemas que surgen a menudo relacionados con el rendimiento. Una
experiencia típica aplicación es que incluso después de corrección
lógica se ha demostrado, fallos de diseño se descubren que pueden
causar una degradación del rendimiento de un orden de magnitud. La
exploración de este problema ha llevado a la conclusión de que la
dificultad se presenta generalmente, no en el propio protocolo, pero en
el sistema operativo en el que se ejecuta el protocolo. Siendo este el
caso,
- 6- Revisión Comunicación ordenador
especificación de la arquitectura. Sin embargo, todavía convencidos de
la necesidad de orientar a implementador. Seguimos luchando con
este problema hoy en día. La otra clase de ayuda diseño es el
simulador, que tiene una realización particular y explora el servicio que
se puede ofrecer bajo una variedad de cargas. sin embargo, nadie ha
intentado construir un simulador que tengan en cuenta la gran
variabilidad de la aplicación de puerta de enlace,
la aplicación host y el
rendimiento de la red, que se ve dentro de posibles realizaciones de
Internet. Por lo tanto, es el caso que el análisis de la mayoría de las
realizaciones de Internet se realiza en la parte posterior de un sobre. Es un
comentario en la estructura objetivo de la arquitectura de Internet que una
parte posterior del análisis sobre, si se hace por una persona con
conocimientos suficientes, suele ser suficiente. El diseñador de una
realización particular de Internet es generalmente menos interesado en la
obtención de la última cinco por ciento posible en utilización de la línea que
saber si el tipo de servicio deseado se puede lograr en todo dados los
recursos disponibles por el momento.
La relación entre la arquitectura y el rendimiento es extremadamente
difícil. Los diseñadores de la arquitectura de Internet tenía muy claro
que fue un grave error para asistir sólo para corrección lógica y pasar
por alto la cuestión de rendimiento. Sin embargo,
ellos
experimentado grandes dificultades en la formalización de cualquier aspecto
de la restricción de rendimiento dentro de la arquitectura. Estas dificultades se
presentaron tanto porque el objetivo de la arquitectura no era para limitar el
rendimiento, pero para permitir la variabilidad, y en segundo lugar (y tal vez
más fundamentalmente), ya que no parecía haber ninguna herramienta
formales útil para describir el rendimiento.
Este problema es especialmente agravante porque el objetivo del
proyecto de Internet era producir documentos de especificaciones que se
convertirían en las normas militares. Es un problema bien conocido con
la contratación del gobierno que no se puede esperar un contratista para
satisfacer cualquier criterio que no es una parte de la norma de
contratación. Si la Internet está preocupado por el rendimiento, por lo
tanto, era obligatorio que los requisitos de rendimiento pueden poner en
la especificación de adquisiciones. Fue trivial para inventar
especificaciones que limitaban el rendimiento, por ejemplo para
especificar que la aplicación debe ser capaz de pasar a 1.000 paquetes
por segundo. Sin embargo, este tipo de restricción no podría ser parte de
la arquitectura, y era, por tanto, depende de la persona que realiza la
adquisición de reconocer que estas restricciones de rendimiento se
deben agregar a la especificación, y para especificar de manera
adecuada para lograr una realización que proporciona los tipos de
servicio requeridos. No tenemos una buena idea de cómo ofrecer
orientación en la arquitectura de la persona que realiza esta tarea.
ACM SIGCOMM
9. Los datagramas
La característica fundamental de la arquitectura de Internet es el uso de
datagramas como la entidad que se transporta a través de las redes
subyacentes. Como se ha sugerido este trabajo, hay varias razones por las
que los datagramas son importantes dentro de la arquitectura. En primer
lugar, que eliminan la necesidad de estado de conexión dentro de los nodos
de conmutación intermedios, lo que significa que la Internet puede ser
reconstituido después de un fallo sin preocupación por el estado. En
segundo lugar, el datagrama proporciona un bloque de construcción básico
de que una variedad de tipos de servicio puede ser implementado. En
contraste con el circuito virtual, que por lo general implica un tipo fijo del
servicio, el datagrama ofrece un servicio más elemental que los puntos
finales pueden combinar según sea apropiado para construir el tipo de
servicio que se necesita. En tercer lugar, el datagrama representa el
supuesto servicio de red mínima, lo que ha permitido una amplia variedad
de redes a ser incorporados en diversas realizaciones de Internet. La
decisión de utilizar el datagrama fue sumamente exitosa, lo que permitió
Internet
conocer su mayor parte importantes objetivos muy
exitosamente.
Hay una suposición errónea a menudo asociado con los datagramas,
que es que la motivación para datagramas es el soporte de un servicio
de nivel superior, que es esencialmente equivalente a la de
datagramas. En otras palabras, a veces se ha sugerido que se
proporciona el datagrama porque el servicio de transporte que
requiere la aplicación es un servicio de datagramas. De hecho, esto es
raramente el caso. Mientras que algunas aplicaciones en Internet,
como las consultas simples de servidores de fecha o los servidores de
nombres, utilice un método de acceso basado en un datagrama poco
fiable, la mayoría de los servicios en Internet les gustaría un modelo
de transporte más sofisticado que la simple datagrama. Algunos
servicios les gustaría que el mayor fiabilidad, a algunos les gustaría el
retraso alisado y amortiguada, pero casi todos tienen una expectativa
más complejo que un datagrama.
10. TCP
Hubo varias decisiones de diseño interesantes y controvertidos en el
desarrollo de TCP, y el propio TCP pasó por varias versiones principales
antes de convertirse en un estándar razonablemente estable. Algunas de
estas decisiones de diseño, tales como la gestión de ventanas y la
naturaleza de la estructura de dirección del puerto, se tratan en una serie
de notas de implementación publicados como parte del manual de
protocolos TCP. 17,18 Pero una vez más la motivación de la decisión a veces
falta. En esta sección, intento de capturar algunos de los razonamientos
principios que entró en partes de TCP. Esta sección es necesariamente
incompleta; una
- 7- Revisión Comunicación ordenador
revisión completa de la historia de la propia TCP requeriría otro a continuación, esta inundación no podría haber ocurrido. Control a nivel de
artículo de esta longitud. paquete tiene el efecto, sin embargo, de proporcionar un límite severo en el
rendimiento si se envían paquetes pequeños. Si el host receptor especifica
El host-a ARPANET original de ordenadores de protocolo proporcionado de
un número de paquetes para recibir, sin ningún conocimiento del número de
control de flujo basado en los dos bytes y paquetes. Esto parecía demasiado
bytes en cada uno, la cantidad real de los datos recibidos puede variar en
complejo, y los diseñadores de TCP sentía que sólo una forma de regulación
un factor de 1000, dependiendo de si el host emisor pone uno o mil bytes
sería suficiente. La elección fue para regular la entrega de bytes, en lugar de
paquetes. El control de flujo y el reconocimiento de TCP se basa por tanto en
cada paquete. En retrospectiva, la decisión correcto diseño puede haber

el número de bytes en lugar de número de paquete. En efecto, sido que si TCP es proporcionar un apoyo eficaz de una variedad de
servicios, ambos paquetes y bytes deben ser regulados, como se hizo en

en TCP no hay ninguna importancia a la paquetización de los protocolos de ARPANET originales. Otra de las decisiones de diseño

los datos. relacionadas con el flujo de bytes era la bandera, o EOL el Término de la
Carta. Esto ahora ha desaparecido del protocolo, sustituido por la bandera
Esta decisión fue motivada por varias consideraciones, algunas de las
Push, o PSH. La idea original de EOL era romper el flujo de bytes en los
cuales se convirtieron en irrelevantes y otros de los cuales eran más
registros. Fue implementado, poniendo los datos de los registros separados
importantes que lo anticipado. Una de las razones para reconocer bytes era
en paquetes separados, que no era compatible con la idea de combinar los
permitir la inserción de información de control en el espacio de la secuencia
paquetes de retransmisión. Así que la semántica de EOL se cambió a una
de bytes, por lo que el control, así como los datos podrían ser reconocidos.
forma más débil, es decir, sólo que los datos hasta este punto en la
Que el uso del espacio de secuencia se ha caído, en favor de las técnicas
corriente fue de uno o más elementos completos a nivel de aplicación, lo
ad hoc para tratar con cada mensaje de control. Si bien la idea original ha
que debería ocasionar una descarga de cualquier búfer interno de TCP o de
abrogación generalidad, que causó la complejidad en la práctica. Una
la red. Al decir "uno o más" en lugar de "exactamente una", se hizo posible
segunda razón para el flujo de bytes era permitir que el paquete TCP se
combinar varios juntos y mantener el objetivo de compactar los datos en el
divide en paquetes más pequeños si es necesario con el fin de pasar a
montaje. Pero la semántica más débiles hecho que varias aplicaciones
través de una red con un tamaño pequeño paquete. Sin embargo, esta
tuvieron que inventar un mecanismo ad hoc para la delimitación de los
función se trasladó a la capa IP cuando se dividió IP de TCP e IP se vio
registros en la parte superior del flujo de datos. En esta evolución de la
obligado a inventar un método diferente de fragmentación. Una tercera
semántica RFL, había una forma intermedia poco conocido, que genera
razón para el reconocimiento de bytes en lugar de paquetes era permitir
gran debate. Dependiendo de la estrategia de amortiguación del anfitrión, el
que una serie de pequeños paquetes que se reunió en un solo paquete más
modelo de flujo de bytes de TCP puede causar grandes problemas en un
grande en el envío de acogida si la retransmisión de los datos fue
caso improbable. Considere un huésped en el que se pone los datos de
necesario. No estaba claro si esta ventaja sería importante; que resultó ser
entrada en una secuencia de tampones de tamaño fijo. Un tampón se
crítico. Los sistemas como UNIX que tienen un modelo de comunicación
devuelve al usuario, ya sea cuando está lleno, o se recibe un EOL.
interna basada en las interacciones de un solo carácter a menudo envían
Consideremos ahora el caso de la llegada de un paquete fuera de orden
muchos paquetes con un byte de datos en ellos. (Uno podría argumentar
que está tan lejos de fin de estar más allá del búfer en uso. Consideremos
desde una perspectiva de red que este comportamiento es tonto, pero era
ahora, además, que después de recibir este paquete fuera de orden, un
una realidad y una necesidad para el acceso remoto interactivo.) A menudo
paquete con un EOL provoca que la memoria intermedia actual para ser
Se observó que una gran cantidad de este tipo podría producir una
devuelto al usuario sólo parcialmente lleno. Esta secuencia particular de
inundación de paquetes con un byte de datos, la cual llegaría mucho más
acciones tiene el efecto de hacer que la salida de datos de la orden en la
rápido que una serie lenta podría procesarlos. El resultado es la pérdida de
siguiente memoria intermedia para estar en el lugar equivocado, a causa de
paquetes y retransmisión. Si la retransmisión era de los paquetes originales,
los bytes vacíos en el búfer devuelto al usuario. El hacer frente a esto
el mismo problema se repite en cada retransmisión, con un impacto en el
generó problemas teneduría de libros en el huésped, que parecía
rendimiento tan intolerable como para evitar la operación. Pero dado que
innecesario. Para hacer frente a esto, se propuso que la EOL debe "agotar"
los bytes se habían reunido en un paquete para la retransmisión, la
toda la secuencia espacio hasta el siguiente valor que era cero mod el
retransmisión se produjo de una manera mucho más eficaz que permitió el
tamaño del búfer. En otras palabras, se propuso que EOL debe ser una
funcionamiento práctico.
herramienta para mapear el flujo de bytes a la gestión de memoria
intermedia del huésped.

Por otro lado, el reconocimiento de bytes podría ser visto como la

creación de este problema en primer lugar. Si la base de control de flujo
había sido paquetes en lugar de bytes,

ACM SIGCOMM - 8- Revisión Comunicación ordenador

Esta idea no fue bien recibida en el momento, ya que parecía demasiado ad
hoc, y sólo un host parecía tener este problema. * En retrospectiva, puede
haber sido la idea correcta de incorporar en TCP algún medio de relacionar
el espacio de secuencia y el algoritmo de gestión de memoria intermedia del
huésped. En ese momento, los diseñadores simplemente carecían de la
visión para ver cómo podría hacerse de una manera bastante general.
11. Conclusión
En el contexto de sus prioridades, la arquitectura de Internet ha tenido
mucho éxito. Los protocolos son ampliamente utilizados en el entorno
comercial y militar, y han dado lugar a una serie de arquitecturas
similares. Al mismo tiempo, su éxito ha dejado claro que en ciertas
situaciones, las prioridades de los diseñadores no se ajustan a las
necesidades de los usuarios reales. Más atención a cosas tales como la
contabilidad,
gestión de recursos y
Se necesitan funcionamiento de las regiones con administraciones separadas.
Mientras que el datagrama ha servido muy bien en la solución de los
objetivos más importantes de Internet, no ha servido tan bien cuando
tratamos de abordar algunos de los objetivos que eran más abajo en la
lista de prioridades. Por ejemplo, los objetivos de la gestión de
recursos y la rendición de cuentas han demostrado ser difíciles de
conseguir en el contexto de los datagramas. Como la sección anterior
información no sería crítico para mantener el tipo deseado de servicio
asociada con el flujo. En su lugar, ese tipo de servicio sería aplicada por
los puntos finales, lo que enviar periódicamente mensajes para asegurar
que el tipo adecuado de servicio estaba siendo asociada con el flujo. De
esta manera, la información de estado asociada con el flujo podría
perderse en un accidente sin interrupción permanente del servicio que
está utilizando características. Yo llamo a este concepto "estado blando",
y es muy posible que nos permita lograr nuestros objetivos primarios de
supervivencia y flexibilidad, mientras que al mismo tiempo haciendo un
mejor trabajo de hacer frente a la cuestión de la gestión de recursos y la
rendición de cuentas. La exploración de los bloques de construcción
alternativos constituyen una de las direcciones actuales de investigación
dentro del programa DARPA Internet.
12. Agradecimientos - una perspectiva
histórica
Sería imposible reconocer a todos la
contribuyentes al proyecto de Internet; ha habido literalmente cientos
más de los 15 años de desarrollo: diseñadores, ejecutores, escritores
y críticos. De hecho, un tema importante, que probablemente merece
un artículo en sí mismo, es el proceso mediante el cual se logró este
proyecto. Los participantes procedían de universidades, laboratorios
de investigación y las empresas, y se unieron (hasta cierto punto) para

discutido, la mayoría de los datagramas son una parte de alguna lograr este objetivo común. La visión original de TCP vino de Robert

secuencia de paquetes desde la fuente al destino, en lugar de
unidades aisladas en el nivel de aplicación. Sin embargo, la puerta de
enlace no puede ver directamente la existencia de esta secuencia, ya
que se ve obligado a hacer frente a cada paquete en el aislamiento.
Por lo tanto, las decisiones de gestión de recursos o la contabilidad se
debe realizar en cada paquete por separado.
Kahn y Vinton Cerf, que vio muy claramente, en 1973, cómo un
protocolo con características adecuadas podría ser el pegamento que
reunir las distintas tecnologías de red emergentes. Desde su posición
en DARPA, que guían el proyecto en sus primeros días hasta el punto
en TCP e IP se convirtieron en estándares para el Departamento de
Defensa. El autor de este trabajo se unió al proyecto en los mid70s,

Esto sugiere que puede haber un mejor bloque de construcción que el

datagrama de la próxima generación de
arquitectura. La característica general de este bloque de construcción es
que sería identificar una secuencia de paquetes que viajan desde la
fuente hasta el destino, sin asumir cualquier tipo particular de servicio con
ese servicio. He utilizado la palabra "flujo" para caracterizar este bloque
referencias
de construcción. Sería necesario que las puertas de enlace tengan estado
de flujo con el fin de recordar la naturaleza de los flujos que están
pasando a través de ellos, pero el estado
1. V. Cerf, y R. Kahn, "Un protocolo para la red de paquetes de
intercomunicación", IEEE Transactions on Communications, Vol.
22, No. 5, mayo de 1974, pp. 637-648.
* Este uso de la EOL se llama propiamente "Caucho EOL", pero sus detractores rápidamente llamó
"goma de amortiguación parachoques bebé" en un intento de ridiculizar la idea. Crédito debe ir al
2. ISO, "Transporte Protocolo de Especificaciones", Tech. informe
creador de la idea, Bill Plummer, para pegarse a sus armas de fuego en la cara de los detractores
diciendo que el anterior a él diez veces rápido.
IS-8073, Organización Internacional de Normalización,
septiembre de 1984.

ACM SIGCOMM - 9- Revisión Comunicación ordenador

3. ISO, "Protocolo para la Prestación de Servicio de Red
ConnectionlessMode '', Tech. DIS8473 informe de la Organización
Internacional de Normalización, 1986
4. R. Callon, "Protocolo de Internetwork '', Procedimientos de
IEEE, Vol. 71, No. 12, diciembre de 1983, pp. 1388-1392.
5. Jonathan B. Postel "Protocolo Internetwork Enfoques", IEEE
Transactions on Communications, Vol. Com-28, N ° 4, abril
de 1980, pp. 605-611.
16. W.Edmond. S Blumenthal. A.Echenique, S.Storch,
T.Calderwood y T.Rees, '' The Butterfly satélite IMP para la Red de
paquetes de banda ancha por satélite '',
Actas de la ACM SIGCOMM '86, ACM, Stowe, Vt., Agosto
1986, pp. 194-203.
17. David D. Clark, '' Ventana y Estrategia Reconocimiento en TCP
NIC-RFC-813" , Protocolo DDN
Manual, Vol. 3, julio de 1982, pp. 3-5 a 3-26.
18. David D. Clark, "Nombre, direcciones, puertos y rutas
NIC-RFC-814' ', DDN Manual del Protocolo,
Vol. 3, julio de 1982, pp. 3-27 a 3-40.

6. Jonathan B. Postel, Carl A. Sol, Danny Cohen, "El Protocolo de

Internet ARPA '', Red de computadoras 5, Vol. 5, No. 4, julio de
1981 pp. 261-271.

7. Alan Sheltzer, Robert Hinden, y Mike Brescia, "Conexión de

diferentes tipos de redes con puertas de enlace", Transmisión
de datos, De agosto de 1982.

8. J. McQuillan y D. Walden, "Las decisiones ARPA Red de

Diseño", Red de computadoras, Vol. 1, No. 5, agosto de 1977,
pp. 243-289.

9. R .E. Kahn, S .A. Gronemeyer, J. Burdifiel, EV Hoversten, "Los

avances en la tecnología de radio por paquetes '', Actas de la
IEEE, Vol. 66, No. 11, noviembre de 1978, pp. 1408-1496.

10. BM Leiner, DL Nelson, FA Tobagi, '' Problemas en Packet Radio

Diseño", Actas de la IEEE,
Vol. 75, No. 1. enero de 1987, pp. 6-20.

11. -, '' Transmission Control Protocol RFC-793" , DDN

Manual del Protocolo, Vol. 2, septiembre de 1981, pp.
2,179-2,198.

12. Jack Haverty, "Formatos XNET para Protocolo de Internet

versión 4 IEN 158 '', Protocolo DDN
Manual, Vol. 2, octubre de 1980, pp. 2-345 a 2-
348.

13. Jonathan Postel, “Protocolo de datagramas de usuario

NICRFC-768”, DDN Manual del Protocolo, Vol. ' .
Agosto de 1980, pp. 2,175-2,177.

14. I. Jacobs, R. Binder, y E. Hoversten, el propósito general de

paquetes de redes de satélite" Actas
del IEEE, Vol. 66, No. 11, noviembre de 1978, pp. 1448-1467.

15. C. Topolcic y J. Kaiser, "El Sistema de Control de SATNET

'', Actas del IEEE baldosas
MILCOM, Boston, MA, Octubre de 1985, pp.
26.1.1-26.1.9.

ACM SIGCOMM - 10- Revisión Comunicación ordenador