Работа сетей Ethernet с медленными каналами связи, методы сопряжения и конвертации Опции

[Волощенко]

Здравствуйте!
Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.
Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:
- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;
- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.
Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.
Хотел бы обменяться мнениями с теми, кто сталкивался с данной проблемой.
Спасибо.

[Krys]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться. Но выше этого уровня есть транспортный, в частности, протокол TCP. Глубоко не вникал в его работу, но этот протокол должен по количеству недошедших пакетов подстраивать скорость передачи пакетов, чтобы они не терялись и не образовывались задержки, связанные с повторной передачей пакетов.
Я пока начинаю работать над похожей задачей и надеюсь, что так и будет, как я выше описал.
А все перечисленные вами ранее методы бесполезны: если в каналах разная скорость, это обязательно когда-то приведёт к невозможности доставить очередной пакет. Например, метод шлюза работает, пока не переполнится буфер. А потом всё равно пакеты потеряются.
Метод обратного давления приводит к бесполеному "торможению по цепочке". Вообще, коллизии имеют место только в полудуплексном режиме (я работаю с полным дуплексом на гигабитном изернете). В полном дуплексе есть механизм управления потоком, описываемый стандартом IEEE 802.3х (см. тему http://electronix.ru/forum/index.php?showtopic=15533 К стати, я с этим механизмом до конца так и не разобрался, так что был бы благодарен за помощь с русскоязычными текстами, поясняющими его). Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"

[Shamil]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться.

Почему же "никуда не деться" ?
Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 10..20 (наверное ).

Что будет происходить: переполнится входной буфер вашего узкого горлышка, он будет оказывать обратное давление (хоть коллизией, хоть через механизм контроля потоков) на стоящее перед ним (по ходу передачи пакета) оборудование канального уровня (в первую очередь, коммутирующее), которое должно приостановить передачу пакета. В этом случае уже в этом предыдущем устройстве начнёт заполняться буфер и переполнится. Он опять должен оказывать обратное давление на предыдущее устройство и т.д. по цепочке. Это всё лишнее, если протокол TCP нормально выполняет свои функции и не даёт переполняться буферам, обеспечивая скорость "на грани"

К сожалению, протокол TCP контролирует целостность только одного сеанса связи между двумя процессами (потребителями). А через узкое горло может быть организовано ничем не ограниченное множество независимых сеансов TCP.
Да и вообще, речь идет о передаче не IP пакетов, а пакетов Ethernet, в которые могут инкапсулироваться множество различных протоколов. Поэтому без управления потоком на MAC уровне не обойтись.
Я тоже только подступаюсь к этой проблеме. Посколько разбираться со всеми нюансами нет времени, я решил взять микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.
Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

[Krys]

насколько я представляю работу стека протоколов, при переполнении входного буфера вашего узкого горлышка, пакеты канального уровня теряются, никуда не деться.

Почему же "никуда не деться" ?
Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 10..20 (наверное :cranky: ).

Почему именно такая цифра? С потолка? Вы знаете, что если скорости не совпадают, то любой буфер переполнится, какой большой бы он ни был. Зачем такой здоровый буфер? Это же надо сколько памяти? Железка будет очень дорогой. Обычно руководствуются правилом, что в буфере должно укладываться 2 пакета: чтобы протоколы TCP успели договориться на приёмной и передающей сторонах

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

Да и к чему я это всё пишу:

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

Под переполнением я, разумеется, имел в виду заполнение до определённого порога, при котором посылается команда приостановки передачи. Но самое главное: вы представляете, что каждый раз при переполнении всё оборудование канального уровня от узкого места до источника пакетов будет подвержено распространению по цепочке кадра приостановки передачи, а после опустошения буфера - кадра возобновления передачи? Кому нужен весь этот бесполезный трафик, если гораздо проще поручить на передающем конце протоколу TCP подстроить оптимальную скорость посылки пакетов в сеть? И тогда весь механизм контроля потоков не пригодится.
А если ещё учесть, что на пути от источника пакетов до узкого горлышка возможно хоть один свич не поддерживает механизм контроля потоков? Тогда все старания этого механизма, весь паразитный трафик из кадров приостановки и возобновления передачи напрасны. Этот свич, не поддерживающий механизм контроля потока будет слать пакеты, и следующее по пути их распространения оборудование будет заполнять свой приёмный буфер. И он заполнится. Лишние пакеты всё равно начнут убиваться.
Пусть уж лучше протокол TCP возьмётся за эту работу.

К сожалению, протокол TCP контролирует целостность только одного сеанса связи между двумя процессами (потребителями). А через узкое горло может быть организовано ничем не ограниченное множество независимых сеансов TCP.

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

Да и вообще, речь идет о передаче не IP пакетов, а пакетов Ethernet, в которые могут инкапсулироваться множество различных протоколов. Поэтому без управления потоком на MAC уровне не обойтись.

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

Я тоже только подступаюсь к этой проблеме. Посколько разбираться со всеми нюансами нет времени, я решил взять микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.
Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

У меня лично Gigabit Ethernet, там со свичами с малым количеством портов пока проблема... я делаю вообще свич на ПЛИС.

[zltigo]

сли гораздо проще поручить на передающем конце протоколу TCP подстроить оптимальную скорость посылки пакетов в сеть?

Махровый идеализм :-)))).

я делаю вообще свич на ПЛИС.

Тогда это вообще не Ваша "проблема".