Активные сети

by Sasha Shkrebets last modified Feb 06, 2023 12:53 PM
Активные сети (Active Networks, AN), причины возникновения и технологии стоящих за ними. Связь активных сетей с SDN, преемственность.

Продолжаем изучение истории SDN.

На этом уроке мы поговорим про активные сети (Active Networks, AN). Мы поговорим о том, что такое активные сети,
о причинах возникновения активных сетей, и о технологиях стоящих за ними. Мы также поговорим о том, как связаны активные сети с SDN, а также о том, что унаследовали SDN от AN.

На предыдущем уроке мы говорили об истории централизованного управления сетью, которое использовали по крайней мере с 80-х  в пункте управления сетью  компании  АТ&Т

Сегодня мы собираемся изучить причины появления SDN и их истоках в проектах активных сетей в 90-х.

Что такое активные сети?

Активные сети - это сети в которых коммутаторы выполняют определенные вычисления над сетевыми пакетами при их пересылке.

Несколько примеров, представьте, что один маршрутизатор или каждый маршрутизатор в сети совершает некоторые действия, обусловленные программой, с пакетами, которые проходят через маршрутизатор.

Промежуточные устройства (middleboxes) так же пример активных сетей.

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

Откуда появились активные сети?

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

Так же было замечено, что сложно внедрять новые сетевые услуги по мере их разработки.

Короче говоря, мотивацией для развития активных сетей было желание ускорить инновации. Замечено, что инновации требуют консенсуса и время, которое потребуется пройти от работающего прототипа, до окончательного внедрения технологии внедрения в реальных сетях может занимать десятилетия, потому что требуется стандартизировать, организовать производство нового оборудования и дальнейшая отладка и внедрение в работающих сетях может длиться буквально бесконечно.

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

Если вы можете поместить активные узлы в сеть, где маршрутизаторы могут скачать и реализовать новые услуги в существующей инфраструктуре - это позволяет внедрять инновации пользователям.

Итак, основная идея в том, что сообщение или пакет могли бы нести не только данные, но и инструкции, что делать с этими данными.

Эти активные маршрутизаторы, которые могут выполнять произвольные операции, могут сосуществовать с традиционными, которые могут только пересылать пакеты.

Каждый из этих программируемых коммутаторов, мог бы осуществлять дополнительную обработку, в дополнению к пересылке пакетов.

Таким образом есть как потребность, так и производители, которые вместе делают активные сети востребованными в данный момент.

С одной стороны распространение  прокси, транскодеров и т.п. приводит к большому количеству специализированных решений, которые решают потребности пользователей в обработке пакетов. Проблематика или цель активных сетей заменить множество специфичных решений более универсальным.

С другой стороны предложение от производителей. В свое время, было множество исследований и разработок для поддержки безопасного исполнения переносимого кода. В частности, появились Java апплеты и обеспечили возможность разрабатывать переносимый код, который бы работал в любом месте и это позволило переносить ПО, что оказало поддержку для некоторых типов активных сетей.

Так же разрабатывалась поддержка со стороны ОС. Scout OS создана для поддержки сетевой коммуникация.

Были созданы новые технологии, позволяющие безопасный доступ к низкоуровневым ресурсам, и SPIN обеспечивающая доверенный код, или предоставляющая технологии, позволяющие создать доверенный код.

Итак, есть два разных подхода к активным сетям.

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

Чуть позже мы рассмотрим Capsules более детально.  Но есть другой подход, который выглядит более знакомым для нас. И он выглядит именно как подход SDN,  вот в чем идея:

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

Теперь давайте посмотрим на Capsules, эта технология фактически расширяет существующий заголовок пакета в добавление к обычному заголовку IP пакета с вашими данными.

Рассмотрим заголовок AN, в данном случае заголовок  ANTS. Он был разработан в МТИ и этот заголовок фактически имел несколько дополнительных полей. Одно было поле типа, которое определяло инструкцию для исполнения в конкретном коде, поле  Предыдущий адрес,  обозначао узел, где взять инструкцию если ее нет на текущем узле. Поля с аргументами позволяют пакету передать параметры в исполняемый код, и в конце, конечно, собственно сами полезные данные.

Итак, некоторые наиболее заметные проекты в области  AN.

Один из них был ANTS, который мы рассмотрели только что И он фактически использовал подход Capsules в пакете, которые должны были содержать фактически Java программы внутри пакетов.

Естественно, это создало ограничения для обеспечения QoS и для решения этого университет Аризоны создал  нечто названое Joust JVM, которая обеспечивала лучшую производительность для сценариев AN.

Еще была программа Switchware в университете Пенсильвании, по разработке программируемого коммутатора и скриптового языка, поддерживающего вызовы свитчлетов.

Проект Smart Packets в BBN, нацеленный на применении подхода AN к проблемам управления сетями.

Open Signalling в Колумбийском университете разработали язык NetScript который позволял разработчикам создавать процедуры обработки данных и описывать конвееры для обработки потоков данных. Позже в курсе мы рассмотрим некоторые современные программируемые плоскости коммутации, которые похожи на Open Signalling

И наконец проект Tempest из Кембриджа, где изобрели нечто названное свитчлеты, являвшимися программируемыми виртуальными коммутаторами и мы рассмотрим их подробнее на следующей лекции.

Итак, что же случилось с активными сетями? Эта технология появилась почти 25 лет назад. Почему хотя бы некоторые из этих идей до сих пор не реализованы?

Ну, во-первых - они появились не вовремя.  В то время не было понятного применения для этого типа программирования. Как оказалось, и мы увидим это в рамках курса, одно из самых востребованных применений для SDN это ЦОД и облака. Но в то время ЦОД и облаков просто не было, таким образом не было понятного применения для активных сетей. Как минимум не было  в ближайшей перспективе. В добавок, аппаратная поддержка не дешева, все используют специальные интегральные схемы (ASIC) для поддержки таких технологий. Сейчас есть больший выбор для реализации программируемой плоскости коммутации, такой как TCAM, ПЛИС.

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

Будет ли это сделано за счет Capsules или наоборот, за счет программируемого коммутатора, это менее важно, чем  обеспечение программируемости, гибкости в инфраструктуре.

Так же слишком много внимание уделяется пользователям, как вы и я, сидящими за своими компьютерами, или домашними компьютерами, как программистам. в отличии от этого в идее SDN программистом видится администратор сети, или администратор сетевой услуги. Те люди, которые внедряют новые технологии в сети.

И наконец, очень много внимания уделяется совместимости с нынешними реализациями и внедрениями.

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

Итак, давайте на минутку поразмышляем о влиянии активных сетей на SDN. Какие уроки мы можем извлечь из идеи активных сетей?

Ну во-первых, была идея программирования функционала сети для развития инноваций. Постановка задачи, или мотивация, практически такая же как в SDN, и истоки ведут к активным сетям.

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

Эта идея фактически выросла из концепции активных сетей и мы встречаем ее снова и снова, и снова, в таких проектах как Planetlab, Flowvisor, GENI.

Даже сейчас, весь мир обсуждает как объединить  SDN и middleboxes.

Это все имеет корни из идей пришедших из концепции активных сетей.

Напоследок, еще одно замечание про middleboxes. Очень важно, что идея активных сетей уделяла много внимания middleboxes. Одна из задач активных сетей была в развитии различных типов промежуточных узлов и видение универсальной архитектуры. И сейчас мы видим то же видение реализуемое в разных SDN проектах И, возможно, важно оглянуться назад, обратить внимание на некоторые работы в области  AN, что бы убедиться может ли полученный опыт быть использован для интеграции SDN с middleboxes.

Navigation