4.4.5. Протокол XTP

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Транспортный протокол XTP (xpress transport protocol; http://www.ca.sandia.gov/xtp/) разработан в 1992 году, является протоколом нового поколения и имеет целью преодолеть недостатки такого популярного протокола как TCP (медленный старт, неэффективная работа при возникновении потерь пакетов). В XTP функции обеспечения надежной передачи данных и управления разделены, протокол допускает управление пропускной способностью канала и успешно справляется с перегрузкой канала. Принципиальной особенностью XTP является независимость от числа участников информационного обмена (обычный режим эквивалентен мультикастингу, по этой причине XTP может использоваться и как мультикастинг-протокол) и возможность работы с MAC, IP или AAL5. Протокол призван в перспективе заменить TCP, UDP, Appletalk и IPX. Мультикастинг в XTP в отличии от других протоколов может гарантировать доставку информации, что может оказаться важным при многоточечном управлении или в некоторых распределенных базах данных.

При передаче больших массивов информации последовательные пакеты нумеруются. В случае потери принимающая сторона посылает отправителю список не доставленных пакетов (TCP повторяет пересылку всех пакетов, начиная с потерянного). Именно алгоритм селективной ретрансмиссии и позволяет повысить эффективность использования канала. Длина пакетов XTP кратна 64 бит. Совокупность информации, описывающей состояние XTP, называется контекстом. Каждый контекст управляет как входящим, так и исходящим потоками данных. Два активных контекста и поток данных образуют ассоциацию. В исходном состоянии контекст оконечной системы пассивен и находится в состоянии ожидания. Первый передаваемый пакет содержит полную адресную информацию. После получения первого пакета контекст становится активным. С этого момента ассоциация сформирована и обмен может происходить в обоих направлениях. Каждый последующий пакет несет в себе ключевой код, определяющий его принадлежность к данному контексту. При завершении передачи устанавливаются соответствующие биты опций, связь разрывается, а контексты возвращаются в пассивное состояние. Все виды XTP-пакетов имеют один и тот же формат заголовков. Управление контекстом осуществляется с помощью флагов, содержащихся в заголовке. Всего предусмотрено 15 флагов.

На рис. 4.4.5.1 показана зависимость пропускной способности канала для сети ATM при использовании транспортных протоколов TCP и XTP, в обоих случая использовался в качестве базового протокол IP. Измерения производились для приложений типа FTP. Из рисунка видно, что даже 1% потерянных или поврежденных пакетов понижает пропускную способность на 30% при работе с протоколом TCP. XTP требует только три пакета, чтобы сформировать виртуальный канал, в то время как XTP требует для тех же целей семь пакетов. Благодаря своей простоте XTP может легко подменить любой транспортный протокол в любом существующем телекоммуникационном приложении. Протокол предоставляет некоторые услуги недоступные в других протоколах, что оказывается особенно привлекательным для приложений мультимедиа.

Рис. 4.4.5.1. Зависимость пропускной способности канала при использовании протоколов TCP и XTP ( www.mentat.com/xtp.xtp.html и xtpdata.html XTP 95-20, Xpress Transport Protocol Specification (XTP revision 4.0), 1995, XTP Forum, Santa Barbara, CA 93108 USA )

При 5% потерях пакетов XTP обеспечивает в 6 раз большую пропускную способность, чем TCP. В таблице 4.4.5.1 приведены сравнительные результаты измерения пропускной способности канала ATM (155 Мбит/с) при использовании протоколов TCP, UDP и XTP (использовались пакеты длиной 8190 байт).

Таблица 4.4.5.1. Сравнительные характеристики протоколов TCP, UDPи XTP

Из таблицы видно, что в нормальных условиях протокол XTP гарантирует пропускную способность на 25% выше, чем TCP или UDP.

Все поля в XTP-пакетах передаются так, что наиболее значимый байт передается первым (порядок байт - "big-endian"). Формат заголовка XTP-пакета показан на рис. 4.4.5.2. Поле ключ определяет принадлежность пакета к тому или иному контексту, поле команда (CMD) задает процедуру обработки пакета. Поле длина (DLEN) определяет объем данных в пакете, а поле номер по порядку (SEQ) представляет собой порядковый номер пакета в последовательности. Поля контрольная сумма и синхронизация используются для проверки корректности доставки. Старший бит поля ключ (RTN - возврат, рис. 4.4.5.3) зарезервирован в качестве флага, указывающего на контекст передающей (=0) или принимающей стороны (принимающая сторона, посылая пакеты, ставит RTN=1). Код поля ключ должен быть уникальным. Для обеспечения этого остальная часть поля делится на два субполя: индекс и инстанция (распределение бит между ними зависит от реализации и реальных потребностей). Индекс служит для выбора контекста, а инстанция подтверждает корректность кода индекс. Так при получении пакета сначала по индексу определяется контекст, а затем производится сравнение кодов инстанции в пакете и в таблице контекстов.

Рис. 4.4.5.2 Формат кадра протокола XTP

Рис. 4.4.5.3 Структура поля ключ

32-разрядное поле команды содержит в себе субполе опции. Названия различных бит этого поля показаны на рис. 4.4.5.4.

Рис. 4.4.5.4. Формат поля команда

btag=1	указывает на то, что первые восемь байт сегмента данных стали полем btag (beginning tag field - начальная метка). Служит для постановки меток для прикладных программ. BTAG имеет смысл только для информационных пакетов и должен быть обнулен для всех остальных.
dreq=1	SEQ данного пакета.
edge	при получении пакета значение этого бита сравнивается с со значение бита edge предыдущего пакета. Если их величины отличаются, посылается управляющий пакет. Отправитель может изменять значения этого бита, чтобы вызвать присылку управляющего пакета, не привлекая механизма SREQ или DREQ.
end=1	указывает на прекращение использования данного контекста, устанавливается в последнем пакете, завершающем диалог, а также при ликвидации ассоциации.
EOM	служит для обозначения границ сообщения в потоке данных. Если EOM=1, то этот пакет завершает сообщение. Управляющие пакеты не должны иметь EOM=1. Этот бит устанавливается прикладной, а не протокольной программой.
fastnak	показывает, что получатель должен обеспечивать быстрое отрицательное подтверждение (если необходимо). Этот бит устанавливается отправителем лишь тогда, когда протокольный уровень ниже XTP не меняет часто порядок пакетов.
multi=1	указывает на использование режима мульткастинга. Значение этого бита должно быть идентичным для всех пакетов в период жизни ассоциации.
noerr=1	информирует получателя о том, что отправитель не будет повторно присылать пакеты и рекомендует получателю отключить контроль ошибок.
Nocheck=1	указывает на то, что контрольная сумма вычислена только для полей заголовка, в противном случае - для всего пакета.
Noflow=1	указывает на то, что отправитель не следит за ограничениями потока данных (например, игнорирует значение alloc).
RES=1	позволяет режим резервирования. Устанавливая его, отправитель обращает внимание получателя на то, что значение alloc, присланные получателем в контрольных пакетах, должно соответствовать реальному объему свободного буферного пространства.
Sort=1	указывает, что значение кода в поле sort заголовка должно интерпретироваться и использоваться для приоритетного отбора пакетов.
sreq=1	указывает получателю, что он должен немедленно послать контрольный пакет. Бит SREQ устанавливается отправителем в соответствии со своей политикой подтверждений или в случае возникновения ошибок.
Wclose и Rclose	используются при диалоге отсоединения. wclose-бит указывает на то, что не будет больше записей в выходной информационный поток. rclose-бит служит для того, чтобы сообщить, что все биты, занесенные во входной поток, доставлены.

XTP-передатчик контролирует все биты поля опции для каждого пакета. Некоторые дополнительные данные о битах субполя опции можно найти в таблице 4.4.5.2.

Таблица 4.4.5.2. Значения битов субполя опции

"По-пакетно" означает, что бит может изменяться от пакета к пакету. "Раз на ассоциацию" означает, что все контексты ассоциации должны иметь этот бит идентичным. "Один раз" означает, что бит может быть установлен один раз за время жизни контекста

Таблица 4.4.5.3. Коды типов пакетов XTP (Pformat)

Младший байт поля команда содержит субполе типа пакета (ptype). Биты 0-4 этого субполя содержат код формата пакета (Pformat, см. таблицу 4.4.5.3). Биты 5-7 определяют версию протокола (ver). Для XTP 4.0 код версии равен 001.

Поле DLEN содержит число байт в массиве данных пакета, следующем непосредственно за заголовком. Так как информационные пакеты с нулевым объемом данных запрещены, код dlen не может быть равен нулю.

Поле Check содержит контрольную сумму. Если бит nochek=1, то в поле записана контрольная сумма только заголовка, в противном случае - всего пакета.

Поле приоритет (sort) предназначено для задания приоритета пересылаемой информации. Это поле интерпретируется лишь в случае, если бит sort=1. При sort=0 поле приоритет должно быть обнулено. Контексты с приоритетным трафиком посылают пакеты с sort=1 и с определенным кодом в поле приоритет. Бесприоритетные контексты шлют пакеты с sort=0 и нулевым полем приоритета. На приемной стороне информация доставляется в соответствии с кодом приоритета. Поле приоритет характеризуется беззнаковым 16-разрядным числом. Код приоритет, равный нулю, указывает на самый низкий приоритет, чем больше этот код, тем выше приоритет. XTP обслуживает активные контексты в соответствии с присвоенными им приоритетами. Высокоприоритетная информация посылается раньше низкоприоритетной. Аналогичный порядок обслуживания работает и на принимающей стороне.

32-битовое поле синхронизация (Sync) служит для синхронизации диалога. Каждый контекст хранит код последнего посланного значения Sync в переменной Saved_sync. Когда пакет послан с Sreq=1, значение переменной Saved_sync увеличивается на единицу и этот код заносится в поле Sync отправляемого пакета. Получатель запоминает последний полученный код Sync в контекстной переменной Rcvd_sync. Значение этой переменной записывается в поле эхо каждого посылаемого управляющего пакета. Когда управляющий пакет получен, код поля sync сравнивается со значением Rcvd_sync. Если sync і Rcvd_sync, то управляющий пакет обрабатывается нормально. В противном случае управляющий пакет содержит информацию, которая старее полученной с предыдущими пакетами, и обрабатываться не должен.

Поле номер по прядку (SEQ) характеризуется 64-разрядным числом без знака и представляет собой порядковый номер байта в передаваемом потоке. Для первого пакета (first) поле SEQ характеризует объем буферов для потока откликов, а для пакетов Join это поле содержит дентификатор получателя (ключ контекста). Join-пакет отклик на запрос содержит в поле SEQ порядковый номер байта для текущей ассоциации. Диапазон значений поля номер по порядку для информационных пакетов начинается с SEQ и простирается вплоть до SEQ+ DLEN - 1. Для DIAG пакетов поле SEQ содержит код SEQ входного пакета, который вызвал ошибку. Если посылка пакета DIAG вызвана не входным пакетом, код SEQ должен быть равен нулю.

Вслед за заголовком обычно следует его расширение (сегмент), формат которого зависит от типа пакета. Используются управляющие и информационные сегменты.

Управляющие сегменты несут в себе информацию о состоянии контекста, его приславшего. XTP пакеты, содержащие управляющие сегменты называются контрольными пакетами. Управляющие сегменты содержат пакеты типа Cntl, Ecntl и Tcntl. Управляющий сегмент Cntl-пакета несет в себе информацию об управлении обменом. Ecntl-пакеты включают в себя сегменты управления ошибками, а Tcntl-пакеты - сегменты управления трафиком. Формат управляющего сегмента показан на рис. 4.4.5.5.

Рис. 4.4.5.5 Формат общего управляющего сегмента пакета XTP

Три поля общего управляющего сегмента представляют статусную информацию и содержатся во всех трех типах контрольных пакетов. Первые два поля RSEQ и alloc являются параметрами управления обменом. Поле Echo используется для идентификации контрольных пакетов, которые являются откликом на пакеты с битом SREQ=1. Поле RSEQ содержит в себе номер очередного байта, подлежащего пересылке, и определяет начало окна, управляющего обменом. Поле Alloc интерпретируется, когда разрешено управление обменом. Код поля Alloc определяет объем данных, который отправитель может послать (а получатель принять). Если бит RES=1, то поле Alloc задает размер буфера, зарезервированного для данной ассоциации. Поле Echo используется для установления соответствия между запросом статуса и контрольными пакетами. Код поля Echo равен наибольшему значению sync для полученных пакетов. Это значение хранится в контекстной переменной rcvd_sync. Когда формируется контрольный пакет, значение rcvd_sync заносится в поле Echo этого пакета.

Формат сегмента управления ошибками показан на рис. 4.4.5.6. Этот сегмент включает в себя все поля общего управляющего сегмента, дополнительно использовано только два поля Nspan и Spans, которые сообщают о том, какие пакеты потеряны.

Рис. 4.4.5.6 Формат сегмента управления ошибками

Сегмент управления ошибками используется в пакетах Ecntl. Поле Nspan определяет число Spans в Ecntl-пакете. Так как пакет Ecntl посылается только в случае потери информации, поле Nspan несет в себе код не меньше 1. Поле Spans содержит в себе Nspan пар чисел, которые характеризуют интервалы номеров байт, переданных корректно. Речь здесь идет о данных, имеющих номера больше того, который указан в поле RSEQ. На основании этих данных можно вычислить, какая именно информация потеряна.

Формат сегмента управления трафиком показан на рис. 4.4.5.7. Помимо полей общего управляющего сегмента здесь присутствуют поля RSVD и XKEY, а также спецификация трафика. Поле RSVD является резервным и должно содержать нуль. Поле XKEY является обязательной принадлежностью всех Tcntl-пакетов, величина этого поля должна равняться значению ключа для контекста, посылающего пакет (бит RTN=1). Спецификация трафика используется в пакетах типа first и Tcnnl. Пакет first предлагает параметры режима обмена, а Tcntl несет в себе отклик на это предложение.

Рис. 4.4.5.7 Формат сегмента управления трафиком

Поле tlen определяет длину спецификации трафика, включая 4-байтовый дескриптор (tlen і ). Поле service используется для задания типа транспортного сервиса на фазе установления режима обмена. Коды доступных видов сервиса представлены в таблице 4.4.5.4. Эта информация передается в пакете типа first.

Таблица 4.4.5.4. Коды поля тип сервиса (service)

Код типа сервиса	Описание
0x00	Не специфицировано
0x01	Традиционная передача дейтограмм без подтверждения
0x02	Передача дейтограмм с подтверждением
0x03	Реализация транзакций
0x04	Традиционная передача потока данных с гарантированной доставкой
0x05	Передача потока данных в мультикастинг-режиме без подтверждения
0x06	Мультикастинг режим передачи потока данных с гарантированной доставкой

Поле tformat определяет формат поля traffic. Код tformat=0 используется тогда, когда не нужно ни какой спецификации трафика, в 4-байтовое поле traffic в этом случае записываются нули. В противном случае используется код tformat=0x01. Формат поля traffic для этого арианта показан на рис. 4.4.5.8.

Рис. 4.4.5.8 Формат поля traffic

Поле maxdata несет в себе код максимального размера информационного сегмента, который отправитель может послать за время жизни ассоциации. Поля inrate и inburst представляют собой параметры, определяющие входной поток данных. Поля outrate и outburst являются параметрами, задающими выходной поток данных.

Информационный сегмент включает в себя пользовательскую и другую протокольную и диагностическую информацию. XTP-пакеты, содержащие информационный сегмент, называются информационными пакетами. К их числу относятся пакеты типа data, first, join и diag. Информационные пакеты могут включать в себя сегмент данных, адресный сегмент, спецификатор трафика и диагностический сегмент. Формат полей адресного сегмента показан на рис. 4.4.5.9.

Рис. 4.4.5.9 Формат полей адресного сегмента

Адресный сегмент используется в пакетах типа first и join. Протокол XTP использует параметрическую схему адресации, возможны несколько форматов адресов отправителя и места назначения. Поле Alen определяет полную длину адресного сегмента. Поле Adomain представляет собой адресный демультиплексор, допуская работу с несколькими адресными доменами. Поле Adomain используется в частности для того, чтобы обеспечить совместимость с протоколами UDP и TCP (для TCP Adomain=6, для UDP 17, а для XTP 36). Поле Aformat идентифицирует адресный синтаксис в соответствии с таблицей 4.4.5.5.

Таблица 4.4.5.5. Значения кодов поля Aformat

Код поля aformat	Синтаксис адреса
0x00	Нулевой адрес
0x01	ip-адрес
0x02	ISO адрес протокольного сетевого уровня для передачи без установления связи
0x03	Адрес сети Ксерокс
0x04	IPX-адрес
0x05	Локальный адрес
0x06	IP-адрес версии 6

Поле адрес несет в себе адреса отправителя и получателя пакетов, форматы которых заданы полем Aformat.

Формат полей сегмента данных показан на рис. 4.4.5.10. Эти сегменты предназначены для применения на прикладных пользовательских уровнях и программами поддержки протокола XTP не интерпретируются. Сегмент включается в пакеты типа first и data.

Рис. 4.4.5.10 Формат полей сегмента данных

Размер поля Data имеет произвольное значение, первые 8 байт (поле Btag) представляют собой специальную метку (если бит опций заголовка btag=1). При Btag=0 метка отсутствует. Интерпретация поля Btag осуществляется исключительно прикладной программой и для XTP его значение безразлично.

Формат полей диагностического сегмента показан на рис. 4.4.5.11. Этот сегмент используется пакетами типа DIAG для информирования протокольной или прикладной программы о случаях ошибок. Поле Code определяет тип и категорию ошибки, вызвавшей отправку пакета типа DIAG. Поле val позволяет уточнить причину ошибки. Поле message является опционным и может иметь произвольную длину. Обычно это поле содержит текстовую интерпретацию полей Code и VAL.

Рис. 4.4.5.11 Форматы полей диагностического сегмента

Назад: 4.4.4. Протокол передачи команд и сообщений об ошибках (ICMP)
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.6. Протокол преобразования адресов ARP