Licklider Transmission Protocol (Licklider Transmission Protocol)

Licklider Transmission Protocol — это протокол связи «точка-точка», предназначенный для использования в каналах связи для дальнего космоса, который был разработан для обеспечения надежной передачи данных по каналам с экстремально большими значениями времени кругового обхода и/или частыми разрывами связи, в связи с чем данный протокол прежде всего предназначен для поддержки надежной дальней связи через межпланетные радиоканалы.

Licklider Transmission Protocol обычно рассматривается как стандартный базовый протокол уровня конвергенции для Bundle Protocol, поддерживающий широкий выбор сетей.

Протокол получил свое наименование в честь американского ученого Джозефа Ликлайдера.

Описание протокола

Работа рассматриваемого протокола начинается с момента, когда экземпляр клиента запрашивает у машины LTP передачу блока данных удаленному клиенту.

LTP рассматривает каждый блок данных, как состоящий из двух частей — «красной» и «зеленой». При доставке «красной» используются подтверждения и при необходимости повторы передачи, а при доставке"зеленой" предпринимаются попытки доставить без обеспечения гарантий. LTP может работать, подобно протоколу TCP и UDP одновременно в рамках одной сессии.

Экземпляр клиента использует программный интерфейс LTP для идентификации LTP экземпляра удаленного клиента, которому нужно передать данные, местоположение передаваемых данных, общий размер передаваемой информации и размер данных в начальной части блока, которые передаются в качестве «красных». Передающая машина начинает сеанс передачи этого блока и уведомляет экземпляр клиента о начале сеанса, при этом важно заметить, что передающая машина не согласует начало сеанса с машиной удаленного клиента.

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

Протокол LTP рассчитан на работу непосредственно «поверх» протокола канального уровня, но может также в некоторых случаях (например, при разработке программ или при использовании в частных ЛВС) работать «поверх» протокола UDP.

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

Таймер запускается в момент маркировки конца «красной» части, поэтому при отсутствии отклика он может быть автоматически запущен снова.

Каждый модуль данных локального протокола канального уровня должен содержать целое число сегментов LTP и локальный протокол канального уровня никогда не должен доставлять неполные сегменты LTP приемной машине LTP. Когда в качестве локального протокола канального уровня используется UDP, следует использовать расширение LTP для аутентификации [LTPEXT], чтобы гарантировать целостность данных в тех случаях. От использования этого расширения можно отказаться, если на всем пути обеспечивается пренебрежимо малая вероятность повреждения пакетов (как в некоторых приватных ЛВС) или последствиями повреждения данных в процессе передачи и/или обработки можно пренебречь (как в некоторых случаях при разработке приложений). Когда расширение LTP для аутентификации не используется, протокол LTP требует от локального протокола канального уровня контроля целостности всех принятых сегментов. В частности, локальный протокол канального уровня должен детектировать и отбрасывать принятые поврежденные сегменты.

Принятые сегменты, которые не были отброшены, передаются приемной машине LTP через интерфейс API, поддерживаемый локальным протоколом канального уровня.

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

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

На следующем этапе помещенный в очередь сегмент подтверждения отчета незамедлительно передается приемной машине.

Приемная машина получает сегмент подтверждения отчета и выключает для этого сегмента таймер повтора. Сеанс приема красной части и передача блока на этом завершается.

Отложенная передача

Информация о состоянии канала также уведомляет LTP о невозможности передачи сегментов. В межпланетной связи ни в какой момент нельзя быть уверенным в наличии двухсторонней связи. В LTP всегда возможна генерация исходящего, который невозможно передать незамедлительно, — в ответ на прием сегмента, по тайм-ауту или запросу клиентского сервиса. Эти сегменты должны помещаться в очередь для последующей передачи, когда канал будет организован, о чем укажет информация о состоянии канала.

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

Создание и размещение сегмента в очереди и последующая реальная передача этого сегмента, в принципе, совершенно не синхронизированы.

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

Концептуально отмена постановки в очередь (de-queuing) сегментов из очередей трафика, привязанных к данному получателю, инициируется при получении сигнала о состоянии канала, указывающего, что базовая коммуникационная система передает данные этому адресату (то есть канал к получателю активен). Это прекращается после получения сигнала о том, что базовая коммуникационная система больше не передает данных этому получателю.

Таймеры

LTP опирается на точный расчет ожидаемого времени прибытия сегментов с отчетами и подтверждениями для того, чтобы знать, когда нужен упреждающий повтор передачи. Если расчетное время оказалось немного раньше, в результате могут возникнуть издержки от ненужного повтора передачи. С другой стороны, расчетное время прибытия может на несколько секунд позже безопасно и единственным «наказанием» за более поздний тайм-аут и повтор передачи будет незначительная задержка доставки данных и освобождения ресурсов сессии.

Поскольку статистику, основанную на истории интервалов кругового обхода, невозможно безопасно использовать для предсказания времени кругового обхода LTP, мы должны предположить, что время кругового обхода по крайней мере приблизительно детерминировано (то есть достаточно точная оценка значения RTT может быть выполнена индивидуально в реальном масштабе времени на основе доступной информации).

Расчет выполняется в два этапа:

Первое приближение RTT рассчитывается простым удвоением времени прохождения светового луча к получателю с добавлением произвольного значения предполагаемой дополнительной задержки (например, в очередях или при обработке в оконечных точках). Для операций в глубоком космосе такая добавка обычно составит несколько (немного) секунд. Хотя такая добавка представляется аномальной с точки зрения стандартов Internet, она невелика по сравнению со временем прохождения света туда и обратно. Мы предпочли риск запоздалого повтора передачи, который просто задержит доставку одного блока на сравнительно небольшое время, слишком раннему повтору, ведущему к неоправданному расходу пропускной способности и общему снижению производительности.
Затем для учета дополнительных задержек, вносимых перебоями в связи, таймеры динамически приостанавливаются на те периоды, когда относящиеся к делу удаленные машины LTP заведомо не способны передавать отклики. Предполагается, что состояние удаленных систем определяется на основе сигналов о состоянии канала от работающего оборудования.

Приведенное ниже обсуждение служит базой для расчетов ожидаемого времени прибытия LTP.

Общее время, требуемое для одного «кругового обхода» (передача и прием исходного сегмента, а затем передача и прием сегмента подтверждения) состоит из перечисленных ниже компонент.

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

В этом контексте, где могут возникать ошибки продолжительностью в секунды и даже минуты, протокольное время обработки на каждой из сторон сессии считается пренебрежимо малым.

Задержка во входной очереди также считается пренебрежимо малой, поскольку даже на мелких космических станциях скорость обработки LTP значительно выше скорости передачи данных.

Применяется два механизма снижения задержки в выходных очередях до пренебрежимо малых значений.

Ожидаемое время прибытия сегмента подтверждения не рассчитывается, пока базовая система связи не уведомит LTP о начале передачи исходного сегмента. Все задержки выходногой очереде для исходного сегмента к этому моменту уже состоялись.
Модель отложенной передачи LTP минимизирует задержку доставки сегментов подтверждений (отчеты и подтверждения) базовой коммуникационной системе. Таким образом, сегменты подтверждения (концептуально) добавляются в конец внутренней очереди операций, а не в очередь данных приложения, поэтому они имеют более высокий приоритет передачи по сравнению с другими исходящими сегментами, то есть они всегда должны извлекаться из очереди для первостепенной передачи. Это ограничивает задержку в выходной очереди для данного сегмента подтверждения до времени, требуемого для извлечения из очереди и отправки всех ранее созданных сегментов подтверждения, которые еще находятся в очереди на передачу. Поскольку сегменты подтверждения передаются нечасто, и обычно малы, задержка данного сегмента подтверждения в выходной очереди будет, вероятно, минимальной.

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

Задержка при передаче на каждой стороне сессии — это просто размер сегмента, поделенный на скорость передачи. Она несущественна за исключением ситуаций, когда скорость передачи предельно мала (например, 10 бит/с) и применение LTP может оказаться нецелесообразным по иным причинам (например, издержки, связанные с заголовком LTP, могут быть слишком велики при такой скорости). Поэтому задержкой на излучение обычно пренебрегают.

Предполагается, что время распространения сигнала в одном направлении с точностью до секунды известно всегда (например, обеспечивается рабочей средой).

Поэтому начальное ожидаемое время прибытия для каждого сегмента подтверждения обычно рассчитывается путем добавления к текущему времени излучения исходного сегмента удвоенного времени прохождения сигнала в одном направлении и 2*N секунд запаса для учета задержки в очередях и при обработке и длительности излучения на обеих сторонах. Параметр N устанавливается системой управления и значение 2 секунды представляется разумным по умолчанию.

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

Повтор передачи

Потеря или повреждение переданного сегмента может привести к отклонению работы LTP от обычной последовательности событий, описанной выше.

Потеря одного или нескольких сегментов данных красной части, отличных от сегмента EORP, вызывает повторную передачу данных — приемная машина возвращает отчет, указывающий все полученные непрерывные диапазоны красной части (в предположении, что не были получены описанные ниже дискреционные контрольные точки). Отчет о получении обычно передается в одном отчетном сегменте, содержащем уникальный порядковый номер отчета и охват красной части данных. Например, если данные красной части охватывали блок со смещениями [0:1000] и были получены все данные, кроме диапазона [500:600], сегмент отчета будет содержать уникальный номер (скажем, 100), а охват [0:1000] будет указан двумя записями — (0:500) и (600:1000). Максимальный размер сегмента отчета, как и всех сегментов LTP, ограничивается значением MTU в канале данных. Если было потеряно много дискретных сегментов одного большого блока и/или значение MTU в канале данных достаточно мало, может потребоваться создание множества сегментов отчета. В таких случаях LTP создает нужное число сегментов данных и делит область охвата красной части между сегментами отчетов так, что каждый из них может сохранять самостоятельность.

При получении каждого отчетного сегмента передающая машина выполняет указанные ниже действия.

Выключение таймера для контрольной точки, указанной полученным сегментом отчета (при наличии).
Размещение в очереди подтверждения приема отчетного сегмента для отключения таймера повтора на приемной стороне). Этот сегмент передается при ближайшей возможности.
Если прием данных, указанный в сегменте отчета, говорит о том, что не все охваченные данные были получены, обычно инициируется повторная передача путем добавления в очередь всех не принятых сегментов. Последний из таких сегментов помечается как контрольная точка и содержит порядковый номер сегмента отчета, для которого выполняется повтор передачи. Эти сегменты также отправляются при ближайшей возможности, но лишь после сегментов, ранее помещенных в очередь для передачи приемной стороне. Запускается таймер для контрольной точки, чтобы повторить передачу, если не будет получен соответствующий сегмент отчета.
Если прием данных, указанный в сегменте отчета, говорит о том, что все охваченные данные были получены, а объединение всех указанных в отчетах приемов данных в этой сессии говорит о получении всей красной части блока, передающая машина уведомляет локального клиента о получении всей красной части блока и окончании красной части сессии.

При получении сегмента подтверждения отчета приемная сторона выключает таймер для этого сегмента. При получении сегмента контрольной точки с отличным от 0 порядковым номером приемная машина выполняет указанные ниже действия:

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

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

Отметим, что избыточный сегмент отчета (то есть уже полученный и обработанный отправителем) передается повторно в результате потери соответствующего сегмента подтверждения отчета, вызывает, например, передачу другого сегмента подтверждения отчета, а в остальных случаях игнорируется. Если какой-либо из сегментов данных, повторно переданных в ответ на исходное получение сегмента отчета, теряется, дальнейший повтор этих сегментов будет запрашиваться отчетом о получении, созданном в ответ на получение последний повторно переданных данных, помеченных как контрольная точка. Таким образом, ненужные повторы подавляются.

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

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

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

Немедленное завершение сеанса после передачи сегмента отчета, который подтверждает полноту приема
Завершение сеанса при получении явного указания от отправителя.

В первом случае потеря финального отчетного сегмента будет вызывать повторную передачу контрольной точки отправителем, но к моменту прибытия переданной повторной контрольной точки сессия уже будет закрыта.

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

Прерывание сессии

Сеанс передачи может быть прерван передающей или приемной машиной в ответ на запрос экземпляра локального клиента или при отказе операции LTP, как указано выше.

Прерывающая сеанс машина удаляет все сегменты из очереди сессии и уведомляет локальный экземпляр соответствующего клиентского сервиса о прерывании сессии. Если никаких сегментов в этой сессии еще не было передано или получено от соответствующей машины LTP, в этот момент прерывающая сессию машина просто закрывает все связанные с сессией состояния и на этом прерывание сессии завершается.

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

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

При следующей возможности помещенный в очередь сегмент подтверждения сегмента прерывания незамедлительно передается прерывающей сессию машине.

Прерывающая сеанс машина получает уведомление о разрыве сессии, выключает таймер сегмента прерывания и закрывает все записи состояния для сессии.

Потеря сегмента прерывания или соответствующего отклика на этот сегмент приводит к тайм-ауту. В этом случае прерывающая сессию машина повторно передает сегмент прерывания.

Особенности

Данный протокол обладает следующими особенностями Архивная копия от 24 февраля 2022 на Wayback Machine:

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

Применение

В 2008 г. Лаборатория реактивного движения по контракту с НАСА установила и протестировала элементы (Bundle Protocol и Licklider Transmission Protocol) DTN-технологии на космическом аппарате дальнего космоса и девяти компьютерах в самой лаборатории. Этот эксперимент выполнялся в тесной кооперации с проектом EPOXI, который представляет собой комбинацию двух компонентов — наблюдения за планетами вне солнечной системы и пролет около кометы Хартли 2. Эксперимент DINET начался, когда КА был на расстоянии около 15 млн миль (24 млн км) от Земли. В ходе эксперимента через DTN-узлы в JPL на борт КА было передано около 300 изображений, после чего они были автоматически пересланы обратно в JPL. При этом отрабатывались следующие элементы DTN-технологии: формирование DTN-связки (bundle), передача, сбор, динамическая маршрутизация, управление переполнением, порядок операций и процедуры автоматической пересылки. Данные элементы отрабатывались как на борту КА, так и на Земле, в течение 27 дней. В течение этого времени КА приблизился к Земле на расстояние около 15 млн км. Временные задержки сигнала составляли соответственно 81 с с начала эксперимента и 49 с к концу. Все пересылаемые бандлы были успешно получены без искажений, несмотря на некоторые плавающие проблемы в работе станций сети дальнего космоса (Deep Space Network — DSN) в процессе слежения. Эксперимент DINET показал возможность космического сетевого обмена данными между узлами с подобной Интернету автоматизацией и низкими затратами на обслуживание.

Ссылки

Nikolai Malykh. RFC 5325 Licklider Transmission Protocol - Motivation (рус.). Энциклопедия сетевых протоколов (21 сентября 2008). Дата обращения: 17 декабря 2020. Архивировано 21 октября 2020 года.