Некоторые мысли по возможной модернизации сетей

[user_anonymous]

========================================================

Некоторые мысли по возможной модернизации сетей.

 

Изначально локальные сети задумывались как большое количество достаточно

равноправных узлов, и при этом не учитывались никакие особенности их

топологии. В реальности же мы видим, что есть участники сетей, на долю

которых приходится большая часть трафика. Это, например, разного рода

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

произвести оптимизацию сети с целью упрощения управляемости, снижения

нагрузки на сетевое оборудование, повышения качества обслуживания и

оптимизации полосы пропускания.

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

количество хостов, к которым идет большая часть трафика, а также вменяемый

администратор, который эти хосты знает.

В коммутаторах пересылка пакетов между портами происходит на основе таблицы

коммутации, в которой выполняется поиск соответствия между адресом и портом.

Очевидно, что если мы имеем сеть с подобным неравновесным распределением

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

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

поиск в таблице коммутации. И вот тут можно произветси хорошую оптимизацию.

Для этого необходимо ввести понятие канала. КАНАЛ - это запись, имеющая

определенный НОМЕР_КАНАЛА (небольшое число) и сцепленную с ним информацию об

адресе назначения, приоритетности трафика и его ширине. Номера каналов

должны быть уникальными в пределах всего сегмента Ethernet. Параметры канала

назначаются администратором на основе его знаний об особенностях

распределения трафика в сети, ее топологии и требованиям по качеству

обслуживания трафика в канале. Любой порт коммутатора с точки зрения канала

может находится в одном из следующих состояний:

0 - Порт выключен

1 - Порт включен и является точкой назначения канала

2 - Порт включен и является транзитным портом

3 - Порт включен и является абонентским портом

 

Все порты на любом коммутаторе изначально являются абонентскими.

Порт превращается в точку назначения канала по воле администратора, о чем

делается запись в конфигурации коммутатора. Затем коммутатор пересылает эту

информацию по всем имеющимся у него транзитным портам. Подключенные к нему

промежуточные коммутаторы также пересылают эту информацию по транзитным

портам следующим коммутаторам в дереве. На абонентские порты запись никогда

не пересылается и с них никогда не принимается информация о новой точке

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

администратор производит оптимизацию трафика в масштабе всей сети.

Теперь посмотрим, для чего все это делалось. Предположим, что абонентский

хост отправляет данные через абонентский порт на конечную точку канала.

Первоначально абонентский хост ничего не знает о канале. Как только свитч

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

Причем, в отличии от традиционной схемы, сначала идет поиск среди каналов, и

только потом в таблице коммутации. Если адрес назначения принадлежит каналу,

то фрейм маркируется в соответствии с номером канала, а клиентскому хосту

посылается информация о том, что передача ведется по каналу с определенным

номером. Все дальнейшие пакеты, идущие с клиентского хоста к цели, должны

маркироваться этим номером. А этот номер - не что иное, как индекс в массиве,

так что вместо поиска по таблице коммутации свитч выполняет только извлечение

из массива по индексу, что требует меньше ресурсов и времени. На основании

информации из записи о канале, коммутатор устанавливает величину полосы

пропускания и приоритет трафика. Если же пакет с клиентского хоста не

попадает ни в один из существующих каналов, то он доставляется до цели

традиционным способом с применением настроек для внеканальных пакетов.

Особенно здорово было бы сделать для таких пакетов низкую скорость передачи,

что моментально снизило бы нагрузку на сеть от вирусов, любителей торрентов и

ДВД-фильмов.

Если пакет с клиентского хоста идет с неверным номером канала, то он никуда

не передается, а на клиентский хост посылается сообщение об ошибке.

Если в точке назначения произошли каие-то изменения, либо истек таймаут, то

по сети рассылаются пакеты обновления информации о точке назначения либо о

ее ликвидации.

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

коммутаторы (особенно на агрегации), обеспечило бы качество обслуживания,

причем с привязкой к конкретным сервисам и при этом не сильно удорожило бы

сеть, так как для реализации схемы не требуются какие-либо выдающиеся

вычислительные мощности.

========================================================

 

Хотелось бы узнать ваше мнение по сабжу - реально ли это было бы так хорошо, как мне кажется, или я что-то неучел, не понимаю или забыл.

[Taras]

MPLS?

[user_anonymous]

MPLS?

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

Edited February 14, 2008 by user_anonymous

[Sonne]

Молодой человек вы про ATM что-нибудь вобще слышали?

Про полисниг? Про МПЛС?

 

Если же пакет с клиентского хоста не

попадает ни в один из существующих каналов, то он доставляется до цели

традиционным способом с применением настроек для внеканальных пакетов.

Голубиной почтой?

[user_anonymous]

Если же пакет с клиентского хоста не

попадает ни в один из существующих каналов, то он доставляется до цели

традиционным способом с применением настроек для внеканальных пакетов.

Голубиной почтой?

Вообще-то голубиная почта - это что-то новое в пересылке пакетов. ИМХО держать голубей для этих целей будет накладно. Гораздо дешевле было бы по традиции воспользоваться таблицей МАК-адресов :)

 

Насчет MPLS и АТМ - посмотрите на ценники и представьте, как вы ставите это на доступ. И платите за это железо из своего кармана. А реализация того, наброски чего я описал, лишь чуть-чуть подняла бы цену на железку класса продвинутой мыльницы.

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

Edited February 14, 2008 by user_anonymous

[LionSprings]

Вообще-то голубиная почта - это что-то новое в пересылке пакетов

Чегойт оно новое? Даже RFC есть соответствующее. RFC 1149 :)

Edited February 14, 2008 by LionSprings

[Прохожий]

На самом деле ничего такого, что влияло бы на цену здесь нет. Потому что стоимость поиска в таблице адресов с точки зрения как технической "стоимости", так и влияния не цену конечного продукта - исчезающе мала. Не во всякий микроскоп разглядишь :)

 

Если Вы где-то прочитали, что CAM (Content addressing memory) есть очень дорогая штука - да, факт, только нужно ее совсем немного. Основная стоимость свича - это даже не чипы...

[user_anonymous]

На самом деле ничего такого, что влияло бы на цену здесь нет. Потому что стоимость поиска в таблице адресов с точки зрения как технической "стоимости", так и влияния не цену конечного продукта - исчезающе мала. Не во всякий микроскоп разглядишь :)

 

Если Вы где-то прочитали, что CAM (Content addressing memory) есть очень дорогая штука - да, факт, только нужно ее совсем немного. Основная стоимость свича - это даже не чипы...

Хмм. Я не утверждаю, что я прав и ни в коей мере не претендую на истину в последней инстанции - как раз именно для того. чтобы понять, где я ошибаюсь и решил тут это запостить. Меня больше привлекла возможность объединить все вместе - очень красивая (и дешевая) просто картинка получилась, хотя и не без изъянов - например, на что еще никто не обратил внимания (не ткнул носом, если хотите :)) - так это на то, что канал в моей схеме односторонрий получается. Но вот представим картинку - есть сеть с поддержкой подобных каналов. На внутренние ресурсы делаются каналы по сотке или даже по гигабиту, а весь остальной трафик идет на десятке, и все это безо всяких АЦЛ и из одного места. Да еще и обновляется само. Да еще все это дешево. Разве плохо?

[Прохожий]

Да еще все это дешево. Разве плохо?

Дешево не будет. Долго объяснять почему, придется поверить. Это раз.

 

И второе: у Вас там есть чумовые слова "указывается администратором" - а чем больше руками делается - тем сложнее и менее надежно в эксплуатации.

 

Кстати, а чем, собственно, Вас имеющаяся модель QoS не устраивает?

[Nag]

Может подробную статью с картинками в обзор? ;-)

 

[MEF]

А как кос с будет работать с трафиком который в тунелях летает? РРОЕ или РРТР к примеру? Чтоб его разобрать, пакет, уже не коммутатор нужен.

[Sonne]

На самом деле ничего такого, что влияло бы на цену здесь нет. Потому что стоимость поиска в таблице адресов с точки зрения как технической "стоимости", так и влияния не цену конечного продукта - исчезающе мала. Не во всякий микроскоп разглядишь :)

 

Если Вы где-то прочитали, что CAM (Content addressing memory) есть очень дорогая штука - да, факт, только нужно ее совсем немного. Основная стоимость свича - это даже не чипы...

Хмм. Я не утверждаю, что я прав и ни в коей мере не претендую на истину в последней инстанции - как раз именно для того. чтобы понять, где я ошибаюсь и решил тут это запостить. Меня больше привлекла возможность объединить все вместе - очень красивая (и дешевая) просто картинка получилась, хотя и не без изъянов - например, на что еще никто не обратил внимания (не ткнул носом, если хотите :)) - так это на то, что канал в моей схеме односторонрий получается. Но вот представим картинку - есть сеть с поддержкой подобных каналов. На внутренние ресурсы делаются каналы по сотке или даже по гигабиту, а весь остальной трафик идет на десятке, и все это безо всяких АЦЛ и из одного места. Да еще и обновляется само. Да еще все это дешево. Разве плохо?

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

 

Для начала перейдите от нелепой макрохарактеристики полосы 100 Мбит или 1Гбит к конкретным тимингам пакетов и очередей. Уже на этом этапе придете к концепции очередей. Метки как способ коммутации реализованы в MPLS. Непонятно что вы называете внутренним каналом наиболее близко к этому термину virtual circuit из ATM. Неполохо было бы перед изобретением очередного велосипеда поинтересоваться архитектурой предыдущих моделей.

 

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

а) к сужению трубы (потери на смешивание и разделение)

б) к росту накладных расходов ( ресурсы на смешивание и разделение)

 

Так что задача одновременно классифицировать трафик и удешевить его передачу заведомо противоречива и может быть решена только принципиальным прорывом за грани привычного знания ( методика ТРИЗ), но не решается никаким добавлением шестеренок.

[user_anonymous]

А как кос с будет работать с трафиком который в тунелях летает? РРОЕ или РРТР к примеру? Чтоб его разобрать, пакет, уже не коммутатор нужен.

Честно говоря, не совсем уверен, правильно ли я понял этот вопрос. Если по моей задумке, то так как все там работает на L2, то ей пофигу на QoS вышестоящих протоколов - сначала обеспечивается канал с заданными параметрами по порту свича и связанному с ним мак-адресу (который может идти например до того же VoIP шлюза), а дальше уже дело протоколов высшего уровня, которые будут идти в этом канале. Тоесть допустим в случае с тем же войп шлюзом админ на свиче, к которому он подсоединен, прописал, что этот порт-точка окончания канала, информация тутже разошлась по всей сети и осела на всех коммутаторах. Когда кто-то посылает пакет к войп-шлюзу - берутся параметры из прописанной админом информации о скорости канала и приоритете трафика и в соответствии с ними в сеть посылаются пакеты. Промежуточные свичи на основе метки канала смотрят, какие параметры должны быть у пакета и посылают его дальше, пока он не дойдет до точки назначения. Тоже самое будет и с каналом, идущем к серверу доступа, и работать это будет совершенно независимо от того, какой трафик идет по каналу, есть ли там туннели или нету.

[MEF]

Млин не нада великов , оптика до дома и фсё щастье!

[user_anonymous]

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

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

 

Для начала перейдите от нелепой макрохарактеристики полосы 100 Мбит или 1Гбит к конкретным тимингам пакетов и очередей. Уже на этом этапе придете к концепции очередей. Метки как способ коммутации реализованы в MPLS. Непонятно что вы называете внутренним каналом наиболее близко к этому термину virtual circuit из ATM. Неполохо было бы перед изобретением очередного велосипеда поинтересоваться архитектурой предыдущих моделей.

А я, между прочим, интересовался. Помню, как в свое время про АТМ очень много писали в журнале "Сети" - все спорили, кто круче и что лучше, и кто же победит - дешевая труба или дорогая интеллектуальная сеть. И где он сейчас? Есть ли хоть одна домовая сеть, где бы клиентов подключали по АТМ? Да большинство людей даже слова то такого не слышали. потому что оборудование было дорогое. И дорогим умерло. А коммутация на основе меток из МПЛС - разве это плохо? Идея то хорошая. Но опять же - задумка была слишком универсальная и потому дорогая. Но если МПЛС слишком дорого для доступа - почему бы не взять у нее идеи, но приделать это к дешевому Ethernet?

 

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

а) к сужению трубы (потери на смешивание и разделение)

б) к росту накладных расходов ( ресурсы на смешивание и разделение)

Полностью согласен. Поэтому все дложно быть максимально просто. Поставить метку на пакет - просто. Дропать пакеты, идущие вне полосы или с превышением скорости - просто. При этом, если внимателно почитать мой первый пост, можно обнаружить, что расходы частично перекладываются на клиентское железо. Отсюда кстати и полосы в 10 и 100 МБит - для минимальной переделки драйверов сетевых карт. Сори, что не расписал это более явно - я думал, что это очевидно.

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

 

PS В конце-концов все это - лишь умственное упражнение. Так что не расстраивайтесь, даже если все это лишь очередной велосипед, то по крайней мере велосипед занимательный - вас же зацепило :)

 

[Sonne]

А я, между прочим, интересовался. Помню, как в свое время про АТМ очень много писали в журнале "Сети" - все спорили, кто круче и что лучше, и кто же победит - дешевая труба или дорогая интеллектуальная сеть. И где он сейчас? Есть ли хоть одна домовая сеть, где бы клиентов подключали по АТМ? Да большинство людей даже слова то такого не слышали. потому что оборудование было дорогое. И дорогим умерло. А коммутация на основе меток из МПЛС - разве это плохо? Идея то хорошая. Но опять же - задумка была слишком универсальная и потому дорогая. Но если МПЛС слишком дорого для доступа - почему бы не взять у нее идеи, но приделать это к дешевому Ethernet?

Дык МПЛС и есть попытка сделать именно то что вы делаете.

 

Поставить метку на пакет - просто. Дропать пакеты, идущие вне полосы или с превышением скорости - просто. При этом, если внимателно почитать мой первый пост, можно обнаружить, что расходы частично перекладываются на клиентское железо. Отсюда кстати и полосы в 10 и 100 МБит - для минимальной переделки драйверов сетевых карт. Сори, что не расписал это более явно - я думал, что это очевидно.

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

Тут две фундаментальные ошибки

 

1. Задача любого оператора первым делом стереть всю приоритезацию, которая не согласована ( читай оплачена ) клиентом. Вы думаете клиентское ПО честно пометет трафик в соответствии с нуждами оператора? Ничего подобного любая дырка у оператора будет немедленно вздрючена сотней вирусов, интернет-бустеров, оптимизаторов и прочей програмной херни, которая камня на камне не оставит от вашей благородной идеи.

Собственно сложность отделения вредного трафика оператором произрастает от огромного желания этого трафика замаскироваться под полезный.

 

2. Любое "якобы полезное" измение массовых стандартных вещей приведет к немедленному отторжению технологии потребителями. Попробуйте в отдельно взятой стране перевести движение с левосторонего на правосторонее, либо стандартизировать ширину ЖД колеи.

 

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

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

[Прохожий]

А коммутация на основе меток из МПЛС - разве это плохо? Идея то хорошая. Но опять же - задумка была слишком универсальная и потому дорогая.

Не слишком то она универсальная и вовсе не потому она дорогая. МПЛС, если разобраться, очередной мутант от попыток скрестить ужа с ежом, а пакетные технологии с канальными. Первый был - АТМ. И говорить, что МПЛС - это такая прямо панацея от всего - как минимум это значить жрать marketing bullshit и не знать, как это работает архитектурно. Другой вопрос, что нет достойной альтернативы, кроме PBT/MAC-IN-MAC, но это совсем другая история...

 

Зонни дело говорит, на самом деле. В Ваших идеях чувствуется недостаток знаний. Понятно, что ковчег построил любитель, а титаник - толпа профессионалов, но Ною сам Бог помогал :)

 

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

Вот-вот!

[user_anonymous]

Тут две фундаментальные ошибки

 

1. Задача любого оператора первым делом стереть всю приоритезацию, которая не согласована ( читай оплачена ) клиентом. Вы думаете клиентское ПО честно пометет трафик в соответствии с нуждами оператора? Ничего подобного любая дырка у оператора будет немедленно вздрючена сотней вирусов, интернет-бустеров, оптимизаторов и прочей програмной херни, которая камня на камне не оставит от вашей благородной идеи.

Собственно сложность отделения вредного трафика оператором произрастает от огромного желания этого трафика замаскироваться под полезный.

Э, нет, вот с этим вынужден не согласится. Сейчас у нас в стандартных сетях действует схема "все, что не запрещено - разрешено". А потм мы пытаемся уменьшать аппетиты вирусов и любителей п2п, а они пытаются маскирвать или шифровать трафик, применять всякие программные примочки, тоесть все то, о чем вы и сказали. Тоесть, грубо говоря, весть трафик априори считается полезным, а потом мы из него пытаемся выделить вредный. Заметьте, что моя схема от этого в корне отличается. У меня весь не попадающий в канал трафик считается вредным и идет с пониженным приоритетом и скоростью. А канал заканчивается там, где нужно провайдеру, и клиент с этим ничего сделать не может. Тоесть клиентскому ПО остается два выбора - либо честно послать то, что нужно - куда нужно, либо попасть в канал вредного трафика. Тоесть, все, что не разрешено - запрещено. Обычно такая схема работает очень хорошо.

 

2. Любое "якобы полезное" измение массовых стандартных вещей приведет к немедленному отторжению технологии потребителями. Попробуйте в отдельно взятой стране перевести движение с левосторонего на правосторонее, либо стандартизировать ширину ЖД колеи.

Согласен. Поэтому любое внедрение новой технологии должно опираться на труды предшественников, а не обесценивать их. Но если посмотреть на то, что представлялось мне, то можно видеть, что все как раз сделано для сохранения обратной совместимости. Тоесть существующее оборудование даже без перепрошивки по-прежнему продолжает работать, правда не так быстро, как могло бы (так как трафик не маркируется, то он попадает в медленный канал). Приведу простой пример из реального мира - свитч-мыльница может нормально пропускать сквозь себя 802.1q, хотя представления не имеет о тегах. Ну максимум, если уж он очень древний, может потребоваться уменьшить МТУ до 1496.

 

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

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

Ну, я вообще-то не собираюсь лично заниматься внедрением - как совершенно верно заметил Прохожий

В Ваших идеях чувствуется недостаток знаний. Понятно, что ковчег построил любитель, а титаник - толпа профессионалов, но Ною сам Бог помогал :)

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

Кстати, большое спасибо вам, что вы тратите свое время на обсуждение.

 

[Sonne]

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

Ну что же это такое, то а? Ну кто вам сказал такую чушь?

 

Сейчас весь трафик провайдер считает по-умолчанию "вредным" термин best offer delivery слышали?

Хотя учитывая отсутствие нормального перевода этого термина и непонимание его даже среди админов и отраслевых продавцов это не удивительно. Видимо мозгов хватает только на слово best.

 

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

 

Переосмыслите свою идею исходя из того, что сейчас все данные в стандартных сетях идут по "плохому каналу".

[Прохожий]

Зонни, только не best offer, a best effort. Ну это не принципиально.

 

Аноним, всякая обработка в пакетных сетях состоит из максимум трех частей:

1. Классифицировать

2. Пометить

3. Доставить

 

Давайте дальше по пунктам. По первому сделать нельзя ничего, не трогая протоколы от IP и выше. То есть можете классифицировать хоть по конкретной сессии - но делать это придется на входе в сеть. Причем, классификация, пожалуй, наиболее ресурсоемкая процедура. Ибо по L2 не очень-то отклассифицируешь - мало информации, по L3 можно, по L4 и выше было бы оптимально - но чем выше по модели - тем больше доступных критериев и выше сложность их определения. Для тренировки можете попробовать создать надежный критерий определения HTTP трафика. Причем классификация всегда должна быть максимально приближена к точке входа трафика в сеть - иначе теряет смысл. Т.е. - на юзерском порту, ибо терминалу доверия нет по определению.

 

2. Вопрос с пометкой закрыт давно и надежно. Есть DSCP на L3 и есть 802.1p на L2. Обе модели в принципе достаточны, радикально их улучшить не получится.

 

3. Доставка. Ничего нового здесь придумать нельзя - слишком уж это все фундаментально. Если сеть пакетная - она ОБРЕЧЕНА на per hop behaviour, вопрос тольк в:

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

б) способе засовывания пакетов в исходящую трубу. Если задуматься, то можно понять, что для MUXа это значит, что каждому контейнеру на входе предопрелелено место на выходе. А в пакетных - не предопределено. Вся разница.

 

Все, что можно: а) скрещивать утюги с бабочками, т.е. в пакетные сети пытаться привнести детерминизм сетей, ориентированных на соединения. Получится, по сути, очередной МПЛС. б) совершенствовать и ускорять алгоритмы поиска следующего скачка, в том числе и через придумывание новых видов протоколов в) совершенствовать и ускорять алгоритмы формирование таблиц поиска следующего скачка (куда входят все алгоритмы маршрутизации), опять же, и через придумывание новых видов протоколов. Причем, по сути-то пункт "а" виртуален насквозь, и реализуется только через пункты "б" и "в"

 

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

[AlexBT]

Да, ничего лучше прямого провода пока еще не придумали.

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

А прямой провод - это всегда канал...

[Paxton]

Хотелось бы узнать ваше мнение по сабжу - реально ли это было бы так хорошо, как мне кажется, или я что-то неучел, не понимаю или забыл.

Дружище, я смотрю вас тут разбивают в пух и прах.

Даже обвинили в изобретении велосипеда.

Но не падайте духом!

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

Задача в пределе проста - срастить Ethernet (цена) и MPLS (операторские фичи).

Но не просто срастить, а избавится от детских проблем, которые выплывают в операторских сетях: для Ethernet - это MAC-learning, Spanning Tree и прочая лабуда, для MPLS - сложность оборудования, реализующего все фичи, что выливается в недетскую цену оборудования доступа.

 

Вобщем советую копать в сторону проектов Nortel PBT/PBB (provider backbone transport/provider backbone bridging или что-то вроде того) и IEEE 802.1ah.

 

Коробки, которые коммутируют без MAC learning'a уже есть - например, ADVA FSP150.

 

P.S> Самое важное, как мне кажется, что такие вопросы кого-то еще волнуют. А то на меня пустые корридоры и лаборатории ИППИ (Институт проблем передачи информации, если кто не знает) в свое время произвели удручающее впечатление.

Главное - меньше слушайте знатоков. Страна Советов канула в Лету, но советов осталось еще не на одну страну :)

[Nag]

Самое важное, как мне кажется, что такие вопросы кого-то еще волнуют.

Присоединяюсь. :-)

[jab]

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

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

И тот путь, который Ethernet прошел за 35 лет, превратившись в потребительскую технологию, а потом ( уже имея десятки миллионов устройств в активе ) в операторскую, придется проходить каждой новой технологии. А для этого она должна иметь неоспоримые преимущества для массового

потребителя, которых у MPLS нет.

[Sonne]

Кстати всяким гуглям давно пора по хлебалу:

 

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

 

Главная идея принципов "нейтральности сетей" как раз и заключается в том, что провайдер обрабатывает и передает весь трафик абсолютно одинаково, не учитывая его особенностей и происхождение. Это опасно потенциальными злоупотреблениями провайдеров и становлению их главными объектами по управлению информационными потоками в стране. К числу сторонников принципов "нейтральности сетей" относятся такие компании и организации, как Microsoft, Google, Network Neutrality Squad, Consumers Union и Consumer Electronics Association.

 

Щас анонимус им покажет где у рака кака. Засунет всех в плохую трубу, не побоюсь сказать, в клоаку, и потребует деньги на апгрейд каналов.

 

Водопровод, понимаете? А мы сантехники, про которых никто не вспомнит пока гавно не зальет пятачок перед очком. Это они элита, хайтек, иновации. Мы водопроводчики, пока забастовку не объявим, за людей считаться не будем. Но даже водопроводчики имеют права наказывать за слив в канализацию цемента, соляной кислоты и прочих опасных веществ, вот сюда и будем копать :)