От FORCES к Ethane: Control Plane Evolution (Субтитры)

File contents

WEBVTT

1
00:00:00.400 --> 00:00:03.660
Добро пожаловать на курс по программно-определяемым сетям.

2
00:00:03.660 --> 00:00:07.479
В этом уроке мы завершим обсуждение истории

3
00:00:07.479 --> 00:00:09.759
программно-определяемых сетей, и, в частности, мы

4
00:00:09.759 --> 00:00:13.450
рассмотрим историю управления сетями с коммутацией пакетов.

5
00:00:13.450 --> 00:00:16.250
Мы уже немного изучили историю

6
00:00:16.250 --> 00:00:18.714
управления центральной сетью, но большая часть этого была в контексте

7
00:00:18.714 --> 00:00:22.242
телефонной сети и сетей с коммутацией каналов, и сегодня мы

8
00:00:22.242 --> 00:00:25.220
рассмотрим, как развивалось управление пакетными коммутационными сетями.

9
00:00:26.340 --> 00:00:29.307
Я начну с напоминания о том, почему разделение

10
00:00:29.307 --> 00:00:31.377
управления сетью от простых данных является хорошей

11
00:00:31.377 --> 00:00:33.999
идеей, а затем мы рассмотрим различные способы

12
00:00:33.999 --> 00:00:38.340
, которые были разработаны для управления сетями с коммутацией пакетов.

13
00:00:38.340 --> 00:00:41.538
Начнем с рассмотрения протокола FORCES,

14
00:00:41.538 --> 00:00:46.010
который был разработан в инженерной группе Интернета.

15
00:00:46.010 --> 00:00:49.610
Который эффективно определил пользовательский отдельный

16
00:00:49.610 --> 00:00:53.640
канал управления для управления переключателями или элементами пересылки.

17
00:00:53.640 --> 00:00:56.856
Затем мы рассмотрим платформу управления маршрутизацией, которая

18
00:00:56.856 --> 00:01:01.144
использовала существующий протокол, в частности протокол пограничного шлюза,

19
00:01:01.144 --> 00:01:04.561
чтобы диктовать или контролировать решения маршрутизации, или решения о пересылке

20
00:01:04.561 --> 00:01:09.270
, которые были приняты маршрутизаторами, говорящими AGP в магистральной сети.

21
00:01:09.270 --> 00:01:14.625
Затем мы рассмотрим, как появление открытого оборудования обеспечило гораздо более

22
00:01:14.625 --> 00:01:20.089
широкое внедрение раздельного управления сетями с коммутацией пакетов.

23
00:01:21.600 --> 00:01:24.820
Итак, сначала напомним себе, почему раздельный контроль - хорошая идея.

24
00:01:26.040 --> 00:01:28.308
Во-первых, это обеспечивает более быстрые инновации, так как

25
00:01:28.308 --> 00:01:31.610
логика управления напрямую не связана с оборудованием.

26
00:01:31.610 --> 00:01:36.362
Во-вторых, он позволяет контроллеру потенциально видеть общесетевое представление,

27
00:01:36.362 --> 00:01:41.450
тем самым упрощая вывод и объяснение поведения сети.

28
00:01:41.450 --> 00:01:43.990
Наконец, наличие отдельного канала управления

29
00:01:43.990 --> 00:01:46.200
позволяет иметь отдельный программный

30
00:01:46.200 --> 00:01:49.410
контроллер, что

31
00:01:49.410 --> 00:01:51.620
значительно облегчает внедрение новых сервисов в сеть.

32
00:01:53.000 --> 00:01:55.211
Давайте рассмотрим три различных способа

33
00:01:55.211 --> 00:01:59.560
, которые были разработаны для управления сетями с коммутацией пакетов.

34
00:01:59.560 --> 00:02:02.464
Первый экземпляр отдельного канала управления для

35
00:02:02.464 --> 00:02:07.630
сетей с коммутацией пакетов вышел из рабочей группы по разработке Интернета.

36
00:02:07.630 --> 00:02:10.080
В виде протокола СИЛС.

37
00:02:10.080 --> 00:02:12.440
Протокол был впервые стандартизирован в 2003 году.

38
00:02:12.440 --> 00:02:17.165
И было три реализации этого конкретного стандарта.

39
00:02:17.165 --> 00:02:21.066
Стандартные по существу определяемые протоколы,

40
00:02:21.066 --> 00:02:26.170
позволяющие нескольким элементам управления управлять элементами пересылки.

41
00:02:26.170 --> 00:02:29.870
Которая, по сути, отвечала бы за пересылку пакетов

42
00:02:29.870 --> 00:02:35.230
, измерение, формирование, классификацию трафика и так далее.

43
00:02:35.230 --> 00:02:39.090
Таким образом, идея заключалась в том, что переключатели или элементы пересылки могут управляться. По

44
00:02:39.090 --> 00:02:43.910
стандартному каналу управления, называемому интерфейсом FORCES.

45
00:02:43.910 --> 00:02:46.460
И, может быть несколько таких контроллеров,

46
00:02:46.460 --> 00:02:49.080
контролирующих поведение пересылки, этих элементов пересылки.

47
00:02:50.120 --> 00:02:51.130
Итак, это все хорошо и хорошо.

48
00:02:51.130 --> 00:02:55.300
И, в некоторых случаях это выглядит очень похоже на стандарт открытого потока, который мы знаем сегодня.

49
00:02:55.300 --> 00:02:58.410
Но проблема, связанная с этим подходом, заключалась в том

50
00:02:58.410 --> 00:03:03.230
, что он требовал стандартизации, принятия поставщиками и развертывания нового оборудования.

51
00:03:03.230 --> 00:03:09.270
И эти конкретные препятствия были теми же препятствиями, которые были мотивацией для некоторых

52
00:03:09.270 --> 00:03:13.840
из предыдущих работ, таких как активные сетевые проекты, которые мы рассматривали.

53
00:03:17.290 --> 00:03:19.942
Другой подход заключался в том, чтобы по существу использовать

54
00:03:19.942 --> 00:03:23.608
существующие протоколы в качестве каналов управления, главным образом

55
00:03:23.608 --> 00:03:26.806
перехватывая существующие протоколы маршрутизации, для отправки

56
00:03:26.806 --> 00:03:29.961
управляющих сообщений элементам пересылки.

57
00:03:29.961 --> 00:03:34.740
Такой подход был принят платформой управления маршрутизацией.

58
00:03:34.740 --> 00:03:39.745
Идея заключалась в том, что каждая автономная система или независимая сеть

59
00:03:39.745 --> 00:03:44.211
может иметь платформу управления маршрутизацией или RCP, которая будет вычислять

60
00:03:44.211 --> 00:03:47.830
маршруты от имени маршрутизаторов, а затем использовать существующие

61
00:03:47.830 --> 00:03:53.050
протоколы BGP для передачи этих маршрутов маршрутизаторам, так что идея.

62
00:03:53.050 --> 00:03:56.110
Было ли, что вычисления произойдут здесь, в RCP.

63
00:03:57.280 --> 00:04:02.784
Но после вычисления маршрутов результаты этих вычислений будут

64
00:04:02.784 --> 00:04:08.370
перенесены в таблицы пересылки маршрутизаторов стандартными протоколами маршрутизации.

65
00:04:08.370 --> 00:04:11.117
Таким образом, эти маршрутизаторы

66
00:04:11.117 --> 00:04:13.730
были под впечатлением, они просто разговаривали с любым старым маршрутизатором, но на

67
00:04:13.730 --> 00:04:15.941
самом деле они разговаривали с умным боксом

68
00:04:15.941 --> 00:04:20.150
, который фактически вычислял маршруты от их имени.

69
00:04:20.150 --> 00:04:25.470
Использование существующих протоколов In-Band для управления сетью с коммутацией пакетов

70
00:04:25.470 --> 00:04:30.350
эффективно облегчает переход от статус-кво.

71
00:04:30.350 --> 00:04:35.580
В то, где все управление централизовано, в определенной сети.

72
00:04:36.810 --> 00:04:40.172
RCP эффективно использовал BGP в качестве канала управления

73
00:04:40.172 --> 00:04:44.518
, так что элементы пересылки думали, что они

74
00:04:44.518 --> 00:04:47.798
разговаривают только с другим маршрутизатором, но

75
00:04:47.798 --> 00:04:51.920
на самом деле все смарты для сети были централизованы в одной точке.

76
00:04:53.810 --> 00:04:58.520
Этот подход несколько упрощает развертывание, так как он не

77
00:04:58.520 --> 00:05:03.420
требует стандартизации на новом наборе протоколов управления.

78
00:05:03.420 --> 00:05:07.350
Однако проблема, связанная с этим подходом, заключается в том, что контроль

79
00:05:07.350 --> 00:05:13.660
над сетью ограничен тем, что могут поддерживать существующие протоколы, такие как BGP.

80
00:05:13.660 --> 00:05:17.659
Таким образом, RCP был ограничен, потому что все, что

81
00:05:17.659 --> 00:05:21.286
он мог сделать, это контролировать решения о маршрутизации BGP

82
00:05:21.286 --> 00:05:24.727
, когда на самом деле сетевой оператор может

83
00:05:24.727 --> 00:05:28.210
захотеть управлять гораздо более широким диапазоном поведения.

84
00:05:29.670 --> 00:05:32.760
В конечном счете, архитектура все еще оказалась полезной.

85
00:05:32.760 --> 00:05:36.819
И версия RCP в настоящее время работает

86
00:05:36.819 --> 00:05:41.670
по крайней мере в одной большой сети back bone сегодня, чтобы сделать такие вещи, как

87
00:05:41.670 --> 00:05:48.600
автоматическое перенаправление трафика для инцидентов безопасности или очистки трафика, но

88
00:05:48.600 --> 00:05:56.170
тем не менее, спектр приложений, которые могут поддерживать что-то вроде RCP.

89
00:05:56.170 --> 00:06:00.440
По-прежнему несколько относительно ограничен по сравнению с тем, что

90
00:06:00.440 --> 00:06:04.870
может быть возможно с общей отдельной плоскостью управления.

91
00:06:08.010 --> 00:06:12.784
Настройка оборудования в плоскости данных потенциально упрощает

92
00:06:12.784 --> 00:06:17.289
поддержку гораздо более широкого спектра приложений в плоскости управления.

93
00:06:18.750 --> 00:06:21.368
Первым проектом, который реализовал это, был

94
00:06:21.368 --> 00:06:25.603
проект Ethane, который представил сетевую архитектуру для

95
00:06:25.603 --> 00:06:29.530
предприятия, что позволило прямое применение единой

96
00:06:29.530 --> 00:06:34.320
мелкозернистой политики сети на так называемом контроллере домена.

97
00:06:35.500 --> 00:06:39.130
Контроллер домена будет вычислять таблицы потока. Он

98
00:06:39.130 --> 00:06:43.365
должен быть установлен в каждом из коммутаторов предприятия

99
00:06:43.365 --> 00:06:48.120
на основе политик контроля доступа, определенных на контроллере домена.

100
00:06:49.690 --> 00:06:53.360
Ethane требовал развертывания пользовательских коммутаторов.

101
00:06:53.360 --> 00:06:56.363
И некоторые из

102
00:06:56.363 --> 00:07:00.510
них были реализованы на основе OpenWRT, NetFPGA и Linux.

103
00:07:00.510 --> 00:07:04.070
Проблема такого подхода, конечно, заключается в том, что

104
00:07:04.070 --> 00:07:08.320
он требует пользовательских коммутаторов, поддерживающих протокол Ethane.

105
00:07:10.250 --> 00:07:14.990
То, что мы ищем, так это то, что дает нам лучшее из обоих миров.

106
00:07:14.990 --> 00:07:17.650
Что-то, что может работать на существующих

107
00:07:17.650 --> 00:07:22.750
протоколах, но не потребует настройки оборудования.

108
00:07:22.750 --> 00:07:26.220
Ответ на этот вопрос был OpenFlow.

109
00:07:26.220 --> 00:07:29.080
И здесь идея заключалась в том, чтобы

110
00:07:29.080 --> 00:07:34.520
в основном использовать возможности существующего оборудования и открыть их.

111
00:07:34.520 --> 00:07:37.460
Таким образом, стандартный протокол управления

112
00:07:37.460 --> 00:07:40.440
может контролировать поведение этого оборудования.

113
00:07:42.890 --> 00:07:46.674
В OpenFlow отдельный контроллер взаимодействует

114
00:07:46.674 --> 00:07:49.842
с таблицей потока коммутатора, чтобы установить

115
00:07:49.842 --> 00:07:53.450
записи таблицы переадресации в коммутатор, которые

116
00:07:53.450 --> 00:07:57.200
контролируют поведение переадресации сети.

117
00:07:59.000 --> 00:08:05.305
Поскольку большинство коммутаторов уже реализовали таблицы потоков, единственное, что

118
00:08:05.305 --> 00:08:11.416
необходимо было для того, чтобы сделать OpenFlow реальностью, было убедить поставщиков коммутаторов

119
00:08:11.416 --> 00:08:17.236
открыть интерфейс для этих таблиц потока, чтобы отдельный программный

120
00:08:17.236 --> 00:08:23.290
контроллер мог диктовать, что будет заполнено в этих таблицах потока.

121
00:08:25.770 --> 00:08:29.130
Итак, что мы узнали об управлении сетью в этом уроке?

122
00:08:31.050 --> 00:08:34.762
Один из уроков заключается в том, что управление и плоскость данных обязательно должны быть

123
00:08:34.762 --> 00:08:38.090
разделены, потому что вертикально интегрированные коммутаторы

124
00:08:38.090 --> 00:08:41.470
очень затрудняют внедрение новых плоскостей управления.

125
00:08:41.470 --> 00:08:45.110
В некотором смысле FORCES выглядит очень похожим на OpenFlow.

126
00:08:45.110 --> 00:08:48.802
Но поскольку это потребовало новой стандартизации и принятия, а также

127
00:08:48.802 --> 00:08:53.330
изменений в аппаратном обеспечении, развертывание в конечном итоге стало очень сложным.

128
00:08:54.630 --> 00:08:59.990
Второй урок заключается в том, что использование существующих протоколов упрощает развертывание.

129
00:08:59.990 --> 00:09:03.240
Но это также ограничивает то, что можно сделать, и мы видели это в RCP.

130
00:09:05.150 --> 00:09:08.654
Наконец, мы увидели, что открытое оборудование может позволить

131
00:09:08.654 --> 00:09:11.939
развязать контроль и фактически может стимулировать принятие, и

132
00:09:11.939 --> 00:09:15.151
это потенциально одна из причин, которые сделали OpenFlow

133
00:09:15.151 --> 00:09:19.560
настолько невероятно успешным по сравнению с этими другими аналогичными предложениями.