Кратко

  • RFC 3077 сохранила физически односторонний спутниковый канал, а недостающий обмен на уровне канала имитировала IP-туннелями между двусторонними интерфейсами узлов.
  • Односторонние объявления DTCP помогали обнаруживать фиды и удалять устаревшие конечные точки туннелей, но не аутентифицировали фид, не выбирали единственный лучший маршрут для всех и не доказывали доставку приложению.

Опубликованная в марте 2001 года RFC 3077 начинает с физического ограничения. Фид может передавать данные по однонаправленной линии, а приёмник — только слушать. Фид, способный лишь отправлять, сам ничего не принимает на этом интерфейсе. Между тем многие протоколы Интернета предполагают двустороннюю связь: маршрутизатор отправляет пакет следующему узлу и ожидает ответа или обновления маршрутов.

Решением не стало превращение спутникового приёмника в передатчик. И приёмнику, и фиду требовался обычный двунаправленный интерфейс с подключением к IP-инфраструктуре. Когда приёмнику нужно было отправить кадр канального уровня фиду, он инкапсулировал кадр и переносил его через туннель к интернет-адресу фида. Фид снимал инкапсуляцию и передавал кадр на сторону однонаправленного канала. Спутниковое вещание оставалось нисходящим путём; обратный путь между выбранными узлами обеспечивал туннель.

Зачем имитировать двусторонний канальный сегмент, а не создавать только новую IP-сеть? Такая модель позволяла существующим протоколам верхних уровней работать, не зная о физике спутникового канала. RFC перечисляет шесть видов обмена, возможных в двусторонней вещательной сети. Передача от фида к приёмнику, шестой сценарий, уже работала через физическую линию. Туннелям предстояло обеспечить остальные пять: от приёмника к фиду, между приёмниками, а также широковещательный и многоадресный трафик. Благодаря этому ARP и протоколы маршрутизации непосредственно подключённых соседей могли оставаться на привычном уровне.

Но физическая линия не получала передатчик обратного направления.

Для переноса разных внутренних пакетов по IP документ рекомендует Generic Routing Encapsulation (GRE). В описанном формате внешний IP-пакет приходит на двунаправленный адрес фида, заголовок GRE обозначает протокол канального уровня однонаправленной линии, а полезная нагрузка содержит исходный MAC-кадр. Возможен и другой тип туннеля, если обе стороны договорились о его значении. RFC 3077 адаптирует туннель к канальному уровню, но не превращает GRE в механизм авторизации или безопасности.

Менее очевиден способ обнаружения фидов, к которым нужно строить туннели. Dynamic Tunnel Configuration Protocol (DTCP) не использует для этого интернет-канал возврата: сообщения HELLO идут от фидов к приёмникам по той же однонаправленной линии. JOIN объявляет о работающем фиде; LEAVE может сообщить о его остановке. HELLO также содержит интервал, номер последовательности, тип туннеля и один или несколько двунаправленных IP-адресов фида (FBIP). Приёмники слушают многоадресные объявления DTCP и ведут список активных фидов, конечных точек и таймеров.

Сообщение LEAVE позволяет быстро удалить запись. Если HELLO больше не приходят, запись со временем истекает. У этого сигнала ограниченный смысл: мог отказать фид или сама однонаправленная линия. В обоих случаях двустороннюю связность через этот фид больше нельзя считать надёжной. Таймер показывает, какие попытки следует прекратить, но не определяет неисправный компонент и не доказывает доставку пакета приложению.

Выбор фида остаётся локальным. Каждый приёмник самостоятельно назначает фид по умолчанию. Меньшая задержка туда-обратно приведена в RFC лишь как пример, а не как единое обязательное правило. Администратор может предпочесть другую объявленную конечную точку туннеля, если до неё проще добраться. Даже MAC-адрес фида на однонаправленной линии (FUMAC), нужный для работы, не снабжён универсальным способом обнаружения. Общий формат упорядочивает обмен, но полезность пути по-прежнему определяется локальной настройкой.

Слово «двусторонний» скрывает разницу в задержках. В RFC в качестве примера приводится около 250 миллисекунд задержки в одну сторону для геостационарного спутника; интернет-канал возврата тоже имеет переменную задержку. Спецификация предупреждает, что реактивное разрешение адресов вроде ARP может заставить фид ждать ответ, пока пакеты накапливаются, а затем исчерпать буфер и привести к потерям. Это инженерный риск, описанный в стандарте, а не измерение конкретной службы. Пути объединены, но не становятся одинаковыми по задержке, пропускной способности или подчинённости.

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

Доверие относится к другому уровню. RFC предупреждает, что подмена ARP или IP может открыть услугу неавторизованным узлам. В качестве противодействия предлагается аутентифицировать туннели, однако сам механизм не специфицирован. Протоколы маршрутизации на эмулируемом сегменте должны использовать собственную доступную аутентификацию, чтобы не допустить внедрения ложных маршрутов неавторизованным приёмником. JOIN и объявленные через DTCP адреса — это сообщения, а не учётные данные.

Спецификация также не обещает автоматическую совместимость оборудования. Профиль применения должен определить MAC-формат и тип туннеля; если используется не GRE, его значение стороны должны согласовать отдельно. Настройка многоадресной маршрутизации и масштабирование оставлены за пределами RFC. Она делает однонаправленный канал пригодным для использования, соединяя его с обратной сетью, но не унифицирует пути и не задаёт доверие по умолчанию.

Основные источники