Потоковая маршрутизация и открытый поток

Question

Это, возможно, не типичный вопрос о переполнении стека.

Мой коллега размышлял, что маршрутизация на основе потоков будет следующей большой вещью в сети. Openflow предоставляет технологию использования недорогих коммутаторов в крупных приложениях, ИТ-центрах и т. Д .;замена коммутаторов и маршрутизаторов Cisco, HP и т. д.Теория заключается в том, что вы можете создать иерархию этих переключателей openflow с простой настройкой, например.нет связующего дерева.Открытый поток направит каждый поток к соответствующему порту коммутатора / коммутатора, используя только знание иерархии коммутаторов (без маршрутизаторов).Решение состоит в том, чтобы сэкономить деньги предприятий и упростить сетевое взаимодействие.

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

Answer 1

OpenFlow - это исследовательский проект из Стэнфордского университета под руководством профессора Ника МакКауна . В оригинальной исследовательской работе цель OpenFlow заключалась в том, чтобы дать исследователям возможность «запускать экспериментальные протоколы в сетях, которые они используют каждый день». В течение многих лет исследователи сетей сталкивались с почти невозможной задачей развертывания и оценки своих идей в реальных сетях с использованием реальных коммутаторов Ethernet и IP-маршрутизаторов. Трудность заключается в том, что настоящие коммутаторы и маршрутизаторы таких компаний, как Cisco, HP и другие, являются закрытыми проприетарными блоками, которые реализуют стандартные «протоколы», такие как связующее дерево Ethernet и OSPF. Есть бизнес-причин , почему Cisco и HP не позволят вам запускать программное обеспечение на своих коммутаторах и маршрутизаторах; нет технической причины. OpenFlow был изобретен для решения проблемы людей: если Cisco не хочет, чтобы вы запускали код на своем коммутаторе, возможно, они хотя бы могут предоставить очень узкий интерфейс, позволяющий удаленно настраивать их коммутатор, и этот узкий интерфейс называется OpenFlow.

Насколько мне известно, более десятка компаний в настоящее время внедряют поддержку OpenFlow для своих коммутаторов. Некоторые, такие как HP, предоставляют программное обеспечение OpenFlow только для исследовательских целей. Другие, такие как NEC, фактически предлагают коммерческую поддержку.

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

Причина, по которой OpenFlow чаще всего обсуждается в контексте корпоративных сетей, заключается в том, что OpenFlow вырос из предыдущего исследовательского проекта под названием Ethane , который использовал механизм удаленного программирования коммутаторов OpenFlow в сети предприятия для того, чтобы централизовать политику безопасности. Этан, и, соответственно, OpenFlow, привел непосредственно к двум начинающим компаниям: Nicira , основанная Martin Casado , и Big Switch Networks , основанная Гвидо Аппенцеллер . Было бы проще реализовать этаноподобную систему, если бы все коммутаторы в сети поддерживали OpenFlow.

С корпоративными сетями тесно связаны сети центров обработки данных, сети, которые соединяют тысячи и десятки тысяч серверов в таких компаниях, как Google, Facebook, Microsoft, Amazon.com и Yahoo !. Одна проблема с Ethernet заключается в том, что он не масштабируется до такого количества серверов в одной сети уровня 2. Мы попытались решить эту проблему в исследовательском проекте под названием PortLand . Мы использовали OpenFlow для облегчения программирования переключателей с центрального контроллера, который мы назвали Fabric Manager. Мы выпустили исходный код PortLand как открытый исходный код.

Однако мы также обнаружили ограничение функциональности OpenFlow. В другом проекте по исследованию сетей центров обработки данных под названием Helios мы не смогли использовать OpenFlow, поскольку он не предоставлял механизм для объединения нескольких портов коммутатора в группу агрегации каналов (LAG). Можно предположить, что спецификацию OpenFlow можно расширять до бесконечности, пока не станут доступны все возможные функции коммутатора.

Существуют и другие сети, такие как сети доступа в Интернет, магистральные интернет-сети, домашние сети, беспроводные сети, сотовые сети и т. Д. Исследователи пытаются выяснить, как OpenFlow вписывается во все эти рынки. На самом деле сводится к вопросу "какую проблему решает OpenFlow?" Этан приводит аргументы в пользу корпоративных сетей, но я еще не видел убедительных аргументов в пользу сетей любого другого типа. OpenFlow может быть следующей большой вещью, или это может закончиться тем, что «не решайте проблему людей с техническим решением».

Answer 2

Чтобы оценить будущее сетей на основе потоков и OpenFlow, вот способ подумать об этом.

1. Все начинается с кремниевых трендов: закон Мура (2Х транзисторов за 18-24 месяца) и коррелированное, но более медленное улучшение пропускной способности ввода / вывода, доступного для одного чипа (примерно в 2 раза каждые 30-36 месяцев). ). Теперь вы можете купить полнофункциональные одночиповые коммутаторы 10GbE с 64 портами и чипами, которые имеют сочетание портов 40GbE и 10GbE с сопоставимой общей пропускной способностью ввода / вывода.

2. Существует множество способов физически соединить их в сетку (игнорируя ограничения без петель связующего дерева и способ, которым Ethernet изучает MAC-адреса). В мире высокопроизводительных вычислений (HPC) была проделана большая работа по созданию кластеров с InfiniBand и другими протоколами с использованием ячеек небольших коммутаторов для подключения к вычислительным серверам. Теперь это применяется к сетям Ethernet. Геометрия топологии CLOS или жирного дерева позволяет использовать двухэтапную сетку с большим количеством портов. Таким образом, математика такова: где n - количество портов на чип, количество устройств, которые вы можете подключить в двухэтапной сетке, - (n * 2) / 2, а количество, которое вы можете подключить в трехэтапной схеме. Стадия сетки равна (n * 3) / 4. В то время как при использовании стандартного связующего дерева и обучения протокол связующего дерева отключит многолучевые связи на втором этапе, большинство поставщиков коммутаторов Ethernet имеют своего рода протокол агрегации каналов с несколькими шасси, который преодолевает ограничение многолучевого распространения. Есть также стандарты работы в этой области. Хотя это может быть неочевидно, подавляющее большинство схем агрегации каналов распределяет трафик, поэтому все кадры любого данного потока выбирают один и тот же путь. Это сделано для того, чтобы минимизировать неупорядоченные кадры, чтобы они не сбрасывались каким-либо протоколом более высокого уровня. Они могли бы назвать это «мультиплексированием на основе потоков», но вместо этого они называют это «агрегацией каналов».

3. Хотя дьявол кроется в деталях, существует множество операторов и поставщиков центров обработки данных, которые пришли к выводу, что им не нужно иметь большие многослотовые коммутаторы шасси на уровне агрегации / ядра для подключения к серверу, вместо этого используя сетки недорогих переключателей 1U или 2U.
4. Люди также пришли к выводу, что в конечном итоге вам понадобится какая-то станция управления для настройки конфигурации всех коммутаторов. Опять же, опираясь на опыт работы с HPC и InfiniBand, они используют так называемый контроллер InfiniBand. В мире телекоммуникаций большинство сетей электросвязи эволюционировали, чтобы отделить управление и часть плоскости управления от блоков, по которым передается трафик данных.

Подводя итог вышеприведенным пунктам, сети коммутаторов Ethernet с внешней плоскостью управления с многолучевым трафиком, в котором потоки хранятся в порядке, являются эволюционными, а не революционными и, вероятно, станут мейнстримом. По крайней мере, одна крупная компания, Juniper, сделала публичное заявление об одобрении этого подхода. Я бы назвал все эти «потоковой маршрутизацией».

Несмотря на проприетарные подходы Juniper и других производителей, эта область требует стандартов. Open Networking Foundation (ONF) был основан для продвижения стандартов в этой области, начиная с OpenFlow. В течение нескольких месяцев шестьдесят с лишним членов ONF будут отмечать свой первый год. Я считаю, что каждый участник заплатил десятки тысяч долларов за вступление. Хотя у протокола OpenFlow есть пути, прежде чем он получит широкое распространение, он имеет реальный импульс.

Answer 3

Больше контекста по SDN, в котором обсуждается инициатива IETF по SDN и OpenFone ONF.Работа в сочетании - это мощная комбинация http://bit.ly/A8xYso

Answer 4

Отличный вид OpenFlow Саймона Кросби

http://community.citrix.com/display/ocb/2011/03/21/The+Rise+of+the+Software+Defined+Network

Answer 5

@ Натан: OpenFlow 1.1 фактически добавляет некоторые примитивы, которые позволяют использовать несколько ссылок через Multipath Proposal .

Answer 6

Натан, Отличный исторический отчет и обзор openflow. Спасибо!

Вы затронули те моменты, которые я обдумывал, почему Openflow может не получить широкого распространения. Так как он был разработан, чтобы быть открытым, чтобы позволить исследователю возможность запускать экспериментальные протоколы и не обязательно быть «совместимым» с крупными игроками Cisco / HP / и т.д. это ставит себя на нишевый (хотя и потенциально большой) рынок, подробнее об этом позже. И, как вы заявили, он получил некоторое распространение в «облачных дата-центрах (CDC)», например. Google, Facebook и т. д., поскольку им необходимо использовать экспериментальные протоколы, чтобы получить конкурентное преимущество или оптимизировать свои приложения.

Как вы заявили, некоторые поставщики коммутаторов добавили возможность openflow, чтобы извлечь выгоду из нишевой потребности в научных кругах и потенциально продавать в CDC; Google, Facebook. Это потенциально большой рынок (или пузырь, если вы пессимистичны).

Проблема, которую я вижу, состоит в том, что большая часть рынка (80% и более) - это корпоративные ИТ-центры обработки данных. Требования здесь для стабильной, совместимой сети. Открыть и дешевле было бы неплохо, но не за счет прежних.

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

Итак, я пришел к выводу, что, кроме исследований и, возможно, CDC (google, facebook), рынок довольно маленький. Я полагаю, что если исследователи используют openflow, чтобы придумать лучший протокол для, скажем, агрегации каналов или управления перегрузками, то в конечном итоге Cisco и HP предоставят их в своем стандартном предложении, потому что его потребуют клиенты. Таким образом, openflow может оказывать влияние на рынок (через исследовательское сообщество), но он не будет разрушителем рынка.

Согласны ли вы с моими выводами? Спасибо за ваш вклад.