[Voloshchenko 0]

Здравствуйте!

Кто сталкивался с подобной проблемой, когда разные фрагменты сети Ethernet, отстоящие друг от друга на десятки километров, соединены между собой низкоскоростными телекоммуникационными каналами связи типа ИКМ30. Такие каналы используют конверторы и структура канала такая: Ethernet-ИКМ30-Соединительная Линия-ИКМ30-Ethernet, а пиковая скорость передачи равна 64кБит*N, где N=1..30.

Для согласования скорости из Ethernet в ИКМ30, по моему представлению, используются такие методы:

- «шлюза», когда принятые, но еще не переданные пакеты накапливаются в очереди;

- «метод обратного давления», когда во время передачи текущего пакета, прием всех новых пакетов блокируется путем создания коллизий – одновременной передачей из конвертора в сеть Ethernet любого встречного пакета.

Мне нужно найти правильный выход, так как с помощью сниффера Ethereal четко заметил, что новый пакет приходит из Ethernet в конвертор до того, как в ИКМ30 передан предыдущий - а это приводит к отказам. Возможно, здесь есть еще тонкости применения в протоколе TCP/IP.

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

Спасибо.

[Krys 2]

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

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

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

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

[Shamil 2]

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

Почему же "никуда не деться" ?

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

 

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

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

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

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

Если у вас нет требований по индустриальному исполнению, есть еще более удобный свич фирмы Infineon ADM6993/X, у него третий порт может отдавать пакеты в формате HDLC на вашей скорости.

[Voloshchenko 0]

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

По этому напрашивается такая мысль - модифицировать метод "скользящего окна", тем что на определенном протокольном этапе перехватывать размер допускаемого к приему окна, «вручную» изменять в нем число разрешенных к передаче в окне кадров, например, с M до 1-го и далее передавать в направлении сервера. Таким образом, мы возвращаемся к квитированию.

[Krys 2]

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

По этому напрашивается такая мысль - модифицировать метод "скользящего окна", тем что на определенном протокольном этапе перехватывать размер допускаемого к приему окна, «вручную» изменять в нем число разрешенных к передаче в окне кадров, например, с M до 1-го и далее передавать в направлении сервера. Таким образом, мы возвращаемся к квитированию.

Вобщем-то этим и занимается протокол TCP

[Krys 2]

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

Почему же "никуда не деться" ?

Надо просто попросить устройства посылающие пакеты притормозиться, не дожидаясь полного заполнения буфера. Ну и буфер брать приличного размера, пакетов на 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 0]

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

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

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

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

[Krys 2]

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

Позволю себе не согласиться: идеальным выглядит решение с механизмом контроля потоков. И вот оно, как раз, и разбивается о суровую правду жизни, которую я описывал ранее. Что не все устройства это поддерживают, что гоняется лишний трафик и т.д. С моим мнением коррелируют утверждения авторов книги [Компьютерные сети: Принципы, технологии, протоколы: Учебник для вузов/ Виктор Григорьевич Олифер, Наталия Алексеевна Олифер. - СПб.: Питер, 2002. - 669[3] с.: ил. - (Учебник для вузов)], если не ошибаюсь.

А вот протокол TCP, как раз должен выполнять требуемые действия по подстройке скорости. Я детально в нём не разбирался, но определённые понятия имею.

 

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

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

[zltigo 0]

А вот протокол TCP, как раз должен выполнять требуемые действия по подстройке скорости. Я детально в нём не разбирался, но определённые понятия имею.

Конретные реализации стеков конкретно на это и на обработку (только фиксация для статистики)

аппаратных ошибок любезно доставляемых Вашим switch плюют :-( Это я имел ввиду под

идеализмом :-(. Собственно этот бардак начался с распространения интернета, когда что-либо кто-либо перестал гарантировать, ну а на локальные сети "автоматически" распространилось :-(

[Harbour 0]

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

[kolobok0 0]

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

 

дело вот в чём...

сам разговор об абстрактном Ethernet конечно же занимательная весчь, но мягко говоря бесполезная... При реализации стэка протоколов Вы будете реализовывать все нижележащие протоколы. Если идёт речь о TCP/IP то Вам придётся покопаться с MAC уровнем, с IP уровнем, протоколами ARP (скорее всего захотите поддержать), протокол ICMP (скорее всего захотите поддержать), рядом лежащий UDP...

Дык вот, если речь идёт об "узком" горлышке IP уровня, который может ДЕФРАГМЕНТИРОВАТЬ пакеты кде то там и у Вас должным образом должна производиться сборка - то тогда "первый удар" будет принимать именно он. Данный уровень не содержит механизма регулирования пропускной способности канала. И тут нужен кэш. И решение таких проблем как время жизни разрозненных пакетов при сборке. В принцепе, чтоб не быть голословным - вот ссылки, возможно кому нить они помогут...

 

русско язычная ссылка

ссылка на -гнездо- протоколов

 

с уважением

(круглый)

[Voloshchenko 0]

Спасибо за ответы и ссылки на документацию.

Есть мнение, что согласование высокой скорости Ethernet и медленной E1 (TDM,PCM30) достаточно сделать методом «обратного давления», создавая коллизии на аппаратном МАС-уровне. В этом случае, когда низкоскоростной канал все еще находится в режиме передачи предыдущего пакета, нужно на ранних этапах распознать поступление нового пакета Ethernet и, пока он продолжает поступать, сгенерировать свой встречный. Тогда встречное устройства на МАС-уровне распознает коллизию, прекратит передачу и попробует с некоторой задержкой ее повторить (что может выполняться несколько раз), и это в итоге даст нужную нам задержку, а значит и согласование скорости.

1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?

2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал? :excl:

[zltigo 0]

Есть мнение...

Ошибочное. Подробности были в личном письме.

[Joe 0]

Спасибо за ответы и ссылки на документацию.

Есть мнение, что согласование высокой скорости Ethernet и медленной E1 (TDM,PCM30) достаточно сделать методом «обратного давления», создавая коллизии на аппаратном МАС-уровне. В этом случае, когда низкоскоростной канал все еще находится в режиме передачи предыдущего пакета, нужно на ранних этапах распознать поступление нового пакета Ethernet и, пока он продолжает поступать, сгенерировать свой встречный. Тогда встречное устройства на МАС-уровне распознает коллизию, прекратит передачу и попробует с некоторой задержкой ее повторить (что может выполняться несколько раз), и это в итоге даст нужную нам задержку, а значит и согласование скорости.

1. Непонятным является то, куда, в какую физическую линию, генерировать «свой встречный» пакет? Ведь есть два провода входных и два выходных. Если не в ту, из которой поступает новый пакет (два входных провода), то как быть с полнодуплексным режимом, получается, что для него этот метод не работает?

2. Все-таки должны быть универсальные методы согласования. Кто-то ж их уже опробовал? :excl:

 

А не проще решить проблему применением готового моста? Видел реализацию на MB86976 (Fujitsu Ethernet Bridge Controller см. рисунок). У него с одной стороны подключается LIU Ethernet а с другой - WAN-interface. Еще правда к нему надо DRAM подцепить. Скорость в WAN-части - до 8 Мбит/с. Придется, конечно, повозится с "N*64" и синхронизацией в ИКМ-части, но зато проблема с "запихиванием слона в запорожец" решиться однозначно.

 

[iosifk 3]

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

 

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

 

 

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

 

Поддержка ограничения объема обмена информацией

KS8995MA поддерживает аппаратное ограничение объема обмена информацией, как на стороне приема, так и на стороне передачи независимо для каждого порта. Это также поддерживает ограничение объема обмена информацией для приоритетной или неприоритетной среды. Предел объема обмена информацией начинается от 0 Кб/сек и подходит к частоте работы линии с шагом в 32Кб/сек.

KS8995MA использует одну секунду как временной интервал для паузы. В начале каждого интервала, счетчик обнуляется, и механизм, определяющий объем обмена информацией начинает считать число байтов, переданных/полученных в течение этого интервала.

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

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

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

 

 

Удачи!