Илл. 5.41. Фрагментация при элементарном размере 1 байт. (а) Исходный пакет, содержащий 10 байт данных. (б) Фрагменты после прохождения через сеть с максимальным размером пакета 8 байт плюс заголовок. (в) Фрагменты после прохождения через шлюз размера 5

Илл. 5.42. Поиск путевого значения MTU

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

Недостатком этого метода является то, что отправка пакета может вызвать дополнительную задержку. Эта задержка может увеличиться в несколько раз в зависимости от того, сколько раз отправителю придется повторять отправку (меняя размер пакета), прежде чем какие-либо данные достигнут адресата. Возникает вопрос: существуют ли более эффективные схемы? Вероятно, да. Рассмотрим, к примеру, вариант, при котором слишком большие пакеты просто обрезаются. В таком случае адресат узнает путевое значение MTU максимально быстро (по размеру доставленного пакета), а также получает некоторую часть данных.

5.6. Программно-конфигурируемые сети

Процесс управления трафиком всегда был очень непростым: он требует от операторов сетей настройки параметров конфигурации протоколов маршрутизации, которые затем производят перерасчет путей. Трафик идет по новым маршрутам, что ведет к перераспределению нагрузки. К сожалению, механизмы управления трафиком носят косвенный характер: изменение конфигурации протоколов меняет маршрутизацию и в отдельных сетях, и между ними. При этом протоколы часто ведут себя непредсказуемо. Эти проблемы во многом решаются с помощью программно-конфигурируемых сетей (Software-Defined Networking, SDN), которые мы обсудим далее.

5.6.1. Общие сведения

По сути, компьютерные сети всегда были «программно-конфигурируемыми», поскольку в маршрутизаторах используется конфигурируемое программное обеспечение, извлекающее информацию из пакетов и принимающее решения об их передаче. В то же время та часть ПО, которая запускает алгоритмы маршрутизации и реализует остальную логику передачи пакетов, всегда была вертикально интегрированной в сетевое оборудование. Купив маршрутизатор Cisco или Juniper, оператор сети был вынужден работать с программными технологиями, которые внедрил поставщик оборудования. Например, изменить какие-либо параметры протокола OSPF или BGP было просто невозможно. Главной причиной разработки SDN стало понимание, что плоскость управления (control plane) (логика выбора маршрутов и принятия решений о передаче) работает на программном уровне и может выполняться абсолютно независимо от плоскости данных (data plane) (аппаратных технологий, которые непосредственно извлекают информацию из пакетов и решают, что с ними делать). Эти плоскости показаны на илл. 5.43.

Если структурно разделить плоскость управления и плоскость данных, то логично предположить, что плоскость управления совсем необязательно запускать на сетевом оборудовании. На самом деле одна из популярных спецификаций SDN подразумевает наличие логически централизованной программы, зачастую написанной на языке высокого уровня (например, Python, Java, Golang, C). Эта программа принимает логические решения о пересылке и уведомляет о них все участвующие устройства. В качестве канала связи между высокоуровневой программой и нижележащим аппаратным обеспечением можно использовать любой механизм, поддерживаемый сетевым устройством. Один из первых SDN-контроллеров использовал в качестве плоскости управления протокол BGP (Фимстер и др.; Feamster et al., 2003). Позднее появились технологии OpenFlow, NETCONF и YANG, которые предложили более гибкие способы передачи информации плоскости управления сетевым устройствам. В некотором смысле технология SDN стала реинкарнацией давно известной архитектурной концепции централизованного управления, появлению которой способствовало наличие уже устоявшихся вспомогательных технологий (свободно распространяемых API для чипсетов, программного управления распределенными системами).

Илл. 5.43. Разделение плоскости управления и плоскости данных в программно-конфигурируемых сетях

Хотя технология SDN активно развивается в течение многих лет, основной принцип разделения плоскости данных и плоскости управления остается неизменным. Вы можете подробно ознакомиться с историей появления этой набирающей популярность технологии в работе Фимстера и др. (Feamster et al., 2013). Далее мы рассмотрим несколько основных направлений развития SDN. Это контроль переадресации и маршрутизации (технологии плоскости управления); программируемое оборудование и настраиваемая переадресация (технологии, делающие плоскость данных более программируемой); и программируемая сетевая телеметрия (приложение для сетевого администрирования, которое соединяет эти два компонента и играет ключевую роль для SDN).

5.6.2. Плоскость управления в SDN: логически централизованное программное управление

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

Первые исследования в области SDN были направлены на то, чтобы упростить для сетевых операторов задачу по регулированию трафика. Вместо настройки конфигурации сети предлагалось напрямую контролировать, какой путь выбирает каждый маршрутизатор. Первые реализации технологии SDN должны были работать в рамках существующих интернет-протоколов маршрутизации для непосредственного управления выбором путей. Одним из таких решений стала платформа управления маршрутизацией (Routing Control Platform, RCP) (Фимстер и др.; Feamster et al., 2003), впоследствии развернутая в магистральных сетях для балансировки нагрузки и защиты от DoS-атак. Позднее появился ряд других систем, в частности Ethane (Касадо и др.; Casado et al., 2007), обеспечивающая централизованный программный контроль аутентификации хостов в сети. Однако для ее реализации требовались нестандартные коммутаторы, что не способствовало ее распространению.