Контроль передачи данных в конвергентных сетях. часть 1

Использовалась статья Cisco

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

Одной из причин ненадежности Ethernet заключается в отсутствии обратной связи между получателем данных и их отправителем. Проблема особенно критична в сетях с большим количеством хопов (hops). Часто бывает так, что отправитель передает данные с большей скоростью, чем получатель их обрабатывает. Это приводит к тому, что входные буферы получателя быстро заполняются (buffer overflow), а новые пакеты, которые хранить уже негде, просто отбрасываются (drop). Причем, никакого уведомления об этом отправитель не получает.

В сетях передачи данных такая ситуация не является критичной. Обнаружив, что каких-то Ethernet фреймов не хватает (drop detection), протоколы сетевого (3) уровня просят переслать их заново. Получив недостающие пакеты, эти протоколы их упорядочивают (in-order) и передают выше по стеку.

Ситуация значительно хуже в сетях хранения данных. Протокол Fibre Channel не осуществляет ретрансмиссию только отдельных фреймов (так же, как и не допускают доставку пакетов в неправильной последовательности - out of order delivery). В случае обнаружения потери части фреймов, устройствам приходится передавать заново всю последовательность (sequence). Естественно, это приводит к катастрофическому падению производительности.

Для того, чтобы избежать возможность потери фреймов в связи с переполнением входных буферов принимающих устройств, реализован специальный механизм контроля передачи данных (flow control). В “чистом” Fibre Channel этот механизм работает на уровне FC2. Он построен на первоначальном обмене информацией о количестве имеющихся в наличии входных буферов, дальнейшем уменьшении значений счетчиков буферных кредитов (BB credits) при отправке данных и их инкрементации при получении от порта-соседа коротких сообщений R_RDY об освобождении буферов. Подробнее в 3 части.

В конвергентных сетях на базе 10Gbps Ethernet при передаче FCoE трафика мы также обязаны использовать контроль передачи данных. Однако там для этого используется совсем другой подход. Порт-получатель данных постоянно следит за количеством своих свободных буферов. Как только он видит, что их количество достигает некого минимального уровня, порту-отправителю посылается специальный (MAC control frame) фрейм PAUSE, уведомляющий о необходимости на какое-то время приостановить передачу всех данных. Однако, такой подход не является оптимальным, так как в конвергентных сетях остановка FCoE трафика не должна приводить к задержке передачи данных других сетевых протоколов.
Поэтому механизм контроля передачи данных на базе PAUSE расширен функциональностью PFC (Priority Flow Control). Различным протоколам назначаются соответствующие классы сервиса (Classes of Services, CoS). Значение CoS передается в одном из полей VLAN-тега пакетов (VLAN tag). Контроль передачи осуществляется независимо для каждого из 8x возможных CoS. Структура пакетов не использующих и использующих PFC показана на рисунке.

Продолжительность паузы для каждого CoS определена в соответствующем 2byte поле количеством квантов времени. Один квант представляет собой время, необходимое для передачи 512bits данных на текущем Transfer Rate (в данном случае 10Gbps). Значение ноль принудительно снимает передачу данных с паузы.
Насколько я понял, в данный момент коммутаторы Cisco не пытаются интеллектуально подходить к определению необходимой продолжительности паузы. Вместо этого выставляется очень большое значение PAUSE, а затем явным образом снимается контрольным фреймом со значением 0. Как это работает у других, я не знаю.

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

Часть 2 здесь...