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

В условиях реализации упрощенного варианта предоставления услуг, когда эти два класса трафика никак не разделяются в процессе обслуживания, единственный способ обеспечения гарантий не превышения согласованных в SLA уровней задержек и вариаций задержек - это содержание сетевых ресурсов в недогруженном состоянии. Другими словами, оператор, который не утруждает себя внедрением систем дифференцированного обслуживания, вынужден содержать ресурсы своей сети недогруженными. В этом случае, коэффициент использования каждого ресурса, как показывает практика, не должен превышать 0,2-0,3, поскольку только при таких достаточно «расточительных» условиях пакеты, принадлежащие раз ным классам, будут продвигаться по своим маршрутам с минимальными задержками. Допустим, что в рамках этого упрощённого варианта предоставления услуг оператор сети всё же будет пытаться более эффективно загружать свои ресурсы, например, на уровнях (по коэффициенту загрузки) 0,6-0,7 (здесь следует иметь в виду, что определенную часть пропускной способности необходимо резервировать для передачи служебного трафика). Тогда такой оператор сможет, более или менее, качественно обслужить только тех пользователей, трафик которых является нечувствительным к задержкам. Так что, «упрощённый» подход к обслуживанию, когда разные классы трафика не разделяются в процессе. обслуживания, вряд ли, можно считать рациональным. Во многих практически важных случаях желательно уметь различать классы трафика и выполнять решение задачи инженерии потоков данных с учетом существования различий в требованиях к качеству обслуживания.

Если осуществляется инженерия трафика разных классов, то в расширениях протоколов маршрутизации необходимо обеспечить отдельный учет загрузок каждого ресурса сети в разрезе каждого класса трафика. При этом, как показывает практика, коэффициент загрузки любого сетевого ресурса трафиком, чувствительным к задержкам, должен не превышать 0,2-0,3, в то время как для обработки трафика, не чувствительного к задержкам, этот коэффициент может выбираться в пределах 0,6-0,7. Если, при этом, чувствительный к задержкам трафик будет обслуживаться в одной приоритетной очереди, а не чувствительный трафик - по схеме обслуживания «с максимальными усилиями», то трафик каждого из вышеназванных классов с большой долей вероятности получит необходимый для него уровень обслуживания. Вышеприведенное иллюстрируется на графике (см. рис. 5.11), отображающем зависимость средней задержки пакетов т от выбранного коэффициента загрузки сетевого ресурса К.

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

Рисунок 5.11- Зависимость средней задержки пакетов от уровня загрузки сетевого ресурса жно быть связано два счетчика загрузки: один счётчик - для приоритетного, чувствительного к задержкам, трафика; второй - для не чувствительного к задержкам (фонового) трафика. Допустим, возникнет необходимость добавления к уже существующим двум потокам дополнительного потока приоритетного класса. Следовательно, в этом случае, возникнет необходимость определения возможности прохождения этого дополнительного потока через какой-либо конкретный сетевой ресурс. Тогда в процессе проверки обеспечения такой возможности необходимо сравнивать между собой среднюю интенсивность нового потока со свободной долей производительности ресурса, которая не задействована для обслуживания существующего приоритетного трафика.

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

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

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

ТЕХНОЛОГИИ ОЦЕНИВАНИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА ПЕРЕДАЧ И ДАННЫХ В СЕТЯХ С ПАКЕТНОЙ КОММУТАЦИЕЙ

⇐Механизмы реализации выбранных маршрутов | Сети передачи пакетных данных | Характеристика транспортных услуг - виды транспортных услуг и услуг некоммутируемого доступа⇒