ADMINISTRACION DE REDES

RESUMEN

Roberto Alvarado De La Cruz

Si las entidades de transporte en muchas máquinas envían demasiados paquetes a la red con exagerada rapidez, ésta se congestionará y se degradará el desempeño a medida que se retrasen y pierdan paquetes.El proceso de controlar la congestión para evitar este problema es la responsabilidad combinada de las capas de red y de transporte. La congestión ocurre en los enrutadores, por lo que se detecta en la capa de red. Sin embargo, se produce en última instancia debido al tráfico que la capa de transporte envía a la red.La única manera efectiva de controlar la congestión es que los protocolos de transporte envíen paquetes a la red con más lentitud.

6.3.1 Asignación de ancho de banda deseable

Se trata de encontrar una buena asignación de ancho de banda a las entidades de transporte que utilizan la red. Una buena asignación producirá un buen desempeño, ya que utiliza todo el ancho de banda disponible pero evita la congestión, tratará con igualdad a las entidades de transporte que compitan entre sí, y rastreará con rapidez los cambios en las demandas de tráfico.

Eficiencia y potencia

Una asignación eficiente del ancho de banda entre las entidades de transporte utilizará toda la capacidad disponible de la red.Tanto para el caudal útil como para el retardo, el desempeño se empieza a degradar cuando comienza la congestión. Por instinto, obtendremos el mejor desempeño de la red si asignamos ancho de banda hasta el punto en que el retardo empieza a aumentar con rapidez. Este punto está por debajo de la capacidad.Para identificarlo, Kleinrock (1979) propuso la métrica de potencia, en donde

Potencia = Carga/Retardo

En un principio la potencia aumentará con la carga ofrecida, mientras el retardo permanezca en un valor pequeño y aproximadamente constante, pero llegará a un máximo y caerá a medida que el retardo aumente con rapidez. La carga con la potencia más alta representa una carga eficiente para que la entidad de transporte la coloque en la red.

Equidad máxima-mínima

Si la red proporciona a un emisor cierta cantidad de ancho de banda para que la utilice, el emisor debe usar sólo esa cantidad de ancho de banda. Sin embargo, es común el caso en que las redes no tienen una reservación estricta de ancho de banda para cada flujo o conexión. Tal vez sí la tengan para algunos flujos en los que se soporta la calidad del servicio, pero muchas conexiones buscarán usar el

ancho de banda que esté disponible o la red las agrupará bajo una asignación comúnUna segunda consideración es lo que significa una porción equitativa para los flujos en una red. Es lo bastante simple si N flujos usan un solo enlace, en cuyo caso todos pueden tener 1/N parte del ancho de banda (aunque la eficiencia dictará que deben usar un poco menos, si el tráfico es en ráfagas). La forma de equidad que se desea con frecuencia para el uso de red es la equidad máxima-mínima. Una asignación tiene equidad máxima-mínima si el ancho de banda que se otorga a un flujo no se puede incrementar sin tener que disminuir el ancho de banda otorgado a otro flujo con una asignación que no sea mayor. Esto es, si se incrementa el ancho de banda de un flujo, la situación sólo empeorará para los flujos con menos recursos.Las asignaciones máxima-mínima se pueden calcular con base en un conocimiento global de la red.Una forma intuitiva de pensar sobre ellas es imaginar que la tasa para todos los flujos empieza en cero y se incrementa lentamente. Cuando la tasa llega a un cuello de botella para cualquier flujo, entonces ese flujo deja de incrementarse. Los demás flujos seguirán incrementándose y compartirán la capacidad disponible por igual, hasta que también lleguen a sus respectivos cuellos de botella.Una tercera consideración es el nivel sobre el cuál una red se puede considerar equitativa: al nivel de las conexiones, de las conexiones entre un par de hosts o de todas las conexiones por host.Lo más común es considerar la equidad por conexión, pero por lo general no es imprescindible una equidad precisa. Es más importante en la práctica que ninguna conexión se quede sin ancho de banda, a que todas las conexiones reciban la misma cantidad exacta de ancho de banda. De hecho, con TCP es posible abrir varias conexiones y competir por el ancho de banda en forma más agresiva. Esta táctica la utilizan aplicaciones que requieren grandes cantidades de ancho de banda, como BitTorrent para compartir archivos de igual a igual.

Convergencia

Un último criterio es que el algoritmo de control de congestión debe converger rápidamente hacia una asignación equitativa y eficiente del ancho de banda.Debido a la variación en la demanda, el punto de operación ideal para la red varía con el tiempo. Un buen algoritmo de control de congestión debe converger con rapidez hacia el punto de operación ideal; y debe rastrear ese punto a medida que cambia con el tiempo. Si la convergencia es muy lenta, el algoritmo nunca estará cerca del punto de operación cambiante. Si el algoritmo no es estable, puede fracasar al tratar de converger hacia el punto correcto en algunos casos, o incluso puede oscilar alrededor del punto correcto.

6.3.2 Regulación de la tasa de envío

Podemos limitar la tasa de envío mediante dos factores. El primero es el control de flujo, en el caso en que haya un uso insuficiente de búfer en el receptor. El

segundo es la congestión, en el caso en que haya una capacidad insuficiente en la red.La forma en que un protocolo de transporte debe regular la tasa de envío depende de la forma de retroalimentación que devuelva la red. Las distintas capas de la red pueden devolver distintos tipos de retroalimentación, la cual puede ser explícita o implícita, y también precisa o imprecisa.Un ejemplo de un diseño explícito y preciso es cuando los enrutadores indican a las fuentes la velocidad a la que pueden enviar. Los diseños en la literatura, como XCP (Protocolo Explícito de Congestión, del inglés eXplicit Congestion Protocol ), operan de esta forma (Katabi y colaboradores, 2002).Un diseño explícito e impreciso es el uso de ECN (Notificación Explícita de Congestión, del inglés Explicit Congestion Notification) con TCP. En este diseño, los enrutadores establecen bits en paquetes que experimentan congestión para advertir a los emisores que reduzcan la velocidad, pero no les dicen cuánto deben reducirla.

Si se proporciona una señal explícita y precisa, la entidad de transporte puede usarla para ajustar su tasa con el nuevo punto de operación. Por ejemplo, si XCP indica a los emisores la tasa que deben usar, éstos simplemente usarán esa tasa. Sin embargo, en los otros casos se requieren algunas conjeturas.A falta de una señal de congestión, los emisores deben reducir sus tasas. Cuando se proporcione una señal de congestión, los emisores deben reducir sus tasas. La forma en que se deben aumentar o reducir las tasas se proporciona mediante una ley de control. Estas leyes tienen un efecto importante en el desempeño.

6.3.3 Cuestiones inalámbricas

Los protocolos de transporte como TCP que implementan control de congestión deben ser independientes de la red subyacente y de las tecnologías de capa de enlace. Es una buena teoría, pero en la práctica hay problemas con las redes inalámbricas. La cuestión principal es que la pérdida de paquetes se usa con frecuencia como señal de congestión, incluyendo a TCP como vimos antes. Las

redes inalámbricas pierden paquetes todo el tiempo debido a errores de transmisión.

Para funcionar bien, las únicas pérdidas de paquetes que debe observar el algoritmo de control de congestión son las pérdidas debido a un ancho de banda insuficiente, no las pérdidas debido a errores de transmisión. Una solución a este problema es enmascarar las pérdidas inalámbricas mediante el uso de retransmisiones a través del enlace inalámbrico. Por ejemplo, 802.11 usa un protocolo de parada y espera para entregar cada trama, y reintenta las transmisiones varias veces si es necesario antes de reportar la pérdida de un paquete a la capa superior. En el caso normal, cada paquete se entrega a pesar de los errores de transmisión transitorios que no son visibles para las capas superiores.

La estrategia de enmascaramiento es suficiente para permitir que la mayoría de los protocolos de transporte operen bien a través de la mayoría de los enlaces inalámbricos. Sin embargo, no siempre es una solución adecuada. Algunos enlaces inalámbricos tienen tiempos de ida y vuelta largos, como los satélites. Para estos enlaces se deben usar otras técnicas para enmascarar la pérdida, como FEC (Corrección de Errores hacia Adelante), o el protocolo de transporte debe usar una señal que no sea de pérdida para el control de congestión.Un segundo aspecto relacionado con el control de congestión a través de enlaces inalámbricos es la capacidad variable. Esto es, la capacidad de un enlace inalámbrico cambia con el tiempo, algunas veces en forma brusca, a medida que los nodos se desplazan y la relación señal —ruido varía con las condiciones cambiantes del canal. Esto es distinto a los enlaces cableados, cuya capacidad es fija. El protocolo de transporte se debe adaptar a la capacidad cambiante de los enlaces inalámbricos; de lo contrario se congestionará la red o no se podrá usar la capacidad disponible.Una posible solución a este problema es simplemente no preocuparse por ello. Esta estrategia es viable, puesto que los algoritmos de control de congestión ya deben manejar el caso en que nuevos usuarios entren a la red, o que los usuarios existentes cambien sus tasas de envío. Aun cuando la capacidad de los enlaces cableados es fija, el comportamiento cambiante de otros usuarios se presenta a sí mismo como una variabilidad en el ancho de banda que está disponible para un usuario dado. Por ende, es posible usar TCP a través de una ruta con un enlace inalámbrico 802.11 y obtener un desempeño razonable.

6.6 Aspectos Del Desempeño

Cuando hay cientos o miles de computadoras conectadas entre sí, son comunes las interacciones complejas, con consecuencias imprevisibles. Con frecuencia, esta complejidad conduce a un desempeño pobre, sin que nadie sepa por qué.

6.6.1 Problemas de desempeño en las redes de computadoras

Las sobrecargas también se pueden desencadenar en forma sincrónica. Por ejemplo, si un segmento contiene un parámetro erróneo (por ejemplo, el puerto al que está destinado), en muchos casos el receptor devolverá con amabilidad una notificación de error.

La tormenta de difusión resultante podría paralizar la red. UDP sufrió de este problema hasta que se cambió el protocoloICMP para hacer que los hosts evitaran responder a errores en los segmentos UDP enviados a direcciones de difusión. Las redes inalámbricas deben tener especial cuidado en evitar las respuestas de difusión no verificadas, debido a que la difusión ocurre en forma natural y el ancho de banda inalámbrico es limitado.

6.6.2 Medición del desempeño de las redes

Cuando una red tiene un desempeño pobre, con frecuencia sus usuarios se quejan con los operadores y les exigen mejoras. Para mejorar el desempeño, los operadores deben primero determinar exactamente lo que ocurre. Para averiguar qué está ocurriendo en realidad, deben efectuar mediciones.

Las mediciones se pueden hacer de muchas maneras y en muchos lugares (tanto físicos como en la pila de protocolos). El tipo de medición más básico es iniciar un temporizador al empezar alguna actividad y medir el tiempo que tarda esa actividad.

Asegúrese que el tamaño de la muestra sea lo bastante grandeNo mida el tiempo para enviar un segmento; mejor repita la medición (por ejemplo, un millón de veces) y obtenga el promedio. Los efectos iniciales, como cuando la NIC 802.16 o el módem de cable obtienen una reservación de ancho de banda después de un periodo de inactividad, pueden reducir la velocidad del primer segmento, además de que el encolamiento introduce la variabilidad.

Asegúrese de que las muestras sean representativasLo ideal sería que la secuencia total de un millón de mediciones se repitiera a distintas horas del día y de la semana para ver el efecto de diferentes condiciones de red sobre la cantidad medida.

La caché puede arruinar las medicionesAl repetir una medición varias veces se obtendrá una respuesta inesperadamente rápida si los protocolos usan mecanismos de caché.

Asegúrese de que no ocurra nada inesperado durante sus pruebasEs probable que si realiza mediciones al mismo tiempo en que algún usuario ha decidido llevar a cabo una conferencia de video a través de su red obtenga distintos resultados a los que obtendría si no hubiera una conferencia de video. Es mejor ejecutar las pruebas en una red inactiva y crear la carga completa usted mismo. Aunque esta metodología también presenta algunos obstáculos.

Tenga cuidado al usar un reloj de grandes intervalosLa función de los relojes de computadora es sumar uno a un contador, a intervalos regulares.

Tenga cuidado con la extrapolación de los resultadosHay que cuidarse de los efectos de contención que se vuelven mucho más pronunciados cuando hay mucha carga.

6.6.3 Diseño de hosts para redes rápidas

Las mediciones y los ajustes pueden mejorar con frecuencia el desempeño de una manera considerable, pero no pueden sustituir un buen diseño en primer lugar. Una red mal diseñada se puede mejorar sólo hasta cierto punto. Más allá de eso, hay que rediseñarla desde cero.

La velocidad del host es más importante que la velocidad de la redLa amplia experiencia ha demostrado que en casi todas las redes rápidas, la sobrecarga de los sistemas operativos y protocolos domina el tiempo real en el alambre

Reducir el conteo de paquetes para disminuir la sobrecargaCada segmento tiene cierta cantidad de sobrecarga (por ejemplo, el encabezado) al igual que datos (la carga útil). Se requiere ancho de banda para ambos componentes. También se requiere el procesamiento para ambos componentes (por ejemplo, procesar el encabezado y realizar la suma de verificación).

Minimizar las copias de datosLa forma más simple y directa de implementar una pila de protocolos en capas es usar un módulo para cada capa. Por desgracia, esto conduce a la copia de datos (o por lo menos, acceder a los datos en varias pasadas) mientras cada capa realiza su propio trabajo. Un sistema operativo ingenioso minimizará el copiado mediante la combinación del procesamiento de varias capas. Por ejemplo, es común que TCP e IP se implementen juntos (como “TCP/IP”), de modo que no es necesario copiar la carga útil del paquete a medida que el procesamiento cambia de la capa de red a la de transporte. Otro truco común es realizar varias operaciones dentro de una capa en una sola pasada sobre los datos.

Minimizar las conmutaciones de contextoUna regla relacionada es que las conmutaciones de contexto (por ejemplo, del modo de kernel al modo de usuario) son mortales. Tienen los mismos inconvenientes que las interrupciones y las copias combinadas.Este costo es la razón por la que los protocolos de transporte se implementan casi siempre en el kernel. Así como se reduce el conteo de paquetes, también se pueden reducir las conmutaciones de contexto al hacer que el procedimiento de biblioteca que envía datos use un búfer interno hasta que tenga una cantidad considerable de éstos. Asimismo, en el lado receptor los pequeños segmentos

entrantes se deben agrupar y pasar al usuario de un solo golpe, en vez de pasarlos por separado para minimizar las conmutaciones de contexto.

Evitar la congestión es mejor que recuperarse de ellaLa vieja máxima de que más vale prevenir que lamentar sí aplica a la congestión en las redes. Al congestionarse una red se pierden paquetes, se desperdicia ancho de banda, se introducen retardos inútiles y otras cosas. Todos estos costos son innecesarios; la recuperación requiere tiempo y paciencia. Es mejor que no ocurra en primer lugar.

Evitar expiraciones del temporizadorLos temporizadores son necesarios en las redes, pero hay que usarlos con cuidado y se deben reducir al mínimo los tiempos de expiración. Al expirar un temporizador, lo común es que se repita una acción. Si en realidad es necesario repetir la acción, que así sea, pero su repetición innecesaria es un desperdicio.La manera de evitar el trabajo extra es tener cuidado de que los intervalos del temporizador sean más bien conservadores. Un temporizador que tarda demasiado en expirar agrega una pequeña cantidad de retardo extra a una conexión en el caso (improbable) de que se pierda un segmento. Un temporizador que expira cuando no debería consume recursos del host, desperdicia ancho de banda e impone una carga adicional tal vez a docenas de enrutadores sin una buena razón.

6.6.4 Procesamiento rápido de segmentos

La sobrecarga de procesamiento de los segmentos tiene dos componentes: la sobrecarga por segmento y la sobrecarga por byte. Ambas deben combatirse. La clave para el procesamiento rápido de los segmentos es separar el caso normal de éxito (transferencia de datos en un solo sentido) y manejarlo como caso especial. Muchos protocolos tienden a enfatizar lo que deben hacer cuando algo sale mal (por ejemplo, cuando se pierde un paquete), pero para que los protocolos operen con rapidez, el diseñador debería concentrarse en minimizar el tiempo de procesamiento cuando todo sale bien. Minimizar el tiempo de procesamiento cuando ocurre un error es algo secundario.

6.6.5 Compresión de encabezado

Para usar bien el ancho de banda, hay que transportar los encabezados de protocolo y las cargas útiles con el mínimo de bits. Para las cargas útiles esto significa usar codificaciones compactas de información, como las imágenes en formato JPEG en vez de mapas de bits, o los formatos de documentos tales comoPDF, que incluyen compresión. También significa el uso de mecanismos de caché a nivel de aplicación, como las cachés web que reducen las transferencias en primer lugar

La compresión de encabezados se utiliza para reducir el ancho de banda que ocupan los encabezados de los protocolos de capas superiores en los enlaces. Se utilizan esquemas diseñados de manera especial, en vez de métodos de propósito general. Esto se debe a que los encabezados son cortos, por lo que no se comprimen bien por separado; además, para descomprimirlos es necesario recibir todos los datos anteriores. Si se pierde un paquete, esto no será posible.La compresión de encabezados obtiene ventajas considerables gracias a que se conoce el formato del protocolo.Con la compresión de encabezados, es posible tener encabezados simples en protocolos de capas superiores y codificaciones compactas a través de enlaces con poco ancho de banda. ROHC (CompresiónRobusta de Encabezados, del inglés RObust Header Compression) es una versión moderna de compresión de encabezados que se define como un marco de trabajo en el RFC 5795. Está diseñada para tolerar la pérdida que puede ocurrir en los enlaces inalámbricos. Hay un perfil para cada conjunto de protocolos que se van a comprimir, como IP/UDP/RTP. Los encabezados comprimidos se transportan mediante la referencia a un contexto, que en esencia es una conexión; los campos de los encabezados se pueden predecir con facilidad para los paquetes de la misma conexión, pero no para los paquetes de distintas conexiones. En una operación típica, ROHC reduce los encabezados IP/UDP/RTP de 40 bytes hasta un valor entre 1 y 3 bytes.La compresión de encabezados puede ayudar a reducir la cantidad de datos que se envían y, por ende, reduce el retardo de transmisión. Es posible obtener el mismo efecto al enviar paquetes más pequeños. En este caso se hace un canje entre un aumento en la sobrecarga del software para obtener un menor retardo de transmisión.

6.6.6 Protocolos para redes de alto desempeño

Desde la década de 1990 han existido las redes de gigabits que transmiten datos a través de largas distancias.Debido a la combinación de una red rápida, o “canal grueso”, y un retardo grande, a estas redes se les conoce como redes long fat. Cuando surgieron estas redes, la primera reacción de la gente fue usar en ellas los protocolos existentes, pero pronto surgieron varios problemas. En esta sección estudiaremos algunos problemas relacionados con el aumento en la velocidad y el retardo de los protocolos de red.

Una cantidad útil a tener en cuenta al momento de analizar el desempeño de una red es el producto ancho de banda-retardo, que se obtiene al multiplicar el ancho de banda (en bits/seg) por el tiempo de retardo de ida y vuelta (en segundos). El producto es la capacidad del canal, desde el emisor hasta el receptor y en sentido inverso (en bits)

6.7 Redes Tolerantes Al Retardo

En estas redes que se conectan en forma ocasional, para comunicar los datos se almacenan en nodos y se reenvían más tarde, cuando haya un enlace funcional. Esta técnica se denomina conmutación de mensajes. En un momento dado, los datos se transmitirán al destino. Una red cuya arquitectura se basa en esta metodología se llama DTN (Red Tolerante al Retardo o Red Tolerante a las Interrupciones, del inglés Delay-Tolerant Network, o Disruption-Tolerant Network).El trabajo en las DTN empezó en 2002, cuando la IETF estableció un grupo de investigación sobre el tema. La inspiración de las DTN provino de una fuente insólita: los esfuerzos por enviar paquetes al espacio. Las redes espaciales deben lidiar con una comunicación intermitente y retardos muy largos. Kevin Fall observó que las ideas para estas interredes interplanetarias se podían aplicar a las redes en la Tierra, en donde la conectividad intermitente era la norma (Fall, 2003). Este modelo proporciona una útil generalización de Internet, en donde el almacenamiento y los retardos pueden ocurrir durante la comunicación.La entrega de datos es semejante a la entrega en el sistema postal, o el correo electrónico, en vez de la conmutación de paquetes en los enrutadores.

6.7.1 Arquitectura DTN

El principal supuesto en Internet que las DTN buscan relajar es que una trayectoria punto a punto entre un origen y un destino existe durante toda la sesión de comunicación. Cuando no se da este caso, los protocolos normales de Internet fallan. Las DTN resuelven la falta de conectividad punto a punto con una arquitectura basada en la conmutación de mensajes, como se muestra en la figura 6-56. También está diseñada para tolerar los enlaces con poca confiabilidad y retardos extensos. Esta arquitectura se especifica en el RFC 4838.

En terminología de DTN, a un mensaje se le llama bundle. Los nodos DTN están equipados con almacenamiento, que por lo general es persistente como un disco o memoria tipo Flash. Almacenan los bundles hasta que haya enlaces disponibles y

después reenvían esos bundles. Los enlaces trabajan en forma intermitente. La figura 6-56 muestra cinco enlaces intermitentes que no están trabajando en ese momento, y dos enlaces que sí están trabajando. A un enlace funcional se le denomina contacto.El proceso de almacenar y reenviar los bundles en los nodos DTN es similar al proceso de encolar y reenviar los paquetes en los enrutadores, sólo que existen diferencias cualitativas. En los enrutadores deInternet, el encolamiento ocurre durante milisegundos, o cuando mucho, segundos. En los nodos DTN, los bundles pueden estar almacenados por horas hasta que llegue un autobús a la ciudad, mientras un avión completa su vuelo, hasta que un nodo sensor acumula suficiente energía solar como para funcionar, hasta que una computadora inactiva se despierta, etc.

La principal ventaja de la arquitectura DTN en este ejemplo es que se adapta en forma natural a la situación en la que el satélite necesita almacenar imágenes, debido a que no hay conectividad en el momento en que se toma la imagen. También hay dos ventajas adicionales. En primer lugar, tal vez no haya un solo contacto que dure lo suficiente como para enviar las imágenes. Sin embargo, éstas se pueden dispersar por los contactos con tres estaciones terrestres. En segundo lugar, el uso del enlace entre el satélite y la estación terrestre está separado del enlace a través de la red de soporte. Esto significa que la descarga del satélite no está limitada por un enlace terrestre lento. Puede proceder a toda velocidad y el bundle se almacenará en la estación terrestre hasta que se pueda transmitir al punto de recolección.Un aspecto importante que la arquitectura no especifica es cómo encontrar buenas rutas a través de nodos DTN. Una ruta a usar en esta trayectoria. Las buenas rutas dependen de la naturaleza de la arquitectura que describe cuándo enviar los datos, y también a qué contactos. Algunos de ellos se conocen de antemano.

6.7.2 El protocolo Bundle

Para ver con más detalle la operación de las redes DTN, vamos a analizar los protocolos de la IETF. Las redes DTN son un tipo de red emergente; las DTN experimentales han usado distintos protocolos, puesto que no hay un requerimiento para usar los protocolos de la IETF.

La pila de protocolos DTN se muestra en la figura 6-58. El protocolo clave es el protocolo Bundle, que se especifica en el RFC 5050. Este protocolo es responsable de aceptar los mensajes de la aplicación y enviarlos como uno o más bundles por medio de operaciones de almacenamiento-transporte- reenvío hacia el nodo DTN de destino. En la figura 6-58 también podemos ver que el protocolo Bundle opera encima del nivel de TCP/IP. En otras palabras, podemos usar TCP/IP sobre cada contacto para mover los bundles entre un nodo DTN y otro. Este posicionamiento trae a relucir la cuestión de si el protocolo Bundle es un protocolo de capa de transporte o de capa de aplicación.

El protocolo Bundle puede operar sobre otros tipos de protocolos, como UDP, o incluso sobre otros tipos de interredes. Como el protocolo Bundle es fijo, aunque está diseñado para operar sobre una variedad de transportes, debe haber un vacío en la funcionalidad entre los protocolos. Ese vacío es la razón por la que se incluye una capa de convergencia

Cada mensaje consiste en un bloque primario, que se puede considerar como un encabezado, un bloque de carga útil para los datos y otros bloques opcionales. El bloque primario empieza con un campo Versión (en la actualidad es la 6) seguido de un campo Banderas. Entre otras funciones, las banderas codifican una clase de servicio para permitir que un origen marque sus bundles como de alta o baja prioridad, además de otras solicitudes de manejo; porejemplo, si el destino debe confirmar la recepción del bundle.Después vienen las direcciones, que resaltan tres partes interesantes del diseño. Además de los campos identificadores Destino y Origen, hay un campo identificador Guardián. El guardián es la parte responsable de ver que se entregue el bundle. En Internet, por lo general el nodo de origen es el guardián, ya que es el nodo que retransmite los datos si no se entregan en última instancia al destino.No obstante, en una DTN el nodo de origen no siempre puede estar conectado, por lo que tal vez no tenga forma de saber si se entregaron o no los datos. Para lidiar con este problema, las redes DTN usan la noción de transferencia de guardián, en donde otro nodo cercano al destino puede asumir la responsabilidad de ver que se entreguen los datos en forma segura. Por ejemplo, si se almacena un bundle en un avión para reenviarlo más tarde y en otra ubicación, el avión se puede convertir en el guardián del bundle.El segundo aspecto interesante es que estos identificadores no son direcciones IP. Como el protocolo bundle está diseñado para funcionar a través de una variedad de transportes e interredes, define sus propios identificadores.El tercer aspecto interesante es la forma en que se codifican los identificadores. También existe un identificador Informe para los mensajes de diagnóstico. Todos los identificadores se codifican como referencias a un campo Diccionario de longitud variable. Este campo provee compresión cuando los nodos guardián o de informe son iguales que el origen o el destino. A continuación viene un campo Creación, el cual transporta la hora en que se creó el bundle, junto con un número de secuencia proveniente del origen para mantener el orden, además de un campo Tiempo de vida que indica el lapso después del cual los datos del bundle ya no serán de utilidad. Estos campos existen debido a que los datos se pueden almacenar durante un largo periodo en los nodos DTN, por lo que debe haber alguna forma de quitar los datos viejos de la red.

El bloque primario se completa con el campo Diccionario. Después viene el bloque de carga útil. Este bloque empieza con un campo Tipo corto que lo identifica como carga útil, seguido de un pequeño conjunto de Banderas que describen las opciones de procesamiento. Luego viene el campo Datos, precedido de un campo Longitud. Por último, puede haber otros bloques opcionales, como un bloque que transporta parámetros de seguridad.