ИНКАПСУЛЯЦИЯ АДРЕСА АСИММЕТРИЧНОЙ СЕТИ Российский патент 2015 года по МПК H04L12/46 

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

На фиг.1 показана схема варианта осуществления услуги взаимно соединенных (VPLS) LAN виртуальной частной локальной сети (LAN).

На фиг.2 показана схема варианта осуществления сети виртуального уровня 2.

На фиг.3 показана схема варианта осуществления механизма пограничного контроля.

На фиг.4 показана схема варианта осуществления схемы передачи фрейма данных.

На фиг.5 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.6 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.7 показана схема варианта осуществления взаимно соединенных сайтов уровня 2.

На фиг.8 показана схема варианта осуществления расширения уровня 2 по многоадресным областям.

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

На фиг.10 показана схема варианта осуществления механизма ограничения адреса области.

На фиг.11 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.12 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.13 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.14 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.15 показана схема варианта осуществления схемы широковещательной передачи.

На фиг.16 показана схема другого варианта осуществления схемы широковещательной передачи.

На фиг.17 показана схема варианта осуществления взаимно соединенных районов сети.

На фиг.18 показана схема другого варианта осуществления взаимно соединенных районов сети.

На фиг.19 показана схема варианта осуществления схемы прокси ARP.

На фиг.20 показана схема другого варианта осуществления схемы передачи фрейма данных.

На фиг.21 показана схема другого варианта осуществления схемы прокси ARP.

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

На фиг.23 показана схема варианта осуществления физического сервера.

На фиг.24 показана схема варианта осуществления схемы асимметричной инкапсуляции адреса сети.

На фиг.25 показана схема варианта осуществления схемы обработки ARP.

На фиг.26 показана схема варианта осуществления расширенной полезной нагрузки ARP.

На фиг.27 показана схема варианта осуществления другой схемы передачи фрейма данных.

На фиг.28 показана схема протокола варианта осуществления улучшенного способа обработки ARP.

На фиг.29 показана схема протокола варианта осуществления расширенного способа определения адресов.

На фиг.30 показана схема варианта осуществления модуля компонента сети.

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

Осуществление изобретения

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

Современные сети передачи данных, которые могут представлять собой сети уровня 2 или уровня 3, обеспечивают возможность соединения с "облачными" услугами и виртуальными машинами (VM), для которых может потребоваться охват по множеству мест положения или сайтов. Иногда сети уровня 2 для центров данных, которые соединяют кластеры услуг (или VM) и устройства-накопители, должны осуществлять охват множества мест положения. Сети центра данных также, возможно, должны находиться на уровне сетей уровня 2 для поддержки уже развернутых вариантов применения и, таким образом, экономии средств, например, миллионов долларов. Передача данных на уровне 2 между кластером услуг и/или устройствами накопителями включает в себя балансирование нагрузки, кластеризацию базы данных, восстановление ошибок виртуального сервера, транспарентные операции ниже сетевого уровня (уровень 3), распространение подсети по множеству местоположений и избыточность. Передача данных на уровне 2 также включает в себя механизм поддержания жизнеспособности между приложениями. Некоторым приложениям требуются одинаковые IP-адреса для связи во множестве мест положений, где один сервер может быть активным, и другой сервер может находиться в дежурном режиме. Активные серверы и серверы в дежурном режиме (в различных местах положений) могут выполнять обмен сообщениями для поддержания жизнеспособности между собой, что может потребовать использования механизма поддержания жизнеспособности уровня 2.

На фиг.1 иллюстрируется вариант осуществления взаимно соединенных VPLS локальных вычислительных сетей (LAN) 100. Взаимно соединенные VPLS LAN 100 представляют собой масштабируемый механизм, который можно использовать для соединения сети уровня 2 через множество мест положений DC, например, физических мест положений для установления унифицированной или плоской сети уровня 2. Взаимно соединенные VPLS LAN 100 могут содержать VPLS 110 и множество LAN 120, которые могут быть соединены с VPLS 110 через множество краевых узлов 112, таких как краевые маршрутизаторы. Каждая LAN 120 может содержать множество коммутаторов 122 уровня 2, соединенных с соответствующими краевыми узлами 112, множество коммутаторов 124 доступа, соединенных с соответствующими коммутаторами уровня 2, множество VM 126, соединенных с соответствующими коммутаторами 124 доступа. Компоненты взаимно соединенных VPLS LAN 100 могут быть скомпонованы, как показано на фиг.1.

VPLS 110 может представлять собой любую сеть, которая выполнена с возможностью соединения с LAN 120 через разные места положения или DC. Например, VPLS 110 может содержать сеть Уровня 3, для взаимного соединения LAN 120 через различные DC. Коммутаторы 122 уровня 2 могут быть выполнены с возможностью выполнять обмен данными с уровнем соединения данных модели взаимного соединения открытой системы (OSI). Примеры протоколов соединения данных включают в себя Ethernet для LAN, протокол "из точку-в точку" (РРР), протокол соединения данных высокого уровня (HDLC), и усовершенствованный протокол управления передачей данных (ADCCP) для соединений "из точку-в точку". Коммутаторы 124 доступа могут быть выполнены с возможностью перенаправления данных между коммутаторами 122 уровня 2 и VM 126. VM 126 могут содержать виртуальные машины системы, которые обеспечивают платформы системы, например, операционные системы (OS) и/или виртуальные машины процесса, в которых работают программы или приложения. VM 126 в каждой LAN 120 может быть распределены по множеству процессоров, центральных процессорных устройств (CPU) или компьютерных систем. Множество VM 126 в LAN 120 также могут совместно использовать одни и те же системные ресурсы, такие как пространство на диске, запоминающее устройство, процессор и/или другие вычислительные ресурсы. VM 126 могут быть расположены на полке и соединены с соответствующими LAN 120, например, через коммутаторы 124 доступа.

Некоторые аспекты VPLS взаимно соединенных LAN 100 могут представлять непрактичные или нежелательные проблемы при воплощении. В одном аспекте VPLS 110 могут потребовать воплощения глобальной вычислительной сети (WAN), которая поддерживает коммутацию метки протокола с множеством меток (MPLS). Однако некоторые операторы не поддерживают MPLS через WAN и, таким образом, могут иметь трудности при воплощении взаимно соединенных VPLS LAN 100. Кроме того, для разрешения адресов уровня соединения с хост-устройствами, например, для VM 126 через LAN 120, может потребоваться протокол ARP IP версии четыре (IPv4) или ND IP версии шесть (IPv6), такой как IPv4 ARP, описанный в Internet Engineering Task Force (IETF) Request for Comments (RFC) 826 и IPv6 ND, описанный IETF RFC 4861, оба из которых представлены здесь по ссылке. ARP может выполнять лавинные запросы во все взаимно соединенные LAN 120 и, таким образом, отбирать существенное количество системных ресурсов (например, ширины полосы). С таким механизмом лавинного ARP могут быть связаны проблемы масштабирования, по мере того, как увеличивается количество LAN 120 и/или VM 126. Для взаимно соединенной VPLS LAN 100 также требуется устанавливать псевдопровода (PWs) сетки, для соединения с LAN 120, что может потребовать интенсивной конфигурации и технической поддержки состояния туннелей. В некоторых сценариях VPLS 110 может использоваться пограничный шлюзовый протокол (BGP) для раскрытия LAN 120 и построения сетки PW для каждой LAN 120.

Виртуализация оптического транспорта (OTV) представляет собой другой масштабируемый механизм, который был предложен для соединения сетей уровня 2 через множество мест положения или DC для установления плоской сети уровня 2. OTV представляет собой способ, предложенный Cisco, который зависит от IP инкапсуляции передач данных уровня 2. OTV может использовать протокол маршрутизации промежуточная система - промежуточная система (IS-IS) для распределения возможности доступа к MAC в пределах каждого местоположения (например, DC) для других мест положения. Схема OTV также может иметь некоторые непрактичные или нежелательные аспекты. В одном аспекте OTV может потребовать поддержки относительно большого количества групп многоадресной передачи для провайдера базовой сети IP. Поскольку каждая LAN может иметь отдельную топологию наложения, может существовать относительно большое количество топологий наложения, которые поддерживаются IP сетью провайдера услуги, что может составить нагрузку на базовую сеть. OTV также могут потребовать, чтобы краевой узел использовал протокол администрирования групп Интернет (IGMP), для соединения с различными группами многоадресной передачи в области IP. Если каждый краевой узел будет соединен с множеством VLAN, может потребоваться участие краевого узла во множестве групп IGMP.

В OTV краевые устройства, такие как шлюз, в каждом местоположении, могут представлять собой IP хост-устройства, которые находятся на расстоянии одного транзитного участка друг от друга, что может не потребовать воплощения протокола состояния соединения между краевыми устройствами для обмена информацией о возможности доступа. Однако состояние соединения также может использоваться для аутентификации однорангового устройства, что может потребоваться в OTV, если одноранговое устройство присоединяется к VLAN, путем передачи отчета IGMP версии 3 (IGMPv3). В качестве альтернативы, OTV может использовать способ аутентификации BGP. Однако моменты времени аутентификации BGP могут быть другими, чем моменты времени аутентификации IS-IS. Например, BGP может быть настроен на рабочие характеристики, составляющие секунды, и IS-IS может быть настроен на субсекундные рабочие характеристики. Кроме того, протокол IS-IS может не быть пригодным для обработки, по существу, больших количеств хост-устройств и VM, например, десятки тысяч, в каждом местоположении, в системе OTV. OTV также может быть непригодной для поддержки десятков тысяч закрытых групп пользователей.

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

Способы включают в себя механизм управления границей, для масштабирования относительно большого плоского уровня 2 по множеству местоположений. При этом приложения, серверы и/или VM могут не иметь информации о виртуальной сети уровня 2, которая содержит множество сетей уровня 2, взаимно соединенных с другой сетью, такой как сеть уровня 3, уровня 2,5, или уровня 2. Сети уровня 2 могут быть расположены в разных или отдельных физических местах положения, на множестве этажей, в одном местоположении, или во множестве рядов, взаимно соединенных уровнем 3. Механизм разрешения адреса, независимого от протокола, также можно использовать, и он может быть пригодным для обработки относительно большой виртуальной сети уровня 2 и/или, по существу, большого количества сетей уровня 2 по множеству мест положений.

На фиг.2 иллюстрируется вариант осуществления виртуальной сети 200 уровня 2 по разным DC или физическим местам положения. Сеть 200 виртуального уровня 2 может представлять собой масштабируемый механизм для соединения сети уровня 2 по множеству мест положения, например, географических мест положения или DC, или множеству сайтов в пределах одного центра данных для установления унифицированной или плоской сети уровня 2. Виртуальная сеть 200 уровня 2 может содержать сеть 210 услуги и множество сетей 220 уровня 2 могут быть соединены с сетью 210 услуги через множество краевых узлов 212, таких как краевые маршрутизаторы. Сеть 210 обслуживания может называться здесь схемой взаимного соединения, такой как сеть провайдера услуги, основная сеть, сеть уровня 3, сеть уровня 2 или 2,5, или любая другая сеть, которая соединяет или взаимно соединяет компоненты в множестве сайтов. Каждая сеть 220 уровня 2 может содержать множество L2GW 222, соединенных с соответствующими краевыми узлами 212, и множество промежуточных коммутаторов 224, которые могут быть соединены с L2GW 222. Компоненты виртуальной сети 200 уровня 2 могут быть скомпонованы, как показано на фиг.2. Промежуточные коммутаторы 224 также могут быть соединены с множеством хост-устройств и/или VM (не показаны).

Сеть 210 обслуживания может представлять собой любую сеть, установленную для взаимного соединения сетей 220 уровня 2, таких как сеть провайдера услуги. Например, сеть 210 обслуживания может представлять собой сеть уровня 2, уровня 2,5 или уровня 3, такую как виртуальная частная сеть (VPN). Сеть 210 обслуживания может не иметь информации обо всех адресах, например, MAC-адресах, за пределами L2GW 222. L2GW 222 могут представлять собой краевые узлы в каждом местоположении DC и могут иметь интерфейс уровня 2 для внутренней связи в местоположениях DC. L2GW 222 и промежуточные коммутаторы 224 могут связываться с хост-устройствами и/или VM в одних и тех же местах положений в пределах одних и тех же сетей 220 уровня 2, используя соответствующие MAC-адреса хост-устройств. Однако L2GWs 222 и промежуточный коммутатор 224 не обязательно могут иметь информацию о MAC адресах хост-устройств/VM в других сетях 220 уровня 2. Вместо этого, хост-устройство в одной сети 220 уровня 2 может использовать адрес L2GW 222 другой сети 220 уровня 2 (в другом местоположении или месте), как адрес места назначения, для связи с целевым хост-устройством в другой сети уровня 2. Когда фрейм (например, фрейм Ethernet), поступает в L2GW 222 целевого сайта, например, другой сети уровня 2, адрес назначения целевого хост-устройства может быть транслирован L2GWs 222 на основе IP-адреса, переносимого в полезной нагрузке фрейма, например, используя таблицу трансляции сетевых адресов (NAT) или таблицу трансляции адресов MAC (MAT), как описано ниже.

В одном варианте осуществления каждый L2GW 222 может поддерживать адреса всех хост-устройств/VM в пределах одной и той же сети 220 уровня 2 из L2GW 222 в таблице информации локальных IP-адресов (Local-IPAddr Table). L2GW 222 может также быть выполнен с возможностью воплощения функции ARP, как описано ниже. Кроме того, L2GW 222 может поддерживать таблицу передачи MAC, которая может содержать адреса MAC для не-IP приложений. Адреса MAC могут содержать адреса MAC хост-устройств/VM, и промежуточный коммутатор 224 в одном и том же местоположении, например, в одной и той же сети 220 уровня 2.

L2GW 222 может информировать свои одноранговые устройства (например, другие L2GWs 222) в других местах положений (например, в других сетях 220 уровня 2) обо всех активных VLAN и обо всех IP-адресах локальных хост-устройств в каждом их местоположении VLAN. Если отсутствуют IP приложения в пределах области, L2GW 222 также может информировать свои одноранговые устройства, передавая адреса MAC и VLAN для этих не-IP приложений. Сайт уровня 2 или сеть 220 уровня 2 могут иметь множество VLAN, разрешенных в портах L2GWs' 222 и в портах 224 промежуточных коммутаторов, с целью удобства выполнения операций. Таким образом, VM или хост-устройством, принадлежащим любой из разрешенных VLAN, можно управлять без дополнительной конфигурации. VLAN, которая является активной на сайте (или сеть 220 уровня 2) может иметь хост-устройство, принадлежащее этой VLAN, которое расположено в пределах этого сайта. L2GW 222 в разных местах положения может получать IP-адреса хост-устройств всех других мест положений, даже если L2GW 222 может содержать только информацию адреса для VLAN, которые являются активными в их локальных сайтах (например, в удаленной таблице информации IP-адресов для каждого L2GW 222). Если в локальной области отсутствуют хост-устройства, которые принадлежат идентификатору VLAN (VID) для VLAN, тогда может не потребоваться содержать информацию об удаленных хост-устройствах для этого VID, поскольку может отсутствовать обмен данными с этим VID, который направлен на локальную область. Термины VLAN и VID используются здесь взаимозаменяемо для обозначения установленной VLAN, даже при том, что VLAN может быть назначено множество VID (например, как описано в IEEE 802.1Q). Следовательно, каждый L2GW 222 может отображать каждую группу IP-адресов, которые принадлежат местоположению (например, сети 220 уровня 2) на адрес MAC, соответствующий L2GW 222, который принадлежит тому же местоположению. L2GW 222 также передает обновление информации адреса для одноранговых устройств, когда происходит обмен в ее Local-IPAddrTable, для обновления информации в других одноранговых устройствах. Это может обеспечить возможность обновления информации адреса и отображения в каждом L2GW 222 с последовательным приращением.

На фиг.3 иллюстрируется вариант осуществления механизма 300 управления границей. Механизм 300 управления границей может представлять собой масштабируемый механизм для установления плоской или виртуальной сети уровня 2 через множество сайтов, мест положения или DC. Виртуальная сеть уровня 2 может содержать сеть 310 обслуживания и множество сетей 320 уровня 2, которые могут быть соединены с сетью 310 обслуживания через множество краевых узлов 312, таких как краевые маршрутизаторы. Каждая сеть 220 уровня 2 может содержать множество L2GW 322, соединенных с соответствующими краевыми узлами 312, и множество промежуточных коммутаторов 324, которые могут быть соединены с L2GW 322. Промежуточные коммутаторы 324 также могут быть соединены (или могут быть доступны) для хост-устройств 326, например, инициированы по VM или серверу. Компоненты виртуальной сети уровня 2 могут быть размещены, как показано на фиг.2, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На основе механизма 300 управления границей, каждый L2GW 322 может поддерживать IP-адрес хост-устройств во всех местах положений, принадлежащих VLAN, которые являются активными на ее соответствующем локальном сайте уровня 2, например, соответствующем сети 320 уровня 2. Каждый L2GW 322 также может знать MAC-адреса одноранговых L2GW 322 в других местах положений. Однако L2GW 322 может не поддерживать MAC-адреса хост-устройств в других местах положений, что может существенно уменьшить размер обмениваемых (и сохраняемых) данных между L2GW 322, поскольку IP-адреса могут быть сведены к минимуму (например, 10.1.1-х может представлять 255 хост-устройств), в то время как адреса MAC могут не быть сведены к минимуму. IP-адреса, поддерживаемые в L2GW 322, могут быть отображены на MAC-адреса соответствующего L2GW 322 в тех же местах положений. В частности, каждый набор IP-адресов хост-устройств, которые принадлежат каждому местоположению или сети 300 уровня 2, может быть отображен на адрес MAC L2GW 322 в этом местоположении. Однако L2GWs 322 может выполнять обмен между разными местами положения, множеством MAC-адресов для узлов, в которых работают не-IP приложения.

Для поддержки разрешения адресов между разными местоположениями сети виртуального уровня 2, запрос ARP (или ND) может быть передан из первого хост-устройства 326 (хост-устройство А) и может быть перехвачен соответствующим локальным L2GW 322 в первом местоположении или в сети 320 уровня 2. Хост-устройство А может передать запрос ARP для получения адреса MAC второго хост-устройства 326 (хост-устройства В) во втором месте положения или в сети 320 уровня 2. Если локальный L2GW 322 имеет запись для хост-устройства В, принадлежащего той же VLAN, как хост-устройства А, например, IP-адрес хост-устройства В, локальный L2GW 322 может ответить на запрос ARP/ND, посылая свой собственный адрес MAC в хост-устройство А. В качестве альтернативы, локальный L2GW 322 может передавать соответствующий адрес MAC L2GW (где находится хост-устройство В) в ответе ARP/ND в хост-устройство А. Если локальный L2GW 322 не поддерживает или не сохраняет запись для хост-устройства В для VLAN, локальный L2GW 322 может предполагать, что хост-устройство В не существует. Например, L2GW 322 может обновлять свои одноранговые устройства с их локальными хост IP-адресами и их соответствующими VLAN на регулярной или периодической основе. Возможно, что некоторые L2GW 322 не имели принятые обновления для IP-адресов вновь сконфигурированных хост-устройств в других местах положения для некоторых VLAN. В таком случае никакой ответ не будет передан обратно, и запрашивающий объект (хост-устройство А), может передавать множество запросов ARP/ND для целевого хост-устройства.

В варианте осуществления L2GW 222 может передавать множество объединенных IP-адресов в локальные хост-устройства для каждой VLAN в другие L2GW 222 на других местах уровня 2. Количество записей в объединенных адресах может быть существенно меньшим, чем соответствующее количество записей в Local-IPAddrTable L2GW 222. в некоторых вариантах осуществления L2GW 222 может передавать запросы во все другие L2GWs 222 на других сайтах уровня 2 для запроса IP-адресов (в объединенной форме) в одиночную VLAN (или любую из VLAN) в удаленных сайтах. Это может быть полезным, когда хост-устройство, принадлежащее VLAN, которая не была активной, добавляют к локальному сайту L2GW 222.

В таблице 1 иллюстрируется пример отображения хост-адресов на соответствующие MAC адреса L2GW и VLAN, в соответствии с механизмом 300 управления границей. Множество адресов MAC L2GW (например, MAC L2GW1 и MAC L2GW2) может быть отображено на множество соответствующих хост-адресов. Каждый адрес MAC-L2GW может быть отображен на множество IP хост-адресов (или MAC) во множестве VLAN (например, VLAN#, VLAN-x, …), которые могут быть ассоциированы с одним и тем же местоположением или DC. Каждая VLAN также может содержать множество виртуальных частных групп (VPG) (или закрытых групп пользователей) из хост-устройств. VPG может представлять собой кластер хост-устройства и/или VM, которые принадлежат области уровня 2 (или области L2) и могут связываться друг с другом через уровень 2. Область уровня 2 может использоваться здесь для обозначения вспомогательного местоположения или подсайта в сети уровня 2. Когда сеть уровня 2 охватывает несколько сайтов или мест положения, каждый сайт может называться здесь областью уровня 2. Термины область уровня 2, сайт уровня 2 и район уровня 2 может использоваться здесь взаимозаменяемо. Термины область, сайт и район также могут использоваться здесь взаимозаменяемо. Хост-устройства VPG также могут иметь группы многоадресной передачи, установленные среди них. Хост-устройства/VM в пределах VPG могут охватывать множество физических мест положения. Во многих случаях одна VLAN может быть выделена для одного потребителя, например, может быть только одна VPG на VLAN. При этом может не потребоваться иметь колонку VPG (или атрибут) в таблице в таких случаях.

Например, VLAN# может содержать множество хост-устройств во множестве VPG, включая в себя G-x1, G-x2, … И каждая VPG может содержать множество хост-устройств. Для IP применений IP-адреса хост-устройств в каждой VLAN могут быть отображены на соответствующий адрес MAC L2GW в одном и том же местоположении, например, как в случае VLAN# и VLAN-x…). IP-адреса могут быть сведены к минимуму для уменьшения количества записей в таблице. Для не-IP применений MAC-адреса хост-устройств в каждой VLAN могут быть отображены на соответствующий адрес MAC L2GW в том же местоположении для VLAN так, как в случае VLAN-x1. В некоторых случаях, может быть только один VPG для каждой VLAN, и, следовательно, колонка VPG в таблице 1 может не потребоваться.

Таблица 1 Механизм управления границей L2GW VLAN VPG Хост-устройство L2GW1 MAC VLAN# G-x1 Все IP хост-устройства в этой группе G-x2 Все IP хост-устройства в этой группе VLAN-x …   G-xj   VLAN-x1 G-j1 MAC (коммутаторы и/или узлы без IP адресов) MAC G-j2 MAC L2GW2 MAC      

На фиг.4 иллюстрируется вариант осуществления схемы 400 направления фрейма данных, которая может использоваться в виртуальной сети уровня 2, охватывающей множество местоположений или DC. Виртуальная сеть уровня 2 может содержать сеть 410 обслуживания и множество сетей 420 уровня 2, которые могут быть соединены с сетью 410 обслуживания через множество краевых узлов 412, таких как краевые маршрутизаторы. Каждая сеть 420 уровня 2 может содержать множество L2GW 422, соединенных с соответствующими краевыми узлами 412, и множество промежуточных коммутаторов 424, которые могут быть соединены с L2GWs 422. Промежуточные коммутаторы 424 также могут быть соединены с хост-устройствами 426, например, VM. Компоненты виртуальной сети уровня 2 могут быть размещены так, как показано на фиг.4, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На основе схемы 400 направления фрейма данных, L2GWs 422 может поддерживать стандарт Института инженеров по электронике и радиотехнике (IEEE) 802.1ah для MAC-в-MAC, который представлен здесь по ссылке, используя поле типа Ether для обозначения, что для внутреннего фрейма требуется трансляция адреса MAC. Например, первый L2GW 422 (GW1) может, например, принимать фрейм 440, фрейм Ethernet, из первого хост-устройства 426 (хост-устройство А) в первом местоположении (Loc 1). Фрейм 440 может быть предназначен для второго хост-устройства 426 (хост-устройство В) во втором местоположении (Loc 2). Фрейм 440 может содержать адрес (DA MAC) 442 назначения MAC для GW1 (L2GW-Loc1), адрес (SA MAC) 444 источника MAC для хост-устройства (MAC A), IP адрес (IP DA) 446 места назначения для хост-устройства В (В), адрес (IP-SA) 448 источника для хост-устройства А (А) и полезную нагрузку. GW1 может затем добавить внешний заголовок MAC для фрейма 440, для получения внутреннего фрейма 460. Внешний заголовок MAC может содержать MAC-DA 462 для GW2 (L2GW-Loc2), MAC-SA 464 для GW1 (L2GW-Loc1), и Тип 466 Ether, который обозначает, что для внутреннего фрейма 460 требуется трансляция адреса MAC. Внутренний фрейм 460 также может содержать MAC-DA 468 для GW1 (L2GW-Loc1) и MAC-SA 470 для хост-устройства A (MAC для А). Внутренний фрейм 460 может затем быть передан в сеть 410 обслуживания в GW2, которая может обрабатывать внешний заголовок MAC для трансляции адреса MAC во фрейме. При этом GW2 может получать второй фрейм 480, который может содержать MAC-DA 482 для хост-устройства В (MAC для В), MAC-SA 484 для хост-устройства A (MAC для A), IP-DA 486 для хост-устройства В (В), IP-SA 488 для хост-устройства А (А) и полезную нагрузку. Второй фрейм 480 может затем быть перенаправлен в хост-устройство В в Loc 2.

Схема 400 передачи фрейма данных может быть проще при воплощении, чем схема OTV Cisco, в которой требуется инкапсуляция внешнего заголовка IP. Кроме того, множество микросхем Ethernet поддерживают IEEE 802.1ah. Так метка случая обслуживания (I-TAG), такая, как установлено в 802.1ah, может использоваться для дифференциации между разными VPGs. Таким образом, поле I-TAG также можно использовать в схеме 400 передачи фрейма данных для разделения между множеством VPG в области провайдера, например, в сети 410 обслуживания. GW2 может выполнять схему трансляции MAC, описанную выше, используя MAT, что может быть аналогично использованию NAT для трансляции общедоступного IP в частный IP. В отличие от схемы NAT, которая основана на сеансе протокола управления передачей (TCP), схема MAT может быть основана на использовании внутреннего IP-адреса для поиска адреса MAC.

На фиг.5 иллюстрируется вариант осуществления другой схемы 500 передачи фрейма данных для не-IP приложений. Схема 500 передачи фрейма данных может использовать адреса MAC не-IP хост-устройств или хост-устройств, которые воплощают не-IP приложения вместо IP-адресов, для перенаправления фреймов между хост-устройствами, расположенными в разных местах положения в виртуальной сети уровня 2. Виртуальная сеть уровня 2 может содержать сеть 510 обслуживания, и множество сетей 520 уровня 2 могут быть соединены с сетью 510 обслуживания через множество краевых узлов 512, таких как краевые маршрутизаторы. Каждая сеть 520 уровня 2 может содержать множество L2GW 522, соединенных с соответствующими краевыми узлами 512, и множество промежуточных коммутаторов 524, которые могут быть соединены с L2GW 522. Промежуточные коммутаторы 524 также могут быть соединены с хост-устройствами 526, например, VM. Компоненты виртуальной сети уровня 2 могут быть размещены так, как показано на фиг.5, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На основе схемы 500 передачи фрейма данных, L2GW 522 могут поддерживать IEEE 802.1ah для MAC-В-MAC. Например, первый L2GW (GW1) 520 может принимать фрейм 540, например, фрейм Ethernet, из первого хост-устройства 526 (host А), находящегося в первом местоположении (Loc 1). Фрейм 540 может быть намечен или предназначен для второго хост-устройства 526 (host В) во втором местоположении (Loc 2). Фрейм 540 может содержать MAC-DA 542 для GW1 (L2GW-Loc1), MAC-SA 544 для хост-устройства A (MAC для А), и полезную нагрузку. GW1 может затем добавлять внешний заголовок MAC к фрейму 540 для получения внутреннего фрейма 560. Внешний заголовок MAC может содержать MAC-DA 562 для GW2 (L2GW-Loc2), MAC-SA 564 для GW1 (L2GW-Loc1), и Ether Type 566, который обозначает, что внутренний фрейм 560 представляет собой фрейм MAC-в-MAC. Внутреннее поле 560 также может содержать MAC-DA 568 для хост-устройства В (MAC для В) и MAC-SA 570 для хост-устройства A (MAC для А). Внутренний фрейм 560 может затем быть перенаправлен в сеть 510 обслуживания в GW2, которая может обрабатывать внутренний фрейм 560 для получения второго фрейма 580. Второй фрейм 580 может содержать MAC-DA 582 для хост-устройства В (MAC для В) и MAC-SA 584 для хост-устройства A (MAC А), и полезную нагрузку. Второй фрейм 580 может быть затем перенаправлен в хост-устройство В в Loc 2.

Схема 500 передачи фрейма данных может иметь более простое воплощение, чем схема OTV Cisco, для которой требуется инкапсуляция внешнего заголовка IP. Кроме того, множество микросхем Ethernet поддерживают IEEE 802.1ah. I-TAG, как описано в 802.1ah, может использоваться для дифференциации между разными VPG. Таким образом, поле I-TAG также может использоваться в схеме 500 передачи фрейма данных для разделения между множеством VPG области провайдера, например, в сети 510 обслуживания. GW2 может обрабатывать второй фрейм 580, как описано выше, без выполнения схемы трансляции MAC.

На фиг.6 иллюстрируется вариант осуществления другой схемы 600 передачи фрейма данных, которая может использоваться в виртуальной сети уровня 2 во множестве мест положения. Схема 600 направления фрейма данных может использоваться для направления фреймов из хост-устройства, которое переместилось из предыдущего местоположения в новое местоположение в виртуальной сети уровня 2, и поддерживает тот же изученный адрес MAC для второго хост-устройства. Виртуальная сеть уровня 2 может содержать сеть 610 обслуживания и множество сетей 620 уровня 2, которые могут быть соединены с сетью 610 обслуживания через множество краевых узлов 612, таких как краевые маршрутизаторы. Каждая сеть 620 уровня 2 может содержать множество L2GW 622, соединенных с соответствующими краевыми узлами 612, и множество промежуточных коммутаторов 624, которые могут быть соединены с L2GWs 622. Промежуточные коммутаторы 624 также могут быть соединены с хост-устройствами 626, например, VM. Компоненты виртуальной сети уровня 2 могут быть размещены, как показано на фиг.6, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

Когда первое хост-устройство 626 (host А) перемещается из предыдущего местоположения (Loc 1) в новое местоположение (Loc 3), хост-устройство А все еще может использовать тот же самый изученный адрес MAC для второго хост-устройства 626 (host В). В соответствии со схемой 600 передачи фрейма данных, L2GW 622, находящийся в Loc 3 (GW3), может поддерживать 802.1ah MAC-B-MAC, используя поле Ether Type, для обозначения, что для внутреннего фрейма требуется трансляция адреса MAC. GW3 может воплощать схему передачи фрейма данных, аналогично схеме 400 передачи фрейма данных для передачи данных во второй L2GW 622 Loc 2 (GW2), используя адрес MAC GW2 во внешнем заголовке MAC. Таким образом, GW2 может декапсулировать внешний заголовок MAC и выполнять трансляцию адреса MAC, как описано выше (для схемы 400 направления фрейма данных).

Например, GW3 может принимать фрейм 640, например, фрейм Ethernet, из хост-устройства А после перемещения в Loc 3. Фрейм 640 может быть предназначен для хост-устройства В в Loc 2. Фрейм 640 может содержать MAC-DA 642 для предыдущего L2GW 622 (GW1) Loc I (L2GW-Loc1), MAC-SA 644 для хост-устройства A (MAC для A), IP-DA 646 для хост-устройства В (В), IP-SA 648 для хост-устройства А (А) и полезную нагрузку. GW3 может затем добавлять внешний заголовок MAC к фрейму 640, для получения внутреннего фрейма 660. Внешний заголовок MAC может содержать MAC-DA 662 для GW2 (L2GW-Loc2), MAC-SA 664 для GW1 (L2GW-Loc1), и Type Ether 666, который обозначает, что для внутреннего фрейма 660 не требуется трансляция адреса MAC. Внутренний фрейм 660 также может содержать MAC-DA 668 для хост-устройства В (MAC для В) и MAC-SA 670 для хост-устройства A (MAC для А). Внутренний фрейм 660 может затем быть передан в сеть 610 обслуживания в GW2, которая может обрабатывать внешний заголовок MAC для трансляции адреса MAC во фрейме. При этом GW2 может получить второй фрейм 680, который может содержать MAC-DA 682 для хост-устройства В (MAC для В), MAC-SA 684 для хост-устройства A (MAC для А), и полезную нагрузку. Второй фрейм 680 может затем быть передан в хост-устройство В в Loc 2.

Кроме того, хост-устройство В может переместиться из Loc 2 в другое местоположение, например, Loc 4 (не показано). Если GW2 узнал, что хост-устройство В переместилось из Loc 2 в Loc 4, тогда GW2 может использовать адрес MAC другого L2GW 622 в Loc 4 (GW4), как MAC-DA, во внешнем заголовке MAC, как описано выше. Если GW2 не узнал, что хост-устройство В переместилось из Loc 2 в Loc 4, тогда фрейм может быть передан с помощью GW2, без внешнего заголовка MAC. Также, фрейм может быть потерян, например, в сети 610 обслуживания. Фрейм может быть потерян временно, до тех пор, пока фрейм не будет повторно передан с помощью GW2, после того, как хост-устройство В передаст объявление о его новом местоположении GW2 или Loc 2.

На фиг.7 иллюстрируется вариант осуществления взаимно соединенных сайтов уровня 2я (или районов) 700, которые могут воплощать механизм, аналогичный виртуальным сетям уровня 2, как описано выше. Взаимно соединенные сайты 700 уровня 2 могут содержать множество L2GWs 722, соединенных множеством граничных или краевых узлов 712. Краевые узлы, например, краевые маршрутизаторы могут принадлежать сети обслуживания, например, сети уровня 3. Взаимно соединенные сайты 700 уровня 2 также могут содержать множество промежуточных коммутаторов 724, соединенных с L2GWs 722, и множество VM 726, соединенных с промежуточными коммутаторами 724. L2GWs 722, промежуточные коммутаторы 724 и VM 726 могут поддерживать множество поднаборов, которые соответствуют множеству уровней 2 (L2) областей адресов. Компоненты взаимно соединенных сайтов 700 уровня 2 могут быть размещены, как показано на фиг.7, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

Каждая область адреса L2 может использовать механизм управления границей, такой как механизм 300 управления границей, где промежуточные коммутаторы 724 и VMs 726 в пределах каждой области уровня 2 знают о локальных MAC-адресах, но не MAC-адреса и VLAN для хост-устройств, серверов и/или VM 726 в других областях адреса L2. Однако, хост-устройства, серверы и/или VM 726 могут связываться друг с другом, как в одиночной сети с плоским уровнем 2, не имея никакой информации о других областях уровня 2. Области уровня 2 могут быть взаимно соединены друг с другом через граничные или краевые узлы 712, которые могут быть взаимно соединены через главную сеть или сеть провайдера услуги (не показана). Области адреса L2 могут быть расположены на одном сайте DC или на множестве географических сайтов. Архитектура взаимно соединенных сайтов 700 уровня 2 среди множества сайтов (мест положения) также может называться здесь расширением уровня 2 для множества сайтов, взаимно соединенных с сетью обслуживания (уровень 3, 2, 5, 2 или другие сети), сети псевдо уровня 2 по сайтам, взаимно соединенным сетью обслуживания, виртуальным уровнем 2, или сетью псевдоуровня 2.

На фиг.8 иллюстрируется один вариант осуществления расширения 800 уровня 2 по множеству сайтам взаимно соединенным с сетью обслуживания. Расширение 800 уровня 2 может содержать множество L2GWs 822, соединенных с множеством граничных или краевых узлов 812, которые могут принадлежать провайдеру услуги или базовой сети (не показана). Расширение 800 уровня 2 также может содержать множество промежуточных коммутаторов 824, соединенных с L2GWs 822, и множество хост-устройств/серверов/VM 826, соединенных с промежуточными коммутаторами 824. Промежуточные коммутаторы 824 и хост-устройства/серверы/VM 826 могут быть отделены от или расположены в виде множества областей адреса L2. Например, один из сайтов L2 обозначен кругом из пунктирной линии на фиг.8. Промежуточные коммутаторы 824 L2GW 822 и хост-устройства/серверы/VM 826 могут соответствовать сети уровня 2 в одном или множеств мест положений DC. Компоненты расширения 800 уровня 2 могут быть размещены, как показано на фиг.8, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На фиг.9 показана схема варианта осуществления сети 900 псевдоуровня 2 по множеству мест размещения. Сети 900 псевдоуровня 2 могут представлять собой механизм для соединения уровня 2 по множеству мест положения, например, географических мест положения или DC для установления одной плоской сети уровня 2. Сети 900 псевдо уровня 2 могут содержать сеть провайдера услуги или базовую сеть 910 и множество областей 920 сети уровня 2, которые могут быть соединены с сетью провайдера услуги или базовой сетью 910 через множество краевых узлов 912, таких как краевые маршрутизаторы. Каждый сайт 920 уровня 2 может быть расположен в разных сайтах или местоположениях (этаж или зона) DC и может содержать множество L2GWs 922, соединенных с соответствующими краевыми узлами 912, и множество промежуточных переключателей 924, соединенных с соответствующими L2GW 922. Промежуточные переключатели 924 также могут быть соединены с множеством хост-устройств/серверов/VM (не показаны). Компоненты 2 сети 900 псевдоуровня могут быть расположены, как показано на фиг.9, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На фиг.10 иллюстрируется вариант осуществления механизма 1000 ограничения адреса области. Механизм 1000 ограничения адреса области может использоваться в сетях псевдоуровня 2 по множеству сайтов, для обработки разрешения адресов между разными сайтами уровня 2. Сети псевдоуровня 2 по множеству сайтов могут содержать сеть 1010 обслуживания и множество сайтов 1020 сети уровня 2, которые могут быть соединены с сетью 1010 обслуживания через множество краевых узлов 1012. Сайты 1020 уровня 2 могут быть расположены в одном и том же или на разных сайтах DC, и могут содержать множество L2GW 1022, соединенных с соответствующими краевыми узлами 1012, и множество промежуточных коммутаторов 1024, соединенных с соответствующими L2GW 1022. Промежуточные коммутаторы 1024 также могут быть соединены с множеством хост-устройств/серверов/VM 1026. Компоненты сетей псевдо уровня 2 могут быть размещены так, как показано на фиг.10, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

В частности, адрес MAC L2GW 1022 на одном сайте 1020 уровня 2 может использоваться, как прокси для всех или множества хост-устройств за пределами этого локального сайта. В первом варианте выбора (вариант выбора 1) MAC-адрес для локального L2GW 1022 в сайте 1020 уровня 2 может использоваться, как прокси для хост-устройств в других сайтах 1020 сети уровня 2. В этом сценарии только адреса локальных хост-устройств могут быть изучены промежуточными коммутаторами 1024 и хост-устройствами/серверами/VM 1026 в одних и тех же локальных сайтах 1020 уровня 2. MAC-адреса внешних L2GW 1022 в других сайтах 1020 уровня 2 могут не быть открыты локальных сайтов 1020 уровня 2.

В качестве альтернативы, во втором варианте выбора (вариант выбора 2), адреса MAC L2GW 1022 в удаленном сайте 1020 уровня 2 могут использоваться, как прокси для всех хост-устройств, находящихся на соответствующем сайте. В таком варианте выбора адреса MAC внешних L2GW 1022 на других сайтах 1020 уровня 2 могут быть изучены на каждом сайте 1020 уровня 2. При таком варианте выбора адреса MAC удаленных L2GW 1022, которые соответствуют сайту 1020 уровня 2, где находятся целевые хост-устройства, могут быть возвращены в ответ на запросы ARP/ND локальных хост-устройств, например, когда хост-устройство пытается связаться с хост-устройством в удаленном сайте 1020 уровня 2 и запрашивает адрес внешнего хост-устройства. Вариант 2 выбора может иметь некоторые преимущества по сравнению с вариантом 1 выбора в некоторых ситуациях.

В соответствии с механизмом 1000 ограничения адресов области, каждый L2GW 1022 может знать обо всех адресах хост-устройств в одном и том же локальном сайте 1020 уровня 2 L2GW 1022, например, используя схему инверсного ARP или другие способы. Каждый L2GW 1022 также может информировать другие L2GW 1022 в других сайтах 1020 уровня 2, сообщая IP-адреса хост-устройств и соответствующие VLAN (или VID).

Для разрешения адресов в пределах одного уровня 2 между разными сайтами, запрос ARP/ND может быть передан из первого хост-устройства 1026 (host А) в соответствующий локальный L2GW 1022 на первом сайте (Site I). Host А может передавать запрос ARP/ND, для получения адреса MAC о втором хост-устройстве 1026 (host В) на втором сайте (Site 2). Если локальный L2GW 1022 имеет запись для host В для VLAN, например, IP-адрес host В в одной и той же VLAN, локальный L2GW 1022 может отвечать на запрос ARP, передавая свой собственный адрес MAC (вариант 1 выбора), или адрес MAC второго L2GW 1022, ассоциированного с хост-устройством В на сайте 2 (вариант 2 выбора) в хост-устройство А. Запрос ARP/ND, переданный из одного сайта, например, сайта 1, может быть перехвачен локальным L2GW 1022, и не может быть передан (локальным L2GW 1022) в другой сайт.Если локальный L2GW 1022 не содержит запись для host В в той же самой VLAN, локальный L2GW 1022 может предполагать, что host В не существует, и может не передавать ответ в host A. L2GW 1022 каждого сайта могут передавать обновления локальных IP-адресов их хост-устройств и их соответствующих VLAN на регулярной или периодической основе в свои одноранговые устройства L2GW 1022. При этом возможно, что некоторые L2GW 1022 не принимали IP-адреса вновь сконфигурированных хост-устройств в их других местах положения. Как правило, хост-устройство А может передавать запрос ARP/ND многократно (?? повторно), если ответ не будет принят.

На фиг.11 иллюстрируется вариант осуществления схемы 1100 передачи фрейма данных, которая может использоваться для передачи сообщений или фреймов в пределах сети одного псевдоуровня 2 по множеству сайтов. Сеть псевдоуровня 2 по множеству сайтов может содержать провайдера услуги базовой сети 1110 и множество областей 1120 сети уровня 2, которые могут быть соединены с сетью провайдера услуги или базовой сетью 1110 через множество краевых узлов 1112. Области 1120 сети уровня 2 могут быть расположены в одном или больше сайтах DC или в местах положения, и могут содержать множество L2GW 1122, соединенных с соответствующими краевыми узлами 1112, и множество промежуточных коммутаторов 1124, соединенных с соответствующими L2GW 1122. Промежуточные коммутаторы 1124 могут быть также соединены с множеством хост-устройств/серверов/VM 1126. Компоненты сети псевдоуровня 2 могут быть расположены, как показано на фиг.11, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На основе схемы 1100 передачи фрейма данных, первый L2GW 1022 (GW1) может принимать первый фрейм 1140, например, фрейм Ethernet, из первого хост-устройства 1126 (host А) в первой области 1120 адреса (область 1). Первый фрейм 1140 может быть предназначен для второго хост-устройства 1126 (host В) во второй области 1120 адреса (область 2). Первый фрейм 1140 может содержать MAC-DA 1142 для L2GW 1122 (GW). Host А может получать MAC-адрес GW в ответе ARP из GW1, возвращаемом на запрос ARP для host В. GW может соответствовать GW1 в области 1 (в соответствии с вариантом 1 выбора) или второму L2GW 1122 (GW2) в область 2 (в соответствии с вариантом 2 выбора). Первый фрейм 1140 также может содержать MAC-SA 1144 для host A (MAC для A), IP-DA 1146 для host В (В), IP-SA 1148 для host А (А) и полезную нагрузку.

На основе варианта 1 выбора, GW1 может принимать первый фрейм 1140, сверять VID/IP-адрес места назначения host В (например, как обозначено IP-DA 1146 для host В), и заменять MAC-DA 1142 для GW в первом фрейме 1140 MAC-DA 1162 для GW2 во внутреннем фрейме 1160. GW1 также может заменять MAC-SA 1144 для host A (MAC A) в первом фрейме 1140 на MAC-SA 1164 для GW1 во внутреннем фрейме 1160. Внутренний фрейм 1160 также может содержать IP DA 1166 для host В (В), IP-SA 1168 для host А (А) и полезную нагрузку. GW1 может передавать внутренний фрейм 1160 в область 2 через провайдера услуги или базовую сеть 1110. На основе варианта 2 выбора, GW1 может отфильтровывать все фреймы данных, предназначенные для GW2, или любого другого внешнего L2GW 1122, например, на основе списка доступа, заменять адреса источника фреймов данных (MAC-SA) 1144 для хост-устройства А или MAC для А) на собственный адрес MAC GW1, и затем передавать фреймы данных, на основе MAC места назначения.

GW2 может принимать внутренний фрейм 1160 и обрабатывать внутренний фрейм 1160 для трансляции адреса MAC фрейма. На основе варианта 1 выбора GW2 может принимать внутренний фрейм 1160, сверять VID/IP-адрес назначения для host В (например, как обозначено IP-DA 1166 для host В) и заменять MAC-DA 1162 для GW2 во внутреннем фрейме 1160 на MAC-DA 1182 для host В (MAC для В) во втором фрейме 1180. GW2 может также заменять MAC-SA 1164 для GW1 во внутреннем фрейме 1160 на MAC-SA 1184 для GW2 во втором фрейме 1180. Второй фрейм 1180 также может содержать IP-DA 1186 для host В (В), IP-SA 1188 для host А (А) и полезную нагрузку. GW2 может затем передавать второй фрейм 1180 в host В места назначения. На основе варианта 2 выбора, GW2 может только сверять VID/IP-адрес места назначения host В (например, как обозначено IP-DA 1166 для host В) и заменять MAC-DA 1162 на GW2 с DA MAC 1182 для host В (MAC для В) во втором фрейме 1180. Однако GW2 может для этого содержать MAC-SA 1164.

Как описано выше, GW2 может выполнять трансляцию адреса MAC, используя IP-DA 1166 для host В во внутреннем фрейме 1160, для поиска соответствующего MAC- DA 1182 для host B (MAC для В) во втором фрейме 1180. Такой этап трансляции MAC может потребовать приблизительное такое же количество работы, как и в схеме NAT, например, для трансляции открытого адреса IP в частный адрес IP. Трансляция адреса MAC в схеме 1100 передачи фрейма данных может быть основана на использовании host IP-адресов для поиска соответствующего адреса MAC, в то время как схема NAT основана на сессии TCP.

На фиг.12 иллюстрируется вариант осуществления другой схемы 1200 передачи фрейма данных, которая может использоваться для передачи сообщений или фреймов между сетями псевдоуровня 2 по множеству областей адреса. В частности, сети псевдоуровня 2 могут быть взаимно соединены через сеть IP/MPLS. Сети псевдоуровня 2 в областях адресов могут содержать IP сети /сети 1210 MPLS и множество областей 1220 сети уровня 2, которые могут быть соединены с сетью 1210 IP/MPLS через множество краевых узлов 1212. Сеть 210 IP/MPLS может предоставлять IP услугу для поддержки внутренней области между областями адреса, например, областями 1220 сети уровня 2. Области 1220 сети уровня 2 могут быть расположены в одном или больше DC сайтах или местах положения и могут содержать множество L2GW 1222, соединенных с соответствующими краевыми узлами 1212, и множество промежуточных коммутаторов 1224, соединенных с соответствующими L2GW 1222. Промежуточные коммутаторы 1224 также могут быть соединены с множеством хост-устройств/серверов/VM 1226. Компоненты сетей псевдоуровня 2 могут быть размещены, как показано на фиг.12, и могут быть аналогичны соответствующим компонентам виртуальной сети 200 уровня 2.

На основе схемы 1200 передачи фрейма данных первый L2GW 1022 (GW1) может принимать первый фрейм 1240, например, фрейм Ethernet, из первого хост-устройства 1226 (host А) в первой области адреса (область 1). Первый фрейм 1240 может быть предназначен для второго хост-устройства 1226 (host В) во второй области адреса (область 2). Первый фрейм 1240 может содержать MAC-DA 1242 для L2GW 1222 (GW). Host A может получать адрес MAC GW в отклике ARP из GW1 в ответ на запрос ARP для host В. GW может соответствовать GW1 в области 1 (в соответствии с вариантом 1 выбора) или второму L2GW 1222 (или GW2) в области 2 (в соответствии с вариантом 2 выбора). Первый фрейм 1240 также может содержать MAC-SA 1244 для host A (MAC для А), в IP-DA 1246 для host В (В), IP-SA 1248 для host А (А) и полезную нагрузку.

GW1 может принимать первый фрейм 1240 и обрабатывать этот фрейм на основе одного из двух вариантов выбора. В первом варианте выбора GW1 может принимать первый фрейм 1240 и добавлять IP заголовок для получения внутреннего фрейма 1250. IP заголовок может содержать IP-DA 1251 для GW2 и IP-SA 1252 для GW1. GW1 может также обрабатывать первый фрейм 1240, аналогично схеме 1100 передачи фрейма данных для получения во внутреннем фрейме 1250 MAC-DA 1253 для GW2, MAC-SA 1254 для GW1, IP-DA 1256 для host В (В) и IP-SA 1257 для host А (А). GW1 может передавать внутренний фрейм 1250 GW2 через сеть 1210IP/MPLS. GW2 может принимать внутренний фрейм 1250 и обрабатывать этот внутренний фрейм 1250, аналогично схеме 1100 передачи фрейма данных для получения второго фрейма 1280, который содержит MAC-DA 1282 для host В (MAC для В), MAC-SA 1284 для GW1 (в соответствии с вариантом 1 выбора) или GW2 (в соответствии с вариантом 2 выбора), IP-DA 1286 для host В (В), IP-SA 1288 для host А (А) и полезную нагрузку. GW2 может затем передавать второй фрейм 1250 в host В.

Во втором варианте выбора GW1 может принимать первый фрейм 1240 и заменять MAC-DA 1242 для GW в первом фрейме 1240 на IP-DA 1262 для GW2 во внутреннем фрейме 1260. GW1 также может заменять MAC-SA 1244 для host A (MAC для А) в первом фрейме 1240 на IP-SA 1264 для GW1 во внутреннем фрейме 1260. Внутренний фрейм 1260 также может содержать IP-DA 1266 для host В (В), IP-SA 1268 для host А (А) и полезную нагрузку. GW1 может передавать внутренний фрейм 1260 GW2 через сеть 1210 IP/MPLS. GW2 может принимать внутренний фрейм 1260 и заменять IP-DA 1162 для GW2 во внутреннем фрейме 1260 на MAC-DA 1282 для host В (MAC для В) во втором фрейме 1280. GW2 также может заменять IP-SA 1264 для GW1 во внутреннем фрейме 1260 на MAC-SA 1284 для GW2 (в соответствии с вариантом 1 выбора) или GW1 (в соответствии с вариантами 2 выбора) во втором фрейме 1280. Второй фрейм 1280 также может содержать IP-DA 1286 для host В (В), IP-SA 1288 для host А (А) и полезную нагрузку. GW2 может затем перенаправлять второй фрейм 1250 в host В.

В представленном выше расширении псевдоуровня 2 или в сетях среди множества областей, каждый L2GW может быть выполнен с возможностью отображения IP-MAC всех хост-устройств в каждой VLAN в L2GW соответствующих областей адреса. Каждый L2GW может также передавать IP-адреса всех хост-устройств в каждой VLAN в соответствующей области адреса в другие L2GW в других областях адресов на регулярной или периодической основе. Таким образом, L2GWs в областях адресов могут получать IP-адреса хост-устройств в каждой из VLAN для всех областей адреса сети псевдоуровня 2. MAC-адреса хост-устройств в каждой области адреса могут не быть переданы локальными L2GW в L2GW областей других адресов, которые могут, по существу, уменьшить размер данных, обмениваемых между L2GW. Однако L2GWs разных областей адресов могут выполнить обмен между собой MAC-адресами, соответствующими не-IP приложениям, например, если количество не-IP приложений относительно мало. BGP или аналогичный способ может использоваться для обмена информацией адреса, включая в себя обновления, между L2GWs между областями адресов.

В таблице 2 иллюстрируется пример отображения хост-адресов в соответствующие MAC-адреса L2GW в сетях псевдоуровня 2. Множество MAC-адресов L2GW (например, GW-A MAC и GW-B MAC) могут быть отображены на множество соответствующих хост-адресов. Каждый MAC-адрес L2GW может быть отображен на множество хост IP (или MAC) адресов во множестве VLAN (например, VID-1, VID-2, VID-n, …), которые могут находиться в той же области адреса.

Таблица 2 Отображение IP MAC L2GW VLAN Хост-устройство GW-A MAC VID-1 IP адреса всех хост-устройств в данной VLAN (IP Prefix) MAC адреса (не-IP приложения) VID-2 IP адреса всех хост-устройств в данной VLAN (IP Prefix) MAC адреса (не-IP приложения) VID-n IP адреса всех хост-устройств в данной VLAN (IP Prefix) MAC адреса (не-IP приложения) GW-B MAC    

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

На фиг.13 иллюстрируется вариант осуществления другой схемы 1300 передачи фрейма данных, которая может использоваться для передачи сообщений или фреймов между сетями псевдоуровня 2 по множеству областей адресов и мест расположения. Схема 1300 передачи фрейма данных может быть основана на варианте 1 выбора, описанном выше, и может использоваться для передачи фреймов из хост-устройства, которое перемещается из предыдущего местоположения в новое местоположение в сетях псевдоуровня 2, и поддерживает один и тот же изученный адрес MAC для второго хост-устройства. Сети псевдоуровня 2 могут содержать провайдера услуги или базовой сети 1310 и множество областей 1320 сети уровня 2, которые могут быть соединены с провайдером услуги или базовой сетью 1310 через множество краевых узлов 1112. Области 1320 сети уровня 2 могут быть расположены во множестве DC сайтов или мест положения, и могут содержать множество 1322 L2GW, соединенных с соответствующими краевыми узлами 1312, и множество промежуточных коммутаторов 1324, соединенных с соответствующими L2GW 1322. Промежуточные коммутаторы 1324 также могут быть соединены с множеством хост-устройств/серверов/VM 1326. Компоненты сетей псевдоуровня 2 могут быть размещены, как показано на фиг.13, и могут быть аналогичны соответствующим компонентам сети 200 виртуального уровня 2.

На основе схемы 1300 передачи фрейма данных, GW3 может принимать первый фрейм 1340, например, Фрейм Ethernet, из первого хост-устройства 1326 (host А) после перемещения из Loc 1 в Loc 3. Фрейм 1340 может быть предназначен для второго хост-устройства 1326 (host В) в Loc 2. Первый фрейм 1340 может содержать MAC-DA 1342 для GW1 в Loc I, MAC-SA 1344 для host A (MAC для A), IP-DA 1346 для host В (В), IP-SA 1348 для host А (А) и полезную нагрузку. GW3 может обрабатывать первый фрейм 1340 и заменять MAC-SA 1344 на host A (MAC для А) в первом фрейме 1340 на MAC-SA 1354 для GW3 в первом внутреннем фрейме 1350, например, аналогично схеме 1100 передачи фрейма данных. Первый внутренний фрейм 1350 также может содержать MAC-DA 1352 для GW1, IP-DA 1356 для host В (В), IP-SA 1358 для host А (А) и полезную нагрузку. GW3 может передавать первый внутренний фрейм 1350 в Loc 1 через провайдера услуги или базовую сеть 1310.

GW1 может принимать первый внутренний фрейм 1350, сверять VID/IP-адрес места назначения host В (например, как обозначено IP-DA 1356 для host В), и заменять MAC-DA 1352 в GW1 в первом фрейме 1340 на MAC-DA 1362 для GW2 во втором внутреннем фрейме 1360. Второй внутренний фрейм 1360 также может содержать MAC-SA 1364 для GW3, IP-DA 1366 для host В (В), IP-SA 1368 для host А (А) и полезную нагрузку. GW1 может передавать второй внутренний фрейм 1360 в Loc 2 через провайдера услуги или базовую сеть 1310.

GW2 может принимать второй внутренний фрейм 1360 и обрабатывать этот второй внутренний фрейм 1360 для трансляции MAC-адреса фрейма. GW2 может принимать второй внутренний фрейм 1360, сверять VID/IP-адрес места назначения host В (например, как обозначено IP-DA 1366 для host В), и заменять MAC-DA 1362 для GW2 во внутреннем фрейме 1360 на MAC-DA 1382 для host В (MAC для В) во втором фрейме 1380. GW2 может также заменять MAC- SA 1364 для GW3 во втором внутреннем фрейме 1360 на MAC-SA 1384 для GW2. GW2 может затем передавать второй фрейм 1380 в хост-устройство В места назначения.

Кроме того, хост-устройство В может двигаться из Loc 2 в другое местоположение, например, Loc 4 (не показано). Если GW2 определило, что хост-устройство В переместилось из Loc 2 в Loc 4, то GW2 может передавать обновления своим собственным одноранговым устройствам (другие L2GW 1322, находящиеся в других местах положения). Когда L2GW 1322 в Loc 4 (GW4) определяет, что host В добавлен к его области, GW4 также может обновить свои одноранговые устройства. При этом каждая L2GW 1322 может иметь обновленную информацию адреса о host В. Если L2GW 1322 не изучила, что host В переместился из Loc 2 в Loc 4, то L2GW 1322 может все еще передавать фрейм, предназначенный для host В из локальных хост-устройств в Loc 2. В свою очередь, GW2 может принимать и передать фрейм в Loc 2, где фрейм теряется после удаления host В из Loc 2. Фрейм может быть временно потерян до тех пор, пока фрейм не будет повторно подан в L2GW 1322 после анонсирования host В его нового местоположения L2GW 1322.

На фиг.14 иллюстрируется вариант осуществления другой схемы 1400 передачи фрейма данных, которая может использоваться для передачи сообщений или фреймов между сетями псевдоуровня 2 по множеству сайтов или областей. Схема 1400 передачи фрейма данных может быть основана на варианте 2 выбора, описанном выше, и может использоваться для передачи фреймов из хост-устройства, которое перемещается из предыдущего местоположения в новое местоположение в сетях псевдоуровня 2 и поддерживает тот же изученный адрес MAC для второго хост-устройства. Сети псевдоуровня 2 могут содержать сеть 1410 обслуживания и множество областей 1420 сети уровня 2, которые могут быть соединены с сетью 1410 обслуживания через множество краевых узлов 1412. Области 1420 сети уровня 2 могут быть размещены во множестве сайтов или в местах положения DC и могут содержать множество L2GW 1422, соединенных с соответствующими краевыми узлами 1412, и множество промежуточных коммутаторов 1424, соединенных (прямо или опосредованно) с соответствующими L2GW 1422. Промежуточные коммутаторы 1424 также могут быть соединены (прямо или опосредованно) с множеством хост-устройств/серверов/VM 1426. Компоненты сетей псевдоуровня 2 могут быть размещены, как показано на фиг.14, и могут быть аналогичны соответствующим компонентам сети 200 виртуального уровня 2.

На основе схемы 1400 передачи фрейма данных, GW3 может принимать первый фрейм 1440, например, фрейм Ethernet, из первого хост-устройства 1426 (host А) после перемещения из Loc 1 в Loc 3. Фрейм 1440 может быть предназначен для второго хост-устройства 1426 (host В) в Loc 2. Первый фрейм 1340 может содержать MAC-DA 1442 для GW2 в Loc 2, MAC-SA 1444 для host A (MAC для A), IP-DA 1446 для host В (В), IP-SA 1448 для host А (А) и полезную нагрузку. GW3 может обрабатывать первый фрейм 1440 и заменять MAC-SA 1444 для host A (MAC для А) в первом фрейме 1440 на MAC-SA 1464 для GW3 во внутреннем фрейме 1460, например, аналогично схеме 1100 передачи фрейма данных. Внутренний фрейм 1460 также может содержать MAC-DA 1462 для GW2, IP-DA 1466 для host В (В), IP-SA 1468 для host А (А) и полезную нагрузку. GW3 может передавать внутренний фрейм 1460 Loc 2 через провайдер услуги или главную сеть 1410.

GW2 может принимать внутренний фрейм 1460 и обрабатывать этот внутренний фрейм 1460 для трансляции MAC адресов фрейма. GW2 может принимать внутренний фрейм 1460, выполнять поиск VID/IP-адреса места назначения для host В (например, как обозначено IP-DA 1466 для host В (В), и заменять MAC-DA 1462 на GW2 во внутреннем фрейме 1460 на MAC-DA 1482 для host В (MAC для В) во втором фрейме 1480. Внутренний фрейм 1460 также может представлять собой MAC-SA 1484 для GW3. GW2 может затем передавать второй фрейм 1480 в хост-устройство В места назначения.

Кроме того, хост-устройство В может перемещаться из Loc 2 в другое местоположение, например, Loc 4 (не показано). Если GW2 определила, что host В переместилось из Loc 2 в Loc 4, тогда GW2 может передавать обновления своим одноранговым устройствам (другим L2GW 1322, в других местах положения). Когда L2GW 1322 в Loc 4 (GW4) определяет, что host В добавлен к его области, GW4 также может обновить свои одноранговые устройства. В таком случае, каждая L2GW 1322 может иметь обновленную адресную информацию о host В. Если L2GW 13222 не определила, что host В переместилось из Loc 2 в Loc 4, тогда L2GW 1322 все еще может передавать фрейм, предназначенный для host В, из локального хост-устройства в Loc 2. В свою очередь, GW2 может принимать и передавать фрейм в Loc 2, где этот фрейм теряется, поскольку host В переместилось из Loc 2. Фрейм может быть потерян временно до тех пор, пока фрейм не будет снова передан в L2GW 1322 после того, как host В объявит о своем новом местоположении для L2GW1322.

Расширение или сети псевдоуровня 2, описанные выше, могут поддерживать разрешение адресов в каждой из областей адреса и могут использовать механизм, для поддержания L2GW обновленной в настоящее время с IP-адресами всех хост-устройств в их областях/местах положения. Разрешение адресов и обновление IP-адреса могут быть воплощены в одном из двух сценариев. Первый сценарий соответствует в случае, когда хост-устройство или VM, выполнено с возможностью передавать невызванные сообщения ARP, после добавления или после перемещения в сеть. Второй сценарий соответствует случаю, когда хост-устройство или VM, которое было добавлено к сети или переместилось в сеть, не передает объявления ARP. Эти два сценария могут обрабатываться, как описано в выше в сетях виртуального уровня 2.

Сети виртуального уровня 2 и, аналогично, сети псевдоуровня 2, описанные выше, могут поддерживать определение адресов в каждом местоположении/области и механизм для поддержания каждой L2GW обновленной в данный момент времени IP-адресом ее локальных хост-устройств, в ее местоположении/области. В одном сценарии, когда хост-устройство а или VM добавляют к сети, это хост-устройство или VM может передавать объявление ARP, такое как невызванное сообщение ARP, в свою сеть уровня 2 или в локальную область. В другом сценарии хост-устройство или VM, добавленные к сети, могут не передавать объявление ARP.

В первом сценарии новая VM в сети уровня 2 или в местоположении/области могут передавать невызванные сообщения ARP в L2GW. Когда L2GW принимает невызванные сообщение ARP, L2GW может обновлять ее локальный IPAddrTable, но может не передавать невызванное сообщение ARP в другие места положения/области или сети уровня 2. Кроме того, L2GW может использовать таймер для каждой записи в IPAddrTable, для обработки случая отключения или удаления хост-устройства из местоположения/области. В случае, когда величина подсчета таймера для записи практически будет исчерпана, L2GW может передать ARP (например, используя одноадресную передачу) в хост-устройство для данной записи. Передача ARP в виде одноадресного сообщения, вместо широковещательной передачи ARP, может исключить лавинное распространение области локального уровня 2 для хост-устройства и L2GW. Когда хост-устройство перемещается из первого местоположения во второе местоположение, L2GW может принимать обновленное сообщение из первого местоположения и/или второго местоположения. Если L2GW детектирует, что хост-устройство существует, как в первом местоположении, так и во втором местоположении, L2GW может передавать локальное сообщение ARP в первое местоположение для проверки, что хост-устройство не существует больше в первом местоположении. После определения, что хост-устройство больше не присутствует в первом местоположении, например, если не будет детектирован ответ на сообщение ARP, L2GW может, соответственно, обновить свой локальный IPAddrTable. Если L2GW принимает ответ для сообщения ARP для его собственного местоположения, тогда может использоваться механизм множественной адресации MAC для BGP.

Во втором сценарии новое хост-устройство в определенном местоположении может не передавать объявление ARP. В этом случае, когда для приложения (например, в хост-устройстве) требуется разрешить MAC-адрес для хост-устройства IP, это приложение может передать запрос ARP, который может быть передан в режиме широковещательной передачи в местоположении. Запрос ARP может быть перехвачен L2GW (или коммутатором наверху стойки (ToR)), например, воплощая функцию прокси ARP. В относительно крупных DC L2GW может не иметь возможности обрабатывать все запросы ARP. Вместо этого, множество делегатов L2GW (например, коммутаторов ToR) могут перехватывать объявления ARP. L2GW может проталкивать IP-адреса (например, краткую сводку IP-адресов), которые были определены, из других мест положений своим соответствующих делегатам (коммутаторы ToR). Делегаты могут затем перехватывать запросы ARP из хост-устройств или локальных серверов. Если IP-адрес в ARP запросе из хост-устройства или сервера присутствует в IPAddrTable в L2GW, такая L2GW может возвращать ответ ARP с MAC-адресом L2GW в хост-устройство или сервер, без перенаправления переданного в режиме широковещательной передачи запроса ARP куда-либо дальше. Для не-IP приложений, например, приложений, которые работают непосредственно через Ethernet без IP, приложения могут использовать адреса MAC, как DA, при передаче данных. He-IP приложения не могут передавать сообщение ARP перед передачей фреймов данных. Фреймы данных могут быть переданы с использованием неизвестной лавинной передачи или Протокола регистрации множества MAC (MMRP).

В одном сценарии приложение (например, в хост-устройстве) может передавать невызванное сообщение ARP, после присоединения к одной из взаимно соединенных сетей уровня 2 в одном местоположении, для получения MAC-адреса для целевого IP-адреса. Когда L2GW или ее делегат (например, коммутатор ToR) могут принимать запрос ARP и проверять его таблицу IP хост-устройств. Если IP-адрес будет найден в таблице, L2GW может передать ответ ARP в приложение. L2GW может передавать свой адрес MAC в ответе, если целевой IP-адрес соответствует IP хост-устройства в другом местоположении. Если IP-адрес не будет найден, ответ не может быть передан из L2GW, которая может поддерживать текущие или последние обновленные IP-адреса хост-устройств во всех местах положения. В относительно крупных DC множество L2GW могут использоваться, например, в одном и том же местоположении, где каждая L2GW может обрабатывать поднабор VLAN. При этом каждой L2GW может потребоваться поддерживать поднабор IP-адресов, которые содержат IP-адреса хост-устройств соответствующей VLAN.

В случае достаточно крупных DC, например, которые содержат десятки тысяч VM, для одного узла может быть трудно обработать все ARP запросы и/или невызванные сообщения ARP. В этом случае можно рассмотреть несколько схем. Например, множество узлов или L2GW может использоваться для обработки разных поднаборов VLAN в пределах DC, как описано выше. Кроме того или в качестве альтернативы, множество делегатов могут быть назначены для L2GW в каждом местоположении. Например, может использоваться множество коммутаторов ToR или коммутаторов доступа. Каждый делегат L2GW может быть ответственным за перехват невызванных сообщений ARP по своим соответствующим нисходящим каналам передачи данных или в форме протокола связываний порта. Делегаты могут передавать консолидированный список адресов (AddressList) в свои L2GW. L2GW также может проталкивать свои изученные списки адресов IP из других местоположений своим делегатам. Если существует множество L2GW в местоположении, которые ответственны за разные поднаборы VLAN, этим делегатам может потребоваться передавать множество консолидированных сообщений, которые содержат каждый AddressLists во VLAN, ассоциированных с соответствующими L2GW.

При сравнении со схемой Cisco OTV, при использовании сети виртуального уровня 2, описанной выше, можно существенно уменьшить размер таблиц переадресации в промежуточных коммутаторах в каждом местоположении. Коммутаторы в одном местоположении могут не потребоваться для изучения MAC-адресов IP хост-устройств в других местах положения, например, предполагая, что большинство хост-устройств работает в IP приложениях. Такая схема также позволяет существенно уменьшить размер информации адреса, обмен которой осуществляется между L2GW. Например, подсеть, которая может содержать тысячи VM, может отображать адрес MAC L2GW. Иерархическая схема уровня 2 для виртуальной сети уровня 2 может использовать стандарт 802.1ah, который может поддерживаться коммерческими наборами микросхем Ethernet, в то время, как в схеме Cisco используется собственная инкапсуляция IP. Обе схемы могут использовать адрес устройства шлюза в местоположении однорангового устройства (L2GW), в качестве внешнего адреса места назначения. Иерархическая схема уровня 2 также может использовать трансляцию адресов, которая может поддерживаться текущими шлюзами IP. Однако иерархическая схема уровня 2 может использовать трансляцию адреса MAC вместо трансляции IP-адреса. При трансляции адреса MAC может потребоваться воплощение NAT на уровне несущей, которое может выполнять трансляцию адресов для десятков тысяч адресов.

В варианте осуществления VLAN могут быть охвачены множество мест положения. Таким образом, группа многоадресной передачи данных также может охватывать множество мест положения. В частности, группа многоадресной передачи может охватывать поднабор местоположений в виртуальной сети уровня 2. Например, если существует приблизительно десять местоположений в виртуальной сети уровня 2, группа многоадресной передачи может охватывать только три из десяти мест положений. Группа многоадресной передачи в пределах одного экземпляра услуги может быть выполнена системой администратора сети (NMS) или может быть установлена автоматически в Уровне 2, используя MMRP. Поскольку L2GW поддерживает 802.1ah, L2GW может иметь встроенный компонент для отображения группы многоадресной передачи клиента для соответствующих групп многоадресной передачи в базовой сети. В сценарии наихудшего случая L2GW может получать реплику фреймов данных многоадресной передачи во всех местах положения для экземпляра услуги. Например, в соответствии с данными исследований Microsoft, приблизительно один из четырех графиков может проходить через разные местоположения. Таким образом, репликация L2GW может быть проще, чем воплощение сложного механизма в ядре провайдера.

Сеть виртуального уровня 2 может поддерживать трафик широковещательной передачи, такой, как запросы ARP и/или запросы протокола конфигурации динамического хост-устройства (DHCP). Трафик широковещательной передачи может поддерживаться путем формирования множества делегатов ARP, таких как коммутаторы ToR, в каждом местоположении. Трафик широковещательной передачи также может быть поддержан путем добавления нового компонента к протоколу построения порта для делегатов, для поддержания текущих обновлений во всех хост-устройствах IP из серверов. Кроме того, L2GW может проталкивать на периодической или регулярной основе все изученные IP-адреса хост-устройств из других мест положения.

В некоторых случаях L2GW может принимать неизвестные DA. L2GW может содержать текущие обновления всех хост-устройств (или приложений) в ее местоположении и периодически или регулярно проталкивать свою информацию об адресе однорангового устройства (другие L2GW в других местах положения). Если L2GW принимает фрейм, содержащий неизвестный DA, L2GW может выполнять широковещательную передачу этого фрейма в другие места положения. Для исключения атак на сеть, предел может быть установлен для максимального количества раз, L2GW может перенаправлять или выполнять широковещательную передачу записанных неизвестных DA. L2GW может быть выполнен с возможностью изучать адреса промежуточных коммутаторов в других местах положения для исключения ошибок в адресе промежуточного коммутатора для неизвестного адреса, перед подачей этого адреса в другое местоположение. Хотя могут существовать десятки тысяч VM в каждом местоположении DC, количество коммутаторов в каждом DC может быть ограничено, такое, как количество ToR или доступов, конец коммутаторов ряда или объединения, и/или основных коммутаторов. L2GW может изучать адреса MAC всех промежуточных коммутаторов в местоположении вперед по времени, например, через модуль протокольных данных моста (BPDU) для каждого коммутатора. Сообщения могут не быть переданы непосредственно в промежуточные коммутаторы, за исключением систем администрирования или операций, и сообщений администрирования и контроля (ОАМ). Промежуточный коммутатор, который ожидает или выполнен с возможностью принимать сообщения NMS/OAM, может обеспечить возможность другим коммутаторам местоположения изучать свой адрес MAC, путем передачи автономного сообщения NMS или объявлений MMRP.

В некоторых вариантах осуществления L2GW может использовать BGP, например, вместо IS-IS, для обмена информацией адреса. Множество вариантов выбора можно использовать для управления передачами данных уровня 2 (L2). Например, опции передачи данных могут включать в себя передачу данных только на Уровне 2 с MAC и MAC, передачу данных уровня 2 для MPLS и передачу данных уровня 2 в сети уровня 3. Варианты выбора плана управления уровня 2 могут включать в себя управление сеткой уровня 2 IS-IS, статическое управление MPLS уровня 2,5, протокол распределения меток (LDP), протокол резервирования ресурсов (RSVP) - организация трафика (ТЕ) с использованием протокола внутреннего шлюза (IGP) основанный на ограничении кратчайший путь первым (CSFP) и поиск BGP. Некоторые проблемы отображения VLAN также могут быть учтены, такие как отображение VLAN-MAC, требуемое для уникальности, и являются ли VLAN соединенные мостами сети (например, VLAN-4K-) слишком малыми для DC. В таблице 3 иллюстрируется множество вариантов выбора плана управления, которые могут использоваться для плана управления уровнем 2. Варианты выбора могут быть основаны на IEEE 802.1ah, IEEE 802.1q и IEEE 802.1aq, все из которых представлены здесь по ссылке. В таблице 4 иллюстрируются некоторые из преимуществ и недостатков (за и против) вариантов выбора планом управления в таблице 2.

Таблица 3 Варианты выбора маршрута управления уровнем 2 Транспорт Плоскость управления L2 Плоскость управления MPLS IGP-OSPF/IS-IS BGP Мост магистральной линии провайдера L2 (РВВ) 802.1q 802.1ah Не применимо Пропустить отображение IP-MAC Сетка внутреннего BGP (IBGP) Сетка внешнего BGP (EBGP) VPLS (MPLS) взаимодействие с L2 для изучения MAC LDP для области RSVP-TE MPLS статично IGP для CSPF Автоматическое определение BGP конечных точек Усреднение VPLS ARP L2 через IP Только L2 с DC (802.1aq) Не применимо Удостоверение от однорангового устройства Возможности соединения с одноранговым устройством Пропустить отображение IP-MAC mapping Явно заданная многопотоковая обработка (ХМТ) Удостоверение одноранговых устройств Возможности соединения пути с одноранговым устройством Распределение IP-отображения

Таблица 4 Варианты выбора плоскости управления Транспорт Плоскость управления L2 Плоскость управления MPLS IGP-открытый кратчайший путь первым (OSPF)IS-IS BGP L2PBB Конфигурация уровня 3 отсутствует Выполнено VPLS Обработка: IS-IS пропускает адрес MAC Многопотоковая (MT)-VPN->VLAN Следовательно: эффективность для IP отображения Обработка: политики BGP автоматическая политика BGP, используемая для L2 РВВ для отображения VPLS BGP эффективно для большого количества одноранговых узлов и I-MAC отображение множества VLAN VPLS (MPLS) Изучение взаимодействия MAC с L2 За: Выполнена Против: Избыточные коды, многоадресная передача неэффективна За: CSPF для IS-IS/OSPF Быстрое схождение одноранговых узлов Топология МТ Против: неэффективно с А) большим количеством одноранговых узлов В) большим количеством отображений IP-MAC За: Некоторые из указанных выше Против: Внутренняя область BGP Взаимодействие MPLS с Уровнем 3 MPLS (L3) VPN L2 через IP Ограничена только для DC Неприменимо Удостоверение одноранговых узлов Возможность соединения одноранговых узлов Отображение IP на MAC ХМТ Удостоверение одноранговых узлов Возможность соединения с путями одноранговых узлов Распределение отображения IP

Может существовать ряд отличий между OTV Cisco и BGP, которые могут поддерживаться в виртуальной сети уровня 2. Например, основные аспекты OTV могут включать в себя группы многоадресной передачи OTV, использование IS-IS OTV, для которого может потребоваться МТ IS-IS, и передача OTV. Кроме того, ВОР может поддерживать отображение BGP MAC и наложение IP, например, для группы многоадресной передачи DC. В отображении BGP MAC может также использоваться МТ BGP. Кроме того, IBGP может поддерживаться IS-IS МТ, и используя IS-IS для одноранговой топологии (например, проверка пути с коммутацией меток (LSVP)).

В виртуальной сети уровня 2, описанной выше, количество приложений в пределах одной сети уровня 2 (или DC) может существенно увеличиваться, например, с течением времени. Таким образом, может потребоваться механизм для исключения проблем, связанных с существенно крупными сетями уровня 2. Такие проблемы могут включать в себя непрогнозируемое поведение серверов/хост-устройств и их приложений. Например, серверы/хост-устройства могут соответствовать различным поставщикам, где некоторые могут быть выполнены с возможностью передачи сообщений ARP, и другие могут быть выполнены с возможность передачи сообщений в режиме широковещательной передачи. Кроме того, типичные коммутаторы уровня 2 с малой стоимостью могут не иметь сложные свойства, которые позволяют блокировать фреймы данных широковещательной передачи, не позволяя им иметь политику, воплощенную для ограничения лавинной передачи и широковещательной передачи. Хост-устройства или приложения также могут отбрасывать в течение определенного времени MAC-адреса для частого отображения целевого IP, например, в течение нескольких минут. Хост-устройство также может часто передавать невызванные сообщения ARP, например, в случае, когда хост-устройство выполняет переключение (из активного режима в режим ожидания) или, когда у хост-устройство имеет незначительный программный сбой. В некоторых случаях, компоненты сети уровня 2 разделяют на меньшие подгруппы для ограничения широковещательной передачи меньшим количеством узлов.

На фиг.15 иллюстрируется вариант осуществления типичной схемы 1500 широковещательной передачи, которая может использоваться в сети/области уровня 2, например, VLAN, которая может составлять часть виртуальных сетей уровня 2 или сетей псевдоуровня 2, приведенных выше. Сеть/область уровня 2 или VLAN может содержать множество коммутаторов 1522 доступа (AS), размещенных в Pod 1530, например, в DC. VLAN также может содержать множество закрытых групп 1535 пользователей (CUG), соединенных с AS 1522. Каждый CUG 1535 может содержать множество коммутаторов 1524 конца ряда (EoR), соединенных с AS 1522, множество коммутаторов 1537 ToR, соединенных с коммутаторами 1524 EoR, и множество серверов/VM 1539, соединенных с коммутаторами 1537 ToR. AS 1522 могут быть соединены с множеством Pod (не показаны) в остальном DC могут соответствовать другим сетям/областей уровня 2 в виртуальных сетях уровня 2 или в сетях псевдоуровня 2. Компоненты сетей/областей уровня 2 или Pod 1530 могут быть размещены, как показано на фиг.15.

Типичная схема 1500 широковещательной передачи может пострадать от проблем масштабируемости широковещательной передачи. Например, фреймы с неизвестными DA могут быть переданы лавинно в пределах Pod 1530 во все оконечные системы во VLAN. Например, фреймы с неизвестными DA могут быть переданы в лавинном режиме во все или множество серверов/VM 1539 в AS 1522 в CUG 1535, как обозначено пунктирными стрелками на фиг.15. Фреймы с неизвестными адресами также могут быть переданы в лавинном режиме в противоположном направлении через AS 1522, во множество других Pod (в других DC) в базовой сети, которые могут быть ассоциированы с теми же услугами, что и Pod 1530. Фреймы могут быть дополнительно переданы в лавинном режиме во множество VM, в других Pod, что может достигать тысяч VM. Такая схема широковещательной передачи неизвестного DA может быть не эффективной в относительно крупных сетях, например, которые содержат множество DC.

На фиг.16 иллюстрируется вариант осуществления другой схемы 1600 широковещательной передачи, которая может использоваться в сети/области уровня 2, например, VLAN, которая может составлять часть сетей виртуального уровня 2 или сетей псевдоуровня 2, описанных выше. Схема 1600 широковещательной передачи может быть в большей степени управляемой и, таким образом, более масштабируемой и эффективной, чем схема 1500 широковещательной передачи. Сеть/область уровня 2 или VLAN могут содержать множество AS 1622, размещенных в Pod 1630, например, в DC. VLAN также может содержать множество CUG 1635, соединенных с AS 1622. Каждый CUG 1635 может содержать множество коммутаторов 1624 EoR, соединенных с AS 1622, множество коммутаторов 1637 ToR, соединенных с коммутаторами 1624 EoR, и множество серверов/VM 1639, соединенных с коммутаторами 1637 ToR. AS 1622 могут быть соединены с множеством Pod (не показаны) в других DC, которые могут соответствовать другим сетям/областей уровня 2 сетей виртуального уровня 2 или сетей псевдоуровня 2 сети. Компоненты сетей/областей уровня 2 или Pod 1630 могут быть размещены, как показано на фиг.16.

Для управления или ограничения объема широковещательной передачи схемы 1600 широковещательной передачи, только фреймы с неизвестными DA могут быть переданы в лавинном режиме в пределах Pod 1530 в один корень, например, в один сервер/VM 1639, который может быть обозначен, как сервер широковещательной передачи, или в AS 1622. Фреймы могут быть переданы в лавинном режиме в корень, используя маршрутизируемую многоточечную (RMP) конфигурацию VLAN, например, проталкивание метки VLAN для VLAN RMP, которую направляют в сервере широковещательной передачи. Однако фрейм, передаваемый в лавинном режиме может не быть передан во все другие серверы, например, которые не являются серверами широковещательной передачи, что может экономить ресурсы соединения и обработки в сервере поступающих извне фреймов. Кроме того, передаваемые фреймы могут быть не переданы в базовую сеть, например, в другие Pod или DC.

В некоторых вариантах осуществления сервер широковещательной передачи может содержать проксисервер ARP, сервер DHCP и/или другие серверы со специфичными функциями, например, для улучшения эффективности, масштабируемости и/или безопасности. Например, сервер широковещательной передачи может быть выполнен с возможностью обеспечения безопасности в DC, что позволяет использовать только выбранные услуги широковещательной передачи. Если известная услуга не будет выбрана, фреймы данных с неизвестными DA могут быть переданы из сервера широковещательной передачи по первой или исходной VLAN. Схема 1600 широковещательной передачи может использоваться для обработки в случаях, когда приложениям потребителя разрешено использовать широковещательную передачу уровня 2. Ограничитель скорости передачи данных также может использоваться для защиты от "штормов в режиме широковещательной передачи", например, исключение существенного трафика при широковещательной передаче.

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

Быстрый рост виртуальных хост-устройств может существенно повлиять на сети и услуги. Например, одна из получаемых в результате проблем может представлять собой обработку с частыми запросами ARP, такими как запросы ARP IP версии 4 (IPv4), или запросы по изучению соседних устройств (ND), такие как запросы ND IP версии 6 (IPv6) из хост-устройств. Хост-устройства в DC могут передавать такие запросы часто, из-за использования кэш или записей, которые устаревают в течение приблизительно в нескольких минут. В случае десятков тысяч хост-устройств в DC, которые могут иметь разные MAC-адреса, количество сообщений ARP или ND, или запросов в секунду может достигать больше чем приблизительно 1000-10000 запросов в секунду. Такая скорость или частота поступления запросов могут накладывать существенную вычислительную нагрузку на хост-устройства. Другая проблема, связанная, по существу, с большим количеством виртуальных хост-устройств в DC, может представлять собой существующие дублированные IP-адреса в пределах одной VLAN, которые могут повлиять на схему ARP или ND, не позволяя правильно работать. Некоторые технологии балансирования нагрузки также могут требовать множества хост-устройств, которые обслуживают одно и то же приложение для использования одного и того же IP-адреса, но с разными MAC-адресами. Некоторые облачные вычислительные услуги могут позволить пользователям использовать свои собственные подсети с IP-адресами и самостоятельно определенными политиками среди подсетей. При этом может оказаться невозможным обозначить VLAN для каждого клиента, поскольку максимальное количество доступных VLANS может составлять приблизительно 4095 в некоторых системах, в то время как их может быть сотни тысяч в подсетях клиентов. В этом сценарии могут присутствовать дублированные IP-адреса в разных подсетях клиентов, которые заканчиваются в одной VLAN.

В одном варианте осуществления предложен масштабируемый механизм разрешения адреса, который мог бы использоваться, по существу, в крупных сетях уровня 2, которые могут содержать одну VLAN, которая включает в себя существенное количество хост-устройств, таких как VM и/или конечные станции. Кроме того, описан механизм для правильного разрешения адресов во VLAN с дублированными IP-адресами. Этот механизм может использоваться, как для адресов ARP IPv4, так и для адресов ND IPv6.

На фиг.17 иллюстрируется вариант осуществления взаимно соединенных районов 1700 сети в соединенной мостом сети уровня 2, например, Ethernet. Соединенная мостом сеть уровня 2 может содержать множество основных мостов 1712 в основном районе 1710, который может быть соединены с множеством районов 1720. Соединенная мостом сеть уровня 2 также может содержать множество DBB 1722, которые могут составлять часть основного района 1710 и районы 1720, и, таким образом, может взаимно соединять основной район 1710 и районы 1720. Каждый район 1720 также может содержать множество промежуточных коммутаторов 1724, соединенных с соответствующими DBB 1722, и множество конечных станций 1726, например, серверов/VM, соединенных с соответствующими промежуточными коммутаторами 1724. Компоненты взаимно соединенных сетевых районов 1700 могут быть размещены, как показано на фиг.17.

На фиг.18 иллюстрируются другие варианты осуществления взаимно соединенных сетевых районов 1800, которые могут быть выполнены аналогично взаимно соединенным сетевым районам 1700. Взаимно соединенные сетевые районы 1800 могут содержать множество основных мостов 1812 и множество DBB 1822 (например, коммутаторов ToR) или коммутаторов границы района в основном районе 1810. Взаимно соединенные сетевые районы 1800 могут также содержать множество промежуточных коммутаторов 1824 и множество конечных станций 1826, например, серверов/VM, во множестве районов 1820. Районы 1820 также могут содержать DBB 1822, которые соединяют районы 1820 с основным районом 1810. Компоненты взаимно соединенных сетевых районов 1800 могут быть размещены, как показано на фиг.18. VLAN может быть установлена во взаимно соединенных сетевых районах 1800, как обозначено толстыми сплошными линиями на фиг.18. VLAN может быть ассоциирована с VID и может быть установлена между одним из основных мостов 1812 в основном мосту 1810, поднаборе DBB 1822 в районах 1820, и поднаборе промежуточных коммутаторов 1824 и серверов/VM 1826 в районах 1820.

DBB 1822 в районах 1820 могут знать и поддерживать пару <MAC, VID> для каждой конечной станции 1826 в районах 1820. Такая информация адреса может быть передана конечными станциями 1826 в соответствующие DBB 1822, в соответствующих районах 1820 через протокол раскрытия и конфигурации (VDP) интерфейса виртуальной станции (VSI) при виртуальном соединении мостами кромок (EVB). DBB 1822 также может регистрировать эту информацию в другой DBB 1822, например, через MMRP. В качестве альтернативы, информация адреса может быть передана конечными станциями 1826 в их DBB 1822, используя невызванные сообщения ARP или путем передачи сообщений конфигурации из NMS.

В одном варианте осуществления масштабируемый механизм разрешения адреса может быть воплощен для поддержки VLAN, которые содержат относительно большое количество хост-устройств во взаимно соединенных сетевых районах 1800. В частности, адрес MAC 1822 DBB в одном районе 1820 и VID VLAN могут использоваться, как ответ на запрос ARP, для адресов хост-устройств в районе, из других районов 1820. В некоторых случаях DS могут быть выполнены с возможностью получения сведенной информации об адресе для конечных станций 1826 в районе 1820, когда DS может не иметь возможности обработки относительно большого количества сообщений для отдельных оконечных станций 1826 или хост-устройств. В таких случаях DBB 1822 в районе 1820 м EVB может прекращать все невызванные сообщения ARP для хост-устройств в районе или может просматривать все невызванные сообщения ARP, переданные из своего района 1920, и передавать, вместо этого, например, невызванные групповые объявления, в которых сведена информация адреса хост-устройств для DS. DBB может передавать свое собственное невызванное объявление ARP для объявления для всех хост-устройств IP-адресов в своем районе 1820, в другие районы 1820.

Кроме того, DBB 1822 в районе 1820 может использоваться как прокси ARP, путем передачи своего собственного MAC-адреса в другие районы 1820, например, через основной мост 1812 в основном районе 1810. Основные мосты 1812 могут иметь MAC-адреса DBB 1822 только в районе 1820, но и могут не иметь MAC-адреса промежуточных коммутаторов 1824 и конечных станций 1826 или хост-устройств, что делает эту схему более масштабируемой. Например, когда первая конечная станция 1826 в первом районе 1820 передает запрос ARP для получения адреса второй конечной станции 1826 во втором районе 1820, MAC-адрес DBB 1822 второго района 1820 может быть возвращен в ответ в первую конечную станцию 1826.

На фиг.19 иллюстрируется вариант осуществления схемы 1900 прокси ARP, которая может использоваться соединенным мостом сети уровня 2, например, для взаимно соединенных сетевых районов 1800. Соединенная мостом сеть уровня 2 может содержать основной район 1910, множество DBB 1922 или коммутаторов на границе района, соединенных с основным районом 1910, и множество конечных станций 1926 (например, VM), соединенных с соответствующими DBB 1922 в их районах. Соединенный мостом с сетью Уровень 2 также может содержать DS1940, которая может быть соединена с DBB 1922, например, через основной район 1910. DBB 1922 и конечные станции 1926 могут принадлежать VLAN, установленной в соединенной мостом сети уровня 2, и ассоциированной с VID. Компоненты соединенной мостами сети уровня 2 могут быть размещены, как показано на фиг.19.

На основе схемы 1900 прокси ARP, первый 1922 DBB (DBB X) может перехватывать запрос ARP из первой конечной станции 1926 в ее локальном районе. Запрос ARP может представлять запрос адреса MAC второй конечной станции 1926 в другом районе. Запрос ARP может содержать IP DA (10.1.0.2) второй конечной станции 1926, и адрес источника IP (SA) (10.1.0.1) и MAC SA (А) первой конечной станции 1926. Первая конечная станция 1926 может поддерживать IP-адреса других конечных станций 1922 в таблице 1960 VM ARP. DBB X может передавать запрос DS для получения MAC-адреса во вторую конечную станцию 1926 из DS 1940. Запрос DS может содержать IP-адрес (10.1.0.2) второй конечной станции 1926 и IP SA (10.1.0.1), и MAC SA (А) первой конечной станции 1926. DS 1940 может поддерживать IP-адреса, MAC-адреса и информацию об ассоциированных DBB 1922 или местоположениях конечных станций 1926 (хост-устройств) в таблице 1950 DS адресов.

DS 1940 может затем возвращать в DBB X ответ DS, который содержит IP-адрес (10.1.0.2) второй конечной станции 1926 и MAC-адрес (Y) второй DBB 1926 (DBB Y), ассоциированный со второй конечной станцией 1926 в другом районе, как обозначено в таблице 1950 адресов DS. В свою очередь, DBB X может передавать ответ ARP в первую конечную станцию 1926, которая содержит IP DA (10.1.0.1) и MAC DA (А) первой конечной станции 1926, IP SA (10.1.0.2) второй конечной станции 1926 и MAC-адрес DBB Y (Y). Первая конечная станция 1926 может затем ассоциировать MAC-адрес DBB Y (Y) с IP-адресом (10.1.0.2) второй конечной станции 1926 в таблице 1960 VM ARP. Первая конечная станция 1926 может использовать MAC-адрес DBB Y, как DA, для передачи фреймов, которые предназначены для второй конечной станции 1926.

В схеме 1900 прокси ARP DBB 1922 может потребоваться содержать только MAC-адреса других DBB 1922 в районах без MAC-адресов и IP-адресов хост-адресов в этих районах. Поскольку DA во фреймах данных, переданных в DBB 1922, соответствуют только MAC-адресам DBB, как описано выше, DBB 1922 может не потребоваться знать другие адреса, что делает эту схему более масштабируемой.

На фиг.20 иллюстрируется вариант осуществления схемы 2000 передачи фрейма данных, которая может использоваться в соединенной мостом сети уровня 2, например, для районов 1800 взаимно соединенной сети. Соединенная мостом сеть уровня 2 может содержать основной район 2010, множество DBB 2022 или коммутатор на границе района, множество районов 2020, соединенных с основным районом 2010, и множество промежуточных коммутаторов 2024 и конечных станций 2026 (например, VM), соединенных с соответствующими DBB 2022 в их районах 2020. Некоторые из DBB 2022, промежуточных коммутаторов 2024 и конечных станций 2026 района 2020 могут принадлежать VLAN, установленной в соединенной мостом сети уровня 2, и ассоциированной с VID. Компоненты соединенной мостом сети уровня 2 могут быть размещены, как показано на фиг.20.

Схема 2000 передачи данных фрейма может быть основана на MAT в DBB 2022, которые могут быть аналогичны IP NAT. MAT может содержать использование внутренних IP-DA и таблицы ARP, для поиска соответствующих MAC-DA. Например, первая DBB 2022 (DBB1) может принимать фрейм 2040, например, фрейм Ethernet, из первой конечной станции 2026 (host А) в первом районе (district 1). Фрейм 2040 может быть предназначен для второй конечной станции 2026 (host В) во втором районе (district 2). Фрейм 2040 может содержать MAC-DA 2042 для второй DBB в районе district 2 (DBB2), MAC-SA 2044 для хост-устройства A (MAC для A), IP-DA 2046 для хост-устройства В (В), IP-SA 2048 для хост-устройства (А) и полезную нагрузку. DBB1 может передавать фрейм 2040 в район 2 через основной район 2010. Вторая DBB 2022 (DBB2) в районе 2 может принимать фрейм 2040 и заменять MAC-DA 2042 для DBB2 (DBB2) во фрейме 2040 на MAC-DA 2082 для хост-устройства В (MAC для В) во втором фрейме 2080. DBB2 может определять MAC для В на основе IP-DA 2046 для хост-устройства В (В) и соответствующей записи в своей таблице ARP. Второй фрейм также может содержать MAC-SA 2084 для хост-устройства A (MAC для А), IP-DA 2086 для хост-устройства В (В), IP-SA 2088 для хост-устройства А (А) и полезную нагрузку. DBB2 может передавать второй фрейм 2080 в хост-устройство В в районе 2. Поскольку SA в принимаемых фреймах в районе 2, не меняются, схема 2000 передачи фрейма может не влиять на воплощенные DHCP в сети.

В описанной выше сети для основных мостов или коммутаторов основного района, например, основные мосты 1812 в основном районе 1810, может потребоваться только поддерживать MAC-адреса DBB в районах без MAC-адресов и IP-адресов хост-устройств в районах. Поскольку DA во фреймах данных, передаваемых через основной район, могут соответствовать только MAC-адреса DBB, как описано выше, для основных мостов может не потребоваться знание других адресов. MAC-адреса DBB могут содержаться в базах данных передачи основных мостов (FDB). Основные мосты или коммутаторы могут определять топологию всех DBB через протокол на основе состояния соединения. Например, DBB могут передавать объявления о состоянии соединения (LSA), например, используя IEEE 802.1aq, транспарентное взаимное соединение множества соединений (TRILL), или ядро на основе IP. Если используется Протокол связующего дерева (STP) среди основных мостов, изучение адресов MAC может быть не разрешено в основных мостах. В этом случае DBB могут сами себя регистрировать в основных мостах.

В варианте осуществления DBB могут действовать, как прокси ARP, как описано выше, если DS не используется. Невызванные сообщения ARP могут быть переданы конечными станциями, для объявления своих собственных MAC-адресов. Невызванные групповые объявления могут также быть переданы DBB для объявления своих собственных MAC-адресов и IP-адресов для всех хост-устройств в пределах их локальных районов. Невызванные групповые объявления могут использоваться для объявления о MAC-district для других DBB, в других районах. Анонсируемые MAC-адреса и IP-адреса могут использоваться в других DBB для трансляции DBB MACO-DA в полученных фреймах, в соответствии с DA IP хост-устройств. Невызванные групповые ARP могут быть переданы в DBB, для объявления поднабора IP-адресов хост-устройств для каждой VLAN, ассоциированной с DBB. Невызванные групповые ARP могут содержать отображение поднаборов хост IP-адресов для множества VLAN для DBB.

В таблице 5 иллюстрируется пример отображения хост IP-адресов для соответствующих адресов MAC DBB во взаимно соединенных районах. Отображение может быть передано в невызванной групповой ARP с помощью DBB, для объявления ее хост IP-адресов для каждой VLAN, ассоциированной с DBB. MAC-адрес DBB (DBB-MAC) может быть отображен на множество соответствующих IP-адресов хост-устройств. Каждый адрес DBB MAC может быть отображен на множество IP-адресов хост-устройств во множестве VLAN (например, VID-1, VID-2, VID-n, …), которые могут находиться в одном и том же или в разных районах.

Таблица 5 Информация, переносимая невызванной групповой ARP DBB VLAN Хост-устройство DBB-MAC VID-1 IP адреса всех хост-устройств в этой VLAN (IP Prefix) VID-2 IP адреса всех хост-устройств в этой VLAN (IP Prefix) VID-n IP адреса всех хост-устройств в этой VLAN (IP Prefix)

В некоторых ситуациях множество хост-устройств во взаимно соединенных районах могут иметь одинаковые IP-адреса и могут быть ассоциированы с одним и тем же VLAN (или VID). Например, виртуальная подсеть облачной компьютерной услуги сервиса может позволять клиентам наименовать свои собственные частные IP-адреса. Количество виртуальных подсетей, предлагаемых облачной компьютерной услугой, может существенно превышать общее количество разрешенных VLAN (например, приблизительно 4095 VLAN). При этом множеству виртуальных хост-устройств (например, VM или виртуальных конечных станций) может быть разрешено иметь одинаковые IP-адреса, но с разными MAC-адресами. В других случаях множество конечных станций может использовать одинаковое приложение, используя одинаковые IP-адреса, но разные MAC-адреса.

В одном варианте осуществления DBB может быть назначено множество MAC-адресов, упомянутых здесь, как MAC-адреса делегаты, например, для того, чтобы разделить между разными хост-устройствами, в которых используются одинаковый (дублированный) IP-адрес. DBB также могут быть ассоциированы с множеством VLAN. Кроме того, каждая VLAN по DBB может быть ассоциирована с множеством подсетей или виртуальных подсетей, например, которые содержат разные поднаборы хост-устройств в пределах VLAN. Виртуальные подсети могут быть ассоциированы с множеством ID подсетей. Если количество дублированных IP-адресов для хост-устройств существенно меньше, чем количество виртуальных подсетей VLAN, тогда количество MAC-адресов делегатов для DBB также может быть существенно меньше.

На фиг.21 иллюстрируется вариант осуществления схемы 2100 прокси ARP, которая может использоваться для взаимно соединенных районов сети в соединенной мостом сети уровня 2. Соединенная мостом сеть уровня 2 может содержать основной район 2110, множество DBB 2122 или граничных коммутаторов района, соединенных с основным районом 2110, и множество конечных станций 2126 (например, VM), соединенных с соответствующими DBB 2122 в своих районах. Соединенная мостом сеть уровня 2 также может содержать DS 2140, который может быть соединен с DBB 2122, например, через основной район 2110. DBB 2122 и конечные станции 2126 могут принадлежать VLAN, установленной в соединенной мостом сети уровня 2. Компоненты соединенной мостом сети уровня 2 могут быть размещены, как показано на фиг.21.

Основываясь на схеме 2100 прокси ARP, первая DBB 2122 (DBB X) может перехватывать запрос ARP из первой конечной станции 2226 в ее локальном районе. Запрос ARP может представлять собой запрос MAC адреса для второй конечной станции 2126 в другом районе. Запрос ARP может содержать IP-DA (10.1.0.2) второй конечной станции 2126, и SA-IP (10.1.0.1) и MAC-SA (А) первой конечной станции 2126. Первая конечная станция 2126 может поддерживать IP адреса других конечных станций 2122 в таблице 2160 ARP VM. DBB X может затем перенаправлять запрос DS, для получения адреса MAC для второй конечной станции 2126 из DS 2140. Запрос DS может содержать IP-адрес (10.1.0.2) второй конечной станции 2126 и IP-SA (10.1.0.1), и MAC-SA (А) первой конечной станции 2126. DS 2140 может поддерживать IP-адреса, MAC-адреса, ID VLAN или VID, ID потребителя (виртуальная подсеть) и информацию об ассоциированных DBB 2122 или местах положения конечных станций 2126 в таблице 2150 адресов DS.

DS 2140 может использовать MAC-SA (А) в запросе DS, для определения, какой из ID потребителя (виртуальная подсеть) принадлежит запрашивающей VM (первая конечная станция 2126). Например, в соответствии с таблицей 2150 адресов DS, ID потребителя Джо соответствует MAC-SA (А). DS 2140 может затем возвратить в DBB X ответ DS, который содержит IP адрес (10.1.0.2) второй конечной станции 2126, и адрес делегата MAC (Y1) второй DBB 2126 (DBB Y), ассоциированной с ID потребителя (Джо) первой конечной станции 2126. В свою очередь, DBB X может передать ответ ARP в первую конечную станцию 2126, которая содержит IP-DA (10.1.0.1) и MAC DA (А) первой конечной станции 2126, IP-SA (10.1.0.2) второй конечной станции 2126, и MAC адрес делегат DBB Y (Y1). Первая конечная станция 2126 может затем ассоциировать MAC адрес делегат DBB Y (Y1) с IP адресом (10.1.0.2) второй конечной станции 2126 в таблице 2160 VM ARP. Первая конечная станция 2126 может использовать MAC адрес делегат DBB Y, как DA для перенаправления фреймов, которые предназначены для второй конечной станции 2126.

Третья конечная станция 2126 в другом районе может также передавать запрос ARP (для второй конечной станции 2126 в соответствующую локальную DBB 2122 (DBB Z) в районе третьей конечной станции. DBB Z может затем связываться с DS 2140, как описано выше, и возвращать, соответственно, в третью конечную станцию 2126 ответ ARP, который содержит IP DA (10.1.0.3) и MAC DA третьей конечной станции 2126, IP SA (10.1.0.2) второй конечной станции 2126, и MAC адрес делегат DBB Y (Y2), ассоциированный с ID потребителя Боб третьей конечной станции 2126 в таблице 2150 адресов DS. Третья конечная станция 2126 может затем ассоциировать адрес MAC делегата DBB Y (Y2) с IP адресом (10.1.0.2) второй конечной станции 2126 в таблице 2170 ARP VM третьей конечной станции 2126. Третья конечная станция 2126 может использовать этот MAC адрес делегат DBB Y, как DA для передачи фреймов, которые предназначены для второй конечной станции 2126.

В таблице 6 иллюстрируется пример отображения дублированного IP адреса хост-устройства для соответствующего адреса MAC делегата DBB во VLAN во взаимно соединенных районах. Дублированный адрес хост-устройства может использоваться множеством хост-устройств для одного предназначенного для этого приложения или хост-устройства. Адреса DBB делегата MAC могут быть назначены для разных хост-устройств, в которых используются одинаковое приложение (или которые связываются с одним и тем же устройством). Для каждой VLAN IP адрес хост-устройства может быть отображен на множество MAC адресов делегатов DBB (MAC 12, MAC 13, MAC 14, …) для множества хост-устройств, например, ассоциированных с разными подсетями VLAN. Адреса MAC DBB делегатов могут также быть ассоциированы с основным (оригинальным) адресом MAC DBB (MAC 11). Основной адрес MAC и адреса MAC-делегаты DBB для одного и того же IP могут быть разными для разных VLAN. Когда VLAN не имеет адреса делегаты, основной адрес DBB может использоваться для VLAN. Если существует приблизительно 10 дублированных IP адресов в пределах одной VLAN, тогда приблизительно 10 столбцов (десять адресов MAC) в таблице 6 могут использоваться.

Таблица 6 MAT для дублированных IP адресов. IP адрес Основной адрес DBB DBB Делегат 1 DBB Делегат 2 DBB Делегат 3 DBB Делегат 4 …… 10.1.0.1 (VLAN#1) MAC 11 MAC 12 MAC 13 MAC 14     10.1.0.1 (VLAN#2) MAC 21 MAC 22 ……       10.1.0.1 (VLAN#3) MAC 31 ……                      

В таблице 7 иллюстрируется пример отображения IP адресов хост-устройств множества адресов делегатов MAC, например, для множества подсетей. Отображение может быть передано в невызванном групповом ARP из DBB, для сообщения ее IP адресов хост-устройства для каждой VLAN, ассоциированной с DBB. Каждый адрес делегата MAC (DBB-MAC1, DBB-MAC2, …) может быть отображен на множество соответствующих IP адресов хост-устройств в подсети. Каждый адрес MAC делегата DBB может быть ассоциирован с ID потребителя или ID виртуальной подсети для IP адресов хост-устройств. IP адреса хост-устройств для каждого адреса MAC делегата DBB также могут соответствовать множеству VLAN (VID-1, VID-2, VID-n, …). Адреса IP хост-устройств в каждой подсети могут быть разными. Дублированные адреса IP хост-устройств, которые могут быть ассоциированы с одним и тем же VLAN, но с разными ID потребителя, могут быть отображены на разные адреса MAC делегаты DBB.

Таблица 7 Информация, переносимая невызванной групповой ARP DBB VLAN Хост-устройство DBB-MAC1 VID-1 IP адрес всех хост-устройств в этой VLAN (IP Prefix) VID-2 IP адреса всех хост-устройств в этой VLAN (IP Prefix) VID-n IP адреса всех хост-устройств в этой VLAN (IP Prefix) DBB-MAC2 VID-1 IP адреса всех хост-устройств в этой VLAN (IP Prefix) VID-2 IP адреса всех хост-устройств в этой VLAN (IP Prefix) VID-n IP адреса всех хост-устройств в этой VLAN (IP Prefix)

На фиг.22 иллюстрируется вариант осуществления схемы 2200 обхода отказа, которая может использоваться для взаимно соединенных сетевых районов с соединенной мостом сетью уровня 2. Схема 2100 обхода отказа может использоваться в случае отказа любой из DBB (например, коммутатора ToR) во взаимно соединенных районах. Соединенная мостом сеть уровня 2 может содержать множество основных мостов 2212 и множество DBB 2222 или коммутатор на границе района в основном районе 1810 и множество районов 2220. Районы 2220 могут содержать DBB 2222, множество промежуточных коммутаторов 2224 и множество конечных станций 2226, например, серверов/VM. Соединенная мостом сеть уровня 2 также может содержать DS (не показана), которая может быть соединена с DBB 2222, например, через основной район 2210. Некоторые из DBB 2222, промежуточных коммутаторов 2224 и конечных станций 2226 могут принадлежать VLAN, установленной в соединенной мостом сети уровня 2. Компоненты соединенной мостом сети уровня 2 могут быть размещены, как показано на фиг.22.

Когда происходит отказ активной DBB 2222 во VLAN, VLAN может быть установлена с использованием одного или больше находящихся в дежурном режиме DBBs 2222. Находящаяся в дежурном режиме DBB 222 может устанавливать активные соединения, по меньшей мере, с некоторыми из промежуточных коммутаторов 2224, принадлежащих VLAN, и, возможно, с использованием нового основного моста 2212. Это обозначено пунктирными линиями на фиг.22. При этом пути в конечных станциях 2226 VLAN могут не быть потеряны, что обеспечивает для конечных станций 2226 возможность связи через VLAN. В случае, когда происходит отказ DBB 222 во VLAN, DS может быть уведомлен об этом отказе, например, путем передачи явно выраженного сообщения DS или используя способ проверки работоспособности. Таким образом, DBB может заменять информацию адреса DBB, в которой произошел отказ, и, возможно, другие первоначальные DBB 2222 во VLAN во входах таблицы адресов DS информацией новых DBBs 2222, которые находились в режиме ожидания и затем использовались для замены отказавших и других оригинальных DBB 2222. Замененные DBB, в которых произошел отказ, и оригинальные обозначены кругами на фиг.22. После детектирования DBB 2222 с отказом, DBB замены может быть передана LSA в DS или в основной район 2010 для обозначения того, что адреса DBB, в которой произошел отказ, включая в себя все адреса делегаты, являются доступными при замене DBB 2222.

Используя виртуализацию сервера, физический сервер может содержать большее количество VM, например, от десятков до сотен виртуальных конечных станций или VM. Это может привести к существенному увеличению количества виртуальных хост-устройств в DC. Например, для относительно больших DC приблизительно 50000 серверов, каждый из которых может поддерживать приблизительно до 128 VM, общее количество VM в DC может быть равно приблизительно 50000×128 или приблизительно 6400000 VM. Для достижения динамического выделения ресурсов в таком большом наборе серверов, в DC могут использоваться сети уровня 2 на основе Ethernet. Такая большая сеть уровня 2 с потенциальным существенным количеством виртуальных хост-устройств может представлять новые проблемы для лежащей в основе технологии Ethernet. Например, одна проблема может составлять масштабируемость таблицы перенаправления MAC из-за плоского пространства адреса MAC. Другая проблема может представлять собой обработку пиковых нагрузок во время широковещательной передачи, связанных с ARP и другим графиком во время широковещательной передачи.

Один подход по уменьшению размера таблицы перенаправления MAC, также называемый здесь FDB, в ядре сети, может состоять в использовании инкапсуляции сетевого адреса, например, в соответствии с IEEE 802.1 ah и TRILL. Инкапсуляция сетевого адреса 802.1 ah и TRILL описаны в стандарте IEEE P802.1ah/D4.2 и проект draft-letf-trill-rbridge-protol-12-txt IETF, соответственно, оба из которых включены здесь по ссылке. Используя инкапсуляцию сетевого адреса, количество записей FDB в основных коммутаторах может быть уменьшено до общего количества коммутаторов (включая в себя кромку и ядро) в сети, независимо от количества VM. Например, при использовании приблизительно 20 серверов на краевой коммутатор, количество краевых коммутаторов в сети, содержащей приблизительно 50000 серверов, может быть равно приблизительно 50000/20 или приблизительно 2500. Однако, при определении адреса MAC пути передачи данных, размер FDB краевых коммутаторов (например, коммутаторов ToR DC), может быть приблизительно таким же, как и в случае, когда инкапсуляция адреса сети не используется, что может быть существенно большим.

Даже при избирательном изучении MAC в коммутаторах ToR, размер FDB может все еще может быть существенно большим. Например, если коммутатор ToR имеет приблизительно 40 расположенных после него портов, пара коммутаторов ToR может иметь вплоть до приблизительно 40 серверов с двойной привязкой, соединенных с коммутатором ToR. Если сервер поддерживает приблизительно до 128 VM, коммутатор ToR может иметь приблизительно 128х40/2, или приблизительно 2560 VM, соединенных с коммутатором ToR при нормальной работе, например, когда коммутаторы ToR обрабатывают приблизительно такое же количество VM. Количество VM может увеличиваться вплоть до приблизительно 5120, если произойдет отказ одного из коммутаторов ToR. Если каждая VM связывается в среднем приблизительно с 10 удаленными VM одновременно, размер FDB коммутатора ToR (например, количество записей) может составлять, по меньшей мере, число, пропорциональное приблизительно 2560 (локальные VM)+2560×10 (удаленные VM)+2500 (коммутаторов ToR) или приблизительно 30660 записей, которые могут быть дополнительно дублированы в сценарии с отказом.

Инкапсуляция сетевого адреса в 802.1ah и TRILL может быть симметричной. В частности, те же коммутаторы, что и краевые коммутаторы, могут выполнять инкапсуляцию адреса. Проблема, возникающая при симметричной инкапсуляциями сетевого адреса в 802.1ah и TRIL, состоит в том, что краевой коммутатор должен поддерживать маршрут до удаленных VM, которые связываются с локальными VM. Количество удаленных VM может существенно изменяться. Одно из решений, предложенных А. Гринбергом и др. в статье под названием "Towards a Next Generation Data Center Architecture: Scalability and Commoditization", опубликованной в PRESTO 08, которая представлена здесь по ссылке, состоит в удалении процедуры инкапсуляции сетевого адреса внутри VM, уменьшая, таким образом, размер FDB коммутатора до минимума, что может быть равно сумме количества локальных VM и количества краевых коммутаторов в сети (например, равно приблизительно 2560+2500 или приблизительно 5060 записей в представленном выше примере). Недостаток такого подхода состоит в изменении стека протокола операционной системы (OS) гостевого устройства.

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

Схема инкапсуляции асимметричного сетевого адреса может быть воплощена в сети уровня 2, которая содержит краевые и основные коммутаторы, так, как и в разных вариантах осуществления сети, описанных выше. Например, краевые коммутаторы могут соответствовать коммутаторам ToR в каждом из DS. Каждому из краевых коммутаторов может быть назначен уникальный ID, который может представлять собой MAC адрес (как в 802.1ah), один размером приблизительно 16 битов псевдоним (такой как TRILL) или IP адрес. Сеть может быть выполнена с возможностью перенаправления фрейма на основе ID краевого коммутатора - места назначения, который содержится в заголовке фрейма из входного краевого коммутатора в выходной краевой коммутатор. Фрейм может быть направлен внутри сети, используя любую технологию транспортирования. Асимметричная схема инкапсуляции сетевого адреса может быть аналогична схеме инкапсуляции адреса в 802.1ah, также называемой MAC-в-MAC. Изучение MAC может быть не разрешено в сети, но может быть разрешено в портах, обращенных к серверу краевого коммутатора. Термины сервер, конечная станция и хост-устройство могут использоваться здесь взаимозаменяемо. Термины виртуальный сервер, VM, виртуальная конечная станция и виртуальное хост-устройство также могут использоваться здесь взаимозаменяемо.

В MAC-в-MAC существуют два типа MAC адресов: MAC адреса, назначенные для краевых коммутаторов, также называются сетевыми адресами или магистральными MAC (В-MAC) адресами, и MAC адреса, используемые VM, также называются MAC адресами потребителя (С-MAC). На фиг.23 иллюстрируется вариант осуществления типичного физического сервера 2300, который может представлять собой сервер с двойной привязкой в DC. Физический сервер 2300 может содержать виртуальный коммутатор 2310, множество VM 2340 и множество физических карт 2350 сетевого интерфейса (pNIC). Виртуальный коммутатор 2310 может содержать прокси 2330 ARP и FDB 2320, которые могут составлять локальную FDB 2322 и удаленную FDB 2324. Виртуальный коммутатор 2310 может быть расположен внутри гипервизора физического сервера 2300. Виртуальный коммутатор 2310 может быть соединен с VM через множество соответствующих виртуальных карт сетевого интерфейса (NIC) 2342 VM 2340 и множество соответствующих портов 2312 виртуального коммутатора виртуального коммутатора 2310. Виртуальный коммутатор 2310 также может быть соединен с pNIC 2312 через множество соответствующих магистральных портов 2314 виртуального коммутатора в виртуальном коммутаторе 2310. pNIC 2350 может использоваться, как восходящие каналы или магистральные каналы для виртуального коммутатора 2310. Физический сервер 2300 может быть соединен с множеством краевых коммутаторов 2360 через соответствующие pNIC 2350 физического сервера 2300. Таким образом, краевые коммутаторы 2360 могут быть соединены через компоненты физического сервера 2300 (pNIC 2350 и виртуальный коммутатор 2310) с VM 2340. Компоненты физического сервера 2300 могут быть расположены, как показано на ФИГ.23.

Для балансирования нагрузки трафик может быть распределен в магистральные каналы (pNIC 2350) на основе ID виртуального порта или С-MAC адресов источника VM для трафика. Каждая VM 2340 может иметь виртуальный NIC 2342 с уникально назначенным С-MAC адресом. VM 2340 может передавать трафик в краевой коммутатор 2360 во время нормальной работы. Например, первая VM 2340 (VM1) может передавать множество фреймов, предназначенных для внешних VM, в другие физические серверы, в сети (не показаны), через соответствующий первый краевой коммутатор 2350 (краевой коммутатор X). Второй краевой коммутатор 2360 (краевой коммутатор R) может представлять собой коммутатор резервного копирования для краевого коммутатора X. Когда краевой коммутатор Х становится недоступным, из-за неисправности (например, происходит неисправность соответствующего pNIC 2350, соединение между pNIC 2350 и краевым коммутатором Х становится неисправным, или краевой коммутатор Х становится неисправным), виртуальный коммутатор 2310 может затем передавать фреймы в краевой коммутатор R.

В FDB 2320, локальная FDB 2322 может соответствовать локальным VM (VM 2340) и может содержать множество адресов назначения С-MAC (С-MAC DA), множество ID VLAN и множество ассоциированных ID порта виртуального коммутатора. С-MAC DA и ID VLAN могут использоваться для проверки локальной FDB 2322, для получения соответствующих ID виртуального коммутатора. Удаленная FDB 2324 может соответствовать внешней VM (на других физических серверах) и может содержать множество адресов назначения В-MAC (DA B-MAC), и множество DA С-MAC, ассоциированных с DA В-MAC.DA С-MAC могут использоваться для проверки дистанционной FDB 2324 с помощью локальных VM, для получения соответствующих DA В-MAC. Дистанционная FDB 2324 может быть заполнена прокси 2330 ARP, как описано ниже.

На основе симметричной инкапсуляции адреса. Фрейм Ethernet из VM 2340 может не иметь метки или может иметь метку. Если фрейм не имеет метки, может использоваться ID VLAN, назначенный для соответствующего порта 2312 виртуального коммутатора. В направлении вверх по потоку от VM 2340 до краевого коммутатора 2360, виртуальный коммутатор 2310 может выполнять следующие этапы после приема фрейма Ethernet из VM 2340:

Этап 1: Используется DA С-MAC и ID VLAN при поиске в таблице локальной FDB 2322. Если будет найдено соответствие, фрейм перенаправляют в порт 2312 виртуального коммутатора, который указан в соответствующей записи FDB (no ID порта виртуального коммутатора). В противном случае, выполняется переход на этап 2.

Этап 2: Используют DA С-MAC в проверке таблицы удаленной FDB 2324. Если будет найдено соответствие, выполняют инкапсуляцию MAC-в-MAC на основе асимметричной инкапсуляции сетевого адреса (описана ниже), и передают фрейм в магистральный порт 2314 виртуального коммутатора, который ассоциирован с SA С-MAC во фрейме. В противном случае, переходят на этап 3.

Этап 3: Отбрасывают фрейм и передают улучшенный запрос ARP в сервер ARP в сети (не показан).

На фиг.24 иллюстрируется вариант осуществления схемы 2400 асимметричной инкапсуляции сетевого адреса, которая может использоваться в физическом сервере. На основе схемы 2400 асимметричной инкапсуляции сетевого адреса VM 2402 может передавать, в направлении вверх по потоку, фрейм, предназначенный для другой внешней или дистанционной VM в другом физическом сервере в сети (не показан). Фрейм может содержать С-MAC DA (В) 2410 дистанционной VM, C-MAC SA (А) 2412 VM 2402, С-VLAN ID 2414 для VLAN VM 2402, данные или полезную нагрузку 2416, и последовательность 2418 проверки фрейма (FCS). VM 2402 может передавать фрейм в виртуальный коммутатор 2404.

Виртуальный коммутатор 2404 (в том же физическом сервере) может принимать фрейм из VM 2402. Виртуальный коммутатор 2404 может обрабатывать фрейм и добавлять заголовок к фрейму, для получения фрейма MAC-в-MAC. Заголовок может содержать В-MAC DA (Y) 2420, В-MAC SA (0) 2422, B-VLAN ID 2424 и ID мгновенной услуги 2426 (I-SID). В-MAC адрес (Y) может быть ассоциирован с С-MAC DA (В) 2410 в краевом коммутаторе 2406. В-MAC адрес (Y) может обозначать местоположение удаленного VM, который представляет собой С-MAC адрес (В). В-MAC SA 2422 может быть установлена в ноль виртуальным коммутатором 2404. B-VLAN ID 2424 может быть установлен в C-VLAN ID 2414. I-SID 2426 может быть не обязательным и может не использоваться в заголовке, если фрейм Ethernet передают только в С-MAC (В) DA. Виртуальный коммутатор 2404 затем может передавать фрейм MAC-в-MAC в краевой коммутатор 2406.

Краевой коммутатор 2406 (соединенный с физическим сервером) может принимать фрейм MAC-в-MAC из виртуального коммутатора 2404. Краевой коммутатор 2406 может обрабатывать заголовок фрейма MAC-в-MAC, для получения нового заголовка во фрейме MAC-в-MAC. Новый заголовок может содержать В-MAC DA (Y) 2440, В-MAC SA (X) 2442, B-VLAN ID 2444 и I-SID 2446. В-MAC SA (X) 2442 может быть установлен в адрес В-MAC (X) краевого коммутатора 2406. B-VLAN ID 2444 может быть изменен, если необходимо, так, чтобы он соответствовал VLAN в сети. Остальные поля заголовка могут не изменяться. Краевой коммутатор 2406 может затем передавать новый фрейм MAC-в-MAC на основе В-MAC DA (Y) 2442 и, возможно, В- VLAN ID 2444 через ядро 2408 сети, например, базовую сеть или основной район сети.

В направлении вниз по потоку краевой коммутатор 2406 может принимать фрейм MAC-в-MAC из сетевого ядра 2408 и выполнять декапсуляцию фрейма. Фрейм MAC-в-MAC может содержать заголовок и исходный фрейм, переданный из дистанционной VM в VM 2402. Заголовок может содержать В-MAC DA (X) 2460 для краевого коммутатора 2406, В-MAC SA (Y) 2462, который соответствует дистанционной VM, и краевой коммутатор 2406, B-VLAN ID 2464 для VLAN дистанционной VM, и I-SID 2466. Оригинальный фрейм для дистанционной VM может содержать С-MAC DA (А) 2470 для VM 2402, С-MAC SA (В) 2472 дистанционной VM, C-VLAN ID 2474, ассоциированный с VM 2402, данные или полезную нагрузку 2476, и FCS 2478. Краевой коммутатор 2406 может удалять заголовок из фрейма MAC-в-MAC и передавать оставшийся первоначальный фрейм в виртуальный коммутатор 2404. Краевой коммутатор 2406 может проверять свою таблицу перенаправления, используя С-MAC DA (А) 2470 и C-VLAN ID 2474 для получения ID порта исходящего коммутатора и передачи исходного фрейма из физического сервера, который обращен к или соединен с соответствующим портом коммутатора. В свою очередь, виртуальный коммутатор 2404 может передавать оригинальный фрейм в VM 2402. Виртуальный коммутатор 2404 может передавать оригинальный фрейм в VM 2402 на основе С-MAC DA (А) 2470 и C-VLAN ID 2474.

Таблицы перенаправления в краевом коммутаторе 2406 могут включать в себя локальную FDB и удаленную FDB. Локальная FDB может использоваться для перенаправления фреймов в локальные VM и может быть заполнен в результате изучения MAC и индексирован С-MAC DA и C-VLAN ID в принимаемом фрейме. Удаленная FDB может использоваться для перенаправления фреймов к удаленные VM и может быть заполнен с помощью протокола маршрутизации или централизованного плана управления/администрирования и индексирован DA В-MAC и, возможно, B-VLAN ID в принимаемом фрейме.

В схеме 2400 асимметричной инкапсуляции адреса инкапсуляция MAC-в-MAC может быть выполнена в виртуальном коммутаторе 2404, в то время как декапсуляция MAC В- MAC может быть выполнена в краевом коммутаторе 2406. При этом, размер FDB в краевых коммутаторах может быть существенно уменьшен и может стать более управляемым, даже для существенно больших сетей уровня 2, например, в мега DC. Размер удаленной FDB в виртуальном коммутаторе 2404 может зависеть от количества удаленных VM, которые выполняют обмен данными с локальными VM, например, VM 2402. Например, если виртуальный коммутатор поддерживает приблизительно 128 локальных VM, и каждая локальная VM в среднем связывается приблизительно с 10 удаленными VM одновременно, удаленная FDB может содержать приблизительно 128×10 или приблизительно 1289 записей.

На фиг.25 иллюстрируется вариант осуществления схемы 2500 обработки ARP, которая может использоваться в физическом сервере 2300. На основе схемы 2500 обработки ARP VM 2502 может выполнять широковещательную передачу запроса ARP для удаленной VM. Запрос ARP может содержать С-MAC DA (ВС) 2510, который обозначает сообщение широковещательной передачи С-MAC SA (А) 2512 VM 2502, С-VLAN ID 2514 для VLAN VM 2502, полезную нагрузку 2516 ARP и FCS 2518.

Виртуальный коммутатор 2504 (в том же физическом сервере), который может быть выполнен с возможностью перехвата всех сообщений ARP из локальных VM, может перехватывать запрос ARP для удаленной VM. Прокси ARP в виртуальном коммутаторе 2504 может обрабатывать запрос ARP и добавлять заголовок во фрейм для получения расширенного сообщения ARP (ERAP) одноадресной передачи. Фрейм может быть инкапсулирован с использованием MAC-в-MAC, например, аналогично схеме 2400 асимметричной инкапсуляции сетевого адреса. Заголовок может содержать В-MAC DA 2520, В-MAC SA (0) 2522, B-VLAN ID 2524 и I-SID 2526. В-MAC DA 2520 может быть ассоциирован с сервером 2508 ARP в сети. B-VLAN ID 2524 может быть установлен, как C-VLAN ID 2514. I-SID 2526 может использоваться, в случае необходимости или может не использоваться. Сообщение ERAP также может содержать С-MAC DA (Z) 2528, С-MAC SA (А) 2530, C-VLAN ID 2532, полезную нагрузку 2534 ERAP и FCS 2536. Прокси ARP может заменять С-MAC DA (ВС) 2510 и полезную нагрузку ARP 2516 в принятом фрейме на С-MAC DA (Z) 2528 для удаленной VM и полезную нагрузку 2534 ERAP, соответственно, в ERAP. Виртуальный коммутатор 2504 может затем передавать сообщение ERAP в краевой коммутатор 2506.

Краевой коммутатор 2506 может обрабатывать заголовок в сообщении ERAP для получения нового заголовка. Новый заголовок может содержать В-MAC DA (Y) 2540, В-MAC SA (X) 2542, B-VLAN ID 2544 и I-SID 2546. В-MAC SA (X) 2542 может быть установлен в В-MAC АДРЕС (X) краевого коммутатора 2506. B-VLAN ID 2544 может быть изменен, если необходимо, так, чтобы он соответствовал VLAN в сети. Остальные поля в заголовке могут не изменяться. Краевой коммутатор 2506 может затем перенаправлять новое сообщение ERAP в сервер 2508 ARP в сети.

Сервер ARP 2508 может обрабатывать принятое сообщение ERAP и возвращать ответ ERAP в краевой коммутатор 2506. Ответ ERAP может содержать заголовок и фрейм ARP. Заголовок может содержать ВМС (X) DA 2560 для краевого коммутатора 2506, В-MAS SA 2562 сервера 2508ARP, B-VLAN ID 2564 и I-SID 2566. Фрейм ARP может содержать С-MAC (А) DA 2568 для VM 2502, С-MAC SA (Z) 2570 запрашиваемой удаленной VM, C-VLAN ID 2572, полезную нагрузку ERAP 2574 и FCS 2576. Краевой коммутатор 2506 может декапсулировать сообщения ERAP путем удаления заголовка и затем передавать фрейм ARP в виртуальный коммутатор 2504. Виртуальный коммутатор 2504 может обрабатывать фрейм ARP и передавать ответ ARP, соответственно, в VM 2502. Ответ ARP может содержать С-MAC (A) DA 2590 для VM 2502, С-MAC SA (В) 2592, ассоциированный с местоположением удаленной VM, C-VLAN ID 2594, полезную нагрузку 2596 ARP и FCS 2598.

Прокси ARP в виртуальном коммутаторе 2504 также может использовать сообщение ERAP, для заполнения удаленной FDB в краевом коммутаторе 2506. Прокси ARP может заполнять запись в таблице FDB парой из удаленного С-MAC и удаленного коммутатора В-MAC, которая может быть найдена в полезной нагрузке 2574 ERAP. С-MAC и удаленный коммутатор В-MAC могут быть найдены в поле аппаратного адреса отправителя (SHA) и в поле адреса места нахождения отправителя (SLA), соответственно, в полезной нагрузке 2574 ERAP.

Гипервизор в физическом сервере, который содержит виртуальный коммутатор 2504, также может регистрировать VM, например, локальную VM 2502 или удаленную VM, в сервере ARP 2508, аналогично схеме 2500 обработки ARP. В этом случае, виртуальный коммутатор 2504 может передавать фрейм ERAP одноадресной передачи в сервер ARP 2508 со всеми полями отправителя, равными всем целевым полям. Другой способ регистрации VM описан в предварительной заявке на патент США №61/389,747 автора Y. Xiong и др. под названием "A MAC Address Delegation Scheme for Scalable Ethernet Networks with Duplicated Host IP Addresses ", которая представлена здесь по ссылке, как если бы она была воспроизведена здесь полностью. Эта схема может обрабатывать сценарий дублированного адреса IP.

На фиг.26 иллюстрируется вариант осуществления полезной нагрузки 2600 ERAP, которая может использоваться в схеме 2500 обработки ARP, такой как полезная нагрузка 2574 ERAP. Полезная нагрузка 2600 ERAP может содержать тип 2610 аппаратных средств (HTYPE), тип 2612 протокола (PTYPE), длину 2614 аппаратного адреса (HLEN), длину 2616 адреса протокола (PLEN), поле 2618 операции (OPER), SHA 2620, адрес 2622 протокола отправителя (SPA), целевой аппаратный адрес (ТНА) 2624, и целевой адрес 2626 протокола (ТРА), которые могут представлять собой элементы типичного сообщения ARP. Кроме того, полезная нагрузка 2600 ERAP может содержать SLA 2628 и целевой адрес 2630 местоположения (TLA). На фиг.6 также показано смещение в битах для каждого поля в полезной нагрузке 2600 ERAP, на которой также обозначен размер каждого поля в битах.

Одна проблема использования сервера ARP (например, сервера 2508 ARP) и запрета изучения MAC в сети представляет собой, в случае, когда VM становится недоступной, из-за отказа ее краевого коммутатора или соединения, соединяющего сервер ARP с краевым коммутатором. В этом случае, может потребоваться некоторое время для того, чтобы виртуальный коммутатор знал новое местоположение нового или заменяющего краевого коммутатора для VM. Например, если краевой коммутатор Х в физическом сервере 2300 становится недоступным, виртуальный коммутатор 2310 может направлять фреймы из VM1 в краевой коммутатор R, который может стать новым местоположением для VM1.

Для уменьшения времени для обновления удаленной FDB в виртуальном коммутаторе 2310 вокруг нового местоположения VM, может использоваться невызванное сообщение ERAP. Виртуальный коммутатор 2310 может вначале передавать невызванное сообщение ERAP в краевой коммутатор R во фрейме инкапсуляции MAC-в-MAC, включающем в себя набор В-MAC DA для адреса (ВС) широковещательной передачи. В невызванном сообщении SHA ERAP (например, SHA 2620) может быть установлено равным ТНА (например, ТНА 2624), SPA (например, SPA 2622) может быть установлено равным ТРА (например, ТРА 2626), и SLA (например, SLA 2628) может быть установлено равным TLA (например, TLA 2630). Краевой коммутатор R может затем передавать невызванное сообщение ERAP в множество из, или во все другие краевые коммутаторы в сети, например, через дерево распределения. Когда краевой коммутатор получает невызванное сообщение ERAP, краевой коммутатор может декапсулировать сообщения и передать сообщение через порты, обращенные к серверу краевого коммутатора. Когда виртуальный коммутатор затем принимает невызванное сообщение ERAP, виртуальный коммутатор может обновить свою удаленную FDB, если SHA уже существует в удаленной FDB. Сервер ARP в сети может обновлять новое местоположение затронутой VM таким же образом.

Схема асимметричной инкапсуляции сетевого адреса, описанная выше, может использовать инкапсуляцию MAC-в-MAC в одном варианте осуществления. В качестве альтернативы, эта схема может быть расширена до других способов инкапсуляции. Если TRIEL поддерживается и используется в сети, где краевой коммутатор идентифицируется приблизительно 16 битами псевдонимов, инкапсуляция TRILL может использоваться в схеме асимметричной инкапсуляции сетевого адреса. В качестве альтернативы, инкапсуляция IP в-IP может использоваться, если краевой коммутатор идентифицирован адресом IP. Кроме того, инкапсуляция сетевого адреса может быть выполнена на уровне виртуального коммутатора, и декапсуляция сетевого адреса может быть выполнена на уровне краевого коммутатора. В общем, схема инкапсуляции сетевого адреса может применяться на любом уровне или в любых сетевых компонентах, если только инкапсуляция и декапсуляция будут поддерживаться на разных уровнях или в разных компонентах.

В соединенной мостами сети, которая разделена на районы, такие как взаимно соединенные сетевые районы 1800, DBB может представлять собой мост, участвующий во множестве районов. Адрес DBB может быть называться здесь сетевым адресом, для отличия адреса DBB от АДРЕСОВ С-MAC VM в каждом районе. Используя схему асимметричной инкапсуляции адреса, описанную выше, инкапсуляция сетевого адреса может выполняться в коммутаторе, ближе к хост-устройствам или виртуального коммутатора ближе виртуальным хост-устройствам. Например, промежуточные коммутаторы 1824, например, коммутаторы ToR, могут выполнять инкапсуляцию сетевого адреса. Промежуточные коммутаторы 1824 могут инкапсулировать фреймы данных, поступающие из поднаборов хост-устройств и которые содержат адрес целевой DBB. Однако промежуточные коммутаторы 1824 могут не изменять фреймы данных, поступающие со стороны сети, например, DBB 1822 в основном районе 1810. Целевая DBB 1822, которая находится одним уровнем выше промежуточного коммутатора 1824, может декапсулировать фреймы данных со стороны сети (основной район 1810) и перенаправлять декапсулированный фрейм данных в направлении хост-устройств в пределах своего района.

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

Соединенная мостом сеть, соединенная с 1822 DBB (например, основной район 1810), может быть основана на IP. Основная сеть (или район), которая взаимно соединяет DBB, может представлять собой L3 частной виртуальной сети (VPN), L2 VPN или стандартные сети IP. В таких сценариях DBB может инкапсулировать фреймы данных MAC из их локального района с правильным целевым адресом DBB, который может представлять собой заголовок IP или MPLS.

На фиг.27 иллюстрируется вариант осуществления схемы 2700 передачи фрейма данных, которая может использоваться в соединенной мостом сети уровня 2, например, взаимно соединенных сетевых районов 1800. Схема 2700 передачи фрейма данных также может воплощать схему асимметричной инкапсуляции сетевого адреса, описанную выше. Соединенная мостом сеть уровня 2 может содержать основной район 2710, множество DBB 2722 или краевые коммутаторы района во множестве районов 2720, соединенных с основным районом 2710, и множество промежуточных или краевых коммутаторов 2724 и физических серверов 2726, соединенных с соответствующими DBB 2022 в их районах 2720. Физические серверы 2726 могут содержать множество VM и виртуальных коммутаторов (не показаны). Некоторые из DBB 2722, промежуточных/краевых коммутаторов 2724 и физических серверов 2726 в районах 2720 могут принадлежать VLAN, установленной в соединенной мостом сети уровня 2, и ассоциированной с ID VLAN. Компоненты соединенной мостом сети уровня 2 могут быть размещены, как показано на фиг.27.

В соответствии со схемой асимметричной инкапсуляции сетевого адреса, промежуточный/краевой коммутатор 2724 может принимать фрейм 2740, например, фрейм Ethernet, из первой VM (host А) в физическом сервере 2726, в первом районе (district 1). Фрейм 2040 может быть предназначен для второй VM (host В) во втором физическом сервере 2726, во втором районе (district 2). Фрейм 2040 может содержать В-MAC DA 2742 для второй DBB (DBB2) в районе district 2, В-MAC SA 2744 для хост-устройства A (ToR А), С-MAC DA 2746 для хост-устройства В (В), С-MAC SA 2748 для хост-устройства A (A), IP SA 2750 для хост-устройства (A), IP DA 2752 для хост-устройства В (В) и полезную нагрузку. Промежуточный/краевой коммутатор 2724 может перенаправлять фрейм 2040 в первую DBB 2722 (DBB1) в районе 1. DBB1 может принимать и обрабатывать фрейм 2740 для получения внутреннего фрейма 2760. Внутренний фрейм 2760 может содержать В-MAC DA 2762 для DBB2, В-MAC SA 2764 для DBB1, С-MAC DA 2766 для хост-устройства В (В), С-MAC SA 2768 для хост-устройства A (A), IP SA 2770 для хост-устройства A (A), IP DA 2752 для хост-устройства В (В) и полезную нагрузку. DBB1 может затем перенаправлять внутренний фрейм 2760 в район 2 через основной район 2710.

DBB2 в районе 2 может принимать и декапсулировать внутренний фрейм 2740 для получения второго фрейма 2780. DBB2 может удалять В-MAC DA 2762 для DBB2 и В-MAC SA 2764 из внутреннего фрейма 2760, для получения второго фрейма 2780. Таким образом, второй фрейм 2780 может содержать С-MAC DA 2782 для хост-устройства В (В), С-MAC SA 2784 для хост-устройства A (A), IP SA 2786 для хост-устройства A (A), IP DA 2788 для хост-устройства В (В) и полезную нагрузку. DBB2 может передавать второй фрейм 2780 в хост-устройство В в районе 2.

В схеме 2700 направления фрейма данных промежуточный/краевой коммутатор 2724 может не выполнять функцию MAC-в-MAC для фреймов, принимаемых из локальных физических серверов 2724, соединенных с промежуточным/краевым коммутатором 2724. В другом варианте осуществления процедура инкапсуляции первого фрейма 2740 может быть выполнена с помощью виртуального коммутатора в физическом сервере 2726 вместо промежуточного/краевого коммутатора 2724, который может передавать первый фрейм 2740, без обработки физического сервера 2726 в соответствующей DBB 2722.

На фиг.28 иллюстрируется вариант осуществления улучшенного способа 2800 обработки ARP, который может использоваться в соединенной мостом сети уровня 2, такой как взаимно соединенные мостом сетевые районы 1800. Улучшенный способ 2900 обработки ARP может начинаться в этапе 2801, куда локальное хост-устройство 2810 может передавать запрос ARP в локальное местоположение 2830 через первый мост 2820, например, локальную DBB. Локальное местоположение 2830 может соответствовать тому же местоположению или району, что и локальное хост-устройство 2810. Запрос ARP может быть передан для получения MAC адреса, ассоциированного с удаленным хост-устройством 2860. Локальное хост-устройство 2810 может назначить IP адрес IPA и MAC адрес А. Удаленному хост-устройству 2860 может быть назначен IP адрес IPB и MAC адрес В. Запрос ARP может содержать адрес A SA-MAC и SA IPA IP адрес для локального хост-устройства 2810. Запрос ARP может также содержать DA MAC адрес, установленный в ноль, и DA IP адрес IPB для удаленного хост-устройства 2860. Локальное местоположение 2830 может перенаправлять запрос ARP в сервер 2840 ARP в сети.

На этапе 2802, сервер 2840 ARP может передать ответ EARP в первый мост 2820. Ответ EARP может содержать SA MAC адрес А и SA IP адрес IPA для локального хост-устройства 2810, DA MAC адрес В и DA IP адрес IPB для удаленного хост-устройства 2860 и MAC адрес для второго моста в удаленном местоположении 2850 удаленного хост-устройства 2860. На этапе 2803, первый мост 2820 может обрабатывать/декапсулировать ответ EARP и передавать ответ ARP в локальное хост-устройство 2810. Ответ ARP может содержать MAC адрес А и IP адрес IPA для локального хост-устройства 2810, и MAC адрес В и IP адрес IPB для удаленного хост-устройства 2860. Таким образом, локальное хост-устройство 2810 может узнать MAC адрес В удаленного хост-устройства 2860. Первый мост 2820 также может ассоциировать (в локальной таблице) MAC адрес Y удаленного моста в удаленном местоположении 2850 с IP адресом IPB удаленного хост-устройства 2860. Для первого моста 2820 может не потребоваться сохранять MAC адрес В удаленного хост-устройства 2860.

На этапе 2804 локальное хост-устройство 2810 может передавать фрейм данных, предназначенный для удаленного хост-устройства 2860 в первый мост 2820. Этот фрейм данных может содержать адрес SA MAC и SA адрес IP локального устройства 2810, и адрес DA MAC и адрес DA IP удаленного хост-устройства 2860. На этапе 2805 первый мост 2820 может принимать и обрабатывать/инкапсулировать фрейм данных для получения внутреннего фрейма. Внутренний фрейм может содержать SA MAC адрес Х первого моста 2820, DA MAC адрес Y удаленного моста, DA MAC адрес В и DA IP адрес IPB удаленного хост-устройства 2860, и SA MAC адрес А и SA IP адрес IPA локального хост-устройства 2810. На этапе 2806 удаленный мост, в удаленном местоположении 2850, может принимать внутренний фрейм и обрабатывать/декапсулировать внутренний фрейм для получения второго фрейма, путем удаления SA MAC адреса Х первого моста 2820 и DA MAC адреса Y удаленного моста. Таким образом, второй фрейм может быть аналогичен исходному фрейму, переданному из локального хост-устройства 2810. Удаленный мост затем может передавать второй фрейм в удаленное хост-устройство 2860. Способ 2800 может затем заканчиваться.

В способе 2800 улучшенной обработки ARP, главная сеть может использовать 802.1aq или TRILL для определения топологии. Если главная сеть использует 802.1aq для определения топологии, то первый мост 2820 может не инкапсулировать фрейм, переданный из локального хост-устройства 2810, и может перенаправлять фрейм в удаленное местоположение 2850 без обработки. Кроме того, фрейм, переданный через базовую сеть, может быть передан в лавинном режиме только во втором местоположении 2850 и только, когда порт передачи, обозначенный во фрейме, не был определен.

В варианте осуществления расширенная схема разрешения адресов может быть воплощена с помощью шлюзов района или узлов шлюза, которые могут представлять собой краевые узлы TRILL, краевые узлы MAC-в-MAC, или любой другой тип наложенных сетевых краевых узлов. Расширенная схема разрешения адресов может быть основана на схеме прокси ARP, воплощенной в DBB во множестве районов в соединенной мостом сети уровня 2, такой, как схема 1900 прокси ARP. Например, промежуточные/краевые узлы 2724, которые могут быть соединены с множеством физических серверов и/или VM, могут воплощать расширенную схему разрешения адресов, аналогичную схеме прокси ARP, описанной выше. Узел шлюза может использовать сервер DS в схеме прокси ARP для отображения с разложением между целевым местом назначения (например, хост-устройство) и выходным краевым узлом. Выходной краевой узел может представлять собой целевой шлюз в районе, выходной узел TRILL, краевой узел MAC-в-MAC, или любой другой тип наложенного сетевого краевого узла. Ответ из DS может также представлять собой ответ EARP, как описано выше.

Расширенная схема разрешения адресов может использоваться для масштабирования DC сети с существенным количеством хост-устройств. Сеть наложения (например, соединенная мостом сеть) может представлять собой MAC-в-MAC, TRILL или другие типы сетей уровня 3 или уровня 2 через Ethernet. Кромка сети наложения может представлять собой сетевой коммутатор, такой как коммутатор доступа (или коммутатор ToR) или объединения коммутатора (или коммутатора EoR). Кромка сети наложения также может соответствовать виртуальному коммутатору в сервере. Могут присутствовать два сценария для сетей наложения, для использования расширенной схемы разрешения адресов. Первый сценарий соответствует симметричной схеме, такой сети TRILL или MAC-в-MAC. В этом сценарии узел кромки наложения может выполнять, как пути инкапсуляции, так и декапсуляции. Второй сценарий соответствует асимметричной схеме, где сеть наложения может воплощать асимметричную схему инкапсуляции сетевого адреса, описанную выше.

На фиг.29 иллюстрируется вариант осуществления расширенного способа 2900 разрешения адресов, который может быть воплощен в сети наложения. Расширенный способ 2900 разрешения адресов может начинаться на этапе 2901, где первая VM 2910 (VM А) может передавать фрейм или пакет, адресованный во вторую VM 2980 (VM В), в первый коммутатор шлюза или гипервизор (HV) 2920 (HV А). VM А и VM В могут представлять собой конечные хост-устройства в разных районах. VM А может быть соединена с HV в первом районе, и VM В может быть соединена со вторым коммутатором шлюза или HV 2970 (HV В) во втором районе. HV может представлять собой узел сети наложения, выполненный с возможностью инкапсулировать или добавлять заголовок адреса сети наложения на фрейм данных или пакет. В сценарии симметричной схемы HV может представлять собой DBB, краевой узел TRILL или краевой узел MAC-в-MAC. В сценарии асимметричной схемы HV может представлять собой виртуальный коммутатор в пределах гипервизора, коммутатор шлюза или коммутатор доступа.

На этапе 2902 HV А может передавать запрос разрешения адресов (AR) в сервер 2930 ARP для выполнения пары отображений из VM В IP адреса в VM В MAC адрес и HV В MAC адреса, в случае симметричной схемы. Сервер ARP может содержать сервер DS или соответствовать ему, такому как DS 1940. В асимметричной схеме отображение может осуществляться из VM В IP адреса в пару из VM В MAC адреса и адреса MAC второй DBB 2960 (DBB В). DBB В может представлять собой удаленную DBB в том же районе, что и VM В.

HV А также может быть выполнен с возможностью перехватывать (переданные в режиме широковещательной передачи) запросы ARP из локальных VM и перенаправлять эти запросы ARP в сервер DS. HV А может затем получать ответы EARP из сервера DS и размещать в кэш отображения между целевыми адресами и адресами целевого шлюза (как обозначено в ответах EARP). Адрес целевого шлюза также может называться здесь адресом целевого местоположения. В другом варианте осуществления, вместо перехвата запросов ARP с помощью HV А, сервер DS может передавать объединенную информацию отображения в HV на регулярной или периодической основе, или когда VM перемещаются или мигрируют между районами. Объединенная информация отображения может содержать одну и ту же информацию, обмен которой выполняют с L2GWs в виртуальных сетях уровня 2, описанных выше. Например, объединенная информация отображения может быть сформатирована, как невызванные групповые объявления, как описано выше.

На этапе 2903, HV А может формировать внутренний заголовок адреса, который содержит (SA: VM MAC, DA: VM В MAC) и внешний заголовок, который содержит (SA: HV MAC, DA: HV В MAC), в случае симметричной схемы. В асимметричной схеме внешний заголовок может содержать (SA: HV MAC, DA: DBB В MAC). HV А может добавлять внутренний заголовок и внешний заголовок к фрейму, принятому из VM А, и передавать полученный в результате фрейм в мост 2940, соединенный с HV в том же районе. В пределах района может быть не известен DA внешнего заголовка, который может представлять собой HV В MAC или DBB В MAC.

На этапе 2904 фрейм может быть передан из моста 2940 в первую DBB 2950 (DBB А) в районе. В DBB А могут быть известны DA HV В MAC или DBB В MAC, поскольку ядро может работать, выполняя передачу по установленному маршруту (например, 802. laq SPBM или TRILL), и изучение может быть не разрешено в ядре. На этапе 2905 DBB А может перенаправлять фрейм в DBB В.

На этапе 2906 DBB В может направлять фрейм в HV В, поскольку DBB может знать все адреса HV из подсистемы маршрутизации, в случае симметричной схемы. В асимметричной схеме DBB может удалять внешний заголовок, содержащий (DA: DBB MAC), и перенаправлять фрейм в VM В MAC в остальном заголовке, поскольку адреса, локальные для района, могут быть зарегистрированы и известны в пределах района.

На этапе 2907 HV В может принимать фрейм, удалять внешний заголовок, содержащий (DA: HV В MAC), и направлять полученный в результате фрейм в VM В MAC в остальном заголовке, поскольку адреса, локальные для сервера, известны для HV В, в случае симметричной схемы. Кроме того, HV В может определять отображение из VM MAC (SA в остающемся заголовке) для HV MAC (SA в удаленном заголовке), который может впоследствии использоваться во фреймах ответ из VM В в VM А. В асимметричной схеме, в дополнение к передаче фрейма в VM В, HV В может передавать сообщение ARP в сервер 2930ARP (или DS), для получения отображения из VM MAC (SA в остальном заголовке) в DBB A MAC, который может впоследствии использоваться в ответных фреймах из VM В в VM А.

VM В может затем передавать фреймы, адресованные в VM А (адрес назначения IP). На этапе 2908 HV В может сформировать внутренний заголовок адреса, который содержит (SA: VM В MAC, DA: VM A MAC) и внешний заголовок, который содержит (SA: HV В MAC, DA: HV A MAC) для фрейма, в случае симметричной схемы. HV В может поддерживать VM A IP для отображения VM A MAC и VM MAC для отображения HV A MAC из ранее принятого сообщения или ответа AR. В асимметричной схеме внешний заголовок может содержать (SA: HV В MAC, DA: DBB A MAC). HV В может поддерживать VM A MAC для отображения DBB A MAC из ранее полученного ответа AR. В качестве альтернативы, HV В может передавать сообщение ARP в сервер ARP (или DS), для получения отображения в случае необходимости. Фрейм может быть затем передан из VM В в VM А таким же образом, как описано на этапах, представленных выше (например, в обратном направлении). Способ 2900 может затем заканчиваться.

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

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

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

Удаление заголовка из входящих фреймов из удаленных s может уменьшать размер формируемой таблицы адреса в локальных коммутаторах, которые используют для перенаправления фреймов в локальные узлы. FDB или FIB в локальных коммутаторах могут не требовать записей для удаленных шлюзов и удаленных узлов, расположенных после удаленных шлюзов. FDB или FIB локальных коммутаторов, расположенные после шлюза, могут содержать записи всех локальных узлов, расположенных после множества локальных шлюзов, включая в себя этот шлюз. Коммутатор может также содержать прокси ARP, выполненный с возможностью обработки запросов ARP/ND из локальных узлов.

На фиг.30 иллюстрируется вариант осуществления модуля 3000 сетевого компонента, который может представлять собой любое устройство, которое передает/принимает пакеты через сеть. Например, модуль 3000 компонента сети может быть расположен в L2GW с охватом разных мест положения/областей в виртуальных/сетях псевдоуровня 2. Модуль 3000 сетевого компонента может содержать один или больше входных портов или модулей 3010 для приема пакетов, объектов или TLV из других сетевых компонентов, логическую схему 3020 для определения в какие сетевые компоненты следует передать эти пакеты, и один или больше исходящих портов или модулей 3030, для передачи фреймов в другие сетевые компоненты.

Сетевые компоненты, описанные выше, могут быть воплощены в любом сетевом компоненте общего назначения, таком как компьютерная система или компонент сети с достаточной мощностью обработки, ресурсами памяти и возможностью передачи данных через сеть для обработки с необходимой рабочей нагрузкой, помещенной на ней. На фиг.31 иллюстрируется типичная, компьютерная система 3100 общего назначения, пригодная для воплощения одного или больше вариантов осуществления компонентов, раскрытых здесь. Компьютерная система 3100 общего назначения включает в себя процессор 3102 (который может называться CPU), который сообщается с запоминающими устройствами, включающими в себя второй накопитель 3104 информации, постоянное запоминающее устройство (ROM) 3106, оперативное запоминающее устройство (RAM) 3108, устройства 3110 ввода/вывода (I/O), и устройство 3112 сетевого соединения. Процессор 3102 может быть воплощен, как одна или больше микросхем CPU, или может составлять часть одной или больше специализированных интегральных микросхем (ASIC).

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

По меньшей мере, один вариант осуществления был описан выше и варианты, комбинации и/или модификации варианта (вариантов) осуществления и/или свойств варианта (вариантов) осуществления, которые могут быть выполнены специалистом с обычными навыками в данной области техники, будут находиться в пределах объема раскрытия. Альтернативные варианты осуществления, которые могут быть получены в результате комбинирования, интегрирования и/или исключения особенностей варианта (вариантов) осуществления, также находятся в пределах раскрытия. Когда цифровые диапазоны или ограничения будут установлены в явном виде, такие специальные диапазоны или ограничения следует понимать, как включающие в себя итеративные диапазоны или ограничения или как магнитуды, попадающие в явном виде в установленные диапазоны или ограничения (например, от приблизительно 1 до приблизительно 10 включает в себя 2, 3, 4, и т.д.; больше чем 0,10 включает в себя 0,11, 0,12, 0,13 и т.д.). Например, всякий раз, когда раскрыт цифровой диапазон с нижним пределом R₁ и верхним пределом R_u, любое число, находящееся в пределах этого диапазона, в частности, раскрыто. В частности, следующие числа в пределах диапазона, в частности, раскрыты: R=R₁+k*(R_u-R₁), где k представляет собой переменную в диапазоне от 1 процента до 100 процентов с приращением в 1 процент, то есть, k равно 1 процент, 2 процента, 3 процента, 4 процента, 7 процентов, …, 70 процентов, 71 процент, 72 процента, …, 97 процентов, 96 процентов, 97 процентов, 98 процентов, 99 процентов, или 100 процентов. Кроме того, любой цифровой диапазон, определенный двумя числами R, как определено и описано выше, также, в частности, раскрыт.Использование термина "в случае необходимости" в отношении любого элемента пункта формулы изобретения означает, что этот элемент требуется, или, в качестве альтернативы, этот элемент не требуется, причем обе альтернативы находятся в пределах объема пункта формулы изобретения. Использование более широких терминов, таких как: содержит, включает в себя, и имеющий, следует понимать, как предоставление поддержки для более узких терминов, таких как состоящий из, состоящий в частности из, и состоящий по существу из. В соответствии с этим, объем защиты не ограничивается описанием, изложенным выше, но определен формулой изобретения, которая следует ниже, этот объем, включает в себя все эквиваленты предмета изобретения, представленные в формуле изобретения. Каждый пункт формулы изобретения представлен, как дополнительное раскрытие в описании и в формуле изобретения, и представляет собой вариант (варианты) осуществления настоящего раскрытия. Описание ссылки в раскрытии не является признанием того, что она представляет собой предшествующий уровень техники, в частности, любой ссылки, которая была опубликована в день после даты приоритета данной заявки. Раскрытие всех патентов, патентных заявок и публикаций, указанных в раскрытии, тем самым представлено здесь по ссылке, в такой степени, что они обеспечивают примерные, процедурные или другие детали, вспомогательные для раскрытия.

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

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

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

1. Устройство с виртуальным коммутатором (2404), характеризующееся тем, что выполнено с возможностью:
приема при работе в восходящем направлении от первой виртуальной машины (2402) при помощи виртуального коммутатора (2404) фрейма, отправленного от первой виртуальной машины (2402) на вторую виртуальную машину, добавления к фрейму первого заголовка и отправки фрейма с первым заголовком на краевой коммутатор (2406); и
приема при работе в нисходящем направлении от краевого коммутатора (2406) при помощи виртуального коммутатора (2404) фрейма, отправленного от второй виртуальной машины к первой виртуальной машине (2402), при этом заголовок удален краевым коммутатором (2406), и передачи фрейма без удаленного заголовка на первую виртуальную машину.

2. Устройство по п.1, в котором при работе в восходящем направлении краевой коммутатор (2406) выполнен с возможностью приема фрейма от виртуального коммутатора (2404), обработки первого заголовка для получения второго заголовка во фрейме и передачи фрейма со вторым заголовком через сетевое ядро (2808) на вторую виртуальную машину.

3. Устройство по п.1, в котором поле адреса источника во втором заголовке во фрейме представляет собой прокси-адрес или адрес-делегат.

4. Устройство по п.1, в котором виртуальный коммутатор (2404) выполнен с возможностью пересылки декапсулированных фреймов данных в локальную виртуальную машину (2402) на основе баз данных пересылки (FDB) краевого коммутатора.

5. Устройство по п.1, в котором таблицы пересылки краевого коммутатора (2406) содержат локальную базу данных пересылки (FDB) для локальных виртуальных машин и удаленную FDB для удаленных виртуальных машин.

6. Устройство по п.5, в котором FDB для локальных виртуальных машин краевого коммутатора (2406) содержит записи для локальных виртуальных машин.

7. Устройство по п.1, в котором виртуальный коммутатор (2404) содержит прокси протокола разрешения адресов (ARP), выполненный с возможностью обработки запросов ARP/обнаружения соседей (ND) от локальных виртуальных машин.

8. Устройство по п.1, в котором исходящие фреймы инкапсулированы с использованием управления доступом к среде (MAC) - в - MAC в соответствии со стандартом Института инженеров по электронике и радиотехнике (IEEE) 802.1 ah, при этом первый заголовок содержит адрес MAC для целевого местоположения, отображенного на целевое место назначения исходящих фреймов.

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

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

11. Устройство с краевым коммутатором (2406), характеризующееся тем, что выполнено с возможностью:
приема при работе в восходящем направлении от виртуального коммутатора (2404) при помощи краевого коммутатора (2406) фрейма, отправленного от первой виртуальной машины (2402) на вторую виртуальную машину, к которому виртуальный коммутатор добавил первый заголовок, обработки первого заголовка для получения второго заголовка во фрейме и передачи фрейма со вторым заголовком через сетевое ядро (2408) на вторую виртуальную машину; и
приема при работе в нисходящем направлении от сетевого ядра (2408) при помощи краевого коммутатора (2406) фрейма, отправленного от второй виртуальной машины на первую виртуальную машину (2402), удаления заголовка из фрейма и передачи фрейма на виртуальный коммутатор (2404).

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

13. Устройство по п.11, в котором поле адреса источника во втором заголовке во фрейме представляет собой прокси-адрес или адрес-делегат.

14. Устройство по п.11, в котором таблицы пересылки краевого коммутатора (2406) содержат локальную базу данных пересылки (FDB) для локальных виртуальных машин и удаленную FDB для удаленных виртуальных машин.

15. Устройство по п.14, в котором FDB для локальных виртуальных машин краевого коммутатора (2406) содержит записи для локальных виртуальных машин.

16. Устройство по п.11, в котором исходящие фреймы инкапсулированы с использованием управления доступом к среде (MAC) - в - MAC в соответствии со стандартом Института инженеров по электронике и радиотехнике (IEEE) 802.1 ah, при этом первый заголовок содержит адрес MAC для целевого местоположения, отображенного на целевое место назначения исходящих фреймов.

17. Устройство по п.11, в котором исходящие фреймы инкапсулированы с использованием прозрачного взаимного соединения множества связей (TRILL), при этом заголовок содержит псевдоним размером приблизительно 16 битов для целевого местоположения, отображенного на адрес целевого места назначения исходящих фреймов.

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