Kievuz

Протокол LLC уровня управления логическим каналом

Протокол LLC уровня управления логическим каналом

Протокол LLC уровня управления логическим каналом

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

Протокол LLC занимает уровень между сетевыми протоколами и протоколами уровня MAC.

Протоколы сетевого уровня передают через межуровневый интерфейс данные для протокола LLC – свой пакет (например, пакет IP, IPX или NetBEUI), адресную информацию об узле назначения, а также требования к качеству транспортных услуг, которое протокол LLC должен обеспечить.

Протокол LLC помещает пакет протокола верхнего уровня в свой кадр, который дополняется необходимыми служебными полями. Далее через межуровневый интерфейс протокол. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня MAC, который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).

В основу протокола LLC положен протокол HDLC (High-level Data Link Control Procedure), являющийся стандартом ISO.

Собственно стандарт HDLC представляет собой обобщение нескольких близких стандартов, характерных для различных технологий: протокола LAP-B сетей Х.

25 (стандарта, широко распространенного в территориальных сетях), LAP-D, используемого в сетях ISDN, LAP-M, работающего в современных модемах. В спецификации IEEE 802.2 также имеется несколько небольших отличий от стандарта HDLC.

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

3.2.1. Три типа процедур уровня LLC

В соответствии со стандартом 802.2 уровень управления логическим каналом LLC предоставляет верхним уровням три типа процедур:

· LLC1 – процедура без установления соединения и без подтверждения;

· LLC2 – процедура с установлением соединения и подтверждением;

· LLC3 – процедура без установления соединения, но с подтверждением.

Этот набор процедур является общим для всех методов доступа к среде, определенных стандартами 802.3 – 802.5, а также стандартом FDDI и стандартом 802.12 на технологию l00VG-AnyLAN.

Процедура без установления соединения и без подтверждения LLC1 дает пользователю средства для передачи данных с минимумом издержек. Это дейтаграммный режим работы. Обычно этот вид процедуры используется, когда такие функции, как восстановление данных после ошибок и упорядочивание данных, выполняются протоколами вышележащих уровней, поэтому нет нужды дублировать их на уровне LLC.

Процедура с установлением соединений и подтверждением LLC2 дает пользователю возможность установить логическое соединение перед началом передачи любого блока данных и, если это требуется, выполнить процедуры восстановления после ошибок и упорядочивание потока этих блоков в рамках установленного соединения. Протокол LLC2 во многом аналогичен протоколам семейства HDLC (LAP-B, LAP-D, LAP-M), которые применяются в глобальных сетях для обеспечения надежной передачи кадров на зашумленных линиях. Протокол LLC2 работает в режиме скользящего окна.

В некоторых случаях (например, при использовании сетей в системах реального времени, управляющих промышленными объектами), когда временные издержки установления логического соединения перед отправкой данных неприемлемы, а подтверждение о корректности приема переданных данных необходимо, базовая процедура без установления соединения и без подтверждения не подходит. Для таких случаев предусмотрена дополнительная процедура, называемая процедурой без установления соединения, но с подтверждением LLC3.

Использование одного из трех режимов работы уровня LLC зависит от стратегии разработчиков конкретного стека протоколов. Например, в стеке TCP/IP уровень LLC всегда работает в режиме LLC1, выполняя простую работу извлечения из кадра и демультиплексирования пакетов различных протоколов – IP, ARP, RARP. Аналогично используется уровень LLC стеком IPX/SPX.

А вот стек Microsoft/IBM, основанный на протоколе NetBIOS/NetBEUI, часто использует режим LLC2. Это происходит тогда, когда сам протокол NetBIOS/NetBEUI должен работать в режиме с восстановлением потерянных и искаженных данных. В этом случае эта работа перепоручается уровню LLC2. Если же протокол NetBIOS/NetBEUI работает в дейтаграммном режиме, то протокол LLC работает в режиме LLC1.

Режим LLC2 используется также стеком протоколов SNA в том случае, когда на нижнем уровне применяется технология Token Ring.

3.2.2. Структура кадров LLC. Процедура с восстановлением кадров LLC2

По своему назначению все кадры уровня LLC (называемые в стандарте 802.2 блоками данных – Protocol Data Unit, PDU) подразделяются на три типа – информационные, управляющие и ненумерованные.

· Информационные кадры (Information) предназначены для передачи информации в процедурах с установлением логического соединения LLC2 и должны обязательно содержать поле информации. В процессе передачи информационных блоков осуществляется их нумерация в режиме скользящего окна.

· Управляющие кадры (Supervisory) предназначены для передачи команд и ответов в процедурах с установлением логического соединения LLC2, в том числе запросов на повторную передачу искаженных информационных блоков.

· Ненумерованные кадры (Unnumbered) предназначены для передачи ненумерованных команд и ответов, выполняющих в процедурах без установления логического соединения передачу информации, идентификацию и тестирование LLC-уровня, а в процедурах с установлением логического соединения LLC2 -установление и разъединение логического соединения, а также информирование об ошибках. Все типы кадров уровня LLC имеют единый формат:

Кадр LLC обрамляется двумя однобайтовыми полями «Флаг», имеющими значение 01111110. Флаги используются на уровне MAC для определения границ кадра LLC. В соответствии с многоуровневой структурой протоколов стандартов IEEE 802, кадр LLC вкладывается в кадр уровня MAC: кадр Ethernet, Token Ring, FDDI и т. д. При этом флаги кадра LLC отбрасываются.

Кадр LLC содержит поле данных и заголовок, который состоит из трех полей:

· адрес точки входа службы назначения (Destination Service Access Point, DSAP);

· адрес точки входа службы источника (Source Service Access Point, SSAP);

· управляющее поле (Control).

Поле данных кадра LLC предназначено для передачи по сети пакетов протоколов вышележащих уровней – сетевых протоколов IP, IPX, AppleTalk, DECnet, в редких случаях – прикладных протоколов, когда те вкладывают свои сообщения непосредственно в кадры канального уровня. Поле данных может отсутствовать в управляющих кадрах и некоторых ненумерованных кадрах.

Адресные поля DSAP и SSAP занимают по 1 байту. Они позволяют указать, какая служба верхнего уровня пересылает данные с помощью этого кадра.

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

Для идентификации этих протоколов вводятся так называемые адреса точки входа службы (Service Access Point, SAP). Значения адресов SAP приписываются протоколам в соответствии со стандартом 802.2. Например, для протокола IP значение SAP равно 0х6, для протокола NetBIOS -0*F0.

Для одних служб определена только одна точка входа и, соответственно, только один SAP, а для других – несколько, когда адреса DSAP и SSAP совпадают. Например, если в кадре LLC значения DSAP и SSAP содержат код протокола IPX, то обмен кадрами осуществляется между двумя IPX-модулями, выполняющимися в разных узлах. Но в некоторых случаях в.

кадре LLC указываются различающиеся DSAP и SSAP. Это возможно только в тех случаях, когда служба имеет несколько адресов SAP, что может быть использовано протоколом узла отправителя в специальных целях, например для уведомления узла получателя о переходе протокола-отправителя в некоторый специфический режим работы. Этим свойством протокола LLC часто пользуется протокол NetBEUI.

Поле управления (1 или 2 байта) имеет сложную структуру при работе в режиме LLC2 и достаточно простую структуру при работе в режиме LLC1 (рис. 3.2).

Рис. 3.2. Структура поля управления

В режиме LLC1 используется только один тип кадра – ненумерованный. У этого кадра поле управления имеет длину в один байт.

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

Учитывая, что в протоколе Ethernet при записи реализован обратный порядок бит в байте, то запись поля управления кадра LLC1, вложенного в кадр протокола Ethernet, имеет значение 0х03 (здесь и далее префикс Ох обозначает шестнадцатеричное представление).

В режиме LLC2 используются все три типа кадров. В этом режиме кадры делятся на команды и ответы на эти команды. Бит P/F (Poll/Final) имеет следующее значение: в командах он называется битом Poll и требует, чтобы на команду был дан ответ, а в ответах он называется битом Final и говорит о том, что ответ состоит из одного кадра.

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

· Установить сбалансированный асинхронный расширенный режим (SABME). Эта команда является запросом на установление соединения. Она является одной из команд полного набора команд такого рода протокола HDLC. Расширенный режим означает использование двухбайтных полей управления для кадров остальных двух типов.

· Ненумерованное подтверждение (UA). Служит для подтверждения установления или разрыва соединения.

· Сброс соединения (REST). Запрос на разрыв соединения.

После установления соединения данные и положительные квитанции начинают передаваться в информационных кадрах. Логический канал протокола LLC2 является дуплексным, так что данные могут передаваться в обоих направлениях.

Если поток дуплексный, то положительные квитанции на кадры также доставляются в информационных кадрах.

Если же потока кадров в обратном направлении нет или же нужно передать отрицательную квитанцию, то используются супервизорные кадры.

В информационных кадрах имеется поле N(S) для указания номера отправленного кадра, а также поле N(R) для указания номера кадра, который приемник ожидает получить от передатчика следующим. При работе протокола LLC2 используется скользящее окно размером в 127 кадров, а для их нумерации циклически используется 128 чисел, от 0 до 127.

Приемник всегда помнит номер последнего кадра, принятого от передатчика, и поддерживает переменную с указанным номером кадра, который он ожидает принять от передатчика следующим. Обозначим его через V(R). Именно это значение передается в поле N(R) кадра, посылаемого передатчику.

Если в ответ на этот кадр приемник принимает кадр, в котором номер посланного кадра N(S) совпадает с номером ожидаемого кадра V(R), то такой кадр считается корректным (если, конечно, корректна его контрольная сумма).

Если приемник принимает кадр с номером N(S), неравным V(R), то этот кадр отбрасывается и посылается отрицательная квитанция Отказ (REJ) с номером V(R).

При приеме отрицательной квитанции передатчик обязан повторить передачу кадра с номером V(R), а также всех кадров с большими номерами, которые он уже успел отослать, пользуясь механизмом окна в 127 кадров.

В состав супервизорных кадров входят следующие:

· Отказ (REJect);

· Приемник не готов (Receiver Not Ready, RNR);

· Приемник готов (Receiver Ready, RR).

Команда RR с номером N(R) часто используется как положительная квитанция, когда поток данных от приемника к передатчику отсутствует, а команда RNR -для замедления потока кадров, поступающих на приемник. Это может быть необходимо, если приемник не успевает обработать поток кадров, присылаемых ему с большой скоростью за счет механизма окна.

Получение кадра RNR требует от передатчика полной приостановки передачи, до получения кадра RR.

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

Выводы

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

· LLC предоставляет верхним уровням три типа процедур: процедуру без установления соединения и без подтверждения; процедуру с установлением соединения и подтверждением; процедуру без установления соединения, но с подтверждением.

· Логический канал протокола LLC2 является дуплексным, так что данные могут передаваться в обоих направлениях.

· Протокол LLC в режиме с установлением соединения использует алгоритм скользящего окна.

· Протокол LLC с помощью управляющих кадров имеет возможность регулировать поток данных, поступающих от узлов сети. Это особенно важно для коммутируемых сетей, в которых нет разделяемой среды, автоматически тормозящей работу передатчика при высокой загрузке сети.

Источник: http://kursak.net/protokol-llc-urovnya-upravleniya-logicheskim-kanalom/

Локальные сети (11)

Протокол LLC уровня управления логическим каналом

Сохрани ссылку в одной из сетей:

В основупротокола LLC положен протокол HDLC(High-level Data Link Control Procedure), широко использующийсяв территориальных сетях.

В соответствиисо стандартом 802.2 уровень управлениялогическим каналом LLC предоставляетверхним уровням три типа процедур:

  • LLC1 – сервис без установления соединения и без подтверждения;

  • LLC2 – сервис с установлением соединения и подтверждением;

  • LLC3 – сервис без установления соединения, но с подтверждением.

Этотнабор процедур является общим для всехметодов доступа к среде, определенныхстандартами 802.3-802.5.

Сервисбез установления соединения и безподтверждения LLC1 даетпользователю средства для передачиданных с минимумом издержек. Обычно,этот вид сервиса используется тогда,когда такие функции как восстановлениеданных после ошибок и упорядочиваниеданных выполняются протоколамивышележащих уровней, поэтому нет нуждыдублировать их на уровне LLC.

Сервисс установлением соединений и сподтверждением LLC2 даетпользователю возможность установитьлогическое соединение перед началомпередачи любого блока данных и, еслиэто требуется, выполнить процедурывосстановления после ошибок иупорядочивание потока этих блоков врамках установленного соединения.Протокол LLC2 во многом аналогиченпротоколам семейства HDLC (LAP-B, LAP-D, LAP-M),которые применяются в глобальных сетяхдля обеспечения надежной передачикадров на зашумленных линиях.

Внекоторых случаях (например, прииспользовании сетей в системах реальноговремени, управляющих промышленнымиобъектами), когда временные издержкиустановления логического соединенияперед отправкой данных неприемлемы, аподтверждение корректности приемапереданных данных необходимо, базовыйсервис без установления соединения ибез подтверждения не подходит. Для такихслучаев предусмотрен дополнительныйсервис, называемый сервисом безустановления соединения, но с подтверждениемLLC3.

Чащевсего в локальных сетях используютсяпротоколы LLC1. Это объясняется тем, чтокабельные каналы локальных сетейобеспечивают низкую вероятностьискажений бит и потери кадров. Поэтому,использование повышающего надежностьобмена протокола LLC2 часто приводит кнеоправданной избыточности, толькозамедляющей общую пропускную способностьстека коммуникационных протоколов.

Темне менее, иногда протокол LLC2 применяетсяи в локальных сетях. Так, этот протоколиспользуется стеком SNA в том случае,когда мэйнфремы или миникомпьютеры IBMвзаимодействуют через сети Token Ring.Протокол LLC2 используется также компаниейHewlett-Packard в том случае, когда принтерыподключается к сети Ethernet непосредственно,с помощью встроенных сетевых адаптеров.

2.Стандарты технологии Ethernet

Ethernet -это самый распространенный на сегодняшнийдень стандарт локальных сетей. Общееколичество сетей, использующих внастоящее время Ethernet, оценивается в 5миллионов, а количество компьютеров,работающих с установленными сетевымиадаптерами Ethernet – в 50 миллионов.

Когдаговорят Ethernet, то под этим обычно понимаютлюбой из вариантов этой технологии. Вболее узком смысле, Ethernet – это сетевойстандарт, основанный на технологияхэкспериментальной сети Ethernet Network, которуюфирма Xerox разработала и реализовала в1975 году (еще до появления персональногокомпьютера).

Метод доступа был опробованеще раньше: во второй половине 60-х годовв радиосети Гавайского университетаиспользовались различные вариантыслучайного доступа к общей радиосреде,получившие общее название Aloha. В 1980 годуфирмы DEC, Intel и Xerox совместно разработалии опубликовали стандарт Ethernet версии IIдля сети, построенной на основекоаксиального кабеля.

Поэтому стандартEthernet иногда называют стандартом DIX позаглавным буквам названий фирм.

Наоснове стандарта Ethernet DIX был разработанстандарт IEEE 802.3, который во многомсовпадает со своим предшественником,но некоторые различия все же имеются.В то время, как в стандарте IEEE 802.

3различаются уровни MAC и LLC, в оригинальномEthernet оба эти уровня объединены в единыйканальный уровень. В Ethernet определяетсяпротокол тестирования конфигурации(Ethernet Configuration Test Protocol), который отсутствуетв IEEE 802.3.

Несколько отличается и форматкадра, хотя минимальные и максимальныеразмеры кадров в этих стандартахсовпадают.

Взависимости от типа физической средыстандарт IEEE 802.3 имеет различные модификации- 10Base-5, 10Base-2, 10Base-T, 10Base-F.

Дляпередачи двоичной информации по кабелюдля всех вариантов физического уровнятехнологии Ethernet используется манчестерскийкод.

Всевиды стандартов Ethernet используют одини тот же метод разделения среды передачиданных – метод CSMA/CD.

2.1 Метод доступаCSMA/CD

В сетяхEthernet используется метод доступа к средепередачи данных, называемый методомколлективного доступа с опознаваниемнесущей и обнаружением коллизий(carrier-sense-multiply-access with collision detection, CSMA/CD).

МетодCSMA/CD определяет основные временные илогические соотношения, гарантирующиекорректную работу всех станций в сети:

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

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

Послеобнаружения коллизии каждый узел,который передавал кадр и столкнулся сколлизией, после некоторой задержкипытается повторно передать свой кадр.Узел делает максимально 16 попытокпередачи этого кадра информации, послечего отказывается от его передачи.

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

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

Четкоераспознавание коллизий всеми станциямисети является необходимым условиемкорректной работы сети Ethernet.

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

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

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

Всепараметры протокола Ethernet подобранытаким образом, чтобы при нормальнойработе узлов сети коллизии всегда четкораспознавались. Именно для этогоминимальная длина поля данных кадрадолжна быть не менее 46 байт (что вместесо служебными полями дает минимальнуюдлину кадра в 72 байта или 576 бит).

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

Поэтому для скорости передачиданных 10 Мб/с, используемой в стандартахEthernet, максимальное расстояние междудвумя любыми узлами сети не должнопревышать 2500 метров.

Сувеличением скорости передачи кадров,что имеет место в новых стандартах,базирующихся на том же методе доступаCSMA/CD, например, Fast Ethernet, максимальнаядлина сети уменьшается пропорциональноувеличению скорости передачи. В стандартеFast Ethernet она составляет 210 м, а в гигабитномEthernet ограничена 25 метрами.

Независимоот реализации физической среды, всесети Ethernet должны удовлетворять двумограничениям, связанным с методомдоступа:

  • максимальное расстояние между двумя любыми узлами не должно превышать 2500 м,

  • в сети не должно быть более 1024 узлов.

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

Уточним основныепараметры операций передачи и приемакадров Ethernet, кратко описанные выше.

Станция,которая хочет передать кадр, должнасначала с помощью MAC-узла упаковатьданные в кадр соответствующего формата.

Затем для предотвращения смешениясигналов с сигналами другой передающейстанции, MAC-узел должен прослушиватьэлектрические сигналы на кабеле и вслучае обнаружения несущей частоты 10МГц отложить передачу своего кадра.

После окончания передачи по кабелюстанция должна выждать небольшуюдополнительную паузу, называемуюмежкадровым интервалом(interframe gap), что позволяетузлу назначения принять и обработатьпередаваемый кадр, и после этого начатьпередачу своего кадра.

Одновременнос передачей битов кадра приемно-передающееустройство узла следит за принимаемымипо общему кабелю битами, чтобы вовремяобнаружить коллизию. Если коллизия необнаружена, то передается весь кадр,поле чего MAC-уровень узла готов принятькадр из сети либо от LLC-уровня.

Еслиже фиксируется коллизия, то MAC-узелпрекращает передачу кадра и посылаетjam-последовательность, усиливающуюсостояние коллизии. После посылки всеть jam-последовательности MAC-узел делаетслучайную паузу и повторно пытаетсяпередать свой кадр.

В случаеповторных коллизий существует максимальновозможное число попытокповторной передачи кадра (attempt limit),которое равно 16. При достижении этогопредела фиксируется ошибка передачикадра, сообщение о которой передаетсяпротоколу верхнего уровня.

Длятого, чтобы уменьшить интенсивностьколлизий, каждый MAC-узел с каждой новойпопыткой случайным образом увеличиваетдлительность паузы между попытками.Временное расписание длительностипаузы определяется на основе усеченногодвоичного экспоненциального алгоритмаотсрочки (truncated binary exponential backoff).Пауза всегда составляет целое числотак называемых интервалов отсрочки.

Интервалотсрочки (slot time) – это время,в течение которого станция гарантированноможет узнать, что в сети нет коллизии.Это время тесно связано с другим важнымвременным параметром сети – окномколлизий (collision window).

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

Интервал отсрочки выбираетсяравным величине окна коллизий плюснекоторая дополнительная величиназадержки для гарантии:

интервалотсрочки = окно коллизий + дополнительнаязадержка

Встандартах 802.3 большинство временныхинтервалов измеряется в количествемежбитовых интервалов, величина которыхдля битовой скорости 10 Мб/с составляет0.1 мкс и равна времени передачи одногобита.

Величинаинтервала отсрочки в стандарте 802.3определена равной 512 битовым интервалам,и эта величина рассчитана для максимальнойдлины коаксиального кабеля в 2.5 км.

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

Времяпаузы после N-ой коллизии полагаетсяравным L интервалам отсрочки, где L -случайное целое число, равномернораспределенное в диапазоне [0, 2N]. Величинадиапазона растет только до 10 попытки(напомним, что их не может быть больше16), а далее диапазон остается равным [0,210], то есть [0, 1024]. Значения основныхпараметров процедуры передачи кадрастандарта 802.3 приведено в таблице 1.

Таблица1.

Битовая скорость

10 Мб/c

Интервал отсрочки

512 битовых интервалов

Межкадровый интервал

9.6 мкс

Максимальное число попыток передачи

16

Максимальное число возрастания диапазона паузы

10

Длина jam-последовательности

32 бита

Максимальная длина кадра (без преамбулы)

1518 байтов

Минимальная длина кадра (без преамбулы)

64 байта (512 бит)

Длина преамбулы

64 бита

Учитываяприведенные параметры, нетруднорассчитать максимальную производительностьсегмента Ethernet в таких единицах, какчисло переданных пакетов минимальнойдлины в секунду (packets-per-second, pps).

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

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

Источник: https://works.doklad.ru/view/zoSq7uWqHZo/2.html

ovdmitjb

Add comment