Эндрю Уэзеролл - Компьютерные сети. 5-е издание

В терминологии DTN сообщение называется посылкой. Узлы DTN оснащены запоминающими устройствами — как правило, с постоянной памятью (диски, флэш-память и т. д.). В них посылки хранятся до тех пор, пока нужный канал не активизируется; затем происходит отправка посылок. Каналы работают с перерывами. На рис. 6.50 изображено пять непостоянных каналов, которые в данный момент не работают, и два активных канала. Активный канал называется контактом. На рис. 6.50 также изображены две посылки, которые хранятся в узлах DTN, ожидая нужного контакта. По такой схеме пакеты передаются от источника в пункт назначения.

Рис. 6.50. Архитектура DTN

Такая схема очень похожа на то, что происходит с пакетами на маршрутизаторах. Однако здесь есть качественные отличия. На маршрутизаторах в Интернете ожидание в очереди длится несколько миллисекунд, в худшем случае — секунд. В узлах DTN посылки могут храниться часами — до тех пор, пока автобус не прибудет в город, самолет не приземлится, узел сенсорной сети не накопит солнечную энергию, необходимую для его работы, спящий компьютер не проснется и т. д. Эти примеры иллюстрируют и второе отличие: узлы могут перемещаться (вместе с автобусом или самолетом) вместе с хранящимися в них посылками, и это может играть ключевую роль в доставке данных; маршрутизаторы Интернета двигаться не могут. Чтобы описать весь процесс перемещения посылок, иногда используют термин «получение—перенос—отправка» («store—carry—forward»).

Для примера рассмотрим ситуацию, изображенную на рис. 6.51. Так протоколы DTN впервые использовались в космосе (Wood и др., 2008). Источник посылок — один из спутников LEO Международной системы мониторинга стихийных бедствий, который делает снимки Земли. Изображения должны приходить на пункт сбора данных. Но спутник имеет непостоянную связь с тремя наземными станциями. Двигаясь по орбите, он связывается ними по очереди. Таким образом, спутник, наземные станции и пункт сбора данных являются узлами DTN. По каждому контакту посылка (или часть посылки) передается наземной станции. Затем посылки доставляются на пункт сбора данных по транзитной наземной сети. На этом передача завершается.

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

Рис. 6.51. Использование DTN в космосе

В описании архитектуры DTN не рассматривается важный вопрос: как находить хорошие маршруты через узлы DTN. Хорошие маршруты зависят от архитектуры, которая описывает, когда следует отправлять данные и по каким направлениям (контактам). О некоторых контактах можно узнать заранее. Так, в нашем космическом примере заранее известно движение небесных тел. В эксперименте по использованию DTN в космосе заранее было известно время связи, а также то, что контакт с каждой наземной станцией длится от 5 до 14 минут и что пропускная способность нисходящей линии составляет 8,134 Мбит/с. С помощью этих сведений можно планировать передачу посылок с изображениями.

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

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 может использоваться более легковесный протокол.