Технологія P4: чи стане вона майбутнім Software Defined Networking
Відколи бізнеси почали перетворювати ІТ-інфраструктури в хмарні середовища, відчувається їхнє прагнення мати все більше і більше контролю над своїми мережами.
Донедавна з цим справлявся SDN (Software Defined Networking), однак його потенціал був суттєво обмежений негнучкістю мережевого обладнання. Це і підштовхнуло networking-спільноту створити програмоване обладнання, яке б замінило традиційні світчі. В основу інновації лягла мова програмування P4.
У цій статті я розказую, чи стане P4 чарівною пігулкою для мережевої індустрії та в яких випадках вона точно спрацює.
Чому програмно-конфігурованим мережам (SDN) потрібен P4
Однією з ключових проблем, які намагається вирішити SDN-спільнота, є скорочення часу на впровадження нових протоколів і розширення їхнього функціоналу. Постає логічне запитання — чому це все триває так довго?
Перш за все, кожен протокол повинен пройти через робочу групу IETF (Internet Engineering Task Force), що само по собі є тривалим процесом. Після того, як офіційний стандарт визначено, дизайнери чіпів мають імплементувати його у свої ASIC-и (реальні приклади, такі як VXLAN, показують, що ця частина може тривати навіть декілька років). До того ж, ніхто не гарантує, що жодні модифікації протоколів не знадобляться через якийсь час.
Мало того, що компанії, які оперують великими мережами, повинні чекати на обладнання, щоб підтримувати ці протоколи, є ще одна важлива проблема. Виробники мережевих чіпів — єдині, хто може визначити, як працюватиме та чи інша функція. Користувачі промислових мереж розуміють, що вони не можуть диктувати свої побажання, натомість змушені використовувати рішення, які їм нав’язують їхні вендори. Поява P4 — це результат об’єднаних зусиль консорціуму з розробки програмованих мережевих чіпів, який прагне перевернути цей підхід з ніг на голову, дозволяючи підприємствам встановлювати власну логіку обробки і пересилання пакетів мікроконтролерами.
Чому вашій мережі потрібен P4
P4 (Programming Protocol-Independent Packet Processors) — це предметно-орієнтована мова програмування для вираження того, як пакети обробляються через data plane програмованого елементу переадресації. Це може бути апаратний чи програмний комутатор, інтерфейсна мережева карта, роутер або інше мережеве обладнання.
P4 забезпечує розробнику базовий набір інструментів для впровадження мережевого стеку в апаратне забезпечення. Він здатен оперувати такими абстракціями, як типи заголовків (набір полів і їхні розміри), парсери (як заголовки організовані разом, як їх розрізнити тощо), таблиці для пов’язування ключів з діями, лічильники тощо. Але не більше. Мова P4 не знає, як виглядає Ethernet чи IP-заголовки. Саме девелопер тлумачить чіпу, що таке Ethernet-заголовок і як його розібрати, виконати порівняння, зібрати (збудувати заголовок для вихідних пакетів) і до якого порта (чи портів) передати пакет, тощо.
Програмованість відкриває нові можливості для бізнесів: гнучкість мережевого стеку на противагу традиційним світчами з фіксованою функцією; здатність вдосконалюватися (те, чого апаратні рішення ніколи не матимуть), що дозволяє додавати функції і протоколи до мережевих пристроїв, оновлюючи їхнє програмне забезпечення P4, замість того, щоб купувати нові світчі.
Чи замінить P4 OpenFlow
OpenFlow — це один з найпоширеніших сьогодні SDN-протоколів. Він має встановлену інфраструктуру, спільноти і контролери, що працюють поверх нього. Чого ще хотіти? Марно сподіватися, що всі відмовляться від OpenFlow і почнуть впроваджувати світчі за допомогою P4 у своїх мережах. Однак OpenFlow має декілька значних недоліків, які працівники дата-центрів повинні взяти до уваги.
Функції OpenFlow базуються на наборі визначених протокольних заголовків (також відомих під назвою TTPs — table type patterns), які вендори обладнання можуть підтримувати або ні. Більше того, додавання нового TTP не є завданням з легких і вимагає великої роботи, так само як і залучення спільноти. Це може не задовольняти вимоги академічного дослідження або динамічного середовища в дата-центрах, де вимоги змінюються дуже швидко або коли вони навіть невідомі. Натомість P4 дозволяє програмувати обладнання загальним способом і впроваджувати його за лічені дні.
Цікаво, що OpenFlow також може бути написаний мовою P4, що робить його, по суті, часткою того, що P4 може запропонувати світові. P4 — це незалежний від протоколу інструмент, який може імплементувати мережевий стек для будь-якої потреби і забезпечити контролеру API для заповнення таблиць. Проблема з OpenFlow в тому, що він вимагає перегляду специфікації, у той час як рішення, базовані на P4 (як наприклад, P4 Runtime), є гнучкішими і динамічнішими.
Інша річ, на яку варто звернути увагу, — це OF-DPA (OpenFlow data plane abstraction) — апаратна абстракція, яку розробила компанія Broadcom, щоб накладати OpenFlow-специфікацію на свій пайплайн. Чим більше OF-DPA буде адаптовано мережами, тим більше OpenFlow буде пов’язаний з бродкомівськими чіпами. OpenFlow не виправдовує первинне покликання SDN бути незалежним від вендорів. Інші компанії мають іншу пайплайн-імплементацію і не зможуть слідувати OF-DPA специфікації, шукаючи інші можливості, такі як P4, де вони все ще залишаються конкурентноздатними.
Приклади використання P4
P4 Runtime. P4 Runtime завойовує все більше і більше популярності у світі SDN-контролерів, whitebox-рішень тощо. Призначення цього проекту полягає в наданні автогенерованого інтерфейсу для програмування P4 таблиць. Він, як і P4, повністю незалежний від протоколів і вендорів.
Один із актуальних проектів з використанням P4 — це ONOS. Проект спрямований на підтримку P4 Runtime як протоколу для контролю P4 пайплайнів і роботи з match-action таблицями через існуючі ONOS API. ONOS вже підтримує пристрої, що базуються на Tofino і Spectrum на чолі з P4 Runtime API.
Stratum — це оупенсорсний проект Google для розробки референсної реалізації white-box світчів. Ця платформа також використовує P4 як інструмент за власним вибором для визначення пайплайну мережевого чіпа разом з P4 Runtime для динамічного програмування таблиць.
Inband Network Telemetry. INT — це інфраструктура, призначена для збору і звітування стану мережі засобами самих мережевих чіпів, без перевантажування контролера. INT є реальним кандидатом для того, щоб бути реалізованим на P4, тому що він може змінюватися з часом і вимагати додаткових розширень функціоналу. P4 пропонує абсолютно гнучкий підхід, що дозволяє відслідковувати теоретично будь-які атрибути мережі. Користувачі самі можуть вирішити, які дані повинні бути додані в заголовок і які вузли повинні це робити. Використовуючи цей підхід, можна відслідковувати шлях пакету в мережі, затримку при передаванні, заповнення буферів пам’яті і багато інших метрик.
Behavioral Model. Мова програмування P4 може використовуватися як «золотий стандарт» для індустрії, щоб пояснювати вендорам обладнання, як повинні поводитися їхні мікроконтролери. Програмний світч P4 дозволяє компілювати і запускати симуляції, написані на P4, щоб розробляти новий функціонал без жодного обладнання для обробки пакетів.
SAI. Передбачалося, що P4 буде використовуватися не лише для визначення пайплайну з нуля, але й для того, щоб розширити існуючий. Як приклад, Microsoft і Mellanox продемонстрували розширення для оупенсорсного NOS SONiC. SONiC використовує SAI (Switch Abstraction Interface) у якості відкритого API, якого повинні дотримуватися вендори. Оскільки P4 не зважає на те, який тип API генерує компілятор, він також може генерувати (або розширювати) вже існуючі API, такі як SAI. Це приносить багато вигоди для бізнесів, чиї мережеві вимоги задовольняються старішими протоколами, але які все ж потребують розширення функціоналу для спеціальних випадків. Як і в ситуації із заголовками SAI, новий модуль може бути доданий до ASIC через P4 і сконфігурований через SAI-розширення.
Яке майбутнє у P4
Наразі P4 перебуває на ранній стадії освоєння, але вже зараз бачимо позитивну динаміку і зацікавлення ним серед ключових гравців ринку. Організації, які мають достатньо власних ресурсів, щоб програмувати мережеві чіпи, зараз можуть перетворити свої світчі на будь-що, що їм потрібно. У них більше немає потреби чекати на свого постачальника ASIC-а, щоб той створив новий протокол або змінив той чи інший параметр. Тепер вони можуть зробити це самостійно.
Потенційно така гнучкість може привести до економії коштів і дозволить компаніям купувати мережеве обладнання напряму у виробників, без посередництва. У свою чергу постачальники чіпів не хочуть прогавити нагоду і інвестують у підтримку P4, щоб залишатися у грі. Навіть якщо сьогодні ще невідомо достеменно, чи P4 стане стандартом для індустрії, ініціативи таких компаній, як Google, Microsoft та інших, сприяють тому, щоб це сталося.
