В том случае, когда информация о фактическом размещении данных кадра основной полосы (например, в DVB-S2 в поле длина поля данных (Data Field Length) не представлена, так как информация сигнализации переносится в Заголовке Основной Полосы, то приемник должен распознавать присутствие дополнения посредством обнаружения конкретной комбинации битов индикатора старта, индикатора конца и типа метки. Синтаксис структуры кадра основной полосы показан в таблице 2. Приемник должен отбрасывать любые пакеты GSE, следующие за этой комбинацией, которая никогда не должна использоваться для каких-либо заголовков GSE.
Таблица 2
Синтаксис структуры кадра основной полосы
Каждый пакет GSE состоит из Заголовка GSE и последующей полезной нагрузки GSE, где находится инкапсулированный PDU или фрагмент инкапсулированного PDU. На рисунке 2 показан формат заголовка GSE. Применение незаштрихованных полей всегда обязательно, а заштрихованные поля могут быть опущены в зависимости от типов предыдущих полей управления в первых 4 битах заголовка GSE. Наличие возможных заголовков расширения определяется типом протокола. Минимальная длина заголовка GSE 2 байта.
![]() Рисунок 2 - Формат заголовков GSE
Далее представлена семантика основных пакетов GSE:
Label_Type_Indicator: Поле 2 бита. При наличии дополнения в поле Label_Type_Indicator должно быть установлено "00". В противном случае, если в поле Start_Indicator установлен "0", то Label_Type_Indicator зарезервирован, и в поле должно быть установлено "11". Семантика величин поля Label_Type_Indicator показана в таблице 3. Определение меток и способов адресации представлено в разделе 5.
Таблица 3
Семантика величин поля Label_Type_Indicator
Padding_bits: Биты дополнения должны быть установлены в "0".
Примечание - N1 это количество байтов до конца кадра основной полосы.
Padding_bytes: Байты дополнения, в поле должен быть установлен "0". В случае применения дополнения в Start_Indicator, End_Indicator и Label_Type_Indicator должен быть установлен "0"/"00".
GSE_Length: Поле 12 битов указывает размер в байтах пакета GSE, отсчитываемого от байта после поля GSE_Length. Максимальная длина GSE_Length для пакета GSE может составлять 4096 байт. Поле GSE_Length указывает на начало следующего пакета GSE, на окончание поля данных (Data Field) или начало поля дополнения, если пакет GSE является в кадре последним.
Protocol_Type: Поле 16 битов указывает тип нагрузки, переносимой в PDU или присутствие Next-заголовка. Совокупность значений, которые могут переноситься в этом поле, делится на диапазоны двух типов и должны следовать правилам, описанным в [5]:
- Тип 1: Тип поля Next-заголовок. Первый тип диапазона пространства значений соответствует диапазону от 0 до 1535 десятичных значений. Эти значения могут быть использованы для идентификации конкретных канальных протоколов и/или могут указывать на наличие Заголовков расширения, которые несут дополнительные поля опциональных протоколов (например, шунтирование инкапсуляции). Диапазон подразделен на значения от 0 до 256 и от 256 до 1535 в зависимости от типа расширения. Использование этих значений координируется реестром [5].
- Тип 2: Тип поля совместимый EtherType. Второй тип диапазона пространства лежит в интервале значений между 0x600 (1536 десятичных значений) и 0xFFFF. Этот набор присвоений типа следует назначениям DIX/IEEE (не допускается использование этого диапазона в качестве указателя длины кадра). Все присвоения в этом пространстве используют значения, определенные для EtherType. Следующие два значения типа представлены в качестве примеров (взятых из реестра EtherTypes IEEE):
Пример:
0x0800: IPv4 Payload
0x86DD: IPv6 Payload.
6_byte_Label: Поле 48 битов содержит метку 6 байт, применяемую для адресации (см. раздел 5).
3_byte_Label: Поле 24 бита содержит метку 3 байта, применяемую для адресации (см. раздел 5).
Примечание - N2 является длиной в байтах расширения заголовков, установленных в соответствии с [5].
Extension_Header_byte: Опциональные байты могут быть использованы для выполнения одного или нескольких заголовков расширения. Формат заголовка расширения определен в [5].
Примечание - N3 представляет собой длину инкапсулированного PDU или фрагмента PDU в байтах.
PDU_data_byte: Эти байты содержат данные PDU.
CRC_32: Это поле присутствует только в пакете GSE, который несет последний фрагмент PDU. Это поле должно быть установлено в соответствии с 4.2.3.
Детализированная семантика пакета GSE представлена в [7] (4.2.1).
4.2.2 Кодер CRC-32
При сборке приемником фрагментов PDU, рассеянных по нескольким кадрам, существует вероятность того, что фрагмент может отсутствовать. Возможность обнаружения ошибок GSE, обусловленных неправильной сборкой, достигается вычислением CRC-32 на уровне PDU для каждого фрагментированного PDU.
Каждый пакет GSE, в котором бит S равен "0", а бит E равен "1", переносит 32-битовое поле CRC в последних четырех байтах пакета GSE. Это облегчает вычисление CRC аппаратными средствами. При вычислении CRC используется полином CRC-32, представленный ниже. Это 32-битовое значение рассчитывается в соответствии с порождающим полиномом
, представленным в шестнадцатеричном исчислении:X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 +
+ X5 + X4 + X2 + X1 + X0.
Инкапсулятор инициализирует накапливающий регистр CRC-32, устанавливая значение 0xFFFF FFFF. Затем он вычисляет значение CRC-32 пакета GSE для передачи. Пакет GSE включает все байты полезной нагрузки PDU и поля: общей длины, типа протокола, метки (если передается) и расширения заголовков (если имеют место). Вычисленное значение CRC-32 помещается в поле CRC. Процедура вычисления близка к процедуре, применяемой в протоколе SCTP ([8]) при вычислении контрольной суммы.
При сборке PDU приемник выполняет поверку целостности независимым вычислением величины CRC всего собранного PDU с добавлением вышеупомянутых полей и сравнением этой величины с переданной величиной в последнем трейлере пакета GSE.
PDU, не прошедшие проверку величины CRC, отбрасываются, заставляя приемник войти в состояние ожидания.
Пример вычислений CRC показан на рисунке 3. В качестве примера приведен случай, когда PDU разделен на три фрагмента, которые переданы в трех пакетах GSE.
![]() Затененные поля на рисунке 3 обозначают те фрагменты, которые участвуют в вычислении CRC: байты, по которым должен быть вычислен CRC, опуская поле общая длина, не принимая во внимание все последующие заголовки пакета GSE вплоть до поля ID Frag и не включая поле CRC.
Пакеты GSE с данными от PDU должны иметь одинаковый ID Frag и должны передаваться по порядку. Однако они не могут быть переданы последовательно, так как могут чередоваться с пакетами GSE, переносящими полные PDU или фрагменты с другими ID Frag. Собранные PDU будут поставлены на более высокие уровни после приема последнего фрагмента PDU.
При фрагментации применяются следующие правила:
- все пакеты GSE, переносящие данные одного и того же PDU, должны иметь одинаковые ID Frag;
- первый пакет GSE с конкретным ID Frag должен иметь бит S, равный "1", и бит E, равный "0";
- пакеты GSE, переносящие фрагменты PDU, которые не являются ни первым, ни последним фрагментом PDU, должны иметь бит S, равный "0", и бит E, равный "0";
- последний пакет GSE с конкретным ID Frag должен иметь бит S, равный "0", и бит E, равный "1";
- до тех пор, пока PDU не заполнен, его ID Frag не должен повторно использоваться на интервале 256 кадров основной полосы;
- все пакеты GSE с одинаковым ID Frag должны передаваться в порядке очередности;
- поле метка должно использоваться только в первом пакете GSE.
Всякий раз при фрагментации инкапсулятор GSE исполняет первые байты X1 PDU и следующие операции:
- формирует пакет GSE с установкой бита S, равного "1", и с установкой бита E, равного "0";
- устанавливает в поле длина GSE расчетное количество байтов, включая длину данных X1 PDU (см. рисунок 3), длины полей ID Frag, общей длины, тип протокола, уровень (если поле уровень существует) и любого заголовка расширения. Полезная нагрузка GSE переносится в первой части инкапсулированного PDU с длиной X1 байтов. Полученная длина GSE не должна превышать величину остающегося свободного пространства в текущем поле данных кадра основной полосы;
- устанавливает свободное значение ID Frag;
- устанавливает в поле общая длина расчетное количество байтов, включая длину нефрагментированного PDU, поля тип протокола, поля метка (при наличии) и любого заголовка расширения;
- добавляет поле тип протокола;
- добавляет поле метка (если применяется);
- выполняет вставки X1 (см. рисунок 3) байтов из данных PDU в полезную нагрузку GSE;
- помещает этот пакет GSE в текущем кадре первым пакетом GSE или после любого другого пакета GSE, уже присутствующего в кадре.
Когда PDU разделен на количество фрагментов более двух, инкапсулятор GSE принимает следующие X2 (см. рисунок 3) данные PDU и:
- формирует пакет GSE с установкой бита S в "0" и с установкой бита E в "0";
- устанавливает в поле общая длина в заголовке GSE расчетное количество байтов, включая длину данных X2 PDU и поля ID Frag. Полученная длина GSE не должна превышать величину остающегося свободного пространства в текущем поле данных кадра основной полосы;
- устанавливает то же значение ID Frag, что и в предыдущем фрагменте этого PDU;
- вставляет байты X2 (см. рисунок 3) из PDU в полезную нагрузку GSE и следующие операции;
- помещает этот пакет GSE в выбранный кадр (в зависимости от алгоритма планирования) как первый пакет GSE или после любого другого пакета GSE уже присутствующего в кадре. Такая же операция повторяется для всех фрагментов PDU за исключением последнего.
Инкапсулятор GSE обрабатывает остающиеся X3 данные PDU (см. рисунок 3) и следующие операции:
- формирует пакет GSE с установкой бита S в "0" и с установкой бита E в "1";
- устанавливает в поле длина GSE в заголовке GSE расчетное количество байтов, включая длину поля данные PDU X3, поля ID Frag и размера поля CRC-32. Полученная длина GSE не должна превышать остающееся свободное пространство в текущем поле данных кадра основной полосы;
- устанавливает в поле ID Frag ту же самую величину, что и в предыдущих фрагментах этого PDU;
- вставляет остающийся X3 (см. рисунок 3), данные PDU в полезной нагрузке GSE и добавляет CRC 32;
- помещает этот пакет GSE в выбранном кадре основной полосы в качестве первого пакета GSE или после любого другого пакета GSE, уже установленного в кадре.
Примеры форматов пакетов GSE приведены в приложении В.
Поле метка является опциональным. В зависимости от величины, установленной в поле индикатор типа метки, оно может иметь длину 6 байтов, 3 байта или может отсутствовать. Зависимость параметров поля метка от установленного значения в поле индикатор типа метки (LT) представлена ниже.
Поле индикатор типа метки, содержащее "00" или "01", соответствует одноадресным пакетам IP, предназначенным для использования маршрутизаторами линий коллективного пользования (т.е. линий, соединяющих несколько приемников).
Поле метка может не использоваться (установлено "10") в тех случаях, когда одноадресные IP-пакеты и/или многоадресные пакеты поставляются к приемникам, которые могут использовать дискриминатор поля (например, адрес получателя IPv4/IPv6 или параллельный MAC адрес доставки) инкапсулированные протоколом, которые могут быть интерпретированы как адреса уровня 2.
При значении индикатора типа метки "00" 6-байтовая метка следует непосредственно за полем тип протокола (например, может переносить поле точка присоединения к сети (Network Point of Attachment; NPA)).
При значении индикатора типа метки "01" 3-байтовая метка (например, поле NPA), следует непосредственно за полем тип протокола. Обработка приемником пакетов GSE с 3-байтовой меткой является опциональной.
В режиме адресации "По умолчанию" адресация поля тип протокола соответствует адресам назначения NPA, которые являются 6-байтовыми числами, обычно выражаемыми в шестнадцатеричном исчислении. Метки могут использоваться для идентификации тех приемников в сети, которые должны обрабатывать конкретные пакеты GSE. 3-байтовая метка может использоваться в качестве альтернативной адресации, например, в сетях DVB-RCS, где 3-байтовая метка может представить 1-байтовый ID группы и 2-байтовый ID входа (в систему).
Значение адреса 0x00:00:00:00:00:00 в качестве метки в пакете GSE не используется. Младший значащий бит первого байта поля тип протокола устанавливается в "1" для многоадресных кадров. Остающиеся байты определяют групповой адрес канального уровня. Конкретное значение адреса 0xFF:FF:FF:FF:FF:FF определяет адрес соединения вещания. Это означает, что собранный PDU (если он был фрагментирован) должен быть поставлен всем приемникам.
Пакеты IPv4, переносящие адрес вещания подсети IPv4, должны быть поставлены всем системам с тем же префиксом сети. В присутствии 6-байтовой метки GSE индикатор типа метки установлен в "00", 6-байтовая метка должна переносить адрес NPA соединения вещания (0xFF:FF:FF:FF:FF:FF). В тех случаях, когда PDU является многоадресным пакетом IP и используется 6-байтовая метка GSE (индикатор типа метки установлен в "00"), групповой адрес приемника IP многоадресного пакета должен быть отображен в многоадресном поле тип протокола (в соответствии с методом, используемым для формирования MAC-адреса назначения в Ethernet). Метод отображения групповых адресов IPv4 определен в [9]. Метод отображения групповых адресов IPv6 определен в [10].
При передаче нескольких последовательных PDU к одному месту назначения метки повторного использования могут быть опущены. В этом случае поле тип протокола может быть удалено из всех сцепленных пакетов GSE, кроме первого (индикатор типа этикетки установлен на "11"). Первый пакет из объединенных пакетов GSE должен содержать метку 3 байта или метку 6 байтов (индикатор поля тип протокола установлен на "00" или "01"). Приемник, который принимает пакет GSE с меткой в режиме повторного использования, предполагает, что поле тип протокола ранее принятого пакета GSE остается в силе. Метку повторного использования допускается применять в том случае, когда пакеты GSE передаются в том же кадре основной полосы.
Допускается поддержка протоколом GSE одновременного использования нескольких 6-байтовых адресов и одного 3-байтового адреса. Механизм привязки для каждого адреса настоящим стандартом не определен и должен разрабатываться дополнительно.
Терминал может использовать следующие варианты адресации:
- все терминалы с одноадресным MAC могут использовать свой аппаратный адрес MAC как 6-байтовый адрес. Такая адресация действительна для всех типов терминалов (например, в системе DVB-S2 - в режиме приема, в системе DVB-RCS - в наземном обратном канале и т.д.);
- терминалы могут использовать механизм отображения MAC к IP, описанный в [9] и [10] для IPv4 и IPv6 многоадресной сигнализации адреса при получении сигнала в прямом канале (см. раздел 6).
Терминал также может поддерживать другие механизмы адресации, такие как:
- однонаправленный механизм для безадресного режима при инкапсуляции IP дейтаграмм для передачи через транспортный поток MPEG-2, описанный в [5];
- терминалы DVB-RCS могут связывать свой ID групповой регистрации с 3-байтовым адресом, если это отображено в прямом канале (см. раздел 6);
- возможны другие варианты привязки 3-байтовой метки:
- в режиме ATM: привязка к идентификатору виртуального канала/идентификатору виртуального пути (Virtual Channel Identifier/Virtual Path Identifier; VCI/VPI) (см. раздел 6);
- в режиме расширения виртуальной локальной сети VLAN (3-байтовый MAC-адрес как ID VLAN для простых случаев неявной привязки с выделенным групповым маркером, например, 0xFFFF) (см. раздел 6).
Сигнализация присутствия в транспортном потоке MPEG потока GSE IP/MAC выполняется дескриптором generic_stream_location_descriptor, определенным в [2] (8.4.5.15), который переносится в таблице уведомления (Network Information Table; NIT) (также см. [2]).
В дескрипторе generic_stream_location_descriptor должны использоваться селекторные байты в IP/MAC для передачи поля generic_stream_binding_info, синтаксис которого представлен в таблице 4.
Таблица 4
Синтаксис поля generic_stream_binding_info
multicast_binding: Флаг устанавливается в "1", если используется IP для отображения адресов MAC в соответствии с [9] для групповых адресов IPv4 и в соответствии с [10] для групповых адресов IPv6. Если флаг устанавливается в "0", то отображение IP-адресов к MAC-адресам для групповых адресов выполняется вне контекста настоящего стандарта.
dvb_rcs_group_logon_id_binding: Флаг устанавливается в "1", если интерактивный терминал должен связать (обработать) groupid/logon_id как 3_byte_label.
atm_pvc_binding: Флаг устанавливается в "1", если идентификатор VPI/VCI будет передаваться в поле 3_byte_label.
vlan_extension_binding: Флаг устанавливается в "1", если vlan_id будет передаваться в поле 3_byte_label.
(справочное)
ФУНКЦИОНИРОВАНИЯ ИНКАПСУЛЯТОРА И ПЛАНИРОВЩИКА
А.1 Правила работы инкапсулятора и планировщика
На рисунке А.1 показана блок-схема инкапсулятора и планировщика, на которой выделены ключевые функции, связанные с процессами инкапсуляции и планирования, выполняющимися в передатчике. Представление этой блок-схемы предназначено для иллюстрации основных функциональных элементов и их взаимосвязей, а не для указаний правил реализации инкапсуляции GSE.
![]() Рисунок А.1 - Блок-схема инкапсулятора и планировщика
Входящие IP или другие пакеты сетевого уровня обрабатываются и направляются в различные буферы в зависимости от их назначения, требований и приоритета QoS. Для случая системы ACM рассматривается и качество канала до терминала назначения. После выполнения такой классификации планировщик выбирает пакеты, подлежащие передаче на основе определенной стратегии планирования, которая в общем случае стремится максимизировать производительность при гарантии достижения индивидуальных целей QoS.
Планировщик в инкапсуляторе GS выполняет рациональное размещение пакетов GSE в кадрах основной полосы, что позволяет оптимизировать эффективность системы. На рисунке А.2 показаны несовмещенные операции инкапсуляции и планирования. PDU1, PDU2 и PDU3 образуют последовательность PDU, предварительно запланированную внешним планировщиком. Термин MODCOD содержит параметры формата модуляции и скорости кодирования, связанные с данным PDU. Предполагается, что производительность MODCOD2 выше, чем MODCOD1, то есть MODCOD1 соответствует случаю более устойчивой (робастной) передачи. PDU инкапсулируются и размещаются в кадрах основной полосы инкапсулятора GSE.
![]() Рисунок А.2 - Несовмещенные операции
инкапсуляции и планирования
Когда PDU фрагментирован с целью оптимального заполнения поля данных кадра основной полосы, как в случае с PDU2 в вышеупомянутом примере, остающийся фрагмент PDU инкапсулируется в независимом пакете GSE, который должен быть передан в одном из следующих кадров основной полосы. Однако если интеллектуальная стратегия планирования не используется, то сгенерированный пакет GSE будет запланирован для кадра основной полосы, вместе с другими предварительно запланированными инкапсулированными PDU. Так как параметры передачи являются постоянными для того же кадра, инкапсулятор должен "понизить" к уровню MODCOD 1 фрагмент следующего PDU, необходимого для заполнения кадра. Это подразумевает ухудшение емкости мгновенного канала по отношению к достижимому значению из-за несогласованности процессов планирования и инкапсуляции. На рисунке А.3 приведены совмещенные операции инкапсуляции и планирования. Показано, как объединенная операция планирования и инкапсуляции может устранить потери эффективности линии и может обеспечить лучшую эффективность системы.
![]() Рисунок А.3 - Совмещенные операции
инкапсуляции и планирования
Настоящий стандарт не устанавливает правила выполнения совмещенных операций инкапсуляции и планирования.
А.2 Использование индикатора типа метки
Индикатор типа метки позволяет инкапсулятору сообщать приемникам формат адреса NPA, который должен использоваться для фильтрации принятых пакетов GSE. Присутствие Индикатора типа метки в каждом пакете GSE в серии пакетов GSE, имеющих один и тот же адрес NPA является избыточным, избыточность устраняется использованием значения LT "11". Инкапсулятор должен использовать значение типа метки "11" только в рамках одного единственного кадра и никогда не использовать для первого пакета кадра GSE. Это правило предотвращает возникновение неоднозначностей в случае потери кадра.
(обязательное)
Приемник настраивается на конкретный общий непрерывный поток с приемным фильтром для приема всех кадров этого потока. Эти кадры собраны для формирования потока пакетов GSE. Единственный приемник может принять несколько общих потоков. В каждом случае сборка должна выполняться независимо для каждого общего потока и для каждого фрагментированного PDU. Для выполнения сборки приемник может использовать буфер для хранения частично собранного PDU. В конкретных реализациях приемника могут использоваться другие структуры данных, но при этом должно обеспечиваться выполнение эквивалентных операций, описанных ниже.
В минимальной комплектации приемник должен содержать один буфер сборки для каждого адреса, с которым он связывается. Механизмы поддержки QoS развитой сети могут использовать различные ID Frag на адрес, чтобы учесть чередование фрагментов PDU по этому адресу. Поэтому для работы в этом виде сетей приемник должен быть в состоянии обработать в общем потоке одновременно до 256 фрагментированных PDU.
Приемник должен начать обработку первого пакета GSE, который начинается непосредственно после основного заголовка кадра основной полосы, и затем продолжать обработку всех последующих пакетов GSE. Приемник может определить начало следующего пакета GSE, вычисляя длину текущего пакета GSE по значению поля длина GSE в заголовке GSE.
Примечание - Кадр основной полосы может содержать более одного пакета GSE.
Б.1 Фильтрация
Приемник должен фильтровать пакеты GSE для конкретных режимов маркировки (например, 3-байтовые или 6-байтовые метки). Если бит S в заголовке GSE установлен в "1", то приемник должен интерпретировать биты метки. Если заголовок GSE содержит 6 байтов или 3 байта, то метка соответствует любому фильтру, и приемник продолжает обработку пакета. В противном случае приемник должен отбросить пакет GSE и продолжать обработку следующего пакета GSE. Если биты LT установлены в "10" (метка не существует), то приемник должен обрабатывать пакет независимо от любых фильтров. Если поле LT установлено в "11" (режим повторного использования метки), то приемник должен проверить, был ли предыдущий пакет GSE в кадре предназначен для приемника. Если это так, приемник обрабатывает пакет, в противном случае приемник должен отбросить пакет GSE. Использование величины LT "11" после предыдущей величина LT "10" (отсутствие метки) недопустимо.
Если оба бита S и E установлены в "1", то пакет GSE содержит единственный PDU. Приемник считывает поле длина GSE и может обработать пакет в соответствии с Б.3 настоящего приложения, в противном случае пакет GSE должен пройти процесс сборки в соответствии с Б.2 настоящего приложения.
Б.2 Процесс сборки
Если бит S установлен на "1", а бит E установлен на "0", то пакет GSE содержит первый фрагмент PDU с данным Frag ID. Перед входом в процессе сборки для этого ID Frag приемник должен выполнить операции:
- проверить факт использования идентификатора, что означает наличие в буфере перекомпоновки приемника фрагментов с этим ID Frag. Если идентификатор ID Frag уже используется, то приемник должен сначала отбросить сохраненные ранее в буфере фрагменты, соответствующие этому ID Frag;
- инициализировать процесс сборки для данного ID Frag и начать сборку нового PDU. Необходимое пространство буфера представлено в поле Общей Длины.
Когда бит S установлен на "0", то пакет GSE содержит продолжение или окончание фрагмента. Если буфер приемника находится в состоянии сборки для ID Frag, соответствующего ID Frag в Заголовке GSE, то он продолжает обработку. В противном случае пакет GSE должен быть отброшен.
Если биты S и E установлены на "0", то пакет GSE содержит продолжение фрагмента PDU с ID Frag, соответствующему ID Frag в заголовке GSE. Он должен быть добавлен к фрагменту в буфер сборки. Приемник может проверить размер фрагмента, чтобы общая собранная длина не превышала размер общей длины (если размер общей длины превышен, то приемник должен отбрасывать в буфере фрагменты, соответствующие этим ID Frag и прервать сборку).
Если бит S установлен на "0", а бит E установлен на "1", то пакет GSE содержит последний фрагмент PDU с ID Frag, заданной в заголовке GSE. Приемник должен добавить фрагмент к сборке в буфер для этого ID Frag. Приемник должен проверить, соответствует ли количество принятых байтов, в том числе длину нефрагментированной PDU, поля тип протокола, поля тип метки (при наличии), а также любого продления этого заголовка, общему значению длины поля в первом пакете GSE для этого PDU. Если длина собранного PDU и дополнительных вышеперечисленных полей не соответствуют общему значению длины поля, приемник должен отбрасывать PDU. Наконец, приемник сравнивает CRC (последние 4 байта текущего пакета GSE) с текущим CRC в буфере PDU. Если CRC не совпадают, то приемник должен отбросить текущий буфер PDU. Эта ошибка должна учитываться как ошибка PDU CRC. Если CRC сопоставимы, то это означает, что инкапсулированный PDU принят правильно и PDU должны быть обработаны (см. Б.3). После этого приемник освобождает этот ID Frag, чтобы обеспечить его повторное использование для следующих блоков PDU.
Если PDU, принадлежащий данному ID Frag, не может быть собран на интервале 255 последовательных кадров, то приемник должен его отбросить из буфера и освободить ID Frag. Эта ошибка должна учитываться как ошибка тайм-аута сборки PDU.
После приема достоверного и полного PDU приемник начинает проверку типа поля. Ряд типов заголовков описаны в [5], другие типы могут быть указаны в будущем реестре заголовков. Значения типа поля (не превышающие 256) указаны в обязательных расширениях заголовка. Приемник должен выполнять обработку для указанного значения типа поля. Заголовки, расширяемые в будущем, могут следовать за этим расширением заголовка. Все нереализованные значения принятых данных должны отбрасываться и обработка должна продолжаться со следующего пакета GSE. Это событие ошибки должно быть записано как ошибка расширения заголовка PDU.
Значения типа поля в интервале значений от 256 до 1535 соответствуют опциональному расширению заголовка. Если расширение типа реализовано, то приемник выполняет обработку поля указанного значения типа. В противном случае он удаляет поле заголовка и обрабатывает следующее значение типа. За этим заголовком расширения могут следовать заголовки будущих расширений.
После этого полезная нагрузка PDU передается на следующий уровень протокола. PDU со значением поля типа, превышающим 1536 (которое не поддерживается приемником), может быть отброшено. Это событие ошибки должно быть записано как ошибка типа PDU.
Б.4 Метки повторного использования
Если первый пакет GSE в кадре основной полосы имеет индикатор типа метки, установленный на "11", то приемник должен отбросить пакет GSE и обрабатывать следующие пакеты GSE, пока он не обнаруживает пакет GSE, значение индикатора типа метки которого не равно "11"
Б.5 Дополнение
Прием заголовка GSE, в котором индикатор начала и индикатор конца установлены в "0" и индикатор тип метки установлен в "00", означает, что дополнение обнаружено, и приемник не может отбросить все следующие байты до конца кадра основной полосы.
(справочное)
![]() Рисунок В.1 - Пакет GSE, переносящий полный
нефрагментированный PDU с 6-байтовым адресом NPA
![]() нефрагментированный PDU с 3-байтовым адресом NPA
![]() начало, продолжение и окончание PDU
![]() и распределение в кадре основной полосы
![]()
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/35/gost_36245.html
На правах рекламы:
|