Работа сетей 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 на вашей скорости.

[iosifk]

Здесь говорилось о:

микросхему свича KS8993M фирмы Micrel, которая уже содержит в себе реализацию механизмов контроля потока. Один из 3-х портов этого свича может отдавать пакеты по MII интерфейсу, и я собираюсь эти пакеты упаковывать в поток E1 на своей скорости, а контроль переполнения очередей возлагаю на свич, который судя по его описанию умеет это делать.


Вот кусок перевода даташита для KS8995, просто для справки:

Поддержка ограничения объема обмена информацией
KS8995MA поддерживает аппаратное ограничение объема обмена информацией, как на стороне приема, так и на стороне передачи независимо для каждого порта. Это также поддерживает ограничение объема обмена информацией для приоритетной или неприоритетной среды. Предел объема обмена информацией начинается от 0 Кб/сек и подходит к частоте работы линии с шагом в 32Кб/сек.
KS8995MA использует одну секунду как временной интервал для паузы. В начале каждого интервала, счетчик обнуляется, и механизм, определяющий объем обмена информацией начинает считать число байтов, переданных/полученных в течение этого интервала.
На стороне приема, если число принятых байтов превышает запрограммированный предел, то коммутатор прекратит получать пакеты для этого порта, пока интервал, длительностью в одну секунду не истечет. Есть опция, предусматривающая управление потоком данных, используемая для того, чтобы предотвратить потери пакетов. Если предел на ограничение объема обмена информацией запрограммирован на скорости большие или равные 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 8 КБ ниже уровня предела, то будет вызвано управление потоком данных. Если предел на ограничение объема обмена информацией запрограммирован на скорости ниже чем 128 Кб/сек, и счетчик байтов находится на уровне, отстоящем на 2 КБ ниже предела, то в этом случае также будет вызвано управление потоком данных.
На стороне передачи, если число байтов превышает запрограммированный предел, коммутатор прекратит передавать пакеты через этот порт, пока интервал длительностью в одну секунду не истечет.
Если допускается обслуживание с приоритетами, то KS8995MA может поддержать различный уровень объема обмена информацией как для высоко-приоритетных и для низко-приоритетных пакетов. Такой режим обслуживания может быть запрограммирован в соответствующих регистрах управления режимами работы микросхемы.


Удачи!