Раздел: Документация
0 ... 32 33 34 35 36 37 38 ... 55 -сеть осуществляет доставку этих пакетов в пункт назначения, куда они приходят, возможно, с нарушением порядка их передачи и с различной задержкой -приемная часть приложения (приемник) реконструирует источник данных из прибывших пакетов и с некоторой задержкой воспроизводит информационный сигнал настолько точно, насколько это оказывается возможным. Такие приложения в [73] получили название «Play-Ьаск Application)) (воспроизводящие). Вторую категорию составляют приложения, воспроизводящие данные, содержащиеся в пакетах, в том порядке, в котором они поступают в приемник. Для сетей с пакетной коммутацией такие приложения представляются крайне мало перспективными, а с позиций рассматриваемой архитектуры сети ISPN они могут быть использованы без всяких ограничений. Для приложений первого класса отмеченная предобработка их пакетов, очевидно, требует буферизации. Это позволяет демпфировать явление джиттера пакетов (неравномерность времени доставки), осуществить накопление определенного их числа и начать воспроизведение каждого блока информационной последовательности с задержкой т. Очевидно, что все пакеты, полученные до момента т, могут быть использованы для реконструкции информационного сигнала. Однако все, что получено после т, в этом отношении уже бесполезно. Рассматривая проблемы сервиса для приложений реального времени, отметим следующие факторы: -реализация функции интерактивности требует минимизации времени кодирования/декодирования информации и формирования/деформирования потока пакетов -для установления разумной величины т (следовательно, и объема буфера) приложение должно получить информацию о величине (максимально возможной или статистически вероятной) задержки передачи пакетов сетью -наличие буферизации пакетов в приемнике делает приложение индифферентным по отношению к порядку прибытия пакетов данных в пределах т -многие приложения реального времени вполне терпимы к определенному уровню потерь и искажений пакетов; следовательно, величина т не всегда должна быть настолько большой, чтобы все пакеты, составляющие единицу информационного потока, были получены к моменту начала воспроизведения. В целом, проблема определения необходимой величины т настолько существенна, что представляется целесообразным рассмотреть природу задержки передачи пакетов в сети. 5.2.2. Источники задержки передачи данных Существуют две составляющие величины времени задержки передачи пакетов данных в сети. Первая, фиксированная составляющая обусловлена характеристиками среды передачи, величиной пакета и количеством коммутирующих устройств на его пути. Вторая, имеющая варьируемую величину, обусловлена временем, которое каждый пакет затрачивает в очередях на обслуживание в коммутаторах (маршрутизаторах). Именно эта составляющая, обуславливающая явление джиттера, должна быть ограничена и, по возможности, минимизирована для обеспечения необходимого качества работы приложения реального времени. Обычно в сети одновременно существуют несколько источников данных с нерегулярным характером трафика, претендующих на один канал передачи. При этом непозволительно весь ресурс канала предоставить в распоряжение лишь одного источника. Архитектура сетевого сервиса ISPN должна быть таковой, чтобы все клиенты получили качество обслуживания более высокое, чем в обычной IP-сети и, одновременно, были защищены от потенциальных неприятностей, связанных с таким статистическим разделением канала. (Наиболее очевидной неприятностью является аномально высокий трафик, порождаемый одним из приложений). Для достижения приемлемого качества функционирования в определенной сетевой среде приложение должно располагать возможностью определить допустимый уровень потерь при доставке данных, что описывается вероятностью ошибочного приема пакета Рош и величину допустимой задержки воспроизведения т, необходимой для приема числа пакетов, достаточного для качественной реконструкции сигнала источников. Эти два параметра (т и Рош) составляют основу интерфейса «сеть - приложение». Некоторые из приложений реального времени используют получаемую от сети априорную оценку сверху величины возможной задержки передачи пакетов вне зависимости от ее реального значения. Такого рода приложения относятся к группе неадаптивных. Приемники других, адаптивных, приложений измеряют задержку, реально проявляющуюся в конкретных сетевых условиях, и устанавливают величину т, достаточную для приема минимально необходимого количества пакетов, гарантирующих заданное качество реконструкции источника сообщения. Ясно, что таким образом определяемая величина т будет меньше значения, устанавливаемого заранее и, следовательно, использование пропускной способности канала будет лучше. С другой стороны, любая стратегия адаптивного установления т не будет совершенной, и такие приложения могут иметь качественные показатели ниже, чем неадаптивные приложения. Механизмы адаптации, используемые на практике, достаточно разнообразны, а реализация их не столь уж и сложна, как может показаться. Так, видеоприло- жения могуг адаптироваться посредством пропуска некоторого количества кадров, а аудиоприложения добиваются адаптации небольшой регулировкой так называемого «интервала молчания». Естественно, что такие механизмы адаптации имеют границы, определяемые требованиями качества работы приложения. Другим критерием классификации приложений реального времени является их терпимость к кратковременным нарушениям сервиса. В этом отношении важны не только способность приложения продолжать свою работу, но и отношение пользователей к таким нарушениям. Так, например, если система КВКС обслуживает взаимодействие хирургов во время операции, то нарушения сервиса, даже кратковременные, будут совершенно недопустимы. Вместе с тем, сессия КВКС между членами семьи во время субботнего отдыха вполне может допустить временные сбои в передаче изображения (особенно, если это будет учтено в стоимости услуги). Таким образом, сетевые клиенты реального времени могут классифицироваться в двумерной системе координат вида «адаптивность, толерантность». Очевидные соображения приводят к выводу, что приложения, нетерпимые к нарушениям сервиса, одновременно должны быть и неадаптивными, а адаптивные приложения являются толерантными. Следовательно, можно констатировать, что в сети ISPN для приложений реального времени необходимы, как минимум, 2 класса сервиса: -гарантированный сервис [74], базирующийся на априорной оценке сверху возможной величины времени передачи пакетов в сети и предназначенный для нетолерантных и неадаптивных приложений -прогнозируемый сервис для толерантных приложений; его реализация предполагает, что определение времени доставки пакета базируется не на модели «наихудшего случая», а на статистической оценке поведения потока данных в системе. Этот вид сервиса в RFC 1633 получил название сервиса контролируемой загрузки [75] (controlled - load service). Основной задачей сервиса контролируемой загрузки является создание для приложений реального времени таких же условий работы, какие они имели бы в практически незагруженной IP-сети, располагающей лишь традиционными сервисными механизмами (так называемым «best-effort service»). Очевидно, что реализация сервиса контролируемой загрузки требует наличия определенного механизма контроля доступа к сетевым ресурсам (admission control). Рассмотренные виды сервиса, соответствующие модели интегрального обслуживания, определяют набор правил, по которым сеть выделяет свои ресурсы отдельным потокам. Это выделение ресурсов производится з момент обработки запроса доступа к сети и реализуется на уровне потока (т.е. ресурсы закрепляются за определенным потоком). При этом никак не определяется политика разделения ресурсов между группами потоков, объединяемых по определенным признакам. Этой цели служит модель разделения ресурсов. Напомним, что рассматривая задачу обслуживания отдельных потоков, мы фиксировали внимание на величине задержки доставки пакетов потока как на основной количественной характеристике, определяющей практически все параметры QoS для потока. С позиций же модели разделения ресурсов такой базисной характеристикой является общая емкость канала связи. Рассмотрим несколько примеров, иллюстрирующих возможные схемы решения задачи разделения канала между группами потребителей. Многопользовательское разделение канала. Канал связи может быть арендован и использоваться несколькими организациями. При этом необходимо гарантировать, что в условиях перегрузки каждый потребитель получит свою долю пропускной способности линии, пропорциональную его финансовым вложениям. В условиях же недогрузки канала каждый из потребителей может получить всю его свободную емкость. Многопротокольное разделение. В условиях многопротокольной среды Интернет может оказаться важным предотвращение перегрузки линий потоками, соответствующими одному из семейств протоколов (DecNet, IP, IPX, SNA и т.п.). Проблема заключается в том, что методы детектирования состояния перегрузки канала у разных протоколов отличаются степенью своей «агрессивности», и невозможность соединения по одному из протоколов может возникнуть существенно раньше, чем по другому. Предупреждение такой ситуации требует тонкой настройки маршрутизаторов и, соответственно, формирования определенных правил разделения емкости линий между потоками разных протоколов. Разделение канала на уровне приложений. Даже в рамках, например, IP-приложений может быть необходимым введение ограничений на используемую определенным классом приложений емкость канала. Так, для обеспечения нормальной работы служб FTP может оказаться полезным ограничить долю пропускной способности канала, выделяемую для мультимедийных приложений. В целом, модель разделения ресурсов - это набор правил деления полной пропускной способности канала. Выше мы отметили, что контроль доступа к сетевым ресурсам необходим для обеспечения качества обслуживания потоков данных реального времени. Аналогично, он необходим и для реализации правил разделения канала. Следовательно, процедуры контроля доступа к ресурсам сети должны учитывать как фактор времени доставки потока, так и фактор доступности необходимой емкости канала связи. Таким образом, общая модель сети ISPN включает в себя: -механизмы оценки или измерения характеристик трафика -алгоритмы контроля доступа к совместно используемым ресурсам -механизмы резервирования ресурсов, определяющие способы, котоыми приложение согласовывает необходимый ему уровень качества обслуживания со всеми устройствами, участвующими в соединении. 5.2.3. Обобщенная схема реализации модели интегрального обслуживания Для последующего обсуждения следует уточнить понятие «поток данных» (data How), которое до сих пор использовалось в интуитивно ясном смысле. «Поток» в RFC 1633 определяется как однонаправленная последовательность дейтограмм, имеющая один источник и требующая одного и того же уровня качества обслуживания. Поток может иметь п адресов назначения (в групповых соединениях). Сетевое приложение реального времени должно располагать возможностью описания своих потоков, что необходимо, прежде всего, для реализации процедур классификации пакетов и, в конечном итоге, обеспечения необходимого уровня качества обслуживания. Кроме того, это требуется для управления собственно источником трафика. С этой целью определена структурированная переменная T Spec, значения полей которой могут задаваться пользователем или поступать от сетевого интерфейса. Эта структура включает в себя параметры фильтра TBF (Token Bucket Filter - фильтр «маркерная корзина»), верхнюю границу интенсивности потока «Р» (кбайт/с), минимальный (т) и максимальный (М) размер пакета потока (кбайт). Фильтр TBF является основным механизмом регулирования потребления данным потоком выделенного ему ресурса (части емкости канала). Он описывается двумя параметрами: интенсивностью генерации маркеров - «г» (кбит/с) и «объемом корзины» - b (кбит). Действие фильтра основывается на предположении, что «корзина» непрерывно заполняется маркерами, и каждый генерируемый приложением пакет размером s кбит потребляет из корзины S маркеров. Если источник в момент t, генерирует i-ый пакет размером S„ то можно утверждать, что он согласован с TBF (г, Ь) при условии, что для любого i справедливо [107]: rij = min [ b, rij i + (t, - tj i) • r - Sj ] > 0, n0 = b Величина n-lf если она удовлетворяет приведенному выше неравенству, показывает, сколько маркеров осталось в корзине после ухода i-ro пакета. Если п, < 0, то передача i-oro пакета на сетевой интерфейс оказывается невозможной. Базисными элементами обобщенной схемы реализации модели интегрального обслуживания являются блок контроля трафика и протокол резервирования ресурсов. При этом, в отличие от традиционного IP-сервиса (best-effort service), эта модель требует, чтобы не только конечные станции, но и маршрутизаторы содержали в своих операционных системах инструменты обеспечения необходимого уровня качества обслуживания для каждого потока. Именно эту задачу и решает блок контроля трафика. Последний реализуется посредством трех программных компонент - диспетчера пакетов, классификатора пакетов и блока контроля доступа. Диспетчер пакетов управляет передачей разных потоков, используя какой-либо алгоритм управления очередями. Вероятно, наиболее простым алгоритмом является приоритетная очередь, в которой пакеты с более высоким приоритетом обслуживаются в первую очередь. Однако при наличии большого числа таких пакетов низкоприоритетные потоки вообще могут не получить доступа к выходному каналу. Альтернативой может служить кольцевая (карусельная) схема очереди, предоставляющая различным классам потоков доступ к выходному порту на основе пропорционального разделения общей пропускной способности канала. Могут использоваться и другие, более сложные, алгоритмы управления очередями В большинстве своем они базируются на анализе значений тех полей заголовка пакетов, которые отражают их индивидуальные сервисные характеристики (например, предельное время доставки). Существенное влияние на функционирование диспетчера оказывает и выбор стратегии отбрасывания пакетов в случае переполнения его выходного буфера. В контексте сервиса реального времени стратегия уничтожения «лишних» пакетов существенно более тесно связана с задачей обеспечения необходимого уровня качества обслуживания, чем в случае традиционного IP-сервиса. Действительно, отбрасывание одного из пакетов очереди ведет к уменьшению времени доставки всех последующих и может, таким образом, служить дополнительным инструментом обеспечения заявленного уровня обслуживания потока. Вместе с тем очевидно, что в ситуации заполненности буфера простое отбрасывание прибывающих пакетов не является оптимальным решением. В случае приоритетной очереди отбрасыванию должны подвергаться прежде всего низкоприоритетные пакеты. Например, для видеопотока MPEG-приложения таковыми могут быть пакеты, соответствующие В-кадрам. В целом, стратегия устранения переполнения очереди и алгоритм управления ею должны быть хорошо согласованы. Диспетчер функционирует на уровне выходного драйвера операционной системы и соответствует протоколу звена передачи данных (канальный уровень модели OSI). Диспетчер пакетов включает в себя и блок оценивания параметров выходного трафика, что необходимо для управления очередями и для работы процедур контроля доступа. Классификатор пакетов. Для контроля и учета трафика каждый поступающий на маршрутизатор пакет должен быть отнесен к определенному классу обслуживания (все пакеты одного класса получают одинаковое обслуживание). Процесс классификации реализуется посредством сравнения информации, извлекаемой из заголовка сетевого пакета с данными, содержащимися в переменной Flow Spec. Поля этой структурированной переменной определяются в ходе выполнения процедур резервирования ресурсов и могут содержать сетевые адреса, номера портов источника и получателя пакета, идентификатор 0 ... 32 33 34 35 36 37 38 ... 55
|
