Результат интеллектуальной деятельности: СПОСОБ И УСТРОЙСТВО, ДЛЯ РЕТРАНСЛЯЦИИ ПАКЕТОВ

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

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

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

Преобразование сетевых адресов (NAT) является процессом модификации информации о сетевых адресах в заголовках пакетов дейтаграмм при переходе через устройство маршрутизации трафика с целью повторного отображения заданного адресного пространства в другое. NAT используется совместно с имитацией сети (или имитацией IP), которая является способом, который скрывает все адресное пространство, обычно состоящее из приватных сетевых адресов, за одним адресом IP в другом, часто открытом адресном пространстве. Этот механизм осуществляется в устройстве маршрутизации, которое использует таблицы преобразования с запоминанием состояний, чтобы отображать “скрытые” адреса в один адрес, а затем переписывает исходящие пакеты протокола Internet (IP) на выходе таким образом, что они кажутся как берущие начало из маршрутизатора. В обратном маршруте связи ответы отображаются обратно в порождающий адрес IP с использованием правил (“состояния”), сохраненных в таблицах преобразования. Правила таблицы преобразования, установленные таким образом, сбрасываются после короткого периода без нового трафика, обновляющего их состояние.

Конечно, использование преобразования сетевых адресов означает, что со многими хост-узлами в Internet нельзя непосредственно устанавливать связь с помощью других хост-узлов, поскольку они находятся за преобразователем сетевых адресов (NAT), который предотвращает входящие соединения. Разработаны разные способы прохождения NAT, например создание интерактивной возможности соединения (см. J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. draft-ietf-mmusicice-19 (работа в ходе выполнения). October 2007), чтобы преодолеть эту проблему, но с определенными видами NAT единственным способом, чтобы создать одноранговое соединение между двумя хост-узлами, необходимо ретранслировать весь трафик через узел, с которым могут устанавливать связь оба одноранговых узла (включая одноранговый узел или одноранговые узлы за NAT).

Прохождение с использованием ретрансляторов вокруг NAT (TURN) (см. Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). draft-ietf-behave-turn-15 (работа в ходе выполнения). February 2009) позволяет хост-узлу (который является клиентом TURN) регистрировать “ретранслированный адрес” (комбинацию адреса IP и номера порта) в сервере TURN таким образом, что сеанс устанавливается “через” NAT между сервером TURN и клиентом TURN (примечание, соединение, инициированное с помощью хост-узла за NAT, обычно даст в результате сеанс, который установлен через NAT и через который узел, с которым инициировано соединение, может посылать пакеты в хост-узел). Соединение, инициированное с помощью дистанционного однорангового узла с ретранслированным адресом, ретранслируется с помощью сервера TURN на клиент TURN таким образом, что оно проходит через пробитое отверстие в NAT. Клиент TURN может посылать данные в одноранговый узел с помощью сервера TURN таким образом, что с точки зрения однорангового узла данные кажутся берущими начало из ретранслированного адреса. С использованием сервера TURN, даже с самым ограниченным типом NAT, маршрут связи может быть установлен между двумя одноранговыми узлами.

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

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

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

Проект Internet (IETF) “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (July 8, 2007)”, предоставляет механизм для избежания инкапсуляции. Этот механизм использует запрос “установки активного места назначения” (“Set Active Destination”). Однако механизм не позволяет, чтобы множество сеансов были мультиплексированы в сервер TURN в клиентскую линию связи. Это предложение дополнительно рассмотрено в J. Rosenberg et al, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN); draft-ietf-behave-turn-07.txt, описывающей использование TURN.

Perreault S. et al, “Traversal Using Relays around NAT (TURN) Extensions for Allocations TCP; draft-ietf-behave-turn-tcp-03.txt” описывает процедуру, предназначенную для установления соединений TCP с помощью сервера TURN. Использование “идентификатора соединения” позволяет серверу TURN связывать вместе первое соединение TCP между сервером TURN и хост-узлом и второе соединение TCP между сервером TURN и одноранговым узлом.

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

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

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

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

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

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

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

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

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

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

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

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

Модуль определения идентификации может быть сконфигурирован с возможностью определения входящего и/или исходящего идентификаторов верхнего уровня посредством идентификации и использования одного из следующих параметров протокола: тэга опознавательного кода хост-узла (HIT); идентификатора источника синхронизации (SSRC); индекса параметра защиты (SPI); номеров портов TCP.

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

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

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

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

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

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

Краткое описание чертежей

Фиг.1 схематически иллюстрирует сценарий сетевой связи, включающий в себя прохождение NAT с использованием TURN.

Фиг.2 иллюстрирует сигнализацию регистрации в сетевом сценарии по фиг.1 и связанную с модифицированным протоколом TURN.

Фиг.3 схематически иллюстрирует формат пакета ESP.

Фиг.4 иллюстрирует ретрансляцию пакета в сетевом сценарии по фиг.1.

Фиг.5 схематически иллюстрирует клиент TURN и сервер TURN сетевого сценария по фиг.1.

Фиг.6 - блок-схема последовательности этапов, иллюстрирующая процессы регистрации на сервере TURN и ретрансляции пакета.

Фиг.7 схематически иллюстрирует формат пакета RTP.

Фиг.8 схематически иллюстрирует формат пакета HIP.

Подробное описание изобретения

Проблема прохождения NAT рассмотрена выше в контексте инкапсуляции TURN. Теперь будут описаны усовершенствование в TURN и другие решения прохождения NAT с использованием ретрансляции данных.

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

Когда клиент TURN желает связаться с одноранговым узлом без использования инкапсуляции TURN, он сначала выполняет проверку с помощью сервера TURN, чтобы определить, поддерживает ли или нет сервер TURN механизм HLI, описанный в настоящей заявке. Если поддерживает, тогда клиент TURN регистрирует пару HLI (один идентификатор для входящей связи (входящий идентификатор) и один идентификатор для исходящей связи (исходящий идентификатор)) в сервере TURN. Регистрация HLI на сервере TURN содержит два байтовых массива (один для каждого HLI), а также длину массива, смещение и адрес однорангового узла. Для входящего трафика, когда сервер TURN принимает пакет, направленный в ретранслированный адрес, он проверяет, чтобы понять, соответствуют ли данные пакета зарегистрированному входящему HLI, и если соответствует, он посылает пакет без какой-либо инкапсуляции клиенту TURN, так как входящий HLI будет однозначно идентифицировать адрес однорангового узла для клиента TURN. Когда сервер TURN принимает пакет из клиента TURN, он проверяет, чтобы понять, соответствуют ли данные пакета зарегистрированному исходящему HLI, и, если соответствуют, пакеты посылаются в адрес однорангового узла, который был зарегистрирован для этого исходящего HLI (открытого адреса, назначенного клиенту TURN с помощью NAT, т.е. адрес клиента, преобразованный с помощью NAT, который включен как исходный адрес пакета, принятого в сервере TURN, переключается в ретранслированный адрес в соответствии с обычным поведением TURN).

HLI может быть любым байтовым массивом, значение и местоположение которого известно до того, как данные будут переданы или приняты. Длина массивов и их смещения (т.е. через сколько байтов после заголовка транспортного уровня начинается HLI) могут быть определены при регистрации идентификаторов HLI (клиентом TURN) на сервере TURN. Например, в случае ESP, инкапсулированного в UDP (RFC3948), значение SPI могло бы быть использовано в качестве HLI. Другим примером возможного HLI был бы номер порта TCP, если TCP туннелируется через UDP и ретранслируется через сервер TURN. Идентификатор источника синхронизации транспортного протокола реального времени (RTP) является другим примером HLI.

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

Если данные, ассоциированные с определенным протоколом, должны быть обменены между клиентом TURN и только одним одноранговым узлом, любое постоянное поле в заголовке протокола, который отличается от других одновременно ретранслируемых протоколов, является достаточным. Например, для этой цели мог бы быть достаточным номер версии протокола или значение магического сигнала. Значение “магического сигнала” (в этом контексте) является постоянной величиной в заголовке протокола, которую используют для дифференциации сообщений определенного протокола от сообщений, связанных с другими протоколами в том же потоке. Например, STUN (RFC5389), протокол, используемый TURN и ICE, содержит этот вид идентификатора во всех сообщениях.

Если, с другой стороны, сообщениями, использующими один и тот же протокол, обменивается клиент TURN с множеством одноранговых узлов, требуется идентификатор, который является разным для каждого однорангового узла. Многие протоколы имеют некоторый идентификатор в каждом пакете для источника и/или места назначения данных (например, тэги HIT отправителя и приемника HIP или источника синхронизации RTP). Для других протоколов может быть необходимым генерировать HLI посредством комбинирования информации во множестве полей протоколов.

Обычно клиент TURN неявно знает значение для исходящего HLI, поскольку он является субъектом, инициирующим пакеты и генерирующим сообщения верхнего уровня. Если используется внешний стек протоколов (такой как IPsec, предоставляемый операционной системой) и стек генерирует значение, используемое в качестве HLI, клиенту может потребоваться запросить значение из стека или искать его из посланных пакетов.

Если клиент TURN знает априори значение HLI для однорангового узла (например, это постоянное поле протокола, или определенные одноранговые узлы всегда используют одно и то же значение), не требуется никакая дополнительная сигнализация до регистрации идентификаторов HLI в сервере TURN. Например, в случае трафика сигнализации HIP, хост-узлы знают тэги опознавательного кода хост-узла (HIT), которые будут использованы в заголовке HIP, даже до устанавливания связи друг с другом, поскольку HIT вычисляется из опознавательного кода (идентификационных данных) хост-узла. Следовательно, тэги HIT могут быть использованы в качестве идентификаторов HLI без какой-либо дополнительной сигнализации. Однако, если HLI не известен априори клиенту TURN, клиент TURN должен узнать значение HLI либо из сигнализации протокола, либо автоматически из первого принятого пакета. Конечно, эта сигнализация (при допущении, что она проходит через сервер TURN, а не через некий другой ретранслятор, например сервер SIP или сервер-ретранслятор HIP) или первый пакет данных должны быть TURN-инкапсулированы. В качестве примера, заявители предлагают рассмотреть конфигурирование ассоциации защиты IPsec с использованием IKE (RFC4306) или HIP. Хост-узлы согласуют значение SPI, которое будет вставлено в начало каждого зашифрованного пакета ESP. Таким образом, до того как какие-либо данные будут посланы, клиент TURN узнает значение SPI однорангового узла, которое он может использовать в качестве HLI. Описанные способы не требуют никакой поддержки для HLI или даже для обычного TURN в одноранговом узле. Альтернативный подход, который обязательно требует поддержки HLI в одноранговом узле, включает в себя явный запрос клиентом TURN значения HLI у однорангового узла (например, с использованием новых сообщений STUN/TURN).

Чтобы проиллюстрировать предложенный подход к реализации TURN без обязательного требования инкапсуляции TURN, заявители предлагают рассмотреть случай UDP-инкапсулированного ESP. Фиг.1 схематически иллюстрирует клиент TURN (хост-узел А) 1, который находится за NAT 2. Одноранговый узел, хост-узел В 3 также находится за NAT 4 и желает связаться с хост-узлом А с использованием UDP-инкапсулированного ESP. Это осуществляется с использованием сервера TURN (или ретранслятора) 5. Фиг.1 изображает иллюстративные адреса IP источника (src) и пункта назначения (dst) и номера портов, включенные в пакеты, в разных точках в сети. Фиг.2 иллюстрирует сигнализацию, ассоциированную с этим сценарием. Клиент TURN, который поддерживает расширение HLI, сначала регистрируется в сервере TURN с использованием стандартного запроса назначения TURN (этап 1). Клиент включает параметр HLI-SUPPORTED (HLI поддерживается) в запрос, чтобы проверить, поддерживает ли сервер TURN это расширение. Если сервер поддерживает ретрансляцию HLI, он отвечает сообщением подтверждения назначения (Allocation OK) (этап 2). Однако, если сервер TURN не поддерживает ретрансляцию HLI, он отклоняет запрос, и клиент может либо зарегистрироваться на сервере без расширения, либо проверить некоторый другой сервер TURN. Параметр HLI-SUPPORTED имеет тип “требуемой полноты” (comprehension-required (RFC5389), так что если (устаревший) сервер TURN не распознает его, он отклоняет запрос. Один или оба из хост-узлов на фиг.1 могут быть расположены за множеством NAT. Это не изменяет принципа процесса ретрансляции.

Затем хост-узлы согласуют ассоциации защиты IPsec. С этой целью они могут использовать, например, HIP или IKE. Согласование может быть выполнено либо через сервер TURN, либо с использованием некоторой другой службы ретрансляции, такой как сервер-ретранслятор HIP (id-hip-nat-traversal: см. Basic HIP Extensions for Traversal of Network Address Translators. Draft-ietf-hip-nat-traversal-06 (работа в ходе выполнения). March 2009) или одноранговая оверлейная сеть. Если сервер TURN задействуется в сигнализации IPsec, сообщения сигнализации инкапсулируются с помощью TURN между сервером и клиентом TURN, если идентификаторы HLI не установлены для протокола сигнализации.

Затем клиент TURN запрашивает “разрешения” для однорангового узла и включает входящий и исходящий HLI, которые должны быть проверены относительно всех ретранслированных данных (этап 3). Сервер TURN отвечает с помощью подтверждения разрешения (Permission OK) (этап 4). Разрешения являются частью обычного поведения TURN и повышают безопасность посредством разрешения только одноранговым узлам с зарегистрированным разрешением использовать ретранслированный адрес. Регистрация HLI является вложенной в стандартную процедуру регистрации разрешения. Так как клиент будет использовать UDP-инкапсулированный ESP, он регистрирует значения SPI для однорангового узла (адрес 198.76.28.5:6789) в качестве идентификаторов HLI. В примере по фиг.1 входящий SPI является “0×A1B2C3D4”, а исходящий SPI является “0×B2C3D4E5”. Оба параметра являются четырех байтов длиной и начинаются сразу после заголовка UDP (смещение HLI равно нулю), поскольку SPI всегда находится в первых четырех байтах пакета ESP. В клиенте TURN адрес однорангового узла в ассоциациях безопасности (SA) IPsec устанавливается в адрес сервера TURN, так что стек IPsec посылает пакеты ESP, предназначенные для однорангового узла, в сервер TURN. Фиг.3 иллюстрирует формат пакета ESP.

Фиг.4 иллюстрирует обмен пакетами ESP между клиентом TURN и одноранговым узлом (нижняя последовательность сообщений на фигуре), который не требует инкапсуляции TURN. Когда одноранговый узел посылает пакет, который не соответствует зарегистрированному HLI (в этом примере, нечто, отличное от ESP, например сообщение проверки возможности соединения прохождения NAT или сообщение протокола сигнализации), данные пересылаются клиенту с инкапсуляцией TURN (верхняя последовательность на фиг.4). Клиент может ответить на сообщение инкапсуляцией ответа и сигнализацией адреса однорангового узла в метаданных инкапсуляции. Когда сервер TURN ретранслирует ответ, он удаляет инкапсуляцию TURN. После приема ответа одноранговый узел посылает UDP-инкапсулированные пакеты ESP с SPI, который соответствует зарегистрированному HLI. Сервер TURN обнаруживает соответствие и передает пакеты без какой-либо инкапсуляции. Стек IPsec клиента TURN принимает данные и обрабатывает их соответствующим образом. Когда программа, использующая IPsec, посылает данные обратно в одноранговый узел, стек IPsec автоматически посылает данные (только с инкапсуляцией UDP) в сервер TURN. Сервер TURN обнаруживает, что данные соответствуют зарегистрированному HLI, и пересылает данные в одноранговый узел, адрес которого был зарегистрирован для HLI. Без труда будет понятно, что подавляющее большинство пакетов, обмен которыми осуществляется, не требует инкапсуляции TURN при использовании подхода, описанного в настоящей заявке.

Несмотря на то, что вышеописанный способ использует простые байтовые массивы для сопоставления данных разрешениям, могли бы быть осуществлены более сложные правила пересылки. Например, можно было бы расширить байтовые массивы с помощью битовых масок и позволить проверки битового уровня для мультиплексирования соединений. Также вместо только одного правила пересылки клиент TURN мог бы добавить множество правил, все из которых соответствуют определенному адресу однорангового узла. Даже логические операции, учитывающие множество байтовых/битовых позиций в данных, могли бы быть использованы для выбора правила. Например, это делало бы возможным пересылать все пакеты клиенту TURN без инкапсуляции за исключением пакетов, связанных с проверками возможности соединения прохождения NAT (и для которых необходима информация о реальном адресе отправителя).

Фиг.5 схематически иллюстрирует клиентский терминал 1 (или UE) и сервер 5 TURN, сконфигурированные с возможностью осуществления подхода, описанного выше (с NAT, помещенным между этими двумя субъектами). В UE 1 обеспечен модуль 6 прохождения NAT, ролью которого является регистрировать UE на сервере TURN, для того, чтобы назначать для UE ретранслированный адрес. Модуль 7 определения HLI предусмотрен с возможностью определения соответственных HLI как для входящего, так и исходящего потоков в заданный одноранговый узел. После определения эти HLI передаются в модуль 8 регистрации HLI, который регистрирует идентификаторы HLI на сервере TURN, в связи с адресом однорангового узла. Детали регистрации также передаются в средство 9 управления пакетами, которое использует идентификаторы HLI и адрес однорангового узла, чтобы определить, требуется или нет инкапсуляция для исходящих пакетов, и чтобы правильно маршрутизировать входящие пакеты на верхние уровни.

Фиг.5 иллюстрирует сервер 5 TURN. Он содержит модуль 10 регистрации клиентских терминалов и ассоциированную память 11 для регистрации связей HLI для UE 1. Инспектор 12 входящих пакетов сконфигурирован исследовать пакеты, адресованные в ретранслированный адрес, чтобы идентифицировать зарегистрированный входящий HLI, и пересылать такие пакеты в UE без инкапсуляции TURN. Инспектор 13 исходящих пакетов сконфигурирован идентифицировать зарегистрированный исходящий HLI в пакетах, принятых из UE, и соответственным образом маршрутизировать пакеты в адрес назначения однорангового узла. Конечно, будет понятно, что сервер TURN будет обрабатывать множественные регистрации HLI параллельно для разных UE (а также, возможно, для одного и того же UE).

Фиг.6 - логическая блок-схема, иллюстрирующая основные этапы в процессе обработки пакетов на основе HLI. Процесс начинается на этапе 100, а на этапе 200 UE регистрируется на сервере TURN, чтобы получить ретранслированный адрес. Эта регистрация может происходить до того, как пользователь принимает решение инициировать сеанс. При допущении, что это имеет место, на этапе 300 пользователь инициирует сеанс с одноранговым узлом с помощью UE. Этот этап может быть в ответ на прием сообщения инициирования сеанса из однорангового узла (например, принятого с помощью сервера TURN с использованием инкапсуляции TURN или с помощью некоторого другого сервера-ретранслятора). Затем на этапе 400 UE определяет входящий и исходящий HLI для сеанса и регистрирует их на сервере TURN в связи с адресом однорангового узла на этапе 500. После завершения этого этапа регистрации на этапах 600 и 700 UE и сервер TURN обрабатывают пакеты, как описано, чтобы избежать инкапсуляции TURN между UE и сервером TURN. Этапы 600 и 700 выполняются параллельно.

Следующие подразделы иллюстрируют, как ретрансляция на основе HLI может быть использована с некоторыми примерными протоколами, отличными от ESP. Однако список является неисчерпывающим, и специалист поймет, что описанный подход является применимым к большому числу разных протоколов.

Транспортный протокол реального времени (RTP)

Пакеты RTP (RFC3550: A Transport Protocol for Real-Time Applications. RFC 3550. July 2003) начинаются с фиксированного заголовка, как проиллюстрировано на фиг.7. Поле SSRC, используемое для потока меток из разных источников, содержит случайное число, в отношении которого требуется, чтобы оно было глобально уникальным в сеансе RTP. При использовании RTP с ретрансляцией на основе HLI клиент TURN устанавливает свой исходящий HLI таким образом, чтобы он соответствовал его собственному SSRC, используемому с определенным одноранговым узлом, а его входящий HLI соответствовал SSRC однорангового узла.

Протокол опознавательного кода хост-уза (HIP)

Заголовок пакета HIP (RFC5201: Host Identity Protocol. RFC 5201. April 2008) логически является заголовком расширения IPv6, и его формат изображен на фиг.8. Тэги опознавательного кода хост-узла (HIT) отправителя и приемника идентифицируют осуществляющие связь оконечные точки и, следовательно, являются подходящими для идентификаторов HLI. Клиент TURN, использующий ретрансляцию на основе HLI, устанавливает исходящий HLI таким образом, чтобы им “HIT приемника” сопоставлялся HIT однорангового узла, и входящий HLI таким образом, чтобы им “HIT отправителя” сопоставлялся с HIT однорангового узла.

Номера портов TCP также могут быть использованы в качестве идентификаторов HLI в случае, когда пакеты TCP инкапсулируются в UDP.

Из вышеприведенного обсуждения будет понятно, что ретрансляция на основе HLI удаляет или уменьшает непроизводительные затраты ширины полосы пропускания, обусловленные инкапсуляцией TURN между клиентом и сервером TURN. Также уменьшаются непроизводительные затраты обработки, поскольку нет необходимости добавлять и удалять заголовки инкапсуляции в клиенте и сервере TURN. Кроме того, собственные стеки операционной системы могут быть использованы для обработки ретранслированных данных, вследствие отсутствия требования на инкапсуляцию. Решение является обратносовместимым с существующими клиентами TURN и не требует поддержки HLI из одноранговых узлов.

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

HLI, зарегистрированные на сервере TURN, могут рассматриваться более обобщенно как набор правил. Например, когда в пакетах не присутствует единый уникальный идентификатор, набор правил, такой как “если HLI_1 находится в позиции 1, а HLI_2 в позиции 2, но нет HLI_3 в позиции 3, пакет соответствует правилу/разрешению ретрансляции”, может быть установлен и зарегистрирован на сервере TURN.

Специалисту в данной области техники будет понятно, что различные модификации могут быть сделаны в отношении вышеописанных вариантов осуществления не выходя за рамки объема настоящего изобретения. Например, подход может быть применен к протоколам ретрансляции, отличным от TURN (и которые используют инкапсуляцию ретранслированных пакетов), например SOCKS 5 (IETF RFC 1928), и фактически, например, к дополнительным усовершенствованиям в настоящее время специфицированного протокола TURN. Определенные варианты осуществления позволяют серверу TURN или некоторому другому сетевому узлу определять идентификаторы HLI, используемые для сеанса. В этом случае этот определяющий узел может сигнализировать идентификатор или идентификаторы HLI на клиент TURN, а также на сервер TURN, если узел сам не является сервером TURN. Специалист также поймет, что механизм ретрансляции, описанный в настоящей заявке, является применимым не только к прохождению NAT. Например, он мог бы быть применен к сценарию, в котором клиент использует сервер-ретранслятор, для того, чтобы поддерживать анонимность. Специалист также поймет, что преимущество может быть достигнуто с помощью применения подхода на основе HLI только в одном из входящего и исходящего направлений, а не в обоих.