Викиконспекты - Вклад участника [ru]

Компьютерные сети

2017-01-25T21:18:59Z

Дмитриев Дмитрий: /* Блок 2 */

=Блок 1=
* [[Коммутация на канальном уровне]]
* [[Сети с общей средой передачи данных (подуровень MAC, протоколы)]]
* [[Физическое кодирование]]
* [[Канальный уровень]]
* [[Физический уровень]]
* [[Ethernet]]
* [[Bluetooth]]
* [[Виртуальные локальные сети]]
* [[Протоколы стандарта 802.11]]
* [[Data link layer - LLC]]
* [[Data link layer - Flow control]]
* [[Data link layer - MAC - Aloha, CSMA]]

=Блок 2=
* [[Сетевой уровень]]
* [[Алгоритмы маршрутизации]]
* [[Broadcast. Broadcast routing.]]
* [[Мультикаст. Мультикаст маршрутизация]]
* [[IP]]
* [[Управляющие протоколы Internet]]
* [[Протоколы внешнего и внутреннего шлюза]]
* [[IPv6]]
* [[Транспортный уровень]]
* [[Протоколы транспортного уровня (TCP, UDP, SCTP)]]

=Блок 3=
* [[DHCP]]
* [[Служба DNS. Пространство имен в Internet]]
* [[Служба электронной почты]]
* [[WWW. HTTP. Основы и развитие]]
* [[FTP. Telnet. SSH]]
* [[Авторизация. Аутентификация. Аудит. Radius. Diameter]]
* [[Шифрование]]
* [[SSL/TLS]]
* [[IPsec]]
* [[Протоколы аутентификации]]
* [[Firewall. Концепция, примеры]]
* [[SIP. Телефония поверх IP]]
* [[Одноранговые сети]]
* [[Сетевые атаки. Классификация, описания]]
* [[Мультимедиа поверх IP. RTSP]]
* [[NAT]]
* [[LTE и WiFi]]
* [[WAN - особенности, принципы построения сетей]]
* [[Wireless networks - WAN]]
* [[LAN - особенности топологии]]
* [[Wireless networks - PAN]]

Алгоритмы маршрутизации

2017-01-25T21:18:49Z

Дмитриев Дмитрий: Новая страница: «'''Алгоритмы маршрутизации''' применяются для нахождения наилучшего пути между хостами с...»

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

==Заливка(flooding)==
Алгоритм заливки является одним из самых простых, в нем каждый приходящий пакет пересылается на все исходящие линии, кроме той по которой он пришел.
====Дубликаты пакетов====
Этот алгоритм порождает много лишних пакетов, а в сетях с замкнутыми контурами бесконечное число пакетов, поэтому в заголовок пакета помещают счетчик пройденных им транзитных участков, каждый маршрутизатор, при получении этого пакета и пересылкой дальше уменьшает этот счетчик на единицу. Как только значение счетчика достигает нуля пакет дальше не пересылается. Изначально этот счетчик можно задать равным длине максимального пути в сети, или длине пути от отправителя до получателя, если она известна. Тем не менее один и тот же маршрутизатор может отправлять один и тот же пакет несколько раз, если получил его с разных линий. Один из методов борьбы с отправкой одного и того же пакета много раз состоит в том, что каждый маршрутизатор нумерует каждый пакет получаемый от своих хостов и добавляет этот номер в заголовок. Все маршрутизаторы ведут для всех маршрутизаторов-источников счетчик, хранящий максимальный номер полученного от него пакета. Теперь, когда приходит пакет с номером меньшим, чем тот, что храниться в счетчике пакет вместо пересылки просто игнорируется, поскольку этот пакет уже был переслан.
====Преимущества====
*гарантированно доставляет пакет
*может быть эффективен при широковещательной рассылке
*надежен
*не требует настройки, поэтому может быть использован внутри другого более сложного алгоритма
*удобен для тестирования, так как находит все пути от источника к получателю, в том числа и кратчайшие
====Недостатки====
*дублирование пакетов
*не практичен, так как увеличивает нагрузку на сеть

==Маршрутизация по вектору расстояний(distance vector routing)==
Алгоритмы маршрутизации работают опираясь на таблицы(называемые векторами), поддерживаемые всеми маршрутизаторами и содержащие сведения о кратчайших путях к каждому из возможных адресатов и о том, какую линию соединения при этом использовать. Для обновления этих таблиц маршрутизаторы периодически обмениваются информацией с соседними маршрутизаторами.

Каждая запись таблицы состоит из двух частей: предпочитаемые номер линии для данного адресата и предполагаемое расстояние до него. Будем считать, что каждый маршрутизатор знает расстояние до своих соседей(если расстояние изменяется в транзитных участках то оно равно 1, а если же расстояние измеряется временем задержки распространения, то маршрутизатор может измерить его с помощью специального пакета <tex>ECHO</tex>, в который отправитель помещает время отправления, а получатель отправляет обратно как можно быстрее). Каждые <tex>T</tex> мс все маршрутизаторы посылают свои таблицы всем своим соседям и получают подобные вектора от них. Пусть одна из таких таблиц пришла от соседа <tex>X</tex> и в ней указано расстояние от маршрутизатора <tex>X</tex> до маршрутизатора <tex>Y</tex>, обозначим его <tex>T_{xy}</tex>. Если маршрутизатор знает, что расстояние между ним и маршрутизатором <tex>X</tex> равно <tex>T_x</tex>, то расстояние до маршрутизатора <tex>Y</tex> через маршрутизатор <tex>X</tex> равно <tex>T_x + T_{xy}</tex>. Выполнив такие расчеты для всех своих соседей маршрутизатор может выбрать наилучшие пути и поместить их в соответствующую запись таблицы.

====Проблема счета до бесконечности====
Рассмотрим ситуацию: пусть в сети 5 маршрутизаторов <tex>A, B, C, D, E</tex>, соединенных последовательно. Изначально все они включены и расстояние измеряется в количестве транзитных участков. Внезапно связь между маршрутизаторами <tex>A</tex> и <tex>B</tex> теряется, либо <tex>A</tex> просто отключается. При первом обмене пакетами <tex>B</tex> не слышит ответа от <tex>A</tex>, но маршрутизатор <tex>C</tex> сообщает, что он знает путь до <tex>A</tex> длиной 2. Маршрутизатор <tex>B</tex> изменяет запись в таблице и считает, что теперь у него есть путь длиной 3 до маршрутизатора <tex>A</tex>. Аналогично, при следующей рассылке маршрутизатор <tex>C</tex> установит в своей таблице путь до <tex>A</tex> равным 4, так как получит от маршрутизаторов <tex>B</tex> и <tex>D</tex> таблицы, по которым они знают путь до маршрутизатора <tex>A</tex> длиной 3. С каждой следующей итерацией обновления таблиц расстояние до маршрутизатора <tex>A</tex> будет только увеличивается и через какое-то время уйдет в бесконечность.

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

====Недостатки====
*проблемы счета до бесконечности

==Маршрутизация с учетом состояния линий(link state routing)==
В основе данного алгоритма лежит простая идея каждый маршрутизатор должен уметь:
*обнаруживать своих соседей и узнавать расстояние до них
*задавать метрику расстояния с каждым из своих соседей
*создавать пакет, содержащий всю собранную информацию
*посылать этот пакет другим маршрутизаторам и принимать от них аналогичные
*вычислять кратчайший путь до всех маршрутизаторов
В результате выполнения всех этих пунктов каждый маршрутизатор будет иметь в своем распоряжении полную топологию сети и может запустить [[Алгоритм Дейкстры|алгоритм Дейкстры]] для определения кратчайших путей. Рассмотрим эти пункты подробнее.
====Знакомство с соседями====
Как только маршрутизатор загружается ему нужно получить информацию от соседей, для этого он посылает специальный пакет <tex>HELLO</tex>. В ответ маршрутизатор на другом конце линии посылает ответ, содержащий свое имя. Имена маршрутизаторов должны быть совершенно уникальными.
В случае соединений <tex>point-to-point</tex> проблем не возникает, но если некоторые маршрутизаторы соединены широковещательной связью ситуация усложняется. Пусть, например, маршрутизаторы <tex>A, B, C</tex> соединены широковещательной связью. Моделирование данной модели в виде связей <tex>point-to-point</tex> будет сильно увеличивать размер топологии, поэтому создает искусственный узел, назовем его <tex>N</tex>, соответствующий самой широковещательной связи. На самом деле роль этого узла будет играть один из маршрутизаторов <tex>A, B, C</tex>. Теперь, передача пакетов от <tex>A</tex> к <tex>C</tex> будет следовать по пути <tex>ANC</tex>.
====Задание метрики расстояний====
Метрика расстояния между двумя соседними маршрутизаторами может быть задана автоматически или оператором сети. Чаще всего ее задают обратно пропорциональной пропускной способности линии, благодаря этому будут выбираться пути с большей пропускной способностью. Второй способ заключается в определении задержки специального пакета <tex>ECHO</tex>, на который принимающий его маршрутизатор должен незамедлительно ответить. В это случае будут выбираться пути с наименьшей задержкой.
====Создание пакета состояния линий====
Специальный пакет для обмена информацией между соседними маршрутизаторами начинается с идентификатора отправителя, за которым следует порядковый номер и возраст. Далее для каждого соседа указывается соответствующая стоимость пути с ним. Важен вопрос времени создания этих пакетов. Обычно используются два варианта, первый заключается в том, что такие пакета создаются через определенные равные интервалы времени; второй - в те момента, когда в сети происходит какое-то событие, например линия или маршрутизатор выходят из строя или, наоборот, появляются в сети.
====Распространение пакетов состояния линий====
Распространение пакетов состояния линий - это самая сложная часть алгоритма. Все маршрутизаторы должны принимать такие пакеты как можно быстрее и безотказно, иначе может сложится ситуация, в которой маршрутизаторы могут использовать разные версии топологии, что может привести к петлям или недоступностям машин.
Самый простой способ распространения таких пакетов заключается в использовании алгоритма заливки. Для этого в пакет добавляется порядковый номер, увеличивающий с каждым следующим пакетом(см. [[Алгоритмы маршритизации#Заливка|алгоритм заливки]]).

С этим связано несколько проблем. Первая из них заключается в том, что порядковый номер может достигнуть максимального значения. Решение заключается в использовании 32-битных порядковых номеров, в этом случае даже если каждую секунду рассылать пакеты состояния линий, то порядковых номеров хватит больше, чем 137 лет.
Вторая заключается в том, что если маршрутизатор выключится будет потерян порядковый номер последнего отправленного пакета состояния линий. Если же в последствии он включится с нулевым номером, то часть пакетов будут проигнорированы как устаревшие.
Еще одна проблема состоит в том, что при пересылки пакетов могут произойти искажения, в следствии чего может измениться порядковый номер пакета, и некоторые следующие пакеты могут быть проигнорированы.
Решением двух последних проблем является добавление в пакет его возраста и уменьшении его на единицу каждую секунду. Когда возраст доходит до нуля, он считается устаревшим и данные об маршрутизаторе-отправителе сбрасываются, в том числе и счетчик полученных от него пакетов.

Для повышения надежности могут быть использованы некоторые усовершенствования. Например, когда пакет состояния линий приходит на маршрутизатор для заливки, он может быть поставлен в очередь на отправку не сразу, а через какой-то промежуток времени. Если в течении этого времени приходит еще один пакет от этого же маршрутизатора-отправителя, то маршрутизатор сравнивает их номера, и удаляется более старый пакет. А если номера совпадают, то удаляется дубликат. Так же для защиты от ошибок на линиях связи получение всех пакетов состояния линий подтверждается.
====Вычисление новых маршрутов====
Собрав полный комплект пакетов состояния линий, маршрутизатор может построить полный граф сети, так как он располагает данными о всех линиях. Теперь для построения кратчайших путей можно запустить [[Алгоритм Дейкстры|алгоритм Дейкстры]].
====Преимущества====
*отсутствие проблем медленного распространения новостей
====Недостатки====
*требуется большое количество памяти для хранения топологии сети
*требуется большое количество вычислительных ресурсом маршрутизатора
==Источники информации==
*Э. Таненбаум, Д.Уэзеролл - Компьютерные сети (5-е издание, 2012)
*[https://ru.wikipedia.org/wiki/Алгоритмы_маршрутизации Алгоритмы маршрутизации - Википедия]

Алгоритмы маршритизации

2017-01-25T21:15:14Z

Дмитриев Дмитрий: /* Источники информации */

Алгоритмы маршритизации

2017-01-25T21:14:15Z

Дмитриев Дмитрий:

Алгоритмы маршритизации

2017-01-25T21:11:35Z

Дмитриев Дмитрий:

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

==Заливка(flooding)==
Алгоритм заливки является одним из самых простых, в нем каждый приходящий пакет пересылается на все исходящие линии, кроме той по которой он пришел.
====Дубликаты пакетов====
Этот алгоритм порождает много лишних пакетов, а в сетях с замкнутыми контурами бесконечное число пакетов, поэтому в заголовок пакета помещают счетчик пройденных им транзитных участков, каждый маршрутизатор, при получении этого пакета и пересылкой дальше уменьшает этот счетчик на единицу. Как только значение счетчика достигает нуля пакет дальше не пересылается. Изначально этот счетчик можно задать равным длине максимального пути в сети, или длине пути от отправителя до получателя, если она известна. Тем не менее один и тот же маршрутизатор может отправлять один и тот же пакет несколько раз, если получил его с разных линий. Один из методов борьбы с отправкой одного и того же пакета много раз состоит в том, что каждый маршрутизатор нумерует каждый пакет получаемый от своих хостов и добавляет этот номер в заголовок. Все маршрутизаторы ведут для всех маршрутизаторов-источников счетчик, хранящий максимальный номер полученного от него пакета. Теперь, когда приходит пакет с номером меньшим, чем тот, что храниться в счетчике пакет вместо пересылки просто игнорируется, поскольку этот пакет уже был переслан.
====Преимущества====
*гарантированно доставляет пакет
*может быть эффективен при широковещательной рассылке
*надежен
*не требует настройки, поэтому может быть использован внутри другого более сложного алгоритма
*удобен для тестирования, так как находит все пути от источника к получателю, в том числа и кратчайшие
====Недостатки====
*дублирование пакетов
*не практичен, так как увеличивает нагрузку на сеть

==Маршрутизация по вектору расстояний(distance vector routing)==
Алгоритмы маршрутизации работают опираясь на таблицы(называемые векторами), поддерживаемые всеми маршрутизаторами и содержащие сведения о кратчайших путях к каждому из возможных адресатов и о том, какую линию соединения при этом использовать. Для обновления этих таблиц маршрутизаторы периодически обмениваются информацией с соседними маршрутизаторами.

Каждая запись таблицы состоит из двух частей: предпочитаемые номер линии для данного адресата и предполагаемое расстояние до него. Будем считать, что каждый маршрутизатор знает расстояние до своих соседей(если расстояние изменяется в транзитных участках то оно равно 1, а если же расстояние измеряется временем задержки распространения, то маршрутизатор может измерить его с помощью специального пакета <tex>ECHO</tex>, в который отправитель помещает время отправления, а получатель отправляет обратно как можно быстрее). Каждые <tex>T</tex> мс все маршрутизаторы посылают свои таблицы всем своим соседям и получают подобные вектора от них. Пусть одна из таких таблиц пришла от соседа <tex>X</tex> и в ней указано расстояние от маршрутизатора <tex>X</tex> до маршрутизатора <tex>Y</tex>, обозначим его <tex>T_{xy}</tex>. Если маршрутизатор знает, что расстояние между ним и маршрутизатором <tex>X</tex> равно <tex>T_x</tex>, то расстояние до маршрутизатора <tex>Y</tex> через маршрутизатор <tex>X</tex> равно <tex>T_x + T_{xy}</tex>. Выполнив такие расчеты для всех своих соседей маршрутизатор может выбрать наилучшие пути и поместить их в соответствующую запись таблицы.

====Проблема счета до бесконечности====
Рассмотрим ситуацию: пусть в сети 5 маршрутизаторов <tex>A, B, C, D, E</tex>, соединенных последовательно. Изначально все они включены и расстояние измеряется в количестве транзитных участков. Внезапно связь между маршрутизаторами <tex>A</tex> и <tex>B</tex> теряется, либо <tex>A</tex> просто отключается. При первом обмене пакетами <tex>B</tex> не слышит ответа от <tex>A</tex>, но маршрутизатор <tex>C</tex> сообщает, что он знает путь до <tex>A</tex> длиной 2. Маршрутизатор <tex>B</tex> изменяет запись в таблице и считает, что теперь у него есть путь длиной 3 до маршрутизатора <tex>A</tex>. Аналогично, при следующей рассылке маршрутизатор <tex>C</tex> установит в своей таблице путь до <tex>A</tex> равным 4, так как получит от маршрутизаторов <tex>B</tex> и <tex>D</tex> таблицы, по которым они знают путь до маршрутизатора <tex>A</tex> длиной 3. С каждой следующей итерацией обновления таблиц расстояние до маршрутизатора <tex>A</tex> будет только увеличивается и через какое-то время уйдет в бесконечность.

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

====Недостатки====
*проблемы счета до бесконечности

==Маршрутизация с учетом состояния линий==
В основе данного алгоритма лежит простая идея каждый маршрутизатор должен уметь:
*обнаруживать своих соседей и узнавать расстояние до них
*задавать метрику расстояния с каждым из своих соседей
*создавать пакет, содержащий всю собранную информацию
*посылать этот пакет другим маршрутизаторам и принимать от них аналогичные
*вычислять кратчайший путь до всех маршрутизаторов
В результате выполнения всех этих пунктов каждый маршрутизатор будет иметь в своем распоряжении полную топологию сети и может запустить [[Алгоритм Дейкстры|алгоритм Дейкстры]] для определения кратчайших путей. Рассмотрим эти пункты подробнее.
====Знакомство с соседями====
Как только маршрутизатор загружается ему нужно получить информацию от соседей, для этого он посылает специальный пакет <tex>HELLO</tex>. В ответ маршрутизатор на другом конце линии посылает ответ, содержащий свое имя. Имена маршрутизаторов должны быть совершенно уникальными.
В случае соединений <tex>point-to-point</tex> проблем не возникает, но если некоторые маршрутизаторы соединены широковещательной связью ситуация усложняется. Пусть, например, маршрутизаторы <tex>A, B, C</tex> соединены широковещательной связью. Моделирование данной модели в виде связей <tex>point-to-point</tex> будет сильно увеличивать размер топологии, поэтому создает искусственный узел, назовем его <tex>N</tex>, соответствующий самой широковещательной связи. На самом деле роль этого узла будет играть один из маршрутизаторов <tex>A, B, C</tex>. Теперь, передача пакетов от <tex>A</tex> к <tex>C</tex> будет следовать по пути <tex>ANC</tex>.
====Задание метрики расстояний====
Метрика расстояния между двумя соседними маршрутизаторами может быть задана автоматически или оператором сети. Чаще всего ее задают обратно пропорциональной пропускной способности линии, благодаря этому будут выбираться пути с большей пропускной способностью. Второй способ заключается в определении задержки специального пакета <tex>ECHO</tex>, на который принимающий его маршрутизатор должен незамедлительно ответить. В это случае будут выбираться пути с наименьшей задержкой.
====Создание пакета состояния линий====
Специальный пакет для обмена информацией между соседними маршрутизаторами начинается с идентификатора отправителя, за которым следует порядковый номер и возраст. Далее для каждого соседа указывается соответствующая стоимость пути с ним. Важен вопрос времени создания этих пакетов. Обычно используются два варианта, первый заключается в том, что такие пакета создаются через определенные равные интервалы времени; второй - в те момента, когда в сети происходит какое-то событие, например линия или маршрутизатор выходят из строя или, наоборот, появляются в сети.
====Распространение пакетов состояния линий====
Распространение пакетов состояния линий - это самая сложная часть алгоритма. Все маршрутизаторы должны принимать такие пакеты как можно быстрее и безотказно, иначе может сложится ситуация, в которой маршрутизаторы могут использовать разные версии топологии, что может привести к петлям или недоступностям машин.
Самый простой способ распространения таких пакетов заключается в использовании алгоритма заливки. Для этого в пакет добавляется порядковый номер, увеличивающий с каждым следующим пакетом(см. [[Алгоритмы маршритизации#Заливка|алгоритм заливки]]).

С этим связано несколько проблем. Первая из них заключается в том, что порядковый номер может достигнуть максимального значения. Решение заключается в использовании 32-битных порядковых номеров, в этом случае даже если каждую секунду рассылать пакеты состояния линий, то порядковых номеров хватит больше, чем 137 лет.
Вторая заключается в том, что если маршрутизатор выключится будет потерян порядковый номер последнего отправленного пакета состояния линий. Если же в последствии он включится с нулевым номером, то часть пакетов будут проигнорированы как устаревшие.
Еще одна проблема состоит в том, что при пересылки пакетов могут произойти искажения, в следствии чего может измениться порядковый номер пакета, и некоторые следующие пакеты могут быть проигнорированы.
Решением двух последних проблем является добавление в пакет его возраста и уменьшении его на единицу каждую секунду. Когда возраст доходит до нуля, он считается устаревшим и данные об маршрутизаторе-отправителе сбрасываются, в том числе и счетчик полученных от него пакетов.

Для повышения надежности могут быть использованы некоторые усовершенствования. Например, когда пакет состояния линий приходит на маршрутизатор для заливки, он может быть поставлен в очередь на отправку не сразу, а через какой-то промежуток времени. Если в течении этого времени приходит еще один пакет от этого же маршрутизатора-отправителя, то маршрутизатор сравнивает их номера, и удаляется более старый пакет. А если номера совпадают, то удаляется дубликат. Так же для защиты от ошибок на линиях связи получение всех пакетов состояния линий подтверждается.
====Вычисление новых маршрутов====
Собрав полный комплект пакетов состояния линий, маршрутизатор может построить полный граф сети, так как он располагает данными о всех линиях. Теперь для построения кратчайших путей можно запустить [[Алгоритм Дейкстры|алгоритм Дейкстры]].
====Преимущества====
*отсутствие проблем медленного распространения новостей
====Недостатки====
*требуется большое количество памяти для хранения топологии сети
*требуется большое количество вычислительных ресурсом маршрутизатора

Алгоритмы маршритизации

2017-01-25T20:50:00Z

Дмитриев Дмитрий:

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

==Заливка(flooding)==
Алгоритм заливки является одним из самых простых, в нем каждый приходящий пакет пересылается на все исходящие линии, кроме той по которой он пришел.
====Дубликаты пакетов====
Этот алгоритм порождает много лишних пакетов, а в сетях с замкнутыми контурами бесконечное число пакетов, поэтому в заголовок пакета помещают счетчик пройденных им транзитных участков, каждый маршрутизатор, при получении этого пакета и пересылкой дальше уменьшает этот счетчик на единицу. Как только значение счетчика достигает нуля пакет дальше не пересылается. Изначально этот счетчик можно задать равным длине максимального пути в сети, или длине пути от отправителя до получателя, если она известна. Тем не менее один и тот же маршрутизатор может отправлять один и тот же пакет несколько раз, если получил его с разных линий. Один из методов борьбы с отправкой одного и того же пакета много раз состоит в том, что каждый маршрутизатор нумерует каждый пакет получаемый от своих хостов и добавляет этот номер в заголовок. Все маршрутизаторы ведут для всех маршрутизаторов-источников счетчик, хранящий максимальный номер полученного от него пакета. Теперь, когда приходит пакет с номером меньшим, чем тот, что храниться в счетчике пакет вместо пересылки просто игнорируется, поскольку этот пакет уже был переслан.
====Преимущества====
*гарантированно доставляет пакет
*может быть эффективен при широковещательной рассылке
*надежен
*не требует настройки, поэтому может быть использован внутри другого более сложного алгоритма
*удобен для тестирования, так как находит все пути от источника к получателю, в том числа и кратчайшие
====Недостатки====
*дублирование пакетов
*не практичен, так как увеличивает нагрузку на сеть

==Маршрутизация по вектору расстояний(distance vector routing)==
Алгоритмы маршрутизации работают опираясь на таблицы(называемые векторами), поддерживаемые всеми маршрутизаторами и содержащие сведения о кратчайших путях к каждому из возможных адресатов и о том, какую линию соединения при этом использовать. Для обновления этих таблиц маршрутизаторы периодически обмениваются информацией с соседними маршрутизаторами.

Каждая запись таблицы состоит из двух частей: предпочитаемые номер линии для данного адресата и предполагаемое расстояние до него. Будем считать, что каждый маршрутизатор знает расстояние до своих соседей(если расстояние изменяется в транзитных участках то оно равно 1, а если же расстояние измеряется временем задержки распространения, то маршрутизатор может измерить его с помощью специального пакета <tex>ECHO</tex>, в который отправитель помещает время отправления, а получатель отправляет обратно как можно быстрее). Каждые <tex>T</tex> мс все маршрутизаторы посылают свои таблицы всем своим соседям и получают подобные вектора от них. Пусть одна из таких таблиц пришла от соседа <tex>X</tex> и в ней указано расстояние от маршрутизатора <tex>X</tex> до маршрутизатора <tex>Y</tex>, обозначим его <tex>T_{xy}</tex>. Если маршрутизатор знает, что расстояние между ним и маршрутизатором <tex>X</tex> равно <tex>T_x</tex>, то расстояние до маршрутизатора <tex>Y</tex> через маршрутизатор <tex>X</tex> равно <tex>T_x + T_{xy}</tex>. Выполнив такие расчеты для всех своих соседей маршрутизатор может выбрать наилучшие пути и поместить их в соответствующую запись таблицы.

====Проблема счета до бесконечности====
Рассмотрим ситуацию: пусть в сети 5 маршрутизаторов <tex>A, B, C, D, E</tex>, соединенных последовательно. Изначально все они включены и расстояние измеряется в количестве транзитных участков. Внезапно связь между маршрутизаторами <tex>A</tex> и <tex>B</tex> теряется, либо <tex>A</tex> просто отключается. При первом обмене пакетами <tex>B</tex> не слышит ответа от <tex>A</tex>, но маршрутизатор <tex>C</tex> сообщает, что он знает путь до <tex>A</tex> длиной 2. Маршрутизатор <tex>B</tex> изменяет запись в таблице и считает, что теперь у него есть путь длиной 3 до маршрутизатора <tex>A</tex>. Аналогично, при следующей рассылке маршрутизатор <tex>C</tex> установит в своей таблице путь до <tex>A</tex> равным 4, так как получит от маршрутизаторов <tex>B</tex> и <tex>D</tex> таблицы, по которым они знают путь до маршрутизатора <tex>A</tex> длиной 3. С каждой следующей итерацией обновления таблиц расстояние до маршрутизатора <tex>A</tex> будет только увеличивается и через какое-то время уйдет в бесконечность.

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

====Недостатки====
*проблемы счета до бесконечности

==Маршрутизация с учетом состояния линий==
В основе данного алгоритма лежит простая идея каждый маршрутизатор должен уметь:
*обнаруживать своих соседей и узнавать расстояние до них
*задавать метрику расстояния с каждым из своих соседей
*создавать пакет, содержащий всю собранную информацию
*посылать этот пакет другим маршрутизаторам и принимать от них аналогичные
*вычислять кратчайший путь до всех маршрутизаторов
В результате выполнения всех этих пунктов каждый маршрутизатор будет иметь в своем распоряжении полную топологию сети и может запустить алгоритм Дейкстры для определения кратчайших путей. Рассмотрим эти пункты подробнее.
====Знакомство с соседями====
Как только маршрутизатор загружается ему нужно получить информацию от соседей, для этого он посылает специальный пакет <tex>HELLO</tex>. В ответ маршрутизатор на другом конце линии посылает ответ, содержащий свое имя. Имена маршрутизаторов должны быть совершенно уникальными.
В случае соединений <tex>point-to-point</tex> проблем не возникает, но если некоторые маршрутизаторы соединены широковещательной связью ситуация усложняется. Пусть, например, маршрутизаторы <tex>A, B, C</tex> соединены широковещательной связью. Моделирование данной модели в виде связей <tex>point-to-point</tex> будет сильно увеличивать размер топологии, поэтому создает искусственный узел, назовем его <tex>N</tex>, соответствующий самой широковещательной связи. На самом деле роль этого узла будет играть один из маршрутизаторов <tex>A, B, C</tex>. Теперь, передача пакетов от <tex>A</tex> к <tex>C</tex> будет следовать по пути <tex>ANC</tex>.
====Задание метрики расстояний====
Метрика расстояния между двумя соседними маршрутизаторами может быть задана автоматически или оператором сети. Чаще всего ее задают обратно пропорциональной пропускной способности линии, благодаря этому будут выбираться пути с большей пропускной способностью. Второй способ заключается в определении задержки специального пакета <tex>ECHO</tex>, на который принимающий его маршрутизатор должен незамедлительно ответить. В это случае будут выбираться пути с наименьшей задержкой.
====Создание пакета состояния линий====
Специальный пакет для обмена информацией между соседними маршрутизаторами начинается с идентификатора отправителя, за которым следует порядковый номер и возраст. Далее для каждого соседа указывается соответствующая стоимость пути с ним. Важен вопрос времени создания этих пакетов. Обычно используются два варианта, первый заключается в том, что такие пакета создаются через определенные равные интервалы времени; второй - в те момента, когда в сети происходит какое-то событие, например линия или маршрутизатор выходят из строя или, наоборот, появляются в сети.
====Распространение пакетов состояния линий====
Распространение пакетов состояния линий - это самая сложная часть алгоритма. Все маршрутизаторы должны принимать такие пакеты как можно быстрее и безотказно, иначе может сложится ситуация, в которой маршрутизаторы могут использовать разные версии топологии, что может привести к петлям или недоступностям машин.
Самый простой способ распространения таких пакетов заключается в использовании алгоритма заливки. Для этого в пакет добавляется порядковый номер, увеличивающий с каждым следующим пакетом(см. [[#Заливка|алгоритм заливки]])

Алгоритмы маршритизации

2017-01-24T10:28:49Z

Дмитриев Дмитрий:

Алгоритмы маршритизации

2017-01-24T10:17:32Z

Дмитриев Дмитрий:

Data link layer - LLC

2016-12-11T21:46:10Z

Дмитриев Дмитрий:

{|class="standard" align="right" border ="1" style="text-align:center"
!OSI
!IEEE
|-
|rowspan = "2" | Канальный
|LLC
|-
|MAC
|-
|Физический
|Физический
|}
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI. В компьютерах функции канального уровня реализуются совместными усилиями сетевых адаптеров и их драйверов.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр [[Ethernet | Ethernet]]).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

{|class="standard" align="center" border ="1"
!Флаг
!DSAP
!SSAP
!Control
!Data
!Флаг
|-
|01111110
|Адрес точки входа сервиса назначения
|Адрес точки входа сервиса источника
|Управляющее поле
|Данные
|01111110
|}

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определения границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней, иногда может отсутствовать в управляющих и ненумерованных кадрах.

Поле управления однобайтовое(ненумерованные кадры) или двухбайтовое(информационные и управляющие кадры), и используется для обозначения типа кадра(информационный, управляющий или ненумерованный).
{|class="standard" align="center" border ="1" style="text-align:center"
|-
!Биты
|1
|colspan = "4" | 2-8
|9
|10-16
|-
!Информационные
|0
|colspan = "4" | <math>N(S)</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Управляющие
|1
|0
|<math>SS</math>
|colspan = "2" | <math>XXXX</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Ненумерованные
|1
|1
|<math>MM</math>
|<math>P/F</math>
|<math>MM</math>
|}
В режиме LLC1 используются только ненумерованные кадры. Для этого кадра управляющее поле имеет длину один байт, а все подполя поля управления ненумерованных кадров принимают нулевые значения. Таким образом, значимыми остаются только первые 2 бита поля, используемые для обозначения типа кадра.
[[Файл:Connect.png | right]]
В режиме LLC2 используются кадры всех трех типов. Бит <math>P/F(Poll/Final)</math>: в командах он называется битом <math>Poll</math> и требует, чтобы на команду был дан ответ, в ответах он называется битом <math>Final</math> и говорит, что ответ состоит из одного кадра.
Ненумерованные кадры используются для установления и разрыва соединения двух узлов. Поле <math>M</math> ненумерованных кадров определяет несколько типов команд:
* Установить сбалансированный асинхронный расширенный режим (SABME). Эта команда является запросом на установление соединения. Расширенный режим означает использование двухбайтных полей управления для кадров остальных двух типов.
* Ненумерованное подтверждение (UA). Служит для подтверждения установления или разрыва соединения.
* Сброс соединения (REST). Запрос на разрыв соединения.
После установления соединения данные и положительные квитанции начинают передаваться в информационных кадрах. Логический канал протокола LLC2 является дуплексным, так что данные могут передаваться в обоих направлениях. Если поток дуплексный, то положительные квитанции на кадры также доставляются в информационных кадрах. Если же потока кадров в обратном направлении нет или же нужно передать отрицательную квитанцию, то используются информационные кадры.

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

Приемник всегда помнит номер последнего кадра, принятого от передатчика, и поддерживает переменную с указанным номером кадра, который он ожидает принять от передатчика следующим. Именно это значение передается в поле N(R) кадра, посылаемого передатчику. Если в ответ на этот кадр приемник принимает кадр, в котором номер посланного кадра N(S) совпадает с номером ожидаемого кадра, то такой кадр считается корректным (если, конечно, корректна его контрольная сумма). Если приемник принимает кадр с номером N(S), неравным номеру ожидаемого кадра, то этот кадр отбрасывается и посылается отрицательная квитанция Отказ (REJ) с номером этого кадра. При приеме отрицательной квитанции передатчик обязан повторить передачу кадра с номером указанным в отрицательной квитанции, а также всех кадров с большими номерами, которые он уже успел отослать, пользуясь механизмом окна в 127 кадров(если используется [[Канальный уровень#Протоколы с возвратом на N | протокол с возвратом на N]]).

Поле <math>SS</math> обозначает одну из функций управления:
* Отказ (REJect), биты устанавливаются разными <math>00</math>;
* Приемник не готов (Receiver Not Ready, RNR), биты устанавливаются равными <math>10</math>;
* Приемник готов (Receiver Ready, RR), биты устанавливаются равными <math>01</math>.

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

Биты <math>XXXX</math> зарезервированы и должны иметь нулевые значения.

Адресные поля DSAP и SSAP занимают по 1 байту. Они позволяют указать, какая служба верхнего уровня пересылает данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, чтобы передать извлеченный из кадра пакет нужному протоколу верхнего уровня для последующей обработки. Для идентификации этих протоколов вводятся так называемые адреса точки входа службы (Service Access Point, SAP). Значения адресов SAP приписываются протоколам в соответствии со стандартом 802.2. Например, для протокола IP значение SAP равно <math>0</math>x<math>6</math>. Для одних служб определена только одна точка входа и, соответственно, только один SAP, а для других - несколько, когда адреса DSAP и SSAP совпадают. Например, если в кадре LLC значения DSAP и SSAP содержат код протокола IPX, то обмен кадрами осуществляется между двумя IPX-модулями, выполняющимися в разных узлах. Но в некоторых случаях в кадре LLC указываются различающиеся DSAP и SSAP. Это возможно только в тех случаях, когда служба имеет несколько адресов SAP, что может быть использовано протоколом узла отправителя в специальных целях, например для уведомления узла получателя о переходе протокола-отправителя в некоторый специфический режим работы.

==См. также==
*[[Канальный уровень | Data link layer]]
*[[Data link layer - Flow control | Data link layer - Flow control]]
*[[Data link layer - MAC - Aloha, CSMA | Data link layer - MAC - Aloha, CSMA]]

==Источники==
*Э. Таненбаум, Д.Уэзеролл - Компьютерные сети (5-е издание, 2012)
*[https://ru.wikipedia.org/wiki/Logical_link_control Logical link control - Википедия]

Файл:Connect.png

2016-12-11T21:20:23Z

Дмитриев Дмитрий: загружена новая версия «Файл:Connect.png»

Data link layer - LLC

2016-12-11T21:16:08Z

Дмитриев Дмитрий: /* Формат кадра LLC */

{|class="standard" align="right" border ="1" style="text-align:center"
!OSI
!IEEE
|-
|rowspan = "2" | Канальный
|LLC
|-
|MAC
|-
|Физический
|Физический
|}
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр [[Ethernet | Ethernet]]).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

{|class="standard" align="center" border ="1"
!Флаг
!DSAP
!SSAP
!Control
!Data
!Флаг
|-
|01111110
|Адрес точки входа сервиса назначения
|Адрес точки входа сервиса источника
|Управляющее поле
|Данные
|01111110
|}

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определения границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней, иногда может отсутствовать в управляющих и ненумерованных кадрах.

Поле управления однобайтовое(ненумерованные кадры) или двухбайтовое(информационные и управляющие кадры), и используется для обозначения типа кадра(информационный, управляющий или ненумерованный).
{|class="standard" align="center" border ="1" style="text-align:center"
|-
!Биты
|1
|colspan = "4" | 2-8
|9
|10-16
|-
!Информационные
|0
|colspan = "4" | <math>N(S)</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Управляющие
|1
|0
|<math>SS</math>
|colspan = "2" | <math>XXXX</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Ненумерованные
|1
|1
|<math>MM</math>
|<math>P/F</math>
|<math>MM</math>
|}
В режиме LLC1 используются только ненумерованные кадры. Для этого кадра управляющее поле имеет длину один байт, а все подполя поля управления ненумерованных кадров принимают нулевые значения. Таким образом, значимыми остаются только первые 2 бита поля, используемые для обозначения типа кадра.
[[Файл:Connect.png | right]]
В режиме LLC2 используются кадры всех трех типов. Бит <math>P/F(Poll/Final)</math>: в командах он называется битом <math>Poll</math> и требует, чтобы на команду был дан ответ, в ответах он называется битом <math>Final</math> и говорит, что ответ состоит из одного кадра.
Ненумерованные кадры используются для установления и разрыва соединения двух узлов. Поле <math>M</math> ненумерованных кадров определяет несколько типов команд:
* Установить сбалансированный асинхронный расширенный режим (SABME). Эта команда является запросом на установление соединения. Расширенный режим означает использование двухбайтных полей управления для кадров остальных двух типов.
* Ненумерованное подтверждение (UA). Служит для подтверждения установления или разрыва соединения.
* Сброс соединения (REST). Запрос на разрыв соединения.
После установления соединения данные и положительные квитанции начинают передаваться в информационных кадрах. Логический канал протокола LLC2 является дуплексным, так что данные могут передаваться в обоих направлениях. Если поток дуплексный, то положительные квитанции на кадры также доставляются в информационных кадрах. Если же потока кадров в обратном направлении нет или же нужно передать отрицательную квитанцию, то используются информационные кадры.

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

Приемник всегда помнит номер последнего кадра, принятого от передатчика, и поддерживает переменную с указанным номером кадра, который он ожидает принять от передатчика следующим. Именно это значение передается в поле N(R) кадра, посылаемого передатчику. Если в ответ на этот кадр приемник принимает кадр, в котором номер посланного кадра N(S) совпадает с номером ожидаемого кадра, то такой кадр считается корректным (если, конечно, корректна его контрольная сумма). Если приемник принимает кадр с номером N(S), неравным номеру ожидаемого кадра, то этот кадр отбрасывается и посылается отрицательная квитанция Отказ (REJ) с номером этого кадра. При приеме отрицательной квитанции передатчик обязан повторить передачу кадра с номером указанным в отрицательной квитанции, а также всех кадров с большими номерами, которые он уже успел отослать, пользуясь механизмом окна в 127 кадров(если используется [[Канальный уровень#Протоколы с возвратом на N | протокол с возвратом на N]]).

Поле <math>SS</math> обозначает одну из функций управления:
* Отказ (REJect), биты устанавливаются разными <math>00</math>;
* Приемник не готов (Receiver Not Ready, RNR), биты устанавливаются равными <math>10</math>;
* Приемник готов (Receiver Ready, RR), биты устанавливаются равными <math>01</math>.

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

Биты <math>XXXX</math> зарезервированы и должны иметь нулевые значения.

Адресные поля DSAP и SSAP занимают по 1 байту. Они позволяют указать, какая служба верхнего уровня пересылает данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, чтобы передать извлеченный из кадра пакет нужному протоколу верхнего уровня для последующей обработки. Для идентификации этих протоколов вводятся так называемые адреса точки входа службы (Service Access Point, SAP). Значения адресов SAP приписываются протоколам в соответствии со стандартом 802.2. Например, для протокола IP значение SAP равно <math>0</math>x<math>6</math>. Для одних служб определена только одна точка входа и, соответственно, только один SAP, а для других - несколько, когда адреса DSAP и SSAP совпадают. Например, если в кадре LLC значения DSAP и SSAP содержат код протокола IPX, то обмен кадрами осуществляется между двумя IPX-модулями, выполняющимися в разных узлах. Но в некоторых случаях в кадре LLC указываются различающиеся DSAP и SSAP. Это возможно только в тех случаях, когда служба имеет несколько адресов SAP, что может быть использовано протоколом узла отправителя в специальных целях, например для уведомления узла получателя о переходе протокола-отправителя в некоторый специфический режим работы.

==См. также==
*[[Канальный уровень | Data link layer]]
*[[Data link layer - Flow control | Data link layer - Flow control]]
*[[Data link layer - MAC - Aloha, CSMA | Data link layer - MAC - Aloha, CSMA]]

==Источники==
*Э. Таненбаум, Д.Уэзеролл - Компьютерные сети (5-е издание, 2012)
*[https://ru.wikipedia.org/wiki/Logical_link_control Logical link control - Википедия]

Файл:Connect.png

2016-12-11T21:15:07Z

Дмитриев Дмитрий:

Data link layer - LLC

2016-12-10T11:42:59Z

Дмитриев Дмитрий: /* Формат кадра LLC */

{|class="standard" align="right" border ="1" style="text-align:center"
!OSI
!IEEE
|-
|rowspan = "2" | Канальный
|LLC
|-
|MAC
|-
|Физический
|Физический
|}
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр [[Ethernet | Ethernet]]).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

{|class="standard" align="center" border ="1"
!Флаг
!DSAP
!SSAP
!Control
!Data
!Флаг
|-
|01111110
|Адрес точки входа сервиса назначения
|Адрес точки входа сервиса источника
|Управляющее поле
|Данные
|01111110
|}

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определения границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней, иногда может отсутствовать в управляющих и ненумерованных кадрах.

Поле управления однобайтовое(ненумерованные кадры) или двухбайтовое(информационные и управляющие кадры), и используется для обозначения типа кадра(информационный, управляющий или ненумерованный).
{|class="standard" align="center" border ="1" style="text-align:center"
|-
!Биты
|1
|colspan = "4" | 2-8
|9
|10-16
|-
!Информационные
|0
|colspan = "4" | <math>N(S)</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Управляющие
|1
|0
|<math>SS</math>
|colspan = "2" | <math>XXXX</math>
|<math>P/F</math>
|<math>N(R)</math>
|-
!Ненумерованные
|1
|1
|<math>MM</math>
|<math>P/F</math>
|<math>MM</math>
|}
В режиме LLC1 используются только ненумерованные кадры. Для этого кадра управляющее поле имеет длину один байт, а все подполя поля управления ненумерованных кадров принимают нулевые значения. Таким образом, значимыми остаются только первые 2 бита поля, используемые для обозначения типа кадра.
[[Файл:Conn.jpg | right]]
В режиме LLC2 используются кадры всех трех типов. Бит <math>P/F(Poll/Final)</math>: в командах он называется битом <math>Poll</math> и требует, чтобы на команду был дан ответ, в ответах он называется битом <math>Final</math> и говорит, что ответ состоит из одного кадра.
Ненумерованные кадры используются для установления и разрыва соединения двух узлов. Поле <math>M</math> ненумерованных кадров определяет несколько типов команд:
* Установить сбалансированный асинхронный расширенный режим (SABME). Эта команда является запросом на установление соединения. Расширенный режим означает использование двухбайтных полей управления для кадров остальных двух типов.
* Ненумерованное подтверждение (UA). Служит для подтверждения установления или разрыва соединения.
* Сброс соединения (REST). Запрос на разрыв соединения.
После установления соединения данные и положительные квитанции начинают передаваться в информационных кадрах. Логический канал протокола LLC2 является дуплексным, так что данные могут передаваться в обоих направлениях. Если поток дуплексный, то положительные квитанции на кадры также доставляются в информационных кадрах. Если же потока кадров в обратном направлении нет или же нужно передать отрицательную квитанцию, то используются информационные кадры.

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

Приемник всегда помнит номер последнего кадра, принятого от передатчика, и поддерживает переменную с указанным номером кадра, который он ожидает принять от передатчика следующим. Именно это значение передается в поле N(R) кадра, посылаемого передатчику. Если в ответ на этот кадр приемник принимает кадр, в котором номер посланного кадра N(S) совпадает с номером ожидаемого кадра, то такой кадр считается корректным (если, конечно, корректна его контрольная сумма). Если приемник принимает кадр с номером N(S), неравным номеру ожидаемого кадра, то этот кадр отбрасывается и посылается отрицательная квитанция Отказ (REJ) с номером этого кадра. При приеме отрицательной квитанции передатчик обязан повторить передачу кадра с номером указанным в отрицательной квитанции, а также всех кадров с большими номерами, которые он уже успел отослать, пользуясь механизмом окна в 127 кадров(если используется [[Канальный уровень#Протоколы с возвратом на N | протокол с возвратом на N]]).

Поле <math>SS</math> обозначает одну из функций управления:
* Отказ (REJect), биты устанавливаются разными <math>00</math>;
* Приемник не готов (Receiver Not Ready, RNR), биты устанавливаются равными <math>10</math>;
* Приемник готов (Receiver Ready, RR), биты устанавливаются равными <math>01</math>.

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

Биты <math>XXXX</math> зарезервированы и должны иметь нулевые значения.

Адресные поля DSAP и SSAP занимают по 1 байту. Они позволяют указать, какая служба верхнего уровня пересылает данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, чтобы передать извлеченный из кадра пакет нужному протоколу верхнего уровня для последующей обработки. Для идентификации этих протоколов вводятся так называемые адреса точки входа службы (Service Access Point, SAP). Значения адресов SAP приписываются протоколам в соответствии со стандартом 802.2. Например, для протокола IP значение SAP равно <math>0</math>x<math>6</math>. Для одних служб определена только одна точка входа и, соответственно, только один SAP, а для других - несколько, когда адреса DSAP и SSAP совпадают. Например, если в кадре LLC значения DSAP и SSAP содержат код протокола IPX, то обмен кадрами осуществляется между двумя IPX-модулями, выполняющимися в разных узлах. Но в некоторых случаях в кадре LLC указываются различающиеся DSAP и SSAP. Это возможно только в тех случаях, когда служба имеет несколько адресов SAP, что может быть использовано протоколом узла отправителя в специальных целях, например для уведомления узла получателя о переходе протокола-отправителя в некоторый специфический режим работы.

==См. также==
*[[Канальный уровень | Data link layer]]
*[[Data link layer - Flow control | Data link layer - Flow control]]
*[[Data link layer - MAC - Aloha, CSMA | Data link layer - MAC - Aloha, CSMA]]

==Источники==
*Э. Таненбаум, Д.Уэзеролл - Компьютерные сети (5-е издание, 2012)
*[https://ru.wikipedia.org/wiki/Logical_link_control Logical link control - Википедия]

Файл:Conn.jpg

2016-12-10T10:58:35Z

Дмитриев Дмитрий:

Data link layer - LLC

2016-12-08T12:07:43Z

Дмитриев Дмитрий: /* Формат кадра LLC */

Data link layer - LLC

2016-12-08T12:05:12Z

Дмитриев Дмитрий: /* Формат кадра LLC */

Data link layer - LLC

2016-12-08T11:57:43Z

Дмитриев Дмитрий: /* Сервисы уровня LLC */

Data link layer - LLC

2016-12-08T11:48:22Z

Дмитриев Дмитрий: /* Протокол LLC */

Data link layer - LLC

2016-12-08T11:47:32Z

Дмитриев Дмитрий:

Data link layer - LLC

2016-12-08T11:39:33Z

Дмитриев Дмитрий:

[[Файл:LLC1.png | right]]
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC имеет общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

{|class="standard" align="center" border ="1"
!Флаг
!DSAP
!SSAP
!Control
!Data
!Флаг
|-
|01111110
|Адрес точки входа сервиса назначения
|Адрес точки входа сервиса источника
|Управляющее поле
|Данные
|01111110
|}

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определение границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней.
Поле управления однобайтовое и используется для обозначения типа кадра(информационный, управляющий или ненумерованный). Так же в этом поле указываются порядковые номера отправленных и успешно принятых кадров, если LLC уровень работает по сервису LLC2. Поля DSAP и SSAP позволяют указать какой сервис верхнего уровня пересылается данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, для того, чтобы передать извлеченный из кадра пакет нужному протоколу для последующей обработки.

==См. также==
*[[Канальный уровень | Data link layer]]
*[[Data link layer - Flow control | Data link layer - Flow control]]
*[[Data link layer - MAC - Aloha, CSMA | Data link layer - MAC - Aloha, CSMA]]

==Источники==
*Э. Таненбаум, Д.Уэзеролл - Компьютерные сети (5-е издание, 2012)
*[https://ru.wikipedia.org/wiki/Logical_link_control Logical link control - Википедия]

Файл:Кадр.jpg

2016-12-08T11:30:22Z

Дмитриев Дмитрий:

Data link layer - LLC

2016-12-08T11:29:06Z

Дмитриев Дмитрий:

[[Файл:LLC1.png | right]]
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC имеет общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)
[[Файл:кадр.jpg]]

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определение границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней.
Поле управления однобайтовое и используется для обозначения типа кадра(информационный, управляющий или ненумерованный). Так же в этом поле указываются порядковые номера отправленных и успешно принятых кадров, если LLC уровень работает по сервису LLC2. Поля DSAP и SSAP позволяют указать какой сервис верхнего уровня пересылается данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, для того, чтобы передать извлеченный из кадра пакет нужному протоколу для последующей обработки.

Файл:LLC1.png

2016-12-08T11:25:43Z

Дмитриев Дмитрий: LLC находится между подуровнем MAС и сетевым уровнем

LLC находится между подуровнем MAС и сетевым уровнем

Data link layer - LLC

2016-12-08T11:21:49Z

Дмитриев Дмитрий:

[[Файл:LLC1.png | right]]
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC имеет общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определение границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней.
Поле управления однобайтовое и используется для обозначения типа кадра(информационный, управляющий или ненумерованный). Так же в этом поле указываются порядковые номера отправленных и успешно принятых кадров, если LLC уровень работает по сервису LLC2. Поля DSAP и SSAP позволяют указать какой сервис верхнего уровня пересылается данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, для того, чтобы передать извлеченный из кадра пакет нужному протоколу для последующей обработки.

Data link layer - LLC

2016-12-08T11:18:54Z

Дмитриев Дмитрий:

[[Файл:LLC.png | right]]
'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня [[Data link layer - MAC - Aloha, CSMA | MAC]], который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками, если какой-то кадр теряется из-за шума, на канальном уровне не предпринимается никаких попыток восстановить его. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет, например, в линиях связи реального времени или в каналах с низкой вероятности ошибки или потери кадра. Примером канального уровня, предоставляющего такой сервис, является [[Ethernet | Ethernet]].

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

Сервис LLC3 так же, как и LLC1 не устанавливает логического соединения, но получение каждого кадра подтверждается. Таким образом, отправитель знает, дошел ли кадр до принимающей стороны в целости, был испорчен в пути или не дошел вовсе. Если в течении определенного интервала не поступает подтверждения, что кадр успешно доставлен, или поступает ответ от получателя о том, что кадр был испорчен, то отправитель посылает данный кадр заново. Такой сервис полезен в случае использования каналов с высокой вероятностью ошибок, например в беспроводных сетях. К сервисам такого класса можно отнести [[LTE и WiFi#Wi-Fi | 802.11(WiFi)]].

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

===Формат кадра LLC===
У всех кадров протокола LLC имеет общий формат:
#адрес точки входа сервиса назначения (Destination Service Access Point, DSAP)
#адрес точки входа сервиса источника (Source Service Access Point, SSAP)
#управляющее поле (Control, CTRL)
#поле данных (Data)

Кадр LLC обрамляется двумя однобайтовыми флагами, имеющими значение 01111110. Эти флаги используются на [[Data link layer - MAC - Aloha, CSMA | MAC]] уровне для определение границ блоков. Поле данных кадра LLC предназначено для передачи по сети данных, приходящих от верхних уровней.
Поле управления однобайтовое и используется для обозначения типа кадра(информационный, управляющий или ненумерованный). Так же в этом поле указываются порядковые номера отправленных и успешно принятых кадров, если LLC уровень работает по сервису LLC2. Поля DSAP и SSAP позволяют указать какой сервис верхнего уровня пересылается данные с помощью этого кадра. Программному обеспечению узлов сети при получении кадров канального уровня необходимо распознать, какой протокол вложил свой пакет в поле данных поступившего кадра, для того, чтобы передать извлеченный из кадра пакет нужному протоколу для последующей обработки.

Файл:LLC.png

2016-12-08T11:14:42Z

Дмитриев Дмитрий: LLC занимаем место между подуровнем MAC и сетевым уровнем.

LLC занимаем место между подуровнем MAC и сетевым уровнем.

Data link layer - LLC

2016-12-08T09:10:12Z

Дмитриев Дмитрий:

'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической связью — по стандарту IEEE 802 — верхний подуровень канального уровня модели OSI.

==Задачи==
Основными задачами подуровня LLC является:
# передача кадров данных между узлами с различной степенью надежности.
# обеспечение проверки и правильности передачи информации по соединению.
# предоставление интерфейса [[Сетевой уровень | сетевому уровню]].

==Протокол LLC==
Протокол LLC обеспечивает для технологий локальных сетей нужное качество услуг транспортной службы, передавая свои кадры либо дейтаграммным способом, либо с помощью процедур с установлением соединения и восстановлением кадров. LLC передает свой кадр вместе с адресной информацией об узле назначения соответствующему протоколу уровня MAC, который упаковывает кадр LLC в свой кадр (например, кадр Ethernet).
===Сервисы уровня LLC===
В соответствии со стандартом IEEE 802.2 уровень управления логическим каналом предоставляет верхним уровням три типа процедур:
#LLC1, Type1, connectionless – сервис без установления соединения и без подтверждения.
#LLC2, Type2, connection-oriented – сервис c установлением соединения и с подтверждением.
#LLC3, Type3 – сервис без установления соединения, но с подтверждением.
Сервис LLC1 предоставляет пользователю средства для передачи с минимальными издержками. Данный сервис, обычно, используется, когда задачи восстановления потерянных данных, их упорядочивание и восстановление после ошибок выполняются вышележащими уровнями, и нужды в их дублировании нет.

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

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

===Типы кадров уровня LLC===
#Информационные кадры (Information, I-frame) предназначены для передачи информации в процедурах LLC2, обязательно содержат поле информации.
#Управляющие кадры (Supervisory, S-frame) предназначены для передачи команд и ответов в процедурах LLC2.
#Ненумерованные кадры (Unnumbered, U-frame) – передача информации, тестирование и идентификация LLC уровня в LLC1 и LLC3, установление и разъединение логического соединения, а также информирование об ошибках в LLC2.

Информационные кадры предназначены для передачи информации в процедурах с установлением логического соединения и обязательно должны содержать поле информации. Нумерация информационных кадров осуществляется в режиме [[Канальный уровень#Протоколы скользящего окна | скользящего окна]].

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

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

Data link layer - LLC

2016-12-07T11:51:54Z

Дмитриев Дмитрий: Новая страница: «'''Logical link control''' (общепринятое сокращение {{---}} LLC) {{---}} подуровень управления логической св...»