Двунаправленное резервирование качества услуг (кау) в механизме внутриполосной передачи сигналов
Изобретение относится к технике связи. Технический результат заключается в оптимизировании механизма резервирования КаУ для адаптивных услуг в режиме реального времени, в беспроводных сетях путем использования подхода внутриполосной передачи сигналов для динамического двунаправленного резервирования КаУ. Технический результат достигается за счет резервирования двунаправленного качества услуги (КаУ) для управления сетевыми ресурсами и/или услугами по обработке данных, путем передачи сигналов с информацией управления ресурсом в обоих направлениях вдоль определенных путей маршрута между этими узлами через основанную на IP динамическую специализированную мобильную сеть. 19 з.п. ф-лы, 2 табл., 9 ил.
Область техники, к которой относится изобретение
Настоящее изобретение относится к области поддержания качества услуги (КаУ, QoS) для таких вариантов применения, как адаптивные услуги, предоставляемые в режиме реального времени для мобильных устройств, которые используют для поддержания различных технологий доступа в динамичных мобильных беспроводных IP (протокол Интернет) сетях, где качество обеспечения соединения с узлом может непредсказуемо изменяться со временем.
Источник временной деградации сетевого ресурса состоит в рабочих характеристиках уровня беспроводного канала с ограниченной полосой пропускания. Из-за характеристик радиоканала и их ухудшения соединение между мобильными узлами может изменяться по времени. Непредсказуемые изменения по времени качества канала отрицательно влияют на возможности связи между соседними узлами, а также на доступ терминала к сети.
Другой источник ненадежности находится в потенциально непредсказуемой доступности или подвижном поведении беспроводных узлов, которые принадлежат к промежуточной сети транспортирования, например сети третьей стороны. Мобильные узлы в сети 3G могут расширять инфраструктуру доступа к фиксированной беспроводной сети с беспроводными специализированными сетями для расширения зоны обслуживания радиосигнала и пропускной способности сети для мобильных пользователей. Архитектура, содержащая маршрутизаторы беспроводного доступа или даже мобильные терминалы, была исследована в европейском проекте MIND (см. IST-2000-28584 MIND, Mobile IP-based Network Developments, http://www.ist-mind.org/). Удаление или отключение от беспроводных сетевых узлов, таких как беспроводные маршрутизаторы или мобильные терминалы, приводит к образованию отделенных ответвлений сети, отрезанных от общего доступа. Вследствие этого качество транспортировки по выделенному каналу через сеть может изменяться с течением долгого времени весьма часто и существенно.
Следовательно, существующие потоки, чувствительные к КаУ, должны быть быстро установлены, восстановлены, адаптированы и высвобождены в соответствии с ухудшением беспроводного канала, а также изменениями топологии. Как описано в статье "A Framework for Bidirectional QoS Signaling" (Internet Draft, 2002) авторов S.M.Shahrier and К.М.Shaheen, эта проблема входит в противоречие с принципом поддержания режима голосовых прикладных программ, предоставляемых в режиме реального времени, например, таких как голос-по-ПИ (VoIP, VoIP) или видеоконференция, с требованиями по обеспечению рабочих характеристик, аналогичных существующим коммутируемым беспроводным или кабельным системам для передачи голоса, поскольку все эти симметричные потоковые услуги накладывают стабильные симметричные двунаправленные требования к ресурсам, например, к характеристикам полосы пропускания и задержки.
Сложности существующих протоколов часто не отвечают этим требованиям. Были предложены архитектуры услуг, позволяющие резервировать ресурсы для отдельных потоков данных (например, для обмена файлами с сервером FTP (протокол передачи файлов)), а именно Модель интегрированных услуг (IntServ). В качестве альтернативы была предложена Модель дифференцированной услуги (DiffServ), для улучшения возможности масштабирования, путем определения поведения передачи пакета и агрегатирования потоков с менее статичной информацией, требуемого в сетевых узлах, вместе с путем маршрутизации. Протокол резервирования ресурсов (ПРСВ, RSVP), который представляет собой один из кандидатов для модели IntServ, был предложен для обеспечения возможности для прикладной программы спонтанно обеспечивать требования к ресурсам сигнала для однорангового хоста. Этот протокол может быть интерпретирован на уровне ретрансляционных участков, вместе с каналом маршрутизации, или может быть прозрачно туннелирован в не-ПРСВ участок сети, с соответствующими механизмами отображения в месте границ сети с несоответствующим участком. Хотя протокол ПРСВ получил некоторое признание в исследованиях, относящихся к IP, и органах стандартизации, недостатки протокола становятся очевидными, когда требуется обеспечить взаимодействие с адаптивными прикладными программами, работающими в режиме реального времени в мобильных средах. Даже проводимая в настоящее время стандартизация для расширения ПРСВ (в соответствии с исследованиями, проведенными в IETF WG NSIS), не позволяет в достаточной степени компенсировать описанные сетевые проблемы, поскольку явно выраженное разделение между управлением и данными пользователя не позволяет обеспечить быструю адаптацию к изменяющимся условиям в сети.
На локальном уровне можно использовать специализированные сети, которые соединяют компьютер типа ноутбук или портативный компьютер, для распространения и совместного использования информации среди участников конференции. Они также могут быть соответствующими в случае прикладных программ, работающих в домашних сетях, когда устройства могут связываться непосредственно друг с другом для обмена информацией, например, такой как аудио и/или видео сигналы, сигналы тревоги и обновления конфигурации. Возможно, наиболее далеко идущие прикладные программы в этом контексте представляют собой в большей или меньшей степени автономные сети взаимно соединенных домашних роботов, которые убирают, моют посуду, ухаживают за газоном, обеспечивают охранную функцию и так далее. В последнее время были предложены специализированные многозвенные сети для мониторинга окружающей среды, причем указанные сети можно использовать для предсказания загрязнения воды или предупреждения о приближающемся цунами. Специализированные сети с короткой дальности действия позволяют упростить взаимосвязь между различными мобильными устройствами (например, между сотовыми телефонами и КПК), формируя так называемую "Персональную вычислительную сеть" (ПВС, PAN), исключая, таким образом, необходимость использования кабелей. Этот принцип также позволяет расширить мобильность, предоставляемую фиксированными сетями, на узлы в области специализированной сети.
Обычно мобильные специализированные сети (MCCET, MANETs) работают с распределенными функциями и позволяют передавать трафик по множеству звеньев радиоканала между источником и назначением. Алгоритмы маршрутизации и привлечение радиоуровней представляют собой проблему в области исследования этих сетей. Свойственная непредсказуемость сети, в которой перемещаются эти узлы, представляет проблему для функций маршрутизации и мобильности, если данные требуется последовательно передавать между узлами соответствующих сетей. Тем не менее многозвенные радиосистемы также позволяют сохранить ресурс батареи и поддерживать рабочие характеристики. В любом случае наиболее привлекательное свойство модели специализированной сети состоит, вероятно, в ее независимости от централизованного управления и, таким образом, повышенной свободе и гибкости, предоставляемыми пользователю.
Уровень техники
Для понимания центральной идеи изобретения необходимо кратко объяснить некоторые из наиболее важных концепций и протоколов сохранения КаУ в соответствии с предшествующим уровнем техники.
Как описано в статье by S.Shenker and J.Wroclawski, "Network Element Service Specification Template" (IETF RFC 2216, September 1997) авторов S.Shenker и J.Wroclawski, различные концепции сохранения КаУ предлагают в настоящее время мобильным пользователям. Термин "качество обслуживания" (КаУ) относится к природе предоставляемой услуги по доставке пакета, которая описана параметрами, такими как полученная в настоящее время полоса пропускания, задержка пакета, частота потери пакета и т.д. Традиционно в сети Интернет предлагают возможность доставки с одиночным значением КаУ по принципу наилучшего обслуживания, в котором характеристики доступной полосы пропускания и задержки зависят от мгновенной нагрузки. Управление над КаУ, видимое прикладной программой, выполняется путем соответствующего предоставления используемой инфраструктуры сети.
В сетях, построенных на основе IP, обеспечивающих требуемое КаУ, существуют два основных потока услуги, а именно интегрированные услуги (IntServ) с соответствующей им передачей сигналов протокола установки сохранения (ресурсов) (ПРСВ) и дифференцированные услуги (DiffServ), как описано в статье "An Architecture for Differentiated Services" (IETF RFC 2475, Dec. 1998) by S.Blake, D.Black, M.Carlson, E.Davies, Z.Wang, and W.Weiss. Упомянутая выше архитектура IntServ определяет набор расширений по отношению к традиционной модели наилучшего обслуживания (НО, BE) в сети Интернет с целью обеспечения качества услуги для прикладной программы по принципу КаУ из конца в конец. Указанные дифференцированные услуги обеспечивают агрегатирование и резервирование аналогичных потоков данных КаУ без передачи каких-либо сигналов. Поэтому сети DiffServ классифицируют пакеты на один из небольшого количества агрегатированных потоков данных КаУ или "классов" на основе так называемой точки кода DiffServ (ТКДУ, DSCP).
Для архитектуры КаУ используют классификатор пакета для классификации пакетов на поток, или последовательность пакетов, которые требуется обрабатывать определенным образом, например, как предложено в архитектуре IntServ, которая описана в статье "Integrated Services in the Internet Architecture: An Overview" (IETF RFC 1633, June 1994) by R.Braden и др. С этой целью требуется идентификатор резервирования для уникальной идентификации потока прикладных программ. Идентификатор резервирования может содержать несколько полей пакета, например источник IP, адрес IP назначения, номера порта и т.д. Для IPv6, как описано в "Internet Protocol, Version 6 (IPv6) Specification" (IETF RFC 2460, December 1998) by S.Deering and R.Hinden, поле метки потока было определено для упрощения классификации отдельных потоков. Имеются предложения оценки этого поля вместе с адресом источника отправителя IPv6 для уникальной идентификации потока.
Как описано в статьях ""Resource Reservation Protocol (RSVP) - Version 1: Functional Specification" (IETF RFC 2205, September 1997) by R.Bradon и др., концепция "мягкое состояние" используется протоколом резервирования источника (ПРСВ), который использует периодическое сообщение обновления, пересылаемое по пути передачи данных, для поддержания соединения в рабочем состоянии. Таким образом, ПРСВ представляет собой протокол управления из конца в конец, который формирует часть передачи сигналов архитектуры интегрированных услуг. Резервирование является ориентированным на получателя, и агрегатирование указанного резервирования поддерживается в зависимости от потребностей соответствующей прикладной программы. Поток данных КаУ может иметь множество отправителей, и протокол поддерживает различные стили резервирования, для того, чтобы диктовать, как агрегатировать резервирование для различных отправителей. Два важных типа сообщений, используемых ПРСВ, представляют собой "PATH" и "RESV". Каждый источник данных периодически посылает сообщение "PATH", которое устанавливает состояние пути, в маршрутизаторы вдоль пути от отправителя к получателю. Получатель каждого из потоков данных КаУ периодически передает сообщение "RESV", которое устанавливает состояние резервирования в промежуточных маршрутизаторах вдоль обратного пути от получателя к отправителю. Таким образом, ПРСВ предполагает обеспечение достаточно стабильного пути по сети.
Протокол резервирования мобильного ресурса (МПРСВ, MRSVP), как описано в статье "М RSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts" (Department of Computer Science, Technical Report, DCS-TR-337, Rutgers University, USA, July 1997) by A.K.Talukdar, B.R.Badrinath and A.Acharya, поддерживает два типа резервирования: активное и пассивное резервирование: активное резервирование соответствует потоку данных КаУ, по которому собственно происходит обмен данными, в то время как пассивное резервирование заранее заказывает ресурсы, которые тем временем могут использоваться другими потоками данных, для которых могут потребоваться более слабые гарантии КаУ, или услуг типа наилучшего обслуживания.
Недостатки и проблемы решений предшествующего уровня техники
Одна из наиболее существенных проблем специализированных сетей состоит в том, что путь маршрутизации потока данных и условий КаУ в соединении для связи могут достаточно быстро и существенно изменяться с течением времени. Поэтому поток данных, возможно, потребуется быстро перенаправить, восстановить, адаптировать и высвободить, в соответствии с ухудшением беспроводной среды и изменениями топологии. В настоящее время преобладающие протоколы КаУ, в соответствии с предшествующим уровнем техники, не достаточно хорошо приспособлены для такой динамической мобильной беспроводной среды. Вместо упреждающей проверки ситуации КаУ на потенциальном будущем пути маршрутизации они реагируют более пассивным и реактивным способом на изменения условий КаУ, создаваемые процессами передачи абонента.
Как правило, обычные протоколы резервирования ресурса, такие как ПРСВ, только поддерживают запросы однонаправленного резервирования. Решение, которое обсуждалось до настоящего времени для симметричных прикладных программ, представляет собой дифференцированное двунаправленное резервирование. При этом два однонаправленных соединения устанавливают из противоположных оконечных точек связи ("одноранговые узлы прикладной программы"). Узлы маршрутизации вдоль обоих зарезервированных путей не имеет никакой взаимозависимости, поскольку восходящий поток от мобильного узла к базовой станции не имеет взаимосвязи с его ассоциированным нисходящим потоком от базовой станции к мобильному узлу, в смысле ограничений маршрутизации. Такая непредсказуемая асимметрия может привести, например, к ситуации, когда общее КаУ, необходимое для соединения для разговора, больше не будет достаточным, хотя одно направление соединения будет все еще иметь достаточные возможности. В мобильных беспроводных сетях, когда качество канала связи может часто изменяться с течением времени, существует требование для определенных типов двунаправленных прикладных программ "связывать" маршруты в каждом из направлений. Таким образом, оба направления должны следовать по одному маршруту, или сеть должна их обрабатывать, как отдельный случай.
Хотя в сети Интернет в течение многих лет исследуют КаУ на уровне транспортирования и на сетевом уровне, эти работы, в основном, основаны на предположении использования кабельной сети. Однако беспроводная связь в сети с многосторонним однородным доступом, в которой мобильные узлы должны работать с беспроводными каналами связи, характеризуется ограниченными полосами пропускания, повышенными частотами ошибки и флуктуациями ресурса. Кроме того, когда мобильный узел изменяет свою точку доступа к сети, необходимы механизмы управления поведением системы во время и после передачи абонента. Следовательно, обеспечение КаУ для беспроводной сети должно основываться на решении проблем, связанных с особенностями такого поведения, присущими этим ненадежным сетям. Учитывая прикладные программы, предназначенные для передачи разговора в режиме реального времени, которые выполняются в мобильном узле, такие как голос-по-IP (VoIP) или видоконференции, запрашиваемые возможности КаУ аналогичны существующим в беспроводных коммутируемых или основанных на передаче голосовых данных системах, как описано в статье "A Framework for Bidirectional QoS Signaling" (Internet Draft, 2002) by S.M.Shahrier and K.M.Shaheen.
Такие симметричные потоковые услуги требуют стабильной симметричной двунаправленной полосы пропускания и условий по задержке. Необходимость двунаправленного резервирования также очевидна в соединениях TCP (протокол управления передачей), пропускная способность которых уменьшается, если происходит задержка сообщений-подтверждений или потеря обратного пути.
На фиг.1 представлен пример, в котором поток прикладной программы, генерируемый в мобильном узле, может быть направлен по двум альтернативным путям для соединения с сетью доступа. В современных IP сетях транспортирования отсутствуют ограничения по нисходящему и восходящему потокам, которые могут передаваться по различным каналам физической сети. Таким образом, резервирование КаУ не является двунаправленным, ввиду асимметричной IP маршрутизации для обоих направлений. Эта ситуация может создавать проблемы в мобильных сценариях беспроводной передачи в режиме реального времени, когда прикладная программа работает на основе возможности симметричной передачи по пути передачи данных.
В отличие от кабельного мира такие возможности являются непредсказуемыми по времени в случае беспроводной мобильной связи. Это может привести к ситуации, когда восходящий канал больше не может поддерживать требуемые параметры КаУ и, с другой стороны, на нисходящий канал не было оказано какое-либо влияние, изменяющее качество беспроводного канала связи. Такая асимметрия может привести к тому, что общее значение КаУ, требуемое для двунаправленного соединения, будет неудовлетворительным, хотя путь в одном направлении все еще будет иметь достаточные ресурсы.
Цель настоящего изобретения
Учитывая приведенное выше пояснение, цель настоящего изобретения состоит в предложении эффективного механизма КаУ в среде специализированной сети.
Эта цель достигается с помощью признаков независимых пунктов формулы изобретения. Предпочтительные признаки определены в зависимых пунктах формулы изобретения. Другие цели и преимущества изобретения будут очевидны из подробного его описания, которое приведено ниже.
Сущность изобретения
Предложенное решение настоящего изобретения направлено на механизм процедуры резервирования двунаправленного КаУ в механизме внутриполосной передачи сигнала, который обеспечивает для симметричных услуг, выполняемых в режиме реального времени, работающих в мобильных устройствах, используемых для поддержания различных технологий доступа в динамических мобильных беспроводных IP сетях, где качество обеспечения соединения с узлом иногда может быть непредсказуемым и изменяющимся по времени, возможность взаимного резервирования, отслеживания и/или адаптации ресурсов КаУ и параметров услуги для восходящего и нисходящего направлений по пути передачи данных. Предложенное решение, таким образом, оптимизирует обычные механизмы резервирования КаУ, в соответствии с предшествующим уровнем техники, в частности, для адаптивных услуг в режиме реального времени, в беспроводных сетях и беспроводных специализированных сетях, используя подход внутриполосной передачи сигналов для динамического двунаправленного резервирования КаУ, основанный на динамическом двунаправленном связанном резервировании сетевого ресурса. Технический термин "внутриполосный", таким образом, относится к ситуации, когда отказались от разделения между данными управления и данными плана пользователя. Таким образом, оба направления передачи данных не могут быть независимыми с точки зрения сети. На фиг.2 показан пример сценария связи, в котором восходящий и нисходящий каналы принудительно используют один и тот же путь передачи данных.
В следующем разделе будут кратко описаны необходимые условия для предложенного решения, в соответствии с изобретением, в отношении отслеживания КаУ, управления резервированием и используемой модели мягкого состояния.
- Управление КаУ: структура КаУ должна позволять отслеживать действительные возможности КаУ на уровне канала передачи данных (уровень 2). Следует предположить, что в адаптивную прикладную программу периодически поступает обновленная информация о пути, обеспечивающем КаУ. Поэтому предложен механизм внутриполосной передачи сигнала, который обеспечивает оптимальную поддержку адаптивных прикладных программ.
- Управление резервированием: уровень канала передачи данных должен позволять обрабатывать запросы КаУ, генерируемые моделью КаУ, например пассивные или активные запросы на резервирование ресурса.
- Модель мягкого состояния: в беспроводных сетях инициатор резервирования, которое используется для поддержания зарезервированного соединения в рабочем состоянии, должен позволять периодически обновлять информацию о сетевом состоянии, которая описана моделью резервирования мягкого состояния.
В общем резервирование может быть однонаправленным или двунаправленным. Инициатор запроса на резервирование, таким образом, обеспечивает информацию о резервировании ресурса с помощью "элементов информации КаУ", которые внедрены в "контейнер КаУ".
Предложенный подход внутриполосной передачи сигналов коррелирован с механизмом гибкого резервирования ресурса, который обеспечивает возможности резервирования для широкого диапазона прикладных программ. Такая концепция позволяет прикладным программам клиента или сервера указывать свои требования к стилю резервирования так, чтобы он наилучшим образом подходил для данной услуги или модели бизнеса. Параметры ресурса специфицированы в "элементах информации КаУ", включенных в "контейнер КаУ".
Возможный вариант выполнения состоит в интегрировании "контейнера КаУ" в заголовок расширения IPv6 при передаче между сегментами сети, которое описано в статье ""Internet Protocol, Version 6 (IPv6) Specification" (IETF RFC 2460, December 1998) by S.Deering and R.Hinden. "Контейнер КаУ" резервирования выполнен в модульной форме. Например, прикладная программа может включать в себя такие необходимые параметры из набора заданных значений.
Спецификация "элементов информации КаУ", предложенная для прикладной программы, в основном, влияет на использование ресурса сети. Более конкретно, эти элементы информации влияют на время резервирования, управление над ним и другие вопросы.
Для обеспечения эффективного использования ресурсов среди множества потоков рекомендуется устанавливать сетевые политики, которые определяют допустимые обстоятельства для приложения специфических "элементов информации КаУ". Адаптивность резервирования, то есть способность адаптироваться к изменяющимся условиям в сети, не является параметром стиля резервирования, который должен быть обозначен для уровня IP. Предполагается, что адаптивность согласована между узлами окончания потоков, которые учитывают текущие доступные ресурсы, предлагаемые IP и более низкими уровнями.
Введена концепция, позволяющая обеспечить быстрое резервирование, которое происходит за один проход без подтверждения. В качестве альтернативы резервирование может быть переключено подтверждением, передаваемым в сторону инициатора запроса. Таким образом вводится концепция активного и пассивного резервирование. Оно было получено из МПРСВ, который поддерживает эти два типа резервирования.
Для пассивного резервирования поток может декларировать свою потребность в сетевых ресурсах, например определенную величину полосы пропускания для потенциального использования в будущем. Эти "пассивно зарезервированные" ресурсы могут использоваться любыми другими потоками, пока статус резервирования не изменится на активное резервирование. Поэтому пассивно зарезервированные ресурсы могут заимствоваться другими потоками. Таким образом может быть улучшено использование сети в сетях с изменяющимися условиями. Резервирование пассивного состояния также можно заранее использовать для планируемой передачи абонента.
Активное резервирование устанавливают исключительно для определенного потока или агрегата потоков с хорошо определенными возможностями по КаУ для обмена пакетами данных. Никакой другой поток не может совместно использовать выделенные ресурсы, за исключением того потока, который выполнил активное резервирование. Активное резервирование также определено как мягкое состояние и поэтому его требуется обновлять.
Однонаправленное резервирование можно рассматривать как решение - отступление в случае, когда двунаправленное резервирование не может быть установлено или должно быть высвобождено. В этом случае датаграммы между двумя одноранговыми узлами при передаче данных не обязательно должны быть переданы по одному и тому же пути, из-за асимметричных каналов передачи данных или распределения нагрузки.
По сравнению с ПРСВ, в котором поддерживаются только однонаправленные запросы на резервирование, при таком подходе вводится возможность запроса для двунаправленного резервирования. Для двунаправленного резервирования предполагается, что резервирование восходящего потока и нисходящего потока между двумя одноранговыми хостами использует один и тот же путь по сети в противоположных направлениях. Двунаправленный поток данных представляет собой элементарный случай, который комбинирует резервирование ресурса в противоположных направлениях вдоль одного и того же пути. Двунаправленный путь может быть установлен между ретрансляторами или путем определения подробного пути маршрутизации. Поддержание симметричного и асимметричного резервирования, отдельный набор измеряемых параметров резервирования и полей мониторинга для прямого и обратного направления требуется рассматривать при выполнении протокола.
Для установления резервирования независимый механизм проверки должен проверять как восходящий, так и нисходящий сетевые пути. Требуется проверять доступные ресурсы для каждого сегмента сети как для исходящего, так и для входящего интерфейса, и при этом возможно резервировать (пассивный или активный) ресурсы для обоих интерфейсов перед передачей запроса в маршрутизатор следующего сегмента сети, с точки зрения инициатора.
Обратная связь для результата процесса установления двунаправленного резервирования может быть сохранена в поле "действительное значение". Прикладная программа при приеме информации мониторинга на этапе резервирования отвечает за принятие решения в отношении того, как реагировать на результат резервирования.
Узлы маршрутизации современного уровня техники не поддерживают резервирование в обоих направлениях на одном этапе. В случае, когда узел маршрутизации не поддерживает установку двунаправленного резервирования, результат частично неудачного резервирования будет сохранен в соответственных полях мониторинга (например, в случае измеряемых параметров КаУ в поле "действительного значения"). В этом процессе инициатор будет уведомлен, что может быть установлено только одно направление запроса резервирования, и поэтому запрос на двунаправленное резервирование не может быть выполнен.
Асимметричная нагрузка сети также может привести к неудачной установке двунаправленного резервирования. В случае неудачи инициатор отвечает за принятие решения в отношении действий в ситуации недостаточных ресурсов. Одна схема реакции может состоять в том, что инициатор запрашивает только однонаправленное резервирование. Принимая только однонаправленное резервирование, одноранговый узел самостоятельно несет ответственность за установление нисходящего резервирования.
В случае, когда механизм проверки ресурса детектирует, что восходящий и нисходящий пути для двунаправленного резервирования не следуют по одинаковым маршрутам в определенном узле маршрутизации вдоль пути резервирования, некоторые или все отслеживаемые значения атрибута, выполняемые заголовком датаграммы IP, устанавливают равными нулю в узле-корреспонденте. В зависимости от спецификации синтаксиса протокола резервирования, эти значения атрибута должны быть установлены в ноль, что позволяет оконечным точкам резервирования легко интерпретировать ситуацию асимметрии маршрутизации. На фиг.3 показан путь принятия решения для установки двунаправленного резервирования.
Когда срок действия двунаправленного резервирования истекает, или его явным образом удаляют, удаляют как восходящие, так и нисходящие данные резервирования.
Преимущества настоящего изобретения состоят в возможностях динамического резервирования двунаправленного ресурса, которые могут быть получены за один этап, комбинированного отслеживания и адаптации резервирования в двух направлениях и концепции внутриполосной передачи сигнала, которую можно соответствующим образом применять для мобильных сред.
- Динамическое резервирование двунаправленного ресурса: Определенные прикладные программы, в которых предполагается установление двунаправленного пути передачи данных, получает преимущество при использовании двунаправленного резервирования. Оба направления передачи данных могут не быть независимыми с точки зрения прикладной программы. В беспроводных сетях, где качество канала связи может часто изменяться с течением времени, существует требование к определенным типам прикладных программ "связывать" маршруты в противоположных направлениях, что означает, что оба направления должны следовать по одному маршруту, или сеть должна их рассматривать как один случай.
- Двунаправленное резервирование ресурса за один этап: Ресурсы могут быть выделены по одному сообщению, передаваемому ретрансляторами между инициатором запроса и его узлом-корреспондентом или, в качестве альтернативы, с использованием двух сообщений (запрос и подтверждение). Для связанного двунаправленного резервирования предполагается, что восходящее и нисходящее резервирование между двумя хостами использует одинаковый путь через сеть в противоположных направлениях. Таким образом, изобретение вводит концепцию двунаправленного потока как элементарный случай, который комбинирует резервирование в противоположных направлениях вдоль одного пути. Связывание двунаправленного резервирования обеспечивает преимущества при передаче сигналов, благодаря уменьшению объема передаваемых по сети служебных сигналов.
- Мониторинг и адаптация комбинированного резервирования в двух направлениях: Независимые механизмы проверки необходимы для проверки как восходящего, так и нисходящего сетевых путей. Для каждого сегмента сети требуется проверить доступные ресурсы как для исходящего, так и для входящего интерфейса, и возможность резервирования ресурсов для обоих интерфейсов перед передачей запроса в маршрутизатор следующего сегмента сети, с точки зрения инициатора. Двунаправленный мониторинг или адаптацию ресурсов выполняют в одном сообщении. В случае ситуации передачи абонента и адаптации КаУ связывание потоков может ускорить процесс повторного согласования.
- Концепция внутриполосной передачи сигналов для мобильных сред: Внутриполосная передача сигналов является наиболее предпочтительной для двунаправленного связанного резервирования по каналам передачи данных в сети с непредсказуемыми характеристиками. При этом объем передаваемых служебных сигналов существенно меньше, чем для обычного двунаправленного потока. Например, указанная информация передачи сигналов может быть передана дополнительно схемами прикладной программы, если их регулярно передают в сконфигурированном интервале времени мягкого состояния. Хост, который представляет конечную точку резервирования, генерирует информацию обратной связи о резервировании. Поскольку при этом отсутствуют данные прикладной программы, передаваемые в инициатор резервирования, при предоставлении такой информации обратной связи возникают некоторые проблемы для однонаправленного потока прикладной программы. Для надежного соединения транспортирования (например, TCP) все еще существует двунаправленный поток сообщений, который можно использовать для передачи информации обратной связи в инициатор резервирования. Если двунаправленный поток отсутствует, указанная информация обратной связи может быть размещена в датаграмме IPv6 без какой-либо другой цели. Однако следует учитывать, что эта процедура накладывает дополнительную нагрузку на сеть при передаче сигналов.
Один вариант выполнения изобретения относится к способу резервирования двунаправленного качества услуги (КаУ), предназначенному для резервирования, выделения, мониторинга и/или адаптации сетевых ресурсов, и/или параметров услуги, необходимых для симметричных мультимедийных прикладных программ, работающих в режиме реального времени, и/или услуг передачи данных, работающих в мобильном узле и узле-корреспонденте, путем передачи сигналов с информацией об управлении ресурса в обоих направлениях вдоль определенных путей маршрутизации между этими узлами через специализированную динамическую мобильную сеть, работающую на основе IP, которая содержит ряд взаимно соединенных узлов передачи, в случае, когда возможности соединения непредсказуемо изменяются по времени. Информацию управления ресурсом, предназначенную для передачи между мобильным узлом и узлом-корреспондентом, внедряют в датаграмму IP, которую передают между сегментами сети по пути маршрута соединения, зарезервированного для этих узлов, и информацию об управлении ресурса распространяют между мобильным узлом и узлом-корреспондентом, используя один и тот же путь маршрута между сегментами сети в обоих направлениях.
Таким образом, либо мобильный узел, или его узел-корреспондент инициализирует сообщение-запрос на резервирование ресурса, обозначающее потребность в заданном количестве сетевых ресурсов одновременно в обоих направлениях. Инициатор запроса резервирования и первоначально предложенную величину сетевых ресурсов для резервирования определяют по согласованию или в соответствии с контрактом, который был установлен между одноранговыми узлами, участвующими в передаче данных. В качестве альтернативы обе стороны составляют соглашение путем обсуждения на уровне сеанса или прикладной программы.
В соответствии с изобретением, инициатор сообщения запроса резервирования ресурса генерирует уникальный идентификатор (ИД, ID) резервирования, ассоциирующий двунаправленное соединение с одним потоком прикладной программы или агрегатированным потоком для классификации IP датаграммы в обоих направлениях, для обеспечения определенного поведения при передаче данных, которое остается неизменным в течение времени существования ассоциированного потока. Таким образом, сетевые ресурсы выделяют или отслеживают при передаче между сегментами сети с использованием информации управления ресурса, дополнительно прикрепленной к IP датаграмме, или все это выполняется одновременно для обоих направлений сообщения запроса на резервирование ресурса, в котором информацию управления ресурса для обоих направлений зарезервированного пути маршрута внедряют в одну и ту же IP датаграмму.
Информацию управления ресурса для каждого направления резервирования передают как дополнительную информацию с элементами информации ресурса, которые представляют собой часть расширения заголовка IP датаграммы, в котором каждый элемент информации ресурса представляет либо атрибут ресурса вдоль зарезервированного пути маршрута, ассоциированного с выражаемыми количественно измеряемыми параметрами ресурса или для одного, или для обоих направлений потока, или атрибутом потока для индивидуального потока или агрегата потока, ассоцированного с выражаемой количественно и не выражаемой количественно информацией контекста потока или для одного, или обоих направлений потока.
Таким образом, указанные элементы информации ресурса описывают информацию управления ресурса для восходящего направления из инициатора в направлении к получателю или в нисходящем направлении от получателя к инициатору сообщения запроса о резервировании ресурса или в обоих направлениях одновременно, в котором восходящее и нисходящее направления уникально идентифицированы мобильным узлом и узлом-корреспондентом, с учетом их роли в процедуре резервирования в качестве инициатора либо получателя сообщения запроса на резервирование ресурса.
Элементы информации ресурса организованы в модульной форме для каждого потока, что означает, что узел, который представляет собой источник информации управления ресурсом, определяет количество элементов информации ресурса, которые требуется разместить в заголовке датаграммы IP.
Каждый элемент информации ресурса содержит поле для отслеживаемой величины атрибута и поля спецификации запроса атрибута, определяющие требования к потоку с конкретным атрибутом ресурса, которые описаны верхним пороговым значением, определяющим максимальное значение, и/или нижним пороговым значением, определяющим минимальное значение для соответствующего атрибута ресурса. В качестве альтернативы или в дополнение могут быть указаны дискретные значения для соответствующего атрибута ресурса. Спецификация требования атрибута может быть сгенерирована и модифицирована либо инициатором, или получателем резервирования, и может быть интерпретирована узлами маршрутизации вдоль пути резервирования, для выделения запрашиваемой величины ресурсов.
В соответствии с дополнительным вариантом выполнения настоящего изобретения, одновременно отслеживается информация о доступных ресурсах для обоих направлений резервирования вдоль зарезервированного пути маршрутизации между мобильным узлом и узлом-корреспондентом. Для каждого узла вдоль зарезервированного пути маршрутизации определяют действительные значения атрибута ресурса для восходящего и нисходящего направления. Если в каком-либо узле вдоль зарезервированного пути маршрутизации отслеживаемый атрибут ресурса для восходящего или нисходящего направления или для обоих направлений имеет величину, которая меньше, чем соответствующее отслеживаемое значение атрибута, которое переносится в заголовке IP датаграммы, элементу информации ресурса заголовка IP датаграммы назначают новое значение, что позволяет получателю информации управления ресурсом определять текущие значения ресурса для обоих направлений.
В соответствии с еще одним вариантом выполнения настоящего изобретения, сообщение-запрос на резервирование ресурса, описывающее набор спецификаций требования к атрибуту, передают из инициатора в получатель, и процедура выделения ресурса для одного или обоих направлений резервирования ресурса управляет либо мобильным узлом, или узлом-корреспондентом. Основываясь на таком сообщении на резервирование ресурса, величины атрибута ресурса, которые следует выделить для восходящего направления и нисходящего направления или для обоих направлений, одновременно определяют в каждом передающем узле вдоль зарезервированного пути маршрутизации. Управление ресурсами для двунаправленного резервирования обрабатывается одноранговыми узлами, осуществляющими обмен данными через более высокий уровень согласования. В случае отсутствия механизмов более высокого уровня согласования одноранговые узлы передачи данных могут обмениваться элементами информации в определенных заголовках расширения IP, которые интерпретируются из конца в конец, а не для каждого сегмента сети.
Информация управления ресурсом для различных двунаправленных потоков дополнительно упаковывают в ту же IP датаграмму, в которой для каждого потока прикладывается элемент информации идентификатора резервирования, относящийся к дополнительному потоку, и элементы информации ресурса в заголовке IP датаграммы присоединены к заголовку IP датаграммы, и группы идентификаторов резервирования и другие элементы информации ресурса определяет принадлежность этой информации к определенному потоку. Благодаря этому мобильный узел или узел-корреспондент определяют на уровне IP, можно ли вставить информацию управления двунаправленного или однонаправленного ресурса в IP датаграмму, которая готова для передачи в сетевой интерфейс, или с этой целью требуется сгенерировать отдельную IP датаграмму. Указанную информацию управления ресурсом помещают в любую IP датаграмму, которая следует по зарезервированному пути маршрутизации между инициатором и получателем сообщения запроса на резервирование ресурса.
В соответствии с дополнительным вариантом выполнения изобретения, условия недостаточности ресурсов вдоль пути маршрутизации для восходящего и нисходящего направлений в узле-корреспонденте распознают путем сравнения отслеживаемых значений атрибута со спецификациями запрашиваемых атрибутов в элементах информации ресурса поступающих IP датаграмм. Способ, таким образом, исключает необходимость определения конкретных исключений или предупреждающих сообщений. Оконечная система-адресат должна реагировать на отсутствие конкретного ресурса.
Отслеживаемые значения атрибута ресурса для определенных элементов информации ресурса, указанные в заголовке IP датаграммы, устанавливают равными нулю, когда один или больше передающих узлов не поддерживают эти атрибуты ресурса.
Один вариант выполнения изобретения относится к способу резервирования двунаправленного качества обслуживания (КаУ), который характеризуется этапом установки в ноль отслеживаемых значений атрибута, переносимых в заголовке IP датаграммы, в запрашивающем узле, что позволяет оконечным точкам резервирования легко интерпретировать ситуацию асимметрии маршрутизации, если восходящий и нисходящий пути для двунаправленного резервирования не следуют идентичным маршрутам в определенном узле маршрутизации вдоль зарезервированного пути маршрутизации.
В соответствии с дополнительным вариантом выполнения изобретения, сообщения-запросы на резервирование ресурса со значением, равным нулю, для одной или более спецификаций требования атрибута интерпретируют как явные сообщения на высвобождение передающими узлами вдоль зарезервированного пути маршрутизации инициатором или получателем сообщения запроса на резервирование ресурса. Величины этих спецификаций запрашивающих атрибут, затем ассоциируют с удалением информации о состоянии резервирования для конкретного потока в передающих узлах вдоль зарезервированного пути маршрутизации.
Сообщения-запросы на резервирование ресурса с величиной, не равной нулю, для одной или больше спецификаций требования атрибута интерпретируются как явные сообщения установки передающими узлами, вдоль зарезервированного пути маршрута и получателем сообщений запросов на резервирование ресурса. Величины этих спецификаций требования атрибута затем ассоциируют с установкой информации состояния резервирования, специфичной для потока в передающих узлах вдоль зарезервированного пути маршрута.
В соответствии с еще одним вариантом выполнения изобретения, элемент информации потока, определяющий тип резервирования как двунаправленный или однонаправленный, добавляют в заголовок IP датаграммы сообщения установки резервирования. Этот элемент информации потока затем интерпретируют как передающие узлы вдоль зарезервированного пути маршрута, для обеспечения правильной установки информации о состоянии резервирования.
Краткое описание чертежей
Другие преимущества и варианты выполнения настоящего изобретения представлены в зависимых пунктах формулы изобретения, а также в следующем подробном описании изобретения и на прилагаемых чертежах:
на фиг.1 представлен вид сценария беспроводной двунаправленной связи, в котором различные пути зарезервированы для восходящего и нисходящего соединений, что представляет собой пример, в котором поток прикладной программы, генерируемый в мобильном узле, может быть направлен по двум альтернативным путям для соединения с сетью доступа,
на фиг.2 показан общий вид сценария беспроводной двунаправленной связи, в котором одни и те же пути зарезервированы для восходящего и нисходящего соединений,
на фиг.3 показана блок-схема последовательности выполнения способа, которая представляет процедуру установки двунаправленного резервирования в соответствии с одним вариантом выполнения настоящего изобретения,
на фиг.4 иллюстрируется пример структуры контейнера КаУ в IP датаграмме,
на фиг.5 иллюстрируется пример элемента модульной измеряемой информации КаУ,
на фиг.6 иллюстрируется пример элемента модульной измеряемой информации КаУ в сценарии асимметричной двунаправленной связи,
на фиг.7 иллюстрируется пример элемента модульной измеряемой информации КаУ в сценарии симметричной двунаправленной связи,
на фиг.8 представлен пример связи в сценарии симметричной двунаправленной связи с достаточными ресурсами, и
на фиг.9 показан пример связи в сценарии симметричной двунаправленной связи с недостаточными ресурсами.
Подробное описание изобретения
Ниже подробно поясняются варианты выполнения настоящего изобретения, которые представлены на фиг.1-9. Кроме того, будет приведен краткий обзор синтаксиса для примера сообщения в соответствии с протоколом внутриполосной передачи сигнала для двунаправленной передачи сигналов, в соответствии с настоящим изобретением. Значения символов, которые обозначены ссылочными позициями и знаками на этих фигурах, приведены в таблице 2.
В IPv6 вспомогательную информацию уровня Интернет кодируют в отдельных заголовках, которые могут быть размещены в пакете между заголовком IPv6 и заголовком верхнего уровня. Информация передаваемых сигналов переносится в заголовке опций на уровне сегментов сети, если требуется интерпретировать ее для всех узлов маршрутизации вдоль пути маршрута. Для информации, которая должна быть передана только между одноранговыми узлами, используют заголовок опций назначения.
В соответствии с примером настоящего изобретения заголовок расширения IPv6 на уровне ретрансляционных участков, который определен в статье " Internet Protocol, Version 6 (IPv6) Specification" (IETF RFC 2460, December 1998) by S.Deering and R.Hinden, используется для транспортировки информации управления ресурсом, предназначенной для интерпретации узлами-маршрутизаторами вдоль пути. Информацию, передаваемую сигналами, добавляют к IP датаграмме, которая следует по пути передачи данных зарезервированного канала связи по ретрансляционным участкам. Таким образом, один и тот же путь передачи данных по сети используется на уровне ретрансляционных участков в обоих направлениях для распространения информации, передаваемой сигналами, между обоими одноранговыми узлами обмена данных.
Для обеспечения модульной концепции вводится термин "контейнер КаУ". В общем, контейнер КаУ включает в себя информацию передачи сигналов в форме элементов информации КаУ, которые обычно рассматриваются как один поток, но также могут быть ассоциированы с группой потоков. Ключевая концепция подхода состоит в том, что используется переменное количество и размер элементов информации КаУ, которые размещены в пакете. Например, только информация, которая требуется в данное время для интерпретации, переносится в контейнере. Существуют обязательные элементы информации КаУ и вспомогательные элементы информации КаУ в контейнере КаУ, в котором вспомогательные элементы информации КаУ содержат вспомогательную информацию.
Одно представление элемента информации КаУ представляет собой измеряемый элемент информации КаУ, который переносит измеряемую информацию КаУ. Измеряемый элемент информации КаУ состоит из поля для отслеживаемого значения атрибута и дополнительных полей, которые определяют требования потока, специфичные для атрибута ресурса, то есть спецификацию требования к атрибуту. Верхнее пороговое значение, определяющее максимальное значение или нижнее пороговое значение, определяющее минимальное значение, для соответствующего атрибута ресурса, описывает спецификацию требования атрибута. В качестве альтернативы верхнее и нижнее пороговые значения могут быть определены вместе, что описывает интервал, в пределах которого значения для соответствующего атрибута ресурса являются приемлемыми для резервирования. В качестве альтернативы или в дополнительно могут быть указаны дискретные значения для соответствующего атрибута ресурса. Спецификация требования атрибута может быть сгенерирована и модифицирована либо инициатором, или получателем резервирования и может быть интерпретирована путем маршрутизации узлов вдоль пути резервирования для выделения запрашиваемой величины ресурсов.
Каждый узел, инициализирующий резервирование, должен генерировать уникальный идентификатор резервирования. Двунаправленное соединение ассоциировано с одиночным потоком прикладной программы или агрегатированным потоком. Идентификатор резервирования остается неизменным в течение срока существования его ассоциированного потока и используется для классификации IP датаграммы в обоих направлениях, для получения определенного поведения при передаче.
В другом примере представлена необходимость в независимости идентификатора потока. Когда получатель потока изменяет свою роль и начинает отвечать на сеансы, определенные определенным идентификатором резервирования, получатель может добавлять свой IPv6 адрес в поле адреса источника заголовка IPv6 пакета. В этом случае комбинация из адреса источника и метки потока больше не будет представлять идентификатор резервирования происхождения. Промежуточные узлы больше не будут иметь возможность правильно классифицировать пакеты, которые принадлежат потоку. Поэтому, когда требуется обеспечить прозрачность потока, необходим элемент информации идентификатора резервирования для транспортировки информации идентификатора резервирования происхождения. Различные предположения в отношении модифицированной спецификации, для определения 20-битного поля метки потока, такие как описаны в статье "A Modified Specification for Use of the IPv6 Flow Label for Providing Efficient Quality of Service Using Hybrid Approach" (Internet Draft, Feb. 2002) by R.Banerjee и др., фактически находится за пределами объема этого изобретения. В отличие от некоторых из таких предположений статическую метку потока принимают во время срока действия сеанса.
Идентификатор классификации пакета, который описан в статье "Integrated Services in the Internet Architecture: An Overview" (IETF RFC 1633, June 1994) by R.Braden и др., используется в статье для классификации пакетов на поток или последовательность пакетов, которые следует обрабатывать определенным способом. Поэтому термин "идентификатор резервирования" используется для идентификации уникального потока. Предложено строить идентификатор резервирования из IPv6 адреса источника отправителя (адрес хоста, генерирующего поток) и метки IPv6 потока, определенной в "Internet Protocol, Version 6 (IPv6) Specification" (IETF RFC 2460, December 1998) by S.Deering and R.Hinden. Это не является обязательным вследствие требований независимости идентификатора резервирования от идентификатора потока, ЕР адреса инициатора КаУ и конечных точек потока. Различные сценарии в области мобильной связи требуют такой независимости, поскольку потоки, получаемые при передаче абонента, могут иметь измененные конечные точки и т.д., но все еще будут иметь те же требования КаУ, как описано авторами М.Brunner и др. в их статье "Requirements for QoS Signaling Protocols" (Internet Draft, November 2002, draft-brunner-nsis-req-02.txt).
В случае, если требуется обеспечить прозрачность потока, элемент информации идентификатора резервирования необходимо использовать для транспортировки исходной информации идентификатора резервирования. Для обеспечения эффективной классификации IPv6 потока "элемент информации идентификатора резервирования" может быть построен из поля метки IPv6 потока и адреса источника IPv6, которые расположены только в полях основного заголовка IPv6, в фиксированных положениях. В случае, когда "элемент информации идентификатора резервирования" был указан в контейнере КаУ, информацию потока в заголовке IPv6 необходимо игнорировать. В контейнере КаУ должен находиться первый элемент информации КаУ.
Хотя ПРСВ использует резервирование, ориентированное на получателя, предложенное решение позволяет также переключать запросы для резервирования как на основе отправителя, так на основе получателя. Для резервирования на основе отправителя (обозначено как резервирование восходящего потока) в каждом промежуточном узле маршрутизации выделяют ресурсы для исходящего интерфейса. В отличие от этого для резервирования на основе получателя сетевые ресурсы выделяют во входящем интерфейсе в узле маршрутизации. Для обеспечения возможности различать, в каком направлении необходимо разрешить установку резервирования, оба одноранговых участника обмена данными должны договориться о порядке элементов управления ресурсами для восходящего и нисходящего направлений. Для того чтобы скрыть такое назначение от промежуточных узлов маршрутизации, одноранговый участник обмена данными может изменять последовательность информации управления восходящим и нисходящим ресурсами в отношении заказа информации управления ресурсом в принимаемой IP датаграмме.
Для поддержки двунаправленного сеанса с возможностью выполнения двунаправленной адаптации среды вводят атрибут двунаправленного КаУ, который принадлежит уникальному идентификатору резервирования. Такой атрибут двунаправленного КаУ информирует маршрутизаторы о том, что резервирование вдоль пути передачи данных необходимо установить для обоих направлений. Обратная связь об успешном двунаправленном резервировании может быть получена по результатам мониторинга, который обозначен в поле "действительное значение". Предположение, что симметричный двунаправленный запрос был выполнен, может быть сделано на основе того факта, что только один элемент измеряемой информации КаУ был сгенерирован для двунаправленного резервирования. В отличие от симметричного двунаправленного запроса асимметричный двунаправленный случай предлагает два элемента информации КаУ с идентификаторами идентичного типа, которые сгруппированы в одном КаУ контейнере. Первый элемент информации КаУ будет интерпретирован, как элемент, который описывает прямой поток, и второй элемент, - как элемент, который описывает обратный поток. Восходящее и нисходящее направления определены с точки зрения узла инициатора КаУ.
Каждый контейнер КаУ может переносить несколько элементов информации КаУ. Дополнительно упакованный контейнер КаУ содержит информацию управления ресурсом в IP датаграмме. Его используют для выделения ресурсов при передаче между сегментами сети, отслеживания ресурсов при передаче между сегментами сети или выполнения обеих этих функций одновременно для обоих направлений резервирования. Концепция модульных гибких элементов информации КаУ предлагает преимущество выполнения самым точным образом требований КаУ определенной прикладной программы. Каждый элемент информации КаУ должен следовать формату ТДЗ (TLV, тип-длина-значение). "Тип" определяет данные объекта, "длина" - количество в восьмибитовых байтах, в то время как "значение" описывает поле данных. Элементы информации КаУ обрабатывают в том порядке, в котором они появляются. В качестве примера, показанного на фиг.4, элемент 400а информации КаУ обрабатывают перед элементом 400b информации КаУ.
На фиг.5 представлен пример элемента измеряемой информации КаУ. Помимо полей общего типа и длины присутствует также поле данных объекта, которое разделено на три дополнительных поля. В этих полях содержатся действительное, минимальное и максимальное значения для определенного измеряемого параметра КаУ. В этом примере последние два поля содержат значения, описывающие потребности в КаУ для определенной прикладной программы. В третьем поле содержится информация, поступающая из сети для получения необходимой обратной связи о действительной ситуации условий канала связи из конца в конец. Поэтому это поле обновляют с использованием действительной величины измеряемого параметра КаУ определенной сети. Если это значение установлено равным нулю, для соответствующего измеряемого параметра не выделяют какие-либо ресурсы.
На фиг.6 показан один пример элемента измеряемой информации КаУ в асимметричном двунаправленном сценарии, что означает, что запросы на измеряемые параметры КаУ восходящего и нисходящего потоков будут различными. Оба одноранговых участника обмена данными должны согласовать порядок следования элементов управления ресурсами для ясной идентификации ситуации с ресурсами для восходящего и нисходящего направлений. Для того чтобы скрыть это согласование между одноранговыми участниками обмена данных от промежуточных узлов маршрутизации, одноранговые участники обмена данными могут изменять последовательность информации управления ресурсами, связанными с восходящим и нисходящим потоками, в отношении порядка информации управления ресурсами в принимаемой IP датаграмме.
На фиг.7 представлен один пример элемента измеряемой информации КаУ в симметричном двунаправленном сценарии. В симметричном двунаправленном запросе на резервирование измеряемые параметры КаУ восходящего и нисходящего потоков равны. В этом случае только один элемент информации КаУ с одним и тем же идентификатором типа записывают в контейнер КаУ.
На фиг.8 показан пример передачи данных в симметричном двунаправленном сценарии с достаточными ресурсами. Мобильный узел 106а (МУ, MN) передает запрос (1) симметричного двунаправленного резервирования через промежуточный узел 106b (ПУ, IN) (2) в узел-корреспондент 106с (УК). Таким образом, ПУ имеет достаточные ресурсы для выполнения запроса двунаправленного ресурса, который был инициирован МУ. Поэтому ПУ резервирует 200 кбит/с в каждом направлении и передает (2) запрос на двунаправленное резервирование в УК. УК теперь имеет информацию, которую получил запрос на резервирование. Он передает (3) в явной форме или в форме добавочного сообщения результат в МУ. В нисходящем направлении промежуточный узел 106b может снова интерпретировать запрос на резервирование (4).
На фиг.9 показан пример обмена данными в симметричном двунаправленном сценарии с недостаточными ресурсами. Мобильный узел 106а (МУ) передает запрос на симметричное двунаправленное резервирование (1) через промежуточный узел 106b (ПУ) (2) в узел-корреспондент 106с (УК). В результате этого ПУ имеет недостаточные ресурсы для выполнения запроса на двунаправленный ресурс, инициированного из МУ. ПУ может только зарезервировать скорость передачи битов, равную 150 кбит/с, для восходящего направления. Поле действительного значения, поэтому, изменяется с 200 кбит/с на 150 кбит/с. Узел ПУ передает (2) обновленный запрос на двунаправленное резервирование в УК. УК теперь имеет информацию о том, что запрос на резервирование не может быть выполнен. Он передает (3, 4) результат в явно выраженной форме или в виде сообщения добавления в МУ. Теперь соответствующая прикладная программа, выполняющаяся в МУ, должна соответствующим образом реагировать на недоступность достаточного ресурса вдоль пути.
| Таблица 1 | |
| Определения | |
| Технический термин | Краткое пояснение технического термина |
| Специальная обработка данных | Специальные расчеты относятся к автоматическому обнаружению услуг общего назначения, рекламируемых в сети. Процесс обнаружения может быть основан на заданной информации о названии и/или типе соответствующей услуги. |
| Создание специализированной сети | В отличие от этого создание специализированной сети означает обнаружение автоматических устройств и установление каналов связи между соседними устройствами в незапланированном, неуправляемом виде. Поэтому маршрутизация сообщений может быть выполнена на основе технологии с множеством переходов, в которой функции маршрутизации предлагаются большинством (если не всеми) узлами, участвующими в специализированной сети. |
| Специализированные сети | Специализированная сеть может представлять собой любую сеть для устройств мобильной связи, установленных путем использования механизма создания специализированной сети, как описано выше. Например, это может быть неуправляемая, незапланированная сеть или неподвижные, и/или движущиеся устройства, обменивающиеся данными. |
| Специализированные сети с поддержкой | Специализированная сеть с поддержкой может представлять собой любую сеть или устройство, обменивающееся информацией, установленную с использованием механизма создания специализированной сети, как описано выше, но с поддержкой и под управлением так называемого оператора |
| Технический термин | Краткое пояснение технического термина сети, предоставляющего функцию ААА, а также услуги с дополнительными желательными характеристиками. |
| Нисходящий и восходящий | Термины, обозначающие направление "восходящее" и "нисходящее", определены по отношению к направлению потока данных. Направление графика от терминала ресурса в направлении к терминалу назначения называется "нисходящим"; направление графика от терминала назначения в направлении к терминалу ресурса называется "восходящим". |
| Инициатор КаУ | Этот объект отвечает за инициирование резервирования на основе потока прикладных программ вдоль сетевого пути путем передачи сигналов, содержащих запрос ресурса, в сеть. Объект может быть расположен в конце системы, но также может постоянно находиться в другом месте в сети. Кроме того, могут быть выполнены механизмы, обеспечивающие КаУ, которые являются локальными по отношению к объекту, если имеется ограничение доступных ресурсов. |
| Агрегирование резервирования | Агрегирование резервирования происходит, если множество резервирований, происходящих из разных терминалов источников в направлении одного терминала назначения, можно объединять для представления единого резервирования. Объединяющий узел должен согласовывать комбинирование резервирования на основе сконфигурированной политики образования сети или решений управления. |
| Отправитель и получатель резервирования | Отправитель резервирования представляет собой восходящий, находящийся на границе маршрутизатор, от которого происходят сообщения резервирования. Получатель резервирования определен как нисходящий, находящийся на границе маршрутизатор, в котором заканчивается сообщение резервирования. |
| Спонтанные специализированные сети | Существуют традиционные специализированные сети, в которых поддержка от какого-либо сетевого оператора не обеспечивается, что бы не случилось. В конечном счете сетевые специализированные сети с поддержкой не могут поддерживать спонтанные специализированные сети в случае, когда вовлеченные одноранговые участники обмена данными выходят за пределы зоны обслуживания какой-либо из сетей доступа |
| Таблица 2 | |
| Представленные свойства и их соответствующие ссылочные позиции | |
| Номер | Техническое свойство (Компонент системы, этап способа) |
| 100 | схема, представляющая обзор сценария беспроводной двунаправленной связи, в котором различные пути зарезервированы для восходящего и нисходящего соединений, что представляет собой пример, в котором поток прикладной программы, сгенерированный в мобильном узле 106а, может быть направлен между двумя альтернативными путями для соединения их в транспортную IP сеть 102 |
| 102 | кабельная базовая сеть (IP транспортирования), основанная на IPv6 |
| 103 | шлюз между кабельной базовой сетью 102 и беспроводной сетью 104 |
| 104 | динамическая мобильная специализированная сеть, содержащая ряд взаимно соединенных промежуточных узлов, в которой соединения между этими узлами непредсказуемо изменяются по времени |
| 105а-с | беспроводные маршрутизаторы (передающие узлы), взаимно соединенные через мобильную специализированную сеть 104 |
| 106а | мобильный узел, соединенный с узлом-корреспондентом 106с, по меньшей мере, через один промежуточный узел 106b |
| 106b | (на фиг.8) промежуточный узел, соединенный с кабельной базовой сетью 102 и/или беспроводной сетью 104 |
| 106с | (на фиг.8) узел-корреспондент указанного мобильного узла 106а |
| 200 | схема, представляющая обзор сценария беспроводной двунаправленной связи, в котором одинаковые пути зарезервированы для восходящего и нисходящего соединений |
| 300 | блок-схема последовательности выполнения способа, представляющая процедуру установки двунаправленного резервирования, в соответствии с одним вариантом выполнения настоящего изобретения |
| 400 | схема, представляющая пример структуры контейнера КаУ IP датаграммы |
| 400а | первый элемент информации ресурса (КаУ), сохраненный в контейнере КаУ |
| 400b | второй элемент информации ресурса (КаУ), сохраненный в контейнере КаУ |
| 401a | поле типа (длина: 1 байт) первого элемента информации КаУ 400а, сохраненного в контейнере КаУ |
| 401b | поле длины (длина: 1 байт) первого элемента информации КаУ 400а |
| 401с | поле данных (длина: 2 байта) первого элемента информации 400а КаУ |
| 401d | поле данных (длина: 4 байта) первого элемента информации 400а КаУ |
| 401a' | поле данных (длина: 1 байт) второго элемента информации 400b КаУ, сохраненного в контейнере КаУ |
| 401b' | поле длины (длина: 1 байт) второго элемента информации 400b КаУ |
| 401с' | поле данных (длина: 2 байта) второго элемента информации 400b КаУ |
| 401d' | поле данных (длина: 4 байта) второго элемента информации 400b КаУ |
| 500 | схема, представляющая пример модульного элемента измеряемой информации КаУ |
| 500D | поле данных (длина: 3 байта) элемента 500 измеряемой информации КаУ |
| 501 | поле типа (длина: 1 байт) элемента 500 измеряемой информации КаУ |
| 502 | поле длины (длина: 1 байт) элемента 500 измеряемой информации КаУ |
| 503 | поле действительного значения (длина: 1 байт) элемента 500 измеряемой информации КаУ |
| 504 | поле минимального значения (длина: 1 байт) элемента 500 измеряемой информации КаУ |
| 505 | поле максимальной величины (длина: 1 байт) элемента 500 измеряемой информации КаУ |
| Номер | Техническое свойство (Компонент системы, этап способа) |
| 600 | диаграмма, представляющая пример модульного элемента измеряемой информации КаУ в сценарии асимметричной двунаправленной связи |
| 601а | поле типа (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае асимметричного двунаправленного сценария, обозначающее тип данных, передаваемых из мобильного узла 106а в его узел-корреспондент 106с (прямой поток) |
| 601b | поле длины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае асимметричного двунаправленного сценария, обозначающее количество данных, передаваемых из мобильного узла 106а в его узел-корреспондент 106с (прямой поток) |
| 601с | поле действительной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае прямого потока асимметричного двунаправленного сценария, которое содержит дискретную величину для соответствующего атрибута ресурса |
| 601d | поле максимальной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае прямого потока асимметричного двунаправленного сценария, которое содержит верхнее пороговое значение указанного интервала |
| 601e | поле минимальной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае прямого потока асимметричного двунаправленного сценария, которое содержит нижнее пороговое значение интервала, в пределах которого величины соответствующего атрибута ресурса приемлемы для резервирования |
| 601а' | поле типа (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае асимметричного двунаправленного сценария, обозначающее тип данных, передаваемых из узла-корреспондента 106с в мобильный узел 106а (обратный поток) |
| 601b' | поле длины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае асимметричного двунаправленного сценария, обозначающее количество данных, передаваемых из узла-корреспондента 106с в мобильный узел 106а (обратный поток) |
| 601с' | поле действительной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае обратного потока асимметричного двунаправленного сценария |
| 601d' | поле максимальной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае обратного потока асимметричного двунаправленного сценария |
| 601e' | поле минимальной величины (длина: 1 байт) элемента 600 измеряемой информации КаУ, в случае обратного потока асимметричного двунаправленного сценария |
| 601а" | поле типа (длина: 1 байт) элемента 700 измеряемой информации КаУ, в случае симметричного двунаправленного сценария |
| 601b" | поле длины (длина: 1 байт) элемента 700 измеряемой информации КаУ, в случае симметричного двунаправленного сценария |
| 601с" | поле действительной величины (длина: 1 байт) элемента 700 измеряемой информации КаУ, в случае симметричного двунаправленного сценария |
| 601d" | поле максимальной величины (длина: 1 байт) элемента 700 измеряемой информации КаУ, в случае симметричного двунаправленного сценария |
| 601e" | поле максимальной величины (длина: 1 байт) элемента 700 измеряемой информации КаУ, в случае симметричного двунаправленного сценария |
| 700 | схема, представляющая пример модульного элемента измеряемой информации КаУ в сценарии симметричной двунаправленной связи |
| 800 | схема, представляющая пример связи в сценарии симметричной двунаправленной связи с достаточными ресурсами |
| Номер | Техническое свойство (Компонент системы, этап способа) |
| 900 | схема, представляющая пример связи в сценарии симметричной двунаправленной связи с недостаточными ресурсами |
| S1 | Этап №1: внедрение информации управления ресурсом, предназначенной для передачи между мобильным узлом 106а и узлом-корреспондентом 106с, в IP датаграмму 400, которую передают через ретрансляторы по пути маршрута зарезервированного канала связи этих узлов 106а+с |
| S2 | этап №2: распространение информации управления ресурсами между мобильным узлом 106а и узлом-корреспондентом 106с путем использования одного и того же пути маршрута (альтернатива №1) через ретрансляторы сети 104 в обоих направлениях |
| S3a/b | этап №3а/b: инициирование сообщения запроса на резервирование ресурса, обозначающего требование определенной величины сетевых ресурсов одновременно для обоих направлений мобильным узлом 106а (S3а) или его узлом-корреспондентом 106c (S3b) |
| S4 | этап №4: генерирование уникального идентификатора (ИД) резервирования, ассоциирующего двунаправленное соединение с одним потоком прикладной программы или агрегатированным потоком для классификации IP датаграммы в обоих направлениях инициатором 106а/с сообщения запроса на резервирование ресурса для обеспечения определенного поведения передачи, которое остается неизменным в течение срока существования ассоциированного потока |
| S5 | этап №5: выделение сетевых ресурсов при передаче между сегментами сети, с использованием информации управления ресурсом, добавляемой к IP - датаграмме 400 |
| S6 | этап №6: отслеживание при передаче между сегментами сети этих сетевых ресурсов |
| S7 | этап №7: добавление информации управления ресурсом для каждого направления резервирования через элементы 400а+b информации ресурса, которые представляют собой часть расширения 401c+d, 401c'+d' заголовка IP датаграммы 400, в которой каждый элемент 400а+b информации ресурса представляет либо атрибут ресурса вдоль зарезервированного пути маршрутизации (альтернатива №1) ассоциированного с выражаемым количественно измеряемым параметром ресурса для одного или обоих направлений потока, или атрибутам потока для индивидуального потока или агрегата потока, ассоциированного с выражаемой количественно измеряемой и не выражаемой количественно неизмеряемой контекстной информацией потока в одном или в обоих направлениях потока |
| S8 | этап №8: определение количества элементов 400а+b информации ресурса, которые должны быть помещены в заголовок 401c+d, 401c'+d' IP датаграммы узлом (106а или 106с), который представляет собой узел происхождения информации управления ресурсом |
| S9a | этап №9а: одновременное отслеживание информации о доступных ресурсах для обоих направлений резервирования вдоль зарезервированного пути маршрута (альтернатива №1) между мобильным узлом 106а и узлом-корреспондентом 106с |
| S9b | этап №9Ь: определение действительных значений атрибута ресурса для восходящего и нисходящего направлений, для каждого узла 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) |
| S9c | этап №9с: если в каком-либо узле 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) отслеживаемый атрибут ресурса для восходящего или нисходящего направления или для обоих направлений имеет величину, которая меньше, чем соответствующая величина отслеживаемого атрибута, который переносится в заголовке IP датаграммы, назначение новой величины элементу 400а/b информации ресурса заголовка IP датаграммы |
| Номер | Техническое свойство (Компонент системы, этап способа) |
| S9d | этап №9d: определение текущих значений ресурса для обоих направлений получателем информации управления ресурсом |
| S10a | этап №10а: передача сообщения запроса на резервирование ресурса, описывающего набор спецификаций требований к атрибуту |
| S10b | этап №10b: управление процедурой выделения ресурса для одного или обоих направлений резервирования ресурса мобильным узлом 105 а или узлом-корреспондентом 105с |
| S10c | этап №10с: на основе такого сообщения запроса на резервирование ресурса определение величины атрибута ресурса, который должен быть выделен для восходящего направления, нисходящего направления или для обоих направлений одновременно каждым передающим узлом 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) |
| S11a | этап №11а: добавочная упаковка информации управления ресурсом для различных двунаправленных потоков в одной IP датаграмме 400 |
| S11b | этап №11b: прикрепление элемента информации идентификатора резервирования, относящегося к дополнительному потоку, и элементов 400а+b информации ресурса в заголовке IP датаграммы 400 к заголовку IP датаграммы каждого потока |
| S11c | этап №11с: определение принадлежности этой информации определенному потоку путем группирования идентификаторов резервирования и других элементов информации ресурса 400а+b |
| S12 | этап №12: определение на уровне IP, может ли информация управления двунаправленным или однонаправленным ресурсом быть вставлена в IP датаграмму 400, которая готова для передачи в сетевой интерфейс, или следует сгенерировать отдельную IP датаграмму 400 с этой целью мобильным узлом 106а или узлом-корреспондентом 106с |
| S13a | этап №13а: распознавание условий недостаточности ресурсов вдоль пути маршрута для восходящего и нисходящего направлений в узле-корреспонденте 106с |
| S13b | этап №13b: сравнение отслеживаемых значений атрибута со спецификациями требований атрибута в элементах 400а+b информации ресурса поступающей IP датаграммы 400 |
| S14 | этап №14: установка отслеживаемых значений атрибута ресурса определенных элементов информации ресурса, указанных в заголовке 400 ГР датаграммы, равными нулю в случае, когда, по меньшей мере, один из передающих узлов 150b+с не поддерживает эти атрибуты ресурса |
| S15 | этап №15: установка этих величин атрибута, переносимых в заголовке IP датаграммы, равными нулю, что позволяет конечным точкам резервирования легко интерпретировать ситуацию асимметричности маршрута, если восходящий и нисходящий пути для двунаправленного резервирования не следуют идентичным маршрутам в определенном узле 105b/с маршрутизации, вдоль зарезервированного пути маршрута (альтернатива №1) |
| S16a | этап №16а: интерпретирование сообщений запроса на резервирование ресурса с величиной, равной нулю, для одной или больше спецификаций требования атрибута и явных сообщений высвобождения передающими узлами 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) и инициатором или получателем сообщений запроса на резервирование ресурса |
| S16b | этап №16b: ассоциирование величин этих спецификаций требований атрибута с удалением информации о состоянии резервирования для конкретного потока в передающих узлах 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) |
| Номер | Техническое свойство (Компонент системы, этап способа) |
| S17a | этап №17а: интерпретирование сообщения запроса на резервирование ресурса с величиной, не равной нулю, для одной или больше спецификаций требования атрибута, как явно выраженные сообщения установки передающими узлами 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) и получателем 106с сообщений запроса на резервирование ресурса |
| S17b | этап №17b: ассоциирование величин этих спецификаций требования атрибута с установкой информации состояния резервирования, специфичной для потока в передающих узлах 105b+с вдоль зарезервированного пути маршрута (альтернатива №1) |
| S18a | этап №18а: дополнительная упаковка элемента информации потока, определяющего тип резервирования как двунаправленный или однонаправленный в заголовке 401c+d, 401c'+Ipd' датаграммы сообщения установки резервирования |
| S18b | Этап №18b: интерпретирование этого элемента информации потока в передающих узлах 105b+с вдоль зарезервированного пути маршрута (альтернатива №1), для обеспечения правильной установки информации состояния резервирования |
| S301 | этап №301: включение механизма проверки ресурса |
| S302 | этап №302: в случае, когда по запросу №301 будет получено значение "FALSE" или по запросу №302 будет получено значение "TRUE", установка поля "действительная величина" для обратного направления в элементе измеряемой информации КаУ, равным нулю, и обновление поля "действительная величина" |
| S303 | этап №303: обработка модуля "пассивное или активное резервирование" для восходящего сетевого пути |
| S304 | этап №304: в случае, когда по запросу №302 будет получено значение "FALSE", обновление полей "действительная величина" для обоих направлений в элементе измеряемой информации КаУ |
| S305 | этап №305: обработка модуля "пассивное или активное резервирование" для восходящего или нисходящего сетевых путей |
| Q301 | запрос №301: запрос, поддерживает ли узел маршрутизации двунаправленное резервирование |
| Q302 | запрос №302: в случае, когда по запросу №301 будет получен результат "TRUE", запрос, отличаются ли друг от друга восходящий и нисходящий сетевые пути |
1. Способ резервирования качества услуги (КаУ) для управления сетевыми ресурсами и/или параметрами услуги, необходимыми для симметричных мультимедийных прикладных программ, выполняемых в режиме реального времени, и/или услуг по обработке данных, работающих в мобильном узле (106а) и в узле-корреспонденте (106с), путем передачи сигналов, содержащих информацию по управлению ресурсами, вдоль определенных путей маршрута между этими узлами (106а, 106с), причем указанный способ, основанный на механизме внутриполосной передачи сигналов, содержит следующие этапы:
внедрения (S1) информации по управлению ресурсом, предназначенной для передачи между мобильным узлом (106а) и узлом-корреспондентом (106 с), в сообщении (400), которое передают через путь маршрута, состоящий зарезервированного соединения для этих узлов (106а+с) и
распространения (S2) информация по управлению ресурсом между мобильным узлом (106а) и узлом-корреспондентом (106 с) с использованием одного и того же пути маршрута (альтернатива №1) через сеть (104) в обоих направлениях.
2. Способ по п.1, отличающийся тем, что мобильный узел (106а) инициирует (S3a) сообщение запрос на резервирование ресурса, обозначающее потребность в заданном количестве сетевых ресурсов одновременно в обоих направлениях.
3. Способ по п.1, отличающийся тем, что узел-корреспондент (106с) инициирует (S3b) сообщение запрос на резервирование ресурса, обозначающее потребность в заданном количестве сетевых ресурсов одновременно в обоих направлениях.
4. Способ по любому из пп.2 или 3, отличающийся тем, что инициатор (106а/с) сообщения запроса на резервирование ресурса генерирует (S4) уникальный идентификатор (ИД) резервирования, ассоциирующий двунаправленное соединение, для достижения определенного поведения передачи, которое остается неизменным в течение срока существования ассоциированного потока.
5. Способ по п.2, отличающийся тем, что дополнительно содержит следующие этапы:
выделения (S5) сетевых ресурсов, используя информацию по управлению ресурсом, добавочно упакованную в IP датаграмму (400),
отслеживания (S6) этих сетевых ресурсов или
одновременного выполнения (S5+S6) одновременно для обоих направлений сообщения запроса на резервирование ресурса, в котором информация по управлению ресурсом для обоих направлений зарезервированного пути маршрута внедрена в одну и ту же IP датаграмму (400).
6. Способ по п.1, отличающийся тем, что информация по управлению ресурсом для каждого направления резервирования добавляют (S7) через элементы (400а+b) информации ресурса, которые составляют часть расширения (401c+d, 401c'+d') заголовка IP датаграммы (400), в котором каждый элемент (400а+b) информации ресурса представляет либо атрибут ресурса вдоль зарезервированного пути маршрута, ассоциированный с количественно измеряемым ресурсом или для одного или для обоих направлений потока, или атрибут ресурса для индивидуального потока или агрегата потока, ассоциированного с измеряемой количественно и не измеряемой количественно информацией контекста потока для одного или для обоих направлений потока.
7. Способ по п.6, отличающийся тем, что указанные элементы (400а+b) информации ресурса описывают информацию управления ресурса для восходящего направления от инициатора к получателю или в нисходящем направлении от получателя к инициатору сообщения запроса на резервирование ресурса или в обоих направлениях вместе, в котором восходящее и нисходящее направление уникально идентифицировано мобильным узлом (106а) и узлом-корреспондентом (106с), ввиду их роли в процедуре резервирования, либо как инициатора, или как получателя сообщения запроса на резервирование ресурса.
8. Способ по п.6, отличающийся тем, что указанные элементы (400а+b) информации ресурса организованы в модульной форме для каждого потока, в котором узел (106а или 106с), который является источником информации управления ресурса, определяет (S8) количество элементов (400а+b) информации ресурса, которое требуется разместить в заголовке (401c+d, 401 с'+d') IP датаграммы.
9. Способ по п.1, отличающийся тем, что каждый элемент (400а+b) информации ресурса содержит поле (503) для отслеживаемой величины атрибута и поля (504, 505) спецификации требования атрибута, определяющие требования к потоку, специфичному к атрибуту ресурса, которые описаны верхним пороговым значением, определяющим максимальную величину, и/или нижним пороговым значением, определяющим минимальную величину для соответствующего атрибута ресурса.
10. Способ по п.1, отличающийся тем, что дополнительно содержит следующие этапы:
одновременного отслеживания (S9a) информации о доступных ресурсах в обоих направлениях резервирования вдоль зарезервированного пути маршрута (альтернатива №1) между мобильным узлом (106а) и узлом-корреспондентом (106с),
для каждого узла (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1), определения (S9b) действительных значений атрибута ресурса для восходящего и нисходящего направлений,
если в любом из узлов (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1) отслеживаемый атрибут ресурса для восходящего или нисходящего направлений или для обоих направлений имеет величину, которая меньше, чем соответствующая величина отслеживаемого атрибута, которая переносится в заголовке IP датаграммы, назначения (S9c) новой величины для элемента (400а/b) информации ресурса а заголовке датаграммы IP, что позволяет получателю информации управления ресурсом определять (S9d) текущие значения ресурса для обоих направлений.
11. Способ по п.1, отличающийся тем, что дополнительно содержит следующие этапы:
отправки (S10a) сообщения запроса на резервирование ресурса, описывающего набор спецификаций требований к атрибуту, и управления (S10b) процедурой выделения ресурсов для одного или для обоих направлений резервирования ресурса мобильным узлом (106а) или узлом-корреспондентом (106с),
на основе такого сообщения запроса на резервирование ресурса определения (S10c) величин атрибута ресурса, которые должны быть выделены для восходящего направления, нисходящего направления или для обоих направлений одновременно каждым передающим узлом (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1).
12. Способ по п.1, отличающийся тем, что информацию управления ресурсом для различных двунаправленных потоков добавочно упаковывают (S11а) в ту же IP датаграмму (400), в которой для каждого потока элемента информации идентификатора резервирования, относящегося к дополнительному потоку и элементам (400а+b) информации ресурса в заголовке IP датаграммы (400), прикрепляют (S11b) к заголовку IP датаграммы и группируют идентификаторы резервирования, и другие элементы (400а+b) информации ресурса определяют (S11c) принадлежность этой информации к определенному потоку.
13. Способ по п.1, отличающийся тем, что мобильный узел (106а) или узел-корреспондент (106с) определяет (S12) на уровне IP, может ли быть введена информация по управлению двунаправленным или однонаправленным ресурсом в IP датаграмму (400), которая готова для передачи в сетевой интерфейс, или с этой целью необходимо сгенерировать отдельную IP датаграмму (400).
14. Способ по п.13, отличающийся тем, что информацию по управлению ресурсом помещают в любую IP датаграмму (400), которая следует по зарезервированному пути маршрута (альтернатива №1) между инициатором и получателем сообщения запроса на резервирование ресурса.
15. Способ по п.1, отличающийся тем, что дополнительно содержит этап: распознавания (S13a) условий недостаточности ресурсов вдоль пути маршрута для восходящего и нисходящего направлений в узле-корреспонденте (106с) путем сравнения (S13b) отслеживаемых значений атрибута со спецификациями требования атрибута в элементах (400а+b) информации ресурса прибывающей IP датаграммы (400).
16. Способ по п.1, отличающийся тем, что дополнительно содержит этап установки (S14) в ноль отслеживаемых значений атрибута ресурса специфических элементов информации ресурса, определенных в заголовке (400) IP датаграммы, в случае, когда один или больше передающих узлов (150b+с) не поддерживают эти атрибуты ресурса.
17. Способ по п.1, отличающийся тем, что дополнительно содержит этап установки (S15) в ноль значений атрибута, переносимых заголовком IP датаграммы, что позволяет конечным точкам резервирования просто интерпретировать ситуацию асимметрии маршрутизации, если восходящий и нисходящий пути для двунаправленного резервирования не следуют по идентичным маршрутам в определенном узле маршрутизации (105b/с) вдоль зарезервированного пути маршрута (альтернатива №1).
18. Способ по п.1, отличающийся тем, что дополнительно содержит следующие этапы:
интерпретирования (S16a) сообщений запроса на резервирование ресурса с нулевым значением для одной или больше спецификаций требования атрибута в качестве явных сообщений о высвобождении передающими узлами (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1), и инициатором или получателем сообщений запроса на резервирование ресурса и
ассоциирования (S16b) величин этих спецификаций требования атрибута с удалением информации о состоянии резервирования, специфичного для потока в передающих узлах (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1).
19. Способ по п.1, отличающийся тем, что дополнительно содержит следующие этапы:
интерпретирования (S17a) сообщений запроса на резервирование ресурса с величиной, не равной нулю, для одной или больше спецификаций требований атрибута в качестве явных сообщений установки передающими узлами (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1) и получателем (106с) сообщений запроса на резервирование ресурса и
ассоциирования (S17b) величин этих спецификаций требований атрибута с установкой информация о состоянии резервирования, специфичного для потока в передающих узлах (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1).
20. Способ по п.1, отличающийся тем, что дополнительно содержит следующие этапы:
дополнительной упаковки (S18а) элемента информации потока, определяющего тип резервирования, как двунаправленный или однонаправленный, в заголовке (401c+d, 401c'+d') IP датаграммы сообщения установки резервирования,
интерпретирования (S18b) этого элемента информации потока в передающих узлах (105b+с) вдоль зарезервированного пути маршрута (альтернатива №1), для обеспечения правильной установки зарезервированной информации состояния.
