Resumen
- BTPU admite copias exactas de mensajes para operar sobre un enlace unidireccional que no puede pedir retransmisiones.
- Transfer End revela el último índice esperado; la terminación solo existe localmente cuando el receptor reúne todos los segmentos de
0aN.
La escena parece tranquilizadora: el transmisor envía el mismo fragmento una y otra vez. Sin embargo, ninguna copia regresa con noticias. draft-ietf-dtn-btpu-04, publicado el 7 de septiembre, define un mecanismo para transportar grandes objetos binarios—habitualmente bundles BPv7—sobre una capa de enlace en tramas, no fiable y de una sola dirección.
Los segmentos de un objeto comparten un Transfer number de 32 bits y usan índices crecientes. Transfer End transporta el segmento final y el índice N. El receptor considera completo el traslado cuando posee 0..N, concatena los datos y entrega el bundle reconstruido a una capa superior.
Ese criterio no es un acuse enviado al origen. Que el emisor haya transmitido Transfer End no demuestra que el mensaje cruzó el enlace. Que el receptor lo vea no recupera segmentos anteriores. La reconstrucción completa tampoco demuestra que BPv7 aceptó el objeto, que CRC o BPSec fueron válidos, que otro nodo lo custodió o reenvió, ni que una aplicación lo procesó.
BTPU responde a la pérdida con redundancia abierta. Cualquier mensaje puede repetirse en otra PDU, siempre como copia exacta. La cantidad puede depender de un análisis del entorno, una prioridad local o señales fuera de banda. El borrador no convierte un número de repeticiones en una garantía universal.
La Transfer Window limita el conjunto de traslados simultáneos y ayuda a tratar números antiguos tras la vuelta del contador. El tamaño se acuerda fuera de banda. La cifra 16 aparece como recomendación provisional y todavía está marcada para discusión. Una ventana coherente protege estado y memoria; no certifica una entrega.
Tampoco deben sumarse sin contexto la repetición BTPU, la redundancia de la capa inferior y la codificación de borrado. Son mecanismos diferentes. El Bundle Length Hint solo anuncia memoria necesaria. La protección criptográfica pertenece a otras capas: integridad no equivale a llegada y confidencialidad no equivale a aceptación.
La sección de despliegue fija el límite: BTPU es no fiable y carece de retorno integrado para confirmar éxito. Todo acuse exige un camino lógicamente separado. Además, sin control de congestión propio, no debe usarse en una ruta disputada como Internet público salvo que la capa inferior aporte ese control.
Fuentes
- Registro Datatracker de BTPU
- Texto de BTPU revisión 04
- Historial de BTPU
- Repositorio del autor
- RFC 9171: Bundle Protocol Version 7
- RFC 9172: Bundle Protocol Security
- RFC 9174: TCP Convergence-Layer Protocol v4
- RFC 4838: arquitectura DTN
- RFC 5050: Bundle Protocol
- Registros IANA de Bundle Protocol
- Heng Lu: realidad, no promoción
- Heng Lu: especificación inicial mínima
- Heng Lu: primacía del código en funcionamiento
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

