Тема 5

Канално ниво - кадри, предаване, грешки, номерация, прозорци.

Може би статията е написана неясно. Дайте мнение по въпроса.

Задачата на каналното ниво е да осъществи комуникация между две станции (възли), които са част от една и съща локална мрежа (мрежов сегмент), тоест общуват директно, без нужда от маршрутизиране. Най-ниско ниво на абстракция: При предаване, каналното ниво оформя ПБД, наречени кадри, които директно се изпращат, побитово или по октети, от физическия слой. Обратно, физическото ниво доставя получените битове / октети, от които каналното ниво разпознава отделните кадри.
За да се увеличи платформената независимост и да се улесни наслояването, каналното ниво се разделя на две поднива:

  • Logical Link Control - По-"високото" подниво. Свързва се с по-горните нива. Върши задачи като контрол върху скоростта на предаването и наслагване (мултиплексиране) на различни протоколи от ниво 2.
  • Media Access Control - По-"ниското", свързващо се с физическото ниво. Важна част от него е адресирането (MAC адреси)1, грижи се за достъпа до преносната среда (медията) и управлява логическите канали във физическия такъв.

Деленето на две поднива е по-слабо изразено, отколкото между различните нива, и не всеки протокол го зачита.

Кадри

Кадърът е битова поредица с определена структура, която се разпознава от някой протокол от ниво 2. Неговата големина е ограничена и се влияе от два фактора:

  • Фиксиран максимален размер на буфера - Всяка канална станция има буфери за изпращани и пристигащи пакети. В буфера трябва да могат да се поберат даден брой кадри. Същевременно, за да се постигне висока скорост, буферът не трябва да е списъчна структура с неясна големина. Това налага кадрите да имат ограничена максимална дължина.
  • Надеждност на канала - В преносната среда на канала могат да се случат различни събития - загуба на битове, затихване на сигнала, шумове (интерференция) - които да "повредят" кадъра и да се наложи той да бъде изпратен наново. Някои канали (например, кабелна локална мрежа) са високонадеждни: 1 грешка може да се очаква за 1 ден или повече непрекъснато предаване. Други (например, безжична или сателитна мрежа) са по-податливи на външни влияния и ненадеждни. В по-сигурните канали могат да се изпращат по-дълги кадри, а в по-несигурните е хубаво те да са къси.

Разпознаване

Тъй като кадърът е отрязък от поредица битове, нужно е каналната станция да може да го разпознае. Най-разпространените техники за това са две.

Байтово-ориентирано предаване (Byte stuffing)

Този метод е подобен на асинхроната комуникация и води началото си от терминалните мрежи, по които се предават символни поредици. Използва се в стари канали (мрежи)2. Кадърът се състои от байтове, които се изтеглят от паметта и се пренареждат в 8-битови поредици - октети. Разликата между байт и октет е, че едното е информационна единица, докато другото е просто битова поредица с дължина 8. Терминът октет се използва в серийните комуникации, където не е приложимо понятието байт.3
Тъй като байтовото предаване отначало е обслужвало мрежи за текстов обмен, кадрите започват и завършват със специални знаци (control codes), които са групирани в наборите C0 (ASCII) и C1 (Unicode). По-важните от тях са:

  • SOH (Start of Header, ASCII 01)
  • EOB (или ETB - End of Transmission Block, ASCII 23)
  • STX (Start of Text, ASCII 02)
  • ETX (End of Text, ASCII 03)
  • DLE (Data Link Escape, ASCII 16).

Когато една канална станция започва да предава, тя изпраща в следния ред:

SOH хедър съдържание на кадъра CRC код EOB

В първите, терминално-ориентирани канали, се изпращат само ASCII символи. STX се изпраща между хедъра и съобщението, а ETX - в края на съобщението. В тези канали разпознаването на кадрите е лесно, тъй като SOH и EOB не се срещат в текста на съобщението. Когато мрежите започват да се използват за пренос на данни, това се променя - стойностите на SOH и EOB спокойно могат да се появят някъде в блока от байтове. За да се избегне това, се въвежда употребата на DLE. Преди изпращане на кадъра, станцията проверява съдържанието байт по байт за наличието на служебни символи. Когато тя срещне такива, преди тях изпраща DLE. Отсрещната станция, прочитайки DLE, го премахва, като знае, че следващият непосредствен байт е част от информацията. За да се изпрати байт със стойността на DLE, той също се предшества от DLE - служебните стойности се "екранират"4.

Този метод има един голям недостатък: сканирането на изходящия поток данни е неефективно - прави се сравнение на всеки от байтовете по съответната битова маска за всеки специален символ. С две думи, МНОГО БАВНО.

Битово-ориентирано предаване (Bit stuffing)

По-нов и по-успешен метод. При него се отделя една специална поредица от 8 бита (наричана още флаг или флагова поредица), която да указва начало и край на кадъра - тя се изпраща преди и след него. Най-често използвана (например в HDLC) е 01111110 = 0x7E - 6 поредни единици, отделени чрез нули. Тъй като тази поредица също може да се срещне в предаваните данни, се извършва така нареченият bit stuffing. Преглежда се изходящият поток данни. Вграден брояч се увеличава с 1 при бит със стойност 1 и се нулира при бит със стойност 0. Ако броячът достигне 5, веднага след това се изпраща незначеща, служебна 0 и броячът се занулява. В приемащата страна, друг брояч се инициализира при срещане на 01111110 (начало на кадъра) и брои последователните единици. Ако броячът достигне 5, са възможни следните:

  • Следващият бит е 0. Тогава тя е служебно поставена и автоматично се изхвърля, а броячът се нулира.
  • Следващият бит е 1. Тогава се гледа по-следващият. Ако той е 1, получен е повреден кадър, който се изхвърля. При 0, отчита се край на кадъра и той се обработва по-нататък.

Броячите се реализират хардуерно по много прост начин, което значи, че те са и много бързи.
Недостатък на този метод е, че дължината на изпращания кадър зависи от информацията в него.

Търсене на грешки

При предаване в каналната среда може да се случи някое от следните:

  1. Загубване на кадъра, Загубване на потвърждението: Поради проблеми в преносната среда (например, повредена стартова / финална поредица - 01111110), има вероятност даден кадър въобще да не бъде получен от адресата. Важи и за кадрите, съдържащи потвърждение на други кадри (ако протоколът използва потвърждение). В този случай реакцията на станциите, които предават и приемат, зависи от правилата на протокола, който може да укаже да се чака за потвърждение, да се препраща кадърът или нищо да не се прави.
  2. Битови грешки: Проблеми в канала могат да променят един или повече битове от кадъра или хедъра му. За да се провери кадърът за грешки, се използа контролна сума (FCS). Тя се смята по CRC код, като пресмятането е хардуерно реализирано и става бързо. Нейният резултат, с големина 2 (CRC-16) или 4 байта (CRC-32), се прикрепя в края на кадъра. Получателят пресмята контролната сума на получения кадър и я сравнява с изпратената. Ако кодовете не съвпадат, кадърът е невалиден. Доказано е5, че цикличните кодове в основата на CRC прихващат всички единични грешки (един сгрешен бит) и максимално пакети грешки (няколко поредни грешки) и ако кодът от съобщението съвпада с изчисления, се счита за стопроцентова гаранция за коректността на съобщението.
  3. Прекъснати кадри: Възможно е част от кадъра да липсва, например поради затихване, грешки, спиране на предаването по някаква причина. Тези кадри се улавят лесно - липсват флагове, CRC-кодовете не съвпадат.
  4. Всичко е наред.

Реакция на станцията и потвърждение

Бележка: Йерархията на методите, описани тази секция, е различна от лекциите, понеже там такава няма - никакво подреждане не улових. Материалът долу е подреден според данни и аплети от Google, IEEE, лекции от разни сайтове на чужди университети.
Описаните по-горе механизми могат да се справят с възникващите в канала проблеми. Важен обаче е въпросът кога какво да се приложи. Решението на този въпрос зависи от използвания протокол. В някои протоколи може да се изисква задължително потвърждение (acknowledgement, ACK) на кадри (HDLC, Wireless Ethernet), докато в други може то изцяло да липсва (Ethernet). Ще разгледаме два варианти на предавне: кадър по кадър и поредица от кадри.6

Кадър по кадър

Най-простият метод на предаване е кадър по кадър (Stop-and-wait). При него, след изпращане предавателят държи кадъра в изходния буфер и чака потвърждение. Установено е регламентирано време за получаване на потвърждението (да речем, 5 секунди). След тяхното изтичане се отчита time-out, брояч на time-outs се увеличава с единица и пращането на кадъра се повтаря. При 3 time-outs се счита, че каналът не работи.

Възможно е кадърът да е получен, но потвърждението да се е загубило - предаващата станция не го е получила за определено време. По протокол, предаващата станция ("емитентът") ще изпрати кадъра наново. В този случай получателят ще приеме нещо, което той счита за нов кадър, но което всъщност е дубликат на по-ранен кадър. За да се реши този проблем още на второ (канално) ниво, при stop-and-wait, в хедъра на кадъра началният бит е служебен. Той е алтернативен - в първия кадър стойността му е 0, а за всеки следващ тя се променя (втори - 1, трети - 0 и тъй нататък). При препращане на кадър, стойността на първия бит остава същата. Това помага на получаващата станция да отчете дублиране. Важно е да се отбележи, че е възможно първият бит да се промени поради грешка. В такъв случай, кадърът ще се сметне за валиден, но най-вероятно ще се отхвърли на по-горно ниво.
При 2 валидни кадъра с еднакъв алтернативен бит, ако CRC-кодовете им съвпадат, станцията разпознава дублиран кадър. Ако са различни, счита се, че във втория кадър алтернативният бит е сгрешен.
При получаване на прекъснат кадър или грешен FCS, станцията, в зависимост от протокола, може да изпрати негативно потвърждение (negative acknowledgement, NAK), или да изчака броячът за потвърждение на предавателя да изтече. Вторият метод е по-лесно осъществим хардуерно, но първият е по-надежден. Възможно е и да се прати NAK за целия блок.

Предаването кадър по кадър с потвърждение е крайно неефективно. Затова се правят опити то да се оптимизира: въвеждат се входни и изходни буфери с големина 4 кадъра. Предавателят предава 4 кадъра, които се преглеждат от получателя. Ако всичко е наред, получателят праща ACK, предавателят изчиства буфера и се предават следващи 4 кадъра. Ако не, то не се изпраща ACK / изпраща се NAK, и четирите кадъра се препредават.

Поредица от кадри (Sliding window)

Дори и с въвеждането на буфери, предаването кадър по кадър е неефективно. За да е висока скоростта на предаване, необходимо е потвърждения да се пращат възможно най-рядко. Това би означавало голям буфер и голямо неудобство - ако един от всичките кадри се скапе, целият буфер ще се препредаде наново. Затова се измислят по-гъвкави способи за предаване.
За да се праща по-рядко потвърждение, се измисля така нареченият плъзгащ се прозорец. Той представлява буфер за предаване, в които се пазят изпращаните кадри. Тези кадри се държат в буфера, докато не се потвърдят. При потвърждение на първия кадър от буфера, кадърът се премахва и в буфера постъпва следващ кадър - прозорецът се "мести". Докато първият кадър чака потвърждение, останалите продължават да се изпращат.
Размерът на прозореца се договаря преди началото на изпращането, като за по-ненадеждни канали прозорците са по-малки. Той може да е фиксиран и равен за двете страни, а може да е различен и да се нагажда според натоварването на канала.
При плъзгащ се прозорец, налага се станциите да могат да укажат точно кои кадри не са получени, за да не се препраща целият блок. Въвеждат се така наречените поредни номера (sequence numbers). Те се разполагат в хедъра на кадъра и стойността им за всеки следващ кадър е с единица по-голяма, като най-често числото е циклично - стигайки до максимума, продължава от 0. Получавайки кадрите, адресатът е способен да съобщи на изпращача кои кадри е нужно да се повторят. Важно е номерата на кадрите да бъдат по обхват поне 2 пъти по-големи от размера на прозореца, за да се избегнат всички възможни двусмислия при препращане.
Потвържденията, при възможност, най-често се прикрепят към изходящи от станцията данни (прикрепени потвърждения, piggybacking). Така се намалява трафикът в канала. Ако такова изпращане не е възможно (например, няма изходни данни), ACK се изпраща в собствен кадър.

При липса на потвърждение, има няколко начина за решение:

  • NAK по битова маска - Като потвърждение се изпраща битова маска, своего рода "карта" на неполучените кадри. Разновидност на метода е изпращане на NAK за всички неполучени кадри.
  • Go back N - Решава проблема, когато кадърът не е получен или когато е получен, но потвърждението се е загубило. И в двата случая изпращачът не получава потвърждение за съответния кадър. Докато първият кадър в прозореца не е потвърден, прозорецът не се мърда. През това време следващи кадри от прозореца се изпращат и приемат, но не се потвърждават. Ако таймерът за потвърждение изтече, преди първият кадър да е потвърден, целият прозорец се изпраща наново. Ако всички кадри се изпратят, а първият още не е потвърден, прозорецът отново се изпраща изцяло. Звучи нерентабилно, подобно на Stop-and-wait, но предимството е, че при липса на потвърждение за първия кадър, останалите се изпращат и получават от адресата. Това улеснява по-нататъшната му работа и уплътнява канала. Демонстрация
  • Selective repeat - Почти същото, като GBN с важните разлики, че всички получени кадри се потвърждават и вместо да се изпраща наново целият прозорец, изпращат се само непотвърдените кадри. По-оптимален метод, но и по-сложен за изпълнение. Демонстрация

Допълнителни четива

IEEE 802 стандарти за свободно теглене - включват Ethernet, Token Ring, Wireless Ethernet и други.
Теорията зад CRC
Допълнителни разяснения по подхода Sliding window

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License