СПОСОБ ФУНКЦИОНИРОВАНИЯ МУЛЬТИДОМЕННЫХ СЕТЕЙ ETHERNET ПРОВАЙДЕРА Российский патент 2014 года по МПК H04L12/715 H04L12/761 

Перекрестная ссылка на связанные заявки

Это первая заявка, поданная на настоящее изобретение.

Приложение на микрофишах

Не применимо.

Область техники

Настоящее изобретение относится к управлению пересылкой трафика в сетях Ethernet провайдера и, в частности, к способам расширения сетевых услуг виртуальной частной сети (VPN) по мультидоменной сети Ethernet провайдера.

Уровень техники

Сетевые операторы и поставщики услуг в сфере связи развертывают сети связи с пакетной коммутацией вместо сетей с коммутацией каналов связи. В сетях с пакетной коммутацией, таких как сети Интернет-протокола (IP), IP пакеты маршрутизируются в соответствии с состоянием маршрутизации, сохраненным в каждом Ethernet-коммутаторе в сети. В этом документе термины «пакет», «сеть с пакетной коммутацией», «маршрутизация», «кадр» и «основанная на кадрах сеть», «пересылка» и родственные термины предназначены для охвата любых PDU, сетей связи, использующих PDU, селективной передачи PDU из сетевого узла к сетевому узлу.

Пространство современной пакетной сети составлено из множества автономных доменов, каждый из которых управляется независимым объектом сетевого оператора. Для целей понимания настоящего раскрытия «автономный домен» должен пониматься как относящийся к совокупности соединенных сетевых элементов, включая, без ограничения, Ethernet-коммутаторы, под управлением сетевого оператора. В сетях Интернет-протокола (IP) автономные домены упоминаются как «автономные системы» и могут действительно управляться более чем одним объектом. В сетях Ethernet автономный домен может упоминаться как подсеть или просто как сеть. Однако во всех случаях потребители (или абоненты) получают доступ к автономному домену на условиях договора об услугах с сетевым оператором, который управляет конкретным доменом, с которым потребитель желает соединиться. В типовом случае автономный домен соединен с одним или более соседних автономных доменов через одно или более пограничных шлюзовых устройств, что может позволить потребителю обмениваться пакетами с сетевыми адресами вне конкретного домена, с которым потребитель соединен.

При предоставлении услуг, таких как услуга виртуальной частной сети (VPN), потребитель будет иметь два или более узлов сети, которые желательно должны связываться с использованием данного экземпляра сетевой услуги. Например, компания может иметь офисы продаж во множестве местоположений, и ей может быть желательным связать все эти офисы с использованием элемента (экземпляра) Ethernet услуги типа «из множества точек к множеству точек» (известной как ELAN). Если все потребительские узлы расположены в пределах территории, обслуживаемой одиночным автономным доменом, то для сетевого оператора домена является несложным делом предоставить требуемую услугу всем узлам потребителя. Однако часто случается, что потребительские узлы сети географически рассредоточены в такой степени, что они не могут быть непосредственно соединены с тем же самым автономным доменом. Например, компания может иметь офисы продаж во множестве различных стран, и каждый офис продаж будет обязательно соединяться с автономным доменом, который покрывает область, в которой расположен данный офис. В этом случае должны быть обеспечены некоторые средства для расширения желательной услуги (например, ELAN) по всем из участвующих автономных систем.

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

Известные методы решения этих вопросов включают в себя сетевую федерацию и согласование межоператорных соглашений для каждого элемента (экземпляра) услуги. Сетевая федерация является методом, в котором сетевые операторы, управляющие одним или несколькими автономными доменами, соглашаются унифицировать некоторые аспекты своей сетевой ОАМ функциональности. Например, распределение пакетных маркировок экземплярам сетевых услуг может быть координировано в единую схему администрирования между доменами, так что VPN трафик может надежно распознаваться и обрабатываться в каждой из федеративных сетей (или доменов). Межоператорные соглашения могут быть использованы, например, для обеспечения равномерного распределения ширины полосы конкретным экземплярам услуг по множеству доменов и согласования оплаты по счетам между участвующими операторами. Когда число доменов в федерации и/или число потребителей, которые требуют услуг, которые охватывают множество доменов, ограничено, эти соглашения в общем случае удовлетворительны. Однако успешная федерация автономных доменов становится все более сложной, по мере того как число доменов-участников возрастает. Аналогичным образом, согласование межоператорных соглашений для каждого экземпляра услуги и последующая координация обеспечения и биллинга становятся все более сложными и обременительными, по мере того как число потребителей, требующих мультидоменных услуг, и число участвующих доменов увеличивается.

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

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

Таким образом, один аспект настоящего изобретения предусматривает способ обеспечения расширения сетевой услуги первого домена к удаленному сетевому узлу потребителя, которому предоставляются услуги через шлюз-хост доступа (AG) в Ethernet домене провайдера. В первом домене удаленный узел потребителя представлен как поддерживаемый пограничным шлюзом (BG), соединенным с Ethernet доменом провайдера, так что абонентские пакеты, ассоциированные с сетевой услугой, пересылаются к или от удаленного узла потребителя через BG. В Ethernet домене провайдера магистральное соединение реализуется через Ethernet домен провайдера между AG-хостом и BG. Функция магистрального перекрестного соединения инсталлируется в AG-хосте для переноса абонентских пакетов, ассоциированных с сетевой услугой, между соответствующим виртуальным каналом присоединения (AVC), через который удаленный узел потребителя соединен с AG-хостом, и расширенным AVC, туннелированным через магистральное соединение. Общий идентификатор элемента услуги (I-SID) используется для идентификации как AVC между AG-хостом и удаленным узлом потребителя, так и расширенного AVC между AG-хостом и BG.

При такой конфигурации, первый автономный домен работает как «домашний» домен элемента сетевой услуги и управляет пересылкой трафика, относящейся к элементу сетевой услуги, согласно процедурам конкретного типа сетевой услуги. Таким образом, например, для элемента ELAN услуги Ethernet пакеты потребителя будут пересылаться через первый домен на основе поля МАС адреса места назначения потребителя в пакете, в то время как потребительские пакеты IP VPN услуги будут пересылаться через первый домен согласно IP адресу места назначения потребителя. Аналогичным образом, сетевой оператор первого домена берет на себя ответственность за ОАМ услуги, а также связанные с услугой взаимодействия с потребителем. Второй домен обеспечивает услугу простого агрегирования и организации магистральной сети для первого домена, так что абонентский трафик к или от удаленных сетевых узлов потребителей, которые расположены во втором домене, могут туннелироваться прозрачным образом через второй домен, не требуя от второго домена знать о типах или элементах сетевых услуг, с которыми связан трафик. В то же время сетевой оператор второго домена может просто контролировать трафик в магистральных соединениях (например, путем обеспечения точки вынужденного выполнения политики (PEP) в BG второго домена) как для целей вынужденного выполнения политики, так и для целей биллинга.

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

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

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

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

Фиг.2 - блок-схема, схематично иллюстрирующая осуществление элемента расширенной сетевой услуги в сети по фиг.1 в соответствии с вариантом осуществления настоящего изобретения.

Фиг.3 схематично иллюстрирует репрезентативную функцию магистрального перекрестного соединения, используемого в элементе расширенной сетевой услуги по фиг.2 и

Фиг.4 - диаграмма последовательности сообщений, иллюстрирующая процесс аутентификации и авторизации, используемый в элементе расширенной сетевой услуги по фиг.2.

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

Детальное описание предпочтительных вариантов осуществления

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

Для простоты описания способы в соответствии с настоящим изобретением будут описаны здесь со ссылкой на характерный вариант осуществления, развернутый в домене сети Ethernet провайдера, таком как, например, любая из сетевых сред PLSB (Сопряжение Состояний Каналов Провайдера), PBT (Магистральный Транспорт Провайдера), PBB-TE (Сопряжение Магистралей Провайдера-Разработка Трафика), PBB (Сопряжение Магистралей Провайдера). Однако в то время как домен, указанный ниже в качестве чужого домена, требуется для поддержки технологий сети Ethernet провайдера, должно быть понятно, что настоящее изобретение никоим образом не ограничено такими сетевыми технологиями для домена, предоставляющего сетевую услугу. Вместо этого, специалисты в данной области техники без труда смогут применить предложенное решение в других сетевых средах, и все такие реализации рассматриваются как входящие в предусматриваемый объем приложенной формулы изобретения.

На фиг.1 показана мультидоменная сеть 2, в которой смежные домены 4а-b соединены через пограничные шлюзы (BG) 6. В пределах каждого автономного домена (AD) 4 предусмотрен набор одного или более шлюзов доступа (AG) 8, для поддержки узлов 10 потребителей, так что пользователи на каждом узле могут получить доступ к услугам сети. В типовом случае, соответствующий BG 6 будет предоставляться каждым автономным доменом (AD) 4 и взаимно соединяться посредством меж-BG канала 12. В некоторых вариантах осуществления меж-BG канал 12 может быть магистральным каналом с множеством ретрансляционных участков (который может пересекать третью сеть (не показана)), способным транспортировать Ethernet пакеты BG. В сетевой среде РВТ меж-BG канал 12 будет обычно представлять собой РВТ-магистраль, известную в технике. Альтернативно, меж-BG канал может быть определен как РВВ поток между источником и местом назначения по сети Ethernet канала или магистральных мостов провайдера, что также известно технике. При этих конфигурациях, каждый BG будет пересылать по меж-BG каналу 12 инкапсулированный Ethernet трафик провайдера, предназначенный для другого автономного домена, когда адрес места назначения магистрали (B-DA) Ethernet пакета провайдера является МАС адресом другого BG или другого узла, с которым сопрягается этот BG.

В сетевой среде PLSB, РВТ или РВВ, как AG 8, так и BG 6 могут быть краевыми мостами Ethernet магистрали (ВЕВ) провайдера и различаться главным образом по их соответствующим функциям.

В типовом случае узел 10 потребителя соединен с сетью через канал присоединения между оборудованием потребителя (например, маршрутизатором или сервером в помещении потребителя) и AG 8, выбранным сетевым оператором. Для конкретного типа сети AG также известен как РЕ (Граница Провайдера), Граница Услуги, BRAS (Сервер Широкополосного Удаленного Доступа) или другое наименование, специфическое для типа сети. Это сетевой элемент, который обеспечивает межсетевое взаимодействие между инвариантной услугой подсетью доступа (или присоединения) и осведомленной об услуге базовой сетью домена. В некоторых случаях канал присоединения предусмотрен как физический канал 14 (например, проводной, оптико-волоконный или стационарный беспроводный) между оборудованием потребителя и AG 8. В других случаях оборудование потребителя физически соединено с мультиплексором агрегирования (АМ) 16, который соединен с AG 8 посредством магистрального соединения 18 доступа. В этом случае соединение между оборудованием потребителя и AG 8 является виртуальным каналом через мультиплексор агрегирования 16 и может называться виртуальным каналом присоединения (AVC). Для целей настоящего раскрытия каналы присоединения и виртуальные каналы присоединения (AVC) рассматриваются как эквивалентные, и эти термины используются взаимозаменяемым образом. В среде Ethernet сети провайдера магистральное соединение 18 доступа между мультиплексором агрегирования (АМ) 16 и шлюзом доступа (AG) 8 может быть РВТ магистралью или может быть РВВ инкапсулированными Ethernet-потоками.

В типовом случае сетевой оператор будет назначать идентификатор каждому узлу потребителя, и этот идентификатор будет обычно ассоциироваться с каналом доступа между этим узлом потребителя и его AG-хостом 8, так чтобы однозначно определенно идентифицировать трафик к и от узла потребителя. В случае среды Ethernet сети провайдера этот идентификатор может быть идентификатором элемента (экземпляра) услуги (I-SID). I-SID может также идентифицировать элемент сетевой услуги, установленный сетевым оператором по условиям его договора с потребителем. Для целей настоящего раскрытия, полная совокупность идентификатора VLAN Ethernet магистрали провайдера (B-VID), адрес источника магистрали (B-SA), адрес места назначения магистрали (B-DA) и I-SID, которые инкапсулируют пакеты потребителя, когда они транспортируются по AVC, определяют порт виртуального пользовательского сетевого интерфейса (UNI) потребителя на AG. При такой конфигурации, AG 8, поддерживающий данный узел потребителя, может использовать I-SID, назначенный AVC этого узла, чтобы отображать трафик, поступающий на виртуальный UNI порт, на элемент сетевой услуги потребителя и чтобы определять B-VID, B-SA и B-DA магистрального соединения доступа, через которое AVC туннелируется, когда пакеты должны передаваться на узел потребителя. Отметим, что в обычных сетевых средах элемент сетевой услуги, установленный для потребителя, будет ограничен соответствующим доменом, управляемым сетевым оператором. Этот элемент услуги и ассоциированные с ним потоки трафика обычно не будут распознаваться в других доменах, помимо федерации или на условиях соответствующего договора, согласованного сетевыми операторами, взаимодействие которых требуется для доставки услуги потребителю.

Методы, соответствующие настоящему изобретению, позволяют элемент услуги (такой, как виртуальная частная сеть VPN), реализованный в первом домене, расширить на узлы удаленных пользователей в домене Ethernet провайдера.

Согласно фиг.2, сетевая услуга реализована в первом автономном домене (AD1) 4a, а узел 10r потребителя в смежном автономном домене (AD2) 4b желает соединиться с этим элементом сетевой услуги. Для удобства описания первый автономный домен (AD1) 4a обозначен как «домашний» домен для сетевой услуги, а второй домен (AD2) 4b обозначен как «чужой» домен. В показанном примере оба домена 4a-b являются доменами сети Ethernet провайдера, для простоты описания. Однако хотя чужой домен должен поддерживать методы Ethernet провайдера, это ограничение не применимо к домашнему домену. Выбор домашнего домена может быть основан на любых желательных критериях. Например, сеть оператора, который принимает запрос на предоставление элемента сетевой услуги от потребителя, может предусматривать функцию домашнего домена.

В любом данном домене, узлы потребителей, серверы, магистральные соединения и т.п. рассматриваются как «локальные» для этого домена, в то время как эти элементы в пределах другого домена, рассматриваются как «удаленные».

Сетевой оператор домашнего домена предусматривает обращенные на потребителя функции взаимодействия с потребителем для согласования договоров на услуги, аутентификации пользователей, выставления счетов, технической поддержки и администрирования и управления операциями (ОАМ) элемента услуги. В дополнение, домашний домен предусматривает выполнение специфической для типа сетевой услуги (основанной на адресе) пересылки пакетов, ассоциированных с элементом сетевой услуги. Таким образом, сетевая услуга для потребителя реализуется как элемент (экземпляр) сетевой услуги в домашнем домене, и состояние устанавливается в домашнем домене, чтобы облегчить пересылку пакетов потребителя, ассоциированных с элементом сетевой услуги. Сетевой оператор домашней сети обычно также будет назначать один или более серверов 24 аутентификации для обработки процедур входа в систему и аутентификации узла потребителя, чтобы обеспечить безопасный доступ потребителя к элементу сетевой услуги. Сервер 24 аутентификации может также работать как мультиплексор присоединения (АМ) или как шлюз доступа (AG), поддерживающий один или более локальных узлов потребителей (не показаны на фиг.2) в домашнем домене 4а, но это не является существенным.

Для обеспечения возможности удаленному узлу 10r потребителя соединиться с элементом сетевой услуги потребителя в домашнем домене 4а, удаленный узел 10r потребителя представлен в домашнем домене 4а как поддерживаемый локальным BG 6а. При такой конфигурации удаленный узел 10r потребителя может зарегистрироваться на сервере 24 аутентификации, и абонентские пакеты, ассоциированные с элементом сетевой услуги, будут пересылаться через домашний домен 4а к и от удаленного узла 10r потребителя, как если бы удаленный узел 10r потребителя фактически был локальным узлом потребителя, соединенным с домашним доменом. Это является выгодным, так как это позволяет домашнему домену нести ответственность за пересылку на основе адреса абонентских пакетов элемента услуги, включая абонентские пакеты элемента услуги, маршрутизируемые к и от удаленного узла 10r потребителя, и никакого изменения в протоколе пересылки трафика домашнего домена не требуется, чтобы гарантировать надлежащую пересылку абонентских пакетов элемента услуги через чужой домен 4b.

В случае среды сети Ethernet провайдера, представление удаленного узла 10r потребителя в домашнем домене 4а как поддерживаемого локальным BG 6а может быть реализовано путем представления удаленного узла 10r потребителя как виртуального UNI порта меж-BG канала 12 на BG 6а. В показанном варианте осуществления это выполняется путем расширения AVC 19, соединяющего удаленный узел 10r потребителя с его AG-хостом 8, к BG 6а домашнего домена, который затем выполняет функции интерфейса к элементу сетевой услуги домашнего домена так же, как AG сопрягает не расширенное AVC с локальным элементом сетевой услуги. В этой конфигурации домашний домен 4а может управлять пересылкой на основе адреса всего абонентского трафика, ассоциированного с элементом услуги, обычным образом, как если бы удаленный узел 10r потребителя располагался в домашнем домене 4а.

В этом отношении, следует отметить, что в сетевых средах, в которых как меж-BG канал 12, так и магистральное соединение 18 доступа между AG 8 и АМ 16, способны транспортировать любую одну или более из магистралей PBB, PBT или PLSB, для BG 6а домашнего домена является возможным обрабатывать AVC, расширенное посредством меж-BG канала 12, способом, аналогичным способу, которым AG 8 обрабатывает AVC, расширенное посредством магистрального соединения 18 доступа к АМ 16. В таком случае для чужого домена требуется только расширить AVC через меж-BG канал 12. Это выполняется путем туннелирования AVC через магистральное соединение 20, установленное между AG 8, поддерживающим удаленный узел 10r, и BG 6а домашней сети, и путем реализации функции магистрального перекрестного соединения в AG 8 чужого домена, где функция перекрестного соединения переносит все пакеты, поступающие по регулярному AVC, туннелируемому по магистрали 19, к расширенному AVC, туннелируемому по магистральному соединению 20, и наоборот. Следует отметить, что магистральное соединение проходит через BG 6b чужого домена и, таким образом, расширенное AVC также маршрутизируется через BG чужого домена.

Предпочтительно магистральное соединение 20 между BG 6а домашнего домена и AG 8, поддерживающим удаленный узел 10r, устанавливается согласно договору об услуге, согласованному между соответствующими сетевыми операторами домашнего и чужого доменов. Например, участвующие сетевые операторы могут согласовывать договор, в котором сетевой оператор чужого домена соглашается поддерживать расширенные сетевые услуги, реализованные в домашнем домене. В типовом случае такой договор должен включать в себя политики, управляющие уровнем услуги (например, гарантии по качеству услуг, ограничения использования и т.д.), согласованием платежей и т.д. Предпочтительно такое соглашение не будет связываться с любым данным элементом сетевой услуги или пакетом элементов услуг, но должен определять набор глобальных параметров, в рамках которых доступ в чужом домене к элементам сетевых услуг домашнего домена мог бы быть установлен «на лету». Соответственно, как только договор согласован между соответствующими сетевыми операторами, и меж-BG канал назначен, сетевой оператор чужого домена может установить магистральное соединение 20 между каждым из AG в чужом домене 4b, который может, согласно договору, поддерживать удаленные узлы потребителей, и домашним BG 6а. В варианте осуществления, где чужой домен является сетью Ethernet провайдера, меж-BG канал может транспортировать Ethernet пакеты, и домашний BG является некоторой формой граничного моста Ethernet магистрали провайдера, эти магистрали определяются В-МАС адресами AG 8 и домашнего BG 6а и согласованным B-VID. В РВТ среде эти магистральные каналы 20 могут быть конфигурированы, чтобы удовлетворять условиям согласованного договора с домашним доменом, и таким образом могут поддерживаться независимо от любого данного расширенного типа или элемента сетевой услуги. Кроме того, точка вынужденного выполнения политики (РЕР) 22 может быть инсталлирована в чужом домене BG 6b, чтобы контролировать трафик потребителя по индивидуальным магистралям и/или агрегированный поток по меж-BG каналу и тем самым гарантировать соответствие с согласованным договором.

Использование Ethernet-ориентированных магистралей провайдера является выгодным в том, что виртуальный канал присоединения, поддерживающий данный удаленный узел 10r потребителя, может быть расширен через PLSB, PBT или PBB магистраль между AG-хостом 8 и BG 6а домашнего домена и сохранять тот же I-SID как в части доступа, так и в расширенной части. Как для соединения 18 доступа между AG-хостом 8 и АМ 16, I-SID, назначенный этому расширенному AVC, уникально идентифицирует трафик потребителя к и от удаленного узла 10r потребителя и, таким образом, может использоваться, чтобы гарантировать корректное отображение пакетов потребителя на конкретный элемент сетевой услуги потребителя в домашнем BG 6а.

В примере по фиг.2 удаленный узел 10r потребителя соединен со своим AG-хостом 8 через виртуальный канал доступа (AVC), который пересекает мультиплексор агрегирования (АМ) 16. В показанном примере AVC пересекает уникальный физический канал 14 между удаленным узлом 10r потребителя и АМ 16, и туннелируется через магистральное соединение 18 доступа между АМ 16 и AG-хостом 8. В сценарии, где магистралью доступа является РВВ или РВТ магистраль, целесообразно реализовать функцию магистрального перекрестного соединения в AG-хосте 8, как описано ниже.

В среде Ethernet провайдера абонентский трафик к и от удаленного узла 10r потребителя инкапсулирован с B-VID, B-DA и B-SA магистрального соединения 18 доступа между AG 8 и АМ 16 и уникально идентифицируется посредством I-SID, назначенного AVC. В AG-хосте 8, чтобы расширить AVC через РВТ магистраль к BG 6b, каждый входящий пакет AVC имеет свои поля B-VID, B-DA и B-SA, которые определяют магистральное соединение доступа, замененные полями B-VID, B-DA и B-SA, которые определяют магистраль 20, при сохранении поля I-SID неизменным. Значения полей замены, предварительно сохраненные в памяти AG 8, извлекаются с использованием значения I-SID в качестве индекса и записываются в пакет, согласно любому из многих методов, хорошо известных в технике. Затем AG 8 пересылает пакет согласно его локальному состоянию для нового B-VID и B-DA. В примере, показанном на фиг.3, магистраль 19 доступа определена некоторым значением “b” B-VID и полями B-DA и B-SA, содержащими В-МАС адрес АМ 16 и AG 8. Пакеты, поступающие в AG 8 от АМ 16, будут иметь поле B-SA, установленное в В-МАС адрес АМ 16, и B-DA, установленное в В-МАС адрес AG 8, а для пакетов, поступающих к АМ 16 от AG 8, значения для полей B-DA и B-SA являются обратными. Также в примере по фиг.3 магистраль 20 между AG 8 и домашним BG 6а является магистралью, определенной некоторым другим значением “а” B-VID и полями B-DA и B-SA, содержащими В-МАС адрес домашнего BG 6а и AG 8. Пакеты, поступающие в AG 8 из домашнего BG 6а, будут иметь поле B-SA, установленное в В-МАС адрес домашнего BG 6а, и B-DA, установленное в В-МАС адрес AG 8, а для пакетов, поступающих к домашнему BG 6а от AG 8, значения для полей B-DA и B-SA являются обратными. Соответственно, функция магистрального перекрестного соединения, реализованная в AG-хосте 8, использует I-SID входящего пакета, чтобы идентифицировать абонентский трафик в расширенном AVC, и затем заменяет поля B-VID, B-DA и B-SA во входящей магистрали на поля B-VID, B-DA и B-SA другой магистрали. Для трафика, поступающего от удаленного узла 10r потребителя к домашнему BG 6а, значение “b” B-VID заменяется на “a”, AG В-МАС адрес смещается из поля B-DA в поле B-SA, а в поле B-DA указывается В-МАС адрес BG 6а. Для поддержания непрерывности AVC, функция магистрального перекрестного соединения, реализованная в AG-хосте 8, не изменяет I-SID.

Как отмечено выше, AG и BG являются экземплярами граничных мостов магистрали (ВЕВ), при этом главное различие заключается в их соответствующих функциях. Как таковой, для целей обработки абонентского трафика расширенных сетевых услуг, домашний домен BG 6а может эмулировать AG и обрабатывать магистраль 20, как если бы она была магистральным соединением 18 доступа к мультиплексору агрегирования (АМ), поддерживающему удаленный узел 10r потребителя. BG 6а домашнего домена может также использовать обычные методы, чтобы сообщать адрес потребителя (С-МАС) или адреса удаленного узла 10r потребителя домашнему домену 4а, как это соответствует типу сетевой услуги, на которую подписался узел потребителя. В домашнем домене 4а удаленный узел 10r потребителя будет поэтому представляться как виртуальный UNI порт по отношению к BG 6а домашнего домена (эмулирующего AG), и обычные методы пересылки трафика могут быть использованы для пересылки абонентского трафика расширенного элемента услуги к или от BG 6а домашнего домена от имени удаленного узла 10r потребителя.

В пределах домашнего домена 4а абонентский трафик расширенного элемента услуги уникально идентифицируется посредством I-SID, назначенного элементу услуги оператором домашнего домена. BG 6а домашнего домена может поэтому идентифицировать абонентский трафик расширенного элемента услуги, который предназначен для удаленного узла 10r потребителя, из I-SID и в зависимости от сетевой услуги, С-МАС, соответственно, принятых пакетов. Эти пакеты могут затем надлежащим образом пересылаться через чужой домен 4b к удаленному узлу 10r потребителя путем замены I-SID соответствующим идентификатором расширенного AVC и инкапсулирования с B-VID, B-DA и B-SA магистрали 20 к AG 8. Наоборот, пакеты из удаленного узла 10r потребителя идентифицируются посредством I-SID расширенного AVC и инкапсулируются с B-VID, B-DA и B-SA магистрали 20, как описано выше. Таким образом, BG 6а домашнего домена может обеспечивать надлежащую пересылку этих пакетов в домашний домен путем распаковки пакетов и замены I-SID AVC идентификатором, назначенным элементу услуги, и пересылки пакетов согласно правилам и локальному состоянию элемента сетевой услуги.

Фиг.4 схематично иллюстрирует характерный поток сообщений, который может использоваться для соединения удаленного узла 10r потребителя с расширенной сетевой услугой в примере по фиг.2. Согласно фиг.4, удаленный узел 10r потребителя инициирует запрос на авторизацию использования сети обычным способом, типичным для Ethernet связности. Таким образом, например, может быть послано сообщение запроса регистрации от удаленного узла 10r потребителя к мультиплексору присоединения (АМ) 16, который действует, в терминологии стандарта 802.1Х (также известного как Расширяемый Протокол Аутентификации в Ethernet - ЕАРоЕ), как аутентификатор, чтобы запрашивать идентификатор потребителя и транслировать идентификатор потребителя на сервер аутентификации с использованием протокола сигнализации, такого как RADIUS или DIAMETER в соответствии с процедурами Расширяемого Протокола Аутентификации (EAP). В соответствии с ЕАР процедурами, АМ 16 затем транслирует сообщения обмена аутентификации между сервером аутентификации и потребителем 10r. При нормальных обстоятельствах АМ 16 будет конфигурироваться, чтобы использовать локальный сервер аутентификации (например), поддерживаемый на AG 8, и после успешного завершения процедур регистрации и аутентификации, узел потребителя сможет осуществлять связь через домен сети, к которому он был присоединен, в соответствии с договором потребителя с сетевым оператором домена.

В некоторых вариантах осуществления процедуры регистрации и аутентификации, реализованные в локальном сервере аутентификации, конфигурируются, чтобы распознать, когда узлу потребителя желательно соединиться с сетевой услугой, реализованной в другом домене сети, а не с локальной сетевой услугой, реализованной в локальном домене. Одним методом для выполнения этого является включение имени для домашнего домена как части исходного сообщения запроса на регистрацию. Например, последовательность исходного сообщения запроса на регистрацию может доставлять на локальный сервер аутентификации идентификатор клиента “MyID” в форме “clientID.servicename@homedomain”. Такой идентификатор клиента может затем анализироваться локальным сервером аутентификации для выделения имени домашнего домена, чтобы: идентифицировать, что клиент пытается соединиться с сетевой услугой, реализованной в другом домене; позволить локальному домену распознать свою функцию в коммуникации (т.е. что он является чужим доменом и поэтому должен туннелировать трафик потребителя к другому домену); и определить BG адрес, по которому можно достичь сервер аутентификации, предназначенный для обработки аутентификации клиента и регистрации на элемент сетевой услуги. В варианте осуществления по фиг.2 и 4 локальный сервер аутентификации размещается на AG 8 и имя “homedomain” является именем, которое отображается посредством конфигурации на локальном сервере аутентификации на безопасное соединение с BG 6b, который соединен с домашним доменом 4а. BG 6b, в свою очередь, конфигурируется для ретрансляции сообщений обмена аутентификации со своим одноранговым BG 6а в домашнем домене 4а, который, в свою очередь, способен ретранслировать их на сервер аутентификации в домашнем домене 4а.

Таким образом, в варианте осуществления по фиг.4 сообщение запроса аутентификации и авторизации (АА) пересылается от локального аутентификатора (в данном случае АМ 16, обслуживающего удаленный узел 10r потребителя) к «домашнему» серверу 24 аутентификации (например, идентифицированному посредством “servicename@homedomain”. В показанном варианте осуществления сообщение запроса АА содержит, в качестве параметра, значение I-SID, выбранное посредством АМ для назначения создаваемому AVC.

После приема сообщения запроса, BG 6а домашнего домена пересылает сообщение запроса через домашний домен 4а к «домашнему» серверу 24 аутентификации и инсталлирует функцию «ретрансляции» для облегчения двустороннего обмена сообщениями аутентификации и управления между домашним сервером 24 аутентификации и удаленным узлом 10r потребителя.

После успешного завершения процедур аутентификации и авторизации на домашнем сервере 24 аутентификации, сообщение ответа пересылается от домашнего сервера 24 аутентификации назад к удаленному узлу 10r потребителя и транслируется через BG 6а домашнего домена, BG 6b чужого домена и AG-хост 8. В варианте осуществления по фиг.4 это ответное сообщение содержит I-SID, назначенный элементу сетевой услуги в домашнем домене 4а, а также информацию управления трафиком (такую как идентификация договора на услугу, требования по ширине полосы и т.д.), так что чужой домен 4b может выделить соответствующие ресурсы для расширенного AVC. Когда BG 6a домашнего домена принимает сообщение ответа, он завершает присоединение расширенного AVC как виртуального UNI порта к авторизованному элементу сетевой услуги, чтобы обеспечить возможность надлежащей пересылки абонентского трафика к или от удаленного узла 10r потребителя.

Когда BG 6b чужого домена принимает ответное сообщение, присоединенная точка вынужденного выполнения политики (РЕР) 22 может использовать информацию управления трафиком для определения соответствия с договором на услугу между участвующими сетевыми операторами, и установить механизмы мониторинга трафика и сбора данных измерений по расчетам для AVC, определенного вновь назначенным I-SID, как это желательно. Если информация управления трафиком соответствует с договором на услугу между операторами, то BG 6b чужого домена затем пересылает ответное сообщение к AG-хосту 8. Когда AG-хост 8 принимает ответное сообщение, он может инсталлировать свою функцию магистрального перекрестного соединения, как описано выше, и переслать ответное сообщение к АМ 16. Это дает АМ информацию, необходимую для расширения канала 14 присоединения в качестве AVC 18 к AG. Отметим, что в этом варианте осуществления АМ не осведомлен о том, что AVC не будет завершаться на AG, как это было бы, если запрашивался элемент локальной сетевой услуги. Как только этот процесс завершен, сообщение «успешно» может быть послано к удаленному узлу 10r потребителя, чтобы указать на успешное соединение с элементом расширенной сетевой услуги.

Как можно понять, если РЕР 22 определяет, что информация управления трафиком не соответствует договору на услугу, то РЕР 22 может отказать в разрешении на расширение сетевой услуги для удаленного узла 10r потребителя. В таком сценарии соответствующие сообщения (не показано) могут быть посланы к домашнему серверу 24 аутентификации и/или удаленному узлу 10r потребителя.

Следует отметить, что в среде Ethernet провайдера каждый реализованный элемент (экземпляр) сетевой услуги имеет отличительное значение I-SID, назначенное ему. Эта метка I-SID переносится на всех пакетах, принадлежащих конкретному элементу сетевой услуги, которые транспортируются между ВЕВ. Однако I-SID AVC, которое соединяет конкретный узел потребителя с ВЕВ, не обязательно должен иметь то же самое значение, которое назначено элементу сетевой услуги, присоединенному к нему. В варианте осуществления, описанном выше со ссылкой на фиг.2 и 4, различные I-SID могут быть использованы в домашнем домене в реализации элемента сетевой услуги и чужом домене в реализации расширенного AVC. Например, сетевой услуге, реализованной в домашнем домене, обычно будет назначен I-SID, который используется для облегчения пересылки трафика в домашнем домене. В чужом домене соответствующий I-SID, назначенный каждому AVC, используется для облегчения надлежащего туннелирования абонентского трафика через магистральные соединения 20 между BG 6b чужого домена и каждым участвующим AG-хостом.

Это ожидается как общий сценарий, поскольку автономные домены будут обычно назначать I-SID независимо друг от друга. Смена I-SID как части виртуального UNI порта на функцию отображения для пересылки элемента услуги на BG 6а домашнего домена также облегчает надлежащую пересылку трафика в случаях, когда имеется два или более удаленных узлов потребителей в чужом домене 4b, поддерживаемых вне одного AG, поскольку надлежащая пересылка трафика посредством функции магистрального перекрестного соединения AG, поддерживающих удаленные узлы потребителей, может быть гарантирована использованием соответствующих I-SID, назначенных AVC этих узлов.

В некоторых вариантах осуществления будет желательно использовать тот же самый I-SID для ссылки на элемент сетевой услуги в обоих доменах. Первым примером такого варианта осуществления является услуга двухточечного соединения между одним узлом потребителя в домашнем домене 4а и одним удаленным узлом 10r потребителя в чужом домене 4b. Как можно понять, в подобных вариантах осуществления функция замены I-SID в домашнем BG 6b, описанная выше, не требуется, так как нет необходимости изменять I-SID абонентского трафика, пересекающего BG 6а домашнего домена. С другой стороны, необходимо согласовать общий I-SID, который может использоваться в обоих доменах.

Различные методы могут использоваться для данной цели. Например, участвующие сетевые операторы могут согласованным образом определить набор I-SID, которые должны использоваться только для идентификации расширенных сетевых услуг. Этот набор зарезервированных I-SID может, например, быть согласован как часть вышеупомянутого договора на услугу между двумя сетевыми операторами. В таком сценарии I-SID, назначенный элементу услуги домашним доменом, будет выбираться из списка зарезервированных I-SID. Понятно, что в таком варианте осуществления нет необходимости во включении I-SID, назначенного АМ, в сообщение запроса АА, как показано на фиг.4. Предпочтительнее, путем включения назначенного домашним доменом I-SID в ответное сообщение, направляемое назад к AG-хосту 8 в чужом домене 4b (смотрите фиг.4), BG 6b чужого домена, AG-хост 8 и АМ 16 могут обновить свои соответствующие таблицы маршрутизации, чтобы использовать зарезервированный I-SID элемента услуги.

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

Варианты осуществления изобретения, описанные выше, являются только иллюстративными. Поэтому объем изобретения ограничивается только объемом прилагаемой формулы изобретения.

Изобретение относится к сетям связи с пакетной коммутацией. Техническим результатом является предоставление мультидоменных услуг удаленным потребителям. Способ обеспечения расширения сетевой услуги первого домена к удаленному узлу потребителя, поддерживаемому шлюзом доступа (AG) в Ethernet домене провайдера. В первом домене удаленный узел представляется как поддерживаемый пограничным шлюзом (BG), соединенным с Ethernet доменом провайдера, так что абонентские пакеты, ассоциированные с сетевой услугой, пересылаются к или от удаленного узла потребителя через BG. В Ethernet домене провайдера магистральное соединение реализуется через Ethernet домен провайдера между AG-хостом и BG. 11 з.п. ф-лы, 4 ил.

1. Способ обеспечения расширения сетевой услуги первого домена к удаленному узлу потребителя в сети, содержащей первый автономный домен, соединенный с Ethernet доменом провайдера через, по меньшей мере, один пограничный шлюз (BG) в первом автономном домене, по меньшей мере, второй домен, содержащий шлюз доступа (AG) для поддержки удаленного узла потребителя во втором домене, причем способ содержит:
в первом домене представление удаленного узла потребителя как поддерживаемого BG, так что абонентские пакеты, ассоциированные с сетевой услугой, пересылаются к или от удаленного узла потребителя через BG;
в Ethernet домене провайдера:
реализацию магистрального соединения через Ethernet домен провайдера между AG-хостом и BG; и
инсталлирование функции магистрального перекрестного соединения в AG-хосте, причем функция магистрального перекрестного соединения переносит абонентские пакеты, ассоциированные с сетевой услугой, между соответствующим виртуальным каналом присоединения (AVC), через который удаленный узел потребителя соединен с AG-хостом, и расширенным AVC, туннелированным через магистральное соединение;
при этом общий идентификатор элемента услуги (I-SID) используется для идентификации как AVC между AG-хостом и удаленным узлом потребителя, так и расширенного AVC между AG-хостом и BG.

2. Способ по п.1, в котором магистральное соединение реализуется между AG и BG независимо от сетевой услуги.

3. Способ по п.1, в котором функция магистрального перекрестного соединения инсталлируется в AG-хосте в течение процесса соединения удаленного узла потребителя с сетевой услугой.

4. Способ по п.1, в котором
для абонентских пакетов, принимаемых от удаленного узла потребителя, функция магистрального перекрестного соединения использует общий I-SID для замены информации заголовка, идентифицирующей AVC, соответствующей информацией заголовка, идентифицирующей, по меньшей мере, одно магистральное соединение; и
для абонентских пакетов, принимаемых от BG первого домена, функция магистрального перекрестного соединения использует общий I-SID для замены информации заголовка, идентифицирующей магистральное соединение, соответствующей информацией заголовка, идентифицирующей AVC.

5. Способ по п.4, в котором второй домен является доменом магистральной транспортной сети (РВТ) провайдера, а информация, идентифицирующая, по меньшей мере, одно магистральное соединение, содержит адрес источника канала-носителя (B-SA), адрес места назначения канала-носителя (B-DA) и VLAN ID канала-носителя (B-VID), назначенные магистральному соединению во втором домене.

6. Способ по п.1, в котором общий I-SID назначен AVC во втором домене.

7. Способ по п.6, в котором общий I-SID отличается от соответствующего идентификатора элемента услуги, назначенного сетевой услуге в первом домене.

8. Способ по п.7, дополнительно содержащий инсталлирование функции отображения I-SID в BG, причем функция отображения I-SID управляет BG таким образом, что
пакеты, ассоциированные с сетевой услугой и предназначенные для удаленного узла потребителя, инкапсулируются с I-SID AVC; и
пакеты, ассоциированные с сетевой услугой и принимаемые от удаленного узла потребителя, пересылаются с соответствующим идентификатором элемента услуги, назначенным сетевой услуге.

9. Способ по п.6, в котором общий I-SID является тем же самым, что и соответствующий идентификатор элемента услуги, назначенный сетевой услуге в первом домене.

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

11. Способ по п.10, в котором предварительно определенный набор зарезервированных идентификаторов элемента услуги устанавливается независимо от сетевой услуги.

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