Administracion de redes

resumen

instituto tecnologico de veracruz10:00 11:00 hrs

Si las entidades de transporte en muchas mquinas envan demasiados paquetes

a la red con exagerada rapidez, sta se congestionar y se degradar el
desempeo a medida que se retrasen y pierdan paquetes.
El proceso de controlar la congestin para evitar este problema es la
responsabilidad combinada de las capas de red y de transporte. La congestin
ocurre en los enrutadores, por lo que se detecta en la capa de red. Sin embargo,
se produce en ltima instancia debido al trfico que la capa de transporte enva a
la red.
La nica manera efectiva de controlar la congestin es que los protocolos de
transporte enven paquetes a la red con ms lentitud.

6.3.1 Asignacin de ancho de banda deseable

Se trata de encontrar una buena asignacin de ancho de banda a las entidades de
transporte que utilizan la red. Una buena asignacin producir un buen
desempeo, ya que utiliza todo el ancho de banda disponible pero evita la
congestin, tratar con igualdad a las entidades de transporte que compitan entre
s, y rastrear con rapidez los cambios en las demandas de trfico.

Eficiencia y potencia
Una asignacin 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 desempeo se empieza a
degradar cuando comienza la congestin. Por instinto, obtendremos el mejor
desempeo 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 mtrica de potencia, en donde
Potencia = Carga/Retardo
En un principio la potencia aumentar con la carga ofrecida, mientras el retardo
permanezca en un valor pequeo y aproximadamente constante, pero llegar a un
mximo y caer a medida que el retardo aumente con rapidez. La carga con la
potencia ms alta representa una carga eficiente para que la entidad de transporte
la coloque en la red.

Equidad mxima-mnima
Si la red proporciona a un emisor cierta cantidad de ancho de banda para que la
utilice, el emisor debe usar slo esa cantidad de ancho de banda. Sin embargo, es
comn el caso en que las redes no tienen una reservacin estricta de ancho de
banda para cada flujo o conexin. Tal vez s la tengan para algunos flujos en los
que se soporta la calidad del servicio, pero muchas conexiones buscarn usar el

ancho de banda que est disponible o la red las agrupar bajo una asignacin
comn
Una segunda consideracin es lo que significa una porcin 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 trfico es en rfagas).
La forma de equidad que se desea con frecuencia para el uso de red es la
equidad mxima-mnima. Una asignacin tiene equidad mxima-mnima 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 asignacin que no sea
mayor. Esto es, si se incrementa el ancho de banda de un flujo, la situacin slo
empeorar para los flujos con menos recursos.
Las asignaciones mxima-mnima 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 dems flujos seguirn incrementndose y compartirn la capacidad disponible
por igual, hasta que tambin lleguen a sus respectivos cuellos de botella.
Una tercera consideracin es el nivel sobre el cul 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 ms comn es considerar la equidad por conexin, pero por lo general no es
imprescindible una equidad precisa. Es ms importante en la prctica que ninguna
conexin 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 ms agresiva. Esta
tctica 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 congestin debe converger
rpidamente hacia una asignacin equitativa y eficiente del ancho de banda.
Debido a la variacin en la demanda, el punto de operacin ideal para la red vara
con el tiempo. Un buen algoritmo de control de congestin debe converger con
rapidez hacia el punto de operacin 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 operacin 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 Regulacin de la tasa de envo

Podemos limitar la tasa de envo mediante dos factores. El primero es el control de
flujo, en el caso en que haya un uso insuficiente de bfer en el receptor. El

segundo es la congestin, 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 envo depende
de la forma de retroalimentacin que devuelva la red. Las distintas capas de la red
pueden devolver distintos tipos de retroalimentacin, la cual puede ser explcita o
implcita, y tambin precisa o imprecisa.
Un ejemplo de un diseo explcito y preciso es cuando los enrutadores indican a
las fuentes la velocidad a la que pueden enviar. Los diseos en la literatura, como
XCP (Protocolo Explcito de Congestin, del ingls eXplicit Congestion Protocol ),
operan de esta forma (Katabi y colaboradores, 2002).
Un diseo explcito e impreciso es el uso de ECN (Notificacin Explcita de
Congestin, del ingls Explicit Congestion Notification) con TCP. En este diseo,
los enrutadores establecen bits en paquetes que experimentan congestin para
advertir a los emisores que reduzcan la velocidad, pero no les dicen cunto deben
reducirla.

Si se proporciona una seal explcita y precisa, la entidad de transporte puede

usarla para ajustar su tasa con el nuevo punto de operacin. Por ejemplo, si XCP
indica a los emisores la tasa que deben usar, stos simplemente usarn esa tasa.
Sin embargo, en los otros casos se requieren algunas conjeturas.
A falta de una seal de congestin, los emisores deben reducir sus tasas. Cuando
se proporcione una seal de congestin, 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 desempeo.

6.3.3 Cuestiones inalmbricas

Los protocolos de transporte como TCP que implementan control de congestin
deben ser independientes de la red subyacente y de las tecnologas de capa de
enlace. Es una buena teora, pero en la prctica hay problemas con las redes
inalmbricas. La cuestin principal es que la prdida de paquetes se usa con
frecuencia como seal de congestin, incluyendo a TCP como vimos antes. Las

redes inalmbricas pierden paquetes todo el tiempo debido a errores de

transmisin.
Para funcionar bien, las nicas prdidas de paquetes que debe observar el
algoritmo de control de congestin son las prdidas debido a un ancho de banda
insuficiente, no las prdidas debido a errores de transmisin. Una solucin a este
problema es enmascarar las prdidas inalmbricas mediante el uso de
retransmisiones a travs del enlace inalmbrico. 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 prdida de un
paquete a la capa superior. En el caso normal, cada paquete se entrega a pesar
de los errores de transmisin transitorios que no son visibles para las capas
superiores.
La estrategia de enmascaramiento es suficiente para permitir que la mayora de
los protocolos de transporte operen bien a travs de la mayora de los enlaces
inalmbricos. Sin embargo, no siempre es una solucin adecuada. Algunos
enlaces inalmbricos tienen tiempos de ida y vuelta largos, como los satlites.
Para estos enlaces se deben usar otras tcnicas para enmascarar la prdida,
como FEC (Correccin de Errores hacia Adelante), o el protocolo de transporte
debe usar una seal que no sea de prdida para el control de congestin.
Un segundo aspecto relacionado con el control de congestin a travs de enlaces
inalmbricos es la capacidad variable. Esto es, la capacidad de un enlace
inalmbrico cambia con el tiempo, algunas veces en forma brusca, a medida que
los nodos se desplazan y la relacin seal ruido vara 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 inalmbricos; de lo contrario se congestionar la red o no se podr usar la
capacidad disponible.
Una posible solucin a este problema es simplemente no preocuparse por ello.
Esta estrategia es viable, puesto que los algoritmos de control de congestin ya
deben manejar el caso en que nuevos usuarios entren a la red, o que los usuarios
existentes cambien sus tasas de envo. 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 travs de una ruta con un enlace
inalmbrico 802.11 y obtener un desempeo razonable.

6.6 Aspectos Del Desempeo

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 desempeo pobre, sin que nadie sepa por qu.

6.6.1 Problemas de desempeo en las redes de computadoras

Las sobrecargas tambin se pueden desencadenar en forma sincrnica. Por

ejemplo, si un segmento contiene un parmetro errneo (por ejemplo, el puerto al
que est destinado), en muchos casos el receptor devolver con amabilidad una
notificacin de error.
La tormenta de difusin resultante podra paralizar la red. UDP sufri de este
problema hasta que se cambi el protocolo
ICMP para hacer que los hosts evitaran responder a errores en los segmentos
UDP enviados a direcciones de difusin. Las redes inalmbricas deben tener
especial cuidado en evitar las respuestas de difusin no verificadas, debido a que
la difusin ocurre en forma natural y el ancho de banda inalmbrico es limitado.

6.6.2 Medicin del desempeo de las redes

Cuando una red tiene un desempeo pobre, con frecuencia sus usuarios se
quejan con los operadores y les exigen mejoras. Para mejorar el desempeo, 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
fsicos como en la pila de protocolos). El tipo de medicin ms bsico es iniciar un
temporizador al empezar alguna actividad y medir el tiempo que tarda esa
actividad.
Asegrese que el tamao de la muestra sea lo bastante grande
No mida el tiempo para enviar un segmento; mejor repita la medicin (por ejemplo,
un milln de veces) y obtenga el promedio. Los efectos iniciales, como cuando la
NIC 802.16 o el mdem de cable obtienen una reservacin de ancho de banda
despus de un periodo de inactividad, pueden reducir la velocidad del primer
segmento, adems de que el encolamiento introduce la variabilidad.
Asegrese de que las muestras sean representativas
Lo ideal sera que la secuencia total de un milln de mediciones se repitiera a
distintas horas del da y de la semana para ver el efecto de diferentes condiciones
de red sobre la cantidad medida.
La cach puede arruinar las mediciones
Al repetir una medicin varias veces se obtendr una respuesta inesperadamente
rpida si los protocolos usan mecanismos de cach.
Asegrese de que no ocurra nada inesperado durante sus pruebas
Es probable que si realiza mediciones al mismo tiempo en que algn usuario ha
decidido llevar a cabo una conferencia de video a travs de su red obtenga
distintos resultados a los que obtendra 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 metodologa tambin presenta algunos obstculos.

 Tenga cuidado al usar un reloj de grandes intervalos

La funcin de los relojes de computadora es sumar uno a un contador, a intervalos
regulares.
Tenga cuidado con la extrapolacin de los resultados
Hay que cuidarse de los efectos de contencin que se vuelven mucho ms
pronunciados cuando hay mucha carga.

6.6.3 Diseo de hosts para redes rpidas

Las mediciones y los ajustes pueden mejorar con frecuencia el desempeo de una
manera considerable, pero no pueden sustituir un buen diseo en primer lugar.
Una red mal diseada se puede mejorar slo hasta cierto punto. Ms all de eso,
hay que redisearla desde cero.
La velocidad del host es ms importante que la velocidad de la red
La amplia experiencia ha demostrado que en casi todas las redes rpidas, la
sobrecarga de los sistemas operativos y protocolos domina el tiempo real en el
alambre
Reducir el conteo de paquetes para disminuir la sobrecarga
Cada 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. Tambin se requiere el procesamiento para ambos componentes
(por ejemplo, procesar el encabezado y realizar la suma de verificacin).
Minimizar las copias de datos
La forma ms simple y directa de implementar una pila de protocolos en capas es
usar un mdulo 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 combinacin del procesamiento de varias capas. Por ejemplo, es
comn 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 comn es realizar varias
operaciones dentro de una capa en una sola pasada sobre los datos.
Minimizar las conmutaciones de contexto
Una 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 razn por la que los protocolos de transporte se implementan casi
siempre en el kernel. As como se reduce el conteo de paquetes, tambin se
pueden reducir las conmutaciones de contexto al hacer que el procedimiento de
biblioteca que enva datos use un bfer interno hasta que tenga una cantidad

considerable de stos. Asimismo, en el lado receptor los pequeos 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 congestin es mejor que recuperarse de ella
La vieja mxima de que ms vale prevenir que lamentar s aplica a la congestin
en las redes. Al congestionarse una red se pierden paquetes, se desperdicia
ancho de banda, se introducen retardos intiles y otras cosas. Todos estos costos
son innecesarios; la recuperacin requiere tiempo y paciencia. Es mejor que no
ocurra en primer lugar.
Evitar expiraciones del temporizador
Los temporizadores son necesarios en las redes, pero hay que usarlos con
cuidado y se deben reducir al mnimo los tiempos de expiracin. Al expirar un
temporizador, lo comn es que se repita una accin. Si en realidad es necesario
repetir la accin, que as sea, pero su repeticin innecesaria es un desperdicio.
La manera de evitar el trabajo extra es tener cuidado de que los intervalos del
temporizador sean ms bien conservadores. Un temporizador que tarda
demasiado en expirar agrega una pequea cantidad de retardo extra a una
conexin en el caso (improbable) de que se pierda un segmento. Un temporizador
que expira cuando no debera consume recursos del host, desperdicia ancho de
banda e impone una carga adicional tal vez a docenas de enrutadores sin una
buena razn.

6.6.4 Procesamiento rpido 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 rpido 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 diseador debera 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 Compresin de encabezado

Para usar bien el ancho de banda, hay que transportar los encabezados de
protocolo y las cargas tiles con el mnimo de bits. Para las cargas tiles esto
significa usar codificaciones compactas de informacin, como las imgenes en
formato JPEG en vez de mapas de bits, o los formatos de documentos tales como
PDF, que incluyen compresin. Tambin significa el uso de mecanismos de cach
a nivel de aplicacin, como las cachs web que reducen las transferencias en
primer lugar

La compresin 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 diseados de manera especial, en vez de mtodos de propsito
general. Esto se debe a que los encabezados son cortos, por lo que no se
comprimen bien por separado; adems, para descomprimirlos es necesario recibir
todos los datos anteriores. Si se pierde un paquete, esto no ser posible.
La compresin de encabezados obtiene ventajas considerables gracias a que se
conoce el formato del protocolo.
Con la compresin de encabezados, es posible tener encabezados simples en
protocolos de capas superiores y codificaciones compactas a travs de enlaces
con poco ancho de banda. ROHC (Compresin
Robusta de Encabezados, del ingls RObust Header Compression) es una
versin moderna de compresin de encabezados que se define como un marco de
trabajo en el RFC 5795. Est diseada para tolerar la prdida que puede ocurrir en
los enlaces inalmbricos. 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 conexin; los campos
de los encabezados se pueden predecir con facilidad para los paquetes de la
misma conexin, pero no para los paquetes de distintas conexiones. En una
operacin tpica, ROHC reduce los encabezados IP/UDP/RTP de 40 bytes hasta
un valor entre 1 y 3 bytes.
La compresin de encabezados puede ayudar a reducir la cantidad de datos que
se envan y, por ende, reduce el retardo de transmisin. Es posible obtener el
mismo efecto al enviar paquetes ms pequeos. En este caso se hace un canje
entre un aumento en la sobrecarga del software para obtener un menor retardo de
transmisin.

6.6.6 Protocolos para redes de alto desempeo

Desde la dcada de 1990 han existido las redes de gigabits que transmiten datos
a travs de largas distancias.
Debido a la combinacin de una red rpida, o canal grueso, y un retardo grande,
a estas redes se les conoce como redes long fat. Cuando surgieron estas redes,
la primera reaccin de la gente fue usar en ellas los protocolos existentes, pero
pronto surgieron varios problemas. En esta seccin 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 desempeo 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 reenvan ms tarde, cuando haya un enlace funcional.
Esta tcnica se denomina conmutacin de mensajes. En un momento dado, los
datos se transmitirn al destino. Una red cuya arquitectura se basa en esta
metodologa se llama DTN (Red Tolerante al Retardo o Red Tolerante a las
Interrupciones, del ingls Delay-Tolerant Network, o Disruption-Tolerant Network).
El trabajo en las DTN empez en 2002, cuando la IETF estableci un grupo de
investigacin sobre el tema. La inspiracin de las DTN provino de una fuente
inslita: los esfuerzos por enviar paquetes al espacio. Las redes espaciales deben
lidiar con una comunicacin intermitente y retardos muy largos. Kevin Fall observ
que las ideas para estas interredes interplanetarias se podan aplicar a las redes
en la Tierra, en donde la conectividad intermitente era la norma (Fall, 2003). Este
modelo proporciona una til generalizacin de Internet, en donde el
almacenamiento y los retardos pueden ocurrir durante la comunicacin.
La entrega de datos es semejante a la entrega en el sistema postal, o el correo
electrnico, en vez de la conmutacin 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 sesin
de comunicacin. 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 conmutacin de mensajes, como se muestra en la figura
6-56. Tambin est diseada para tolerar los enlaces con poca confiabilidad y
retardos extensos. Esta arquitectura se especifica en el RFC 4838.

En terminologa de DTN, a un mensaje se le llama bundle. Los nodos DTN estn

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

despus reenvan esos bundles. Los enlaces trabajan en forma intermitente. La

figura 6-56 muestra cinco enlaces intermitentes que no estn trabajando en ese
momento, y dos enlaces que s estn 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, slo que existen
diferencias cualitativas. En los enrutadores de
Internet, el encolamiento ocurre durante milisegundos, o cuando mucho,
segundos. En los nodos DTN, los bundles pueden estar almacenados por horas
hasta que llegue un autobs a la ciudad, mientras un avin completa su vuelo,
hasta que un nodo sensor acumula suficiente energa 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 situacin en la que el satlite necesita almacenar imgenes,
debido a que no hay conectividad en el momento en que se toma la imagen.
Tambin hay dos ventajas adicionales. En primer lugar, tal vez no haya un solo
contacto que dure lo suficiente como para enviar las imgenes. Sin embargo,
stas se pueden dispersar por los contactos con tres estaciones terrestres. En
segundo lugar, el uso del enlace entre el satlite y la estacin terrestre est
separado del enlace a travs de la red de soporte. Esto significa que la descarga
del satlite no est limitada por un enlace terrestre lento. Puede proceder a toda
velocidad y el bundle se almacenar en la estacin terrestre hasta que se pueda
transmitir al punto de recoleccin.
Un aspecto importante que la arquitectura no especifica es cmo encontrar
buenas rutas a travs de nodos DTN. Una ruta a usar en esta trayectoria. Las
buenas rutas dependen de la naturaleza de la arquitectura que describe cundo
enviar los datos, y tambin a qu contactos. Algunos de ellos se conocen de
antemano.

6.7.2 El protocolo Bundle

Para ver con ms detalle la operacin 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 aplicacin y enviarlos como uno o ms
bundles por medio de operaciones de almacenamiento-transporte- reenvo hacia
el nodo DTN de destino. En la figura 6-58 tambin 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 cuestin de si el protocolo Bundle es un
protocolo de capa de transporte o de capa de aplicacin.

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 diseado para operar sobre una variedad de transportes, debe haber un
vaco en la funcionalidad entre los protocolos. Ese vaco es la razn 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 Versin (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, adems de otras solicitudes de manejo; porejemplo, si el destino debe
confirmar la recepcin del bundle.
Despus vienen las direcciones, que resaltan tres partes interesantes del diseo.
Adems de los campos identificadores Destino y Origen, hay un campo
identificador Guardin. El guardin es la parte responsable de ver que se entregue
el bundle. En Internet, por lo general el nodo de origen es el guardin, 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 nocin de transferencia de
guardin, 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 avin para reenviarlo ms tarde y en otra ubicacin, el avin se
puede convertir en el guardin del bundle.
El segundo aspecto interesante es que estos identificadores no son direcciones IP.
Como el protocolo bundle est diseado para funcionar a travs de una variedad
de transportes e interredes, define sus propios identificadores.
El tercer aspecto interesante es la forma en que se codifican los identificadores.
Tambin existe un identificador Informe para los mensajes de diagnstico. Todos
los identificadores se codifican como referencias a un campo Diccionario de
longitud variable. Este campo provee compresin cuando los nodos guardin o de
informe son iguales que el origen o el destino. A continuacin viene un campo
Creacin, el cual transporta la hora en que se cre el bundle, junto con un nmero
de secuencia proveniente del origen para mantener el orden, adems de un
campo Tiempo de vida que indica el lapso despus del cual los datos del bundle
ya no sern 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. Despus viene el bloque

de carga til. Este bloque empieza con un campo Tipo corto que lo identifica como
carga til, seguido de un pequeo 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 parmetros de seguridad.