Онлайн
библиотека книг
Книги онлайн » Разная литература » Компьютерные сети. 6-е изд. - Эндрю Таненбаум

Шрифт:

-
+

Закладка:

Сделать
1 ... 152 153 154 155 156 157 158 159 160 ... 335
Перейти на страницу:
в заголовки пакетов. Затем стандартный алгоритм многоадресной маршрутизации строит связующее дерево, охватывающее всех членов группы. Этот алгоритм не является частью протокола RSVP. Единственное отличие от обычной многоадресной маршрутизации состоит в том, что группе периодически рассылается дополнительная информация, с помощью которой маршрутизаторы обновляют в памяти определенные структуры данных.

Рассмотрим сеть на илл. 5.32 (а). Хосты 1 и 2 — многоадресные отправители, а хосты 3, 4 и 5 — многоадресные получатели. В данном примере они разделены, однако в большинстве случаев эти два множества могут перекрываться. Деревья многоадресной рассылки для хостов 1 и 2 показаны на илл. 5.32 (б) и (в) соответственно.

Илл. 5.32. Протокол резервирования ресурсов (а) Сеть. (б) Связующее дерево многоадресной рассылки для хоста 1. (в) Связующее дерево многоадресной рассылки для хоста 2

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

Пример резервирования показан на илл. 5.33 (а). Здесь хост 3 запросил канал к хосту 1. После создания канала поток пакетов от хоста 1 к хосту 3 может идти без перегрузок. Рассмотрим, что произойдет, если теперь хост 3 зарезервирует канал к другому отправителю, хосту 2, чтобы пользователь мог одновременно смотреть две телевизионные программы. Резервирование второго канала показано на илл. 5.33 (б). Обратите внимание: между хостом 3 и маршрутизатором E должно быть два отдельных канала, так как передаются два независимых потока.

Илл. 5.33. Пример резервирования. (а) Хост 3 запрашивает канал к хосту 1. (б) Затем хост 3 запрашивает второй канал к хосту 2. (в) Хост 5 запрашивает канал к хосту 1

Наконец, на илл. 5.33 (в) хост 5 решает посмотреть программу, передаваемую хостом 1, и также резервирует себе канал. Сначала требуемая пропускная способность резервируется до маршрутизатора H. Затем он замечает, что у него уже есть канал от хоста 1, поэтому дополнительное резервирование выше по дереву не требуется. Обратите внимание, что хосты 3 и 5 могут запросить разную пропускную способность (например, у хоста 3 маленький экран, поэтому ему не нужно высокое разрешение). Следовательно, H должен зарезервировать пропускную способность, достаточную для получателя с самым большим запросом.

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

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

5.4.5. Дифференцированное обслуживание

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

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

Дифференцированное обслуживание может предоставляться набором маршрутизаторов, которые образуют административный домен (например, интернет-провайдер или телефонную компанию). Администрация определяет набор классов обслуживания и соответствующие правила маршрутизации. Пакеты от абонента, пользующегося дифференцированным обслуживанием, получают метку с информацией о классе. Эти сведения записываются в поле Differentiated services пакетов IPv4 и IPv6 (см. раздел 5.7.1). Классы определяются как поведение при переходах (per hop behaviors), так как они отвечают за то, что будет происходить с пакетом на маршрутизаторе, а не во всей сети. Таким пакетам предоставляется улучшенное обслуживание (например, премиум-обслуживание) по сравнению с остальными пакетами (обычное обслуживание). Может потребоваться, чтобы трафик внутри класса соответствовал определенной форме (например, дырявому ведру с заданной скоростью «вытекания» данных). Оператор с хорошим бизнес-чутьем может брать дополнительную плату за передачу каждого премиум-пакета либо установить абонентскую плату за передачу N таких пакетов в месяц. Обратите внимание: здесь не требуется никакой предварительной настройки, резервирования ресурсов и трудоемких согласований параметров для каждого потока, как при комплексном обслуживании. Это делает дифференцированное обслуживание относительно простым в реализации.

Система классов обслуживания встречается и в других сферах. Например, службы доставки посылок могут предлагать несколько уровней обслуживания на выбор: доставка на следующий день, через день или через два дня. Авиакомпании предлагают первый класс, бизнес-класс и эконом. То же самое касается поездов дальнего следования. В парижском метро одно время даже использовались два класса обслуживания при одинаковом качестве сидячих мест. Что касается нашей темы, то классы пакетов могут отличаться друг от друга задержкой, джиттером, вероятностью отклонения в случае коллизии, а также другими параметрами (которых, впрочем, не больше, чем у фреймов Ethernet).

Чтобы разница между QoS на основе классов и QoS на основе потоков стала яснее, рассмотрим пример: интернет-телефонию. В потоковой схеме каждому телефонному соединению предоставляются собственные ресурсы и гарантии, в классовой — все соединения совместно получают ресурсы, зарезервированные для данного класса. С одной стороны, эти ресурсы не может отнять

1 ... 152 153 154 155 156 157 158 159 160 ... 335
Перейти на страницу:

Еще книги автора «Эндрю Таненбаум»: