Search results

Мы продолжаем работу над модулем программируемых плоскостей данных, а также продолжаем обсуждение того, как сделать программируемые плоскости данных более масштабируемыми. В этой части урока мы сосредоточимся на методах, которые могут быть использованы для того, чтобы сделать оборудование более программируемым. Прежде чем мы перейдем к возможностям текущего оборудования и что мы можем сделать, чтобы сделать плоскость данных более программируемым, давайте сначала рассмотрим то, что мы действительно хотим от SDN и рассмотрим, действительно ли текущее оборудование обеспечивает желаемые функции, которые мы хотели бы от SDN. Одной из основных целей SDN является поддержка протокольной обработки. Другими словами, мы должны иметь возможность обрабатывать трафик, путешествующий по сети, независимо от конкретных протоколов управления. Мы должны иметь возможность контролировать поведение сети и перенаправлять наши сетевые устройства в полевых условиях без переразвертывания оборудования, и мы хотели бы, чтобы эти функции были реализованы с помощью быстрых микросхем с низким энергопотреблением.

We are continuing the module on programmable data planes and we are also continuing our discussion of how to make programmable data-planes more scalable. In this part of the lesson we'll focus on techniques that can be used to make hardware more programmable.

В этом уроке мы расскажем о протокольной независимой обработке пакетов. Я опишу необходимость в протокольной независимой обработке пакетов, и мы расскажем об этой концепции довольно подробно в контексте двух примеров. Я сосредоточусь в основном на P4. Программирование не зависящих от протокола пакетных процессоров. Там , где это уместно, я также принесу мотивацию и концепции из другого связанного с этим усилия под названием Protocol Oblivious За последние пять лет количество заголовков в спецификации OpenFlow увеличилось.

In this lesson we'll talk about Protocol-Independent Packet Processing. I'll describe the need for Protocol-Independent Packet Processing, and we'll talk over this concept in some detail in the context of two examples. I will focus mostly on P4.

В этой краткой лекции я представлю краткий пример программного переключателя P4 в действии. Коммутатор P4 состоит из трех основных частей: файла, определяющего формат заголовка, файла, определяющего парсер, и файла, определяющего модель поведения с потоком управления коммутатором. Я дам краткий обзор этих трех компонентов. А затем мы быстро посмотрим на переключатель P4 в действии.

In this brief lecture, I'll present a brief example of the P4 software switch in action. A P4 switch has three main parts, a file that defines the header format, a file that defines the parser, and a file that defines behavior model with a control flow over the switch.

В этой лекции мы расскажем о некоторых программируемых плоскостях данных и роли промежуточного представления в компиляции языков высокого уровня, таких как P4, вплоть до различных аппаратных целей. Во-первых, давайте поговорим о том, почему нам нужна программируемая плоскость данных. Новые устройства плоскости данных обеспечивают все более гибкое управление процессом обработки пакетов. С точки зрения определения пользовательских форматов заголовков пакетов, изменение количества этапов в конвейере обработки пакетов. Добавление состояния, например таблиц, на различные этапы конвейера и определение новых функций плоскости данных для обработки пакетов. Фиксированный характер устройств с открытым потоком затрудняет добавление новых протоколов или удаление протоколов, если они больше не нужны.

In this lecture we'll talk about some programmable data planes and the role of an intermediate representation in compiling high level languages like P4 down to various hardware targets. First, let's talk about why we need a programmable data plane. Emerging data plane devices enable increasingly flexible control, on how they process packets.

This module is relatively independent from some of the other modules, as programmable data planes involve new types of technology. Still, you should by now have a very good understanding of SDN-based control and virtualization. OpenFlow's design was somewhat of an accident of the hardware support that was available at the time. More recently, people are exploring how programmable hardware can help us design a control protocol with the benefit of being able to change the data plane. Задачи обучения Describe why programmable data planes are needed. Discuss the limitations of OpenFlow and how programmable data planes can address some of these limitations. Appreciate some of the design decisions associated with programmable data planes. Compare the tradeoffs between hardware and software programmable data planes (i.e., flexibility vs. performance).

Мы запускаем новый модуль по программированию SDN, который имеет четыре урока. В этом модуле мы сначала рассмотрим мотивацию программирования SDN, затем рассмотрим языки программирования для SDN. В-третьих, мы поговорим о том, как использовать языки программирования для создания управления SDN. И, наконец, мы поговорим о том, как увеличить существующие сетевые контроллеры для обработки более сложных событий высокого уровня, таких как события безопасности, события балансировки трафика и т.д.