Формальные методы в компьютерных сетях - Доп. главы Компьютерных сетей и телекоммуникации к.ф.-м.н. Чемерицкий Е.В.

Страница создана Антон Овчинников
 
ПРОДОЛЖИТЬ ЧТЕНИЕ
Формальные методы в компьютерных сетях - Доп. главы Компьютерных сетей и телекоммуникации к.ф.-м.н. Чемерицкий Е.В.
Формальные методы в
 компьютерных сетях
Доп. главы Компьютерных сетей и
 телекоммуникации
 к.ф.-м.н. Чемерицкий Е.В.
Формальные методы в компьютерных сетях - Доп. главы Компьютерных сетей и телекоммуникации к.ф.-м.н. Чемерицкий Е.В.
Литература:
Qadir, J.; Hasan, O.,
Applying Formal Methods to Networking:
Theory, Techniques, and Applications,
Communications Surveys & Tutorials,
IEEE , vol.17, no.1, pp.256-291, 2015

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 2
 Чемерицкий Е.В.
Формальные методы в компьютерных сетях - Доп. главы Компьютерных сетей и телекоммуникации к.ф.-м.н. Чемерицкий Е.В.
Формальные методы
• Формальные методы – такие методы
 спецификации, проектирования и анализа
 свойств систем, которые имеют строгое
 математическое обоснование
• Верификация – проверка соответствия
 свойств системы заданной спецификации
• Синтез – построения системы, свойства
 которой удовлетворяют заданной
 спецификации

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 3
 Чемерицкий Е.В.
Составные части метода
 формальной верификации
• Язык описания модели – способ
 математического описания устройства и
 характеристик анализируемой системы
• Язык спецификации – способ формального
 описания свойств анализируемой системы
• Метод верификации – алгоритм для
 проверки соответствия модели системы
 заданной спецификации

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 4
 Чемерицкий Е.В.
Составные части метода
 формальной верификации
 Исследуемая Проверяемые
 Система Свойства Системы

 Формальная Формальные
 Модель Спецификации

 Алгоритм
 Верификации

 Система Система
 Корректна! некорректна!

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 5
 Чемерицкий Е.В.
Алгоритм Петерсона (1981)
 Исходные данные
 Глобальные переменные:
 want1 = false, want2 = false, turn = 1
 Процесс 1: Процесс 2:
 while (true) { while (true) {
 
 want1 := true; want2 := true;
 turn := 1; turn := 2;
 while want2 and while want1 and
 turn = 2 do { }; turn = 1 do { };
 
 want1 := false; want2 := false;
 } }
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 6
 Чемерицкий Е.В.
Алгоритм Петерсона (1981)
 Формальная модель
 want1 := false want1 := true turn := 1

 1CS 1NCS 1W1 1W2

 not (want2 = true or turn = 2)

 want2 := false want2 := true turn := 2

 2CS 2NCS 2W1 2W2

 not (want1 = true and turn = 1)
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 7
 Чемерицкий Е.В.
Алгоритм Петерсона (1981)
 Формальная модель
• Система описывается конечным автоматом,
 полученным суперпозицией автоматов для
 каждого из процессов
• Состояние системы – совокупность
 значений разделяемых переменных и
 состояний каждого из процессов
 – Каково общее количество состояний?
 – На самом деле 20.

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 8
 Чемерицкий Е.В.
Алгоритм Петерсона (1981)
 Спецификация свойств
• Свойства системы можно задать формулами
 темпоральной логики LTL:

• (neXt)
 
• (Future)
 
• (Globally)
 
• (Until)
 
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 9
 Чемерицкий Е.В.
Алгоритм Петерсона (1981)
 Спецификация свойств
• Свойства безопасности (safety)
 Никогда не произойдёт ситуации, при которой оба
 процесса одновременно окажутся внутри
 критической секции
 Верификация == Проверка Достижимости
 ¬(1 ∧ 2 )
• Свойства живучести (liveness)
 Процесс пожелавший попасть в критическую секцию
 рано или поздно туда попадёт
 Верификация == Поиск Циклов
 (1 → 1 ) ∧ (2 → 2 )
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 10
 Чемерицкий Е.В.
Формальная верификация
 vs. тестирование

 Задача Эффектиность методов
 Формальная Тестирование
 верификация
 Поиск ошибок средняя высокая
 Доказательство высокая низкая
 корректности
 Сложность высокая низкая
 использования

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 11
 Чемерицкий Е.В.
Формальная верификация
 vs. тестирование

 Типы ошибок Частая Редкая
 Безобидная тестирование ---
 Критическая тестирование формальная
 формальная верификация
 верификация

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 12
 Чемерицкий Е.В.
Типы исследуемых систем
• Трансформирующие системы
 – Преобразовывают входные данные в выходные
 – Можно представить таблицей или формулой
 – Коммутатор со статическими правилами
• Реагирующие системы
 – Поведение зависит от истории воздействий
 – Можно представить конечным автоматом
 – Реактивная программа контроллера

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 13
 Чемерицкий Е.В.
Основные свойства
 математических моделей
• Абстракность
 Модель должна быть упрощением системы
• Адекватность
 Модель должна отражать свойства системы
• Компактность
 Размер и структурная сложность модели влияет
 на сложность решения задачи верификации
 Символьные методы – модель не перечисляет
 явным образом все состояния системы

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 14
 Чемерицкий Е.В.
Некоторые примеры
 формальных моделей
• Таблицы
• Графовые представления
• Булевы формулы
• Двоичные решающие диаграммы
• Размеченные системы переходов
• Временные автоматы
• Сети Петри

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 15
 Чемерицкий Е.В.
Основные свойства
 языков спецификации
• Выразительная мощность
 Язык должен охватывать исследуемые свойства
• Сложность решения задач
 Проверка эквивалентности формул
 Проверка непротиворечивости формул
 Формальная верификация
• Совместимость с моделью
 Сложность верификации напрямую зависит от
 согласованности модели с языком спецификации
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 16
 Чемерицкий Е.В.
Некоторые примеры
 языков спецификации
• Пропозициональная логика
• Логика предикатов первого порядка
• Логика высших порядков
• Логика Хоара
• Модальная логика
• Темпоральная логика
• -исчисления

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 17
 Чемерицкий Е.В.
Методы формальной
 верификации
• Неавтоматические
 Доказательство вручную
• Полуавтоматические
 Theorem proving
 полуразрешимость
• Автоматические
 Model checking
 комбинаторный взрыв

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 18
 Чемерицкий Е.В.
Исторический путь развития
 компьютерных сетей
“Интернет стал жертвой своего успеха”
• Ценность сети Интернет слишком высока
• Эмпирический закон Меткалфа

Значение для формальных методов:
• Разработка методом проб и ошибок
• Инженерная практика ценится выже
 теоретических изысканий

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 19
 Чемерицкий Е.В.
Отцы-основатели о
 формальных методах

• Formal methods have not yielded results
 commensurate with the effort to use them.
 They are overblown, verbose, hard to use,
 hard to understand.
 Vint Cerf
• We reject: kings, presidents and voting.
 We believe in: rough consensus and running code.
 David Clark
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 20
 Чемерицкий Е.В.
Принципы построения
 компьютерных сетей
 David Clark
 The Design Philosophy of the DARPA Internet Protocols
 SIGCOMM ’88. — ACM, 1988. — Pp. 106–114.
• Отказоустойчивость
• Разнообразие сервисов передачи данных
• Поддержка широкого диапазона сетей
• Распределённое управление ресурсами
• Рентабельность
• Расширяемость
• Учёт использованных сетевых ресурсов
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 21
 Чемерицкий Е.В.
Прогнозирование
 поведения сети
 Настройки устройств

 Служебные протоколы

 Информация о сетевом
 окружении

 Алгоритмы генерации правил

 Правила обработки пакетов

 Поведение сети

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 22
 Чемерицкий Е.В.
Верификация сетевых
 протоколов
Исследуемые свойства:
• Deadlocks - ожидание условий, которые
 никогда не будут выполнены
• Livelocks – выполнение инструкций протокола
 не приближает его к цели
• Improper termination – протокол завершается
 не достигнув цели

Число состояний потенциально бесконечно –
метод их полного перебора неприменим!

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 23
 Чемерицкий Е.В.
Верификация статической
 конфигурации сети
Исследуемые свойства:
• Black Holes – тихое сбрасывание пакетов
• Fowrarding Loops – зацикливание пакетов
• Reachability – достигнет ли пакет заданной точки?
• Ограничения на длину маршрутов
• Изоляция потоков

Нужен выразительный язык спецификации!
Как восстановить поведение сети?

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 24
 Чемерицкий Е.В.
Network Security
Верификация и синтез
конфигураций сетевых экранов:
• Проверка эквивалентности
• Проверка избыточности
• Синтез конфигурации состоящей из
 минимального числа правил

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 25
 Чемерицкий Е.В.
Формальные методы и ПКС
• Новые протоколы управления сетевым
 оборудованием дали доступ к актуальным
 правилам обработки пакетов
• Централизация сети позволила собрать
 информацию о конфигурации сети в
 единой точке и отслеживать её изменение
• Появилась возможность адаптации
 наработок из области разработки ПО

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 26
 Чемерицкий Е.В.
Новые сети – новые задачи

 Настройки приложений

 Управляющие приложение

 Служебные модули
 контроллера

 Контроллер

 Правила обработки пакетов

 Поведение сети

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 27
 Чемерицкий Е.В.
Программирование ПКС
Andreas Voellmy, Paul Hudak
Nettle: taking the sting out of programming network
routers

Andreas Voellmy, Hyojoon Kim, Nick Feamster
Procera: a language for high-level reactive network
control

Joshua Reich , Christopher Monsanto , Nate Foster ,
Jennifer Rexford , David Walker
Modular SDN Programming with Pyretic

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 28
 Чемерицкий Е.В.
Control Plane Verification

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 29
 Чемерицкий Е.В.
Программирование ПКС

 APP3
Приложения APP1
 APP4 APP2
API контроллера
Платформа Контроллер

API коммутатора
Коммутаторы

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 30
 Чемерицкий Е.В.
Программирование ПКС

Приложения APP4 APP2 APP3 APP1

API контроллера

 Встроенный интерпретатор
Платформа Контроллер

API коммутатора
Коммутаторы

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 31
 Чемерицкий Е.В.
Программирование ПКС
from pyretic.lib.corelib import *
# отправить пакет на все порты
def main():
 return flood()
# блокировать хост 10.0.0.1
def access_control():
 return ~(match(srcip=’10.0.0.1’) |
 match(dstip=’10.0.0.1’))
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 32
 Чемерицкий Е.В.
Control Plane Verification
Marco Canini, Daniele Venzano et. all
A NICE way to test OpenFlow applications
Строит модель выполнения программы
контроллера с учётом состояния всей ПКС

Thomas Ball, Nikolaj Biorner et all.
VeriCon: Towards Verifying Controller
Programs in Software-Defined Networks
Проверяет программу для всех моделей сети
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 33
 Чемерицкий Е.В.
Data Plane Verification
• Меньше предположений об управляющих
 приложениях на контроллере
• Проверяет выполнение политик на уровне
 проверки правил – метод нечувствителен к
 наведённым ошибкам внутри контроллера
• Естественная интерпретация понятия
 политики маршрутизации

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 34
 Чемерицкий Е.В.
Применение системы Vermont
для верификации контура данных
 Доп. главы Компьютерных сетей и
 телекоммуникации
 к.ф.-м.н. Чемерицкий Е.В.
Политики маршрутизации
 требования к поведению компьютерной сети
• Внешние потоки не достигают почтового сервера
• Исходящие потоки проходят через средство DPI
• Между каждой парой хостов в офисе есть маршрут
• Сети разных департаментов изолированы
• Все маршруты внутри сети короче шести хопов
• Пакеты не образуют циклов маршрутизации
• Хост A не может подлючиться к хосту B до тех пор,
 пока хост B не попытался подключиться к хосту A
• Пропускная способность соединения не меньше R,
 а задержка передачи данных – не превышает T
Анализ свойств отношения
 маршрутизации
Al-Shaer E., Al-Haj S. FlowChecker: Configuration Analysis
and Verification of Federated Openflow Infrastructures //
 SafeConfig ’10. — Chicago, USA, 2010. — Pp. 37–44.

 B
 A

 Kazemian P., Chang M., Zeng H., Varghese G.,
 McKeown N., Whyte S. Real Time Network Policy
 Checking Using Header Space Analysis // NSDI’13. —
 Lombard, USA, 2013. — Pp. 99–111.
VERMÓNT
 VERifying MONiTor
 VERMONT проверяет правила обработки пакетов в
 таблицах коммутаторов на соответствие формальным
 спецификациям политик маршрутизации
Необходимо

 Выразить требования к поведению сети с помощью
 нашего языка спецификаций Одноразовая работа

 Предоставить топологию и файлы конфигурации
 коммутационных устройств Возможна автоматизация

 • Гарантии работы сети в соответствии с ожиданиями
Выгода

 • Выявление ошибоных конфигураций сети
 • Информация о причинах нарушения политики
Анализ свойств отношения
 маршрутизации
 State 2: State 3:
 Header h2 Header h3
 State 1: Port #1 Port #1
 Header h1 Switch #2 Switch #3
 Port #1
 Switch #1
 h2 h3

 h1 B
 h4
 State 4:
 A Header h4
 Port #2
Состояние пакета: Switch #3
 1. Имя коммутатора Switch {0, 1}m
 2. Номер порта Port {0, 1}l
 3. Заголовок пакета Header {0, 1}k
Реляционная модель сети
 Сеть определяется набором отношений
Входные/выходные порты
(линии связи, топология сети) Switch Port
Отношение пересылки
(линии связи, топология сети)
 Switch Port Switch Port

Отношения коммутации на узлах
(отдельные правила и таблицы коммутации)
 Port Header Port Header

Отношение одношаговой маршрутизации
(отдельные коммутаторы, сети коммутаторов)
 Switch Port Header Switch Port Header
Реляционная модель сети
 Сеть определяется набором отношений
OpenFlow правило моделируется шаблоном
Pattern и множеством шаблонов Rewrite
 * - пакет подпадает под шаблон Pattern,
 вне зависимосит от значения бита
 P[0] H[0] H[1] H[2] H[3]

 x1 x2 x3 x4
Pattern 0 0 0 1 0 1 1 * 0 0 0 1 * * * * 0 0 0 1

Rewrite 0 0 0 1 1 1 0 * 0 0 0 1 * * * * 0 0 0 1
 y1 y2 y3 y4
 * - шаблон Rewrite не изменяет значение бита
 41
Binary Decision Diagram
 (ROBDD)
 1 1

 2 Размер BDD зависит от выбора 1
 порядка переменных
 3 2
 1 2 3 4
 4 2
 0 1 1 *
 1 1 3
 1 1 0 *

 2 2 1 2 3 4 3

 3 3 1 1 2 2 4
 ( 3 3 )( 4 4 ∨ 4 4 )
 4 4 4 4

0 1 0 1
Построение BDD по
 состоянию сети
• Строим BDD для каждой пары ⟨ , ⟩

• Строим BDD для каждого правила FlowTable

• Строим BDD для каждого коммутатора

• Строим BDD для всех коммутаторов 

• Строим BDD для топологии 

• Строим композицию и 

• Получаем отношение 

• Получаем транзитивное замыкание ∗

 43
Язык спецификации
 Равенства x[field] = const x[field] = y[field]
 Связки ∧ ∨ ¬ 
 Кванторы ∀ . ∃ . 
 Замыкания + [ , ]

 Правила 1 , = ( , )
 , = ∃ : −1 , ∧ , 
 вычисления
 [i,j] , = , ∨ ⋯ ∨ , 
 замыканий + ( , ) = 1,∞ ( , )
 Входы ( )
 Отношения,
 Выходы ( )
определяющие
 Шаг коммутации ( , )
поведение сети
 Отношение достижимости + ( , )
Пример: запрет циклов по
 состоянию пакета
aux: lead_to_cycle(x) :=
 In(x) and Exist[y:
 R_tc(x,y) and
 Exist[z:
 R_tc(y,z) and
 y == z
 ] z
 ];
 x y

main: no_state_cycles() :=
 Forall[x: not lead_to_cycle(x)];
Метод верификации
 конфигурации сети
 Сеть удовлетворяет политике маршрутизации 
 формулы спецификаций этой политики выполняются для
 отношений, моделирующих указанную сеть

 Топология Спецификации
 и состояние политик
 коммутаторов Генератор Парсер маршрутизации
 отношений спецификаций
 Модельные Абстрактное
отношения в синтаксическое
форме BDD Верификатор дерево

 Политика A Политика B нарушена
 выполняется множеством потоков P
Отношение
 одношаговой
 маршрутизации

 1.094
 Транзитивное
 замыкание
 отношения

 секунды

 6.294
 Общее времяработы
 конструктора
 Время построения модели,

 18.028
 Число вершин дерева
 OBDD, тыс. шт.

 642
 +
 
 Порядок числа путей
 Свойства

 дерева OBDD

 18
 Циклы по
 состояниям
 0.043 Циклы по
 топологии
 0.047

 Пути длиннее
 одного скачка
 0.855
 секунды

 Пути длиннее
 двух скачков
 2.013
 Время верификации ПКС,

 Пути длинее
Stanford University Backbone Network

 трёх скачков
 3.764
 757000 правил
 48 таблиц
 90 Mb файлов с

 Топология Fat Tree
 конфигурациями

 16 маршрутизаторов
Stanford network verification
Проверка Затрачено
 Вердикт
требования времени (мс)
Построение - 3043.687
модели

Циклы YES 166.191
передачи

Чёрные NO 174.845
дыры

Маршруты NO 293.522
Схема развёртывания
 Контроллер ПКС Начальное состояние
 Feeder

 сообщения от команды
 коммутаторов контроллера
 Безопасна ли команда?
 Прокси-сервер Верификатор
 Вердикт верификатора:
 сообщения от команды Политика нарушера –
 коммутаторов контроллера блокировать команду
 Политики выполнены –
 Сеть применить команду
 коммутаторов Спецификации

VERMONT моделирует изменения таблиц коммутаторов после
 применения команды контроллера, и блокирует команду,
 если она приводит к нарушению политик маршрутизации
Сравнение с другими средствами
 Построение Перестроение Мощность Поддержка
 Средство
 модели (мс) модели (мс) языка OpenFlow
VERMONT 3100 100 - 600 FO[TC] полная
2013

NetPlumber 37000 2 - 1000 CTL частичная
Stanford University
2013

VeriFlow >4000 68 - 100 Фиксированный минимальная
University of Illinois набор свойств
2013

AP Verifier 1000 0.1 Фиксированный минимальная
University of Texas набор свойств
2013

Anteater 400000 ??? Фиксированный нет
University of Illinois набор свойств
2011

FlowChecker 1200000 350 - 67000 CTL полная
University of North
Carolina
2010
Демонстрация VERMONT
 Network disjoint
Коммутатор обслуживает не более двух
 абонентов одновременно

 Port #02
 Port #03

 h2
 h3

 s1

 Port #01
 Port #04
 h1
 h4
Спецификация политики
main: disjoint() := Forall[x, out_x, y, out_y:
 !R(x, out_x) or !R(y, out_y) or
 x[p] == out_y[p] and out_x[p] == y[p] or
 x[p] == y[p] and out_x[p] == out_y[p]
];

 y

 out_x
 out_y

 x
Спецификация политики
main: disjoint() := Forall[x, out_x, y, out_y:
 !R(x, out_x) or !R(y, out_y) or
 x[p] == out_y[p] and out_x[p] == y[p] or
 x[p] == y[p] and out_x[p] == out_y[p]
];

 y

 out_x
 out_y

 x
simulator CLI
 MININET
 There are more components
 whose output is not shown:
 • SDN controller
 • VERMONT Verifier
 • VERMONT Feeder
VERMONT
proxy CLI

 Switch S1 is already connected to
 VERMONT proxy

 Flow table of switch S1
switch S1
 Rules at

 is currently empty
Rules at VERMONT MININET
switch S1 proxy CLI simulator CLI

 interrupt mode
 Setting VERMONT proxy to
simulator CLI
 MININET

 Host h1 starts to ping host h3
VERMONT
proxy CLI

 Controller tries to install the rules
 to transmit ping packets

 Proxy interrupts command
 from the controller and sends
 them to Verifier

 Verifier create an updated model
 of the data plane and checks
 them against a set of PFPs
switch S1
 Rules at
simulator CLI
 MININET

 First packet of the flow
 uses slow path
VERMONT
proxy CLI

 Proxy delivers verified
switch S1

 commands to the switch
 Rules at

 Switch table contains rules to
 transmit packets between
 host h1 and host h3
simulator CLI Subsidiary packets use fast path
 MININET
VERMONT
proxy CLI

 Rules have an idle timeout and
 will expire in 5 seconds
switch S1
 Rules at
simulator CLI
 MININET

 Host h2 starts to ping host h4
VERMONT
proxy CLI

 Controller tries to install the rules
 to transmit ping packets

 Proxy interrupts command
 from the controller and sends
 them to Verifier

 Verifier create an updated model
 of the data plane and checks
 them against a set of PFPs
switch S1
 Rules at
simulator CLI
 MININET
VERMONT
proxy CLI

 Proxy drops unsafe commands
 and notifies the controller
switch S1
 Rules at
simulator CLI
 MININET

 Why does ping work?
VERMONT

 Packets are delivered through
proxy CLI

 the control plane

 We can block them!
 But do we really want to?
switch S1
 Rules at
simulator CLI Packets start to use fast path
 MININET
VERMONT
proxy CLI

 Old rules have been expired

 Controller is allowed to
 install new rules

 Switch table contains rules to
 transmit packets between
switch S1

 host h2 and host h4
 Rules at
simulator CLI Packets use slow path
 MININET
VERMONT
proxy CLI

 Rules to transmit packets from
 host h1 to host h3 violate
 forwarding policy
switch S1
 Rules at
simulator CLI Packets start to use fast path
 MININET
VERMONT
proxy CLI

 Switch table contains rules to
 transmit packets between
 host h1 and host h3
switch S1
 Rules at
Проблема консистентного
обновления конфигурации сети
 Доп. главы Компьютерных сетей и
 телекоммуникации
 к.ф.-м.н. Чемерицкий Е.В.
Проблема консистентного
 обновления конфигурации
• Конфигурация сети задаёт привязку
 правил к коммутаторам и топологию сети
• Отношения и для конфигурации 
 определяет пути ℎ передачи пакетов
 0 ∈ 
 , +1 ∈ 
 ℎ = 0 , 1 , … , , +1 , …
• ℎ( ) – множество всех путей
 передачи пакетов для конфигурации 
 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 67
 Чемерицкий Е.В.
Проблема консистентного
 обновления конфигурации
• – команда реконфигурации сети
 добавление, удаление или модификация
 правила маршрутизации
• - конфигурация, полученнная в
 результате применения команды к
 конфигурации 
• Если = 1 , … , , тогда
 ( ) = (… , 1 … )

 Доп.главы Компьютерных сетей к.ф.-м.н.
07.12.2016 68
 Чемерицкий Е.В.
Проблема консистентного
 обновления конфигурации
• На множестве команд реконфигурации 
 введено отношение частичного порядка ≺:
 если ′ ≺ ′′ , то ′′ выполняется
 только после выполнения ′

• Пакет реконфигурации – множество команд
 реконфигурации, дополненное отношением
 частичного порядка ( , ≺).
Проблема консистентного
 обновления конфигурации
Входные данные:
• Начальная конфигурация сети C0
• Требования корректности и безопасности
 пост-условие , инвариант  .
Требуется:
• Найти такой пакет реконфигурации , ≺ , для
 любой линеаризации которого выполнено:
1. 0 ⊨ Φ
2. ∀ ′ = ′ ′′ ⇒ ′ 0 ⊨ Ψ
1. Синтез заданной
 конфигураций сети
Построить такую конфигурацию , которая
удовлетворяла бы заданному постусловию Φ

A. Noyes, T. Warszawski, P. Cernyand, N. Foster.
Toward Synthesis of Network Updates.
2-nd Workshop on Synthesis (CAV-2013), 2013,
Saint Petersburg, Russia
2. Глобально-консистентное
 обновление сети
• Пост-условие Ψ(X):
 = 
• Инвариант Φ(X) :
∀ : → ℎ , ⊆ ℎ ∨ ℎ , ⊆
3. Локально-консистентное
 обновление сети
• Пост-условие Ψ(X):
 ℎ = ℎ 0 ∖ { ℎ0 } ∪ { ℎ1 }
• Инвариант Φ(X) :
 ℎ 0 ∖ ℎ0 ⊆ ℎ ⊆ ℎ 0 ∪ ℎ1

S. Raza, Y. Zhu, C.-N. Chu S. Raza, Y. Zhu, C.-N. Chuah.
Graceful network state migrations.
IEEE/ACM Transactions on Networking, 2011.
4. Восстановление сети
• Пост-условие Ψ(X):
 = 
• Инвариант Φ(X) :
 ℎ 0 ∩ ℎ ⊆ ℎ ∧
 ℎ ⊆ ℎ 0 ∪ ℎ( )

• Конфигурация перешла в 0 в результате
 удаления части правил
• Цель – восстановить 0 из конфигурации 
5. Оптимизация таблицы
 потоков
• Пост-условие Ψ(X):
 ℎ( ) = ℎ( ) ∧
 ∀ ℎ = ℎ → ≤ 
• Инвариант Φ(X) :
 ℎ( ) = ℎ( )

• K. Kogan, S. Nikolenko, W. Culhane, P. Eugster, E. Ruan.
 Towards efficient implementation of packet classifiers.
 Proc. of the 2-d Workshop on Hot Topics in SDN, 2013.
Обновление сети с
 помощью тегов

h (h,1) (h,1) (h,1) h
Обновление сети с
 помощью тегов

 (h,2) (h,2) (h,2)
 (h,2) h

h (h,1) (h,1) (h,1) h

3-х фазовый алгоритм обновления
1: добавление новых правил
Обновление сети с
 помощью тегов

 (h,2) (h,2) (h,2) (h,2)
 (h,2) h

h (h,1) (h,1) h

3-х фазовый алгоритм обновления
1: добавление новых правил
2: переключение потоков
Обновление сети с
 помощью тегов

 (h,2) (h,2) (h,2) (h,2)
 (h,2) h

h

3-х фазовый алгоритм обновления
1: добавление новых правил
2: переключение потоков
3: удаление устаревших правил
Обновление сети с
 помощью тегов
• Заголовки пакетов должны иметь
 дополнительное поле, которое будет
 использоваться исключительно при
 обновлении конфигурации
• В частных случаях задачу обновления
 можно решать без использования
 тегирования, в общем случае такая задача
 неразрешима

07.12.2016 80
Вы также можете почитать