ГОСТ Р 54708—2011
16
Приложение Б
(обязательное)
Физическое отображение
Фактическая передача PFT (илиAF) пакетов должна быть возможна по многим видам существующих систем
передачи с разной возможной инфраструктурой. Три возможных физических отображения определены в этом при-
ложении, однако этот список не является ни исчерпывающим, ни предписывающим. Новые отображения могут
быть определены в будущем.
Б.1 Пакетные связи
Сети пакетной коммутации становятся все более обычными, и во многих случаях либо PFT фрагменты, либо
AF пакеты могут быть отображены точно в пакеты связи. MTU для уровня связи должен быть соблюден, и PFT
фрагментация или PFT фрагментация Рида-Соломона должны использоваться, чтобы гарантировать, что един-
ственный исходный пакет не будет фрагментирован на канальном уровне связи.
Б.1.1 UDP/IP
UDP/IP — одна из самых популярных сетей пакетной коммутации в настоящее время. PFT фрагменты и
AF пакеты могут быть отображены точно в пакеты UDP /IP, если предусмотреть соблюдение MTU уровня UDP/IP.
PFT фрагментация или PFT фрагментация Рида-Соломона должна использоваться, чтобы гарантировать, что
единственный исходный пакет не будет фрагментирован. Любой определенный IP транспортный интерфейс для
UDP/IP может использоваться, включая (но не ограничивая), 10Base-T Ethernet или РРР (двухточечной) связи.
UDP/IP предоставляет источник и номера портов назначения, следовательно, необходимость использования
дополнительного PFT транспортного заголовка маловероятна, однако его использование не запрещено.
UDP/IP не гарантирует доставку пакетов, следовательно использование заголовка PFT Рида-Соломона на-
стоятельно рекомендуется, но не является обязательным.
Б.2 Потоковые связи
Потоковые коммуникации в этом контексте описывают любой тип не пакетных коммуникаций. Примерами
таких коммуникаций служат асинхронные последовательные каналы связи, синхронные последовательные кана-
лы связи и каналы связи TCP/IP. Отличительная особенность таких каналов состоит в том, что наивысшие уровни
(например, AF или PFT уровень) обязаны устанавливать пакетную синхронизацию прежде, чем пытаться декоди-
ровать поток.
Использование PFT уровня настоятельно рекомендуется, поскольку это было разработано для улучшения
надежности синхронизации по сравнению с необработаннымAF уровнем, однако этот необработанныйAF уровень
может использоваться непосредственно, если требуется.
Для физических каналов, которые не гарантируют безошибочный прием, рекомендуется использование до-
полнительного механизма кода Рида-Соломона с FEC, обеспеченного PFT уровнем. Каналы типа TCP/IP гаранти-
руют обеспечение безошибочной связи, не нуждающейся в использовании защитного кода Рида-Соломона, однако
линии связи, использующие RS-232, могут быть подвержены ошибкам и, следовательно, использование дополне-
ния в виде кода Рида-Соломона с FEC целесообразно.
Б.3 Файл
PFT фрагменты или AF пакеты могут быть сохранены в виде файла для офлайнового распределения, ар-
хивации или любой другой цели. Стандартное отображение было определено путем использования опционально
доступного иерархического TAG элемента, однако в будущем другие отображения могут быть определены, либо
предложено использование его расширения. TAG элемент верхнего уровня имеет TAG название
f
i
o_ и использует-ся
для инкапсуляции TAG пакета, одна часть которого является AF пакетом или PFT фрагментом в TAG элементе afpf.
Были определены дополнительные TAG элементы, чтобы контролировать прием или управлять воспроизве-
дением пакетов.
Б.3.1 Файл IO (
f
i
o_) (рисунок Б.1)
TAG элемент “
f
i
o_” — самый высокий уровень TAG элемента в иерархии файлов TAG элементов.
Этот TAG элемент действует как контейнер для TAG элемента afpf. TAG элемент time (метка времени) может
быть представлен опционально.