Проблема управління потоком даних при повнодуплексній роботі

Простій відмова від підтримки алгоритму доступу до середовища, що розділяється, без якої-небудь модифікації протоколу веде до підвищення вірогідності втрат кадрів комутаторами, оскільки при цьому втрачається контроль за потоками кадрів, що направляються кінцевими вузлами в мережу. Раніше потік кадрів регулювався методом доступу до середовища, що розділялося, так що дуже вузол, що часто генерує кадрів, вимушений був чекати своєї черги до середовища і фактична інтенсивність потоку даних, який направляв в мережу цей вузол, була помітно менше тієї інтенсивності, яку вузол хотів би відправити до мережі. При переході на повнодуплексний режим вузлу дозволяється відправляти кадрів комутатор завжди, коли це йому потрібно, тому комутатори мережі можуть в цьому режимі стикатися з перевантаженнями, не маючи при цьому ніяких засобів регулювання («пригальмовування») потоку кадрів.

Причина перевантажень зазвичай криється не в тому, що комутатор є блокуючим, тобто йому не вистачає продуктивності процесорів для обслуговування потоків кадрів, а в обмеженій пропускній спроможності окремого порту, яка визначається тимчасовими параметрами протоколу. Наприклад, порт Ethernet не може передавати більше 14 880 кадрів в секунду, якщо він не порушує тимчасових співвідношень, встановлених стандартом.

Тому, якщо вхідний трафік нерівномірно розподіляється між вихідними портами, легко представити ситуацію, коли в який-небудь вихідний порт комутатора прямуватиме трафік з сумарною середньою інтенсивністю більшою, ніж протокольний максимум. На рис. 3 зображена якраз така ситуація, коли в порт 3 комутатори прямує трафік від портів 1,2,4 і 6, з сумарною інтенсивністю в 22 100 кадрів в секунду. Порт 3 виявляється завантажений на 150 %. Природно, що коли кадри поступають в буфер порту із швидкістю 20 100 кадрів в секунду, а йдуть із швидкістю 14 880 кадрів в секунду, то внутрішній буфер вихідного порту починає неухильно заповнюватися необробленими кадрами.

Рис. 3 - Переповнювання буфера порту в наслідок незбалансованості трафіку

Яким би не був об'єм буфера порту, він в якийсь момент часу обов'язково переповниться. Неважко підрахувати, що при розмірі буфера в 100 Кбайт в приведеному прикладі повне заповнення буфера відбудеться через 0,22 секунд після початку його роботи (буфер такого розміру може зберігати до 1600 кадрів розміром в 64 байт). Збільшення буфера до 1 Мбайт дасть збільшення часу заповнення буфера до 2,2 секунд, що також неприйнятно. А втрати кадрів завжди дуже небажані, оскільки знижують корисну продуктивність мережі, і комутатор, що втрачає кадрів, може значно погіршити продуктивність мережі замість її поліпшення.

Комутатори локальних мереж - не перші пристрої, які стикаються з такою проблемою. Мости також можуть випробовувати перевантаження, проте такі ситуації при використанні мостів зустрічалися рідко із-за невеликої інтенсивності міжсегментного графіка, тому розробники мостів не почали вбудовувати в протоколи локальних мереж або в самі мости механізми регулювання потоку.

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

Примітка. Тут мова йде про протоколах МАС-уровня (Ethernet, Token Ring і т. п), оскільки мости і комутатори мають справу тільки з ними. Протокол LLC2, який уміє управляти потоком даних, для цілей управління потоком кадрів в комутаторах використовувати не можна. Для комутаторів протокол LLC (всі його процедури: 1, 2 і 3) прозорий, як і решта всіх протоколів верхніх рівнів, - комутатор не аналізує заголовок LLC, рахуючи його просто полемо даних кадру МАС-уровня.

Застосування комутаторів без зміни протоколу роботи устаткування завжди породжує небезпеку втрати кадрів. Якщо порти комутатора працюють в звичайному, тобто в напівдуплексному режимі, то у комутатора є можливість надати деяку дію на кінцевий вузол і змусити його припинити передачу кадрів, поки у комутатора не розвантажаться внутрішні буфери. Нестандартні методи управління потоком в комутаторах при збереженні протоколу доступу в незмінному вигляді будуть розглянуті нижче.

Якщо ж комутатор працює в повнодуплексному режимі, то протокол роботи кінцевих вузлів, та і його портів все одно міняється. Тому мало сенс для підтримки повнодуплексного режиму роботи комутаторів декілька модифікувати протокол взаємодії вузлів, вбудувавши в нього явний механізм управління потоком кадрів.

У березні 1997 року прийнятий стандарт IEEE 802.3x на управління потоком в повнодуплексних версіях протоколу Ethernet. Він визначає вельми просту процедуру управління потоком, подібну тій, яка використовується в протоколах LLC2 і LAP-B. Ця процедура має на увазі дві команди - «Припинити передачу» і «Відновити передачу», які прямують сусідньому вузлу. Відмінність від протоколів типу LLC2 в тому, що ці команди реалізуються на рівні символів код фізичного рівня, таких як 4В/5В, а не на рівні команд, оформлених в спеціальних кадрів, що управляють. Мережевий адаптер або порт комутатора, що підтримує стандарт 802.3x і що отримав команду «Припинити передачу», повинні припинити передавати кадрів аж до отримання команди «Відновити передачу».

Деякі фахівці висловлюють побоювання, що така проста процедура управління потоком виявиться непридатною в мережах Gigabit Ethernet. Повне припинення прийому кадрів від сусіда при такій великій швидкості передачі кадрів (1 488 090 кадр/с) може швидко викликати переповнювання внутрішнього буфера тепер у цього сусіда, який у свою чергу повністю заблокує прийом кадрів у своїх найближчих сусідів. Таким чином, перевантаження просто розповсюдиться по мережі, замість того щоб поступово зникнути. Для роботи з такими швидкісними протоколами необхідний тонший механізм регулювання потоку, який би указував, на яку величину потрібно зменшити інтенсивність потоку вхідних кадрів переобтяжений комутатор, а не припиняв цей потік до нуля. Подібний плавний механізм регулювання потоку з'явився у комутаторів АТМ через декілька років після їх появи. Тому існує думка, що стандарт 802.3x - це тимчасове рішення, яке просто закріпило існуючі фірмові прості механізми управління потоком провідних виробників комутаторів. Пройде якийсь час, і цей стандарт змінить інший стандарт - складніший і більш пристосований для високошвидкісних технологій, таких як Gigabit Ethernet.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Лекція 12 Особливості технології 100VG-AnyLAN	\|	Управління потоком кадрів при напівдуплексній роботі

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.034 сек.