DetNet

Детерминированная сеть (DetNet) - это попытка рабочей группы DetNet в IETF создать реализацию детерминированной сети передачи данных для приложений с вычислениями в реальном времени с низкими показателями потери данных, вариацией задержки пакета (джиттером, англ. jitter) и ограниченной задержкой (англ. bounded delay). Примерами приложений, которые требуют подобных характеристик сети являются: потоковая передача необработаного аудио и видео, промышленная автоматизация и управлении транспортными средствами.

DetNet работает на маршрутизируемых сегментах 3-го (сетевого) уровня, используя уровень программно-определяемой сети для интегрирования служб IntServ (интегрированных услуг) и DiffServ (дифференцированных услуг), и поставляет службы через связанные сегменты более низкого канального уровня, используя такие технологии как MPLS и IEEE 802.1 Time-Sensitive Networking.

Технология DetNet стремится перенести высоконадежное производственные сети и аудиовизуальные приложения со специализированных технологий (HDMI, CAN, PROFIBUS, RS-485, RS-422/RS-232, и I²C) в пакетные сети и на базе протокола IP. DetNet поддерживает как новые, так и уже существующие приложения на одной физической сети.

Для поддержки приложений с вычислениями в реальном времени, DetNet применяет резервирование ресурсов на промежуточных узлах по пути потока данных, явные маршруты, не зависящие от топологии сети, а также - репликацию и слияние пакетов для доставки данных даже при потере пути (PREOF - Packet Replication Elmination Ordering Function).

Проблема детерминированной сети

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

Это может приводить к тому что маленькие датаграммы приложений реального времени будут вынуждены ожидать в буфере на промежуточных узлах слишком долго, будучи вытесненными большими потоками вроде передачи файлов по протоколу TCP, что не является допустимым для таких приложений. Из-за работы алгоритмов контроля перегрузки сети на основе потерь, агрессивные TCP-соединения способны переполнять буфер на промежуточных узлах до начала потерь - явление которые называется распуханием буфера (англ. bufferbloat).

Для решения проблемы контроля трафика в сетях IP задействуют техники обеспечения качества обслуживания (англ. QoS). Различные механизмы QoS позволяют достичь допустимых характеристик канала связи для некритичных приложений вроде IP-телефонии и потокового видео. К сожалению данные механизмы не обеспечивают каких либо строгих гарантий вариации задержки на порядках десятых и сотых миллисекунд, что требуется к для критических систем реального времени. По этой причине между система реального времени обычно задействовали различные технологии промышленных сетей (англ. Fieldbus).