В. Столлингс - Современные компьютерные сети (2-е издание, 2003) (1114681), страница 139

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

Текст из файла (страница 139)

Первый шаг представляет собой локальную функцию. Шаги 2 и 3 должны выполняться либо во время ручной настройки, либо прн помощи некоего протокола распределения меток. Таким образом, сущность протокола распределения меток закл>очается в том, что он позволяет одному 15Й-маршрутизатору информировать остальные 152-маршрутизаторы о назначенных нм соответствиях между метками и ГЕС-классами. Кроме того, протокол распределения меток позволяет двум 15 В-марн>рутизаторам узнать возможности друг дру>а, относящиеся к архитектуре МР! 5. Архитектура МР15 не предполагает применения единого протокола распределения меток, а позволяет использовать несколько таких протоколов.

В частности, в КГС 3031 для атой цели описыва>отея новый протокол распределения меток и усовершенствованные существуюп>ие протоколы, такие как ЙЯЧР и ВОР. Взаимосвязь между распределением меток и выбором маршрутов довольно запутана. Лучше всего рассмотреть ее в контексте двух типов маршрутизации. При выборе маршрутов на уровне ретрансляционных участков, как мы вилелн не уделяется особого внимания вопросам конструирования трафика или маршру ' ЦРС 2676, ЦоХ До«г>вв Мевваввпи вп>1 ОХР>«Еаеп»опь, аз>уст 1999. ООО Глава 1В. Протоколы поддержания качества обслуживания 13,3, Протокол ПТР 601 тизации на основе политики.

В этом случае для определения следуюшст 'ц го р~рзнсляционного участка на каждом 1.ЯК-марн>рутизаторе применяется обыч о ычныйпр такал маршрутизации, например ОБРЕ. Относительно простой проток токая распределения меток может работать при помощи протокола маршрутизации. При явном выборе марн>ругов должен быть реализован болеее ложный маршрутизации без единой метрики прокладки маршрута. В этом случ.

ом слУчае протокол распрелеления меток может использовать специальный протокол м. ол маршр~ и зации, например усовершенствованный протокол ОЯРР, или включить чить алгоритм выбора маршрута в более сложный протокол распрелелепия меток. 18.3. Протокол ВТР Наиболее популярным протоколом транспортного уровня является протокол ТСР (Тгапзш!зз!оп Сопгго! Ргогосо! — протокол управления передачей). Хотя протокол ТСР доказал свое значение в плане поддержания широкого диапазона рас распределенных приложений, он не годится для обслуживания распределенных приложений реального времени. Под распределенным приложением реального времени мы подразумеваем приложение, в котором источник генерирует поток данных с постояннои скоростью, а один или несколько получателей должны доставлять данные приложению с той >ке самой постоянной скоростью.

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

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

+ П Протокол ТСР не содер>кит удобного механизма, позволяюгцего синхрониаировать временную информацию с сегментами, что является еше одним требованием прило>кений реального времени. Другой широко применяемый транспортный прото>сел, П!>Р (Пзег Пагадга>п Ргогосо! — пользовательский протокол дейтаграмм), не обладает первыми двумя перечисленными характеристиками протокола ТСР, но, как и протокол ТСР, не предоставляет синхропизирующей информации.

Сам по себе протокол П!>Р не предоставляет универсальных инструментов, полезных для приложений еаль"р ' ного времени. Хотя каждое приложение реального времени может солержать собственные змы поддержки транспорта реального времени, сушествует ряд обших характеристик, служащих основанном для определения обшего протокола, которым стал протокол КТР (Кеа[-гппе Тгапзрогг Ргогосо! — транспортный протокол реального времени), определенный в КГС 1889'. Протокол КТР луч>це всего подходит для гибкого взаимодействия реального времени. Ему не достает механизмов, необходимых для поддержки жесткого графика реалыюго времени, В этом разделе предоставляется обзор протокола КТР. Мы начнем с обсуждения требований транспорта реального времени. Затем мы изучим философский аспект КТР.

Оставшаяся часть данного раздела посвящена двум протоколам, составляющим протокол КТР: протоколу передачи данных, называемому просто КТР, и протоколу КТСР (КТР Сапего! Ргогосо! — управляюгдий протокол КТР). Архитектура протокола ВТР В протоколе КТР наблюдается тесная связь между функциональностью протокола КТР и функциональностью прикладного уровня. В самом деле, протокол КТР лучше всего рассматривать как архитектуру, которой приложения могут пользоваться напрямую для реализапии единого протокола. Без информации, специфичной для конкретного приложения, протокол КТР оказывается неполным. С другой стороны, протокол КТР формирует структуру и определяет общие функции, так что отдельные приложения реального времени освобождаются от части их задач.

Протокол КТР следует принципам архитектуры протоколов, отмеченным в [51]. Два ключевых понятия, представленных в этой статье, — это форм>грование кадров на прикладном уровне и интегрированная многоуровневая обработка. Формирование кадров на прикладном уровне В традиционном транспортном протоколе, таком как ТСР, ответственность за восстановление потерянных при передаче данных выполняется иа транспортном уровне прозрачно для прикладного уровня.

В [5Ц перечисляются два сценария, в которых восстановление потерянных данных лучше перелож>ггь на плечи приложения: + Приложение в определенных пределах способно выдержать несовершенство доставки и продолжать работу. Это, например, аудио- и видеоприложения реального времени. Для та>а>х приложений, возможно, необходимо информировать источник о качестве доставки, а не требовать повторной передачи данных. Если потеряно слишком много данных, источник, возможно, предпочтет перейтп на режим передачи с пониженным качеством, предъявляющим более низкие требования к сети, тем самым увеличивая вероятность доставки. + Возможно, будет лучше, если повторной передачей данных будет заниматься не транспортный, а прикладной уровень.

Это может быть полезно в двух случаях: передающее прило>кение может пересчитывать, а не хранить потерянные данные; ' Нг С 1889, И Р: Л Т>кплрп>Г Р»>>юсм~оглгк>тппе Лрргйопокь якккрь 1996. 602 Глава 18. Протоколы поддержания качества обслу>киванил 18.3. Протокол ЙТР 603 «вместо того чтобы просто передавать еще раз те же потерянные дан>гы >ые, передающее приложение может послать другие данные, пересмотренн в связи с изменившейся ситуацией, или отправить данные, позволяю скорректировать последствия потери оригиналызых данных, Чтобы позволить приложению управлять функцией повторной передачи, в [5 ц предлагается, чтобы нижние уровни, например уровень представления или гран~ портный уровень, работали с данными в тех же единицах, в которых с ними ра~ тает приложение.

Приложение должно разбивать поток данных на модули далнь>х прикладного уровня (Арр![саНоп-1ече! ПаСа Пп[ц АП[>), а более низкие уровни должны сохранять границы между А1Ж-модулями при обработке данных, При кладной уровень является тем уровнем, на котором имеет смысл исправление ошибок отдельных кадров. Если при передаче потеряна часть АПП-модуля, оставшаяся часть модуля, как правило, оказывается бесполезной для приложения. В таком случае прикладной уровень отбрасывает все прибывающие фрагменты и при не обходимости организует повторную передачу всею А1Ж-модуля.

Интегрированная многоуровневая обработка В типичной многоуровневой архитектуре протоколов, такой как ТСР/1 Р или О51, каждый уровень архитеюуры содержит подмножество функций, необходимых для обмена данными, кроме того, каждый уровень должен быть логически структурированным в виде отдельных модулей оконечных систем. Таким образом, при передаче блок данных перемещается вниз по уровням и последовательно ими обрабатывается.

Такая структура не поаволяет программисту выполнять функции параллельно или в порядке, отличном от порядка расположения уровней, что могло бы повысить производительность. Лежащая в основе интегрированной многоуровневой обработки идея, предложенная в [511, заключается в том, что соседние уровни могут быть тесно связаны и программисту должна предоставляться возмо>кность совместного использования функций этих уровней. Идея, ааключающаяся в том, что жесткое разбиение протокола на уровни может привести к низкой эффективности, выскааывз»ась многими исследователями.

Например, в [64! описываются реаультаты изучения проблемы неэффективности удаленного вызова процедур (Ве>поте Ргосег[пге Са[1, ВРС) поверх протокола ТСР и предлагается более тесное взаимодействие двух уровней. Исследователи доказывают, что метод интегрированной мноюуровневой обработки для эффективной передачи данных предпочтительнее. Рисунок 18.9 иллюстрирует способ, которым протокол ВТР реализует принцип интегрированной многоуровневой обработки.

Протокол КТР предназначен для того, чтобы работать поверх не требующего соединения транспортного протокола например $ЛЭР. Протокол ППР обеспечивает базовую функциональность адресации к портам транспортного уровня. Протокол КТР содержит прочие функции транспортного уровня, такие как установление очередности обработки. Однако протокол КТР сам по себе не полон. Чтобы дополнить его функциональностьк> прикладного уровня, может использоваться модификация и/или дополнение КТР-заголовков.

Характеристики

Список файлов книги