В маршрутизации плоскость данных , иногда называемая плоскостью пересылки или плоскостью пользователя , определяет часть архитектуры маршрутизатора , которая решает, что делать с пакетами, поступающими на входящий интерфейс. Чаще всего это относится к таблице, в которой маршрутизатор ищет адрес назначения входящего пакета и извлекает информацию, необходимую для определения пути от принимающего элемента через внутреннюю структуру пересылки маршрутизатора к соответствующему исходящему интерфейсу(ам).
В некоторых случаях таблица может указывать, что пакет должен быть отброшен. В таких случаях маршрутизатор может вернуть ICMP-код «destination unreachable» или другой соответствующий код. Однако некоторые политики безопасности предписывают маршрутизатору отбрасывать пакет молча, чтобы потенциальный злоумышленник не узнал, что цель защищена.
Входящий элемент пересылки также уменьшит поле времени жизни (TTL) пакета и, если новое значение равно нулю, отбросит пакет. В то время как спецификация протокола Интернета (IP) указывает, что сообщение о превышении времени протокола управления сообщениями Интернета (ICMP) должно быть отправлено отправителю пакета (т. е. узлу, указанному в адресе источника), маршрутизатор может быть настроен на молчаливое отбрасывание пакета (опять же в соответствии с политиками безопасности).
В зависимости от конкретной реализации маршрутизатора таблица, в которой ищется адрес назначения, может быть таблицей маршрутизации (также известной как база данных маршрутной информации, RIB) или отдельной базой данных пересылки (FIB), которая заполняется (т. е. загружается) плоскостью управления маршрутизацией , но используется плоскостью пересылки для поиска на гораздо более высоких скоростях. До или после проверки назначения могут быть просмотрены другие таблицы для принятия решения об отбрасывании пакета на основе других характеристик, таких как адрес источника, поле идентификатора протокола IP или номер порта протокола управления передачей (TCP) или протокола пользовательских датаграмм (UDP).
Функции плоскости пересылки выполняются в элементе пересылки. [1] Высокопроизводительные маршрутизаторы часто имеют несколько распределенных элементов пересылки, поэтому маршрутизатор увеличивает производительность за счет параллельной обработки.
Исходящий интерфейс инкапсулирует пакет в соответствующий протокол канала передачи данных. В зависимости от программного обеспечения маршрутизатора и его конфигурации функции, обычно реализуемые на исходящем интерфейсе, могут устанавливать различные поля пакета, такие как поле DSCP , используемое дифференцированными службами .
В общем, переход от входного интерфейса напрямую к выходному интерфейсу через структуру с минимальными изменениями на выходном интерфейсе называется быстрым путем маршрутизатора. Если пакету требуется значительная обработка, например сегментация или шифрование, он может перейти на более медленный путь, который иногда называют сервисной плоскостью маршрутизатора. Сервисные плоскости могут принимать решения о пересылке или обработке на основе информации более высокого уровня, например веб-URL, содержащегося в полезной нагрузке пакета.
Плоскость данных — это часть программного обеспечения , которая обрабатывает запросы данных. [2] Напротив, плоскость управления — это часть программного обеспечения, которая настраивает и отключает плоскость данных. [3]
Концептуальное разделение плоскости данных и плоскости управления проводилось годами. [3] Ранним примером является Unix , где основными файловыми операциями являются открытие и закрытие для плоскости управления и чтение и запись для плоскости данных. [4]
Концептуальное разделение плоскости данных и плоскости управления в программировании программного обеспечения оказалось полезным в области коммутации пакетов , где оно возникло. В сетевых технологиях плоскость данных иногда называют плоскостью пересылки, поскольку она разделяет проблемы: плоскость данных оптимизирована для скорости обработки, а также для простоты и регулярности. Плоскость управления оптимизирована таким образом, чтобы обеспечить конфигурацию , обработку политик, обработку исключительных ситуаций и в целом упрощение и упрощение обработки плоскости данных. [5] [6]
Поставщики разрабатывают маршрутизаторы для определенных рынков. Проектирование маршрутизаторов, предназначенных для домашнего использования, возможно, поддерживающих несколько ПК и VoIP-телефонию, обусловлено сохранением стоимости на максимально низком уровне. В таком маршрутизаторе нет отдельной пересылочной структуры, и есть только один активный путь пересылки: в основной процессор и из основного процессора.
Маршрутизаторы для более требовательных приложений допускают большую стоимость и сложность для получения более высокой пропускной способности в своих плоскостях пересылки.
На производительность пересылки маршрутизатора влияют несколько конструктивных факторов:
Маршрутизаторы могут иметь один или несколько процессоров. В однопроцессорной конструкции эти параметры производительности зависят не только от скорости процессора, но и от конкуренции за процессор. Маршрутизаторы с более высокой производительностью неизменно имеют несколько процессорных элементов, которые могут быть процессорными чипами общего назначения или специализированными интегральными схемами (ASIC).
Высокопроизводительные продукты имеют несколько процессорных элементов на каждой интерфейсной карте. В таких конструкциях главный процессор не участвует в пересылке, а только в плоскости управления и обработке управления.
В Internet Engineering Task Force две рабочие группы в области Operations & Maintenance занимаются аспектами производительности. Группа Interprovider Performance Measurement (IPPM) фокусируется, как следует из ее названия, на операционном измерении услуг. Измерения производительности на отдельных маршрутизаторах или узко определенных системах маршрутизаторов являются компетенцией Benchmarking Working Group (BMWG).
RFC 2544 является ключевым документом BMWG. [7] Классический тест RFC 2544 использует половину портов маршрутизатора (т. е. тестируемого устройства (DUT)) для ввода определенной нагрузки и измеряет время, в течение которого выходные данные появляются на выходных портах.
Первоначально все пункты назначения искались в RIB. Возможно, первым шагом в ускорении маршрутизаторов было наличие отдельных RIB и FIB в основной памяти, причем FIB, как правило, с меньшим количеством записей, чем RIB, был организован для быстрого поиска пунктов назначения. Напротив, RIB был оптимизирован для эффективного обновления протоколами маршрутизации.
Ранние однопроцессорные маршрутизаторы обычно организовывали FIB как хэш-таблицу , в то время как RIB мог быть связанным списком . В зависимости от реализации, FIB мог иметь меньше записей, чем RIB, или то же количество.
Когда маршрутизаторы начали иметь отдельные процессоры пересылки, эти процессоры обычно имели гораздо меньше памяти, чем основной процессор, так что процессор пересылки мог хранить только наиболее часто используемые маршруты. Например, на ранних моделях Cisco AGS+ и 7000 кэш процессора пересылки мог хранить около 1000 записей маршрутов. На предприятии это часто работало довольно хорошо, поскольку было менее 1000 серверов или других популярных подсетей назначения. Однако такой кэш был слишком мал для общей маршрутизации Интернета. Различные конструкции маршрутизаторов вели себя по-разному, когда пункт назначения не находился в кэше.
Состояние промаха кэша может привести к отправке пакета обратно в основной процессор для поиска по медленному пути , который имел доступ к полной таблице маршрутизации. В зависимости от конструкции маршрутизатора промах кэша может привести к обновлению быстрого аппаратного кэша или быстрого кэша в основной памяти. В некоторых конструкциях было наиболее эффективно сделать быстрый кэш недействительным для промаха кэша, отправить пакет, вызвавший промах кэша, через основной процессор, а затем повторно заполнить кэш новой таблицей, которая включала пункт назначения, вызвавший промах. Этот подход аналогичен операционной системе с виртуальной памятью, которая хранит последнюю использованную информацию в физической памяти.
По мере снижения стоимости памяти и роста требований к производительности появились FIB, которые имели то же количество записей маршрутов, что и в RIB, но были настроены на быстрый поиск, а не на быстрое обновление. Всякий раз, когда изменялась запись RIB, маршрутизатор изменял соответствующую запись FIB.
Высокопроизводительные FIB достигают своей скорости за счет специфических для конкретной реализации комбинаций специализированных алгоритмов и оборудования.
Для поиска FIB использовались различные алгоритмы поиска . Хотя сначала использовались известные структуры данных общего назначения, такие как хэш-таблицы , появились специализированные алгоритмы, оптимизированные для IP-адресов. Они включают:
Многоядерная архитектура ЦП обычно используется для реализации высокопроизводительных сетевых систем. Эти платформы облегчают использование программной архитектуры, в которой высокопроизводительная обработка пакетов выполняется в среде быстрого пути на выделенных ядрах, чтобы максимизировать пропускную способность системы. Модель выполнения до завершения минимизирует накладные расходы ОС и задержку. [9]
Для ускорения поиска использовались различные формы быстрой оперативной памяти и, в конечном итоге, базовая память с адресацией по содержимому (CAM). CAM, хотя и был полезен в коммутаторах уровня 2, которым требовалось искать относительно небольшое количество MAC-адресов фиксированной длины , имел ограниченную полезность с IP-адресами, имеющими префиксы маршрутизации переменной длины (см. Бесклассовая междоменная маршрутизация ). Тернарный CAM (CAM), хотя и дорогой, подходит для поиска префиксов переменной длины. [10]
Одной из задач проектирования пересылающего поиска является минимизация объема необходимой специализированной памяти и, все чаще, минимизация мощности, потребляемой памятью. [11]
Следующим шагом в ускорении маршрутизаторов стало создание специализированного процессора пересылки, отдельного от основного процессора. По-прежнему существовал один путь, но пересылка больше не должна была конкурировать с управлением в одном процессоре. Процессор быстрой маршрутизации обычно имел небольшой FIB с аппаратной памятью (например, статической памятью с произвольным доступом (SRAM)) более быстрой и более дорогой, чем FIB в основной памяти. Основная память обычно была динамической памятью с произвольным доступом (DRAM).
Затем маршрутизаторы стали иметь несколько элементов пересылки, которые взаимодействовали через высокоскоростную общую шину [12] или через общую память . [13] Cisco использовала общие шины до тех пор, пока они не переполнились, в то время как Juniper предпочитала общую память. [14]
Каждый элемент пересылки имел свой собственный FIB. См., например, Versatile Interface Processor на Cisco 7500 [15]
В конце концов, общий ресурс стал узким местом, а предел скорости общей шины составил примерно 2 миллиона пакетов в секунду (Mpps). Crossbar fabrics преодолели это узкое место.
По мере увеличения пропускной способности пересылки, даже при устранении накладных расходов на пропуск кэша, общие пути ограничивали пропускную способность. Хотя маршрутизатор мог иметь 16 пересылающих модулей, если была одна шина, была возможна только одна передача пакетов за раз. Были некоторые особые случаи, когда пересылающий модуль мог обнаружить, что выходной интерфейс был одним из логических или физических интерфейсов, присутствующих на карте пересылки, так что поток пакетов полностью находился внутри пересылки. Однако часто было проще, даже в этом особом случае, отправить пакет из шины и получить его из шины.
В то время как некоторые проекты экспериментировали с несколькими общими шинами, окончательный подход состоял в адаптации модели коммутатора с перекрестной шиной из телефонных коммутаторов, в которых каждый пересылающий модуль имел аппаратный путь к каждому другому пересылающему модулю. При небольшом количестве пересылающих модулей пересылающие структуры с перекрестной шиной практичны и эффективны для высокопроизводительной маршрутизации. Существуют многоступенчатые конструкции для систем с перекрестной шиной, таких как сети Clos .