Способ, система и устройство для поддержки услуги hierarchical mobile ip

Иллюстрации

Показать все

Изобретение относится к системам мобильной связи. Технический результат заключается в усовершенствовании поддержки услуги Hierarchical Mobile IP версии 6 (HMIPv6). Способ поддержки услуги HMIPv6 для мобильного узла содержит этап, на котором используют инфраструктуру аутентификации, авторизации и управления учетными записями (ААА), чтобы инициализировать услугу HMIPv6, при этом назначают посредством упомянутой инфраструктуры ААА надлежащую точку привязки мобильности (MAP) мобильному узлу для услуги HMIPv6; и передают по упомянутой инфраструктуре ААА относящуюся к HMIPv6 информацию для аутентификации и авторизации мобильного узла для услуги HMIPv6 в отношении назначенной MAP. 5 н. и 20 з.п. ф-лы, 11 ил., 3 табл.

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение, в общем, относится к мобильной связи и, в частности, предназначается для поддержки услуги протокола Mobile IP (реализация межсетевого протокола (IP) для мобильной связи), главным образом, услуги Hierarchical Mobile IP (иерархического Mobile IP) версии 6.

Предшествующий уровень техники

Mobile IP (MIP) дает возможность мобильному узлу (MN) изменять свою точку подключения к Интернету с минимальным нарушением предоставления услуг. MIP сам по себе не предоставляет никакой конкретной поддержки мобильности в различных административных доменах, что ограничивает применимость MIP при крупномасштабном коммерческом развертывании.

Протокол Mobile IP версии 6 (MIPv6) [1] дает возможность узлам перемещаться по топологии Интернета, одновременно поддерживая достижимость и выполняющиеся соединения с соответствующими узлами. В этом контексте каждый мобильный узел всегда идентифицируется своим опорным адресом вне зависимости от текущей точки подключения к Интернету IPv6. Будучи расположенным вне опорной сети, мобильный узел также ассоциирован с адресом обслуживания (CoA), который предоставляет информацию о текущем местоположении мобильных узлов. Пакеты IPv6, направляемые на опорный адрес мобильного узла, в большей или меньшей степени прозрачно направляются по адресу обслуживания. Протокол MIPv6 дает возможность узлам IPv6 кэшировать связывание опорного адреса мобильного узла к адресу обслуживания и затем отправлять любые пакеты, предназначаемые мобильному узлу, на адрес обслуживания. С этой целью мобильный узел отправляет так называемые обновления связывания своему опорному агенту (HA) и соответствующим узлам, с которыми он обменивается данными, каждый раз при перемещении. Аутентификация обновлений связывания требует некоторого количества двусторонних прохождений сигналов между мобильным узлом и каждым соответствующим узлом. Помимо этого одно двустороннее прохождение необходимо, чтобы обновить опорный агент, хотя это может быть выполнено одновременно с обновлением соответствующих узлов.

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

По этой и другим причинам предложен протокол Hierarchical Mobile IPv6 (HMIPv6) [2], чтобы поддерживать локальные или иерархические формы управления мобильностью. Иерархическое управление мобильностью для Mobile IPv6 уменьшает объем передачи сигналов между MN, его соответствующими узлами (CN) и его HA за счет введения так называемой точки привязки мобильности (MAP), размещенной в гостевой (посещаемой) сети. Введение MAP также может быть использовано, чтобы повышать производительность Mobile IPv6 в показателях скорости эстафетной передачи обслуживания.

Фиг. 1 схематично иллюстрирует пример домена HMIPv6 предшествующего уровня техники с MAP в гостевой сети. Общий вид системы включает в себя опорную сеть 10 с обычным опорным агентом (HA) 15, гостевую сеть 20 с MAP 25 и маршрутизаторами 27 доступа (AR). Мобильный узел (MN) 30, осуществляющий вход в домен MAP, принимает так называемые извещения маршрутизатора, содержащие информацию об одной или более локальных MAP. MN 30 может связывать свое текущее местоположение (адрес обслуживания в режиме соединения, LCoA) с адресом в подсети MAP, называемым региональным адресом обслуживания (RCoA). Выступая в качестве локального HA, MAP 25 принимает все пакеты от имени MN 30, который он обслуживает, и инкапсулирует и переадресует их непосредственно по LCoA этого MN.

MAP может помочь в предоставлении прозрачной мобильности для мобильного узла по мере того, как он перемещается от маршрутизатора 27-1 доступа 1 (AR1) к маршрутизатору 27-2 доступа 2 (AR2), обмениваясь данными с соответствующим узлом (CN) 40. После входа в гостевую сеть мобильный узел 30 обнаруживает глобальный адрес MAP 25. Этот адрес хранится в маршрутизаторах доступа и передается мобильному узлу посредством извещений маршрутизатора. Этот процесс называется обнаружением MAP и необходим, чтобы информировать мобильный узел о наличии MAP. Домен MAP обычно задается маршрутизаторами доступа, которые передают извещения со сведениями MAP подключенным мобильным узлам. Процесс обнаружения MAP продолжается по мере того, как мобильный узел перемещается из одной подсети в другую. До тех пор пока мобильный узел передвигается в рамках домена MAP, маршрутизаторы доступа сконфигурированы, чтобы передавать извещения с одним и тем же адресом или адресами MAP. Если принято изменение в передаваемом адресе MAP, мобильный узел должен выполнить распознавание перемещения и отправить необходимые обновления связывания своему опорному агенту и соответствующим узлам.

Если мобильный узел не поддерживает HMIPv6, то обнаружение MAP не выполняется и Mobile IPv6 не используется для управления мобильностью. С другой стороны, если мобильный узел поддерживает HMIPv6, он должен выбрать использование HMIPv6. В таком случае мобильный узел регистрируется в MAP 25 посредством отправки обновления связывания, содержащего его опорный адрес и адрес LCoA. Опорный адрес, используемый в обновлении связывания, - это адрес RCoA, и MAP 25 сохраняет эту информацию в своем кэше связывания, чтобы иметь возможность переадресовывать пакеты в их конечное место назначения, когда они принимаются от соответствующих узлов 40 или HA 15.

HMIPv6 сам по себе, как в случае MIP, не предоставляет никакой конкретной поддержки мобильности в различных административных доменах, что ограничивает применимость HMIPv6 при крупномасштабном коммерческом развертывании.

Обычно можно ожидать, что MN потребуется быть аутентифицированным перед санкционированием (авторизацией) использования услуг HMIPv6. Важно, чтобы отношение безопасности между мобильным узлом и MAP носило строгий характер; оно предпочтительно должно влечь за собой взаимную аутентификацию, защиту целостности и защиту от атак с повторением пакетов. С этой целью распространение относящихся к полномочиям данных, таких как ключи безопасности, между MN и MAP в настоящее время должно основываться на инфраструктурах открытого ключа (PKI) и других комплексных протоколах. Текущий проект HMIPv6 [2] также ограничивает местоположение MAP в гостевой сети.

Сущность изобретения

Настоящее изобретение преодолевает эти и другие недостатки структур предыдущего уровня техники.

Общая задача настоящего изобретения - предоставить усовершенствованную поддержку услуги HMIPv6 для мобильного узла. Решение должно предпочтительно включать в себя механизмы, которые облегчают развертывание HMIPv6.

В частности, желательно предоставить модернизированное, в то же время надежное решение по аутентификации и авторизации услуги HMIPv6, которое не должно основываться на инфраструктурах открытого ключа (PKI) и других комплексных протоколах.

Другая задача изобретения - обеспечить уменьшение общего времени на настройку HMIPv6.

Еще одна задача изобретения - предоставить способ и систему для поддержки услуги HMIPv6.

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

Эти и другие задачи решаются посредством изобретения, как задано в прилагаемой формуле изобретения.

Базовая идея изобретения заключается в том, что оно основывается на инфраструктуре AAA с целью инициализации услуги HMIPv6 для мобильного узла. В соответствии с предпочтительным вариантом осуществления изобретения инициализация услуги HMIPv6 задействует аутентификацию и авторизацию мобильного узла для услуги HMIPv6 на основе инфраструктуры AAA. В важном сценарии мобильный узел передвигается в гостевой сети, и инфраструктура AAA связывает гостевую сеть с опорной сетью мобильного узла. Тем не менее, изобретение также поддерживает сценарий, когда мобильный узел фактически расположен в опорной сети. В этом случае компонент инфраструктуры AAA опорной сети может предоставлять необходимую поддержку услуги HMIPv6 с помощью MAP в опорной сети.

Использование в качестве основы инфраструктуры AAA предпочтительно задействует передачу относящейся к HMIPv6 информации, необходимой для авторизации мобильного узла для услуги HMIPv6, по инфраструктуре AAA.

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

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

Фаза авторизации, разумеется, включает в себя явную авторизацию, но может также включать в себя конфигурирование задействуемых узлов. Связанное с HMIPv6 конфигурирование, такое как конфигурирование мобильного узла и/или конфигурирование MAP, может, следовательно, обычно учитываться как часть общей процедуры авторизации. Это в типичном случае означает, что относящейся к HMIPv6 информацией может быть информация аутентификации, авторизации и/или конфигурирования HMIPv6.

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

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

В случаях, когда MAP расположена в опорной сети, может быть подходящим использовать сервер AAA опорной сети (AAAh) в качестве надлежащего компонента инфраструктуры AAA для назначения MAP. С другой стороны, когда MAP расположена в гостевой сети, может быть подходящим использовать сервер AAA гостевой сети (AAAv) для назначения MAP. Фактически, местоположение MAP может быть в опорной сети, гостевой сети или других сетях. Больше нет никакой обязательной зависимости от извещений маршрутизатора, содержащих информацию о MAP в рамках заранее заданных доменов MAP.

Использование в качестве основы инфраструктуры AAA, в отличие от использования инфраструктуры PKI, предлагает различные возможности инициализации услуги HMIPv6. Например, можно предоставить расширение к общему протоколу аутентификации, переносимому по инфраструктуре AAA, и/или усовершенствовать приложение протокола архитектуры AAA.

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

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

Другой способ, который должен быть использован как дополняющий или альтернативный дополнениям EAP, может заключаться в том, чтобы усовершенствовать более низкие уровни EAP, например, созданием нового или расширенного приложения протокола структуры AAA, такого как приложение Diameter, адаптированное для HMIPv6, или приложение, основанное на протоколе Radius.

Когда MAP расположена в опорной сети, можно, например, использовать дополненный протокол аутентификации, переносимый по инфраструктуре AAA, или усовершенствованное приложение протокола архитектуры AAA. Тем не менее, когда MAP расположена в гостевой сети, дополненный протокол EAP предпочтительно используется в сочетании с усовершенствованным приложением протокола архитектуры AАA, либо усовершенствованное приложение протокола архитектуры структуры AAA используется без какой-либо поддержки дополнений EAP.

Например, дополненный протокол EAP может переноситься посредством PANA (протокола для переноса аутентификации при доступе к сети), PPP (протокола двухточечного соединения), IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети, а также посредством приложения Diameter или Radius в рамках инфраструктуры AAA.

В частности, использование в качестве основы дополнений EAP предоставляет модернизированное решение, которое управляемо и современно, с минимумом проблем обратной совместимости. Использование EAP дает возможность клиенту AAA (и AAAv) быть осведомленным о процедурах HMIPv6 (т.е. это снимает зависимость от поддержки HMIPv6 в гостевой сети) и выступать в качестве простого опосредованного агента(ов), по меньшей мере, когда MAP расположена в опорной сети. Это одно из основных преимуществ использования EAP.

Посредством также включения относящейся к MIPv6 информации в стек дополненных протоколов аутентификации либо в усовершенствованное приложение протокола инфраструктуры AAA можно одновременно предоставлять аутентификацию и авторизацию HMIPv6 и MIPv6 в одном двустороннем прохождении сигнала по инфраструктуре AAA. Разумеется, можно использовать эту сеть с поддержкой MIPv6/HMIPv6 и исполнять только аутентификацию и/или авторизацию HMIPv6 без участия MIPv6 и наоборот, в зависимости от конкретной потребности MN в конкретном случае. Это дает возможность гибкого использования одного дополненного протокола аутентификации и/или усовершенствованного приложения протокола архитектуры AAA в различных вариантах использования.

Изобретение предлагает следующие преимущества:

- эффективная инициализация услуги HMIPv6;

- эффективная передача относящейся к HMIPv6 информации для авторизации услуги HMIPv6;

- модернизированное решение по поддержке HMIPv6 на основе расширения EAP, которое управляемо и современно, с минимумом проблем обратной совместимости;

- уменьшение общего времени на настройку HMIPv6;

- оптимизация аутентификации, авторизации и мобильности в общей процедуре;

- основанное на AAA назначение MAP;

- размещение MAP не ограничено гостевой сетью;

- MAP может быть расположена в опорной сети, чтобы разрешать вопросы масштабируемости HA, разгружать HA посредством уменьшения числа обновлений связывания, которые переходят к HA в ходе мобильности внутри домена MAP;

- одновременное предоставление аутентификации и авторизации HMIPv6 и MIPv6 в одном двустороннем прохождении сигнала.

Другие преимущества, предлагаемые настоящим изобретением, будут приняты во внимание при прочтении нижеприведенного описания вариантов осуществления изобретения.

Перечень фигур чертежей

Изобретение вместе со своими дополнительными задачами и преимуществами лучше всего понимаемо посредством обращения к последующему описанию, рассматриваемому вместе с прилагаемыми чертежами, на которых:

Фиг.1 - схема, иллюстрирующая пример домена HMIPv6 предшествующего уровня техники с MAP в гостевой сети;

Фиг.2 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, передвигающегося в гостевой сети, согласно примерному варианту осуществления изобретения;

Фиг.3 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, передвигающегося в гостевой сети, согласно другому примерному варианту осуществления изобретения;

Фиг.4 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 для мобильного узла, работающего в собственной опорной сети, согласно примерному варианту осуществления изобретения;

Фиг.5 - блок-схема опорной сети AAA согласно предпочтительному примерному варианту осуществления изобретения;

Фиг.6 - блок-схема узла MAP согласно предпочтительному примерному варианту осуществления изобретения;

Фиг.7 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей Diameter/EAP/HMIPv6, для случая, когда MAP расположена в опорной сети;

Фиг.8 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей Diameter/EAP/HMIPv6, в сочетании с приложением Diameter HMIPv6, для случая, когда MAP расположена в гостевой сети;

Фиг.9 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей приложение Diameter HMIPv6, для случая, когда MAP расположена в опорной сети;

Фиг.10 - иллюстрация примерной последовательности обмена сигналами для AAA HMIPv6, использующей приложение Diameter HMIPv6, для случая, когда MAP расположена в гостевой сети;

Фиг.11 - блок-схема последовательности операций иллюстративного примера способа поддержки услуги HMIPv6 для мобильного узла.

Подробное описание вариантов осуществления изобретения

На чертежах одинаковые символы ссылок используются для соответствующих или аналогичных элементов.

Основная идея согласно изобретению заключается в инициировании услуги HMIPv6 для мобильного узла на основе инфраструктуры AAA вместо использования в качестве основы сложной инфраструктуры PKI для цели аутентификации и авторизации HMIPv6. Инициирование HMIPv6 допустимо как для мобильного узла, работающего в опорной сети, так и мобильного узла, передвигающегося в гостевой сети, используя инфраструктуру AAA опорной сети в первом случае и общую инфраструктуру AAA, связывающую гостевую сеть с опорной сетью, во втором случае.

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

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

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

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

Термин "AAA" должен рассматриваться в рамках его общего смысла в проектах Интернет-документов, RFC и других определяющих стандарты документах. В типичном случае соглашение по аутентификации и ключам безопасности инфраструктуры AAA (авторизация, аутентификация, управление учетными записями) основано на симметричном шифровании, подразумевающем наличие первоначального секрета, совместно используемого мобильным узлом и оператором опорной сети или доверенной стороной. В некоторых сценариях или приложениях, например, функциональная возможность управления учетными записями инфраструктуры AAA может быть отключена или не реализована. Инфраструктура AAA, в общем, включает в себя один или более серверов AAA в опорной сети, промежуточные сети (если имеются) и/или гостевую сеть, а также может включать в себя один или более клиентов AAA.

В общем, протоколы AAA, такие как протокол Diameter, точно позволяют мобильным пользователям передвигаться и получать услугу в сетях, которые не обязательно принадлежат их собственному поставщику услуг. Поэтому, для того чтобы Mobile IP был развернут в коммерческих сетях, должна быть поддержка AAA для протокола. Для специального случая Mobile IPv6 (MIPv6) без какого-либо иерархического управления мобильностью предложен проект Интернет-документа [3], который задает новое приложение для Diameter, которое дает возможность роуминга MIPv6 в сетях, отличных от сети, администрируемой собственным оператором. В нашей Предварительной патентной заявке США номер 60/479156, поданной 18 июня 2003 года, а также в более новом проекте Интернет-документа [4], предложены архитектура и соответствующие протоколы для выполнения авторизации и конфигурирования Mobile IPv6 на основе инфраструктуры AAA. Необходимое взаимодействие между сервером AAA собственного поставщика услуг и мобильным узлом для MIPv6 реализовано с помощью EAP (расширяемого протокола аутентификации), который передает информацию для согласования Mobile IPv6 вместе с данными аутентификации.

Фиг. 2 - схема, иллюстрирующая новую архитектуру поддержки HMIPv6 согласно примерному варианту осуществления изобретения. Мобильный узел 130 передвигается в гостевой сети, и аутентификация и авторизация HMIPv6 выполняются посредством использования инфраструктуры AAA, связывающей гостевую сеть и опорную сеть мобильного узла. В данном примере инфраструктура AAA, по существу, задействует сервер 110 AAA опорной сети, сервер 120 ААА гостевой сети и клиент 122 AAA в гостевой сети.

Предпочтительно, сервер 120 AAA гостевой сети (AAAv) может быть использован как подходящий компонент инфраструктуры AAA для назначения MAP, принимая во внимание политику гостевого оператора при выборе MAP. Выбор MAP может быть, например, основан на текущей загрузке доступных MAP, местоположении мобильного узла и/или, возможно, предпочтениях, заданных мобильным узлом.

Основным компонентом инфраструктуры AAA является сервер 110 AAAh, который предпочтительно переадресует любой запрос на назначение MAP от мобильного узла серверу 120 AAAv и, кроме того, генерирует ключ безопасности или аналогичные реквизиты безопасности для немедленной или будущей ассоциации безопасности между заданным мобильным узлом 130 и назначенной MAP 125. После этого ключ безопасности в типичном случае передается из AAAh 110 в MAP 125 посредством AAAv 120, а MAP 125 предпочтительно отвечает информацией для завершения ассоциации безопасности с AAAh 110 посредством AAAv 120. В завершение сервер 110 AAAh отправляет сгенерированную и собранную информацию по авторизации HMIPv6 мобильному узлу 130 по инфраструктуре AAA. Предполагается, что защищенные туннели инфраструктуры AAA или другие меры безопасности, такие как шифрование и защита целостности источника, используются для передачи конфиденциальной информации, такой как ключи безопасности.

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

Предпочтительно, используется дополненный протокол аутентификации, такой как дополненный протокол EAP (расширяемый протокол аутентификации), адаптированный для HMIPv6, с добавлением усовершенствованного приложения протокола инфраструктуры AAA, такого как приложение HMIPv6 Diameter или Radius, для интерфейса между сервером AAAh и MAP гостевой сети посредством сервера AAAv.

Например, новый или дополненный протокол аутентификации может переноситься посредством PANA (протокола для переноса аутентификации при доступе к сети), PPP (протокола двухточечного соединения), IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети, а также посредством Diameter или аналогичного протокола структуры или поставщика услуг связи AAA в рамках инфраструктуры AAA.

Альтернативно, усовершенствованное приложение протокола структуры AAA, например новое или дополненное приложение Diameter или Radius, используется без поддержки каких-либо дополнений EAP. Для пути между мобильным узлом и клиентом AAA приложение Diameter или Radius может, например, переноситься посредством ICMP (протокола управляющих сообщений в Интернете).

Также определено, что существуют случаи, когда выгодно иметь MAP, размещенную в опорной сети или других сетях, например, для случая, когда гостевая сеть не предоставляет поддержки MAP. Примерная архитектура поддержки HMIPv6 в MAP, расположенной в опорной сети, проиллюстрирована на фиг. 3.

В данном случае для назначения MAP выгодно использовать сервер 110 ААА опорной сети (AAAh). Предпочтительно, сервер 110 AAA опорной сети (AAAh) также генерирует ключ безопасности или аналогичные параметры или полномочия для ассоциации безопасности между мобильным узлом и назначенной MAP 125 и отправляет упомянутый ключ безопасности в MAP 125. MAP 125 отвечает информацией для завершения ассоциации безопасности с AAAh 110, и AAAh 110 далее отправляет информацию авторизации HMIPv6 мобильному узлу 130 по инфраструктуре AAA.

Поскольку MAP 125 расположена в опорной сети, AAAv 120 не должен видеть транзакцию, и, таким образом, можно иметь "процедуру сквозного обмена данными" для аутентификации и авторизации HMIPv6. Это предпочтительно осуществляется посредством использования дополненного протокола аутентификации, такого как дополненный протокол EAP (расширяемый протокол аутентификации), адаптированного для HMIPv6. Альтернативно, может быть использовано усовершенствованное приложение протокола структуры AAA, например приложение HMIPv6 Diameter или Radius. MAP 125, расположенная в опорной сети, также может быть использована, чтобы разрешать вопросы масштабируемости HA, разгрузки HA 115 посредством уменьшения числа обновлений связывания, которые переходят к HA 115 в ходе мобильности внутри домена MAP. Посредством выбора MAP таким образом, чтобы она была топографически близкой к местоположению MN, могут быть реализованы быстрые эстафетные передачи обслуживания.

Следует понимать, что изобретение устранило ограничение предшествующего уровня техники, заключающееся в том, что MAP 125 должна быть расположена в гостевой сети. Теперь местоположение MAP может быть в опорной сети, гостевой сети или других сетях. Технически возможно связывать MN с любой MAP, покуда может быть получен RCoA в MAP с поддержкой AAA, если операторы разрешают это.

Переназначение MAP может произойти в ходе следующих примерных случаев.

- Истечение срока действия ключей безопасности между MN и MAP. В этом случае MN инициирует повторную аутентификацию/авторизацию HMIPv6, и сеть может назначить другую MAP, которая более подходит, на основе, к примеру, текущего топографического местоположения MN.

- При запросе мобильного узла (инициированном MN). В этом случае MN инициирует повторную аутентификацию/авторизацию HMIPv6, запрашивая переназначение MAP.

- При запросе сети (инициированном сетью). В этом случае либо AAAh, либо AAAv инициирует переназначение MAP и "проталкивает" ее MN, когда возникает необходимость, к примеру, когда MN перемещается к AR, который лучше покрывается новой MAP.

Ссылаясь на фиг. 2 и 3 снова, число возможных примеров различных комбинаций протоколов между сегментами "Клиент AAA-AAAh" и "AAAh-(AAAv)-MAP" обобщено ниже:

Клиент AAA<->AAAh AAAh<->(AAAv)<->MAP
(i) Приложение AAA HMIPv6 Приложение AAA HMIPv6
(ii) Дополненный протокол аутентификации Приложение AAA HMIPv6
(iii) Дополненный протокол аутентификации Дополненный протокол аутентификации

Сочетание (iii) главным образом применимо для случая, когда MAP расположена в опорной сети. Когда MAP расположена в гостевой сети, AAAv может быть задействован при выборе MAP на основе политики гостевой сети.

В другом сценарии, проиллюстрированном схематически на фиг.4, мобильный узел 130 фактически расположен в опорной сети, а компонент инфраструктуры AAA, такой как сервер 110 AAAh, предоставляет необходимую поддержку услуги HMIPv6 с помощью MAP 125 в опорной сети. Это означает, что только значимые части дополненного протокола аутентификации HMIPv6 и приложения AAA HMIPv6 должны быть использованы для обмена необходимой информацией аутентификации и авторизации.

Фиг.5 - блок-схема AAA сервера опорной сети согласно предпочтительному примерному варианту осуществления изобретения. В этом примере сервер 110 AAAh, по существу, содержит необязательный модуль 111 назначения MAP, модуль 112 ассоциации безопасности, средство 113 управления информацией авторизации и интерфейс 114 ввода-вывода. Для MAP в случае опорной сети сервер 110 AAAh включает в себя модуль 111 назначения MAP, которой выполнен с возможностью назначения и переназначения подходящей MAP мобильному узлу. Для MAP в случае гостевой сети сервер 110 AAAh в типичном случае принимает необходимую информацию по назначениям MAP посредством своего интерфейса 114 ввода-вывода. Сервер AAAh в типичном случае также принимает стартовое число ключа и обновление связывания (BU) от мобильного узла. Альтернативно, сервер AAAh сам генерирует стартовое число ключа и отправляет его мобильному узлу. Модуль 112 ассоциации безопасности предпочтительно генерирует требуемый ключ безопасности в ответ на стартовое число и защищенным образом передает этот ключ в MAP (непосредственно в MAP в опорной сети или посредством сервера AAAv в MAP в гостевой сети). Обновление связывания (BU) также переадресуется в MAP. Сервер 110 AAAh принимает адрес RCoA от MAP и сохраняет эти данные вместе с другой соответствующей информацией авторизации (и/или конфигурирования) в средстве 113 управления информацией авторизации. Сервер AAAh может также принимать информацию, например информацию IPSec от MAP, для завершения ассоциации безопасности. В завершение собранная информация авторизации (и/или конфигурирования) передается мобильному узлу.

Сервер AAAh также может отвечать за назначение опорного адреса (если только опорный адрес не сконфигурирован самим MN) и/или назначения опорного агента.

Фиг.6 - блок-схема узла MAP согласно предпочтительному примерному варианту осуществления изобретения. В этом примере MAP 125, по существу, содержит модуль 126 назначения RCoA, модуль 127 ассоциации безопасности и интерфейс 128 ввода-вывода. MAP предпочтительно взаимодействует с сервером AAA опорной сети для поддержки установления ассоциации безопасности с мобильным узлом. MAP принимает ключ безопасности от сервера AAA опорной сети по интерфейсу 128 ввода-вывода для защищенного хранения в модуле 127 ассоциации безопасности. MAP также подготавливает и отправляет информацию, необходимую для завершения ассоциации безопасности с мобильным узлом, обратно серверу AAA опорной сети, который, в свою очередь, переадресует информацию мобильному узлу по инфраструктуре AAA. Для связывания в MAP модуль 126 RCoA предпочтительно назначает адрес RCoA мобильному узлу, сохраняет этот адрес вместе с адресом LCoA мобильного узла в кэше связывания (не показан) MAP, а также отправляет назначенный адрес RCoA серверу AAA опорной сети для последующей переадресации мобильному узлу.

Для лучшего понимания изобретения далее описаны более подробные примеры дополненного протокола аутентификации для HMIPv6 и приложения протокола инфраструктуры AAA, адаптированного для HMIPv6.

Дополненный протокол аутентификации для HMIPv6

В предпочтительном примерном варианте осуществления задается дополненный протокол аутентификации для HMIPv6, проиллюстрированный в данном документе посредством нового или дополненного протокола аутентификации EAP (упоминаемого как "способ аутентификации HMIPv6" или "EAP/HMIPv6"), который переносит относящуюся к HMIPv6 информацию, облегчающую, например, обнаружение MAP, динамическое назначение MAP, динамическое назначение RCoA, распространение ключей безопасности между MN и MAP и/или возможное совмещение процедур мобильности HMIPv6.

Если требуется, аутентификация и/или авторизация HMIPv6 и MIPv6 может быть интегрирована в один протокол, к примеру, задающий EAP/HMIPv6 как расширенный набор протокола EAP/MIPv6, который в дополнение к конкретным для MIPv6 значениям длины/типа (TLV) также задает новые конкретные для HMIP TLV-атрибуты. Посредством включения TLV-атрибутов EAP/MIPv6 в качестве части EAP/HMIPv6 можно обеспечивать одновременные исполнения аутентификации и/или авторизации MIPv6 и HMIPv6 за один проход, что дает возможность сокращения времени настройки. Также можно исполнять только аутентификацию и/или авторизацию HMIPv6 без участия MIPv6 и наоборот, в зависимости от конкретной потребности MN в конкретном случае. Это дает возможность гибкого использования одного протокола аутентификации EAP, EAP/HMIPv6 в различных вариантах использования.

В частности, использование в качестве основы дополнений EAP предоставляет модернизированное решение, которое управляемо и современно, с минимумом проблем обратной совместимости. Использование EAP дает возможность клиенту AAA (и AAAv) быть осведомленным о процедурах HMIPv6 (т.е. это снимает зависимость от поддержки HMIPv6 в гостевой сети) и выступать в качестве простого опосредованного агента(ов), по меньшей мере, когда MAP расположена в опорной сети. Это одно из основных преимуществ использования EAP.

Как указывалось выше, EAP/HMIPv6 может, например, переноситься посредством PANA, PPP, ICMP, IEEE 802.1X или даже по интерфейсам GPRS/UMTS между мобильным узлом и клиентом AAA в гостевой сети. Хотя PANA может быть предпочтительным в некоторых случаях, другие протоколы поставщиков услуг связи, которые удовлетворяют требованиям EAP по гарантиям упорядочивания нижних уровней (например, PPP [6] и IEEE 802.1X [7]), могут быть использованы, чтобы переносить EAP/MIPv6 между MN и клиентом AAA. Конкретно для случая CDMA2000 3GPP2 можно переносить EAP/HMIPv6 между MN и клиентом AAA с помощью инкапсуляции протокола канального уровня PPP со значением поля протокола, равным C227 (шестнадцатеричная форма) для EAP [6].

Предпочтительный вариант осуществления использует Diameter, Radius или аналогичный протокол поставщика услуг связи или структуры AAA для обмена данными между клиентом AAA и сервером AAAh. Например, помимо клиента AAA в инфраструктуре AAA может быть использовано приложение Diameter EAP [5] для инкапсуляции EAP/HMIPv6 в Diameter, т.е. между клиентом PAA/AAA и AAAh. Протокол Diameter может быть использован AAAh для необязательного назначения фильтров пакетов MIP посредством правил фильтрации MIP для PAA/EP и HA, которые соответствуют точкам активации фильтров. Протокол Diameter также может быть использован AAAh для распространения ключей безопасности PAA для безопасности PANA и дополнительной сигнализации параметров QoS (качества обслуживания).

Следует заметить, что даже несмотря на то, что Diameter является предпочтительным выбором, в некоторых случаях может быть подходящим вместо него использовать другой протокол AAA, такой как Radius, с модификациями, очевидными для специалиста в данной области техники.

Более того, совмещение процедур мобильности HMIPv6 в EAP/HMIPv6 дает возможное сокращение общего времени на настройку посредством оптимизации аутентификации, авторизации и мобильности в общей процедуре.

Примерные подробности протокола EAP/HMIPv6

Далее предоставляются подробные сведения о протоколе EAP/HMIPv6, чтобы показать примеры общей последовательности обмена сигналами и жизнеспособности концепции.

TLV-атрибуты EAP

В первом примере реализации набор новых TLV-атрибутов EAP задан в рамках EAP/HMIPv6. Посредством этих атрибутов протокол EAP может, в дополнение к основной информации по аутентификации IPv6, переносить относящуюся к HMIPv6 информацию и, в необязательном порядке, также относящуюся к MIPv6 информацию.

Различные протоколы аутентификации возможны для EAP/HMIPv6. В предпочтительном