RU2321959C2

RU2321959C2 - Идентификатор источника для нахождения мас-адреса

Info

Publication number: RU2321959C2
Application number: RU2005136879/09A
Authority: RU
Inventors: Николас В. ТИНГЛ (US); Николас В. ТИНГЛ; Джо РИГАН (US); Джо РИГАН
Original assignee: Алкател Айпи Нетворкс, Инк.
Priority date: 2003-04-28
Filing date: 2004-04-27
Publication date: 2008-04-10
Also published as: US20040213228A1; CN1816991B; WO2004097583A2; EP1618688A4; WO2004097583A3; RU2005136879A; EP1618688A2; US20070036162A1; CN1816991A; US7006499B2; US20060098654A1; EP1618688B1; US7710970B2; US7126949B2

Abstract

Изобретение относится к сетям передачи данных. Значение заголовка или метка, упоминаемая в данном документе как идентификатор станции-источника (SSID), добавляется к заголовку инкапсулированного пакета, например путем добавления SSID в качестве метки на дно стека меток многопротокольной коммутации по метке (MPLS). SSID включает в себя уникальный идентификатор, который идентифицирует маршрутизатор границы сети поставщика (РЕ), от которого исходит пакет. В некоторых вариантах осуществления IP-адрес исходящего РЕ может использоваться как SSID для этого РЕ. РЕ, принимающий данный пакет, может затем привязать МАС-адрес Ethernet источника для принятого трафика TLS, например, к исходящему РЕ. При наличии SSID исходящего РЕ принимающий РЕ может определить, какой маршрут коммутации по метке (LSP) использовать для отправки трафика Ethernet к станции с найденным МАС-адресом. Технический результат заключается в уменьшении меток в адресе станции-источника. 3 н. и 19 з.п. ф-лы, 3 ил.

Description

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

По данной заявке испрашивается приоритет Предварительной заявки на патент США № 60/466245, озаглавленной "Source identifier for MAC address learning over a point-to-multipoint label switched path", поданной 28 апреля 2003 г., которая полностью включена в настоящий документ посредством ссылки для любой цели.

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

Настоящее изобретение в основном относится к маршрутизации данных и к сетям. Более конкретно, раскрывается идентификатор источника для нахождения адреса протокола доступа к среде передачи (MAC-адреса) по коммутируемому по метке маршруту от множества точек к одной точке («многоточка-точка»).

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

Организации и предприятия получают значительный доход, предоставляя услуги передачи данных, основанные на качестве предоставляемых услуг (QoS), которое стало важной метрикой, на которой основана система расчетов. Чтобы улучшить или поддерживать QoS, такие услуги как выделенные линии, виртуальные выделенные линии (VLL), виртуальные частные сети (VPN), виртуальные частные услуги локальных сетей (ЛС) (VPLS) и другие предоставляют выделенные системы передачи данных. Эти системы обеспечивают "выделенный" маршрутный тоннель, который может являться виртуальным каналом (VC) для передачи данных между двумя или более не соединенными локально клиентскими сетями.

Одним из типичных подходов является определение коммутируемых по метке маршрутов (LSP), через которые трафик может тоннелироваться к определенным пунктам назначения или семейству пунктов назначения, обслуживаемых определенным маршрутизатором границы сети поставщика (провайдера) (PE). В случаях, когда может потребоваться возможность отправлять трафик в пункт назначения из нескольких местоположений, может быть определен LSP "многоточка-точка" (иногда обозначаемый в данном документе аббревиатурой "MP2P"). В MPLS (многопротокольной коммутации по метке) LSP типично является MP2P. LSP могут также использоваться для приложений "точка-точка" (P2P) и типично являются результатом использования коммутации по метке и однонаправленной сущности LSP. В таких LSP MP2P множество заданных маршрутов от исходящих PE, ассоциированных с конечными точками входа тоннеля, объединяются в единый маршрут, входящий в PE пункта назначения. Однако возникает проблема в том, что у PE пункта назначения должен быть способ нахождения исходящего PE и привязки данного PE к MAC-адресу принятого пакета, например, чтобы узнать, как маршрутизировать трафик, отправляемый на данный MAC-адрес источника. Когда для реализации LSP используются MPLS или MPLS-версии существующих протоколов (например, RSVP-TE, LDP, MP-BGP и т.д.), у PE пункта назначения (принимающего) нет способа узнать, какой PE создал пакет, так как каждый узел в LSP использует свою собственную метку, чтобы направлять пакеты к следующему узлу, в результате чего принимающий PE может установить по первичной метке только базовое устройство, которое направило пакет к принимающему PE через последний транзитный участок или отрезок LSP.

Обычные реализации "многоточка-точка" требуют для решения данной проблемы наложений виртуальных тоннелей. В частности, при одном из типичных подходов выделяют отдельную метку VC на каждый PE-источник для каждой услуги. Вообще говоря, типичный подход решает проблему идентификации источника и мультиплексирования трафика для различных VPN, использующих один и тот же транспорт. Однако он не уменьшает количества меток. Данный подход невыгоден благодаря накладным расходам и сложности, связанным с выделением, управлением и маршрутизацией пакетов, используя такое большое количество меток. Чтобы численно оценить этот недостаток, представим, что если, например, отдельная метка VC выделяется для каждого из "n" устройств PE или узлов, ассоциированных с конкретным клиентом или услугой, то количество меток на услугу составит порядка n²(точнее n(n-1)), так как для каждого узла потребуется обеспечить отдельный виртуальный канал "точка-точка" к каждому другому узлу. Наоборот, если бы у PE пункта назначения был способ установления исходящего PE, не требующий выделения для каждого PE каждой услуги отдельной метки VC, каждое из n устройств PE потребовало бы только одной метки на услугу, так что потребовалось бы только n меток.

Таким образом, для решения было бы полезным разрешить проблему установления адреса станции-источника без создания дополнительного слоя или сетки тоннелей для LSPO MP2P.

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

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

Фиг.1А - иллюстрация системы нахождения MAC-адреса;

Фиг.1B - иллюстрация системы нахождения MAC-адреса, показывающая базу информации пересылки (FIB);

Фиг.2 - иллюстрация примерного заголовка пакета, включающего в себя идентификатор источника для нахождения MAC-адреса; и

Фиг.3 - иллюстрация процесса привязки идентификатора к MAC-аресу источника.

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

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

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

Маршрутизация данных "многоточка-точка" без наложения или сетки выделенных маршрутных тоннелей обеспечивает желаемые свойства масштабирования, сигнализации и снабжения. Значение заголовка или метка, называемая в данном документе как идентификатор станции-источника (SSID), добавляется к заголовку инкапсулированного пакета, например путем добавления SSID в качестве метки в дно стека меток MPLS или как управляющее слово, добавленное между заголовком MPLS и данными VPN. SSID содержит уникальный идентификатор, идентифицирующий PE, от которого исходит пакет. В некоторых вариантах осуществления изобретения адрес межсетевого протокола (IP) исходящего PE может использоваться в качестве SSID для данного PE. Адрес IP может быть включен как управляющее слово между заголовком MPLS и данными VPN. PE, принимающий данный пакет, может затем связать MAC-адрес сети Ethernet источника принятого трафика TLS, например, с исходящим PE. Имея IP-адрес исходящего PE он может определить, какой LSP использовать, чтобы отправить трафик Ethernet на станцию с найденным MAC-адресом. Используя описанные ниже технические приемы, LSP "многоточка-точка" могут использоваться более эффективно для TLS, VPLS, HVPLS (иерархических виртуальных частных услуг ЛС) и других услуг. Это обеспечивает масштабирование LSP, порядок сложности которого оценивается как "n" вместо "n²" как в обычной реализации, описанной выше. Сигнальные протоколы, такие как RSVP и BGP, могут использоваться для распространения меток простым способом, а упрощенное обеспечение происходит благодаря тому, что каждому PE присваивается единая метка пункта назначения на каждую услугу.

Фиг.1А иллюстрирует систему нахождения MAC-адреса. Система 100 представляет ряд маршрутов данных, которые простираются по сети 101 поставщика услуг. Внутри сети 101 поставщика услуг находятся базовые маршрутизаторы 102-108. Хотя показано 4 базовых маршрутизатора, в других магистралях сети может использоваться больше или меньше базовых маршрутизаторов. На границах сети 101 поставщика услуг расположен ряд PE 110-120. PE 110-120 обеспечивают точки входа/выхода в/из сети 101 поставщика услуг для устройств 122-138 на стороне клиента (CE). CE 122, 124, 128 и 138 ассоциированы с конкретным клиентом и/или услугой и обеспечивают дальнейшую маршуртизацию к пунктам назначения, ассоциированным с клиентом и/или услугой. Используемый в данном документе термин "маршрутизатор" относится к любому оборудованию, используемому для маршрутизации данных от источника к пункту назначения, и может включать в себя любой узел в сети клиента или поставщика, который выполняет данную функцию маршрутизации. Здесь пункты назначения Al, A2, B, C, и D являются примерами пунктов назначения, которые муршрутизируют трафик через CE 122, 124, 128, и 138. В данном примере система сконфигурирована подобно "перевернутому дереву" или конфигурации "многоточка-точка", в которой станции-источники Al, A2, C, и D выполняют обмен данными со станцией назначения B, с трафиком от станций Al, A2, C, и D направленным к станции B, передаваемым по LSP 139 "многоточка-точка", показанным на Фиг.1А как ряд стрелок в пунктирных линиях, начинающихся в PE 110 и PE 114 и заканчивающихся в PE 120, через которые PE 110 и 114 сконфигурированы посылать трафик к PE 120. Аналогично трафик для станций, ассоциированных с PE 110, например Al, A2, и C, мог бы передаваться от станций B и D через второй LSP "многоточка-точка" (не показан на Фиг.1А) с PE 114 и PE 120 в качестве точек входа и PE 110 в качестве PE назначения, а трафик для станций, ассоциированных с PE 114, например D, мог бы передаваться от станций Al, A2, B или C через третий LSP MP2P (не показан на Фиг.1А) с PE 110 и PE 120 в качестве точек входа и PE 114 в качестве PE назначения. Таким образом, местоположения и сетевые станции, ассоциированные с CE 122, 124, 128 и 138, могут присоединяться к виртуальной сети, такой как виртуальная частная услуга LAN, используя сетку маршрутов LSP MP2P, посредством которой клиентский сетевой трафик, например трафик Ethernet, передается между местоположениями прозрачным образом для пользователей различных клиентских станций. Хотя в обмене данными с сетями клиента показаны только CE 122, 124, 128 и 138, в других вариантах использования количество маршрутизаторов CE может отличаться в зависимости от поставщика магистральных или сетевых услуг (NSP), количества клиентов, количества узлов и других факторов, оказывающих влияние на сеть.

Как указано выше, одной из проблем, которые должны быть решены при использовании LSP MP2P, как описывается в данном документе, является необходимость для пункта назначения PE (то есть для конечной точки LSP MP2P) иметь возможность "узнавать" MAC-адрес источника исходного отправителя пакета, принятого PE через LSP MP2P, и связывать данный MAC-адрес с входным PE, через который он поступил и был отправлен по LSP MP2P. В варианте осуществления идентификатор станции-источника (SSID) может быть присоединен в конец заголовка пакета данных или кадра на входном PE, например путем добавления SSID в качестве дополнительной метки на дно стека меток MPLS. При приеме выходным PE, SSID используется для связывания MAC-адреса станции-источника, которая создала пакет (например, MAC-адреса CE 122 для пакета, посланного станцией A1) с входным PE, через который он поступил и был отправлен по LSP MP2P. С использованием SSID количество меток, распространяемых на каждую PE, может быть сокращено с "одной на каждый VPN и на каждую PE того же уровня" до распространения метки по принципу "одна на каждую VPN". Если SSID не является IP-адресом маршрутизатора PE, то может использоваться отдельная конфигурация для сопоставления SSID маршрутизатору PE.

LSP MP2P, показанный на Фиг.1А, может использоваться, например, для передачи пакета клиентской сети от станции A1 к станции B. Такой пакет, созданный станцией A1, будет подаваться на входной PE 110 через CE 122. Пакет будет инкапсулирован PE 110 для передачи через LSP MP2P на PE 120, причем инкапсуляция включает в себя заголовок, содержащий метку VC, ассоциированную с LSP, и затем будет выполнена маршрутизация пакета между базовыми маршрутизаторами 102, 104 и 108, перед тем как пакет достигнет границы сети 101 поставщика услуг на выходном PE 120. PE 120 затем извлечет (декапсулирует) пакет, перестроит его в соответствии с сетью клиента и отправит его на CE 138, от которого он будет доставлен на станцию назначения B. Используемый маршрут является тоннелем LSP, который может устанавливаться путем сигнализации маршрута различным маршрутизаторам на его протяжении. Могут использоваться различные типы сигнальных протоколов, не ограничиваясь перечисленными в данном документе (например, BGP, RSVP и т.п.) Дополнительно для построения тоннельной архитектуры, подобной той, что описана, могут использоваться другие протоколы, отличные от MPLS. Ниже в связи с Фиг.1В приведены дополнительные подробности относительно маршрутизации трафика данных.

Фиг.1B иллюстрирует систему нахождения MAC-адреса, показывая таблицу 140, используемую для сопоставления идентификаторов SSID ассоциированному с ними идентификатору LSP (LSP ID), и FIB 142, используемую, чтобы привязать MAC-адрес источника к соответствующему LSP ID для конкретной VPN.

В LSP MP2P идентификатор LSP ID может использоваться для идентификации выделенного "канала" или маршрута от двух или более входных PE, расположенных вдоль границы сети 101 поставщика услуг к PE назначения. В примере, показанном на Фиг.1А и 1B, LSP ID может использоваться для идентификации LSP MP2P, соединяющего входные PE 110 и 114 с PE назначения 120. Подобные LSP, идентифицируемые ассоциированными с ними LSP ID, могут устанавливаться для транспортировки трафика другим PE, участвующим в конкретной услуге, как, например, LSP, позволяющий PE 110 и PE 120 посылать трафик к PE 114, и LSP, используемый PE 114 и PE 120, чтобы посылать трафик к PE 110. При одном из типичных подходов каждый PE назначения передает другим PE, участвующим в услуге, такой как услуга прозрачной ЛС, метку VC, которая должна использоваться для отправки ассоциированного с услугой трафика данному PE. Например, PE 110 может сигнализировать PE 114 и PE 120, что метка "101" VC должна использоваться для отправки ассоциированного с услугой трафика на PE 110, и PE 114 может сигнализировать PE 110, что метка "302" VC должна использоваться для отправки ассоциированного с услугой трафика на PE 114. Числа, используемые в этом примере, являются совершенно произвольными, и может быть задано любое число, подходящее для применимых протоколов, используемых для установки и обеспечения LSP.

Чтобы знать, как маршрутизировать обратный трафик, каждый PE должен "узнать" связь между MAC-адресом источника в принятых пакетах и LSP ID, ассоциированным с входным устройством PE, которое отправило полученный пакет через LSP MP2P, то есть каждый PE должен заполнять FIB, такую как FIB 142 по Фиг.1B. Например, в случае PE 120, в начале PE 120 заполняет таблицу 140, связывая LSP ID, сообщенный ему для использования каждым из других PE, участвующих в услуге, с SSID для этого PE. В примере, показанном на Фиг.1B, таблица 140 заполнена записью, связывающей LSP ID "101" с SSID для PE 110. В таблице 140 для удобства и ясности SSID показан как "PE110", хотя как отмечалось выше, в качестве SSID может использоваться IP-адрес. Когда пакет, созданный станцией A1 и направленный станции B, принят PE120, если в FIB 142 не существует записей для ассоциированного MAC-адреса источника, создается запись путем ввода MAC-адреса источника и связывания с ним LSP ID, ассоциированного с входным PE, от которого был принят пакет. PE 120 гарантирует отправку принятого пакета корректному CE. Однако в других вариантах осуществления для идентификации CE и, таким образом, для пересылки пакета, не требующей дополнительного поиска MAC-адреса, могло бы использоваться управляющее слово, идентификатор или метка. Как показано на Фиг.1B, этого можно достигнуть считыванием SSID (присоединенного как дополнительная метка в стеке, например, как описано выше), используя таблицу 140, чтобы сопоставить SSID соответствующему LSP ID, и затем связыванием этого LSP ID с MAC-аресом источника в FIB 142. Если в будущем от PE 120 потребуется обрабатывать исходящий трафик, направленный на MAC-арес, ассоциированный со станцией А1, PE 120 будет обращаться к FIB 142, чтобы получить LSP ID, который должен использоваться для передачи пакета корректному PE (в данном случае PE 110).

Фиг.2 иллюстрирует примерный заголовок пакета, включающий в себя идентификатор источника для нахождения MAC-адреса. В заголовок 200 пакета включены несколько полей, представляющих инкапсулированные данные, которые используются для маршрутизации пакета или кадра между станцией-источником и станцией назначения. Метка 202 VC показывает маршрутный тоннель виртуального канала, по которому планируется передавать конкретный пакет данных. Между конкретными конечными точками обеспечиваются определенные маршрутные тоннели, которые назначаются на основе определенного QoS. EXP-биты 204 являются частью заголовка MPLS, предусмотренной для экспериментального значения. Если инкапсулированный кадр является кадром Ethernet, который содержит маркер IEEE 802.lq VLAN, p-биты маркера могут быть преобразованы в EXP-биты на входной конечной точке тоннеля. EXP-биты могут быть преобразованы обратно в p-биты маркера VLSN на выходной конечной точке тоннеля. Бит 206 S обозначает "дно" стека сеток. Значение 208 TTL содержит значение времени жизни метки VC. В данном варианте осуществления метка 202 VC, EXP-биты 204 и значение 208 TTL являются стандартными компонентами заголовка MPLS. Зарезервированное поле 210 предусмотрено для дополнительной информации заголовка. Флаги 212 обеспечивают поле для других меток и идентификаторов, которые могут использоваться для идентификации ресурсов и частей отдельного маршрута, по которому могут маршрутизироваться данные. Длина 214 может использоваться для определения длины некоторых отдельных полей в заголовке инкапсулированного пакета. Порядковый номер 216 определяет порядок пакета данных или кадра, чтобы управлять повторной сборкой по достижении станции назначения. Зарезервированное поле 210, флаги 212, длина 214 и порядковый номер 216 совместно идентифицируются как управляющие слова для использования с реализациями MPLC. В заключение в SSID 218 содержится дополнительное управляющее слово. SSID 218 включено в состав, обеспечивая управляющее слово, которое может быть ассоциировано с исходящей станцией-источником (например, исходящим PE) с целью дать возможность выходной конечной точке тоннеля "узнать" начальные пункты MAC-адреса и связать их с транспортными тоннелями для исходящего трафика, ассоциированного с такими найденными MAC-адресами. Предпочтительно SSID является 4-х байтным полем, хранящим идентификатор, ассоциированный со станцией-источником. Однако в других вариантах осуществления длина поля может быть больше или меньше. Узнавая конкретные адреса источника, граничные маршрутизаторы, такие как PE 112-120, могут определить, откуда пришел конкретный пакет и куда должны быть направлены ответные пакеты.

Фиг.3 иллюстрирует процесс связывания идентификатора станции-источника с MAC-адресом источника. Идентификатор добавляется к пакету и передается по маршрутному тоннелю, такому как LSP или VC (302). Входной конечной точкой, такой как входное устройство PE, может быть добавлен идентификатор LSP или VC. Идентификатором может быть любое значение или строка, которая является уникальной по отношению к входному PE, например IP-адрес PE. После передачи пакет принимают на граничном маршрутизаторе назначения (например, PE) (304), который связывает идентификатор с адресом станции-источника (например, MAC-адресом) (306). Связывая MAC-адрес с идентификатором, граничный маршрутизатор узнает, как маршрутизировать трафик данных обратно к инициирующей точке, ассоциированной с MAC-адресом, при этом нет необходимости устанавливать реальный или виртуальный канал "точка-точка" или маршрут для каждой возможной исходящей конечной точки, как описано выше. После связывания MAC-адреса с идентификатором, идентификатор записывается в FIB конкретного граничного маршрутизатора (например, PE, CE) (308). Другие PE в сети 101 поставщика услуг (Фиг.1А, 1B), которые принимают пакет, например, в случае широковещательной рассылки пакета на все PE, ассоциированные с услугой, могут подобным образом "узнать" связь MAC-адреса источника с идентификатором (например, SSID). В других вариантах осуществления для хранения идентификатора(ов) могут использоваться другие базы данных, базы управляющей информации (MIB) или другие хранилища, ассоциированные с граничными маршрутизаторами (или устройствами).

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

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

Claims

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

принимают данные на станции назначения;

извлекают из заголовка, ассоциированного с данными, идентификатор станции-источника, ассоциированный с исходящей станцией и включенный в заголовок исходящей станцией; и

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

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

3. Способ маршрутизации данных по п.1, при котором упомянутый протокол включает в себя протокол многопротокольной коммутации по метке (MPLS).

4. Способ маршрутизации данных по п.1, при котором идентификатор станции-источника ассоциирован с маршрутом к исходящей станции.

5. Способ маршрутизации данных по п.1, при котором адрес источника содержит адрес протокола доступа к среде передачи (МАС-адрес), ассоциированный с узлом, который первоначально отправил данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и память, сконфигурированную сохранять идентификатор станции-источника и адрес источника,

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

18. Система маршрутизации данных по п.17, в которой данные содержат кадр Ethernet.

19. Система маршрутизации данных по п.17, в которой заголовок пакета основан на многопротокольной коммутации по метке.

20. Система маршрутизации данных по п.17, в которой процессор ассоциирован со станцией назначения.

21. Система маршрутизации данных по п.17, в которой процессор ассоциирован со станцией назначения и станция назначения содержит маршрутизатор границы сети поставщика.

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