ОБЕСПЕЧЕНИЕ АДАПТАЦИИ К ИЗМЕНЕНИЯМ, ПРОИСХОДЯЩИМ В ХОДЕ ЭКСПЛУАТАЦИИ ДЛЯ СЕТЕЙ РЕАЛЬНОГО ВРЕМЕНИ НА БАЗЕ СТАНДАРТА SPACEFIBRE

АННОТАЦИЯ

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

В статье предлагаются профили стандарта, позволяющие устранить эти ограничения. Для реализации этих профилей предлагается переход от использования кодирования 8b/10b к 64b/66b. Использование этого кодирования делает возможным добавление новых команд, необходимых для реализации функций, обеспечивающих адаптивность. Также использование этого кодирования позволяет увеличить полезную пропускную способность физических каналов.

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

ABSTRACT

Most computing systems with real-time requirements can change quite significantly during their operation – adapt to changes in the tasks being solved, faults, and the addition of new nodes and subsystems. The SpaceFibre standard was developed for real-time networks. It has various mechanisms that ensure guaranteed delivery, guaranteed delivery time of data for various data streams. Isolation of data streams is ensured - the exclusion of mutual interference of flows (streams) when they share network resources in conditions of an unchanged network configuration. But in the basic version of the SpaceFibre standard, there are limitations that do not allow dynamic network management to ensure adaptation. During the redistribution of network resources between data flows (streams) and during the restoration of individual virtual networks after locks, errors, regular data transmission over virtual networks sharing physical resources with those for which configuration changes are performed is not possible. The article offers profiles of the standard to eliminate these limitations. To implement these profiles, it is proposed to switch from using 8b/10b encoding to 64b/66b. Using this encoding makes it possible to add new commands necessary for the implementation of functions that ensure adaptability. Also, the use of this encoding allows us to increase the useful bandwidth of physical channels. Verification of the proposed functioning profiles correctness was performed using a mathematical apparatus of timed automata. An evaluation of achievable characteristics was performed for the proposed profiles.

Ключевые слова: SpaceFibre, динамическое управление потоками данных, динамическое управление ресурсами сети, парирование сбоев и отказов, динамическая реконфигурация, кодирование 8b/10b, кодирование 64b/66b, динамически реконфигурируемые автоматы, временные автоматы.

Keywords: SpaceFibre, dynamic data flow management, dynamic network resource management, fault mitigation, dynamic reconfiguration, 8b/10b encoding, 64b/66b encoding, dynamically reconfigurable automata, timed automata.

Введение

Стандарт SpaceFibre был разработан для использования в сетях аэрокосмического назначения [1]. Данный стандарт ориентирован на обеспечение характеристик передачи потоков данных, необходимых для этого класса сетей. В частности, для отдельных потоков данных могут быть определены уровни приоритета, выделена доля физической пропускной способности канала, определены таймслоты, в которые разрешена передача для обеспечения гарантированного времени доставки, механизмы гарантированной доставки данных в условиях сбоев в физических каналах передачи данных. Благодаря этим механизмам стандарт SpaceFibre может использоваться для формирования систем реального времени.

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

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

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

Для обеспечения адаптации к изменениям, происходящим в ходе эксплуатации требуется реализовать новые механизмы, новые алгоритмы функционирования. Для их реализации необходимо добавление новых команд, используемых на уровне звена передачи данных. Но существующий набор команд уже не может быть расширен без удвоения их длины. При использовании кодирования 8b/10b длина слов данных составляет 4 байта, соответственно, длина всех передаваемых объектов данных должна быть кратной длине слова, должна быть выровнена по длине слова. Это приводит не только к снижению полезной пропускной способности, но и к ощутимому усложнению аппаратной реализации звена передачи данных.

В этой статье предлагается подход, позволяющий обеспечить адаптацию к изменениям, происходящим в ходе эксплуатации систем реального времени – новые профили стандарта SpaceFibre, в которых реализованы механизмы динамического перераспределения буферного пространства между потоками данных, сброса отдельных виртуальных сетей без нарушения штатной передачи остальных потоков данных. Для реализации предлагаемого подхода необходим переход к применению в профилях кодирования 64b/66b. Данное кодирование используется во многих современных стандартах, в частности, Infiniband, Serial RIO, Gigabit Ethernet и др. [2, 3, 4, 5, 6].

Данное кодирование обеспечивает более гибкие схемы размещения объектов данных в словах. Это позволяет увеличить длину команд на необходимое количество байтов. При этом аппаратные затраты на реализацию существенно не изменяются. Кроме того, использование этого кодирования позволяет сократить накладные расходы на передачу служебных битов по сравнению с 8b/10b с 20% до 3%.

Особенности передачи данных в базовой версии стандарта SpaceFibre

Звено передачи данных в соответствии со стандартом SpaceFibre включает в себя физический уровень, уровень Линии (Encoding-Lane), уровень повторных передач (Retry) и уровень виртуальных каналов (Virtual channels). Также в стандарте SpaceFibre специфицирован сетевой уровень. Стандарт организован таким образом, что на транспортном уровне могут использоваться различные протоколы передачи данных [1].

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

В стандарте SpaceFibre используется последовательная передача данных (что необходимо для обеспечения высокой скорости передачи данных на достаточно большие расстояния). В этом случае механизмы восстановления последовательности передаваемых объектов данных, основаны на используемом кодировании. Для обеспечения взаимодействия между соседними абонентами (абонентами, непосредственно связанными физической линией связи) между их передатчиками и приемниками должна быть установлена битовая и символьная синхронизация. Канал SpaceFibre является двунаправленным, действия по синхронизации выполняются в каждом из направлений. При использовании 8b/10b длина слов составляет 32 бита (40 битов после кодирования). Слово состоит из 4-х символов. Символы разделяются на символы данных (D) и управляющие (K). Слово может включать в себя символы управления и символы данных или только символы данных. Для установки синхронизации используется один из управляющих символов – символ COMMA (K28.5). Данный символ был выбран, поскольку последовательность нулей и единиц в нем удобна для реализации блоков приема, определения границ битов и символов. Для того, чтобы установить соединение передатчики соседних узлов передают последовательности из слов, начинающихся с K28.5 (слова INIT1, INIT2, INIT3). Слова INIT1 используются для того, чтобы приемная сторона могла установить битовую и словную синхронизацию. Слова INIT2 используются для того, чтобы уведомить противоположную сторону о том, что синхронизация установлена. Слова INIT3 используются для того, чтобы сообщить противоположной стороне информацию о характеристиках данной стороны, о режиме установки соединения (в частности, о том, необходимо ли выполнять сброс верхних уровней звена передачи данных в процессе установки соединения) [1]. Более подробно модели взаимодействия устройств в процессе установки соединения рассмотрены в [7]. После того, как соединение установлено, может осуществляться передача объектов данных от прикладного уровня. Если в дальнейшем в ходе передачи возникает большое количество ошибок (помехи в канале передачи или другие физические процессы могут приводить к потере синхронизации), то соединение может быть переустановлено (выполнена повторная установка соединения).

Требуемые прикладным уровнем характеристики передачи потоков данных обеспечиваются уровнем повторных передач, уровнем виртуальных каналов и сетевым уровнем. Для этого используется механизм виртуальных сетей. Для каждой виртуальной сети может быть задан набор параметров (уровень приоритета, доля пропускной способности физических каналов передачи, перечень таймслотов, в которые разрешена передача данных). Виртуальная сеть может использоваться для передачи одного или нескольких потоков данных, для которых должен быть обеспечен соответствующий заданным параметрам набор характеристик передачи. Количество виртуальных сетей в системе ограничено 64-мя. Каждая виртуальная сеть включает в себя некоторое количество виртуальных каналов в звеньях передачи данных, входящих в пути передачи потоков данных, для которых используется эта сеть. Каждое звено передачи данных включает в себя до 32 виртуальных каналов. Каждый виртуальный канал может принадлежать только одной виртуальной сети. В каждом звене передачи данных одной виртуальной сети может принадлежать только один виртуальный канал. Физические ресурсы звена передачи данных и физического канала передачи данных распределяются между передаваемыми потоками данных в соответствии с параметрами, заданными для виртуальных сетей.

Причины, из-за которых в стандарте SpaceFibre не возможно динамическое перераспределение ресурсов сетевых узлов

Передача данных между соседними абонентами в звене передачи данных осуществляется пофреймово. Максимальный размер поля данных фрейма – 64 слова (256 байтов). Еще два слова используется для передачи заголовка и концевика фрейма, содержащих служебную информацию. Использование физического канала различными виртуальными каналами осуществляется в режиме разделения времени – фреймы разных виртуальных каналов передаются по очередности, определяемой заданным для них набором параметров. В соответствии с базовой версией стандарта SpaceFibre данные параметры могут меняться динамически, без останова передачи данных. Но в стандарте не предусмотрено механизмов для динамического управления этими параметрами в соответствии с локальными изменениями потоков данных.

Для промежуточного хранения фреймов на передающей и приемной стороне используется буферная память, размер которой кратен максимальному размеру фрейма. Для того, чтобы исключить потерю данных на приемной стороне из-за переполнения буфера, используется механизм кредитования от приемника. При этом один символ кредитования соответствует 256 байтам данных – фрейму максимального размера. В соответствии с этим, минимальный размер буфера для каждого виртуального канала на приемной и передающей стороне равен 256 байтам. И, если на приемной стороне размер буфера меньше 768 байтов (трех фреймов), то полезная пропускная способность для виртуального канала существенно снижается из-за ожидания символов кредитования. Показано в [8, 9], что если размер приемного буфера равен одному фрейму, то полезная пропускная способность снижается в два раза. Вследствие этого, для передачи потоков данных, включающих объекты данных небольшого размера, для сокращения используемого буферного пространства целесообразно иметь возможность управлять количеством кредитов соответствующих одному символу кредитования (уменьшать количество кредитов) для разных виртуальных каналов.

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

Причины, из-за которых в стандарте SpaceFibre не возможно восстановление корректного функционирования одной виртуальной сети без нарушения штатной работы других виртуальных сетей

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

Для того, чтобы восстановить корректную работу виртуальной сети после блокировки, необходимо выполнить сброс виртуальных каналов, входящих в состав этой сети (всех или выборочно). Но в базовой версии стандарта SpaceFibre отсутствует возможность сброса отдельных виртуальных каналов, можно сбросить только все звено передачи данных. В результате на время восстановления после сброса штатная передача данных по всем виртуальным каналам (по всем виртуальным сетям), проходящим через это звено передачи данных будет остановлена. Время восстановления возможности передачи данных после сброса Tl в соответствии со стандартом составляет не менее 50 мкс. В течении этого времени во всех виртуальные сетях, проходящих через это звено передачи данных будут накапливаться очереди не переданных пакетов данных. Вследствие этого штатная передача данных будет восстановлена только после того, как эти пакеты, накопленные в этих очередях будут полностью переданы. До этого будут наблюдаться задержки передачи данных, приводящие к несоблюдению требований по времени доставки данных. Это время для каждой виртуальной сети (i), Tri, будет зависеть не только от Tl, но и от соотношения фактически используемой пропускной способности (Rui) и полезной пропускной способности (Ru).Оно может быть оценено по формуле (1):

                                                                      (1)

На рисунке 1 представлены графики зависимости времени восстановления штатного функционирования виртуальных сетей при различных значениях нагрузки.

Рисунок 1. Графики зависимости времени восстановления штатного функционирования виртуальной сети i от нагрузки сети

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

Оценка накладных расходов, полезной пропускной способности при использовании 8b/10b

Обозначим Ca – количество битов в слове, которые добавляются при кодировании, Cm – исходное количество битов в слове. Тогда полезная пропускная способность на уровне кодирования:

                                                                            (2)

Обозначим (максимальную) длину поля данных фрейма Lfm, длину заголовка фрейма – Lfh, длину символа кредитования Lff и длину символа подтверждения - Lfa. Если передача потока данных по каналу осуществляется только в одну сторону, передача символов кредитования, подтверждения осуществляется только в противоположном направлении. Если передача данных идет в обе стороны, то поток данных мультиплексируется с потоком символов кредитования и подтверждения. Можно говорить, что одному фрейму соответствует один символ кредитования и один символ подтверждения. В соответствии с этим полезная пропускная способность на уровне виртуальных каналов может быть оценена по формуле (3) при использовании однонаправленной передачи и по формуле (4) при использовании двунаправленной передачи. (Эти формулы соответствуют ситуации, когда приемный буфер виртуальных каналов достаточно велик, чтобы на передающей стороне не было простоев из-за ожидания кредитования.)

                                                                  (3)

                                                   (4)

Замена кодирования 8b/10b на кодирование 64b/66b

В данном разделе рассмотрен предлагаемый профиль реализации стандарта SpaceFibre, в котором кодирование 8b/10b заменено на 64b/66b без каких-либо дополнений базовой функциональности.

При использовании кодирования 64b/66b длина одного слова составляет 64 бита и 66 битов после кодирования. В начало последовательности из 64-х битов добавляется синхронизирующая последовательность, состоящая из двух битов. Она может принимать значения “01” или “10”. Переход 0->1 или 1->0 используется на приемной стороне для распознавания границ слов (применяется в сочетании со скремблированием остальной части слова). Синхронизирующие последовательности “00” и “11” соответственно, считаются не корректными. Для скремблирования используется полином X58+X39+1. Скремблер является самосинхронизирующимся. Соответственно, при использовании этого кодирования синхронизация приемника осуществляется по любой корректной последовательности слов.

Использование синхронизирующей последовательности “01” указывает, что следующее за ней слово содержит 8 байтов данных. Использование синхронизирующей последовательности “10” указывает, что слово содержит символы управления. Такое слово может содержать и байты данных. Интерпретация слова осуществляется в соответствии со значением, указанным в первом байте этого слова. (Данное поле слова называется TYPE.) В IEEE 802.3ae определено 11 возможных вариантов кодировки. В других стандартах, IP-блоках (например, Xilinx Aurora) используются другие варианты кодировки поля TYPE, интерпретации следующих 56 разрядов слова. Это обеспечивает большую гибкость, адаптивность кодирования в соответствии с размерами объектов, используемых для передачи данных, управляющей информации (команд), минимальные потери пропускной способности канала из-за неиспользуемых разрядов слова.

Для профиля стандарта SpaceFibre предлагается использовать набор кодировок поля TYPE, отличный от используемых в 802.3ae и в Xilinx Aurora. В предлагаемом варианте для установки соединения используется слово INIT3 (TYPE=INIT3), последующие 56 битов позволяют передавать необходимые параметры. (Более подробно предлагаемый процесс установки соединения представлен в [7].) Чтобы определить кодирование остальных управляющих слов, было определено количество полезной информации, передаваемой в каждом из слов при использовании базовой версии SpaceFibre. Для слов ACK/NACK, используемых для передачи информации об успешном, не успешном принятии фреймов это 2 байта, Для команд кредитования – 3 байта, для заголовка, концевика фреймов данных – это 4 байта, для заголовка, концевика Broadcast–это 5 байтов.

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

Для фреймов данных:

• начало фрейма:TYPE=SDF, VC(1 байт), 6 байтов фрейма данных/концевика;
• конец фрейма: TYPE=EDF, количество действительных байтов (1 байт), 6 байтов фрейма данных/концевика/пустых символов.

Концевик включает в себя 3 байта: порядковый номер, и CRC.

Для фреймов Broadcast:

• начало фрейма: TYPE=SBF, BC,BTYPE, 5 байтов поля данных;
• конец фрейма: TYPE=EBF, 3 байта поля данных, 3 байта концевика (Status, порядковый номер, CRC).

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

Для фреймов ACK: TYPE=ACKD|ACKI (передача с последующими символами данных/пустыми символами), порядковый номер фрейма, для которого высылается подтверждение (1 байт), CRC (1 байт), 5 байтов данных или 5 пустых символов.

Для фреймов NACK: TYPE=NACKD|NACKI (передача с последующими символами данных/пустыми символами), порядковый номер фрейма, для которого высылается подтверждение (1 байт), CRC (1 байт), 5 байтов данных или 5 пустых символов.

Для фреймов FCT: TYPE=FCTD|FCTI (передача с последующими символами данных/пустыми символами), флаг размера/умножитель/идентификатор виртуального канала (1 байт), порядковый номер фрейма, CRC (1 байт), 4 байта данных или 4 пустых символа.

На рисунке 2 представлены графики зависимости полезной пропускной способности канала от длины фрейма при использовании кодирования 8b/10b и 64b/66b. Данные графики получены на основе теоретических расчетов с использованием формул (1) – (3). Также для оценки характеристик было проведено моделирование с использованием rtl моделей обоих вариантов реализаций. (Данные модели являются потактово точными моделями реальных устройств, производимых на основе этих моделей.) Разница в полученных оценках не превысила 3%.

Рисунок 2. Графики зависимости полезной пропускной способности канала от длины фрейма

Как можно видеть из этих графиков, использование кодирования 64b/66b позволяет заметно увеличить полезную пропускную способность.

Профили стандарта SpaceFibre, обеспечивающие адаптацию к изменениям в ходе эксплуатации

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

Такое изменение длины команд влечет за собой довольно существенные накладные расходы при реализации оборудования, выполняющего первичную обработку этих команд. Эти накладные расходы оказываются сравнимыми с «полезными» накладными расходами, связанными с собственно добавлением новых режимов функционирования. Также это влечет и определенное снижение полезной пропускной способности. (Максимально достижимая полезная пропускная способность снижается с 75% до 72%.)

Рассмотрим реализацию этих возможностей при использовании кодирования 64b/66b. Для кодирования дополнительных команд, параметров, нам понадобится использовать один дополнительный байт (а не четыре, как при использовании 8b/10b). Вследствие этого полезная пропускная способность уменьшится не значительно, в пределах 1%.

Перераспределение ресурсов буферного пространства. В базовой версии стандарта SpaceFibre приемная сторона отправляет кредиты сразу же при освобождении буферного пространства. При этом приемная сторона в общем случае не располагает информацией о том, есть ли в данном виртуальном канале данные для передачи. (Управление осуществляется не той стороной, на которой наблюдаемы возникающие изменения характеристик трафика.) В результате перераспределение этого буферного пространства другому виртуальному каналу, в котором в данный момент есть данные для передачи, оказывается не возможным. Это делает не возможным динамическую адаптацию к локальным изменениям интенсивностей отдельных потоков данных. Для устранения этой проблемы (противоречия между управляемостью и наблюдаемостью) в ряде стандартов, в частности, в стандарте CXS[10], передающая сторона имеет возможность вернуть кредиты приемной стороне. Аналогичный механизм может быть реализована и в стандарте SpaceFibe.

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

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

Формат предлагаемой команды FCT_RET: TYPE=FCT_RETD|FCT_RETI (передача с последующими символами данных/пустыми символами), идентификатор виртуального канала, который возвращает кредиты/идентификатор виртуального канала, которому возвращают кредиты/количество возвращаемых кредитов (1 байт), порядковый номер фрейма (1 байт), CRC (1 байт), 4 байта данных или 4 пустых символа.

Использование данного механизма позволяет в 2 – 3 раза сократить количество буферного пространства на приемной стороне без потерь полезной пропускной способности.

Изменение максимального размера фрейма, кредита. Изменение максимального размера фрейма, кредита вызывается причинами, сходными с перераспределением буферного пространства. Также, как и в предыдущем случае, изменение характеристик потока данных, вследствие которого целесообразно изменить максимальный размер фрейма, кредита, наблюдаемы на передающей стороне. Действия по изменению максимального размера фрейма выполняются на передающей стороне, какое-либо участие приемной стороны не требуется. Действия по изменению размера кредита должны выполняться на приемной стороне. Соответственно, передающая сторона должна отправить приемной стороне команду изменения размера кредита. Для того, чтобы передающая сторона могла идентифицировать соответствует ли очередной FCT новому или прежнему количеству кредитов, в его формате используется специальный флаг. Значение этого флага инвертируется приемником каждый раз при получении команды изменения размера кредита.

Формат предлагаемой команды FCT_CHG: TYPE=FCT_CHGD|FCT_CHGI (передача с последующими символами данных/пустыми символами), идентификатор виртуального канала/код, соответствующий новому количеству кредитов (1 байт), порядковый номер фрейма (1 байт), CRC (1 байт), 4 байта данных или 4 пустых символа.

Сброс отдельного виртуального канала. В текущей версии стандарта SpaceFibre нет возможности выполнить сброс для отдельного виртуального канала. Данный сброс может понадобиться, если в результате сбоев в одном из виртуальных каналов возникла блокировка и дальнейшая передача данных стала не возможна. (Например, к этому могут приводить сбои, вследствие которых искажаются значения счетчиков кредитования, счетчиков принятых, отправленных слов. Так же сброс требуется в случае возникновения ошибок типа DataOveflow.) Как было показано в предыдущем разделе, в текущей версии сброс может быть выполнен только для всего звена передачи данных. Это приводит к потерям данных и нарушениям требований по времени доставки данных.

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

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

При использовании данного механизма для всех виртуальных сетей, кроме той, для которой выполняется сброс, Tr=0 (их штатное функционирование не будет нарушено). Для сети, для которой выполняется сброс, время восстановления Trmi может быть определено по формуле (5):

                                                                               (5)

Таким образом, для этой сети время восстановления снижается на 15%

В качестве математического аппарата для верификации механизмов нами были выбраны временные автоматы [11, 12, 13, 14, 15]. Для верификации взаимодействия между передающей стороной были разработаны временные автоматы, представленные на рисунке 3.

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

Были сформулированы следующие условия, показывающие, что приемная и передающая сторона находятся в корректном состоянии:

                         (6)

                          (7)

Где t – текущее время,

Dt–максимально допустимое время передачи одного слова в звене передачи данных

TX_FCT_counter – счетчик кредитования на передающей стороне,

RX_FCT_counter – счетчик кредитования на приемной стороне,

TX_data_counter – счетчик данных, переданных передающей стороной,

RX_data_counter – счетчик данных, принятых на приемной стороне.

В ходе верификации сети временных автоматов, представленной на рисунке 2, было определено, что система может перейти в недопустимое состояние:

Arx(reset) → Arx(work)                                                                   (8)

Atx(reset)

В результате будет нарушено условие (6).

Недопустимых состояний, при которых нарушается условие (7) не было.

Рассмотрено недопустимое состояние, в которое перешла система. Время, необходимое для выполнения действий по сбросу на приемной и передающей стороне может быть различным. Сторона RX перешла в локацию Work, в то время, как TX сторона еще находится в локации Reset. В локации Work сторона RX отправила кредитование передающей стороне, которое было утрачено.

Для того, чтобы устранить эту проблему, была изменена схема сброса. После того, как одна из сторон посылает команду сброса, и того, как сброс выполнен на TX стороне, она отправляет подтверждение выполнения сброса. Только получив его, приемная сторона переходит к штатной работе. Модифицированный вариант временных автоматов представлен на рисунке 4.

Рисунок 4. временные автоматы для верификации сброса виртуального канала, второй вариант реализации

Для данной схемы сброса система не может перейти в некорректное состояние. Для реализации схемы сброса добавлена дополнительная команда RST: TYPE=RSTD|RCTI (передача с последующими символами данных/пустыми символами), идентификатор типа (resetили reset_ack)/идентификатор виртуального канала (1 байт), порядковый номер фрейма, CRC (1 байт), 4 байта данных или 4 пустых символа.

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

Заключение

В статье предложены механизмы, позволяющие обеспечить адаптацию к изменениям, происходящим в ходе эксплуатации сетей реального времени на базе стандарта SpaceFibre. Данные механизмы реализованы в форме дополнительных профилей стандарта. Они обеспечивают адаптацию звена передачи данных (использования в нем ресурсов буферного пространства) к локальным изменениям характеристик потоков данных за счет реализации новых механизмов управления сетью. Их использование позволяет перераспределять буферное пространство без сброса звена передачи данных, использовать в 2 – 3 раза меньший объем буферного пространства по сравнению с базовой реализацией без снижения полезной пропускной способности. Появляется возможность использовать для передачи фреймы с полем данных меньшего размера с существенно меньшими накладными расходами. Так полезная пропускная способность при размере фреймов 16 байтов и кодировании 64b/66b такая же, как при размере фреймов 32 байта и кодировании 8b/10b. Это позволяет существенно сокращать буферное пространство для потоков, в которых объекты данных имеют не большой размер.

Предлагаемые механизмы позволяют обеспечить полную изоляцию виртуальных каналов – возможность сброса отдельных виртуальных каналов (виртуальных сетей) с сохранением штатной передачи данных в других виртуальных каналах. Для них время восстановления штатной передачи становится равной нулю, при том что в базовой версии стандарта оно составляло сотни мкс. Время восстановления штатной передачи данных в виртуальной сети, для которой выполняется сброс, сокращается на 15%. Для реализации этих профилей был расширен набор команд, что стало возможным за счет перехода от использования кодирования 8b/10b к 64b/66b. Использование этого кодирования позволило также почти на 20% увеличить полезную пропускную способность физических каналов.

Благодарности

Работа выполнена при финансовой поддержке Министерства науки и высшего образования Российской Федерации, соглашение № FSRF-2023-0003, "Фундаментальные основы построения помехозащищенных систем космической и спутниковой связи, относительной навигации, технического зрения и аэрокосмического мониторинга".

Список литературы:

1. SpaceFibre – Very high-speed serial link. ECSS-E-ST-50-11C. – ESA-ESTEC, 2019. – 233 с.
2. Infiniband Specification. – Infiniband trade association, 2022. – 1045 с.
3. RapidIO Interconnect Specification Part 1: Input/Output Logical Specification 4.1. – RapidIO trade association, 2017. – 1521 с.
4. IEEE 802.3-2022. – IEEE trade association, 2022. – 568 с.
5. Singh J., Mohapatra S. Mohapatra N. R. Performance Optimized 64b/66b Line Encoding Technique for High Speed SERDES Devices // International Symposium on VLSI Design and Test. – 2017. – С. 56 – 61.
6. Wang X., Su L., Du X., Chen Y., Wu J., Physical Coding Sublayer For 32Gbps SerDes Based On JESD204C // IEEE 14th International Conference on ASIC (ASICON). – 2021. – C. 1 – 4.
7. Суворова Е. А., Поляков В. Б. Поддержка кодирования 64b|66b на уровне Lane стандарта SpaceFibre // LXXXVI международная научно-практическая конференция «Технические науки: проблемы и решения». – 2024. – 13 с.
8. Суворова Е. А. Оценка минимального времени доставки пакетов в виртуальных сетях SpaceFibre // сборник докладов Научной сессии ГУАП, посвященной Всемирному дню авиации и космонавтики. – 2020. – 26 с.
9. Suvorova E. An Approach for Estimation of Packet Delivery Time on SpaceFibre Networks // Wave Electronics and its Application in Information and Telecommunication Systems (WECONF). – 2020. – 10 с.
10. AMBA CXS Protocol Specification. – Arm Limited or its affiliates, 2020. – 54 c.
11. Alur R., Dill D. A theory of timed automata // Theor. Comp. Science. – 1994. – C. 183 – 235.
12. Карпов Ю.Г. MODELCHECKING. Верификация параллельных и распределенных программных систем. – BHV: Санкт-Петербург, 2010. – 560 с.
13. AlrahmanY., Azzopardi S., Piterman, N., Margaria T., Steffen, B. Model Checking Reconfigurable Interacting Systems // Leveraging Applications of Formal Methods, Verification and Validation. Adaptation and Learning: 11th International Symposium. – 2022. – C. 59 – 72.
14. Govind R., Herbreteau F., Srivathsan B., Walukiewicz I. Abstractions for the local-time semantics of timed automata: a foundation for partial-order methods // 37th Annual ACM/IEEE Symposium on Logic in Computer Science. – 2022. – C. 1 – 22.
15. Jensen, P.G., Kiviriga, A., Larsen K. G., Nyman U., Mijaika, A., Mortensen J. H., Ábrahám E., Paolieri M. Monte Carlo Tree Search for Priced Timed Automata // 19th International Conference on Quantitative Evaluation of Systems. – 2022. – C. 381 – 398.