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

Читать про QoS.

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

http://www.ozon.ru/context/detail/id/1339144/

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

Много ведь алгоритмов таких, подскажите что-нибудь на русском..... ОЧЕНЬ НАДО.

Учите английский.

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

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

Ну к примеру такой вид ядра

Добавлено через 2 минуты и 39 секунд
           0          0  -> выход
             \       /
              0 - 0
             /       \
вход->0          0

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

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

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

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

Если уж серьёзно помогать - нужно реально знать побольше про вашу сеть - о каких объёмах трафика идёт речь, что из себя представляет ядро (конечно, не идеальный чертёж в Visio, но хотя бы просто побольше информации). Если уж говорим о книжках от Циско, то что из себя представляет сеть в терминах сетевой модели Циско.. опять же, какое оборудование есть, и где.. 

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

Может кто-нибудь знает про реализацию таких протоколов???

В сторону RVSP можете посмотреть.

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

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

Моделирование с очередями рассмотрел мой научный руководитель, он изложил все результаты в своей работе. Мне надо же изобрести не велосипед.. думаю что-то на много сложнее. Мне надо надо написать протокол, который бы позволял граничным узлам как-то договориться, чтобы не грузить сильно ядро... Я даже не могу найти пример алгоритма такого протокола.... У кого-нибудь есть какие-нибудь идеи?

Повторяю, почитайте про RVSP - не совсем оно, но идеи можно почерпнуть. Может попутно и найдёте ещё что-нибудь.

Хм, если уже про технологию в предыдущем посте (хотя, если речь именно о протоколе резервирования ресурсов, то он всё-таки RSVP называется), можете взглянуть ещё на следующие темы, тоже вполне полезно - HSRP, VRRP, GLBP. В основном, они сделаны для отказоустойчивости, но для иллюстрации балансировки нагрузки тоже сойдут.

Nookie, а вуз случаем не МИЭМ?



З.Ы. мелькнула мысль: а почему должны договариваться именно граничные узлы? Должно договариваться ядро между самим собой =)
Но если обязательным условием является, что именно граничные, причём от каждого граничного узла есть канал минимум до двух устройств, входящих в состав ядра, (как оно и бывает обычно), перечисленные выше 3 технологии очень даже в тему.. хотя разговаривают там всё равно элементы ядра, насколько я помню.. 

Это сообщение отредактировал(а) Nicos - 15.12.2007, 06:47

Да, точно RSVP. Прошу прощения за дезинформацию.

Нет, я не с этого вуза. Мне было сказано, что все эти протоколы не подходят....

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

Ну дык вот она и есть эта технология, о которой и говорилось выше, скажем, у Cisco, да и не только:

Traffic policing, Traffic shaping
Это, условно говоря, раздача необходимой полосы пропускания, а далее и параметров качества обслуживания (Quality of Service, QoS) определённым типам трафика и система очередей (WFQ, CBWFQ)

На типы трафика исходный трафик делится технологией NBAR (Network-Based Application Recognition). По заголовку пакета, путём анализа информации верхних уровней определяется тип приложения (список сигнатур часто обновляется) и соответственно применяется правило для этого типа приложений - а дальше, когда трафик уже определён и промаркирован, управлять им можно как угодно, средств для этого полно. 

Детали - в документе Cisco BCMSN Certification Guide - тут его нельзя выкладывать, но найти можно.