6.7.2. Протокол Bundle

Чтобы лучше понять, как работает DTN, мы рассмотрим протоколы IETF. DTN — это развивающийся тип сетей. В экспериментальных реализациях DTN используются самые разные протоколы. Для этого не обязательно использовать именно протоколы IETF. Но на их примере нам будет удобнее рассмотреть наиболее важные вопросы.

Стек протокола DTN показан на рис. 6.52. Основной протокол — это протокол Bundle; он описан в RFC 5050. Он принимает сообщения от приложения и передает их в виде одной или нескольких посылок с помощью операций получения—переноса— отправки принимающему узлу DTN. Как видно из рис. 6.52, он работает над уровнем TCP/IP. Иными словами, TCP/IP может использоваться в каждом из контактов для передачи посылок между узлами. Следовательно, возникает вопрос, к какому уровню относится протокол Bundle — транспортному или прикладному. Как и в случае с RTP, мы придерживаемся мнения, что, несмотря на более высокую позицию в иерархии, протокол Bundle предоставляет многим приложениям транспортные услуги, поэтому мы рассматриваем DTN в этой главе.

Рис. 6.52. Стек протоколов DTN

На рис. 6.52 также показано, что протокол Bundle может работать поверх других протоколов — например, UDP — или даже других интерсетей. К примеру, в космической сети каналы могут обладать большой задержкой. Круговая задержка между Землей и Марсом может составлять 20 минут (в зависимости от их взаимного расположения). Представьте себе, как здорово в таком канале будут работать подтверждения и повторные передачи, особенно для коротких сообщений! Вовсе не здорово. В такой ситуации необходим другой протокол, использующий коды с коррекцией ошибок. В сенсорных сетях, где ресурсы сильно ограничены, вместо TCP может использоваться более легковесный протокол.

Так как протокол Bundle является фиксированным, но в его задачи входит совместимость с различными транспортами, между сферами действия протоколов должен быть небольшой зазор. Эта идея привела к добавлению дополнительного уровня взаимодействия (convergence layer), как показано на рис. 6.52. На самом деле это просто связующий уровень, обеспечивающий совместную работу протоколов. По определению для каждого транспорта более низкого уровня должен существовать отдельный уровень взаимодействия. Уровни взаимодействия, позволяющие подключать новые и существующие протоколы, обычно можно найти в стандартах.

Формат сообщений протокола Bundle приведен на рис. 6.53. По названиям полей можно догадаться, чем занимается этот протокол.

Рис. 6.53. Формат сообщений протокола Bundle

Каждое сообщение состоит из первичного блока, который можно считать заголовком, блока полезной нагрузки (для данных) и факультативных блоков (например, для параметров безопасности). Первичный блок начинается с поля Версия (на данный момент — 6), за которым следует поле Флаги. Помимо всего прочего, с помощью флагов указывается класс обслуживания (чтобы источник мог отметить посылку как высокоприоритетную или низкоприоритетную) и другие обрабатывающие запросы (например, должен ли получатель подтвердить доставку).

Далее следуют адреса. И здесь уже есть кое-что интересное. Помимо полей идентификаторов Адрес назначения и Источник, мы видим идентификатор Ответственный хранитель. Ответственный хранитель — это сторона, обязанная следить за тем, чтобы пакет был доставлен. В Интернете эта роль обычно возложена на источник, так как именно он выполняет повторную передачу, если данные не доходят до пункта назначения. Но в DTN узел-источник не всегда находится на связи и, следовательно, не всегда может узнать, доставлены ли данные. Для решения этой проблемы в DTN используется процедура сдачи-приемки (custody transfer), при которой другой узел, расположенный ближе к получателю, принимает на себя ответственность за доставку данных. Например, если посылка временно хранится на самолете и будет передана позднее и в другом месте, самолет может стать ответственным хранителем этой посылки.

Второй интересный момент заключается в том, что эти идентификаторы не являются IP-адресами. Поскольку протокол Bundle работает с самыми разными транспортами и интерсетями, он использует свои собственные идентификаторы. Они больше похожи на имена высоких уровней, такие как URL веб-страниц, чем на адреса нижних уровней (IP). Такие идентификаторы дают сетям DTN возможности маршрутизации прикладного уровня, например доставки электронной почты или рассылки обновлений программного обеспечения.

Третий любопытный аспект — это то, как кодируются идентификаторы, так же как и идентификаторы в поле Уведомление, для диагностических сообщений. Все эти идентификаторы кодируются с помощью ссылок на поле Словарь переменной длины. Это позволяет использовать сжатие, когда узел ответственного хранителя или узел для диагностических сообщений совпадают с источником или адресом назначения. На самом деле разработчики формата сообщений стремились добиться как эффективности, так и возможности изменения длины поля, используя компактное представление для полей переменной длины. Последнее играет важную роль в беспроводных сетях, а также в сетях с ограниченными ресурсами, таких как сенсорные сети.

Далее следует поле Создание, в котором хранится время создания посылки, а также порядковый номер отправителя; за ним располагается поле Время жизни, в котором указано время, когда посылка будет уже не нужна. Эти поля нужны, так как посылки могут храниться в узлах DTN очень долго, и поэтому в сети должен существовать механизм, позволяющий удалять устаревшие данные. В отличие от Интернета в данном случае часы на узлах должны быть слабо синхронизированы.

Первичный блок завершается полем Словарь. Далее идет блок полезной нагрузки. Он начинается с короткого поля Тип, в котором указано, что это полезная нагрузка, а за ним располагаются Флаги, в которых задаются параметры обработки. Далее следует поле Данные, перед которым располагается поле Длина. Наконец, за ними могут быть факультативные блоки — в частности, блок с параметрами безопасности.

Многие аспекты сетей, устойчивых к задержкам, продолжают обсуждаться в научных сообществах. Как мы уже говорили, хорошие стратегии маршрутизации зависят от природы контактов. Идея хранения данных внутри сети приводит к возникновению новых проблем. Теперь контроль перегрузки должен относить память в узлах DTN к другому типу ресурсов, и такие ресурсы тоже могут заканчиваться. Отсутствие сквозного соединения усугубляет проблему безопасности. Перед тем как принять на себя ответственность за доставку посылки, узел захочет проверить, что отправитель официально зарегистрирован в сети и что получателю нужна эта посылка. Решения этих проблем будут зависеть от типа DTN, ведь космические сети так сильно отличаются от сенсорных!

6.8. Резюме

Транспортный уровень — это ключ к пониманию многоуровневых протоколов. Он предоставляет различные сервисы, наиболее важным из которых является сквозной, надежный, ориентированный на соединение поток байтов от отправителя к получателю. Доступ к нему предоставляется при помощи сервисных примитивов, позволяющих устанавливать, использовать и разрывать соединения. Общепринятый интерфейс транспортного уровня обеспечивается сокетами Беркли.

Транспортные протоколы должны обладать способностью управлять соединением в ненадежных сетях. Установка соединения осложняется возможностью существования дубликатов пакетов, которые могут появляться в самый неподходящий момент. Для борьбы с этими дубликатами при установке соединения применяется алгоритм «тройного рукопожатия». Разрыв соединения проще установки и тем не менее далеко не тривиален из-за наличия проблемы двух армий.

Даже если сетевой уровень абсолютно надежен, у транспортного уровня полно работы. Он должен обрабатывать все служебные примитивы, управлять соединениями и таймерами, распределять пропускную способность и осуществлять контроль перегрузки, а также использовать скользящее окно переменного размера для управления потоком данных.