Способ и система для обновления состояний распределенного отказоустойчивого сетевого межсоединения (drni)

Авторы патента:

САЛЬТСИДИС, Панагиотис (SE)

H04L12/709 - Сети переключения сигналов (передачи данных) (соединение запоминающих устройств, устройств ввода-вывода или центральных процессоров или передача информации или других сигналов между указанными устройствами G06F 13/00)

Владельцы патента RU 2620995:

ТЕЛЕФОНАКТИЕБОЛАГЕТ Л М ЭРИКССОН (ПАБЛ) (SE)

Изобретение относится к конфигурированию набора идентификаторов (ID) диалогов на сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Технический результат – улучшение предоставления услуг конечным пользователям, в частности, через DRNI. Для этого способ начинается с инициализации набора ID диалогов, при этом инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства. Способ продолжается определением того, что распределение набора ID диалогов нуждается в обновлении, установкой значений операционного вектора, индексированного посредством ID диалогов, и установкой значений булева вектора, причем булев вектор перечисляет, ассоциирован ли один шлюз или один агрегатор сетевого устройства с каждым из ID диалогов. 6 н. и 33 з.п. ф-лы, 44 ил., 9 табл.

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

[0001] Варианты осуществления настоящего изобретения в целом относятся к агрегированию каналов и, более конкретно, относятся к способам и устройству для реализации распределенного отказоустойчивого сетевого межсоединения (DRNI) для группы агрегирования каналов (LAG).

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

[0002] Как показано на фиг. 1А, агрегирование каналов является сетевой конфигурацией и процессом, используемым для агрегирования множества каналов между парой узлов 120, 122 в сети для того, чтобы передавать пользовательские данные по каждому из каналов, участвующих в группе агрегирования каналов (LAG) 101 (см., например, стандарт 802.1 AX Института инженеров по электротехнике и электронике (IEEE)). Агрегирование множества сетевых соединений таким образом может увеличить пропускную способность сверх того, что может поддерживать одно соединение, и/или может быть использовано для обеспечения устойчивости в случае выхода из строя одного из каналов. "Распределенное отказоустойчивое сетевое межсоединение" (DRNI) 102 (см. раздел 8 IEEE P802.1AX-REV^TM/D1.0, под названием "Draft Standard for Local and Metropolitan Area Networks - Link Aggregation", от 1 февраля 2013, настоящим включенный во всей своей полноте посредством ссылки) определяет расширения для агрегирования каналов, чтобы иметь возможность использовать агрегирование каналов на сетевом интерфейсе, даже между более чем двумя узлами, например, между четырьмя узлами К, L, M и O, как показано на фиг. 1В.

[0003] Как показано на фиг. 1B, LAG сформирована между сетью 150 и сетью 152. Более конкретно, LAG сформирована между виртуальными узлами или "порталами" 112, 114 LAG. Первый виртуальный узел или портал 112 LAG включает в себя первый узел (К) и второй узел (L). Второй виртуальный узел или портал 114 LAG включает в себя третий узел (М) и четвертый узел (O). Эти узлы также могут упоминаться как "портальные системы". Следует отметить, что как первый, так и второй виртуальные узлы или порталы 112, 114 LAG могут включать в себя один или более двух узлов в портале. Узлы К и М LAG соединены как одноранговые узлы, и узлы L и О LAG также соединены как одноранговые узлы. Как используется в данной заявке, "виртуальный узел LAG " относится к порталу DRNI в IEEE документации, упомянутой выше (то есть, два или более узлов, которые представляются как один узел их соответствующим одноранговым узлам). Кроме того, утверждение, что виртуальный узел или портал 112 "включает в себя" два узла K, L означает, что виртуальный узел или портал 112 эмулирован узлами К, L, это может упоминаться как "эмулированная система". Аналогично, утверждение, что виртуальный узел или портал 114 "включает в себя" два узла M, O означает, что виртуальный узел или портал 114 эмулирован узлами М, О. Отметим, что группа 161 агрегирования каналов образована между каналами К-М и L-О.

[0004] Множество узлов, участвующих в LAG, представляются как один и тот же виртуальный узел или портал с одним системным ID для их одноранговых партнеров в LAG. Системный ID используется для идентификации каждого узла (например, узла К, узла L, узла М и узла О). Системный ID включен в протокольные блоки данных управления агрегированием каналов (LACPDU), передаваемые между отдельными узлами-партнерами LAG (например, между К и М или между L и O). Системный ID может быть сгенерирован на основе идентификаторов компонентных узлов портала с использованием любого индивидуального идентификатора или любой их комбинации. Общий и уникальный системный ID для соответствующего виртуального узла или портала LAG может быть последовательно генерируемым. Таким образом, как показано на фиг. 1В, узел К и узел L принадлежат к той же сети 150 и они являются частью одного и того же портала 112 DRNI (т.е., того же самого виртуального узла LAG), и используют общий системный ID "К" для эмулируемого виртуального узла 112 LAG. Точно так же, Узлы М и О сети 152 рассматриваются узлами К и L как единый виртуальный узел или портал 114 LAG с системным ID "M".

[0005] Фиг. 1В также показывает распределение каналов DRNI конкретной услуги (см. показанный жирной линией канал между К и М на фиг. 1B). Выделенный канал является рабочим каналом между двумя рабочими узлами К и М для конкретной услуги, в то время как невыделенный канал может быть предоставлен в качестве канала защиты между двумя узлами L и О защиты. Распределение услуг интерфейса может затрагивать виртуальную локальную сеть (VLAN), и идентификатор услуги может являться идентификатором VLAN (VID), таким как VID услуги (т.е., "S-VID") (как правило, идентифицирующим услуги на межсетевых Интерфейсах (NNI)) или клиентским VID (т.е. "С-VID") (как правило, идентифицирующим услуги на интерфейсах между пользователем и сетью (UNI)). (Отметим, что магистральные VID неотличимы от S-VID, так как они имеют один и тот же Ethertype.) В примере по фиг. 1B, услуга выделена верхнему каналу (между верхними узлами К, М). Верхний канал, таким образом, выбран в качестве “рабочего” канала, а нижний канал (между узлами L, O) является "резервным" каналом или каналом "защиты". Распределение каналов услуг, т.е., использование того же физического канала для передачи кадра в прямом и в обратном направлениях является весьма желательным.

[0006] В то время как фиг. 1B показывает порталы 112 и 114 DRNI, каждый из которых содержит два узла, порталы DRNI не ограничены таким образом. Каждый портал может содержать от одного до трех узлов. Фиг. 1C иллюстрирует DRNI в альтернативном варианте осуществления. Ссылаясь на фиг. 1С, группа 131 агрегирования каналов содержит портал 142 (одно сетевое устройство 130) на одном конце и портал 144 (два сетевых устройства 132 и 134) на другом конце. Также отметим, что фиг. 1С показывает распределение каналов DRNI конкретной услуги (см. показанный жирной линией канал между сетевыми устройствами 130 и 134). Выделенный канал является рабочим каналом между двумя рабочими узлами (сетевыми устройствами 130 и 134) для конкретной услуги, в то время как невыделенный канал может предоставляться в качестве канала защиты между двумя узлами защиты (сетевыми устройствами 130 и 132). Рабочий узел является одиночным узлом в этой конфигурации, но он может содержать различные наборы портов агрегирования для соединения рабочих каналов и каналов защиты между порталами 142 и 144.

[0007] Провайдеры услуг используют различные варианты групп агрегирования каналов (такие как показанные на фиг. 1А-C и другие альтернативные системы DRNI) для предоставления услуг конечным пользователям. Как предоставлять услуги, в частности, через систему DRNI, является непростой задачей.

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

[0008] Раскрыт способ конфигурирования набора идентификаторов (ID) диалогов на сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Каждый ID диалога для идентификации диалога имеет упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством через внутри-портальный порт (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Способ начинается с инициализации набора ID диалогов на сетевом устройстве, при этом инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства. Способ продолжается определением того, что распределение набора ID диалогов нуждается в обновлении, установкой значений операционного вектора, индексированного посредством ID диалогов, причем операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, и установкой значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли один шлюз или один агрегатор сетевого устройства с каждым из ID диалогов.

[0009] Раскрыто сетевое устройство, конфигурирующее набор идентификаторов (ID) диалогов в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством через внутри-портальный порт (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Сетевое устройство содержит порты, связанные с физическим каналом или каналом агрегирования группы агрегирования каналов, и сетевой процессор, связанный с портами, причем порты включают в себя порты агрегирования. Сетевой процессор выполняет функцию DRNI. Функция DRNI действует, чтобы инициализировать набор ID диалогов на сетевом устройстве, при этом инициализация включает в себя установку элементов операционного булева вектора, ассоциированного с набором ID диалогов, как последовательность нулей, и при этом операционный булев вектор включает в себя индикацию значений, указывающих обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства, далее действует, чтобы определять, что распределение набора ID диалогов нуждается в обновлении, далее действует, чтобы устанавливать значения операционного вектора, индексированного посредством ID диалогов, причем операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, и далее действует, чтобы устанавливать значения булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли один шлюз или один агрегатор сетевого устройства с каждым из набора ID диалогов.

[0010] Раскрыт невременный (не-транзиторный) машиночитаемый носитель хранения данных для конфигурирования набора идентификаторов (ID) диалогов в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Носитель хранения данных содержит инструкции, сохраненные в нем, которые, при исполнении процессором, побуждают процессор выполнять операции. Каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством через внутри-портальный порт (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Операции начинаются с инициализации набора ID диалогов на сетевом устройстве, при этом инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства. Операции продолжаются определением того, что распределение набора ID диалогов нуждается в обновлении, установкой значений операционного вектора, индексированного посредством ID диалогов, причем операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, и установкой значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли один шлюз или один агрегатор сетевого устройства с каждым из ID диалогов.

[0011] Раскрыт другой способ конфигурирования набора идентификаторов (ID) диалогов на сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством посредством внутри-портального порта (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализуют агрегирование каналов, включающее в себя порты агрегирования, с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Способ начинается с инициализации набора ID диалогов на сетевом устройстве, причем инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством IPP. Способ продолжается определением того, что распределение набора ID диалогов нуждается в обновлении. Способ продолжается установкой значений первого операционного вектора, индексированного посредством ID диалогов, причем первый операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено сетевым устройством, установкой значений второго операционного вектора, индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено соседним сетевым устройством, и установкой значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли IPP сетевого устройства с каждым из ID диалогов.

[0012] Раскрыто другое сетевое устройство, конфигурирующее набор идентификаторов (ID) диалогов в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством посредством внутри-портального порта (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования, с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Сетевое устройство содержит порты, связанные с физическим каналом или каналом агрегирования группы агрегирования каналов, и сетевой процессор, связанный с портами, причем порты включают в себя порты агрегирования. Сетевой процессор выполняет функцию DRNI. Функция DRNI действует, чтобы инициализировать набор ID диалогов на сетевом устройстве, причем инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством IPP, далее действует, чтобы определять, что распределение набора ID диалогов нуждается в обновлении, далее действует, чтобы устанавливать значения первого операционного вектора, индексированного посредством ID диалогов, причем первый операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено сетевым устройством, далее действует, чтобы устанавливать значения второго операционного вектора, индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из множества ID диалогов, как назначено соседним сетевым устройством, и далее действует, чтобы устанавливать значения булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли IPP сетевого устройства с каждым из ID диалогов.

[0013] Раскрыт другой невременный (не-транзиторный) машиночитаемый носитель хранения данных для конфигурирования набора идентификаторов (ID) диалогов в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов. Носитель хранения данных содержит инструкции, сохраненные в нем, которые, при исполнении процессором, побуждают процессор выполнять операции. Каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров. Сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством посредством внутри-портального порта (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования, с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала. Операции начинаются с инициализации набора ID диалогов на сетевом устройстве, причем инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством IPP. Способ продолжается определением того, что распределение набора ID диалогов нуждается в обновлении. Операции продолжаются установкой значений первого операционного вектора, индексированного посредством ID диалогов, причем первый операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено сетевым устройством, установкой значений второго операционного вектора, индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено соседним сетевым устройством, и установкой значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли IPP сетевого устройства с каждым из ID диалогов.

[0014] Компьютерная программа для конфигурирования набор идентификаторов диалог (ID) в распределенном отказоустойчивом сетевом межсоединении (DRNI) содержит инструкции, которые, при исполнении по меньшей мере одним процессором, побуждают по меньшей мере один процессор выполнять способы, описанные выше.

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

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

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

[0017] Фиг. 1А является схематичным представлением одного варианта осуществления группы агрегирования каналов между двумя сетевыми устройствами.

[0018] Фиг. 1B является схематичным представлением одного варианта осуществления двух порталов, соединяющих две сети с помощью группы агрегирования каналов.

[0019] Фиг. 1C является схематичным представлением другого варианта осуществления двух порталов, соединяющих две сети с помощью группы агрегирования каналов.

[0020] Фиг. 2 является схематичным представлением одного варианта осуществления подуровня агрегирования каналов.

[0021] Фиг. 3А является схематичным представлением одного варианта осуществления базовой распределенной ретрансляторной системы.

[0022] Фиг. 3В является схематичным представлением одного варианта осуществления эмулированной системы, созданной из двух портальных систем.

[0023] Фиг. 4 является схематичным представлением одного варианта осуществления двух функций DR распределенной ретрансляции.

[0024] На фиг. 5 показана схема структуры данных DRCPDU.

[0025] На фиг. 6А показана диаграмма состояния протокола управления распределенной ретрансляцией (DRCP).

[0026] На фиг. 6В показана схема одного варианта осуществления DRCP.

[0027] На фиг. 6С показано поле состояния топологии структуры DRCPDU согласно одному варианту осуществления настоящего изобретения.

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

[0029] Фиг. 8 является блок-схемой, иллюстрирующей конечный автомат для автомата приема.

[0030] Фиг. 9 является блок-схемой, иллюстрирующей конечный автомат для периодической передачи.

[0031] Фиг. 10 является блок-схемой, иллюстрирующей автомат портальной системы.

[0032] Фиг. 11 является блок-схемой, иллюстрирующей операцию автомата DRNI и агрегатора.

[0033] Фиг. 12 является блок-схемой, иллюстрирующей состояние автомата DRNI IPP.

[0034] Фиг. 13 является схематичным представлением одного варианта осуществления сетевого устройства, реализующего DRNI.

[0035] Фиг. 14 является другой схемой структуры данных DRCPDU согласно одному варианту осуществления изобретения.

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

[0037] Фиг. 16 является другой блок-схемой, иллюстрирующей конечный автомат для автомата приема в соответствии с одним вариантом осуществления изобретения.

[0038] Фиг. 17 является другой блок-схемой, иллюстрирующей конечный автомат для периодической передачи в соответствии с одним вариантом осуществления изобретения.

[0039] Фиг. 18 является другой блок-схемой, иллюстрирующей автомат портальной системы в соответствии с одним вариантом осуществления изобретения.

[0040] Фиг. 19 является блок-схемой, иллюстрирующей операции узла DRCP после потери связи с его соседним узлом в соответствии с одним вариантом осуществления изобретения.

[0041] Фиг. 20 является блок-схемой, иллюстрирующей действие узла DRCP в координации с его соседним узлом после приема множества потоков трафика в соответствии с одним вариантом осуществления изобретения.

[0042] Фиг. 21 является схематичным представлением портальной топологии согласно одному варианту осуществления изобретения.

[0043] Фиг. 22 является блок-схемой конечного автомата приема порта агрегатора согласно одному варианту осуществления изобретения.

[0044] Фиг. 23 является блок-схемой конечного автомата распределения шлюза согласно одному варианту осуществления изобретения.

[0045] Фиг. 24 является блок-схемой конечного автомата приема IPP N согласно одному варианту осуществления изобретения.

[0046] Фиг. 25 является еще одной схемой структуры данных DRCPDU согласно одному варианту осуществления изобретения.

[0047] Фиг. 26А иллюстрирует TLV маски диалога для порта агрегирования согласно одному варианту осуществления изобретения.

[0048] Фиг. 26В иллюстрирует поле состояния маски диалога в TLV маски диалога порта агрегирования согласно одному варианту осуществления изобретения.

[0049] Фиг. 27 иллюстрирует операцию узла DRCP в координации с соседним узлом при условии отказа связи в одном варианте осуществления изобретения.

[0050] Фиг. 28 иллюстрирует операцию узла DRCP после отказа связи согласно одному варианту осуществления изобретения.

[0051] Фиг. 29 представляет другое поле состояния топологии структуры DRCPDU согласно одному варианту осуществления изобретения.

[0052] Фиг. 30 иллюстрирует автомат совместного использования сети/IPL согласно одному варианту осуществления изобретения.

[0053] Фиг. 31 иллюстрирует способ для совместного использования сети/IPL в узле согласно варианту осуществления изобретения.

[0054] Фиг. 32 иллюстрирует способ связи посредством кадра, содержащего структуру DRCPDU, согласно одному варианту осуществления изобретения.

[0055] Фиг. 33 иллюстрирует способ синхронизации с соседом в узле группы агрегирования каналов DRNI согласно варианту осуществления изобретения.

[0056] Фиг. 34 иллюстрирует способ для обновления операционных состояний узла в распределенном отказоустойчивом сетевом межсоединении (DRNI) согласно варианту осуществления изобретения.

[0057] Фиг. 35 иллюстрирует способ конфигурирования набора ID диалогов для агрегатора или шлюза на узле DRCP в распределенном отказоустойчивом сетевом межсоединении (DRNI) согласно варианту осуществления изобретения.

[0058] Фиг. 36 иллюстрирует способ конфигурирования набора ID диалогов для IPP на узле DRCP в распределенном отказоустойчивом сетевом межсоединении (DRNI) согласно варианту осуществления изобретения.

Подробное описание

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

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

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

[0062] Термины

[0063] Следующие термины могут быть использованы в описании.

[0064] Исполнитель (узел-оператор): Локальный объект (то есть, узел или сетевое устройство) в обмене протокола управления агрегированием каналов (LACP).

[0065] Ключ агрегирования: Параметр, ассоциированный с каждым портом агрегирования и с каждым агрегатором системы агрегирования, идентифицирующий те порты агрегирования, которые могут быть агрегированы вместе. Порты агрегирования в системе агрегирования, которые совместно используют тот же самый ключ агрегирования, потенциально способны агрегироваться вместе.

[0066] Порт агрегирования: точка доступа к услуге (SAP) в системе агрегирования, которая поддерживается агрегатором.

[0067] Система агрегирования: однозначно идентифицируемый объект, содержащий (среди прочего) произвольную группировку из одного или более портов агрегирования для целей агрегирования. Экземпляр агрегированного канала всегда возникает между двумя системами агрегирования. Физическое устройство может содержать систему агрегирования сигналов или более одной системы агрегирования.

[0068] Клиент агрегирования: Иерархический объект непосредственно над подуровнем агрегирования каналов, для которого подуровень агрегирования каналов обеспечивает экземпляр услуг внутреннего подуровня (ISS).

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

[0070] ID диалога: Идентификатор, использующий значения (например, в диапазоне от 0 до 4095), чтобы идентифицировать диалог.

[0071] Оконечное оборудование данных (DTE): Любой источник или получатель данных, соединенный с локальной сетью.

[0072] Распределенный ретранслятор (DR): Функциональный объект, распределенный по порталу посредством функции DR в каждой из систем агрегирования, содержащих портал, который распределяет исходящие кадры из шлюзов на агрегаторы, и распределяет входящие кадры из агрегаторов на шлюзы.

[0073] Распределенное отказоустойчивое сетевое межсоединение (DRNI): Агрегирование каналов, расширенное для включения каждого из портала и системы агрегирования или двух (или более) порталов.

[0074] Функция DR: Часть распределенного ретранслятора, находящаяся в одной портальной системе.

[0075] Шлюз: Соединение, как правило, виртуальное (не физический канал между системами), соединяющее распределенный ретранслятор с системой, состоящее из канала шлюза и двух портов шлюза.

[0076] ID диалога шлюза: Значение ID диалога, которое используется для выбора кадров, проходящих через шлюз.

[0077] Услуга внутреннего подуровня (ISS): Расширенная версия услуги MAC, определенная в IEEE Std 802.1AC-2012.

[0078] Внутри-портальный канал (IPL): канал, используемый для соединения функций DR, содержащих распределенный ретранслятор.

[0079] Группа агрегирования каналов (LAG): группа каналов, которые представляются клиенту агрегатора, как если бы они были одним каналом. Группа агрегирования каналов может соединять две системы агрегирования, систему агрегирования и портал или два портала. Один или более диалогов могут быть ассоциированы с каждым каналом, который является частью группы агрегирования каналов.

[0080] Партнер: Удаленный объект (т.е. узел или сетевое устройство) в обмене по протоколу управления агрегированием каналов.

[0081] Идентификатор (ID) диалога порта: Значение идентификатора диалога, которое используется, чтобы выбирать кадры, проходящие через порт агрегирования.

[0082] Портал: Один конец DRNI, включающий в себя одну или более систем агрегирования, каждая с физическими каналами, которые вместе составляют группу агрегирования каналов. Системы агрегирования портала кооперируются, чтобы эмулировать присутствие единой системы агрегирования, к которой присоединена вся группа агрегирования каналов.

[0083] Номер портальной системы: Целое число (например, от 1 до 3 включительно), уникально идентифицирующее портальную систему в пределах ее портала.

[0084] Алгоритм выбора: Алгоритм, используемый для назначения кадров к ID диалогов и ID диалогов к портам агрегирования и шлюзам.

[0085] ID услуги: Значение, извлекаемое из заголовка кадра (VTD, I-SID и т.д.), которое идентифицирует экземпляр услуги, с которой этот кадр ассоциирован.

[0086] Экземпляр услуги: Экземпляр услуги представляет собой набор точек доступа к услуге (SAP), такой, что примитив запроса данных (Data.Request), представленный одной SAP, может привести к примитиву указания данных (Data.Indication), возникающему в одном или более других SAP в этом наборе. В контексте операторов и клиентов, конкретному клиенту предоставляется доступ ко всем SAP такого набора оператором.

[0087] Тип/Длина/Значение (TLV): Короткий, с кодированием переменной длины, информационной элемент, состоящий из последовательных полей типа, длины и значения, где поле типа идентифицирует тип информации, поле длины указывает длину поля информации в октетах, а поле значения содержит собственно информацию. Значение типа определяется локально и должно быть уникальным в пределах протокола, определенного в настоящем стандарте.

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

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

[0090] В данном описании сетевое устройство (например, маршрутизатор, коммутатор, мост) является частью сетевого оборудования, включая аппаратные средства и программное обеспечение, которое соединяет с возможностью связи между собой другое оборудование в сети (например, другие сетевые устройства, конечные станции). Некоторые сетевые устройства представляют собой "сетевые устройства комплексных услуг", которые обеспечивают поддержку нескольких сетевых функций (например, маршрутизации, мостов, коммутации, агрегирования уровня 2, пограничного контроля сессии и/или управления абонентами) и/или предоставляют поддержку услуг множества приложений (например, данные, голос и видео). Конечные абонентские станции (например, серверы, рабочие станции, ноутбуки, нетбуки, портативные компьютеры, мобильные телефоны, смартфоны, мультимедийные телефоны, телефоны протокола VoIP (голосовой Интернет-телефонии), пользовательское оборудование, терминалы, портативные медиа-плееры, GPS-блоки, игровые системы, приставки) получают доступ к контенту/услугам, предоставляемым через Интернет, и/или контенту/услугам, предоставляемым по виртуальным частным сетям (VPN), накладываемым на (например, туннелируемым через) Интернет. Контент и/или услуги, как правило, обеспечиваются одной или несколькими конечными станциями (например, серверными конечными станциями), принадлежащими провайдеру услуг или контента, или конечными станциями, участвующими в услугах одноранговых узлов (P2P), и могут включать в себя, например, общедоступные веб-страницы (например, бесплатный контент, витрины, поиск услуг), частные веб-страницы (например, веб-страницы с доступом по имени пользователя/паролю, предоставляющие услуги электронной почты) и/или корпоративные сети поверх VPN. Как правило, абонентские конечные станции связаны (например, через оборудование в помещении клиента, связанное с сетью доступа (проводным или беспроводным способом)) с устройствами граничной сети, которые связаны (например, через одно или более устройств базовой сети) с устройствами другой граничной сети, которые связаны с другими конечными станциями (например, серверными конечными станциями).

[0091] Сетевые устройства обычно разделены на плоскость управления и плоскость данных (иногда упоминаются как плоскость пересылки или плоскость среды передачи). В случае если сетевое устройство является маршрутизатором (или осуществляет функции маршрутизации), плоскость управления, как правило, определяет, каким образом данные (например, пакеты) должны маршрутизироваться (например, на следующий участок ретрансляции для данных и порт вывода для этих данных), а плоскость данных отвечает за пересылку этих данных. Например, плоскость управления, как правило, включает в себя один или более протоколов маршрутизации (например, протокол внешнего шлюза, такой как Протокол пограничного шлюза (BGP) (RFC 4271), Протокол(ы) внутреннего шлюза (IGP) (например, Открытия сначала кратчайшего пути (OSPF) (RFC 2328 и 5340), От промежуточной системе к промежуточной системе (IS-IS) (RFC 1142), Протокол информации маршрутизации (RIP) (RFC 1058, версия 1; RFC 2453, версия 2 и RFC 2080 следующего поколения)), Протокол распределения меток (LDP) (RFC 5036), Протокол резервирования ресурсов (RSVP) (RFC 2205 2210, 2211, 2212, а также разработка RSVP-трафика (TE): Расширения RSVP для LSP Туннелей RFC 3209, Сигнализация Обобщенной много-протокольной коммутации меток (GMPLS) RSVP-TE RFC 3473, RFC 3936, 4495 и 4558)), которые осуществляют связь с другими сетевыми устройствами для обмена маршрутами и выбора маршрутов на основе одной или более метрик маршрутизации. Кроме того, плоскость управления также, как правило, включают в себя ISO протоколы управления уровня 2, такие как Протокол высокоскоростного связующего дерева (RSTP), Протокол множества связующих деревьев (MSTP) и SPB (Перекрытие кратчайшего пути), которые были стандартизированы различными органами стандартизации (например, SPB был определен в IEEE Std 802.1aq-2012).

[0092] Маршруты и смежности (сетевых узлов) хранятся в одной или более структурах маршрутизации (например, базе информации маршрутизации (RIB), базе информации меток (LIB), одной или более структур смежности) на плоскости управления. Плоскость управления программирует плоскость данных информацией (например, информацией о смежности и маршрутах) на основе структуры (структур) маршрутизации. Например, плоскость управления программирует информацию о смежности и маршрутах в одну или более структур переадресации (например, базу информации переадресации (FIB), базу информации переадресации меток (LFIB), и одну или более структур смежности) на плоскости данных. Плоскость данных использует эти структуры переадресации и смежности при переадресации трафика.

[0093] Каждый из протоколов маршрутизации загружает записи маршрутов в главную RIB на основе некоторых метрик маршрута (метрики могут быть различными для разных протоколов маршрутизации). Каждый из протоколов маршрутизации может хранить записи маршрута, в том числе маршрутные элементы, которые не загружены в главную RIB, в локальной RIB (например, локальной RIB OSPF). Модуль RIB, который управляет главной RIB, выбирает маршруты из маршрутов, загруженных протоколами маршрутизации (на основе набора метрик) и загружает эти выбранные маршруты (иногда называемые записями активных маршрутов) в плоскость данных. Модуль RIB может также вызвать перераспределение маршрутов между протоколами маршрутизации. Для переадресации уровня 2, сетевое устройство может хранить одну или более таблиц мостов, которые используются для пересылки данных на основе информации уровня 2 в этих данных.

[0094] Как правило, сетевое устройство включает в себя набор из одной или более линейных карт, набор из одной или более карт управления и, опционально, набор из одной или более карт услуг (иногда упоминаемых как карты ресурсов). Эти карты связаны вместе через один или более механизмов межсоединений (например, первая полная сетка, связывающая линейные карты, и вторая полная сетка, связывающая все карты). Набор линейных карт составляет плоскость данных, в то время как набор карт управления обеспечивает плоскость управления и обмен пакетами с внешними сетевыми устройствами через линейные карты. Набор карт услуг может обеспечить специализированную обработку (например, услуги от уровня 4 до уровня 7 (например, межсетевой экран, безопасность Интернет-протокола (IPsec) (RFC 4301 и 4309), система обнаружения вторжений (IDS), одноранговая связь (P2P), голос-по-IP (VoIP), пограничный контроллер сессии, мобильные беспроводные шлюзы (шлюзовой узел поддержки пакетной радиосвязи общего пользования (GPRS) (GGSN), шлюз ядра развитой пакетной сети (EPC))). В качестве примера, карта услуг может быть использована для завершения туннелей IPsec и выполнения сопутствующих алгоритмов аутентификации и шифрования.

[0095] В настоящем описании, узел пересылает IP-пакеты на основе некоторой из информации IP-заголовка в IP-пакете; где информация IP-заголовка включает в себя IP-адрес источника, IP-адрес назначения, порт источника, порт назначения (где "порт источника" и "порт назначения" здесь относятся к протокольным портам, в отличие от физических портов сетевого устройства), транспортный протокол (например, протокол пользовательских дейтаграмм (UDP) (RFC 768, 2460, 2 675, 4113 и 5405), протокол управления передачей (TCP) (RFC 793 и 1180) и значения дифференцированных услуг (DSCP) (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290 и 3317). Узлы реализованы в сетевых устройствах. Физический узел реализован непосредственно на сетевом устройстве, в то время как виртуальный узел является программным обеспечением и, возможно, аппаратными средствами, абстракцией, реализованной на сетевом устройстве. Таким образом, несколько виртуальных узлов могут быть реализованы на одном сетевом устройстве.

[0096] Сетевой интерфейс может быть физическим или виртуальным; и адрес интерфейса является IP-адресом, назначенным сетевому интерфейсу, будь то физический сетевой интерфейс или виртуальный сетевой интерфейс. Физический сетевой интерфейс является аппаратным средством в сетевом устройстве, через которое устанавливается сетевое соединение (например, беспроводным способом через контроллер интерфейса беспроводной сети (WNIC) или путем вставки кабеля в порт, соединенный с контроллером сетевого интерфейса (NIC)). Как правило, сетевое устройство имеет несколько физических сетевых интерфейсов. Виртуальный сетевой интерфейс может быть ассоциирован с физическим сетевым интерфейсом, с другим виртуальным интерфейсом или быть самостоятельным (например, кольцевой интерфейс, интерфейс протокола двухточечной передачи). Сетевой интерфейс (физический или виртуальный) может быть нумерованным (сетевой интерфейс с IP-адресом) или ненумерованным (сетевой интерфейс без IP-адреса). Кольцевой интерфейс (и его кольцевой адрес) представляет собой особый тип виртуального сетевого интерфейса (и IP-адрес) узла (физического или виртуального), часто используемого для целей управления; где такой IP-адрес называют узловым кольцевым адресом. IP-адреса, назначенные сетевым интерфейсам сетевого устройства, называются IP-адресами этого сетевого устройства; на более детальном уровне IP-адреса, назначенные сетевым интерфейсам, назначенным узлу, реализованному на сетевом устройстве, могут называться IP-адресами этого узла.

[0097] Некоторые сетевые устройства обеспечивают поддержку для реализации виртуальных частных сетей (VPN) (например, VPN уровня 2 и/или VPN уровня 3). Например, сетевое устройство, где сеть провайдера и сеть клиента связаны, соответственно называются РЕ (граница провайдера) и СЕ (граница клиента). В VPN уровня 2, переадресация, как правило, осуществляется на CE на любом конце VPN, и трафик передается по сети (например, через один или более РЕ, связанные другими сетевыми устройствами). Схемы уровня 2 сконфигурированы между СЕ и РЕ (например, Ethernet-порт, постоянный виртуальный канал (PVC) АТМ, PVC ретрансляции кадра). В VPN уровня 3, маршрутизация, как правило, выполняется посредством PE. В качестве примера, пограничное сетевое устройство, которое поддерживает множество контекстов, могут быть развернуто РЕ; и контекст может быть сконфигурирован с протоколом VPN, и, таким образом, такой контекст называется контекстом VPN.

[0098] Некоторые сетевые устройства обеспечивают поддержку для VPLS (услуги виртуальной частной LAN) (RFC 4761 и 4762). Например, в сети VPLS, абонентские конечные станции получают доступ к контенту/услугам, предоставляемым через сеть VPLS, путем связи с СЕ, которые связаны через РЕ, связанные с другими сетевыми устройствами. Сети VPLS могут быть использованы для реализации сетевых приложений тройной услуги (triple play) (например, приложений данных (например, высокоскоростного Интернет-доступа), видео-приложений (например, телевизионной услуги, такой как IPTV (телевидение по Интернет-протоколу), услуги VoD (видео-по-запросу) и голосовых приложений (например, услуги VoIP (голоса по Интернет-протоколу)), VPN услуг и т.д. VPLS является типом VPN уровня 2, которая может быть использована для многоточечной связности. Сети VPLS также позволяют абонентским конечным станциям, которые связаны с СЕ в отдельных географических местоположениях, осуществлять связь друг с другом через глобальную сеть (WAN), как если бы они были непосредственно подключены друг к другу в локальной сети (LAN) (называемой эмулированной LAN).

[0099] В сетях VPLS, каждая СЕ, как правило, привязана, возможно, через сеть доступа (проводную и/или беспроводную), к мостовому модулю РЕ через схему присоединения (например, виртуальный канал или соединение между СЕ и РЕ). Мостовой модуль РЕ присоединяется к эмулированной LAN через интерфейс эмулированной LAN. Каждый мостовой модуль действует как "экземпляр виртуального коммутатора" (VSI) путем поддержки таблицы переадресации, которая отображает MAC-адреса на псевдопровода и схемы присоединения. PES пересылают кадры (принятые от СЕ) в места назначения (например, другие CE, другие PE), основываясь на поле адреса места назначения МАС, включенном в эти кадры.

[00100] Подуровень агрегирования каналов

[00101] На фиг. 2 представлена схема одного варианта осуществления подуровня 200 агрегирования каналов. Клиент 202 агрегатора осуществляет связь с набором портов 292, 294, 296 агрегирования через агрегатор 250. В одном варианте осуществления агрегатор 250 представляет стандартный IEEE Std 802.1Q интерфейс услуги внутреннего подуровня (ISS) клиенту 202 агрегатора. Агрегатор 250 связывается с одним или более портов агрегирования, включая порты 292, 294, 296 агрегирования. Агрегатор 250 распределяет передачи кадров от клиента 202 агрегатора к портам 292, 294, 296 агрегирования и собирает принятые кадры из портов 292, 294, 296 агрегирования и передает их клиенту 202 агрегатора прозрачным образом.

[00102] Связывание портов 292, 294, 296 агрегирования с агрегатором 250 управляется посредством управления 210 агрегированием каналов, которое несет ответственность за определение, какие каналы могут быть объединены, их агрегирование, связывание портов агрегирования с соответствующим агрегатором и контроль условий для определения, когда необходимо изменение в агрегировании. Такое определение и связывание может находиться под ручным управлением через прямое манипулирование переменными состояния агрегирования каналов (например, через ключи агрегирования) с помощью сетевого администратора. Кроме того, автоматическое определение, конфигурирование, связывание и контроль могут происходить с использованием протокола управления агрегированием каналов (LACP) 214. LACP 214 использует одноранговые обмены по каналам, чтобы определять на постоянной основе возможность агрегирования различных каналов, и постоянно обеспечивает максимальный уровень возможности агрегирования, достижимой между данной парой систем агрегирования.

[00103] Система агрегирования может содержать несколько агрегаторов, обслуживающих клиентов множества агрегаторов. Данный порт агрегирования будет связываться с (максимально) одним агрегатором в любой момент времени. Клиент агрегатора обслуживается одним агрегатором в данный момент времени.

[00104] Упорядочение кадров поддерживается для определенных последовательностей обменов кадрами между клиентами агрегатора (известными как диалоги). Дистрибьютор кадров 234 гарантирует, что все кадры данного диалога передаются к одному порту агрегирования. Для данного диалога, коллектору 224 кадров требуется передавать кадры клиенту 202 агрегатора в порядке, в котором они принимаются от порта агрегирования. Коллектор 224 кадров в противном случае свободен выбирать кадры, принятые от портов 292, 294, 296 агрегирования в любом порядке. Поскольку отсутствуют средства для изменения порядка кадров на одной линии, это гарантирует, что порядок кадров поддерживается для любого диалога. Диалоги могут перемещаться по портам агрегирования в пределах группы агрегирования каналов для балансировки нагрузки и поддержания доступности в случае сбоев каналов.

[00105] Портам 292, 294, 296 агрегирования присвоены соответствующие адреса управления доступом к среде (MAC), которые являются уникальными по группе агрегирования каналов и любой мостовой локальной сети (LAN) (например, соответствующей IEEE 802.1Q мостовой LAN), с которой соединена группа агрегирования каналов. Эти MAC-адреса используются в качестве адресов источника для обменов кадрами, которые инициируются объектами в самом подуровне 270 агрегирования каналов (т.е., обменами LACP 214 и протокола маркеров).

[00106] Агрегатору 250 (и другим агрегаторам, если развернуты) присваивается МАС-адрес, уникальный по группе агрегирования каналов и мостовой LAN (например, соответствующей IEEE 802.1Q мостовой LAN), с которой соединена группа агрегирования каналов. Этот адрес используется в качестве MAC-адреса группы агрегирования каналов с точки зрения клиента 202 агрегатора, как в качестве адреса источника для передаваемых кадров, так и в качестве адреса места назначения для принимаемых кадров. MAC-адрес агрегатора 250 может быть одним из MAC-адресов порта агрегирования в ассоциированной группе агрегирования каналов.

[00107] Распределенное отказоустойчивое сетевое межсоединение (DRNI)

[00108] Агрегирование каналов создает группу агрегирования каналов, которая является набором из одного или более физических каналов, который представляется более высоким уровням как один логический канал. Группа агрегирования каналов имеет два конца, каждый заканчивается в системе агрегирования. DRNI расширяет концепцию агрегирования каналов, так что на одном или обоих концах группы агрегирования каналов одна система агрегирования заменена порталом, каждый из которых состоит из одной или более систем агрегирования.

[00109] DRNI создается с использованием распределенного ретранслятора для взаимосвязи двух или более систем, каждая из которых выполняет агрегирование каналов, чтобы создать портал. Каждая система агрегирования в портале (т.е. каждая портальная система) выполняет агрегирование каналов с одним агрегатором. Распределенный ретранслятор позволяет портальной системе совместно завершать группу агрегирования каналов. Для всех других систем агрегирования, с которыми соединен портал, группа агрегирования каналов представляется завершающейся в отдельной эмулированной системе агрегирования, созданной портальной системой.

[00110] Целью является создать DRNI путем введения распределенного ретранслятора для взаимного соединения двух или трех систем, каждая из которых выполняет агрегирование каналов, чтобы создать портал. Каждая система в портале (т.е. каждая портальная система) выполняет агрегирование каналов одним Агрегатором. Распределенный ретранслятор предназначен для обеспечения того, чтобы портальные системы совместно завершали группу агрегирования каналов. Для всех других систем, с которыми соединен портал, группа агрегирования каналов должна представляться завершающейся в отдельной эмулированной системе, создаваемой портальными системами. Упомянутый выше стандарт IEEE 802.1АХ-REV/D1.0, не обеспечивает достаточной информации в отношении того, как должен функционировать распределенный ретранслятор.

[00111] Распределенные Ретрансляторы

[00112] DRNI создается с использованием распределенного ретранслятора для межсоединения двух или трех систем, каждая из которых выполняет агрегирование каналов, чтобы создать портал. Каждая система в портале (т.е. каждая портальная система) выполняет агрегирование каналов с одним Агрегатором. Распределенный ретранслятор позволяет портальным системам совместно завершать группу агрегирования каналов. Для всех других систем, с которыми соединен портал, группа агрегирования каналов представляется завершающейся в отдельной эмулированной системе, созданной портальными системами.

[00113] Фиг. 3А иллюстрирует основную систему распределенного ретранслятора в качестве отправной точки для описания распределенного ретранслятора. Сетевые каналы, изображенные на фиг. 3А и обсуждаемые здесь, соответствуют физическим или логическим каналам, которые видны и находятся под управлением сетевых протоколов. На этой диаграмме системы А и В, каждая, характеризуются выполнением "функции 1", которая является своего рода функцией пакетной ретрансляции, например, маршрутизатором или мостом. "Функция 1" также может быть операцией файлового сервера, в этом случае внешние два "порта" на каждой системе, скорее всего, не будут присутствовать. Каждая система выполняет один экземпляр подуровня агрегирования каналов. В одном варианте осуществления желательно, чтобы заштрихованные порты быть взаимосвязаны в портал с распределенным ретранслятором.

[00114] Фиг. 3А является примером, но не общим случаем. В общем, распределенный ретранслятор поддерживает следующее:

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

[00116] b) Функции агрегирования каналов, каждая из которых частично суммирует один или более МАС.

[00117] с) Соединения между портальными системами распределенного ретранслятора.

[00118] Целью введения функционального уровня распределенного ретранслятора в этом примере является сделать так, чтобы эти две портальные системы представлялись системам, связанным с ними, как имеющие конфигурацию, показанную на фиг. 3B. Там показана третья эмулированная система С, соединенная с первоначальными портальными системами посредством канала, который был введен между функцией 1 и агрегированием каналов. То есть, портальные системы А и В договариваются действовать, в том отношении как любые другие системы, с которыми они соединены, могут различить, как если бы эмулированная система С действительно существовала, как показано на фиг. 3В. Хотя фиг. 3В является примером, она иллюстрирует принципы распределенного ретранслятора:

[00119] d) Распределенный ретранслятор в эмулированной системе С является (N+1)-портовым ретранслятором для N портальных систем, с N шлюзовыми портами, соединенными с портальными системами, и одним эмулированным подуровнем агрегирования каналов, ассоциированным с первоначальными портальными системами.

[00120] е) Порты агрегирования (также называемые здесь МАС) были перемещены в эмулированную систему и, таким образом, представляются, для всех других систем, одинаково удаленными от реальных портальных систем, содержащих распределенный ретранслятор.

[00121] Фактические конструкции, используемые двумя портальными системами для создания эмулированной системы C, показаны на фиг. 4. Фиг. 4 показывает две функции DR распределенного ретранслятора, по одной функции DR в каждой системе А и В. Этот пример иллюстрирует остальные принципы распределенного ретранслятора:

[00122] f) В каждой системе А и В, порты, которые должны быть ассоциированы с системой C, перемещаются в положение ниже подуровня агрегирования каналов функции DR.

[00123] g) Виртуальный канал и его завершающий виртуальный МАС, называемые "шлюзом", конструируются, чтобы соединять каждую функцию DR с его функцией 1.

[00124] h) Между каждой парой функций DR в портале конструируется внутри-портальный канал (IPL), завершающийся на каждом конце внутри-портальным портом (IPP). (Он может существовать во многих формах, см. обсуждение здесь ниже.)

[00125] i) Существует "алгоритм шлюза", который решает, через какой шлюз кадр может пройти в или из эмулированного распределенного ретранслятора.

[00126] j) Точно так же, "алгоритм порта" решает, через какие порты агрегирования портальной системы кадр может пройти в или из эмулированного распределенного ретранслятора.

[00127] k) Как уже упоминалось выше, может быть три системы, участвующие в создании портала и эмулированной системы С. В таком случае распределенный ретранслятор в эмулированной системе С имеет дополнительный порт шлюза, по одному для каждой портальной системы, и IPL для межсоединения функций DR.

[00128] l) Функции DR, как указано здесь ниже, работают вместе, чтобы перемещать кадры между шлюзами, IPL и подуровнями агрегирования каналов.

[00129] Операция и процедуры распределенного ретранслятора

[00130] Функция DR в каждой портальной системе (фиг. 4) предполагается имеющей (в соответствии с операционными сбоями) три типа портов:

[00131] A) Внутри-портальные порты, не более одного (возможно комплексного в некотором варианте осуществления) порта IPL, соединенного с каждой из других портальных систем, принадлежащих тому же самому порталу;

[00132] В) Точно один виртуальный порт шлюза с виртуальным каналом к виртуальному порту шлюза в портальной системе, в которой находится функция DR; и

[00133] С) Точно один порт агрегатора (порт, который поддерживается экземпляром ISS, идентифицированным префиксом Agg) для подуровня агрегирования каналов с любым числом портов агрегирования, предназначенных для соединения с другими системами таким образом, что эти другие системы считают, что они соединены с одной эмулированной системой.

[00134] На фиг. 3В внутри-портальные каналы и порты IPL не видны, и распределенный ретранслятор эмулированной системы С агрегирования имеет один шлюз для каждой из систем в своем портале.

[00135] Назначением эмулированного распределенного ретранслятора является пропустить каждый кадр, принятый из порта агрегирования ("восходящий кадр"), в шлюз или отказаться от него, и пропустить каждый кадр, принятый из шлюза ("нисходящий кадр"), в порт агрегатора или отказаться от него. Функции DR, содержащие распределенный ретранслятор, иногда должны посылать кадр через один или два внутри-портальных канала, чтобы получить его на корректном шлюзе или порте агрегатора. Функция DR делает выбор, следует ли отбросить или передать кадр на шлюз, порт агрегатора или один из его IPL путем назначения каждого кадра двум ID диалогов, ID диалога шлюза и ID диалога порта, и конфигурирования шлюзов, портов агрегирования и IPL в терминах этих ID диалогов.

[00136] Упомянутый "алгоритм шлюза" состоит из двух частей, алгоритма для назначения любого заданного кадра к ID диалога шлюза и назначения ID диалогов шлюзов к шлюзам (например, с помощью Drni_Gateway_Conversation).

[00137] Если портальная система является VLAN мостом, выполняющим обучение, то отображение кадра на ID диалога шлюза будет основываться на его VLAN ID, в противном случае процесс обучения перерывается по всей сети. Для реализаций DRNI в этих случаях может быть однозначно определенное отображение VLAN ID на ID диалога.

[00138] Аналогичным образом, "алгоритм порта" элемента j в разделе "Распределенные ретрансляторы", описанном выше, состоит из алгоритма для назначения любого заданного кадра к ID диалога порта и назначения ID диалогов портов к портам (с использованием aAggConversationAdminPort[], в качестве примера).

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

[00140] Допускается, но не требуется, чтобы алгоритм шлюза и алгоритм порта использовали те же самые средства для назначения кадра к ID диалога, так что ID диалога шлюза равен ID диалога порта.

[00141] Алгоритм порта всегда применяется к кадру, когда он входит в функцию DR из шлюза, чтобы определить, следует ли направить его на порт агрегатора или на конкретный IPP. Алгоритм шлюза всегда применяется к кадру, когда он входит от порта агрегатора, чтобы определить, следует ли отправлять его к шлюзу или конкретному IPP. Оба алгоритма должны применяться, и их результаты сравниваются, чтобы пересылать кадр, входящий в функцию DR, из IPL, как показано в таблице 1.

Таблица 1
Функция DR: пересылка кадра, принятого из внутри-портального канала n
Алгоритм шлюза гласит: “шлюз это…”	Алгоритм порта гласит: “порт агрегирования это…”	Функция DR выводит кадр на:
мой шлюз	Любой*	мой шлюз
после IPL n	один из моих портов агрегирования	мой порт агрегирования
после IPL n	после IPL n	Отбросить
после IPL m (≠n)	IPL m (≠n)
после IPL m (≠n)	любой <верхний индекс>1	IPL m (≠n)

[00142] А) [1] "Любой" означает, что выход из алгоритма порта не используется; алгоритм шлюза определяет, на какой порт посылается кадр.

[00143] В) [2] Функции DR в различных портальных системах имеют несовместимые конфигурации или имеется неисправность. Кадр отбрасывается, чтобы предотвратить зацикливание.

[00144] С) Таблица 1 предполагает одну из трех конфигураций:

- Две портальные системы, соединенные одним IPL;

- Три портальные системы, соединенные линейно двумя IPL; или

- Три портальные системы, соединенные по кругу тремя IPL.

[00145] D) Алгоритм шлюза приводится в исполнение в обоих направлениях через шлюз; то есть, кадр, входящий в функцию DR из шлюза, отбрасывается, если алгоритм шлюза, примененный к этому кадру, не отправил бы его обратно в шлюз. Это необходимо, чтобы предотвратить то, что кадры, принятые из шлюза, направлялись бы по IPL и пропускались бы обратно в сеть через другой шлюз.

[00146] Е) Если алгоритм шлюза указывает, что кадр должен пройти через шлюз, он должен быть восходящим кадром, потому что нисходящий кадр не мог бы войти в портал из любой другой функции DR, посредством пункта D) выше.

[00147] F) В противном случае, если алгоритм шлюза указывает, что кадр поступил из IPL, на который он бы направлялся, то это нисходящий кадр и поэтому посылается с использованием алгоритма порта. (Если алгоритм порта послал бы его обратно на порт, на который он прибыл, то имеет место какая-то неисправность или неверная конфигурация, и кадр отбрасывается.)

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

[00149] Примечание. Алгоритм порта и протокол управления распределенным ретранслятором распределенного ретранслятора вместе определяют отображение ID диалогов портов на отдельные порты агрегирования, и переменные при их управлении определяют операцию дистрибьютора кадров и коллектора кадров. Однако это не изменяет маршрут данных и управление, как описано, так как распределенный ретранслятор пропускает все данные на или из портов агрегирования через агрегатор.

[00150] Применение алгоритмов шлюза и порта на кадрах, входящих в функцию DR из шлюза и порта агрегатора, как показано в таблице 2 и таблице 3, соответственно.

Таблица 2
Функция DR: пересылка кадра, принятого от моего шлюза
Алгоритм шлюза гласит: “шлюз это…”	Алгоритм порта гласит: “порт агрегирования это…”	Функция DR выводит кадр на:
Мой шлюз	один из моих портов агрегирования	мой порт агрегирования
после IPL n	IPL n
после IPL n	любой	Отбросить

Таблица 3
Функция DR: пересылка кадра, принятого из одного из моих портов агрегирования
Алгоритм шлюза гласит: “шлюз это…”	Алгоритм порта гласит: “порт агрегирования это…”	Функция DR выводит кадр на:
мой шлюз	любой	мой шлюз
после IPL n	любой	IPL n

[00151] Топология портала

[00152] Наиболее общую топологию портала представляют три портальные системы, соединенные в кольцо с помощью трех внутри-портальных каналов, как показано на фиг. 21. Другие поддерживаемые топологии в соответствии с другими вариантами осуществления изобретения являются подмножествами этого, в том числе:

- три портальные системы, соединенные в цепочку посредством двух IPL,

- две портальные системы, соединенные посредством одного IPL,

- портальная система без каких-либо активных IPL.

[00153] Термины “домашняя”, “сосед” и “другой сосед” используются для идентификации портальных систем с точки зрения данного внутри-портального порта. Домашней (главной) является система, содержащая IPP. Соседом является система, соединенная с IPP. Другим соседом является система, соединенная с другим IPP (если присутствует) в домашней системе. Со ссылкой на фиг. 21, используя IPP B1 для примера, его домашней системой является B, его непосредственным соседом является А (потому что он соединен с IPP B1 с помощью IPL AB), и его другим соседом является С (потому что он соединен с IPP В2 с помощью IPL ВС). Отметим, что другим соседом IPP A2 также является С (потому что он соединен с IPP A1 с помощью IPL AC), так сравнивая ID других соседей IPP B1 и А2 проверяется, что имеется не более трех систем в кольце или цепочке.

[00154] Внутри-портальный канал

[00155] Внутри-портальный канал (IPL) представляет собой один логический канал от точки к точке между функциями DR в двух разных системах. Функция DR имеет не более одного IPL для каждой из других систем, содержащих один конец группы агрегирования каналов DRNI. IPL и сетевые каналы могут совместно использовать физический канал или агрегирование каналов (агрегирование каналов является агрегатом из набора каналов).

[00156] IPL может быть физическим (например, 802.3 Ethernet LAN) или логическим (например, экземпляр услуги магистрали 802.1Q или псевдопровод IETF). Внутри-портальный канал может совместно использовать физический канал с другими внутри-портальными каналами или сетевыми каналами. Внутри-портальный канал может быть группой агрегирования каналов и, таким образом, состоять из нескольких физических каналов.

[00157] Часто в развернутых сетях имеет место то, что две системы будут сконфигурированы как с обычным сетевым каналом, соединяющим их, так и с IPL, как показано на фиг. 4. Полезность DRNI была бы снижена, если каждый портал требует своего собственного физического IPL, особенно если пара систем сконфигурирована для поддержки нескольких порталов. DRNI поддерживает ряд методов, с помощью которых системы могут различать кадры на сетевом канале от кадров на конкретном IPL:

- Физический. Отдельный физический канал может быть использован для поддержки какого-либо конкретного сетевого канала или IPL.

- Агрегированный. Отдельный порт агрегатора может использоваться для поддержки IPL.

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

- С использованием меток. Сетевой канал и один или более IPL могут использовать тот же физический канал (или порт агрегатора) с использованием разных ID услуг. Совместное использование меток описано здесь.

- Логический. Кадры в сетевом канале и IPL могут быть инкапсулированы, как описано здесь.

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

[00159] На каждом конце совместно используемого физического канала или порта агрегатора, есть один виртуальный порт для каждой функции (сетевого канала или конкретного IPL), для которой используется канал или порт агрегатора. Любой из указанных выше способов может быть использован одновременно между двумя системами, посредством административного выбора, если оба конца любого данного физического канала или порта агрегатора используют тот же самый способ.

[00160] Совместное во времени использование сети/IPL

[00161] Целью совместного во времени использования сети/IPL является поддержка DRNI, не требуя отдельных физических каналов для сетевого соединения и IPL и не требуя какой-либо модификации кадра. При совместном использовании канала, необходимо иметь возможность определить для каждого кадра, предназначен ли этот кадр, чтобы проходить через сетевое соединение или IPL. Это определение может быть сделано без модификации кадра (например, без перевода VLAN ID или добавления метки или инкапсуляции), если в любой момент времени известно, что физическое соединение используется только в качестве сетевого соединения или используется только в качестве IPL. То, используется ли канал в качестве сетевого соединения или IPL в любой момент времени, устанавливается протоколом управления, используемым для установки полностью соединенной, без петель активной топологии для каждой VLAN в сети.

[00162] Если канал не включен в активную топологию VLAN (например, он был блокирован операцией протокола сетевого управления), он доступен для использования в качестве IPL. В этом случае канал используется посредством DRNI, как если бы это был выделенный (не используемый совместно) IPL.

[00163] Если канал включен в активную топологию VLAN, то нет IPL, доступного для данной VLAN. В этом случае DRNI не в состоянии направить кадр между портом агрегирования в одной портальной системе и шлюзом в другой портальной системе. Поэтому для любого данного кадра, DRNI ограничено, чтобы имеет шлюз и порт агрегирования в одной и той же портальной системе.

[00164] Примечание 1. Тот факт, что совместно используемый канал может быть недоступен для передачи кадров между шлюзом и конкретным портом агрегирования, не ограничивает возможность обмена DRCPDU на совместно используемом канале.

[00165] Имеется два случая, чтобы учитывать удовлетворение ограничения, что для любого данного кадра шлюз и порт агрегирования находятся в той же самой портальной системе. Простым случаем является, когда ID диалогов портов согласованы и симметричны по DRNI, и все кадры с данным VLAN ID отображаются на ID диалогов портов, которые выбирают порты агрегирования в той же самой портальной системе. Затем эта портальная система выбирается в качестве шлюза для этого VLAN ID, и нет необходимости, чтобы какие-либо кадры данных пересекали IPL. В любом другом случае единственным способом гарантировать, что шлюз и конкретный порт агрегирования находятся в одной и той же портальной системе, является то, что когда кадр принимается на любом порте ином, чем порт совместно используемой сети/IPL, та портальная система считается шлюзом для этого кадра, и в каждой портальной системе все ID диалогов портов отображаются на порт агрегирования, связанный с этой системой. В этом режиме портальная система, которая принимает какой-либо кадр на сетевом порту (не являющемся IPP или портом агрегирования), несет ответственность за передачу этого кадра к порту агрегирования, если требуется. Портальная система, которая принимает кадр на IPP, не пересылает этот кадр на порт агрегирования. В этом случае выбор шлюза не обязательно должен быть основан на VID, поэтому, когда портальные системы являются 802.1Q мостами, процесс обучения на совместно используемой сети/IPL нарушается. Поскольку вопросы обучения ограничены этим портом, это может быть исправлено путем синхронизации адресов, обучаемых на DRNI, с другой портальной системой.

[00166] Совместное использование сети/IPL посредством метки

[00167] Если используется распределение кадров для каждой услуги, и если количество услуг, необходимых для поддержки сетевого канала, плюс количество услуг, необходимых для поддержки одного или более IPL, меньше, чем количество услуг, предоставляемых используемым форматом кадра (например, 4094 S-VLAN ID), то преобразование VID может быть использовано для разделения кадров на различные логические каналы.

[00168] Способ выбирается путем конфигурирования aDrniEncapsulationMethod со значением 2. Если разрешено, как указано переменной Enabled_EncTag_Shared, которая управляется механизмом совместного использования сети/IPL, каждый кадр, который должен транспортироваться посредством IPL к соседней портальной системе и ассоциирован ID диалога шлюза, преобразуется, чтобы использовать значение, сконфигурированное в aDrniIPLEncapMap, и каждый кадр, который должен транспортироваться посредством сетевого канала, совместно используемого с IPL, и ассоциирован с ID диалога шлюза, преобразуется, чтобы использовать значение, сконфигурированное в aDrniNetEncapMap.

[00169] Совместное использование сети/IPL посредством инкапсуляции

[00170] Этот метод позволяет совместно использовать IPL с сетевым каналом путем использования методов инкапсуляции (например, экземпляра услуги 802.1Q магистрали, В-VLAN, псевдопровода IETF и т.д.).

[00171] Метод выбирается путем конфигурирования aDrniEncapsulationMethod со значением, представляющим метод инкапсуляции, который используется для транспортировки кадров IPL (кадров данных, проходящих через IPL, т.е. не кадров, не несущих DRCPDU) к соседней портальной системе, когда IPL и сетевой канал совместно используют тот же самый физический канал. Это значение состоит из трех-октетного уникального для организации идентификатора (OUI), идентифицирующего организацию, которая несет ответственность за эту инкапсуляцию, и одного следующего октета, используемого для идентификации метода инкапсуляции, определяемого этой организацией. Если разрешено, как указано переменной Enabled_EncTag_Shared, которая управляется механизмом совместного использования сети/IPL, каждый кадр, который должен передаваться по IPL к соседней портальной системе и ассоциирован с ID диалога шлюза, инкапсулируется способом, указанным посредством aDrniEncapsulationMethod, чтобы использовать значение, сконфигурированное в aDrnilPLEncapMap, и каждый кадр, который принимается посредством IPL, де-инкапсулируется и отображается на ID диалога шлюза с использованием той же самой таблицы.

[00172] Конечный автомат функции DR

[00173] Конечные автоматы функции DR должны реализовывать правила переадресации, указанные в таблицах 1-3. Эти правила переадресации можно резюмировать следующим образом:

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

b) Для кадров, поступающих через шлюз, нисходящих кадров, алгоритм порта решает, следует ли передавать его в порт агрегирования или в IPP в соответствии с его ID диалога порта. Если ID диалога порта кадра соответствует оперативному ID диалога порта портальной системы, то кадр будет пересылаться в порт агрегирования, в противном случае он будет пересылаться в IPP.

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

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

[00174] Некоторые из переменных агрегирования каналов, используемых распределенным ретранслятором, должны быть сформированы особым образом, так что множество портальных систем может взаимодействовать для создания единой эмулированной системы:

е) Два младших бита приоритета порта в ID порта для каждого порта агрегирования в порту агрегатора распределенного ретранслятора устанавливаются в значение DRF_Portal_System_Number. Остальным битам присваивается значение, уникальное в функции DR.

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

[00175] Интерфейсы услуг

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

а) AGG: для примитивов, выдаваемых на интерфейсе между функцией DR и подуровнем агрегирования каналов.

b) Gate: для примитивов, выданных на шлюзе.

с) MacIppN: для примитивов, выдаваемых на интерфейсе между объектами MAC, поддерживающими IPL n, и анализатором/мультиплексором управления DRCP.

d) DRCPCtrlMuxN: для примитивов, выдаваемых на интерфейсе между анализатором/мультиплексором N управления DRCP и объектом управления DRCP (где N идентифицирует IPP, ассоциированный с анализатором/мультиплексором управления DRCP).

е) IppN: для примитивов, выдаваемых на интерфейсе функции DR, поддерживаемом анализатором/мультиплексором N управления DRCP (где N идентифицирует IPP, ассоциированный с анализатором/мультиплексором управления DRCP).

[00177] Переменные на каждую функцию DR

[00178] Последующее описание фокусируется на различных переменных на каждую функцию DR в соответствии с одним вариантом осуществления изобретения.

[00179] DA: Адрес назначения

[00180] SA: Адрес источника

[00181] mac_service_data_unit

[00182] Priority (приоритет): Параметры примитива M_UNITDATA.indication.

[00183] BEGIN (начало): Булева переменная, которая устанавливается в TRUE (истинно), когда система инициализирована или ре-инициализирована, и устанавливается в FALSE (ложно), когда (ре-)инициализация завершена.

[00184] Значение: Булево.

[00185] Drni_Portal_System_Gateway_Conversation: Операционный булев вектор, индексированный посредством ID диалога шлюза, указывающий, разрешено ли индексированному ID диалога шлюза пройти через этот шлюз функции DR (TRUE = проходит). Его значения вычисляются с помощью функции updatePortalSystemGatewayConversation в одном варианте осуществления. В другом варианте осуществления эта переменная построена из Drni_Gateway_Conversation, путем установки в FALSE всех индексированных ID диалога шлюза, которые ассоциированы с другими портальными системами в портале и, из оставшихся индексированных записей ID диалога шлюза, всех тех, которые не согласуются с другими портальными системами.

[00186] Значение: последовательность булевых значений, индексированных посредством ID диалога шлюза.

[00187] Drni_Portal_System_Port_Conversation: Операционный булев вектор, индексированный посредством ID диалога порта, указывающий, разрешено ли индексированному ID диалога порта распространяться через агрегатор этой функции DR (TRUE = проходит). Его значения вычисляются посредством updatePortalSystemPortConversation в одном варианте осуществления. В другом варианте осуществления, эта переменная построена из Drni_Port_Conversation путем установки в FALSE всех индексированных записей ID диалога порта, которые ассоциированы с другими портальными системами в портале и, из остальных индексированных записей ID диалога порта, всех тех, которые не согласуются с другими портальными системами.

[00188] Значение: последовательность булевых значений, индексированных посредством ID диалога порта.

[00189] Сообщения

[00190] Agg: M_UNITDATA.indication

[00191] Gate: M_UNITDATA.indication

[00192] IppN: M_UNITDATA.indication

[00193] Agg: M_UNITDATA.request

[00194] Gate: M_UNITDATA.request

[00195] IppN: M_UNITDATA.request

[00196] Примитивы услуг используются для передачи принятого кадра к клиенту с заданными параметрами.

[00197] Если используются способы совместного использования сети/IPL посредством метки или совместного использования сети/IPL посредством инкапсуляции, то примитивами услуги IppN: M_UNITDATA.indication и IppN:M_UNITDATA.request необходимо манипулировать с помощью операции функций, которые управляются автоматом совместного использования сети/IPL.

[00198] Функция DR: Конечный автомат приема порта агрегатора

[00199] Функция DR: Конечный автомат приема порта агрегатора может реализовать функцию, указанную на фиг. 22, с ассоциированными с ней параметрами в соответствии с одним вариантом осуществления изобретения. Существует одна функция DR: конечный автомат приема порта агрегатора на каждую портальную систему, и существует столько состояний PASS_TO_IPP_N, сколько IPP в портальной системе, каждый из которых идентифицирован индексом n. Префикс "n." на схеме используется для идентификации конкретного IPP n, с которым связана ассоциированная переменная.

[00200] Функция DR: Конечный автомат распределения шлюза

[00201] Функция DR: Конечный автомат состояния шлюза может реализовать функцию, указанную на фиг. 23, с ассоциированными с ней параметрами в соответствии с одним вариантом осуществления изобретения. Существует одна функция DR: конечный автомат состояния шлюза на каждую портальную систему, и существует столько состояний PASS_TO_IPP_N, сколько IPP в портальной системе, каждый из которых идентифицирован индексом n. Префикс "n." на схеме используется для идентификации конкретного IPP n, с которым связана ассоциированная переменная.

[00202] Функция DR: Конечный автомат приема IPP N

[00203] Функция DR: Конечный автомат приема IPP N может реализовать функцию, указанную на фиг. 24, с ассоциированными с ней параметрами в соответствии с одним вариантом осуществления изобретения. Существует одна функция DR: Конечный автомат приема IPP N на каждый IPP и на каждую портальную систему, и существует столько состояний PASS_TO_IPP_M, сколько IPP в портальной системе, каждый из которых идентифицируется индексом m. Префикс "n." или "m." на схеме используется для идентификации конкретного IPP n или IPP m, с которым связана ассоциированная переменная.

[00204] Протокол управления распределенным ретранслятором

[00205] Назначение протокола управления распределенным ретранслятором (DRCP) заключается в следующем:

[00206] А) Устанавливать связь между портальными системами по внутри-портальному каналу;

[00207] В) Проверять согласованную конфигурацию портальных систем;

[00208] С) Определять идентификатор, который должен использоваться для эмулированной системы;

[00209] D) Распределять текущие состояния портальных систем и их порты агрегирования среди каждого из них;

[00210] Е) Вычислять результирующий маршрут любого кадра, требуемый, чтобы пройти через каждый IPL, и обмениваться информацией с соседними портальными системами, как требуется, чтобы избегать петли пересылки и дублированную доставку кадра;

[00211] F) Обмениваться информацией между портальными системами, чтобы поддержать распределенные функции, не специфицированные в данной спецификации.

[00212] Результатом операции DRCP является поддержание переменных, которые управляют пересылкой кадров посредством распределенной ретрансляции.

[00213] DRCP обменивается информацией, чтобы портальные системы могли работать вместе. Первый класс такой информации включает в себя управляемые объекты и переменные, которые должны быть совместимыми, чтобы вообще пропускать какие-либо данные (пункт A выше). В одном варианте осуществления они включают:

[00214] G) AggPortAlgorithm: Все портальные системы должны использовать один и тот же алгоритм порта.

[00215] Н) aDrniGatewayAlgorithm: Все портальные системы должны использовать один и тот же алгоритм шлюза.

[00216] I) aDrniPortalId: Все портальные системы должны иметь то же самое значение для aDrniPortalId, чтобы гарантировать, что все они должны принадлежать к тому же самому порталу.

[00217] J) для aDrniPortalTopology: Все портальные системы должны иметь одинаковое значение для aDrniPortalTopology и в случае портала из трех портальных систем, соединенных в кольцо, тот же самый "канал разрыва петли" aDrniLoopBreakLink должен быть сконфигурирован согласованно по всему порталу.

[00218] K) aDrniPortalSystemNumber: Все портальные системы должны иметь разные значения aDrniPortalSystemNumber, и все эти значения должны быть в диапазоне 1…3, чтобы гарантировать, что информация может быть маркирована осмысленным образом.

[00219] L) aAggActorAdminKey: Два старших бита административного ключа для каждого агрегатора в порту агрегатора распределенной ретрансляции устанавливается в значение DRF_Portal_System_Number. Остальные биты отражают физические характеристики ассоциированных портов агрегирования, и они должны быть одинаковыми для всех портальных систем в портале.

[00220] Второй класс управляемых объектов (пункт В) управляет тем, через какой шлюз и какие порты агрегирования проходит каждый ID диалога. Для этих управляемых объектов, если информация об одном ID диалога сконфигурирована по-разному в разных портальных системах, то оказывается воздействие только на тот ID диалога. Таким образом, портал может работать нормально, и механизмы, которые предотвращают дублированную доставку или петли при пересылке, будут блокировать прохождение любых кадров, принадлежащих к неверно сконфигурированным ID диалогов. Для того чтобы обнаруживать неверную конфигурацию так, чтобы блокировка не была постоянной, функции DR могут уведомлять сетевого администратора, если конфигурации отличаются. Так как эти конфигурации довольно большие, производится обмен контрольной суммой их содержания, а не самими конфигурациями. Этот метод обнаруживает различия с высокой вероятностью, но не с полной достоверностью. В одном варианте эти управляемые объекты включают в себя:

[00221] L) aDrniConvAdminGateway[]: Список, который используется для динамического определения того, какой ID диалога ID проходит через какой из шлюзов.

[00222] М) aAggConversationAdminPort[]: Список, который используется для динамического определения того, какой ID диалога проходит через какой из портов агрегирования.

[00223] DRCP использует информацию о том, какие из ожидаемых портальных систем соединены или не соединены через IPL, чтобы определять идентификатор эмулированного распределенного ретранслятора (пункт С выше в этом разделе).

[00224] Текущими операционными состояниями всех портальных систем и их портами агрегирования обмениваются, так что каждая из функций DR может определить, на какой шлюз или порт агрегатора портальной системы должен быть доставлен каждый кадр (пункт D выше в этом разделе). Каждая функция DR вычисляет вектор, определяющий, какие именно ID диалогов портов и какие ID диалогов шлюзов могут проходить через каждый шлюз, порт агрегирования или IPP. На каждом IPP производится обмен этой информацией (пункт Е выше в этом разделе). Если есть разница между векторами двух функций DR для любого данного ID диалога, выходные переменные устанавливаются таким образом, что функция DR будет блокировать кадры с этим ID диалога. Это предотвращает зацикливание или дублированную доставку любого кадра.

[00225] Установление портала и распределенного ретранслятора

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

[00227] А) Может иметься много систем в сети, и некоторые или все из выбранных портальных систем могут участвовать в других порталах. Определение того, какие другие портальные системы принадлежат к порталу этой портальной системы, осуществляется путем конфигурирования параметров, таких как aDrniPortalId и aDrniPortalSystemNumber.

[00228] В) Как описано выше, любой экземпляр “от точки к точке” MAC-услуги может быть назначен, чтобы быть внутри-портальным каналом. Конкретные экземпляры, назначенные для использования функции DR, сконфигурированы, например, в aDrniIntraPortalLinkList.

[00229] С) То, какой агрегатор в каждой портальной системе должен быть назначен этой функции DR, конфигурируется в aDrniAggregator в одном варианте осуществления.

[00230] D) Методы, которые будут использоваться функциями DR, чтобы назначать кадры ID диалогов шлюзов и ID диалогов портов, конфигурируются в двух управляемых объектах, aDrniGatewayAlgorithm и aAggPortAlgorithm в одном варианте осуществления.

[00231] Е) Начальные и резервные назначения ID диалогов шлюзам и портам агрегирования, чтобы покрывать режимы отказов, конфигурируются в нескольких управляемых объектах: aDrniConvAdminGateway[] и aAggConversationAdminPort[] в одном варианте осуществления.

[00232] Передача, адресация и протокольная идентификации DRCPDU

[00233] Блоки протокольных данных управления распределенной ретрансляции (DRCPDU) передаются и принимаются с использованием услуги, предоставляемой посредством объекта LLC, использующего, в свою очередь, один экземпляр MAC-услуги, предоставляемой в MSAP, ассоциированной с IPP. Каждый DRCPDU передается как один запрос MAC-услуги и принимается как одно указание MAC-услуги со следующими параметрами:

- адрес назначения

- адрес источника

- MSDU (блок данных MAC-услуги)

- приоритет.

[00234] MSDU каждого запроса и указания содержит число октетов, которые обеспечивают идентификацию протокола EtherType, сопровождаемую надлежащим DRCPDU.

[00235] Примечание 1. Для целей настоящего стандарта термин "LLC объект" включает в себя объекты, которые поддерживают различение протокола с использованием поля EtherType, как определено в стандарте IEEE 802.

[00236] Примечание 2. Полный формат кадра DRCP зависит не только от формата DRCPDU, как определено здесь, но и от процедур, зависимых от метода доступа к среде, используемых для поддержки MAC-услуги.

[00237] МАС-адрес назначения

[00238] Адрес назначения для каждого запроса MAC-услуги, используемого для передачи DRCPDU, может быть групповым адресом, выбранным управляемыми объектами IPP. Его значения по умолчанию могут быть групповым адресом ближайшего не-TPMR (двух-портового МАС (управления доступом к среде) ретранслятора) моста.

[00239] MAC-адрес источника: Адрес источника для каждого запроса MAC-услуги, используемый для передачи DRCPDU, может быть индивидуальным адресом, ассоциированным с IPP MSAP (точкой доступа MAC-услуги), в которой сделан запрос.

[00240] Приоритет: Приоритет, ассоциированный с каждым запросом MAC-услуги, должен быть приоритетом по умолчанию, ассоциированным с IPP MSAP.

[00241] Инкапсуляция DRCPDU в кадрах

[00242] DRCPDU кодируется в параметре mac_service_data_unit M_UNITDATA.request или M_UNITDATA.indication. Первые октеты mac_service_data_unit являются протокольным идентификатором, за которым следует DRCPDU, c последующими октетами-заполнителями, если таковые имеются, в соответствии с требованиями базовой MAC-услуги.

[00243] В случае, если экземпляр ISS, используемый для передачи и приема кадров, обеспечивается методом управления доступом к среде, который может поддерживать кодирование EtherType непосредственно (например, IEEE 802.3 MAC), протокольный идентификатор имеет длину в два октета. Все DRCPDU идентифицируются посредством специфицированного EtherType. Если экземпляр ISS обеспечивается методом доступа к среде, который не может непосредственно поддерживать кодирование EtherType (например, IEEE 802.11 MAC), то TPID кодируется в соответствии с правилом для протокола доступа подсети (раздел 10 в IEEE Std 802), который инкапсулирует Ethernet кадры по LLC и содержит заголовок SNAP (шестнадцатеричное АА-AA-03), за которым следует SNAP PID (шестнадцатеричное 00-00-00) с последующим протокольным EtherType (шестнадцатеричное хх-хх).

[00244] Структура и кодирование DRCPDU

[00245] Передача и представление октетов

[00246] Все DRCPDU содержат целое число октетов. Биты каждого октета пронумерованы от 0 до 7, где 0 является младшим битом. Если последовательные октеты используются для представления числового значения, наиболее значимый октет передается первым, а затем последовательно менее значимые октеты.

[00247] Когда кодирование (элемента) в DRCPDU отображается на диаграмме:

[00248] А) Октеты передаются сверху вниз.

[00249] В) В пределах октета, биты показаны с битом 0 слева и битом 7 справа и передаются слева направо.

[00250] С) Когда последовательные октеты используются для представления двоичного числа, первым передается октет, который имеет более значимое значение.

[00251] D) Когда последовательные октеты используются для представления MAC-адреса, младшему биту первого октета присваивается значение первого бита MAC-адреса, следующему более значимому биту - значение второго бита МАС-адреса и так далее до восьмого бита. Аналогично, битам от наименее значимого до самого значимого бита второго октета присваиваются значения от девятого по семнадцатый биты МАС-адреса, и так далее для всех октетов в МАС-адрес.

[00252] Инкапсуляция DRCPDU в кадрах

[00253] DRCPDU кодируется в параметре mac_service_data_unit M_UNITDATA.request или M_UNITDATA.indication в одном варианте осуществления. Первые октеты mac_service_data_unit являются протокольным идентификатором, за которым следует DRCPDU, а затем октеты-заполнители, если таковые имеются, в соответствии с требованиями базовой MAC-услуги.

[00254] В случае, если экземпляр ISS, используемый для передачи и приема кадров, обеспечивается методом управления доступом к среде, который может поддерживать кодирование EtherType непосредственно (например, IEEE 802.3 MAC), протокольный идентификатор имеет длину в два октета, и значением является протокольный EtherType (шестнадцатеричное хх-хх).

[00255] Если экземпляр ISS обеспечивается методом доступа к среде, который не может непосредственно поддерживать кодирование EtherType (например, IEEE 802.11 MAC), то TPID кодируется в соответствии с правилом для протокола доступа подсети (раздел 10 в IEEE Std 802), который инкапсулирует Ethernet кадры по LLC, и включает в себя заголовок SNAP (шестнадцатеричное АА-АА-03), а затем SNAP PID (шестнадцатеричное 00-00-00) и EtherType (шестнадцатеричное хх-хх).

[00256] Структура DRCPDU

[00257] На фиг.5 показан один вариант осуществления структуры DRCPDU в соответствии с изобретением. Поля определены следующим образом:

[00258] А) Subtype. Поле Subtype идентифицирует конкретный медленный протокол, который инкапсулируется. DRCPDU несут значение 0x0X поля Subtype. Примечание. А) отсутствует, если выбор не использует медленный протокол EtherType для идентификации операции DCRP.

[00259] В) Version Number. Это идентифицирует версию DRCP; реализация, совместимая с одним вариантом осуществления, несет значение 0x01.

[00260] С) TLV_type = Portal Information (информация портала). Это поле указывает характер информации, содержащейся в данном TLV-кортеже. Информация DRNI идентифицируется значением 0x01 в одном варианте осуществления.

[00261] D) Portal_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, информация исполнителя использует значение длины 18 (0x12) в одном варианте осуществления.

[00262] Е) Aggregator_Priority. Приоритет, присвоенный ID системы исполнителя (посредством управления или политики администрации) агрегатора, присоединенного к функции DR, кодированный как целое число без знака из aAggActorSystemPriority в одном варианте осуществления.

[00263] F) Aggregator_ID. Компонент МАС-адреса ID системы исполнителя агрегатора, присоединенного к функции DR в одном варианте осуществления.

[00264] G) Portal_Priority. Приоритет, присвоенный ID портала (посредством управления или политики администрации), кодированный как целое число без знака из aDrniPortalPriority в одном варианте осуществления.

[00265] Н) Portal_ID. Компонент МАС-адреса ID порталов из aDrniPortalId в одном варианте осуществления.

[00266] I) TLV_type = Portal Configuration Information (информация конфигурации портала). Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Portal Configuration Information идентифицируется значением 0х02 в одном варианте осуществления.

[00267] J) Portal_Configuration_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, Portal Configuration Information использует значения длины 46 (0x2E) в одном варианте осуществления.

[00268] К) Topology_State. Эта переменная, связанная с топологией функции DR для IPP, кодируется как отдельные биты в пределах одного октета следующим образом и как показано на фиг. 6C:

[00269] 1) Portal_System_Number кодируется в битах 0 и 1. Это номер портальной системы данной функции DR из aDrniPortalSystemNumber.

[00270] 2) Portal_Topology кодируется в битах 2 и 3. Это портальная топология этой функции DR, как сконфигурировано в aDrniPortalTopology.

[00271] 3) Neighbor_Conf_Portal_System_Number кодируется в битах 4 и 5. Это сконфигурированный номер портальной системы портальной системы, которая присоединена к этому IPP.

[00272] 4) Loop_Break_Link кодируется в бите 6. Этот флаг указывает, что IPL, присоединенный к данному IPP, сконфигурирован как канал разрыва петли. TRUE (“истинно”), указывает, что IPL сконфигурирован в aDrniLoopBreakLink и кодируется как 1; в противном случае, флаг кодируется как 0.

[00273] 5) Бит 7 зарезервирован для использования в будущем. Он установлен в 0 при передаче и игнорируется при приеме.

[00274] К2) Topology_State. В альтернативном варианте осуществления состояние топологии может быть закодировано в другом октете следующим образом и как показано на фиг. 29.

[00275] 1) Portal_System_Number кодируется в битах 0 и 1. Номер портальной системы этой функции DR соответствует aDrniPortalSystemNumber в одном варианте осуществления.

[00276] 2) Neighbor_Conf_Portal_System_Number кодируется в битах 2 и 3. Сконфигурированный номер портальной системы соответствует портальной системе, которая присоединена к этому IPP в одном варианте осуществления.

[00277] 3) Биты с 4 по 6 зарезервированы для использования в будущем. Они устанавливаются на 0 при передаче, и они игнорируются при приеме в одном варианте осуществления.

[00278] 4) Other_Non_Neighbor кодируется в бите 7. TRUE (кодируется как 1) указывает, что информация TLV других портов не ассоциирована с непосредственным соседом этой портальной системы. FALSE (“ложно”) (кодируется как 0) указывает, что информация TLV других портов соответствует непосредственному соседу другого IPP на этой портальной системе в одном варианте осуществления.

[00279] L) Oper_Aggregator_Key. Текущее операционное значение ключа агрегатора, присоединенного к функции DR.

[00280] М) Port_Algorithm. Алгоритм порта, используемый этой функцией DR и агрегатором из aAggPortAlgorithm в одном варианте осуществления.

[00281] N) Gateway_Algorithm. Алгоритм шлюза, используемый этой функцией DR из aDrniGatewayAlgorithm в одном варианте осуществления.

[00282] O) Port_Digest. Дайджест приоритизированных данной функцией DR назначений ID диалогов портов порту агрегирования из aAggConversationAdminPort[] в одном варианте осуществления.

[00283] Р) Gateway_Digest. Дайджест приоритизированных данной функцией DR назначений ID диалогов шлюзов шлюзу из aDrniConvAdminGateway[] в одном варианте осуществления.

[00284] Q) TLV_type=DRCP State. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. DRCP State идентифицируется значением 0x03 в одном варианте осуществления.

[00285] R) DRCP_State_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, DRCP State использует значение длиной 3 (0x03) в одном варианте осуществления.

[00286] S) DRCP_State. Переменные DRCP данной функции DR для IPP, кодированные как отдельные биты в пределах одного октета следующим образом и как показано на фиг. 6В:

[00287] 1) Home_Gateway. В одном варианте осуществления он кодируется в бите 0. Этот флаг указывает операционное состояние шлюза данной функции DR. TRUE указывает действующее состояние и кодируется как 1, а недействующее состояние кодируется как 0.

[00288] 2) Neighbor_Gateway кодируется в бите 1 в одном варианте осуществления. Этот флаг указывает операционное состояние шлюза функции DR соседа. TRUE указывает действующее состояние и кодируется как 1, а недействующее состояние кодируется как 0.

[00289] 3) Other_Gateway кодируется в бите 2 в одном варианте осуществления. Этот флаг указывает операционное состояние потенциально другой функции DR. TRUE указывает действующее состояние и кодируется как 1, а недействующее состояние кодируется как 0.

[00290] 4) IPP_Activity кодируется в бите 3 в одном варианте осуществления. Этот флаг указывает активность DRCP соседа на этом IPP. Активный сосед DRCP кодируется как 1, а отсутствие активности DRCP кодируется как 0.

[00291] 5) DRCP_Timeout кодируется в бите 4 в одном варианте осуществления. Этот флаг указывает на управляющее значение таймаута в отношении этого канала. Короткий таймаут кодируется как 1, и длинный таймаут кодируется как 0.

[00292] 6) Gateway Sync кодируется в бите 5 в одном варианте осуществления. Если TRUE (кодируется как 1), то данная функция DR считает, что соседние партнерские системы данного IPP имеют свои шлюзы в состоянии IN_SYNC; т.е., операционный вектор этой портальной системы, перечисляющий, какой шлюз портальной системы (если имеется) пропускает каждый ID диалога шлюза, согласуется с операционным вектором соседей данного IPP. Если FALSE (кодируется как 0), то этот IPP в текущее время находится в состоянии OUT_OF_SYNC; т.е., операционный вектор соседей данного IPP, перечисляющий, какой шлюз портальной системы (если имеется) пропускает каждый ID диалога шлюза, находится в противоречии.

[00293] 7) Port Sync кодируется в бите 6. Если TRUE (кодируется как 1), то данная функция DR считает, что соседние партнерские системы данного IPP имеют свои порты агрегатора в состоянии IN_SYNC; т.е., операционный вектор этой портальной системы, перечисляющий, какой порт агрегирования портальной системы (если имеется) пропускает каждый ID диалога порта, согласуется с операционным вектором соседей данного IPP. Если FALSE (кодируется как 0), то данный IPP в текущее время находится в состоянии OUT_OF_SYNC; т.е., операционный вектор соседей данного IPP, перечисляющий, какой порт агрегирования портальной системы (если имеется) пропускает каждый ID диалога порта, находится в противоречии.

[00294] 8) Expired кодируется в бите 7. Если TRUE (кодируется как 1), то этот флаг указывает, что автомат приема функции DR находится в состоянии EXPIRED (истекло) или DEFAULTED (по умолчанию); если FALSE (кодируется как 0), то этот флаг указывает, что автомат приема функции DR находится ни в EXPIRED, ни в DEFAULTED состоянии.

[00295] Принятые значения состояния Expired не используются посредством DRCP; однако, знание их значения может быть полезно при диагностике проблем протокола. Также отметим, что порядок полей и длины полей могут быть разными в другом варианте осуществления, но по-прежнему соответствуют сущности настоящего изобретения.

[00296] T) TLV_type = Home Ports Information. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Home Ports Information (информация домашних портов) идентифицируется целым значением 0x04 в одном варианте осуществления.

[00297] U) Home_Ports_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, Home Ports Information использует значение длины в 4 раза больше количества портов агрегирования этой портальной системы, которые включены.

[00298] В) Home_Admin_Aggregator_Key. Значение административного ключа агрегатора для агрегатора, присоединенного к этой функции DR, из aAggActorAdminKey.

[00299] W) Home_Oper_Partner_Aggregator_Key. Операционный ключ агрегатора партнера, ассоциированный с LAG ID агрегатора данной портальной системы.

[00300] Х) Active Home Ports. Список активных портов агрегирования в порядке возрастания номера порта. Список управляется операцией LACP (перечисляющей все порты на этой портальной системе, для которой LACP объявляет Actor_Oper_Port_State.Distributing = TRUE).

[00301] Y) TLV_type = Neighbor Ports Information. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Neighbor Ports Information (информация соседних портов) идентифицируется числовым значением 0x05.

[00302] Z) Neighbor_Ports_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, Neighbor Ports Information использует значение длины в 4 раза больше количества соседних портов агрегирования, которые включены.

[00303] Аа) Neighbor_Admin_Aggregator_Key. Значение административного ключа агрегатора для агрегатора, связанного с соседней портальной системой.

[00304] Ab) Neighbor_Oper_Partner_Aggregator_Key. Операционный ключ агрегатора партнера, ассоциированного с LAG ID агрегатора соседней портальной системы.

[00305] Aс) Active Neighbor Ports. Список активных портов агрегирования в порядке возрастания номера порта. Список управляется операцией LACP (перечисляющей все порты на непосредственно соседней портальной системе, для которой LACP объявляет Actor_Oper_Port_State.Distributing = TRUE).

[00306] Ad) TLV_type = Other Ports Information. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Other Ports Information (информация других портов) идентифицируется целым значением 0x06. Этот TLV используется, только если портальная топология содержит три портальные системы.

[00307] Ае) Other_Ports_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа, Other Ports Information использует значение длины в 4 раза больше количества порт агрегирования другой портальной системы, которые включены.

[00308] М) Other_Admin_Aggregator_Key. Значение административного ключа агрегатора для агрегатора, связанного с другой соседней портальной системой.

[00309] Ag) Other_Oper_Partner_Aggregator_Key. Операционный ключ агрегатора партнера, ассоциированный с LAG ID агрегатора другой соседней портальной системы.

[00310] Аh) Active Other Ports. Список активных портов агрегирования в порядке возрастания номера порта. Список управляется операцией LACP (перечисляющей все порты на опциональной другой портальной системе, для которой LACP объявляет Actor_Oper_Port_State.Distributing = TRUE).

[00311] Ai) TLV_type = Other Information. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Other Information (другая информация) идентифицируется целым значением 0x0x в одном варианте осуществления.

[00312] Aj) TLV_type = Terminator. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Информация Terminator (конец сообщения) идентифицируется целым значением 0x00 в одном варианте осуществления.

[00313] Ак) Terminator_Length. Это поле указывает длину (в октетах) этого TLV-кортежа. Информация Terminator использует значение длины 0 (0x00) в одном варианте осуществления.

[00314] Отметим, что использование Terminator_Length, равного 0 является намеренным. В схемах кодирования TLV обычной практикой является кодировать Terminator как 0 одновременно для типа и длины.

[00315] Кроме того, отметим, что реализация Версии 1 гарантированно сможет успешно принимать N PDU, хотя версия N PDU может содержать дополнительную информацию, которая не может быть истолкована (и будет проигнорирована) Версией 1. Решающим фактором в обеспечении обратной совместимости является то, что от любой будущей версии протокола не требуется переопределять структуру или семантику информации, определенной в предыдущей версии; она может только добавлять новые информационные элементы к предыдущему набору. Следовательно, в версии N PDU, реализация Версии 1 может ожидать, что информация Версии 1 будет обнаруживаться точно в тех же местах, что и в PDU Версии 1, и может ожидать, что эта информация будет интерпретироваться так, как определено для Версии 1.

[00316] Отметим, что DRCPDU увеличивается в размерах с числом портов агрегирования. Поддерживается максимум (1500 - 88)/4 = 353 порта агрегирования, распределенных по портальным системам портала. Минимальное количество портов агрегирования, которые должны поддерживаться порталом, равно двум.

[00317] В таблице ниже приводится список TLV, которые применимы для DRCP.

Таблица 4
Значения Type field (поля типа) DRCP TLV
TLV	Type Field
Terminator TLV	0x00
Portal Information TLV	0x01
Portal Configuration Information TLV	0x02
DRCP State TLV	0x03
Home Ports Information TLV	0x04
Neighbor Ports Information TLV	0x05
Other Ports TLV	0x06
Network/IPL Sharing Method TLV	0x07
Network/IPL Sharing Encapsulation TLV	0x08
Зарезервировано для IEEE 802.1	0x09 - 0x0E
Organization Specific TLV	0x0F
Зарезервировано для IEEE 802.1	0x10 - 0xFF

[00318] Варианты осуществления, таким образом, обеспечивают инкапсуляцию DRCPDU в кадры, где каждый DRCPDU содержит поле, указывающее состояние DRCP, например, переменные DRCP для IPP. Поле может быть одним октетом. Поле может дополнительно включать в себя закодированную в разных битах октета информацию об одном или более из следующего: Home_Gateway; Neighbor_Gateway; Other_Gateway; IPP_Activity; DRCP_Timeout; Gateway Sync; Port Sync; Expired.

[00319] На фиг. 14 показан другой вариант структуры DRCPDU согласно изобретению. Хотя структура DRCPDU на фиг. 14 аналогична таковой по фиг. 5, несколько полей отличаются. Например, Home_Ports_Information_Length соответствует 2+4*PN на фиг. 14, а не 2+2*PN, как показано на фиг. 5. Аналогично, некоторые другие поля структуры DRCPDU на фиг. 14 содержат длины, отличные от таковых для структуры DRCPDU на фиг. 5, и две структуры DRCPDU также содержат поля, отсутствующие в другом варианте осуществления. В каждой примерной структуре DRCPDU поля имеют описательные имена для содержания полей. Некоторые из различных полей содержат подобную информацию, но были переименованы или реорганизованы. Специалистам в данной области техники будет понятно, что другие аналогичные структуры DRCPDU возможны в соответствии с принципами и структурами, описанными здесь.

[00320] На фиг. 25 показан другой вариант структуры DRCPDU согласно изобретению. Структура DRCPDU на фиг. 25 аналогична таковой на фиг. 5 и 14 с несколькими различиями. Например, длины информации портов (для домашнего, соседнего и других портов) являются различными. Кроме того, структура DRCPDU на фиг. 25 включает в себя состояние топологии и различные поля для ключей агрегатора, такие как Oper_Aggregator_Key, Home_Admin_Aggregator_Key, Home_Oper_Partner_Aggregator_Key, Neighbor_Admin_Aggregator_Key, Other_Admin_Aggregator_Key и Other_Oper_Partner_Aggregator_Key, описанные выше.

[00321] Фиг. 32 иллюстрирует способ связи посредством кадра, включающего в себя структуру DRCPDU в соответствии с одним вариантом осуществления настоящего изобретения. Способ 3200 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С.

[00322] На этапе 3202 узел DRCP портала инкапсулирует DRCPDU в кадре. DRCPDU включает в себя структуру, включающую (1) поле типа (упоминаемое как подтип), указывающее PDU для DRCP, (2) поле версии, указывающее номер версии DRCPDU, и (3) набор TLV. Набор TLV включает в себя TLV указателя конца (терминатора), TLV портальной информации, TLV портальной конфигурации, TLV состояния DRCP, TLV информации домашних портов и TLV информации соседних портов. Когда портал включает в себя более двух узлов, структура PDU может включать в себя TLV других портов в одном варианте осуществления.

[00323] В одном варианте осуществления набор TLV, кроме того, включает в себя по меньшей мере один из TLV способа совместного использования сети/IPL, TLV инкапсулирования совместного использования сети/IPL, один или более TLV, зарезервированных для IEEE 802.1, и TLV специфический для организации, причем каждый TLV обсуждается в данном документе.

[00324] Каждый из набора TLV включает в себя поле типа TLV. В одном варианте осуществления каждое поле типа TLV включает в себя значения, указанные в таблице 4, показанной выше. Каждый из TLV включает в себя поля, которые могут устанавливаться на значения, обсужденные выше. Например:

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

- TLV информации портала указывает характеристики портала, к которому принадлежит узел DRCP. В одном варианте осуществления характеристики указаны в (1) поле приоритета агрегатора, указывающем приоритет, назначенный агрегатору узла, (2) поле идентификатора (ID) агрегатора, указывающем ID агрегатора, (3) поле приоритета портала, указывающем приоритет, назначенный порталу, и (4) поле адреса портала, указывающем компонент МАС-адреса, ассоциированный с сетевым устройством, как описано выше.

- TLV информации конфигурации портала указывает информацию конфигурации портала, к которому принадлежит узел DRCP. В одном варианте осуществления информация конфигурации указывается в (1) поле состояние топология, указывающем состояние топологии портала, как показано на фиг. 6С и 29, (2) поле операционного ключа агрегатора, указывающем операционный ключ агрегатора, (3) поле алгоритма портала, указывающем используемый алгоритм портала, (4) поле алгоритма шлюза, указывающем используемый алгоритм шлюза, (5) поле дайджеста порта, указывающем дайджест порта, используемый для идентификатора (ID) диалога порта для назначения порта агрегирования, и (6) поле дайджеста шлюза, указывающем дайджест шлюза, используемого для ID диалога шлюза для назначения шлюза, как описано здесь выше.

- TLV состояния DRCP указывает переменные, ассоциированные с IPP. В одном варианте осуществления состояние DRCP включает в себя значения, закодированные, как показано на фиг. 6B, как описано здесь выше.

- TLV информации домашних портов указывает текущее состояние узла в ассоциации с узлом DRCP. В одном варианте осуществления текущее состояние узла указывается в (1) поле административного ключа агрегатора, указывающем значение административного ключа агрегатора для связанного агрегатора, (2) поле операционного ключа агрегатора партнера, указывающем операционный ключ агрегатора партнера, ассоциированного с LAG ID агрегатора узла, (3) поле активного порта агрегирования, указывающем список активных портов агрегирования в узле, как описано здесь выше.

- TLV информации соседних портов указывает текущее состояние соседнего узла в ассоциации с DRNI. В одном варианте осуществления текущее состояние соседнего узла указывается в (1) поле административного ключа агрегатора, указывающем значение административного ключа агрегатора для агрегатора, связанного с соседним сетевым устройством (2) поле операционного ключа агрегатора партнера, указывающем операционный ключ агрегатора партнера, ассоциированного с LAG ID агрегатора соседнего узла, и (3) поле активного порта агрегирования, указывающем список активных портов агрегирования в непосредственно соседней портальной системе, ассоциированной с IPP, как описано здесь выше.

- TLV информации других портов указывает текущее состояние другого соседнего узла, ассоциированного с DRNI, когда локальный портал включает в себя более двух узлов. В одном варианте осуществления текущее состояние другого соседнего узла указывается в (1) поле административного ключа агрегатора, указывающем значение административного ключа агрегатора для агрегатора, связанного с другим узлом, (2) поле операционного ключа агрегатора партнера, указывающем операционный ключ агрегатора партнера, ассоциированный с LAG ID агрегатора соседнего узла, и (3) списке активных портов агрегирования в другом соседнем узле на IPP, как описано здесь выше.

- TLV способа совместного использования сети/IPL указывает способ совместного использования сети и IPL, ассоциированный с узлом; и

- TLV инкапсуляции совместного использования сети/IPL указывает информацию, относящуюся к инкапсуляции способа совместного использования.

[00325] На этапе 3206 узел DRCP посылает кадр к его соседнему узлу портала через IPP, причем соседний узел использует инкапсулированную информацию для управления пересылкой кадров.

[00326] Как описано здесь выше, посредством способа 3200 узел обменивается информацией с соседним узлом и, таким образом, устанавливает и запускает операции DRCP портала. Способ 3200 обеспечивает для узла эффективный способ, чтобы обмениваться информацией с его соседним узлом.

[00327] TLV совместного использования сети/IPL

[00328] Эти TLV требуется только, когда используемым способом совместного использования сети/IPL является один из совместного использования сети/IPL посредством метки или совместного использования сети/IPL посредством инкапсуляции для обеспечения согласованной конфигурации среди портальных систем. Способ совместного по времени использования сети/IPL требует обмена TLV способа совместного использования сети/IPL, но не TLV инкапсуляции совместного использования сети/IPL.

[00329] Примечание. Никакие TLV совместного использования сети/IPL не требуются, когда используемым способом совместного использования сети/IPL является физический или агрегированный способ, обсуждаемый здесь.

[00330] В следующей таблице приведен список TLV, которые применимы для способов совместного использования сети/IPL.

Таблица 5
Значения поля Type TLV совместного использования сети/IPL
TLV	Поле Type
TLV способа совместного использования сети/IPL	0х07
TLV инкапсуляции совместного использования сети/IPL	0х08

[00331] TLV способа совместного использования сети/IPL

[00332] Структура TLV способа совместного использования сети/IPL может быть такой, как показано в таблице ниже и дополнительно описано в следующих определениях полей:

Таблица 6
TLV способа совместного использования сети/IPL
TLV	Длина (октет)
TLV_type = Network/IPL Sharing Method (способ совместного использования сети/IPL)	1
Network/IPL_Sharing_Method_Length = 6	1
DRF_Home_Network/IPL_Sharing_Method	4

[00333] TLV_type = Network/IPL Sharing Method. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. TLV совместного использования сети/IPL идентифицируются числовым значением 0x07.

[00334] Network/IPL_Sharing_Method_Length. Это поле указывает длину (в октетах) этого TLV-кортежа. TLV совместного использования сети/IPL использует значение длины 6 (0x06).

DRF_Home_Network/IPL_Sharing_Method. Это поле содержит значение, представляющее способ совместного использования сети/IPL, который используется для транспортировки кадров IPL к соседней портальной системе на этом IPP, когда IPL и сетевой канал совместно используют один и тот же физический канал. Оно состоит из трех-октетного уникального для организации идентификатора (OUI), идентифицирующего организацию, которая несет ответственность за эту инкапсуляцию, и один следующий октет используется для идентификации метода инкапсуляции, определяемого этой организацией. Всегда устанавливается равным aDrniEncapsulationMethod. Значение 1 указывает на то, что используется совместное во времени использование сети/IPL. Значение 2 указывает, что используемый метод инкапсуляции тот же самый, что и метод, используемый для сетевых кадров, и что используется совместное использование сети/IPL посредством метки. Таблица ниже представляет кодировки метода инкапсуляции согласно IEEE OUI (01-80-С2).

Таблица 7
Методы инкапсуляции IEEE
Поле метода инкапсуляции	Значение
IPL использует отдельный физический канал или канал агрегирования	0
Совместное о времени использование сети/IPL	1
Совместное использование сети/IPL посредством метки	2
Инкапсуляция, основанная на IEEE802.1Q I- TAG	3
Инкапсуляция, основанная на IEEE802.1Q B-VLAN	4
Инкапсуляция, основанная на псевдопроводе IETF	5
Зарезервировано	6-255

[00335] TLV инкапсуляции совместного использования сети/IPL

[00336] Структура TLV инкапсуляции совместного использования сети/IPL может быть такой, как показано ниже и как описано далее в следующих определениях полей.

Таблица 8
TLV инкапсуляции совместного использования сети/IPL
TLV	Длина (октет)
TLV_type = Network/IPL Sharing Encapsulation	1
Network/IPL_Sharing_Encapsulation_Length=34	1
DRF_Home_Network/IPL_IPLEncap_Digest	16
DRF_Home_Network/IPL_NetEncap_Digest	16

[00337] TLV_type = Network/IPL Sharing Encapsulation TLV. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. TLV совместного использования сети/IPL идентифицируется целочисленным значением 0x08.

[00338] Network/IPL_Sharing_Encapsulation_Length. Это поле указывает длину (в октетах) этого TLV-кортежа. TLV совместного использования сети/IPL использует значение длины 34 (0x22).

[00339] DRF_Home_Network/IPL_IPLEncap_Digest. Это поле содержит значение MD5 дайджеста, вычисленного из aDrniIPLEncapMap для обмена с соседней портальной системой на IPL.

[00340] DRF_Home_Network/IPL_NetEncap_Digest. Это поле содержит значение MD5 дайджеста, вычисленного из aDrniNetEncapMap для обмена по совместно используемому сетевому каналу.

[00341] DrniEncapsulationMethod

[00342] АТРИБУТ

[00343] СООТВЕТСТВУЮЩИЙ СИНТАКСИС

[00344] ПОСЛЕДОВАТЕЛЬНОСТЬ ОКТЕТОВ, состоящая из уникального для организации идентификатора (OUI) и одного следующего октета.

[00345] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК

[00346] Этот управляемый объект применим только тогда, когда поддерживается совместное во времени использование сети/IPL или совместное использование сети/IPL посредством метки или совместное использование сети/IPL посредством инкапсуляции. Объект идентифицирует значение, представляющее метод инкапсуляции, используемый для транспортировки кадров IPL к соседней портальной системе, когда IPL и сетевой канал совместно используют один и тот же физический канал. Он состоит из трех- октетного уникального для организации идентификатора (OUI), идентифицирующего организацию, которая несет ответственность за эту инкапсуляцию, и одного следующего октета, используемого для идентификации метода инкапсуляции, определяемого этой организацией. Таблица по методам IEEE инкапсуляции обеспечивает кодировки метода инкапсуляции IEEE OUI (01-80-С2). Значение по умолчанию 0x01-80-C2-00 означает, что IPL использует отдельный физический канал или канал агрегирования. Значение 1 указывает на то, что используется совместное во времени использование сети/IPL. Значение 2 указывает, что используемый метод инкапсуляции является таким же, как и метод, который используется сетевыми кадрами, и что используется совместное использование сети/IPL посредством метки.

[00347] DrniIPLEncapMap

[00348] АТРИБУТ

[00349] СООТВЕТСТВУЮЩИЙ СИНТАКСИС

[00350] ПОСЛЕДОВАТЕЛЬНОСТЬ ЦЕЛЫХ ЧИСЕЛ, индексированная посредством ID диалога шлюза.

[00351] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК

[00352] Этот управляемый объект применим только тогда, когда поддерживается совместное использование сети/IPL посредством метки или совместное использование сети/IPL посредством инкапсуляции. Каждая запись представляет значение идентификатора, используемого для кадра IPL, ассоциированного с ID диалога шлюза для метода инкапсуляции, определенного здесь.

[00353] aDrniNetEncapMap

[00354] АТРИБУТ

[00355] СООТВЕТСТВУЮЩИЙ СИНТАКСИС

[00356] ПОСЛЕДОВАТЕЛЬНОСТЬ ЦЕЛЫХ ЧИСЕЛ, индексированная посредством ID диалога шлюза.

[00357] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК

[00358] Этот управляемый объект применим только тогда, когда поддерживается совместное использование сети/IPL посредством метки. Каждая запись представляет преобразованное значение идентификатора, используемого для сетевого кадра, ассоциированного с этим ID диалога шлюза, когда способ, определенный здесь, является способом совместного использования сети/IPL посредством метки, определенным здесь, и сетевые кадры должны совместно использовать пространство меток, используемое кадрами IPL.

[00359] aAggPortAlgorithm

[00360] АТРИБУТ

[00361] СООТВЕТСТВУЮЩИЙ СИНТАКСИС

[00362] ПОСЛЕДОВАТЕЛЬНОСТЬ ОКТЕТОВ, состоящая из трех-октетного уникального для организации идентификатора (OUI) и одного следующего октета.

[00363] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК

[00364] Этот объект идентифицирует алгоритм, используемый Агрегатором, чтобы соотносить кадры с ID диалога порта.

[00365] aAggActorSystemID

[00366] АТРИБУТ

[00367] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00368] MAC-Aдрес

[00369] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00370] 6-октетное значение МАС-адреса записи-считывания, используемое в качестве уникального идентификатора для системы, которая содержит этот агрегатор.

[00371] Примечание. С точки зрения механизмов агрегирования каналов, описанных в разделе 6, рассматривается только одна комбинация ID системы и приоритета системы исполнителя, и не проводится различие между значениями этих параметров для агрегатора и порта(ов) агрегатора, которые ассоциированы с ней (т.е., протокол описан в терминах операции агрегирования в рамках единой системы). Однако управляемые объекты, предоставляемые для агрегатора и порта агрегирования, обеспечивают управление этими параметрами. Результатом этого является разрешение одной части оборудования быть конфигурируемой посредством управления, чтобы содержать более одной системы с точки зрения операции агрегирования каналов. Это может быть особенно важным в конфигурации оборудования, имеющего ограниченную способность к агрегированию.

[00372] aAggActorSystemPriority

[00373] АТРИБУТ

[00374] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00375] ЦЕЛОЕ ЧИСЛО

[00376] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00377] 2-октетное значение считывания-записи, указывающее значение приоритета, ассоциированное с ID системы исполнителя.

[00378] Специфический для организации TLV

[00379] Любая организация может определять TLV для использования в DRCP. Эти TLV обеспечиваются, чтобы позволить различным организациям, таким как IEEE 802.1, ITU-T, IETF, а также отдельным поставщикам программного обеспечения и оборудования определять TLV, которые оповещают информацию соседним портальным системам. Структура специфического для организации TLV показана в таблице ниже и дополнительно описана в следующих определениях полей.

TLA_type = Organization-Specific	1
Organization_Specific_Length=LL	1
OUI	3
Subtype	7
Value (опционально)	LL-12,…

[00380] TLV_type = Organization Specific TLV. Это поле указывает на характер информации, содержащейся в данном TLV-кортеже. Специфический для организации TLV идентифицируется целым значением 0x0F.

[00381] Network/IPL_Sharing_Encapsulation_Length. Это поле указывает длину (в октетах) этого TLV-кортежа. Специфический для организации TLV использует значение длины LL.

[00382] OUI. Это поле содержит организационно уникальный идентификатор, который можно получить от IEEE.

[00383] Subtype. Это поле содержит значение подтипа, так что дополнительный OUI не требуется, если больше специфических для организации TLV требуется владельцу OUI.

[00384] Value. Это поле содержит информацию, которая должна быть передана соседним портальным системам.

[00385] Обзор конечных автоматов DRCP

[00386] Операция протокола управляется рядом конечных автоматов, каждый из которых выполняет определенную функцию. Эти конечные автоматы по большей части описаны на основе по каждому IPP; любые отклонения от описания по каждому порту агрегирования выделены в тексте. События (такие как истечение таймера или принятые DRCPDU) могут вызвать переходы между состояниями, а также вызвать действия, которые должны быть предприняты; эти действия могут включать в себя необходимость передачи DRCPDU, содержащего повторяющуюся или новую информацию. Периодические и управляемые событиями передачи управляются состоянием переменной Need-To-Transmit (необходимо передать) (NTT), генерируемой конечным автоматом по мере необходимости.

[00387] Конечные автоматы являются следующими:

[00388] А) Автомат приема (фиг. 8). Этот конечный автомат принимает DRCPDU от соседней портальной системы на этом IPP, записывает содержащуюся в нем информацию и блокирует по времени с использованием либо коротких таймаутов, либо длинных таймаутов в соответствии с установкой DRCP_Timeout. Он оценивает поступающую информацию от соседней портальной системы, чтобы определить, согласовали ли домашняя (главная) и соседняя портальные системы обмениваемую протокольную информацию в такой степени, что домашняя портальная система теперь может безопасно использоваться либо в портале с другими портальными системами, либо в качестве индивидуального портала; если нет, то он выдает NTT, чтобы передавать свежую протокольную информацию к соседней портальной системе. Если протокольная информация от соседних портальных систем блокирована по превышению лимита времени, то автомат приема устанавливает значения параметров по умолчанию для использования другими конечными автоматами.

[00389] В) Автомат периодической передачи (PTS - см. фиг. 9). Этот конечный автомат определяет период, в котором главная портальная система и ее соседи будут обмениваться DRCPDU для того, чтобы поддерживать портал.

[00390] С) Автомат портальной системы (PS - см. фиг. 10). Этот конечный автомат отвечает за обновление операционного состояния всех шлюзов и портов агрегирования в портале на основе локальной информации и DRCPDU, принятых по IPP домашней портальной системы. Этот конечный автомат предусмотрен для каждой портальной системы.

[00391] D) Автоматы шлюза и агрегатора DRNI (DGA - см. фиг. 11). Эти автоматы ответственны за конфигурирование ID диалогов шлюзов, которым позволено проходить через шлюз данной функции DR, и ID диалогов портов, которым разрешено распространяться через агрегатор данной функции DR. Эти конечные автоматы предусмотрены на каждую портальную систему.

[00392] Е) Автомат IPP DRNI (IPP - см. фиг. 12). Эти конечные автоматы ответственны за конфигурирование ID диалогов шлюзов и ID диалогов портов, которым разрешено проходить через IPP данной функции DR.

[00393] F) Автомат передачи (ТХ - см. подраздел “Автомат передачи” ниже). Этот конечный автомат обрабатывает передачу DRCPDU, как по требованию от других конечных автоматов, так и на периодической основе.

[00394] На фиг.7 показана взаимосвязь между этими конечными автоматами и поток информации между ними в соответствии с одним вариантом осуществления изобретения. Набор стрелок, обозначенных “информация состояния соседей”, представляет новую информацию соседей, содержащуюся во входящем DRCPDU или поставляемую административными значениями по умолчанию, вводимую в каждый конечный автомат автоматом приема. Набор стрелок, обозначенных “информация состояния домашней системы”, представляет поток обновленной информации состояния домашней системы между конечными автоматами. Передача DRCPDU происходит либо в результате того, что автомат периодической передачи определяет необходимость передачи периодического DRCPDU, или в результате изменений в информации состояния домашней системы, которые должны быть доведены до сведения соседей. Необходимость передавать DRCPDU сигнализируется автомату передачи путем выдачи NTT. Остальные стрелки представляют собой совместно используемые переменные в описании конечного автомата, которые позволяют конечному автомату вызывать возникновение событий в другом конечном автомате.

[00395] Фиг.15 иллюстрирует взаимосвязь между этими конечными автоматами и поток информации между ними в соответствии с другим вариантом осуществления изобретения. Альтернативный вариант осуществления функционирует сходным образом в соответствии с принципами и структурами, описанными здесь и показанными на диаграмме на фиг. 15. Таким образом, описание в основном относится к обоим вариантам осуществления, за исключением особо оговоренных случаев.

[00396] Эти конечные автоматы используют набор констант, переменных, сообщений и функций, как изложено ниже.

[00397] Управление для распределенного отказоустойчивого сетевого межсоединения

[00398] Атрибуты распределенной ретрансляции

[00399] aDrniPortalId

[00400] АТРИБУТ

[00401] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ 8 ОКТЕТОВ, которые соответствуют синтаксису 48-битного MAC-адреса

[00402] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: идентификатор считывания-записи конкретного портала. aDrniPortalId должен быть уникальным среди по меньшей мере всех потенциальных портальных систем, для которых данная портальная система может быть присоединена через IPL. Также используется в качестве ID системы исполнителя для эмулированной системы.

[00403] DrniDescription

[00404] АТРИБУТ

[00405] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00406] PrintableString, 255 символов макс.

[00407] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00408] Текстовая строка для восприятия человеком, содержащая информацию о распределенной ретрансляции. Эта строка только для чтения. Содержания являются специфическими для поставщика.

[00409] aDrniName

[00410] АТРИБУТ

[00411] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00412] PrintableString, 255 символов макс.

[00413] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00414] Текстовая строка для восприятия человеком, содержащая локально значимое имя для распределенной ретрансляции. Эта строка для считывания-записи.

[00415] aDrniPortalAddr

[00416] АТРИБУТ

[00417] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00418] ПОСЛЕДОВАТЕЛЬНОСТЬ ИЗ 6 ОКТЕТОВ, которые соответствуют синтаксису 48-битного MAC-адреса

[00419] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00420] Идентификатор считывания-записи конкретного портала, aDrniPortalAddr должен быть уникальным среди по меньшей мере всех из потенциальных портальных систем, к которым данная портальная система может быть присоединена через IPL. Также используется в качестве ID системы исполнителя (6.3.2) для эмулированной системы.

[00421] aDrniPortalPriority

[00422] АТРИБУТ

[00423] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: ЦЕЛОЕ ЧИСЛО

[00424] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: 2-октетное значение для считывания-записи, указывающее приоритетное значение, ассоциированное с ID портала. Также используется в качестве приоритета системы исполнителя для эмулированной системы.

[00425] aDrniPortalTopology

[00426] АТРИБУТ

[00427] СООТВЕТСТВУЮЩИЙ СИНТАКСИС:

[00428] ЦЕЛОЕ ЧИСЛО

[00429] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК:

[00430] Значение для считывания-записи, указывающее топологию портала. Значение 3 обозначает портал из трех портальных систем, соединенных в кольцо тремя внутри-портальными каналами, значение 2 обозначает портал из трех портальных систем, соединенных в цепь двумя IPL, значение 1 обозначает портал из двух портальных систем, соединенных одним IPL, и значение 0 обозначает портал из одной портальной системы без активных IPL. Значение по умолчанию равно 1.

[00431] aDrniPortalSystemNumber

[00432] АТРИБУТ

[00433] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: номер портальной системы, который является целым числом в диапазоне от 1 до 3 включительно.

[00434] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: идентификатор считывания-записи этой конкретной портальной системы внутри портала. Должен быть уникальным среди портальных систем с тем же aDrniPortalId.

[00435] aDrniIntraPortalLinkList

[00436] АТРИБУТ

[00437] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: ПОСЛЕДОВАТЕЛЬНОСТЬ ЦЕЛЫХ ЧИСЕЛ, которые соответствуют синтаксису идентификатора интерфейса.

[00438] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: список считывания-записи внутри-портальных каналов, назначенных этой распределенной ретрансляции. Номер порта каждого IPL является конфигурируемым, чтобы соответствовать номеру портальной системы присоединенной портальной системы.

[00439] aDrniLoopBreakLink

[00440] АТРИБУТ

[00441] СООТВЕТСТВУЮЩИЙ СИНТАКСИС

[00442] ЦЕЛОЕ ЧИСЛО, которое соответствует синтаксису идентификатора интерфейса.

[00443] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК

[00444] Идентификатор считывания-записи, который соответствует одному из идентификаторов интерфейса aDrniIntraPortalLinkList. Его значение идентифицирует интерфейс ("канал разрыва петли"), который должен разрывать петлю данных, в случае портала из трех портальных систем, соединенных в кольцо, когда все IPL действующие. Этот управляемый объект используется только, когда значение в aDrniPortalTopology равно 3.

[00445] aDrniAggregator

[00446] АТРИБУТ

[00447] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: ЦЕЛОЕ ЧИСЛО, которое соответствует синтаксису идентификатора интерфейса.

[00448] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: считывание-запись идентификатора интерфейса порта агрегатора, назначенного этому распределенному ретранслятору.

[00449] aDrniConvAdminGateway[]

[00450] АТРИБУТ

[00451] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: массив ПОСЛЕДОВАТЕЛЬНОСТИ ЦЕЛЫХ ЧИСЕЛ, которые соответствуют синтаксису номера портальной системы.

[00452] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: Имеется 4096 переменных aDrniConvAdminGateway[] от aDrniConvAdminGateway[0] до aDrniConvAdminGateway[4095], индексированных посредством ID диалога шлюза. Каждый из них содержит текущее административное значение списка приоритета выбора шлюза для распределенной ретрансляции. Этот список приоритета выбора, последовательность целых чисел для каждого ID диалога шлюза, является списком номеров портальных систем в порядке предпочтения, от высшего к низшему, для соответствующего шлюза предпочтительной портальной системы, чтобы переносить этот диалог.

[00453] Примечание. В той степени, в какой администратору сети не удается сконфигурировать те же значения для переменных aDrniConvAdminGateway[] во всех из функций DR портала, кадры могут быть неверно направлены. Протокол управления распределенной ретрансляцией (DRCP, 9.4) предотвращает такого типа ошибки конфигурации.

[00454] aDrniGatewayAlgorithm

[00455] АТРИБУТ

[00456] СООТВЕТСТВУЮЩИЙ СИНТАКСИС: ПОСЛЕДОВАТЕЛЬНОСТЬ ОКТЕТОВ, состоящая из уникального для организации идентификатора (OUI) и одного или более следующих октетов.

[00457] ПОВЕДЕНИЕ ОПРЕДЕЛЕНО КАК: Этот объект идентифицирует алгоритм, используемый функцией DR, чтобы соотносить кадры с ID диалога шлюза.

[00458] Константы

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

[00460] Fast_Periodic_Time: Количество секунд между периодическими передачами с использованием коротких таймаутов.

[00461] Значение: целое число; 1

[00462] Slow_Periodic_Time: количество секунд между периодическими передачами с использованием длинных таймаутов.

[00463] Значение: целое число; 30

[00464] Short_Timeout_Time: Количество секунд перед признанием недействительной принятой информации LACPDU при использовании коротких таймаутов (3 х Fast_Periodic_Time).

[00465] Значение: целое число; 3

[00466] Long_Timeout_Time: Количество секунд перед признанием недействительной принятой информации LACPDU при использовании длинных таймаутов (3 х Slow_Periodic_Time).

[00467] Значение: целое число; 90

[00468] Aggregate_Wait_Time: Количество секунд задержки агрегирования, чтобы несколько каналов агрегировать одновременно.

[00469] Значение: целое число; 2

[00470] Переменные, ассоциированные с распределенной ретрансляцией

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

[00472] Drni_Aggregator_Priority: Системный приоритет агрегатора, ассоциированного с данным порталом. Всегда устанавливается равным aAggActorSystemPriority. Передается в DRCPDU.

[00473] Значение: целое число; назначается администратором или системной политикой.

[00474] Drni_Aggregator_ID: Компонент МАС-адреса системного идентификатора агрегатора, ассоциированного с этим порталом. Всегда устанавливается равным aAggActorSystemID и передается в DRCPDU.

[00475] Значение: 48 бит

[00476] Drni_Gateway_Conversation: Операционный вектор, перечисляющий, какой шлюз портальной системы (если имеется) пропускает каждый ID диалога шлюза.

[00477] Значение: последовательность номеров портальных систем (0 для отсутствия), проиндексированных посредством ID диалога шлюза.

[00478] Значение вычисляется из aDrniConvAdminGateway[] и Drni_Portal_System_State[] при инициализации и всякий раз, когда управляемый объект или переменная изменяется.

[00479] Drni_Port_Conversation: Операционный вектор, перечисляющий, какая портальная система (если имеется) пропускает каждый ID диалога порта.

[00480] Значение: последовательность номеров портальных систем (0 для отсутствия), проиндексированных посредством ID диалога порта.

[00481] Значение вычисляется из aAggConversationAdminPort[] и Drni_Portal_System_State[] при инициализации и всякий раз, когда управляемый объект или переменная изменяется.

[00482] Drni_Portal_Priority: Системный приоритет портала. Всегда устанавливается равным aDrniPortalPriority. Передается в DRCPDU.

[00483] Значение: Целое число

[00484] Назначается администратором или системной политикой.

[00485] Drni_PortalID (или Drni_Portal_Addr в некотором варианте осуществления): Компонент МАС-адреса системного идентификатора портала. Всегда устанавливается равным aDrniPortalld. Передается в DRCPDU.

[00486] Значение: 48 бит

[00487] Назначается администратором или системной политикой.

[00488] Drni_Portal_Topology: сконфигурированная топология портала. Всегда устанавливается равным aDrniPortalTopology. Передается в DRCPDU.

[00489] Значение: целое число в диапазоне [0…3]

[00490] Назначается администратором или системной политикой.

[00491] Переменные для каждой функции DR

[00492] ChangeDRFPorts: Эта переменная отслеживает операционное состояние шлюза и всех портов агрегирования, ассоциированных с данной портальной системой, и устанавливается в TRUE, когда любое из них меняется. Эта переменная также может быть установлена в TRUE, если инициируются новые значения для Drni_Conversation_GatewayList[] или Drni_Conversation_PortList[].

[00493] Значение: булево

[00494] ChangePortal: Эта переменная устанавливается в TRUE, когда DRF_Neighbor_Oper_DRCP_State.IPP_Activity на любом IPP на этой портальной системе изменяется.

[00495] Drni_Conversation_GatewayList[]: массив из 4096 списков, проиндексированных посредством ID диалога шлюза, который определяет, какой шлюз в этом портале переносит какой из ID диалога шлюза. Каждый элемент в массиве представляет собой список шлюзов в этом портале, в порядке приоритета от наиболее желательного до наименее желательного, для переноса индексированного ID диалога шлюза. Назначается администратором или системной политикой. Всегда устанавливается равным aDrniConvAdminGateway[].

[00496] Drni_Conversation_PortList[]: массив из 4096 списков, проиндексированных посредством ID диалога порта, который определяет, какой порт агрегирования этом портале переносит какой из ID диалога порта. Каждый элемент в массиве представляет собой список портов агрегирования в этом портале, в порядке приоритета от наиболее желательного до наименее желательного, для переноса индексированного ID диалога порта. Назначается администратором или системной политикой. Всегда устанавливается равным aAggConversationAdminPort[].

[00497] Значение: последовательность ID порта

[00498] Drni_Portal_System_State[]: Состояния всех портальных систем в этом портале, проиндексированных номером портальной системы.

[00499] Значение: булев флаг, указывающий операционное состояние шлюза (TRUE означает действующее), список (возможно, пустой) ID портов действующих портов агрегирования в этой портальной системе и идентификатор IPP, если таковой имеется, из которого было получено состояние портальной системы. Эта переменная устанавливается с помощью функции updatePortalState. Передается в DRCPDU.

[00500].

[00501] DRF_Home_Admin_Aggregator_Key: Значение административного ключа агрегатора, ассоциированное с агрегатором данной портальной системы. Передается в DRCPDU.

[00502] Значение: Целое число

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

[00504] Назначается администратором или системной политикой.

[00505] DRF_Home_Conversation_GatewayList_Digest: Дайджест aDrniConvAdminGateway[], сконфигурированный в данной функции DR, для обмена с соседними портальными системами. На эту переменную ссылается DRCPDU.

[00506] Значение: MD5 дайджест

[00507] DRF_Home_Conversation_PortList_Digest: Дайджест aAggConversationAdminPort[], сконфигурированный в данной функции DR, для обмена с соседними портальными системами. Передается в DRCPDU.

[00508] Значение: MD5 дайджест

[00509] DRF_Home_Gateway_Algorithm: Алгоритм шлюза, используемый данной функцией DR, чтобы соотнести кадры с ID диалогов шлюзов. Всегда устанавливается равным aDrniGatewayAlgorithm. Передается в DRCPDU.

[00510] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00511] DRF_Home_Port_Algorithm: Алгоритм порта, используемый данной функцией DR, чтобы соотносить кадры с ID диалогов портов. Всегда устанавливается равным aAggPortAlgorithm ассоциированного агрегатора. Передается в DRCPDU.

[00512] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00513] DRF_Home_Oper_Aggregator_Key: Значение действующего ключа агрегатора, ассоциированное с агрегатором данной портальной системы. Его значение вычисляется с помощью функции обновления ключей. Передается в DRCPDU.

[00514] Значение: Целое число

[00515] DRF_Home_Oper_Partner_Aggregator_Key: Действующий ключ агрегатора партнера, ассоциированный с LAG ID агрегатора данной портальной системы. Передается в DRCPDU.

[00516] Значение: Целое число

[00517] DRF_Home_State: Операционное состояние данной функции DR. Передается в DRCPDU.

[00518] Значение: булев флаг, указывающий операционное состояние шлюза данной портальной системы (TRUE означает действующее) и список (возможно, пустой) ID портов действующих портов агрегирования в данной портальной системе.

[00519] DRF_Neighbor_Admin_Conversation_GatewayList_Digest: Значение для алгоритма соседней портальной системы, назначенное администратором или системной политикой для использования, когда информация соседа неизвестна. Его значение по умолчанию равно MD5 дайджесту, вычисленному из aDrniConvAdminGateway[].

[00520] Значение: MD5 дайджест

[00521] DRF_Neighbor_Admin_Conversation_PortList_Digest: Значение для алгоритма соседней портальной системы, назначенное администратором или системной политикой для использования, когда информация соседа неизвестна. Его значение по умолчанию равно MD5 дайджесту, вычисленному из aAggConversationAdminPort[].

[00522] Значение: MD5 дайджест

[00523] DRF_Neighbor_Admin_Gateway_Algorithm: Значение для алгоритма шлюза соседних систем, назначенное администратором или системной политикой для использования, когда информация соседа неизвестна. Его значение по умолчанию устанавливается равным aDrniGatewayAlgorithm.

[00524] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00525] DRF_Neighbor_Admin_DRCP_State: Значение по умолчанию для параметров состояния DRCP соседнего портала, назначенное администратором или системной политикой для использования, когда информация партнера неизвестна или недействительна. Значение состоит из следующего набора переменных, как описано в одном варианте осуществления:

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00526] Значение: 8 бит

[00527] DRF_Neighbor_Admin_Port_Algorithm: Значение для алгоритма порта соседней системы, назначенное администратором или системной политикой для использования, когда информация соседа неизвестна. Его значение по умолчанию устанавливается равным aAggPortAlgorithm.

[00528] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00529] DRF_Portal_System_Number: Уникальный идентификатор для этой портальной системы в портале.

[00530] Значение: целое число в диапазоне [1…3] в одном варианте осуществления.

[00531] Копируется из aDrniPortalSystemNumber. Передается в DRCPDU.

[00532] PSI (изолированное портальное состояние): Эта переменная устанавливается в TRUE посредством функции updateDRFHomeState, когда портальная система изолирована от других портальных систем в том же портале.

[00533] Значение: булево.

[00534] Переменные для каждого IPP

[00535] Последующее описание фокусируется на различных переменных для каждого IPP согласно одному варианту осуществления настоящего изобретения.

[00536] Ipp_Gateway_Conversation_Direction: Операционный список ID диалогов шлюзов, проходящих через шлюзы, доступные через данный IPP. Он устанавливается операцией DRCP.

[00537] Значение: Вектор булевых флагов, проиндексированных посредством ID диалога шлюза; TRUE = некоторый шлюз, доступный через этот IPP, разрешен для данного ID диалога шлюза.

[00538] Для каждого ID диалога шлюза значение равно TRUE, если и только если: а) переменные Drni_Gateway_Conversation и Drni_Portal_System_State[] указывают, что целевая портальная система для данного ID диалога шлюза лежит за этим IPP, и b) Drni_Gateway_Conversation и Ipp_Other_Gateway_Conversation согласованы в отношении того, какая портальная система должна получить этот ID диалога шлюза.

Ipp_Gateway_Conversation_Direction инициализируется в FALSE и пересчитывается каждый раз, когда какая-либо из входящих в него переменных изменяется. Для кадров, принятых по этому IPP, TRUE означает, что кадр является нисходящим кадром, в конечном счете, предназначенным для агрегатора (или отброшенным), а FALSE означает, что кадр является восходящим кадром, в конечном счете, предназначенным для шлюза (или отброшенным). Для кадров, предоставленных для передачи по данному IPP, TRUE указывает, что кадр может пройти, а FALSE, - что не может. Эта переменная не используется для управления нисходящими кадрами.

[00539] Ipp_Port_Conversation_Passes: Операционный список ID диалогов портов, которые разрешено передавать через данный IPP.

[00540] Значение: Вектор булевых флагов, проиндексированных посредством ID диалога порта.

[00541] Эта переменная рассматривается только тогда, когда нисходящий кадр предоставляется для передачи по данному IPP. Для каждого ID диалога порта, значение равно TRUE (ID проходит), если и только если: а) переменные Drni_Port_Conversation и Drni_Portal_System_State[] указывают, что целевая портальная система для данного ID диалога порта лежит за данным IPP, и b) Drni_Port_Conversation и

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

[00542] ChangePortal: Эта переменная устанавливается в TRUE, когда DRF_Neighbor_Oper_DRCP_State.IppActivity на любом IPP на данной портальной системе изменяется.

[00543] Значение: Булево

[00544] CC_Time_Shared: Булево значение, указывающее, что соседняя и домашняя портальные системы на данном IPP согласованным образом сконфигурированы, чтобы использовать совместное во времени использование сети/IPL.

[00545] Значение: Булево

[00546] CC_EncTag_Shared: Булево значение, указывающее, что соседняя и домашняя портальные системы на данном IPP согласованным образом сконфигурированы, чтобы использовать совместное использование сети/IPL посредством метки или совместное использование сети/IPL посредством инкапсуляции, как продиктовано способом сети/IPL, выбранным в aDrniEncapsulationMethod.

[00547] Значение: Булево

[00548] Differ_Conf_Portal: Булево значение, указывающее, что сконфигурированные параметры портала, используемые непосредственно соседней портальной системой на этом IPP, отличаются от ожидаемых.

[00549] Значение: Булево

[00550] Differ_Portal: булево значение, указывающее, что принятый DRCPDU на данном IPP связан с другим порталом.

[00551] Значение: Булево

[00552] DRF_Home_Conf_Neighbor_Portal_System_Number: Значение конфигурации данной портальной системы для номера портальной системы соседней портальной системы, присоединенной к данному IPP. Всегда устанавливается равным значению, присвоенному двум младшим битам компонента приоритета ID порта данного IPP. Передается в DRCPDU.

[00553] Значение: Целое число в диапазоне [1…3].

[00554] DRF_Home_Loop_Break_Link: Булево значение, указывающее, что IPL, присоединенный к данному IPP, сконфигурирован в aDrniLoopBreakLink как канал разрыва петли. Передается в DRCPDU.

[00555] Значение: Булево

[00556] DRF_Home_Network/IPL_IPLEncap_Digest: Дайджест aDrnilPLEncapMap, сконфигурированный на данном IPP, для обмена с соседней портальной системой по IPL. Передается в Network/IPL Sharing Encapsulation TLV.

[00557] Значение: MD5 дайджест

[00558] DRF_Home_Network/IPL_NetEncap_Digest: Дайджест aDrniNetEncapMap, сконфигурированный на данном IPP, для обмена по совместно используемому сетевому каналу. Передается в Network/IPL Sharing Encapsulation TLV.

[00559] Значение: MD5 дайджест

[00560] DRF_Home_Network/IPL_Sharing_Method: Способ совместного использования сети/IPL, используемый данной функцией DR, чтобы совместно использовать этот IPP с сетевыми данными. Всегда устанавливается равным aDrniEncapsulationMethod. Передается в Network/IPL Sharing Method TLV, когда aDrniEncapsulationMethod не установлен в значение по умолчанию NULL.

[00561] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за определение этого способа, с последующим одним октетом, идентифицирующим данный конкретный способ). В другом варианте осуществления используются 5 октетов.

[00562] DRF_Home_Oper_DRCP_State: Действующие значения параметров состояния DRCP данной портальной системы, как сообщается по данному IPP. Это включает следующий набор переменных, как описано выше:

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00563] Значение: 8 бит

[00564] DRF_Neighbor_Admin_Aggregator_Key: В одном варианте осуществления определяется как значение административного ключа агрегатора соседней портальной системы на данном IPP. Передается в DRCPDU.

[00565] Значение: Целое число

[00566] DRF_Neighbor_Aggregator_Priority: Последний принятый по данному IPP системный приоритет агрегатора соседа.

[00567] Значение: Целое число

[00568] DRF_Neighbor_AggregatorID: Последний принятый по данному IPP компонент МАС-адреса ID системы агрегатора соседней портальной системы.

[00569] Значение: 48 бит

[00570] DRF_Neighbor_Aggregator_Priority: Последний принятый по данному IPP системный приоритет агрегатора соседней портальной системы.

[00571] Значение: Целое число

[00572] DRF_Neighbor_Conversation_GatewayList_Digest: последний по данному IPP дайджест ID диалога шлюза соседней портальной системы.

[00573] Значение: MD5 дайджест

[00574] DRF_Neighbor_Conversation_PortList_Digest: последний принятый по данному IPP дайджест ID диалога порта соседней портальной системы.

[00575] Значение: MD5 дайджест

[00576] DRF_Neighbor_Gateway_Algorithm: Значение алгоритма, используемого соседней портальной системой, для соотнесения кадров с ID диалогов шлюзов, принимаемых по данному IPP.

[00577] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00578] DRF_Neighbor_Loop_Break_Link: Булево значение, указывающее, что IPL, присоединенный к данному IPP, идентифицируется соседней портальной системой на данном IPP как канал разрыва петли.

[00579] Значение: Булево

[00580] DRF_Neighbor_Network/IPL_IPLEncap_Digest: последний принятый по данному IPP дайджест aDrniIPLEncapMap соседней портальной системы.

[00581] Значение: MD5 дайджест

[00582] DRF_Neighbor_Network/IPL_NetEncap_Digest: последний принятый по данному IPP дайджест aDrniNetEncapMap для обмена по совместно используемому сетевому каналу соседней портальной системы.

[00583] Значение: MD5 дайджест

[00584] DRF_Neighbor_Network/IPL_Sharing_Method: последний принятый по данному IPP способ совместного использования сети/IPL, используемый соседней портальной системой.

[00585] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за определение данного способа, с последующим одним октетом, идентифицирующим данный конкретный способ).

[00586] DRF_Neighbor_Oper_Aggregator_Key: Последнее принятое по данному IPP действующее значение ключа агрегатора соседней портальной системы.

[00587] Значение: Целое число

[00588] DRF_Neighbor_Oper_Partner_Aggregator_Key: Действующее значение ключа агрегатора партнера соседней портальной системы. Передается в DRCPDU.

[00589] Значение: Целое число

[00590] DRF_Neighbor_Oper_DRCP_State: Действующее значение представления данной портальной системы текущих значений параметров состояния DRCP соседа. Функция DR домашней системы устанавливает эту переменную также на значение, принятое от соседней портальной системы в DRCPDU. Значение состоит из следующего набора переменных, как описано выше:

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00591] Значение: 8 бит

[00592] DRF_Neighbor_Conf_Portal_System_Number: Значение номера портальной системы конфигурации соседней портальной системы для данной портальной системы, которое было последним принято по данному IPP.

[00593] Значение: Целое число в диапазоне [1…3].

[00594] DRF_Neighbor_Port_Algorithm: значение алгоритма, используемого соседней портальной системой, чтобы соотносить кадры с ID диалогов портов, принимаемыми по данному IPP.

[00595] Значение: 4-октетное (3-октетный OUI, идентифицирующий организацию, которая отвечает за установку этого алгоритма, с последующими двумя октетами, идентифицирующими данный конкретный алгоритм). В другом варианте осуществления используются 5 октетов.

[00596] DRF_Neighbor_Portal_System_Number: Последний принятый по данному IPP идентификатор соседней портальной системы.

[00597] Значение: Целое число в диапазоне [1…3].

[00598] DRF_Neighbor_Portal_Topology: Последний принятый по данному IPP идентификатор портальной топологии на этом IPP.

[00599] Значение: целое число в диапазоне [0…3].

[00600] DRF_Neighbor_State: Действующее состояние непосредственно соседней портальной системы на данном IPP.

[00601] Значение: Булев флаг, указывающий операционное состояние шлюза соседней портальной системы (TRUE означает действующее) и список (возможно, пустой) ID портов действующих портов агрегирования на данном IPP.

[00602] Drni_Neighbor_ONN

[00603] Последний принятый на этом IPP флаг ONN соседней портальной системы, переносимый в поле состояния топологии.

[00604] Значение: Целое значение

[00605] DRF_Other_Neighbor_Admin_Aggregator_Key: Операционное значение административного ключа другой соседней портальной системы, ассоциированной с этим IPP. Передается в DRCPDU.

[00606] Значение: Целое число

[00607] DRF_Other_Neighbor_Oper_Partner_Aggregator_Key: Операционное значение ключа агрегатора партнера другой соседней портальной системы, ассоциированной с этим IPP. Передается в DRCPDU.

[00608] Значение: Целое значение

[00609] DRF_Other_Neighbor_State: Операционное состояние другой соседней портальной системы на данном IPP.

[00610] Значение: Булев флаг, указывающий операционное состояние шлюза другой соседней портальной системы (TRUE означает действующее) и список (возможно, пустой) ID портов действующих портов агрегирования на данном IPP.

[00611] Drni_Neighbor_Portal_Addr: Последний принятый по данному IPP компонент MAC-адреса ID системы портала соседней портальной системы.

[00612] Значение: 48 битов

[00613] Drni_Neighbor_Portal_Priority: Последний принятый по данному IPP системный приоритет соседней портальной системы.

[00614] Значение: Целое число

[00615] Drni_Neighbor_PortalID: Последний принятый по данному IPP компонент МАС-адреса ID портальной системы соседней портальной системы.

[00616] Значение: 48 битов

[00617] Drni_Neighbor_State[]: Последнее принятое по данному IPP операционное значение Drni_Portal_System_State[], используемое соседней портальной системой.

[00618] Значение: Для каждой портальной системы, булев флаг, указывающий операционное состояние шлюза текущей портальной системы (TRUE означает действующее) и список (возможно, пустой) в ID портов действующих портов агрегирования в данной портальной системе, как сообщено посредством соседней портальной системы на данном IPP.

[00619] Enabled_Time_Shared: Булево значение, указывающее, что соседняя и домашняя портальные системы на данном IPP согласованным образом сконфигурированы, и способы совместного во времени использования Сети/IPL, определенные здесь, разрешены.

[00620] Значение: Булево

[00621] Enabled_EncTag_Shared: Булево значение, указывающее, что соседняя и домашняя портальные системы на данном IPP согласованным образом сконфигурированы, чтобы использовать способы совместного использования сети/IPL посредством метки или совместного использования сети/IPL посредством инкапсуляции, как диктуется способом сети/IPL, выбранным посредством aDrniEncapsulationMethod.

[00622] Значение: Булево

[00623] Ipp_Other_Gateway_Conversation: Операционный вектор, перечисляющий, какой шлюз портальной системы (если имеется) пропускает каждый ID диалога шлюза, как сообщается непосредственным соседом на данном IPP.

[00624] Значение: Последовательность номеров портальных систем (0 для отсутствия), проиндексированных посредством ID диалога шлюза. Значение вычисляется из aDrniConvAdminGateway[] и DRF_Neighbor_State[] после инициализации и всякий раз, когда управляемый объект изменяется или GatewayConversationUpdate соответствует FALSE.

[00625] Ipp_Other_Port_Conversation_Portal_System: Операционный вектор, перечисляющий, какая портальная система (если таковая имеется) пропускает каждый ID диалога порта, как сообщается непосредственным соседом на данном IPP.

[00626] Значение: Последовательность номеров портальных систем (0 для отсутствия), проиндексированных посредством ID диалога порта. Значение вычисляется из aAggConversationAdminPort[] и DRF_Neighbor_State[] при инициализации и всякий раз, когда управляемый объект изменяется или PortConversationUpdate соответствует FALSE.

[00627] IPP_port_enabled: Переменная, указывающая, что канал установлен, и IPP задействован.

[00628] Значение: Булево

[00629] TRUE, если IPP задействован (MAC_Operational == TRUE).

[00630] FALSE в противном случае.

[00631] Примечание. Средство, с помощью которого значение переменной IPP_port_enabled генерируется базовым MAC, зависит от реализации.

[00632] Ipp_Portal_System_State[]: Список состояний портальных систем, доступных через данный IPP, который был принят последним в DRCPDU из этого IPP. Эта переменная обновляется посредством функции updatePortalSystem.

[00633] Значение: Для каждой портальной системы, булев флаг, указывающий операционное состояние текущего шлюза портальной системы, достижимой через данный IPP (TRUE указывает действующее) и список (возможно, пустой) ID портов операционных портов агрегирования в этой портальной системе.

[00634] В этом списке, состояние непосредственно соседней портальной системы является первым состоянием в списке. Список может иметь не более двух состояний портальной системы.

[00635] NTTDRCPDU: TRUE указывает, что имеется новая протокольная информация, которая должна передаваться по данному IPP, или что соседняя портальная система требует напоминания о старой информации. FALSE используется в противном случае.

[00636] ONN

[00637] Флаг Other Non Neighbor. Это значение обновляется посредством функции updatePortalState и применяется только на порталах, состоящих из трех портальных систем. Передается в DRCPDU.

[00638] Значение: Булево

[00639] TRUE указывает, что Other Ports Information TLV не ассоциирован с непосредственным соседом этой портальной системы. FALSE (кодируется как 0) указывает, что Other Ports Information TLV является непосредственным соседом на другом IPP на этой портальной системе.

[00640] DRCP_current_while_timer

[00641] Этот таймер используется для обнаружения, стала ли принятая протокольная информация недействительной. Если DRF_Home_Oper_DRCP_State.DRCP_Timeout установлен на короткий таймаут, таймер запускается со значением Short_Timeout_Time. В противном случае, он запускается со значением Long_Timeout_Time.

[00642] DRCP_periodic_timer (time_value)

[00643] Этот таймер используется для генерации периодических передач. Он запускается с использованием значения Slow_Periodic_Time или Fast_Periodic_Time, как указано в конечном автомате периодической передачи.

[00644] Константы

[00645] Все таймеры, указанные в данном подразделе, имеют допуск реализации ± 250 мс.

[00646] Drni_Fast_Periodic_Time

[00647] Количество секунд между периодическими передачами, использующими короткие таймауты.

[00648] Значение: Целое число

[00649] 1

[00650] Drni_Slow_Periodic_Time

[00651] Количество секунд между периодическими передачами, использующими длинные таймауты.

[00652] Значение: Целое значение

[00653] 30

[00654] Drni_Short_Timeout_Time

[00655] Количество секунд перед признанием недействительной принятой информации DRCPDU при использовании коротких таймаутов (3 х Fast_Periodic_Time).

[00656] Значение: Целое число

[00657] 3

[00658] Drni_Long_Timeout_Time

[00659] Количество секунд перед признанием недействительной принятой информации DRCPDU при использовании длинных таймаутов (3 х Slow_Periodic_Time).

[00660] Значение: Целое число

[00661] 90

[00662] Переменные, используемые для управления операцией конечного автомата

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

[00664] BEGIN: Эта переменная указывает на инициализацию (или ре-инициализацию) протокольного объекта DRCP. Она устанавливается в TRUE, когда система инициализируется или ре-инициализируется, и устанавливается в FALSE, когда (ре-) инициализация завершена.

[00665] Значение: Булево

[00666] DRCP_Enabled

[00667] Эта переменная указывает, что ассоциированный IPP использует DRCP. Если канал не является каналом от точки к точке, то значением DRCP_Enabled будет FALSE. В противном случае, значением DRCP_Enabled будет TRUE.

[00668] Значение: Булево

[00669] GatewayConversationUpdate: Эта переменная указывает, что распределения для каждого ID диалога шлюза должны быть обновлены.

[00670] Значение: Булево

[00671] IppGatewayAllUpdate: Эта переменная является логическим ИЛИ переменных IppGatewayUpdate для всех IPP на данной портальной системе.

[00672] Значение: Булево

[00673] IppGatewayUpdate: Эта переменная указывает, что распределения для каждого ID диалога шлюза на ассоциированном IPP должны быть обновлены. Существует одна переменная IppGatewayUpdate для каждого IPP на этой портальной системе.

[00674] Значение: Булево

[00675] IppPortAllUpdate: Эта переменная является логическим ИЛИ переменных IppPortUpdate для всех IPP в этой портальной системе.

[00676] Значение: Булево

[00677] IppPortUpdate: Эта переменная указывает, что распределения для каждого ID диалога порта на ассоциированном IPP должны быть обновлены. Существует одна переменная IppPortUpdate для каждого IPP на этой портальной системе.

[00678] Значение: Булево

[00679] PortConversationUpdate: Эта переменная указывает, что распределения для каждого ID диалога порта должны быть обновлены.

[00680] Значение: Булево

[00681] Функции

[00682] Последующее описание фокусируется на различных функциях в соответствии с одним вариантом осуществления изобретения.

[00683] extractGatewayConversationID

[00684] Эта функция извлекает значение ID диалога шлюза путем применением алгоритма шлюза к значениям параметров примитива услуги, который вызывается на объекте ретранслятора функции DR при приеме примитива ISS в одном из портов функции DR. Отношение значений параметров на примитивах ISS и примитивах услуги на портах объекта ретранслятора функции DR обеспечивается ассоциированными поддерживающими функциями на этих портах и их конфигурацией.

[00685] Примечание. Эти поддерживающие функции могут быть таким простыми, как функции поддержки EISS, специфицированные в 6.9 IEEE Std 802.1Q-2011, для случая DRNI, поддерживаемого на сетевом порту клиента или сетевом порту провайдера на мосту провайдера (Раздел 15 в IEEE Std 802.1Q), или более сложными, как функции поддержки EISS, специфицированные в 6.10 или 6.11 IEEE Std 802.1Q-2011, для случая DRNI, поддерживаемого на порту экземпляра провайдера или на пограничном мосту магистрали (Раздел 16 в IEEE Std 802.1Q), или как С-тегированные функции поддержки интерфейса услуги или функции поддержки интерфейса дистанционного обслуживания клиентов, специфицированные в 15.4 или 15.6 в IEEE Std 802.1Q-2013 для случая DRNI, поддерживаемого на пограничном порту клиента или порту удаленного доступа или на пограничном мосте провайдера.

[00686] Значение: Целое число в диапазоне от 0 до 4095.

[00687] extractPortConversationID

[00688] extractPortConversationID

[00689] Эта функция извлекает значение ID диалога порта путем применения алгоритма порта к значениям параметров примитива услуги, который вызывается на агрегаторе после приема примитива ISS на одном порте другой функции DR. Отношение значений параметров на примитивах ISS на агрегаторе и соответствующих примитивах услуги на порту функции DR обеспечивается ассоциированной поддерживающей функцией на агрегаторе и портом функции DR и их конфигурациями. См. Примечание выше.

[00690] Значение: Целое число в диапазоне от 0 до 4095.

[00691] InitializeDRNIGatewayConversation

[00692] Эта функция устанавливает Drni_Portal_System_Gateway_Conversation в последовательность нулей, индексируемую посредством ID диалога шлюза.

[00693] InitializeDRNIPortConversation

[00694] Эта функция устанавливает Drni_Portal_System_Port_Conversation в последовательность нулей, индексируемую посредством ID диалога порта.

[00695] InitializelPPGatewayConversation

[00696] Эта функция устанавливает Ipp_Gateway_Conversation_Direction в последовательность нулей, индексируемую посредством ID диалога шлюза.

[00697] InitializelPPPortConversation

[00698] Эта функция устанавливает Ipp_Port_Conversation_Passes в последовательность нулей, индексируемую посредством ID диалога порта.

[00699] recordDefaultDRCPDU

[00700] Эта функция устанавливает значения параметров по умолчанию для соседней портальной системы на IPP, предоставленной администратором, на текущие операционные значения параметров соседней портальной системы следующим образом:

- DRF_Neighbor_Port_Algorithm

= DRF_Neighbor_Admin_Port_Algorithm;

- DRF_Neighbor_Gateway_Algorithm

= DRF_Neighbor_Admin_Gateway_Algorithm;

- DRF_Neighbor_Conversation_PortList_Digest

= DRF_Neighbor_Admin_Conversation_PortList_Digest;

- DRF_Neighbor_Conversation_GatewayList_Digest

= DRF_Neighbor_Admin_Conversation_GatewayList_Digest;

- DRF_Neighbor_Oper_DRCP_State

= DRF_Neighbor_Admin_DRCP_State;

- DRF_Neighbor_Aggregator_Priority

= aAggPortPartnerAdminSystemPriority;

- DRF_Neighbor_Aggregator_ID = aAggPortPartnerAdminSystemID;

- Drni_Neighbor_Portal_Priority

= aAggPortPartnerAdminSystemPriority;

- Drni_Neighbor_Portal_Addr = aAggPortPartnerAdminSystemID;

- DRF_Neighbor_Portal_System_Number

= DRF_Home_Conf_Neighbor_Portal_System_Number;

- DRF_Neighbor_Portal_Topology = Drni_Portal_Topology;

- DRF_Neighbor_Loop_Break_Link = DRF_Home_Loop_Break_Link и - DRF_Neighbor_Conf_Portal_System_Number

= DRF_Portal_System_Number.

[00701] Кроме того, для соседней портальной системы на IPP:

- DRF_Neighbor_State установлен в NULL (булев флаг для шлюза соседней портальной системы установлен в FALSE, и список операционных портов агрегирования на соседней портальной системе на этом IPP опустошен), и если aDrniPortalTopology сконфигурирован, чтобы содержать три портальные системы, то DRF_Other_Neighbor_State также устанавливается в NULL (булев флаг для шлюза другой соседней портальной системы установлен в FALSE, и список операционных портов агрегирования на другой соседней портальной системе на этом IPP пустой). Никакая информация о состоянии портальной системы не доступна для любой портальной системы на этом IPP;

- DRF_Neighbor_Admin_Aggregator_Key на этом IPP установлен в ноль;

- DRF_Other_Neighbor_Admin_Aggregator_Key на этом IPP установлен в ноль;

- DRF_Neighbor_Oper_Partner_Aggregator_Key на этом IPP установлен в ноль;

- DRF_Other_Neighbor_Oper_Partner_Aggregator_Key на этом IPP установлен в ноль, и,

- Переменная ChangePortal установлена в TRUE.

[00702] Наконец, она устанавливает CC_Time_Shared и CC_EncTag_Shared в FALSE.

[00703] recordNeighborState

[00704] Эта функция записывает значения параметров для Drni_Portal_System_State[] и DRF_Home_Oper_DRCP_State, переносимых в принятом DRCPDU на IPP, как текущие значения параметров для Drni_Neighbor_State[] и DRF_Neighbor_Oper_DRCP_State, ассоциированных с этим IPP, соответственно, и устанавливает DRF_Neighbor_Oper_DRCP_State.IPP_Activity в TRUE.

[00705] Она также записывает переменные, представленные ниже, следующим образом:

- Значения параметров для Home_Gateway в DRF_Home_Oper_DRCP_State и Active_Home_Ports в Home Ports Information TLV, переносимые в принятом DRCPDU на IPP, используются в качестве текущих значений для DRF_Neighbor_State на этом IPP, и ассоциирует эту информацию состояния портальной системы на этом IPP с портальной системой, идентифицированной посредством DRF_Neighbor_Portal_System_Number;

- Значения параметров для Other_Gateway в DRF_Home_Oper_DRCP_State и Other_Neighbor_Ports в Other Ports Information TLV, переносимые в принятом DRCPDU на IPP, используются в качестве текущих значений для DRF_Other_Neighbor_State на этом IPP, и ассоциирует эту информацию состояния портальной системы с портальной системой, идентифицированной значением, присвоенным двух старшим битам DRF_Other_Neighbor_Admin_Aggregator_Key, переносимом в Other Ports Information TLV в принятом DRCPDU. Если никакой Other Ports Information TLV не переносится в принятом DRCPDU, и портальная топология содержит три портальные системы, DRF_Other_Neighbor_State установлен в NULL (Other_Gateway установлен в FALSE, и список операционных портов агрегирования на другой соседней портальной системе на этом IPP опустошен), и никакая информация состояния портальной системы не доступна на этом IPP для удаленной соседней портальной системы на IPP;

- DRF_Neighbor_Admin_Aggregator_Key

= DRF_Home_Admin_Aggregator_Key;

- DRF_Neighbor_Oper_Partner_Aggregator_Key

= DRF_Home_Oper_Partner_Aggregator_Key;

- DRF_Other_Neighbor_Admin_Aggregator_Key

= DRF_Other_Neighbor_Admin_Aggregator_Key и,

- DRF_Other_Neighbor_Oper_Partner_Aggregator_Key

N = DRF_Other_Neighbor_Oper_Partner_Aggregator_Key.

Как DRF_Other_Neighbor_Admin_Aggregator_Key, так и DRF_Other_Neighbor_Oper_Partner_Aggregator_Key установлены в NULL, когда принятый DRCPDU не содержит Other Ports Information TLV.

[00706] Кроме того, если поддерживается совместное во времени использование сети/IPL, функция записывает значение параметра для DRF_Home_Network/IPL_Sharing_Method, переносимого в принятом Network/IPL Sharing Method TLV в качестве текущего значения параметра для DRF_Neighbor_Network/IPL_Sharing_Method и если оно то же, что и DRF_Home_Network/IPL_Sharing_Method системы, она устанавливает CC_Time_Shared в TRUE, иначе она устанавливает CC_Time_Shared в FALSE.

[00707] Кроме того, если поддерживается совместное использование сети/IPL посредством метки или совместное использование сети/IPL посредством инкапсуляции, то функция записывает значения параметров, относящиеся к совместному использованию сети/IPL, соседней портальной системы, содержащиеся в принятых Network/IPL Sharing TLV от IPP, в качестве текущих значений операционных параметров для непосредственно соседней портальной системы на этом IPP следующим образом:

[00708] DRF_Neighbor_Network/IPL_Sharing_Method =

DRF_Home_Network/IPL_Sharing_Method, переносимому в принятом Network/IPL Sharing Method TLV;

[00709] DRF_Neighbor_Network/IPL_IPLEncap_Digest =

DRF_Home_Network/IPL_IPLEncap_Digest, переносимому в принятом Network/IPL Sharing Encapsulation TLV; и

[00710] DRF_Neighbor_Network/IPL_NetEncap_Digest =

DRF_Home_Network/IPL_NetEncap_Digest, переносимому в принятом Network/IPL Sharing Encapsulation TLV.

[00711] Она затем сравнивает вновь обновленные значения соседней портальной системы с ожидаемыми для этой портальной системы и, если

[00712] DRF_Neighbor_Network/IPL_Sharing_Method ==

DRF_Home_Network/IPL_Sharing_Method, и

[00713] DRF_Neighbor_Network/IPL_IPLEncap_Digest

== DRF_Home_Network/IPL_IPLEncap_Digest, и

[00714] DRF_Neighbor_Network/IPL_NetEncap_Digest

== DRF_Home_Network/IPL_NetEncap_Digest, то

[00715] она устанавливает CC_EncTag_Shared в TRUE;

[00716] В противном случае, если одно или более из сравнений показывают, что значения различаются,

[00717] она устанавливает CC_EncTag_Shared в FALSE.

[00718] Она затем сравнивает операционное состояние шлюза для каждой портальной системы, как сообщено посредством Drni_Portal_System_State[] этой портальной системы, с операционным состоянием шлюза для той же портальной системы, как сообщено посредством Drni_Neighbor_State[], и если любые из них отличаются, она устанавливает GatewayConversationUpdate в TRUE и DRF_Home_Oper_DRCP_State.Gateway_Sync в FALSE, в противном случае GatewayConversationUpdate остается неизменным, и DRF_Home_Oper_DRCP_State.Gateway_Sync устанавливается в TRUE.

[00719] Она также сравнивает список ID портов операционных портов агрегирования для каждой портальной системы, как сообщено посредством Drni_Portal_System_State[] этой портальной системы, со списком ID портов операционных портов агрегирования для тех же портальных систем, как сообщено посредством Drni_Neighbor_State[], и если любые из них отличаются, она устанавливает PortConversationUpdate в TRUE и DRF_Home_Oper_DRCP_State.Port_Sync в FALSE, в противном случае PortConversationUpdate остается неизменным, и DRF_Home_Oper_DRCP_State.Port_Sync устанавливается в TRUE.

[00720] recordPortalConfValues

[00721] Эта функция записывает сконфигурированные значения параметров соседней портальной системы, переносимые в принятом DRCPDU от IPP, как текущие значения операционных параметров для непосредственно соседней портальной системы на этом IPP следующим образом:

[00722] DRF_Neighbor_Portal_System_Number

= DRF_Portal_System_Number;

[00723] DRF_Neighbor_Portal_Topology = Drni_Portal_Topology;

[00724] DRF_Neighbor_Conf_Portal_System_Number

= DRF_Home_Conf_Neighbor_Portal_System_Number;

[00725] DRF_Neighbor_Loop_Break_Link

= DRF_Home_Loop_Break_Link;

[00726] DRF_Neighbor_Oper_Aggregator_Key

= DRF_Home_Oper_Aggregator_Key;

[00727] DRF_Neighbor_Port_Algorithm

= DRF_Home_Port_Algorithm;

[00728] DRF_Neighbor_Conversation_PortList_Digest

= DRF_Home_Conversation_PortList_Digest;

[00729] DRF_Neighbor_Gateway_Algorithm

= DRF_Home_Gateway_Algorithm; и

[00730] DRF_Neighbor_Conversation_GatewayList_Digest

= DRF_Home_Conversation_GatewayList_Digest.

[00731] Она затем сравнивает вновь обновленные значения соседней портальной системы с ожидаемыми для этой портальной системы, и если

[00732] DRF_Neighbor_Portal_System_Number

== DRF_Home_Conf_Neighbor_Portal_System_Number, и

[00733] DRF_Neighbor_Portal_Topology

== Drni_Portal_Topology, и

[00734] DRF_Neighbor_Loop_Break_Link

== DRF_Home_Loop_Break_Link, и

[00735] DRF_Neighbor_Conf_Portal_System_Number

== DRF_Portal_System_Number, и

[00736] DRF_Neighbor_Oper_Aggregator_Key

== DRF_Home_Oper_Aggregator_Key, и

[00737] DRF_Neighbor_Port_Algorithm

== DRF_Home_Port_Algorithm, и

[00738] DRF_Neighbor_Conversation_PortList_Digest

== DRF_Home_Conversation_PortList_Digest, и

[00739] DRF_Neighbor_Gateway_Algorithm

== DRF_Home_Gateway_Algorithm, и

[00740] DRF_Neighbor_Conversation_GatewayList_Digest

== DRF_Home_Conversation_GatewayList_Digest, то

[00741] переменная Differ_Conf_Portal устанавливается в FALSE;

[00742] В противном случае, если одно или более из сравнений показывают, что значения различаются,

[00743] переменная Differ_Conf_Portal устанавливается в TRUE, и ассоциированные пары переменных, имеющих различные значения, доступны в aDrniIPPDebugDifferPortalReason.

[00744] recordPortalValues

[00745] Эта функция записывает значения параметров для Drni_Aggregator_Priority, Drni_Aggregator_ID, Drni_Portal_Priority и Drni_PortalID, переносимые в принятом DRCPDU от IPP, как текущие значения операционных параметров для непосредственно соседней портальной системы на этом IPP, следующим образом:

[00746] DRF_Neighbor_Aggregator_Priority

= Drni_Aggregator_Priority;

[00747] DRF_Neighbor_Aggregator_ID = Drni_Aggregator_ID;

[00748] Drni_Neighbor_Portal_Priority

= Drni_Portal_Priority и,

[00749] Drni_Neighbor_Portal_Addr = Drni_Portal_Addr.

[00750] Она затем сравнивает вновь обновленные значения соседней портальной системы с ожидаемыми для этой портальной системы, и если

[00751] DRF_Neighbor_Aggregator_Priority == Drni_Aggregator_Priority и

[00752] DRF_Neighbor_Aggregator_ID == Drni_Aggregator_ID и

[00753] Drni_Neighbor_Portal_Priority == Drni_Portal_Priority и

[00754] Drni_Neighbor_Portal_Addr == Drni_Portal_Addr, то

[00755] переменная Differ_Portal устанавливается в FALSE;

[00756] В противном случае, если одно или более из сравнений показывают, что значения различаются,

[00757] переменная Differ_Portal устанавливается в TRUE, и ассоциированный набор переменных, имеющих различные значения, доступны в aDrniIPPDebugDifferPortalReason.

[00758] reportToManagement

[00759] Эта функция предупреждает систему управления о потенциальном существовании ошибки конфигурации портальной системы в этом портале в связи с приемом неверно сконфигурированного DRCPDU и посылает к ней информацию о конфликте из неверно сконфигурированного принятого DRCPDU.

[00760] setDefaultPortalSystemParameters

[00761] Эта функция устанавливает переменные данной портальной системы на административный набор значений следующим образом:

- Drni_Aggregator_Priority = aAggActorSystemPriority;

- Drni_Aggregator_ID = aAggActorSystemID;

- Drni_Portal_Priority = aDrniPortalPriority;

- Drni_Portal_Addr = aDrniPortalAddr;

- DRF_Portal_System_Number = aDrniPortalSystemNumber;

- DRF_Home_Admin_Aggregator_Key = aAggActorAdminKey;

- DRF_Home_Port_Algorithm = aAggPortAlgorithm;

- DRF_Home_Gateway_Algorithm = aDrniGateway Алгоритм;

- DRF_Home_Conversation_PortList_Digest = MD5 дайджест на

aDrniConvAdminGateway[];

- DRF_Home_Conversation_GatewayList_Digest = MD5 дайджест на

aAggConversationAdminPort[] и;

- DRF_Home_Oper_DRCP_State = DRF_Neighbor_Admin_DRCP_State.

[00762] Кроме того, она устанавливает Drni_Portal_System_State[], как если бы все шлюзы в портале были сообщены как FALSE, и никакой порт агрегирования на любой портальной системе не был сообщен, как действующий.

[00763] setGatewayConversation

[00764] Эта функция устанавливает Drni_Gateway_Conversation на значения, вычисленные из aDrniConvAdminGateway[] и текущего Drni_Portal_System_State[], следующим образом:

[00765] Для каждого индексированного ID диалога шлюза, номер портальной системы идентифицируется выбором наивысшего по приоритету номера портальной системы в списке номеров портальных систем, предоставленном посредством aDrniConvAdminGateway[], когда включены только действующие шлюзы, как обеспечено посредством булевых флагов шлюзов переменной Drni_Portal_System_State[].

[00766] setlPPGatewayConversation

[00767] Эта функция устанавливает Ipp_Other_Gateway_Conversation на значения, вычисленные из aDrniConvAdminGateway[] и Drni_Neighbor_State[] следующим образом:

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

[00769] setlPPGatewayUpdate

[00770] Эта функция устанавливает IppGatewayUpdate на каждом IΡΡ на данной портальной системе в TRUE.

[00771] setlPPPortConversation

[00772] Эта функция устанавливает Ipp_Other_Port_Conversation_Portal_System в значения, вычисленные из aAggConversationAdminPort[] и Drni_Neighbor_State[] следующим образом:

[00773] Для каждого индексированного ID диалога порта, номер портальной системы идентифицируется выбором наивысшего по приоритету номера портальной системы в списке номеров портальной системы, обеспеченном посредством aAggConversationAdminPort[], когда включены только действующие порты агрегирования, как обеспечено ассоциированными списками переменной Drni_Neighbor_State[].

[00774] setIPPPortUpdate

[00775] Эта функция устанавливает IppPortUpdate на каждом IPP на этой портальной системе в TRUE.

[00776] setPortConversation

[00777] Эта функция устанавливает Drni_Port_Conversation в значения, вычисленные из aAggConversationAdminPort[] и текущего Drni_Portal_System_State[] следующим образом:

[00778] Для каждого индексированного ID диалога порта, номер портальной системы идентифицируется путем извлечения двух младших битов компонента приоритета наивысшего по приоритету ID порта (6.3.4) в списке ID портов, предоставленном посредством aAggConversationAdminPort[], когда включены только действующие порты агрегирования, как это обеспечено ассоциированными списками переменной Drni_Portal_System_State[].

[00779] updateDRFHomeState

[00780] Эта функция обновляет DRF_Home_State на основе операционного состояния локальных портов следующим образом:

[00781] Шлюз установлен в TRUE или FALSE на основе механизмов, которые используются для идентификации операционного состояния локального шлюза (TRUE означает действующее, и что

[00782] соединение не блокируется операцией протокола сетевого управления);

[00783] Список действующих портов агрегирования создается включением только тех ID портов агрегирования, для которых присоединенный агрегатор сообщает их как имеющих Actor_Oper_Port_State.Distributing == TRUE (условие, которое исключает случаи, когда ассоциированные порты агрегирования либо не функционируют (port_enabled = FALSE), в состоянии EXPIRED (недействительно) или не в LAG), и PSI установлен в TRUE, если DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE на всех IPP на этой портальной системе, в противном случае PSI устанавливается в FALSE.

[00784] Кроме того, если PSI == TRUE и шлюз == FALSE, то Actor_Oper_Port_State.Sync установлено в FALSE на всех портах агрегирования на этой портальной системе.

[00785] Функция также устанавливает:

[00786] GatewayConversationUpdate в TRUE, если операционное состояние шлюза или сконфигурированные списки для Drni_Conversation_GatewayList[] изменились, и устанавливает PortConversationUpdate в TRUE, если было любое изменение в списке действующих портов агрегирования, как сообщается посредством изменений в ассоциированных переменных Actor_Oper_Port_State.Distributing или сконфигурированных списках для Drni_Conversation_PortList[], в противном случае;

[00787] GatewayConversationUpdate и PortConversationUpdate остаются неизменными.

[00788] updatelPPGatewayConversationDirection

[00789] Эта функция вычисляет значение для Ipp_Gateway_Conversation_Direction следующим образом:

[00790] Для каждого ID диалога шлюза, значение равно TRUE, если и только если:

[00791] а) переменные Drni_Gateway_Conversation и Ipp_Portal_System_State[] указывают, что целевая портальная система для этого ID диалога шлюза лежит за данным IPP, и

[00792] b) Drni_Gateway_Conversation и Ipp_Other_Gateway_Conversation согласованы в отношении того, какая портальная система должна получать этот ID диалога шлюза.

[00793] Кроме того, если Drni_Gateway_Conversation и Ipp_Other_Gateway_Conversation не согласованы для любого ID диалога шлюза:

[00794] Она устанавливает DRF_Home_Oper_DRCP_State.Gateway_Sync в FALSE и

[00795] NTTDRCPDU в TRUE.

[00796] В противном случае:

[00797] DRF_Home_Oper_DRCP_State.Gateway_Sync и NTTDRCPDU остаются неизменными.

[00798] Ipp_Gateway_Conversation_Direction инициализируется в FALSE и пересчитывается каждый раз, когда какая-либо из входящих в него переменных изменяется.

[00799] updateIPPPortConversationPasses

[00800] Эта функция вычисляет значение для Ipp_Port_Conversation_Passes следующим образом:

[00801] Для каждого ID диалога порта, значение равно TRUE (ID проходит), если и только если:

[00802] а) переменные Drni_Port_Conversation и Ipp_Portal_System_State[] указывают, что целевая портальная система для этого ID диалога порта лежит за данным IPP, и

[00803] b) Drni_Port_Conversation и Ipp_Other_Port_Conversation_Portal_System согласованы в отношении того, какая портальная система должна получить этот ID диалога порта.

[00804] Кроме того, если Drni_Port_Conversation и

Ipp_Other_Port_Conversation_Portal_System не согласованы для любого ID диалога порта:

[00805] Она устанавливает DRF_Home_Oper_DRCP_State.Port_Sync в FALSE и

[00806] NTTDRCPDU в TRUE.

[00807] В противном случае:

[00808] DRF_Home_Oper_DRCP_State.Port_Sync и NTTDRCPDU остаются неизменными.

[00809]

[00810] Ipp_Port_Conversation_Passes инициализируется в FALSE и пересчитывается каждый раз, когда какая-либо из входящих в него переменных изменяется.

[00811] updateKey

[00812] Эта функция обновляет операционный ключ агрегатора, DRF_Home_Oper_Aggregator_Key, следующим образом:

[00813] Если enable_long_pdu_xmit == TRUE, то:

[00814] DRF_Home_Oper_Aggregator_Key устанавливается в значение

DRF_Home_Admin_Aggregator_Key путем замены его двух старших битов на значение 01; в противном случае DRF_Home_Oper_Aggregator_Key устанавливается на самой низкое числовое ненулевое значение из набора, содержащего значения DRF_Home_Admin_Aggregator_Key, DRF_Neighbor_Admin_Aggregator_Key и DRF_Other_Neighbor_Admin_Aggregator_Key, на каждом IPP.

[00815] updateNTT

[00816] Эта функция устанавливает NTT в TRUE, если любой из DRF_Home_Oper_DRCP_State.GatewaySync или DRF_Home_Oper_DRCP_State.PortSync или DRF_Neighbor_Oper_DRCP_State.GatewaySync или DRF_Neighbor_Oper_DRCP_State.PortSync равен FALSE.

[00817] updatePortalState

[00818] По всем операциям, связанным с этой функцией, информация, предоставленная посредством DRF_Other_Neighbor_State на IPP, учитывается, если только Drni_Neighbor_ONN на том же IPP соответствует FALSE;

[00819] Эта функция обновляет Drni_Portal_System_State[] следующим образом: информация для данной портальной системы, DRF_Home_State, индексированная посредством номера портальной системы, включена в Drni_Portal_System_State[]. Для каждой из других портальных систем в портале, если информация состояния любой другой портальной системы доступна из двух IPP в этой портальной системе, то:

[00820] Для этой портальной системы, только информация состояния портальной системы, обеспеченная посредством DRF_Neighbor_State на IPP, имеющем другую портальную систему в качестве соседней портальной системы, индексированной номером портальной системы, будет включена в Drni_Portal_System_State[].

[00821] В противном случае, если информация состояния портальной системы доступна только из одного IPP на этой портальной системе, то:

[00822] Эта информация состояния портальной системы, индексированная ассоциированным номером портальной системы, будет включена в Drni_Portal_System_State[] независимо от того, предоставляется ли эта информация посредством DRF_Neighbor_State или DRF_Other_Neighbor_State на этом IPP. Если информация для портальной системы доступна только от DRF_Other_Neighbor_State на этом IPP, то ONN устанавливается в TRUE на этом IPP.

[00823] Каждая портальная система, включенная в портальную топологию, для которой информация состояния портальной системы не доступна из любого из IPP, имеет свою ассоциированную информацию состояния портальной системы Drni_Portal_System_State[], установленную в NULL (шлюз устанавливается в FALSE, и список операционных портов агрегирования на портальной системе опустошается).

[00824] Эта функция обновляет также Ipp_Portal_System_State[] для каждого IPP на этой портальной системе следующим образом:

[00825] Если информация состояния любой другой портальной системы доступна от двух IPP, то:

[00826] Если домашняя портальная система, которая не имеет какого-либо IPL, сконфигурированного как канал разрыва петли, то для каждого IPP на портальной системе, только информация состояния портальной системы, обеспечиваемая посредством DRF_Neighbor_State на этом IPP, будет включена в ассоциированный Ipp_Portal_System_State[], индексированный ассоциированным номером портальной системы, в противном случае

[00827] DRF_Neighbor_State на IPP, индексированный ассоциированным номером портальной системы, будет включен в качестве первого состояния в соответствующий Ipp_Portal_System_State[], и любое другое дополнительное состояние, ассоциированное с другой портальной системой, сообщенное в принятом DRCPDU на этом IPP, индексированное ассоциированным номером портальной системы, будет включено в качестве второго состояния в Ipp_Portal_System_State[], только если Drni_Neighbor_ONN на том же IPP соответствует FALSE.

[00828] [По аналогии с Drni_Portal_System_State[], каждая портальная система, включенная в портальную топологию, для которой информация состояния портальной системы не доступна из любого из IPP, имеет свою ассоциированную информацию состояния портальной системы Ipp_Portal_System_State[], установленную в NULL (шлюз установлен в FALSE, и список операционных портов агрегирования на портальной системе опустошен).]

[00829] updatePortalSystemGatewayConversation

[00830] Эта функция устанавливает Drni_Portal_System_Gateway_Conversation в результат логической операции И между булевым вектором, построенным из Drni_Gateway_Conversation, путем установки в FALSE всех индексированных записей ID диалога шлюза, ассоциированных с другими портальными системами в портале, и булевым вектором, построенным из Ipp_Other_Gateway_Conversation всех IPP, путем установки в FALSE всех индексированных записей ID диалога шлюза, ассоциированных с другими портальными системами в портале.

[00831] updatePortalSystemPortConversation

[00832] Эта функция устанавливает Drni_Portal_System_Port_Conversation в результат логической операции И между булевым вектором, построенным из Drni_Port_Conversation, путем установки в FALSE всех индексированных записей ID диалога порта, ассоциированных с другими портальными системами в портале, и булевым вектором, построенным из Ipp_Other_Port_Conversation_Portal_System, путем установки в FALSE всех индексированных записей ID диалога порта, ассоциированных с другими портальными системами в портале.

[00833] Таймеры

[00834] Последующее описание фокусируется на различных таймерах, применимых в соответствии с одним вариантом осуществления изобретения.

[00835] current_while_timer: Этот таймер используется для обнаружения того, стала ли недействительной по истечении времени принятая протокольная информация. Если Actor_Oper_State.LACP_Timeout установлен на короткий таймаут, таймер запускается со значением Short_Timeout_Time. В противном случае, он запускается со значением Long_Timeout_Time.

[00836] periodic_timer (time_value): Этот таймер используется для генерации периодических передач. Он запускается с использованием значения Slow_Periodic_Time или Fast_Periodic_Time, как задано в конечном автомате периодической передачи.

[00837] wait_while_timer: Этот таймер обеспечивает гистерезис перед выполнением изменения агрегирования, чтобы позволить всем каналам, которые будут присоединяться к ассоциированной группе агрегирования каналов, сделать это. Он запускается с использованием значения Aggregate_Wait_Time.

[00838] Сообщения

[00839] В одном варианте только одно сообщение используется:

[00840] IPPМ:M_UNITDATA.indication(DRCPDU): Это сообщение генерируется посредством анализатора управления DRCP в результате приема DRCPDU.

[00841] DRCPCtrlMuxN:M_UNITDATA.indication(DRCPDU)

[00842] Это сообщение генерируется анализатором/ мультиплексором управления DRCP в результате приема DRCPDU.

[00843] Отметим, что эти два сообщения являются сходными сообщениями для двух различных вариантов осуществления.

[00844] Операции конечных автоматов

[00845] Возвращаясь к операции общего процесса конечного автомата, блок-схема на фиг. 7 определяет набор операций, опирающихся, в одном варианте осуществления, на функции, переменные и сообщения, описанные здесь выше. Этот процесс может быть инициирован в ответ на прием DRCPDU. Этот DRCPDU первоначально передается в блок приема (блок 702). Набор стрелок, обозначенных “информация состояния соседа” представляет новую информацию соседа, содержащуюся во входящем DRCPDU или поставляемую административными значениями по умолчанию, вводимую в каждой конечный автомат автоматом приема DRCPDU. Набор стрелок, обозначенных “информация состояния домашней системы”, представляет поток обновленной информации состояния домашней системы между конечными автоматами. Передача DRCPDU происходит либо как результат автомата периодической передачи, определяющего необходимость периодической передачи DRCPDU, или как результат изменений в информации состояния домашней системы, которые должны быть доведены до сведения соседей. Необходимость передачи DRCPDU сигнализируется к автомату передачи путем выдачи NTTDRCPDU. Остальные стрелки представляют совместно используемые переменные в описании конечных автоматов, которые позволяют конечному автомату вызывать событие, которое должно происходить в другом конечном автомате.

[00846] Автомат приема генерирует NTTDRCPDU, выполняет операцию изменения порта, обновление диалога шлюза и обновление диалога порта.

[00847] Автомат 704 периодической передачи принимает информацию состояния соседа и возвращает информацию состояния домашней системы. Автомат периодической передачи (блок 704) генерирует NTTDRCPDU.

[00848] Автомат портальной системы (блок 706) отвечает за обновление операционного состояния всех шлюзов и портов агрегирования в портале на основе локальной информации и DRCPDU, принятых на IPP домашней портальной системы. Этот конечный автомат предусмотрен для каждой портальной системы.

[00849] Автоматы шлюза и агрегатора DRNI (708) отвечают за конфигурирование ID диалогов шлюзов, которым разрешено проходить через данный шлюз функции DR, и ID диалогов портов, которым разрешено распространяться через агрегатор функции DR. Эти конечные автоматы предусмотрены для каждой портальной системы.

[00850] Автоматы IPP DRNI (710) отвечают за конфигурирование ID диалогов шлюзов и ID диалогов портов, которым разрешено проходить через IPP функции IPP.

[00851] Автомат передачи (712) обрабатывает передачу DRCPDU, как по запросу от других конечных автоматов, так и на периодической основе.

[00852] Автомат приема DRCPDU

[00853] Автомат приема может реализовать функцию, указанную на фиг. 8, с ее ассоциированными параметрами, как описано здесь выше. Процесс может быть инициализирован в блоке 802, когда функция включена и recordDefaultDRCPDU() исполняется и когда DRF_Neighbor_Oper_DRCP_State.IPP_Activitiy ложно. Затем выполняется вход в состояние недействительности по истечении времени (блок 804), и после приема DRCPDU конечный автомат входит в состояние PORTAL_CHECK (блок 808). Функция recordPortalValues проверяет, ассоциирован ли DRCPDU с этим порталом. Если нет, событие сообщается системе управления, и никакая дополнительная обработка DRCPDU не выполняется любым из конечных автоматов этого портала. Если recordPortalValues идентифицирует принятый DRCPDU, будет выполняться переход в состояние COMPATIBILITY CHECK (проверка совместимости) (блок 809), чтобы проверяться с помощью функции recordPortalConfValues. Это сравнивает административно сконфигурированные значения, которые ассоциированы с данным порталом, с принятой информацией, и если они различаются, система будет входить в состояние REPORT_TO_MANAGEMENT (блок 810), и неверно сконфигурированный DRCPDU будет сообщаться системе управления. Автомат приема выходит из состояния REPORT_TO_MANAGEMENT, когда принимается новый DRCPDU (или IPP отключается).

[00854] Если принятый DRCPDU сконфигурирован в соответствии с ожидаемыми значениями для этого портала, автомат приема будет входить в состояние CURRENT (текущее) (блок 812).

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

[00856] В одном варианте осуществления, после приема DRCPDU, конечный автомат входит в состояние PORTAL_CHECK (проверка портала). Функция recordPortalValues проверяет, ассоциирован ли DRCPDU с этим порталом. Если нет, то конечный автомат переходит в состояние REPORT_TO_MANAGEMENT, и принятый DRCPDU будет сообщен системе управления. В состоянии REPORT_TO_MANAGEMENT, система выполнит выход в состояние PORTAL_CHECK, если принимается новый DRCPDU, или в состояние недействительности по истечении времени, если DRCP_current_while_timer истекает. Если функция recordPortalValues идентифицирует принятый DRCPDU как ассоциированный с данным порталом, будет выполняться вход в состояние COMPATIBILITY_CHECK, чтобы проверяться с помощью функции recordPortalConfValues. Она сравнивает административно сконфигурированные значения, которые ассоциированы с этим порталом, с принятой информацией, и если они различаются, система будет входить в состояние REPORT_TO_MANAGEMENT, и неверно сконфигурированный DRCPDU будет сообщаться системе управления. Если портальная система продолжает принимать DRCPDU, которые не соответствуют административно сконфигурированным ожиданиям в течение периода больше, чем двукратный короткий таймаут, конечный автомат будет переходить в состояние DEFAULTED, и текущие операционные параметры для портальной(ых) системы (систем) на этом IPP будут перезаписываться административно сконфигурированными значениями, и будет запускаться обновление портальной системы.

[00857] Если принятый DRCPDU сконфигурирован в соответствии с ожидаемыми значениями для этого портала, автомат приема DRCPDU входит в состояние CURRENT.

[00858] Функция recordNeighborState записывает информацию состояния портала соседа, содержащуюся в DRCPDU, в операционные переменные состояния портала соседа и обновляет свою собственную переменную состояния портала домашней системы. Если они различаются, то устанавливаются триггеры, чтобы уведомить соседа, но и локальные переменные события устанавливаются для запуска обновлений на автомате локальной портальной системы (PS- см. фиг. 10), автомате шлюза и агрегатора DRNI (DGA - см. фиг. 11) и автомате DRNI IPP (IPP - см. фиг. 12).

[00859] В процессе выполнения функций recordPortalValues, recordPortalConfValues и recordNeighborState, автомат приема, совместимый с данной спецификацией, может не подтвердить номер версии, TLV_type или зарезервированные поля в принятых DRCPDU. Те же действия, предпринимаются независимо от значений, принятых в этих полях. Автомат приема может подтвердить поля Portal_Information_Length, Portal_Configuration_Information_Length, DRCP_State_Length или Terminator_Length. Такие действия, вместе с ограничением на дальнейшее улучшение протоколов, обсуждены здесь выше.

[00860] Правила, изложенные выше, позволяют устройствам Версии 1 быть совместимыми с будущими версиями протокола.

[00861] Функция updateNTT используется для определения, требуются ли дальнейшие протокольные передачи; NTTDRCPU установлен в TRUE, если представление соседа относительно переменной операционного состояния портала домашней системы не является актуальным. Тогда запускается current_while таймер. Значением, используемым для запуска таймера, является либо Short_Timeout_Time, либо Long_Timeout_Time, в зависимости от операционного значения таймаута исполнителя.

[00862] Если никакой DRCPDU не принимается до истечения current_while таймера, конечный автомат переходит в состояние EXPIRED. DRF_Neighbor_Oper_DRCP_State.IPP_Activity устанавливается в FALSE, текущее операционное значение переменной Timeout соседа устанавливается на короткий таймаут, и current_while таймер запускается со значением Short_Timeout_Time. Это переходное состояние; настройки таймаута позволяют домашней портальной системе передавать DRCPDU быстро в попытке повторно установить связь с соседом.

[00863] Если никакой DRCPDU вновь не принят до истечения current_while таймера, конечный автомат переходит в состояние DEFAULT. Функция recordDefaultDRCPDU перезаписывает текущие операционные параметры для соседних портальных систем административно сконфигурированными значениями и запускает обновление портальной системы, и состояние сообщается системе управления.

[00864] Если IPP становится недействующим, конечный автомат переходит в состояние INITIALIZE.

DRF_Neighbor_Oper_DRCP_State.IPP_Activity устанавливается в FALSE, функция recordDefaultDRCPDU вызывает использование административных значений параметров партнеров в качестве текущих операционных параметров. Эти действия вынуждают автомат PS отсоединить соседнюю портальную систему от портала, и фильтры ID диалогов шлюзов и портов должны вычисляться заново.

[00865] Автомат приема может также реализовать функцию, указанную на фиг. 16, с ее ассоциированными параметрами. Автомат приема по фиг. 16 следует несколько отличающимся маршрутам потока по сравнению с фиг. 8. Термины и функции альтернативного автомата приема на фиг. 16 аналогичны таковым на фиг. 8. Специалистам в данной области техники будет понятно, что возможны другие реализации в соответствии с принципами и структурами проиллюстрированных автоматов приема.

[00866] Фиг. 33 иллюстрирует способ синхронизации с соседом в узле группы агрегирования каналов DRNI в соответствии с вариантом осуществления изобретения. Способ 3300 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С. Отметим, что опциональные этапы обозначаются как пунктирный блок, как показано на фиг. 33.

[00867] На этапе 3302 узел инициализируется для работы DRCP на IPP, связанном с соседним узлом, использующим IPL. Узел и соседний узел включены в портал, который может содержать дополнительный соседний узел в одном варианте осуществления. Узел связан с соседним узлом через IPP с использованием IPL. В одном варианте осуществления инициализация включает установку значений параметров по умолчанию для соседнего узла на IPP в качестве текущих операционных параметров соседнего узла, предоставленных администратором портала. Параметры включают в себя алгоритм порта соседа, такой как DRF_Neighbor_Port_Algorithm (устанавливается как DRF_Neighbor_Admin_Port_Algorithm), алгоритм шлюза соседа, такой как DRF_Neighbor_Gateway_Algorithm (устанавливается как DRF_Neighbor_Admin_Gateway_Algorithm), и другие, описанные здесь выше в связи с функцией recordDefaultDRCPDU. В одном варианте осуществления инициализация дополнительно включает установку активности IPP соседнего узла в неактивное состояние путем установки DRF_Neigbhor_Oper_DRCP_State.IPP_Activity в “ложно”.

[00868] На этапе 3304 узел определяет, что DRCP включен в IPP. Проверка включает в себя определение переменной (например, IPP_port_enabled), указывающей, что IPP задействует DRCP. В одном варианте осуществления определение осуществляется путем проверки двух переменных для IPP. Одной из них является переменная, указывающая, что IPP задействует DRCP (например, через DRCP_enabled, как описано выше), а другой является переменная, указывающая, что IPL был установлен, и IPP является действующим (например, через IPP_port_enabled, как описано здесь выше).

[00869] На этапе 3306 узел входит в состояние недействительности по истечении времени. В этом состоянии недействительности узел выполняет следующее в одном варианте осуществления: Он устанавливает параметр состояния DRCP узла на недействительное по истечении времени (например, установка DRF_Home_Oper_DRCP_State.Expired, описанная здесь выше, как “истинно”), он также устанавливает активность IPP соседнего узла как неактивное состояние путем установки

DRF_Neigbhor_Oper_DRCP_State.IPP_Activity в “ложно”. Он устанавливает таймер как истекший, если не принят никакой DRCPDU. В одном варианте осуществления, установка таймера выполняется путем установки DRF_Neighbor_Oper_DRCP_State.DRCP_Timeout = короткий таймаут и запуска DRCP_current_while_timer (короткий таймаут).

[00870] После того как таймер истекает, поток переходит на этап 3352, где узел переходит в состояние по умолчанию. В одном варианте осуществления, в состоянии по умолчанию, узел устанавливает значения параметров по умолчанию для соседнего узла на IPP как текущие операционные параметры соседнего узла, предоставленные администратором портала через функцию, такую как recordDefaultDRCPDU, описанную здесь выше. Кроме того, состояние по умолчанию включает в себя отчет о состоянии в систему управления с помощью функции, такой как reportToManagement, как описано здесь выше.

[00871] На этапе 3307 узел принимает DRCPDU. DRCPDU содержит структуру PDU, показанную на фиг. 5, где структура PDU имеет TLV, такие как те, что перечислены в таблице 4. Структура PDU содержит TLV информации домашнего порта и TLV состояния DRCP. В одном варианте осуществления прием DRCPDU указывается в сообщении, генерируемом посредством анализатора/мультиплексора управления DRCP как результат приема DRCPDU, такого как DRCPCtrolMuxN:M_UNITDATA.indication(DRCPDU).

[00872] Далее узел определяет, что принятый DRCPDU ассоциирован с порталом, на этапе 3308. В одном варианте осуществления определение включает в себя проверку переменной (например, Differ_Portal, как описано здесь выше), которая указывает прием DRCPDU, ассоциированного с порталом, или нет. В одном варианте осуществления определение включает в себя выполнение функции (например, recordPortalValues), которая записывает значения параметров портала, переносимые в принятом DRCPDU, как соответствующие значения текущих операционных параметров для соседнего узла на IPP. Значения параметров портала, как описано здесь выше в определении recordPortaValues, включают в себя приоритет агрегатора (например, Drni_Aggregator_Prioirty), ID агрегатора (например, Drni_Aggregator_ID), приоритет соседнего портала (Drni_Portal_Priority) и адрес портала (например, Drni_Portal_Addr) в одном варианте осуществления.

[00873] Если принятый DRCPDU не ассоциирован с порталом, узел может опционально сообщать состояние в систему управления через функцию, такую как reportToManagement, обсужденную здесь выше. Если затем узел принимает другой DRCPDU, поток возвращается на этап 3308, чтобы вновь определить ассоциацию. Аналогичным образом, когда узел находится в состоянии по умолчанию на этапе 3352 и принимает DRCPDU, поток переходит на этап 3308 для определения ассоциации.

[00874] После определения, что принятый DRCPDU ассоциирован с порталом, поток переходит на этап 3310, где узел определяет, что принятый DRCPDU совместим с узлом. Определение включает в себя то, что определение административно сконфигурированных значений, ассоциированных с порталом, согласуется с принятыми значениями из DRCPDU. Проверка включает выполнение функции (например, recordPortalConfValues), которая записывает сконфигурированные значения параметров соседнего узла, переносимые в принятом DRCPDU, как соответствующие текущие значения операционных параметров для соседнего узла на IPP в одном варианте осуществления. Отметим, что сконфигурированные значения параметров в функции, такой как recordPortalConfValue, отличаются от значений параметров портала, таких как recordPortalValue, и отличие обсуждается здесь выше в определениях recordPortalConfValues и recordPortalValues.

[00875] Если принятый DRCPDU не совместим с узлом, узел может опционально сообщать это состояние системе управления с помощью функции, такой как reportToManagement, обсужденной здесь выше. Если затем узел принимает другой DRCPDU, поток возвращается на этап 3308, чтобы вновь определять ассоциацию. При выполнении функции, такой как reportToManagement, узел устанавливает другой таймер на истечение времени, если не принят никакой DRCPDU, и запускает таймер. После того, как таймер истекает, поток возвращается к этапу 3306.

[00876] После определения, что принятый DRCPDU совместим с узлом, узел записывает информацию состояния соседнего узла, содержащуюся в принятом DRCPDU, как операционные переменные состояния соседнего узла на этапе 3312. В одном варианте осуществления функция (например, recordNeighborState) записывает значения параметров, такие как состояние портальной системы (например, Drni_Portal_System_State) и состояние DRCP операции домашнего узла (например, DRF_Home_Oper_DRCP_State), переносимые в принятом DRCPDU, в качестве соответствующих операционных переменных соседнего узла, таких как Drni_Neigbhor_State и DRF_Neighbor_Oper_DRCP_State.

[00877] Опционально, когда записанные операционные переменные состояния соседнего узла отличаются от операционных переменных состояния узла, узел устанавливает один или несколько триггеров, чтобы уведомить соседний узел на этапе 3314. В одном варианте осуществления, функция (например, updateNTT) используется для определения того, требуется ли дальнейшая протокольная передача, как описано здесь выше.

[00878] Способ, обсужденный здесь, обеспечивает эффективный способ для узла DRCP, чтобы обрабатывать информацию, встроенную в DRCPDU, принятый от соседнего узла DRCP. Информация обрабатывается поэтапно, и определяется, что принятый DRCPDU ассоциирован с порталом узла DRCP и совместим с узлом, перед записью информации состояния соседнего узла. Кроме того, вводится таймер, чтобы предотвратить зависание узла в состоянии ожидания.

[00879] Автомат периодической передачи DRCP

[00880] Автомат периодической передачи DRCP может реализовать функцию, определенную на фиг. 9, с ее ассоциированными параметрами, обсужденными здесь выше.

[00881] Автомат периодической передачи DRCP устанавливает желание домашней и соседней портальных систем обмениваться периодическими DRCPDU на IPP для того, чтобы поддерживать портал, и устанавливает, как часто должны происходить эти периодические передачи. Периодические передачи будут иметь место, если это желательно любому участнику. Передачи происходят с частотой, определяемой соседней портальной системой; эта частота связана со скоростью, с которой соседняя портальная система будет блокировать по превышению лимита времени принятую информацию.

[00882] Конечный автомат имеет четыре состояния. Они заключаются в следующем:

NO_PERIODIC (блок 902). В этом состоянии периодические передачи блокируются, и выполняется остановка функции periodic_timer. FAST_PERIODIC (блок 904). В этом состоянии периодические передачи разрешены на высокой скорости передачи. Это состояние вводится из состояния NO_Periodic (блок 902) в ответ на безусловный переход (UCT). Состояние Fast_Periodic может перейти в периодическую передачу (блок 910) и в состояние slow_periodic (блок 905). Состояние SLOW_PERIODIC 906 может быть введено из FAST_PERIODIC 904, когда определен длинный таймаут. В этом состоянии периодические передачи разрешены с медленной скоростью передачи. Если периодический таймер истекает, то состояние переходит в PERIODIC_TX (блок 910). PERIODIC_TX. Это переходное состояние, вход в которое осуществляется по истечении periodic_timer, что декларирует NTT, а затем выходит в FAST_PERIODIC или SLOW_PERIODIC в зависимости от настройки DRCP_Timeout соседа.

[00883] Если периодические передачи разрешены, то частота, с которой они происходят, определяется значением переменной DRF_Neighbor_Oper_DRCP_State.Timeout. Если эта переменная установлена на короткий таймаут, то значение fast_periodic_time используется для определения временного интервала между периодическими передачами. В противном случае, slow_periodic_time используется для определения временного интервала.

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

[00885] Автомат периодической передачи DRCP может также реализовать функцию, определенную на фиг. 17, с ее ассоциированными параметрами. Фиг. 17 содержит различные термины (например, DRCP_periodic_timer и NTTDRCPDU, not periodic_timer и NTT, соответственно, как на фиг. 9), но в остальном потоки те же. Термины и функции альтернативного автомата передачи на фиг. 17 аналогичны таковым на фиг. 9. Специалистам в данной области техники будет понятно, что возможны другие реализации в соответствии с принципами и структурами показанных автоматов передачи.

[00886] Автомат портальной системы

[00887] Автомат портальной системы может реализовать функцию, определенную на фиг. 10, с ее ассоциированными параметрами, обсужденными здесь выше. Этот процесс может инициализироваться в состоянии инициализации портальной системы (блок 1002). Выполняются функции setDefaultPortalSystemParameters и updateKey. В случае если либо ChangePortal, либо ChangeDRFPorts верны, процесс переходит в состояние обновления портальной системы (блок 1004). В состоянии обновления портальной системы, ChangePortal установлен в FALSE, СhangeDRFPorts установлен в FALSE, выполняются updateDRFhomestate и updateKey. Следующее обновление запускается, когда либо ChangePortal, либо ChangeDRFPorts обновляются на TRUE.

[00888] Таким образом, варианты осуществления предусматривают способ, содержащий этапы инициализации в состояние инициализации портала, в котором создаются параметры по умолчанию портальной системы и обновляется ключ, перехода в состояние обновления портальной системы в ответ на переменную ChangePortal или ChangeDRFPorts, соответствующую булеву значению “истинно”, установки в состоянии обновления портальной системы переменной ChangePortal в “ложно”, переменной changeDRFPorts в “ложно”, выполнения updateDRFHomeState, и обновления ключа, и повторного входа в состояние обновления портальной системы при обнаружении, что переменная ChangePortal или ChangeDRFPorts соответствует “истинно”.

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

[00890] Любое локальное изменение в операционном состоянии шлюза портальной системы на состояние распределения любого из присоединенных портов, как сообщено ассоциированным агрегатором, или любое изменение в операционном состоянии соседних портальных систем, как сообщено конечным автоматом RX, запускает переход в состояние PORTAL_SYSTEM_UPDATE. Это заставляет функцию updateDRFHomeState переоценивать переменную, обеспечивающую собственное состояние портальной системы (DRF_Home_State) на основе обновленной локальной информации об операционном состоянии шлюза и всех портов агрегирования на агрегаторе портальной системы. Любое изменение в операционном состоянии шлюза портальной системы отражается на функции GatewayConversationUpdate, которая используется для запуска переходов состояний в конечных автоматах портов и IPP. Точно так же, любое изменение в операционном состоянии портов агрегирования, ассоциированных с портом агрегатора этой портальной системы, отражается на функции PortConversationUpdate, которая используется для запуска переходов состояний в тех же конечных автоматах. Наконец, функция updateKey обновляет операционный ключ, который должен использоваться агрегатором портальной системы, путем выбора наименьшего числового ненулевого значения из набора, содержащего значения административных ключей всех активных портальных систем в портале.

[00891] Конечный автомат возвращается в состояние PORTAL_SYSTEM_UPDATE всякий раз, когда рабочее состояние любого порта функции DR изменяется.

[00892] Автомат портальной системы может также реализовывать функцию, определенную на фиг. 18, с ее ассоциированными параметрами. Фиг. 18 аналогична фиг. 10 за исключением того, что система выполняет обновление состояния портала, используя функцию UpdatePortalState на фиг. 18. Термины и функции альтернативного автомата портальной системы на фиг. 18 аналогичны таковым на фиг. 10. Специалисту в данной области техники будет понятно, что другие реализации возможны в соответствии с принципами и структурами, показанных автоматов портальной системы.

[00893] Фиг. 34 иллюстрирует способ обновления операционных состояний узла в распределенном отказоустойчивом сетевом межсоединении (DRNI) в соответствии с вариантом осуществления изобретения. Способ 3400 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С. Отметим, что опциональные этапы обозначаются как пунктирные блоки, как показано на фиг. 34.

[00894] На этапе 3402 узел инициализирует агрегирование каналов. Инициализация включает в себя установку переменных узла для портала, которому он принадлежит, как сконфигурировано административными настройками. Инициализация выполняется путем выполнения функции (например, setDefaultPortalSystemParameters на фиг. 10) в одном варианте осуществления. Функция устанавливает переменную узла на административно установленные значения, как перечислено в определении setDefaultPortalSystemParameters, описанном здесь выше, что включает в себя системный приоритет агрегатора узла (например, Drni_Aggregator_Priority), системный идентификатор агрегатора узла (например, Drni_Aggregator_ID), системный приоритет портала (например, Drni_Portal_Priority), идентификатор для узла в портале (например, DRF_Portal_System_Number), значение административного ключа агрегатора, ассоциированное с агрегатором (например, DRF_Home_Admin_Aggregator_Key), алгоритм порта, используемый функцией DR узла, чтобы соотносить кадры с ID диалогов портов (например, DRF_Home_Port_Algorithm), алгоритм шлюза, используемый функцией DR узла, чтобы соотносить кадры с ID диалогов шлюзов (например, DRF_Home_Gateway_Algorithm), и т.д.

[00895] На этапе 3404 узел определяет, что операционное состояние, ассоциированное с порталом, изменилось. Изменение операционного состояния может быть указано булевой переменной, которая устанавливается в TRUE, когда операционное значение представления сетевого устройства о значении активности IPP соседнего сетевого устройства является активным. В одном варианте осуществления переменная, такая как ChangePortal, описанная выше, является такой булевой переменной. Изменение операционного состояния может быть также указано булевой переменной, которая устанавливается на “истинно”, когда операционное состояние шлюза узла изменяется. Изменение операционного состояния может быть также указано булевой переменной, которая устанавливается на “истинно”, когда одно из операционных состояний портов агрегирования узла, ассоциированного с первым порталом, изменяется. В одном варианте осуществления переменная, такая как ChangeDRFPorts, описанная здесь выше, является такой булевой переменной для изменений операционных состояний как шлюза, так и портов агрегирования.

[00896] На этапе 3406 узел может установить одну или несколько переменных, указывающих отсутствие изменения операционного состояния, ассоциированного с порталом. В одном варианте осуществления это выполняется путем установки переменных, таких как ChangePortal и ChangeDRFPorts в FALSE, как показано на фиг. 10. Эта установка допускает дальнейшие изменения триггеров обновления операционного состояния ChangePortal и ChangeDRFPorts таким образом, что узел может обнаружить изменение.

[00897] На этапе 3408 узел обновляет набор операционных состояний узла для агрегирования каналов в ответ на изменение операционного состояния, где набор операционных состояний включает в себя операционное состояние шлюза для узла. В одном варианте осуществления обновление выполняется через выполнение функции, такой как updateDRFHomeState, описанной здесь выше. В одном варианте осуществления обновление также создает список операционных портов агрегирования путем включения только тех идентификаторов (ID) портов агрегирования, которые являются действующими (например, присоединенный агрегатор сообщает их как имеющих Actor_Oper_Port_State.Distributing == TRUE (условие, которое исключает случаи, когда ассоциированные порты агрегирования либо не действующие, либо в состоянии недействительности по истечении времени, либо не в группе агрегирования каналов)).

[00898] Способ обеспечивает эффективный способ синхронизации операционных состояний узла DRCP с соседним узлом DRCP на основе изменений портала, к которому принадлежит узел DRCP.

[00899] Автомат шлюза и агрегатора DRNI

[00900] Автомат шлюза и агрегатора DRNI может реализовать функцию, определенную на фиг. 11, с ее ассоциированными параметрами, описанными здесь выше. Имеется два автомата шлюза и агрегатора DRNI на портальной системе. Каждый ассоциирован с типом ID диалога: один для ID диалога шлюза и один для ID диалога порта. Фиг. 11А является процессом шлюза DRNI, который инициализируется в состояние инициализации шлюза DRNI (блок 1102). В этом состоянии выполняется функция InitializeDRNIGatewayConversation, и GatewayCoversationUpdate установлена в FALSE, и если происходит GatewayCoversationUpdate, процесс переходит в состояние обновления шлюза DRNI (блок 1104). В состоянии обновления шлюза DRNI (блок 1104) процесс устанавливает GatewayConversationUpdate в “ложно”, updatePortaState и операция setGatewayConversaion и setlPPGatewayUpdate выполняются, и выполняется updatePortalSystemGatewayConversaion. Обновление шлюза DRNI запускается при каждом появлении GatewayConversation Update.

[00901] Варианты осуществления процесса содержат этапы инициализации в состояние инициализации шлюза DRNI, инициализации диалога шлюза и обновления диалога шлюза в “ложно”, перехода в состояние обновления шлюза DRNI при обнаружении, что переменная обновления диалога шлюза соответствует “истинно”, установки updatePortalState, установки триггеров обновления шлюза IPP, установки переменной обновления диалог шлюза в “ложно”, установки диалога шлюза, обновления диалога шлюза портальной системы и повторного входа в состояние обновления шлюза DRNI после того, как переменная обновления диалога шлюза устанавливается в “истинно”.

[00902] На фиг. 11В показан процесс обновления порта DRNI. В этом процессе процесс обновления порта DRNI начинается в состоянии инициализации порта DRNI (блок 1112). Функция initializeDRNIPortConversation выполняется, и PortCoversationUpdate устанавливается в “ложно”, и процесс продолжается в ответ на возникновение PortConversationUpdate, который переводит состояние в DRNIPortUpdate (блок 1114). В состоянии обновления порта DRNI, процесс устанавливает PortConversationUpdate в “ложно”, операции updatePortalState, setPortConversation, setIPPPortUpdate и операция updatePortalSystemPortConversation выполняются. Обновление порта DRNI перезапускается, когда происходит изменение на значение PortConversationUpdate.

[00903] Варианты осуществления процесса содержат этапы инициализации в состояние инициализации порта DRNI, инициализации диалога порта DRNI и PortCoversationUpdate в “ложно”, перехода в состояние обновления порта DRNI при обнаружении, что переменная обновления диалога порта соответствует “истинно”, установки триггеров обновления порта IPP, установки диалога порта, обновления диалога порта портальной системы и повторного входа в состояние обновления порта DRNI в ответ на обнаружение, что переменная обновления диалога порта соответствует “истинно”.

[00904] Эти конечные автоматы отвечают за конфигурирование ID диалогов шлюзов и ID диалогов портов, которым разрешено проходить через данный шлюз функции DR и агрегатор на основе согласованных правил приоритета и операции DRCP.

[00905] В ответ на триггер от конечного автомата PS (фиг. 10) или конечного автомата DRX (фиг. 8), декларирующих, что операционное состояние шлюза изменилось, конечный автомат переходит в состояние DRNI_GATEWAY_UPDATE. Это вызывает сброс параметров запуска (GatewayConversationUpdate) в “ложно”. Тогда функция updatePortalState будет обновлять переменную, обеспечивающую состояния всех портальных систем (Drni_Portal_System_State[]) путем комбинирования обновленного DRF_Home_State с информацией из операционного состояния портов на других портальных системах, как сообщено принятыми DRCPDU по IPP портальной системы и записано конечным автоматом DRX (фиг. 8), и устанавливает IppGatewayUpdate на каждом IPP на портальной системе в “истинно”, чтобы запустить дальнейшие обновления на конечных автоматах IPP (фиг. 12). Затем вызывается функция setGatewayConversation для идентификации портальной системы, которая отвечает за каждый ID диалога шлюза на основе согласованных приоритетов выбора и операционного состояния шлюзов, как известно этой портальной системе (на основе локального операционного состояния шлюза и декларированного соседними портальными системами операционного состояния их собственных шлюзов, переносимого последними DRCPDU, принятыми от этих соседних портальных систем). Наконец, индексированный посредством ID диалога шлюза булев вектор будет вычисляться на основе соглашения между представлением портальной системы относительно ID диалогов шлюза, которым разрешено проходить через шлюз портальной системы, и представлением всех соседей относительно ID диалогов шлюза, которым разрешено проходить через шлюз этой портальной системы [как декларировано посредством их DRCPDU и записано посредством конечного автомата DRX этой портальной системы (фиг. 8)]. Это гарантирует, что никакому ID диалога шлюза не разрешено проходить через шлюз этой портальной системы, если только соглашение между всеми портальными системами не будет достигнуто.

[00906] Конечный автомат инициализируется, когда все ID диалогов шлюзов отброшены, и переходит в состояние DRNI_GATEWAY_UPDATE всякий раз, когда устанавливается триггер GatewayConversationUpdate.

[00907] Индексированный посредством ID диалога порта булев вектор устанавливается посредством подобной операции конечного автомата, причем разница состоит только в том, что правила выбора приоритета основаны на согласованных ID диалогов портов и алгоритме портов вместо согласованных ID диалогов шлюзов и алгоритма шлюза.

[00908] Фиг. 35 иллюстрирует способ конфигурирования набора ID диалогов для агрегатора или шлюза на сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) в соответствии с вариантом осуществления изобретения. Способ 3500 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным портом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С. Отметим, что опциональные этапы обозначены как пунктирные блоки на фиг. 35.

[00909] На этапе 3502 узел инициализирует набор ID диалогов, и инициализация включает в себя установку записей булева вектора, ассоциированного с набором ID диалогов, как последовательности нулей. ID диалогов представляют собой ID диалогов шлюзов или ID диалогов портов. Булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством шлюза или агрегатора узла, который устанавливается в нули (без обработки) посредством инициализации. Отметим, что узел DRCP содержит один шлюз и один агрегатор.

[00910] Инициализация может быть выполнена с помощью функции, такой как InitializeDRNIGatewayConversation и InitializeDRNIPortConversation, описанные здесь выше. Булев вектор может быть Drni_Portal_System_Gateway_Conversation или Drni_Portal_System_Port_Conversation для ID диалогов шлюза и ID диалогов порта, соответственно. В одном варианте осуществления ID диалога является булевым значением записи (например, “истинно” означает передачу через шлюз или распределение через агрегатор). Инициализация устанавливает все значения в нули, таким образом, они не проходят.

[00911] На этапе 3504 узел определяет, что распределение набора ID диалогов нуждается в обновлении. В одном варианте осуществления, выполнение определения включает в себя проверку булевой переменной (например, переменных GatewayConversationUpdate и PortConversationUpdate, описанных здесь выше, для ID диалогов шлюза и ID диалогов порта, соответственно).

[00912] На этапе 3506 узел устанавливает значения операционного вектора, индексированного посредством ID диалогов, где операционный вектор перечисляет, какой узел портала обрабатывает каждый из набора ID диалогов. В одном варианте осуществления операционный вектор является Drni_Gateway_Converstaion и Drni_Port_Conversation для ID диалогов шлюза и ID диалогов порта, соответственно. Для ID диалогов шлюза, операционный вектор перечисляет, какой узел портала пропускает каждый ID диалогов шлюза. Для ID диалогов порта, операционный вектор перечисляет, какой узел портала пропускает каждый ID диалогов порта.

[00913] На этапе 3508 узел устанавливает значения булева вектора, индексированного посредством ID диалогов, где булев вектор перечисляет, является ли один шлюз или один агрегатор сетевого устройства ассоциированным с каждым из ID диалогов. Операционный булев вектор может быть Drni_Portal_System_Gateway_Conversation или Drni_Portal_System_Port_Conversation для ID диалогов шлюза и ID диалогов порта, соответственно. Для ID диалогов шлюза, каждая запись в булевом векторе указывает, разрешено ли ID диалога шлюза проходить через один шлюз узла. Для ID диалогов порта, каждая запись в булевом векторе указывает, разрешено ли ID диалога порта распределяться через один агрегатор узла.

[00914] Затем опционально на этапе 3510 узел обновляет операционные состояния всех узлов портала. В одном варианте осуществления обновление выполняется с помощью функции, такой как updatePortalState, описанной здесь выше.

[00915] Также опционально, на этапе 3512 узел устанавливает переменную, указывающую, что распределение набора ID диалогов должно быть обновлено. В одном варианте осуществления переменной является setIPPGatewayUpdate и setIPPPortUpdate (описано здесь выше) для ID диалогов шлюза и ID диалогов порта, соответственно.

[00916] Таким образом, варианты осуществления изобретения обеспечивают эффективные способы, чтобы конфигурировать ID диалогов, так что ассоциированные диалоги могут передаваться должным образом в группе агрегирования каналов, содержащей DRNI.

[00917] Автомат IPP DRNI

[00918] Автомат IPP DRNI может осуществлять функцию, определенную на фиг. 12А-В, с ее ассоциированными параметрами, описанными здесь выше. Фиг. 12А иллюстрирует конечный автомат для обновления диалога шлюза IPP в соответствии с одним вариантом осуществления изобретения. Процесс начинается в блоке 1202, где шлюз IPP инициализируется. В этом варианте осуществления инициализация шлюза IPP достигается за счет двух функций инициализации. Посредством IPPGatewayUpdate = FALSE, сетевое устройство устанавливает триггеры обновления шлюзов IPP в “ложно”. Посредством функции InitializeIPPPortConversation(), сетевое устройство устанавливает прохождения диалогов (например, Ipp_Gateway_Conversation_Direction) в последовательность нулей, вновь индексированную ID диалогом шлюза.

[00919] После инициализации конечный автомат переходит в блок 1204, где шлюз IPP обновляется. Передача запускается посредством изменения переменной. Переменная, IppGatewayUpdate, показывает, что распределения ID диалогов шлюзов IPP должны быть обновлены. В одном варианте осуществления IppGatewayUpdate является булевым значением, и как только булево значение переходит в “истинно”, конечный автомат переходит в блок 1204. В блоке 1204 он устанавливает диалог шлюза посредством функции setGatewayConversation. Как описано здесь выше, функция устанавливает значение диалога шлюза DRNI на значения, вычисленные из текущего административного значения списка приоритета выбора шлюза для распределенной ретрансляции (посредством переменной, такой как aDrniConvAdminGateway[]) и текущего состояния системы порта DRNI (путем считывания Drni_Portal_System_State[] в одном варианте осуществления). Кроме того, в блоке 1204, сетевое устройство устанавливает диалог шлюза IPP посредством функции setIPPGatewayConversation(). Кроме того, сетевое устройство обновляет направление диалога шлюза IPP посредством функции updateIPPGatewayConversationDirection(), и, наконец, сетевое устройство сбрасывает IppGatewayUpdate в “ложно”. Блок 1204 повторяется всякий раз, когда необходимо обновление диалога шлюза.

[00920] Таким образом, варианты осуществления процесса содержат этапы инициализации состояния инициализации шлюза IPP, инициализации триггера обновления шлюза IPP в “ложно”, инициализации диалога шлюза IPP, перехода в состояние обновления шлюза IPP при обнаружении, что переменная обновления шлюза IPP соответствует “истинно”, установки диалога шлюза, установки диалога шлюза IPP, обновления направления диалога шлюза IPP, установки переменной обновления шлюза IPP в “ложно” и повторного входа в состояние обновления шлюза IPP в ответ на обнаружение, что переменная обновления диалога шлюза соответствует “истинно”.

[00921] На фиг. 12В показан конечный автомат для обновления диалога порта IPP в соответствии с одним вариантом осуществления изобретения. Процесс обновления порта IPP аналогичен процессу обновления диалога шлюза, поэтому процесс на фиг. 12В аналогичен 12А с функциями и переменными для портов IPP, используемыми для обновления диалога порта IPP.

[00922] Варианты осуществления этого процесса включают в себя этапы инициализации в состояние инициализации порта IPP, инициализации триггера обновления порта IPP в “ложно”, инициализации диалога порта IPP, перехода в состояние обновления порта IPP в ответ на обнаружение, что переменная обновления порта IPP соответствует “истинно”, установки диалога порта, установки диалога IPP, обновления прохода диалога порта IPP, устанавливающего переменную IppPortUpdate в “ложно”, и повторного входа в состояние обновления порта IPP в ответ на обнаружение, что PortConversationUpdate соответствует “истинно”.

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

[00924] В ответ на триггер из конечного автомата DRX (фиг. 8), декларирующий, что IppGatewayUpdate установлен в “истинно”, конечный автомат переходит в состояние IPP_GATEWAY_UPDATE. Это приводит к вызову функции setGatewayConversation. Это будет идентифицировать портальную систему, которая отвечает за каждый ID диалога шлюза, на основе согласованных приоритетов выбора и операционного состояния шлюзов, как известно этой портальной системе (на основе операционного состояния локального шлюза и декларированного соседями операционного состояние их собственных шлюзов, переносимого последним DRCPDU, принятым от этих соседей). Затем функция setIPPGatewayConversation будет идентифицировать портальную систему, которая отвечает за каждый ID диалога шлюза на основе согласованных приоритетов выбора и операционных состояний шлюзов, как декларировано соседней портальной системой на этом IPP (на основе операционного состояния шлюза соседней портальной системы и декларированного операционного состояния соседней портальной системы относительно их представления о других шлюзах в портале, переносимого последним DRCPDU, принятым от соседней портальной системы на этом IPP). Затем, индексированный посредством ID диалога шлюза булев вектор будет вычисляться на основе соглашения между представлением этой портальной системы относительно ID диалогов шлюзов, которым разрешено проходить через IPP, и представлением соседней портальной системы IPP относительно ID диалогов шлюзов, которым разрешено проходить через тот же IPP [как декларируется посредством их DRCPDU и записано конечным автоматом DRX этой портальной системы (фиг. 8)]. Это гарантирует, что никакому ID диалог шлюза не разрешено проходить через этот IPP, если только соглашение между этой портальной системой и ее соседней портальной системой не будет достигнуто. Наконец, IppGatewayUpdate сбрасывается “ложно”.

[00925] Конечный автомат инициализируется, отбрасывая все ID диалога шлюза, и переходит в состояние IPP_GATEWAY_UPDATE всякий раз, когда устанавливается триггер GatewayConversationUpdate.

[00926] Индексированный посредством ID диалога порта булев вектор устанавливается посредством сходной операции конечного автомата, разница лишь в том, что правила выбора приоритета основаны на согласованных ID диалога порта и алгоритме порта, вместо согласованных ID диалога шлюза и алгоритма шлюз.

[00927] Фиг. 36 иллюстрирует способ конфигурирования набора ID диалогов для IPP на узле DRCP в распределенном отказоустойчивом сетевом межсоединении (DRNI) в соответствии с вариантом осуществления изобретения. Способ 3600 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С.

[00928] На этапе 3602 узел инициализирует набор ID диалогов, и инициализация включает в себя установку записей булева вектора, ассоциированного с набором ID диалогов, как последовательности нулей. ID диалогов являются ID диалогов шлюзов или ID диалогов портов. Булев вектор включает в себя значения, указывающие обработку набора ID диалогов через IPP узла.

[00929] Инициализация может быть выполнена функцией, такой как InitializelPPGatewayConversation и InitializelPPPortConversation, описанные здесь выше. Булев вектор может быть Ipp_Gateway_Conversation_Direction или Ipp_Port_Conversation_Passes для ID диалогов шлюзов и ID диалогов портов, соответственно. В одном варианте осуществления значение для ID диалога является булевым значением записи. Например, значение TRUE, для ID диалога шлюза указывает, что некоторый шлюз доступен через этот IPP. Инициализация устанавливает все значения в нули, то есть, нет прохода.

[00930] На этапе 3604 узел определяет, что распределение набора ID диалогов нуждается в обновлении. В одном варианте осуществления выполнение определения включает проверку булевой переменной. В одном варианте осуществления булева переменная является IppGatewayUpdate и IppPortUpdate для ID диалогов шлюзов и ID диалогов портов, соответственно. В другом варианте осуществления булевы переменные являются GatewayConversationUpdate и PortConversationUpdate для ID диалогов шлюзов и ID диалогов портов, соответственно.

[00931] На этапе 3606 узел устанавливает значения первого операционного вектора, индексированного посредством ID диалогов, где операционный вектор перечисляет, какой узел портала обрабатывает каждый из ID диалогов, как назначено узлом. В одном варианте осуществления узел устанавливает значения с помощью функций, таких как setGatewayConversation и setPortConversation, чтобы установить первый операционный вектор, такой как Drni_Gateway_Conversation и Drni_Port_Conversation, соответственно. Для ID диалогов шлюзов, Drni_Gateway_Conversation перечисляет, какой шлюз узла (если таковой имеется) пропускает каждый ID диалог шлюза ID. Для ID диалогов портов, Drni_Port_Conversation перечисляет, какой узел пропускает каждый из ID диалогов портов.

[00932] На этапе 3608 узел устанавливает значения второго операционного вектора, индексированного посредством ID диалогов, где операционный вектор перечисляет, какой узел портала обрабатывает каждый из ID диалогов, как назначено соседним узлом. В одном варианте осуществления узел устанавливает значения с помощью функций, таких как setIPPGatewayConversation и setIPPPortConversation, для установки второго операционного вектора, такого как Ipp_Other_Gateway_Conversation и Ipp_Other_Port_Conversation_Portal_System, соответственно. Как обсуждалось здесь выше, для ID диалогов шлюзов, Ipp_Other_Gateway_Conversation перечисляет, какой узел (то есть, портальная система) (если таковые имеются) пропускает каждый ID диалога шлюза, как назначено соседним узлом на этом IPP, причем соседний узел является непосредственно соседним узлом, когда портал содержит более двух узлов. Аналогично, для ID диалогов портов. Ipp_Other_Port_Conversation_Portal_System перечисляет, какой узел пропускает каждый ID диалога порта, назначенный непосредственно соседним узлом на этом IPP.

[00933] На этапе 3610 узел устанавливает значения булева вектора, индексированного посредством ID диалогов, где булев вектор перечисляет, является ли IPP узла ассоциированным с каждым из ID диалогов. В одном варианте осуществления булев вектор является Ipp_Gateway_Conversation_Direction для ID диалогов шлюзов и Ipp_Port_Conversation_Passes для ID диалогов портов, как описано здесь выше.

[00934] Таким образом, аналогично способу 3500, варианты осуществления настоящего изобретения здесь обеспечивают эффективные способы конфигурирования ID диалогов так, что ассоциированные диалоги могут быть переданы надлежащим образом в группе агрегирования каналов, содержащей DRNI.

[00935] Автомат передачи

[00936] Когда автомат передачи (не показан) создает DRCPDU для передачи, он может заполнить следующие поля соответствующими операционными значениями для этого IPP согласно одному варианту осуществления изобретения:

[00937] ID и приоритет агрегатора

- ID и приоритет портала

- Номер портальной системы

- Состояние топологии

- Операционный ключ агрегатора

- Алгоритм порта

- Алгоритм шлюза

- Дайджест порта

- Дайджест шлюза

- Состояние DRCP

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

[00938] Когда автомат периодической передачи находится в состоянии NO_PERIODIC, автомат передачи должен:

- Не передавать никакие DRCPDU и

- Установить значение NTTDRCPDU в FALSE.

[00939] Когда переменная DRCP_Enabled соответствует TRUE, и переменная NTTDRCPDU соответствует TRUE, автомат передачи может гарантировать, что правильно отформатированный DRCPDU передается [т.е. выдача примитива услуги DRCPCtrlMuxN:M_UNITDATA.Request (DRCPDU)], в соответствии с тем ограничением, что не более, чем определенное количество LACPDU может быть передано в любом интервале Fast_Periodic_Time. Конкретное количество может варьироваться в зависимости от реализации (например, десять или двадцать). Если NTTDRCPDU установлен в TRUE, когда этот предел имеет силу, передача может быть задержана до того времени, когда ограничение больше не будет в силе. Переменная NTTDRCPDU может быть установлена в FALSE, когда автомат передачи передал DRCPDU.

[00940] Если передача DRCPDU задерживается в связи с вышеуказанным ограничением, информация, передаваемая в DRCPDU, соответствует операционным значениям для IPP на момент передачи, а не во время, когда NTTDRCPDU был впервые установлен в TRUE. Другими словами, модель передачи DRCPDU основана на передаче информации о состоянии, которая является текущей во время возникновения возможности передачи, в противоположность постановке сообщений в очередь для передачи.

[00941] Когда DRCP_Enabledvariable ложно, автомат передачи не может передавать никакой DRCPDU и может установить значение NTTDRCPDU в FALSE.

[00942] Автомат совместного использования сети/IPL

[00943] Автомат совместного использования сети/IPL может осуществлять функции, определенные на фиг. 30, с их ассоциированными параметрами. Имеется один автомат совместного использования сети/IPL на каждый IPP в портальной системе для поддерживаемого способа совместного использования сети/IPL. Этот автомат требуется только тогда, когда реализованы способы совместного использования сети/IPL: совместное во времени использование сети/IPL, совместное использование сети/IPL посредством метки или совместное использование сети/IPL посредством инкапсуляции.

[00944] Автомат совместного использования сети/IPL, который соответствует способу 3100 на фиг.31, описанному здесь ниже, обеспечивает передачу и обработку кадров, передаваемых по совместно используемому каналу сети/IPL, только если DRCPDU, принятые по тому же порту, сообщают ту же самую конфигурацию совместного использования сети/IPL соседней портальной системой, результатом чего является множество IPL и сетевого канала, совместно использующих тот же самый физический канал или агрегирование каналов.

[00945] Конечный автомат имеет три состояния. Они являются следующими:

[00946] NO_MANIPULATED_FRAMES_SENT. В этом состоянии, IPL может поддерживаться только с помощью физического канала или канала агрегирования.

[00947] TIME_SHARED_METHOD. В этом состоянии, разрешены способы совместного во времени использования сети/IPL, описанные здесь выше.

[00948] MANIPULATED_FRAMES_SENT. В этом состоянии, разрешены способы манипулирования метками совместного использования сети/IPL посредством меток или совместного использования сети/IPL посредством инкапсуляции, как диктуется способом совместного использования сети/IPL, выбранным в aDrniEncapsulationMethod.

[00949] Система инициализируется в NO_MANIPULATED_FRAMES_SENT, и IPL кадры посылаются по выделенному физическому каналу. Если домашняя портальная система сконфигурирована для режима операции совместного во времени использования сети/IPL, указанного значением 1 в aDrniEncapsulationMethod, система будет переходить в TIME_SHARED_METHOD, если конечный автомат DRX (DRX - фиг. 8) устанавливает CC_Time_Shared в TRUE (указывая, что соседняя портальная система на этом IPP также была сконфигурирована для режима операции совместного во времени использования сети/IPL). Система остается в состоянии TIME_SHARED_METHOD до тех пор, пока принятый DRCPDU не установит CC_Time_Shared в FALSE, что запускает переход состояния в состояние NO_MANIPULATED_FRAMES_SENT, и кадры IPL посылаются по выделенному физическому каналу.

[00950] Точно так же, если домашняя портальная система сконфигурирована для режима операции совместного использования сети/IPL посредством метки или совместного использования Сети/IPL посредством инкапсуляции, как указано значением в aDrniEncapsulationMethod, система будет переходить в MANIPULATED_FRAMES_SENT, если конечный автомат DRX (DRX - фиг. 8) устанавливает CC_EncTag_Shared в TRUE (указывая, что соседняя портальная система на этом IPP также сконфигурирована для совместного использования сети/IPL посредством метки или совместного использования сети/IPL посредством инкапсуляции, соответственно). Система остается в состоянии MANIPULATED_FRAMES_SENT до тех пор, пока принятый DRCPDU не установит CC_EncTag_Shared в FALSE, что запускает переход состояния в состояние NO_MANIPULATED_FRAMES_SENT, и кадры IPL посылаются по выделенном физическому каналу.

[00951] Фиг. 31 иллюстрирует способ совместного использования сети/IPL в узле в соответствии с вариантом осуществления изобретения. Способ 3100 может быть реализован на узле DRCP (также называемом портальной системой портала, например, сетевого устройства) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С. Отметим, что опциональный этап обозначен как пунктирный блок, как показано на фиг. 31.

[00952] На этапе 3102 узел DRCP (локальная портальная система) находится в нормальном состоянии работы, и IPL кадры передаются по выделенному физическому каналу или каналу в направлении соседнего узла DRCP (соседней портальной системы). На этапе 3104 определяется, является ли узел сконфигурированным в соответствии с соседним узлом. Например, это может быть выполнено с использованием функции записи параметров, такой как recordNeighborState, которая по меньшей мере записывает значение параметра, переносимого в TLV, используемом для совместного использования сети/IPL, от соседнего узла, например, поле DRF_Home_Network/IPL_sharing_method в таблице 6. Записанное значение параметра может затем сравниваться с текущим значением соответствующего параметра, используемого узлом. В случае если совместное использование сети/IPL реализовано в узле, и в случае если значения параметров согласованным образом сконфигурированы в узлах, способ переходит к этапу 3106, в котором кадры передаются от узла к соседнему узлу посредством совместного использования сети/IPL.

[00953] Опционально, узел продолжает использовать согласованный способ совместного использования сети/IPL до тех пор, пока он не обнаружит изменение совместного использования сети/IPL в соседнем узле на этапе 3108. Например, CC_Time_Shared или CC_Enctag_Shared указывает, используют ли домашний/соседний узлы согласованные способы совместного использования. Когда два узла не используют согласованный способ совместного использования, поток возвращается на этап 3102, где используется выделенный канал или канал агрегирования.

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

[00955] Координация между состояниями DRCP и LACP: первый набор вариантов осуществления

[00956] В портальной системе DRNI, как показано на фиг. 1B-1C, состояние DRCP и LACP должны быть согласованы, чтобы система работала надлежащим образом. На фиг. 1С, согласованность легче поддерживать. Как показано на 1С, каналом между сетевым устройством 130 и сетевым устройством 134 является рабочий канал (канал 172) и каналом между сетевым устройством 130 и сетевым устройством 132 является канал защиты (канал 174) для услуги. Канал IPL (не показано) между сетевыми устройствами 134 и 132 поддерживает их состояние DRCP в синхронизации. С точки зрения сетевого устройства 130 (портала 142 с одним узлом), он соединен с единой системой (порталом 144), и никакая информация относительно сетевых устройств 132 или 134 по отдельности явно не сообщается сетевому устройству 130.

[00957] Когда канал IPL между сетевыми устройствами 132 и 134 становится нерабочим, сетевые устройства 134 (текущий рабочий узел) и 132 (текущий узел защиты) пытаются взять на себя функцию узла, передающего трафик - с их соответствующей точки зрения, соседний узел не работает должным образом. Сетевое устройство 132, в качестве узла защиты, будет обновлять свой идентификатор (ID) LAG для того, чтобы избежать ситуации, когда оба канала 130-132 и 130-134 (каналы 172 и 174 соответственно) выполняют дублирование трафика. В портале 142, определение того, какой канал должен остаться в группе агрегирования каналов (то есть, рабочий канал), основано на принятии решения сетевым устройством 130, которое применяет нормальные операции агрегирования каналов, чтобы сделать выбор. В частности, сетевое устройство 130 устанавливает канал 130-132 на удержание, чтобы проверить, находится ли канал 130-134 все еще в группе агрегирования каналов (т.е. рабочий канал, несущий трафик). Если канал 130-134 не находится в группе агрегирования каналов, он разрешает трафик по каналу 130-132. Когда канал IPL между сетевыми устройствами 134 и 132 снова действует, состояние DRCP обновляется, и канал 130-132 остается блокированным, и состояние LACP поддерживает канал 130-134 в качестве рабочего канала на протяжении всего процесса (таким образом, нет отключения трафика).

[00958] Для системы DRCP с каждым порталом, содержащим более одного сетевого устройства, поддержание согласованности между состоянием DRCP и LACP требует больше усилий. Дополнительная информация должна обмениваться между порталами и узлами, чтобы поддерживать порталы синхронизированными. В частности, по меньшей мере два операционных ключа (по одному для каждой действующей портальной системы партнера) могут быть введены, чтобы координировать синхронизацию. Одним из них является операционный ключ агрегатора партнера. Операционный ключ агрегатора партнера ассоциирован с идентификатором группы агрегирования канала агрегирования (LAG ID) (узел является узлом партнера). Операционный ключ агрегатора партнера передается в DRCPDU. В одном варианте осуществления операционный ключ агрегатора партнера сохраняется в переменной DRF_Home_Oper_Partner_Aggregator_Key, которая определяется в качестве операционного ключа агрегатора партнера, ассоциированного с LAG ID сетевого устройства (узла портала), описанного здесь выше. Другим является операционный ключ для каждой из партнерских портальных систем в партнерском портале. Операционный ключ портала соседа также ассоциирован с LAG ID узла (узла, являющегося соседним узлом). Операционные ключи порталов соседей (непосредственных или удаленных соседей) передаются в DRCPDU. В одном варианте осуществления операционный ключ агрегатора соседа сохранен в переменной DRF_Neigbhor_Oper_Partner_Aggregator_Key

(DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key в случае третьей портальной системы), которая определяется как значение последнего принятого операционного ключа агрегатора партнера соседнего узла (или другого соседа в случае третьей портальной системы) на его ассоциированном внутри-портальном порту (IPP).

[00959] Для обмена ключами агрегатора, DRCPDU может добавить новое поле для хранения операционного ключа партнера, такое поле можно использовать для переноса DRF_Home_Oper_Partner_Aggregator_Key одного узла в DRCPDU. Функция записи сконфигурированного значения параметра соседнего узла, переносимого в принятом DRCPDU из IPP, может быть также обновлена. Такая функция, например, как описано здесь выше recordNeighborState, может быть использована для установки принятого операционного ключа агрегатора партнера на последний известный операционный ключ агрегатора соседа (например, установка DRF_Neigbhor_Oper_Partner_Aggregator_Key равна принятому DRF_Home_Oper_Partner_Aggregator_Key). Отметим, что когда портал содержит более двух узлов, есть несколько сохраненных DRF_Neigbhor_Oper_Partner_Aggregator_Key или, возможно, DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key, по одному для каждого соседнего узла.

[00960] Со ссылкой на фиг. 1B, канал К-М является рабочим каналом, и канал L-О является каналом защиты. Каждый канал IPL существует между узлами К и L, M и O, чтобы сохранять свое состояние DRCP синхронизированным.

[00961] Когда канал IPL между сетевыми узлами M и O выходит из строя, оба узла М (текущий рабочий узел) и О (текущий узел защиты) для услуги пытаются взять на себя функцию узла, передающего трафик - с их соответствующей точки зрения, именно соседний узел не работает. Узел О, в качестве узла защиты, будет обновлять свой идентификатор (ID) LAG, чтобы избежать ситуации, когда оба канала K-M и L-O переносят дублирующий трафик. В портале 112, узлы K и L должны независимо принимать решения о том, отбросить или разрешить трафик по каналам К-М и L-O. Решение может приниматься путем обмена DRCPDU между соседними узлами в одном варианте осуществления. Кроме того, логика выбора, применяемая каждым узлом, может быть модифицирована, чтобы принимать о внимание передаваемую информацию. Узлы К и L могут быть обновлены, чтобы позволить трафику проходить через ассоциированные каналы K-M и L-О, соответственно, только когда его операционный ключ агрегатора партнера является наименьшим значением из набора значений, включая его операционный ключ агрегатора партнера и операционный(е) ключ(и) портала партнера. Для выбора, чтобы работать, узел О как узел защиты может обновить свое значение операционного ключа (в одном варианте осуществления значение операционного ключа обновляется с использованием функции обновления, такой как функция updateKey, описанная выше), когда он обновляет свой LAG ID.

[00962] Фиг. 19 иллюстрирует операцию узла DRCP после потери связи с его соседним узлом в соответствии с одним вариантом осуществления изобретения. Способ может быть реализован в любом узле DRCP, связанном с одним или несколькими соседними узлами. На этапе 1902 узел DRCP определяет, что он больше не осуществляет связь с его соседним(и) узлом(ами). Потеря связи может быть обусловлена отключением или неисправностью IPP или отключением или неисправностью соседнего узла. На этапе 1904 узел DRCP затем определяет, что он является узлом, в данный момент не осуществляющим передачу трафика. Отметим, что узел DRCP может действовать в качестве рабочего узла или узла защиты портала для услуги. Если узел DRCP является рабочим узлом, никакого дальнейшего действия не требуется, он будет продолжать переносить активный трафик. Если DRCP узел является узлом защиты, способ продолжается на этапе 1906, где узел DRCP обновляет свой операционный ключ и переносит активный трафик. Обновленный операционный ключ устанавливается на самое низкое числовое ненулевое значение набора, содержащего значения ключа этого узла (например, Admin_Aggregator_Key данного узла), ключа соседнего узла (например, Admin_Aggregator_Key соседнего узла) и ключа другого соседнего узла (например, Admin_Aggregator_Key другого соседнего узла) (когда портал содержит 3 портальных системы), на каждом IPP. Обновленный операционный ключ посылается к партнерскому узлу.

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

[00964] Фиг. 20 иллюстрирует операцию узла DRCP в координации с его соседним узлом после приема множества потоков трафика в соответствии с одним вариантом осуществления изобретения. Способ может быть реализован в любом узле DRCP связанном с одним или несколькими соседними узлами. На этапе 2002 узел DRCP определяет, что он принимает трафик от своего партнера. Партнер может быть порталом, содержащим несколько узлов или один узел. Узел DRCP может быть одним узлом портала, в этом случае узел DRCP применяет нормальные операции агрегирования каналов, чтобы сделать выбор, какому трафику разрешить прохождение, если он принимает несколько трафиков от своего партнера (например, позволяя прохождение трафика по текущему рабочему каналу после определения, что канал и соответствующий порт агрегирования все еще находятся в группе агрегирования каналов, в то время как разрешается трафик по текущему каналу защиты после определения, что рабочий канал больше не находится в группе агрегирования каналов). С другой стороны, на этапе 2004 узел DRCP определяет, что он связан с по меньшей мере одним соседним узлом. Когда узел DRCP связан с по меньшей мере одним соседним узлом, узел DRCP разрешает прохождение трафика от своего партнерского узла только тогда, когда принятый операционный ключ партнера является самым низким из операционных ключей партнеров всех соседних узлов портала. В одном варианте осуществления определяется, что DRF_Home_Oper_Partner_Aggregator_Key данного узла ниже, чем все DRF_Neighbor_Oper_Partner_Aggregator_Keys портала.

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

[00966] Фиг. 27 иллюстрирует операцию узла DRCP в координации с его соседним узлом при условии сбоя связи в одном варианте осуществления изобретения. Способ 2800 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С, где узел связан с одним или более соседними узлами. На этапе 2702 узел DRCP определяет, что он принимает трафик от своего партнера. Партнер может быть порталом, содержащим несколько узлов или один узел. Узел DRCP может быть одиночным узлом портала, в этом случае узел DRCP применяет нормальные операции агрегирования каналов, чтобы сделать выбор, какому трафику разрешить прохождение, если он принимает несколько трафиков от своего партнера (например, позволяя прохождение трафика на текущем рабочем канале после определения, что канал и соответствующий порт агрегирования все еще находятся в группе агрегирования каналов, в то же время разрешая трафик по текущему каналу защиты после определения, что рабочий канал больше не находится в группе агрегирования каналов). С другой стороны, на этапе 2704, узел DRCP определяет, что он связан с по меньшей мере одним соседним узлом.

[00967] На этапе 2706 узел DRCP определяет, был ли обновлен принятый операционный ключ. В одном варианте осуществления обновление вызывается отказом/неисправностью IPL. Узел DRCP может определить, что партнерская система испытывает отказ/неисправность IPL, если два старших бита принятого Partner_Oper_Key равны значению 2 или 3, и два младших бита Partner_Oper_Port_Priority порта агрегирования равны значению 2 или 3.

[00968] На этапе 2708 узел DRCP определяет, является ли он изолированным или нет от своего(их) соседнего(их) узла(ов) этого же портала. Узел DRCP может быть изолирован от своего(их) соседнего(их) узла(ов) из-за отказа/неисправности IPL. В этом случае узел DRCP определяет, что связь по IPL на локальном и удаленных порталах неисправна.

[00969] На этапе 2710 узел DRCP определяет, находится ли он в портальной системе более высокого приоритета, и он действует, чтобы предотвратить дублированный трафик, если он есть. В одном варианте осуществления узел DRCP определяет, имеет ли он более высокоприоритетный идентификатор портальной системы, чем его партнерский портал (например, на фиг. 1B, портал 112 может быть более высокоприоритетным порталом, чем портал 114, в этом случае он выполняет этап 2710), и он сбрасывает принятый трафик, если он имеет более высокий идентификатор портальной системы.

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

[00971] Координация между состояниями DRCP и LACP: второй набор вариантов осуществления

[00972] Для координации между состояниями DRCP и LACP, альтернативный способ заключается в обновлении некоторых существующих функций/переменных и работает по-другому, если как локальный, так и партнерский узел DRCP могут сообщать свое состояние IPL.

[00973] Фиг. 26А иллюстрирует TLV маски диалога для порта агрегирования в соответствии с одним вариантом осуществления изобретения. Отметим, что TLV маски диалога является таким же, как показано на фиг. 4А в патентной заявке США № 14/135,556, которая включена посредством ссылки в настоящий документ во всей своей полноте. Фиг. 26В иллюстрирует поле состояния маски в TLV маски диалога порта агрегирования в соответствии с одним вариантом осуществления изобретения. Фиг. 26В отличается от фиг. 4В в патентной заявке США № 14/135,556 тем, что одно поле, PSI (изолированное состояние портала), обозначенное ссылочной позицией 2611, заменяет зарезервированный бит. Этот флаг применим только для портальных систем и используется, чтобы указывать, является ли портальная система изолированной от других портальных систем портала в портале(). TRUE (кодируется как 1), если DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE на всех IPP на этой портальной системе. Его значение в противном случае соответствует FALSE (кодируется как 0).

[00974] Кроме того, функция ReceivedConversationMaskTLV, раскрытая в патентной заявке США № 14/135,556, может быть обновлена следующей дополнительной операцией: она также записывает значение параметра для PSI, переносимое в принятой маске диалога порта, как текущее операционное значение параметра для Partner_PSI.

[00975] Кроме того, функция upddateConversationMaskTLV, раскрытая в патентной заявке США № 14/135,556, может быть обновлена следующей дополнительной операцией: Если эта функция реализуется портальной системой DRCP с ее значением DRF_Portal_System_Number, установленным на значение, отличное от 1, ее идентификатором портальной системы, установленным в значение, численно меньше, чем идентификатор системы партнера, и PSI==Partner_PSI==TRUE, то Comp_Oper_Conversation_Mask устанавливается в NULL.

[00976] Например, со ссылкой на фиг. 1B, когда IPL в K/L и M/O неисправны, все узлы будут передавать трафик - активные узлы К и М передают трафик, поскольку они являются активными узлами, и узлы защиты L и О также передают трафик, так как они изолированы от активных узлов, и теперь считают себя активными. Когда PSI поддерживается на обоих порталах 112 и 114, PSI и принятый PSI партнера были бы TRUE. Предполагая, что портал 112 является более высокоприоритетным порталом (например, системный идентификатор портала 112 ниже, чем у портала 114, то есть его приоритет выше), тогда узел L определяет, что его номер портальной системы (предполагается равным 2, так как это портал двух узлов, а рабочий узел К имеет номер 1 портальной системы) не самый низкий, он будет обновлять свою операционную маску диалога в нуль и не передает и не принимает трафик.

[00977] Фиг. 28 иллюстрирует операцию узла DRCP при сбое связи согласно одному варианту осуществления изобретения. Способ 2800 может быть реализован на узле DRCP (например, сетевом устройстве) портала DRCP (именуемого локальным порталом) в качестве части DRNI, таком как узлы K-О на фиг. 1B и сетевые устройства 132 и 134 на фиг. 1С. На этапе 2802 узел DRCP определяет, что он больше не осуществляет связь с его соседним(и) узлом(ами). Потеря связи может быть вследствие выключения или неисправности IPP, или соседний узел выключен или неисправен. Потеря связи может быть указана в бите PSI, установленном в TRUE (который передается через TLV в LACPDU, описанном здесь выше) в одном варианте осуществления.

[00978] На этапе 2804 узел определяет, что его партнерский узел больше не осуществляет связь с соседним узлом партнера. Партнерский узел может прислать свое состояние PSI через его LACPDU, и PSI будет записываться посредством функции recordReceivedConversationMaskTLV партнера. Когда партнерский узел больше не осуществляет связь со своим соседним узлом, принятое состояние PSI будет установлено в значение TRUE, и в этом случае PSI == Partner_PSI == TRUE.

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

[00980] На этапе 2808 узел определяет, что он не является самым высокоприоритетным узлом своего портала. Приоритет узла в его портале может быть определен по его номеру портальной системы, который равен от 1 до 3 в одном варианте осуществления (для портала с числом узлов до 3). Узел определяет, что он не является самым высокоприоритетным узлом своего портала, если его номер портальной системы не равен 1 в одном варианте осуществления.

[00981] На этапе 2810 узел останавливает передачу и прием трафика группы агрегирования каналов. В одном варианте осуществления узел устанавливает свое Comp_Oper_Conversation_Mask, являющееся операционным значением операционной маски диалога узла, вычисленным обновлением функции маски диалога (например, updateConversationMask).

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

[00983] Вариант осуществления сетевых устройств

[00984] Фиг. 13 представляет собой схему одного примерного варианта осуществления сетевого устройства для выполнения функциональности DRNI, описанной здесь. Сетевое устройство 1380 может быть маршрутизатором или другим аналогичным устройством, реализующим подуровень 1370 агрегирования, как описано выше по отношению к фиг.2, и поддерживает функции агрегирования каналов, описанные выше. Сетевое устройство 1380 может включать в себя сетевой процессор 1300, набор портов 1340, устройство 1350 памяти и аналогичные компоненты сетевого устройства. Компоненты сетевого устройства приведены в качестве примера, но не в качестве ограничения. Сетевое устройство 1380 может реализовать функции агрегирования и подуровень 1370 агрегирования каналов с использованием любого количества или типа процессоров и с любой конфигурацией. В других вариантах осуществления функции агрегирования и подуровень агрегирования каналов и соответствующие компоненты распределены по набору сетевых процессоров, набору линейных карт и их компонентному универсальному или ориентированному на приложение процессору или т.п., реализованному в архитектуре сетевого устройства.

[00985] Порты 1340 могут соединять сетевое устройство через физическую среду, такую как Ethernet, волоконно-оптическая или подобная среда с любым числом других сетевых устройств. Любое количество и разнообразие портов может присутствовать в сетевом устройстве 1380. Любая комбинация или поднабор портов 1340 могут быть организованы и управляются как группа агрегирования каналов или портал DRNI, где сетевое устройство функционирует как система агрегирования. Таким образом, порты могут быть портами агрегирования для одной или более групп агрегирования каналов.

[00986] Набор устройств 1350 памяти в сетевом устройстве 1380 может быть любым типом устройств памяти, кэшей, регистров или подобных устройств хранения данных для использования в качестве рабочей памяти и постоянной памяти. Любое количество и разнообразие устройств 1350 памяти может быть использовано для хранения данных сетевого устройства, включая запрограммированные данные и принятые данные трафика для обработки сетевым устройством 1380. В одном варианте осуществления структуры данных DRNI или подобная организация дайджеста отображения услуги диалога, маски диалога и аналогичные структуры данных, описанные здесь выше, могут храниться в такой структуре данных. Другие структуры данных, сохраняемые в устройстве 1350 памяти, могут включать в себя те, которые описаны здесь выше. В других вариантах осуществления эти структуры данных могут рассматриваться как независимые и могут распределяться по любому количеству отдельных устройств 1350 памяти в сетевом устройстве 1380.

[00987] Набор сетевых процессоров 1300 может осуществлять функции агрегирования и DRNI и подуровень 1370 агрегирования каналов, описанные здесь выше. Функции агрегирования могут включать в себя клиента(ов) 1372 агрегатора и подуровень 1370 агрегирования каналов, который может включать в себя анализатор/мультиплексор 1302 управления, контроллер 1306 агрегирования, коллектор 1325 кадров, дистрибьютор 1320 кадров и DRNI 1313.

[00988] Контроллер 1306 агрегирования, как описано выше, может реализовать функции управления агрегированием каналов протокола управления агрегированием каналов. Эти функции управляют конфигурацией и распределением групп агрегирования каналов, порталом DRNI и подобными аспектами. Анализатор и мультиплексор 1302 управления идентифицирует и пересылает LACPDU из другого трафика данных, принятого на портах агрегирования, и передает LACPDU к контроллеру 1306 агрегирования и другой трафик данных в подуровне 1370 агрегирования каналов.

[00989] Подуровень 1370 агрегирования каналов, как описано выше, управляет сбором и распределением кадров в соответствии с алгоритмом распределения. В подуровне 1370 агрегирования каналов, коллектор 1325 кадров принимает кадры и организует их в соответствии с алгоритмом распределения, используемым совместно с партнерской системой, по группе агрегирования каналов. Дистрибьютор 1320 кадров подготавливает и выбирает исходящие кадры для передачи по набору портов агрегирования в соответствии с алгоритмом распределения. Клиентский интерфейс принимает и передает кадры к/от клиента(ов) 1372 агрегатора. Входящие кадры проходят от коллектора 1325 кадров к клиенту(ам) 1372 агрегатора, а исходящие кадры передаются от дистрибьютора 1320 кадров к клиенту(ам) 1372 агрегатора. Функции 1311 DRNI, описанные выше, выполняются сетевым процессором 1311.

[00990] Хотя изобретение описано в терминах нескольких примерных вариантов осуществления, специалистам в данной области техники должно быть понятно, что изобретение не ограничено описанными вариантами осуществления, а может быть осуществлено на практике с модификацией и изменением в пределах сущности и объема прилагаемой формулы изобретения. Описание, таким образом, следует рассматривать как иллюстративное, а не ограничительное.

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

инициализацию (3502) набора ID диалогов на сетевом устройстве, при этом инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства;

определение (3504) того, что распределение набора ID диалогов нуждается в обновлении;

установку (3506) значений операционного вектора, индексированного посредством ID диалогов, причем операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов; и

установку (3508) значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли один шлюз или один агрегатор сетевого устройства с каждым из ID диалогов.

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

3. Способ по п. 1 или 2, дополнительно содержащий:

обновление (3510) операционных состояний всех сетевых устройств первого портала; и

установку (3512) переменной, указывающей, что распределение набора ID диалогов нуждается в обновлении.

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

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

6. Способ по п. 1 или 2, в котором набор ID диалогов является набором ID диалогов портов, и в котором набор ID диалогов портов используется для выбора кадров, проходящих порты агрегирования первого портала.

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

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

порты (1340), связанные с физическим каналом или каналом агрегирования группы агрегирования каналов, причем порты включают в себя порты агрегирования, и

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

9. Сетевое устройство по п. 8, в котором определение того, что распределение набора ID диалогов нуждается в обновлении, содержит проверку булевой переменной.

10. Сетевое устройство по п. 8 или 9, в котором модуль DRNI дополнительно выполнен с возможностью:

обновлять операционные состояния всех сетевых устройств первого портала; и

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

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

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

13. Сетевое устройство по п. 8 или 9, в котором набор ID диалогов является набором ID диалогов портов, и в котором набор ID диалогов портов используется для выбора кадров, проходящих порты агрегирования первого портала.

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

15. Невременный машиночитаемый носитель хранения данных, содержащий инструкции, сохраненные в нем, которые, при исполнении процессором, побуждают процессор выполнять операции в сетевом устройстве для конфигурирования набора идентификаторов (ID) диалогов в сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов, причем каждый ID диалога предназначен для идентификации диалога, включающего в себя упорядоченную последовательность кадров, причем сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством через внутри-портальный порт (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала, причем операции содержат:

инициализацию (3502) набора ID диалогов на сетевом устройстве, при этом инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством одного шлюза или одного агрегатора сетевого устройства;

определение (3504) того, что распределение набора ID диалогов нуждается в обновлении;

16. Невременный машиночитаемый носитель хранения данных по п. 15, в котором определение того, что распределение набора ID диалогов нуждается в обновлении, содержит проверку булевой переменной.

17. Невременный машиночитаемый носитель хранения данных по п. 15 или 16, в котором операции дополнительно содержат:

обновление (3510) операционных состояний всех сетевых устройств первого портала; и

установку (3512) переменной, указывающей, что распределение набора ID диалогов нуждается в обновлении.

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

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

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

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

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

инициализацию (3602) набора ID диалогов на сетевом устройстве, причем инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством IPP;

определение (3604) того, что распределение набора ID диалогов нуждается в обновлении;

установку (3606) значений первого операционного вектора, индексированного посредством ID диалогов, причем первый операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено сетевым устройством;

установку (3608) значений второго операционного вектора, индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено соседним сетевым устройством, и

установку (3610) значений булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли IPP сетевого устройства с каждым из ID диалогов.

23. Способ по п. 22, в котором определение того, что распределение набора ID диалогов нуждается в обновлении, содержит проверку булевой переменной.

24. Способ по п. 22 или 23, в котором набор ID диалогов является набором ID диалогов шлюзов, и в котором набор ID диалогов шлюзов используется для выбора кадров, проходящих один из шлюзов первого портала.

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

26. Способ по п. 22 или 23, в котором набор ID диалогов является набором ID диалогов портов, и в котором набор ID диалогов портов используется для выбора кадров, проходящих порты агрегирования первого портала.

27. Способ по п. 26, в котором первый операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено сетевым устройством, и в котором второй операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено соседним сетевым устройством.

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

порты (1340), связанные с физическим каналом или каналом агрегирования группы агрегирования каналов, причем порты включают в себя порты агрегирования; и

сетевой процессор (1300), связанный с портами, причем сетевой процессор выполняет функцию DRNI (1313), причем модуль DRNI выполнен с возможностью инициализировать набор ID диалогов на сетевом устройстве, причем инициализация включает в себя установку элементов булева вектора, ассоциированного с набором ID диалогов, в последовательность нулей, и при этом булев вектор включает в себя значения, указывающие обработку набора ID диалогов посредством IPP, далее дополнительно выполнен с возможностью, что распределение набора ID диалогов нуждается в обновлении, дополнительно выполнен с возможностью устанавливать значения первого операционного вектора, индексированного посредством ID диалогов, причем первый операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено сетевым устройством, дополнительно выполнен с возможностью устанавливать значения второго операционного вектора, индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из множества ID диалогов, как назначено соседним сетевым устройством, и дополнительно выполнен с возможностью устанавливать значения булева вектора, индексированного посредством ID диалогов, причем булев вектор перечисляет, ассоциирован ли IPP сетевого устройства с каждым из ID диалогов.

29. Сетевое устройство по п. 28, в котором определение того, что распределение набора ID диалогов нуждается в обновлении, содержит проверку булевой переменной.

30. Способ по п. 28 или 29, в котором набор ID диалогов является набором ID диалогов шлюзов, и в котором набор ID диалогов шлюзов используется для выбора кадров, проходящих один из шлюзов первого портала.

31. Сетевое устройство по п. 30, в котором первый операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога шлюза, как назначено сетевым устройством, и в котором второй операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога шлюза, как назначено соседним сетевым устройством.

32. Сетевое устройство по п. 28 или 29, в котором набор ID диалогов является набором ID диалогов портов, и в котором набор ID диалогов портов используется для выбора кадров, проходящих порты агрегирования первого портала.

33. Сетевое устройство по п. 32, в котором первый операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено сетевым устройством, и в котором второй операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено соседним сетевым устройством.

34. Невременный машиночитаемый носитель хранения данных, содержащий инструкции, сохраненные в нем, которые, при исполнении процессором, побуждают процессор выполнять операции в сетевом устройстве для конфигурирования набора идентификаторов (ID) диалогов в сетевом устройстве в распределенном отказоустойчивом сетевом межсоединении (DRNI) группы агрегирования каналов, причем каждый ID диалога предназначен для идентификации диалога, имеющего упорядоченную последовательность кадров, причем сетевое устройство и соседнее сетевое устройство включены в первый портал группы агрегирования каналов, причем первый портал связан через каналы группы агрегирования каналов со вторым порталом, включающим в себя одно или более удаленных сетевых устройств, причем сетевое устройство соединено с возможностью связи с соседним сетевым устройством посредством внутри-портального порта (IPP) с использованием внутри-портального канала (IPL), причем каждое из сетевого устройства и соседнего сетевого устройства реализует агрегирование каналов, включающее в себя порты агрегирования, с одним агрегатором первого портала, и причем каждое из сетевого устройства и соседнего сетевого устройства включает в себя один шлюз первого портала, при этом операции содержат:

определение (3604) того, что распределение набора ID диалогов нуждается в обновлении;

установку (3608) значений второго операционного вектора,

индексированного посредством ID диалогов, причем второй операционный вектор перечисляет, какое сетевое устройство первого портала обрабатывает каждый из набора ID диалогов, как назначено соседним сетевым устройством; и

35. Невременный машиночитаемый носитель хранения данных по п. 34, в котором определение того, что распределение набора ID диалогов нуждается в обновлении, содержит проверку булевой переменной.

36. Невременный машиночитаемый носитель хранения данных по п. 34 или 35, в котором набор ID диалогов является набором ID диалогов шлюзов, и в котором набор ID диалогов шлюзов используется для выбора кадров, проходящих один из шлюзов первого портала.

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

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

39. Невременный машиночитаемый носитель хранения данных по п. 38, в котором первый операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено сетевым устройством, и в котором второй операционный вектор перечисляет, какое сетевое устройство передает каждый ID диалога порта, как назначено соседним сетевым устройством.

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

Способ для предоставления службы имен внутри промышленной системы связи и маршрутизатор // 2619206

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении безопасности передачи данных в сети.

Система передачи трафика в мультисервисных сетях связи // 2618191

Изобретение относится к технике связи и мультисервисным сетям. Технический результат изобретения заключается в повышении эффективности использования канального ресурса.

Система мониторинга кабельных соединений с использованием рефлектометра // 2618190

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

Интеллектуальная система синхронизации маршрутизации и способы синтетической ретрансляции для установления социальных контактов и потоковой передачи контента для группы пользователей // 2617919

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

Способ и устройство для переключения интерфейса // 2616880

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

Сетевая система, способ, устройство и программа // 2616169

Изобретение относится к средствам управления сетью. Технический результат заключается в снижении нагрузки на сеть.

Способ и устройство для обработки имен и пакетов прозрачного соединения множества каналов (trill) // 2614856

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

Способ и устройство для разделения нагрузки // 2613528

Изобретение относится к технологии разделения нагрузки при передаче данных по сети. Технический результат – эффективное балансирование разделения нагрузки при реализации NAT на множестве CRU.

Устройство управления, система связи, способ передачи управляющей информации и программа // 2612610

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

Сетевой способ и сетевое устройство // 2621606

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных в сети. Способ содержит этапы, на которых конфигурируют сетевую конфигурационную информацию по меньшей мере одного сервера потокового мультимедиа при помощи конфигурационного модуля в сетевом устройстве IPTV; получают при помощи управляющего модуля в сетевом устройстве IPTV сетевую конфигурационную информацию; регулируют коммутационный модуль посредством регулировочного интерфейса коммутационного модуля на основании сетевой конфигурационной информации при помощи управляющего модуля; при этом сетевая конфигурационная информация содержит информацию о сетевом режиме и конфигурационную информацию М внешних интерфейсов в списке внешних интерфейсов коммутационного модуля в сетевом устройстве IPTV, где М - целое число, большее или равное 1; при этом регулировку коммутационного модуля осуществляют посредством регулировки атрибутов М внешних интерфейсов в коммутационном модуле при помощи управляющего модуля. 2 н. и 10 з.п. ф-лы, 8 ил.

Узел связи, устройство управления, система связи, способ обработки пакетов, способ управления узлом связи и программа // 2621619

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

Способ управления механизмами обеспечения качества обслуживания в мультисервисной сети связи // 2622632

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

Способ, устройство и система для загрузки файла // 2623720

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

Система автоматической конфигурации и оптимизации беспроводной стыковки // 2623723

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Система связи содержит два или более устройств, содержащих стыкуемое устройство и один или более хостов стыковки, по меньшей мере одну среду связи, расположенную между двумя или более устройствами, множество системных элементов, которые можно использовать для реализации части одного или более каналов связи, подлежащих установлению, множество интерфейсных элементов данных, представляющих либо точки соединения между системными элементами, либо точки соединения между системным элементом и концевой точкой одного или более каналов связи, подлежащих установлению, причем система согласования соединения содержит по меньшей мере один процессор, выполненный с возможностью: принимать, в качестве первого входного сигнала процессора, одну или более пар концевых точек одного или более каналов связи, в качестве второго входного сигнала процессора, описание возможностей и ограничений по меньшей мере двух устройств и, в необязательном порядке, среды связи, находить поднабор Tx набора B блочных элементов данных. 4 н. и 10 з.п ф-лы, 7 ил.

Способ и устройство для управления пакетами // 2623897

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ управления пакетами, содержащий: прием сообщения интерфейса управления терминалом оптической сети (OMCI), которое переносит конфигурационное правило и послано терминалом оптической линии (OLT) через объект управления, причем это конфигурационное правило включает режимы для обработки пакетов в различных направлениях; обработку пакетов, передаваемых в различных направлениях, по-разному согласно конфигурационному правилу; при этом упомянутое конфигурационное правило содержит часть с условием фильтра и часть обработки; а условие фильтра включает: идентификатор виртуальной локальной сети (VID), идентификатор протокола метки (TPID) или тип Ethernet. 2 н. и 8 з.п. ф-лы, 4 ил.

Архитектура накристального межсоединения // 2625558

Группа изобретений относится к вычислительным системам с большой вычислительной мощностью, реализованным на одном полупроводниковом кристалле. Техническим результатом является повышение масштабируемости сети с низкой задержкой и низким энергопотреблением. В одном варианте система содержит множество площадок, выполненных на полупроводниковом кристалле, по меньшей мере, две из множества площадок имеют множество ядер; и множество сетевых коммутаторов, выполненных на полупроводниковом кристалле, которые связаны с множеством площадок, где первый сетевой коммутатор из множества сетевых коммутаторов содержит множество выходных портов, причем выходные порты первого множества из множества выходных портов предназначены для соединения с соответствующим сетевым коммутатором площадки через межсоединение типа "точка - точка", а выходные порты второго множества выходных портов предназначены для соединения с соответствующими сетевыми коммутаторами множества площадок через межсоединение "точка - группа точек", в которой ширина проводника межсоединения "точка - точка" больше, чем ширина провода межсоединения "точка - группа точек". 3 н. и 15 з.п. ф-лы, 9 ил.

Технология мобильного вычислительного устройства и система и способы, использующие ее // 2625952

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

Способ и устройство для адаптивной радиосвязи // 2626335

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

Способ, система и устройство связи для оптической сетевой системы // 2627112

Изобретение относится к передаче данных в оптической сетевой системе. Технический результат - экономия ресурса полосы пропускания линии и реализация контроля линии, не прерывая обслуживание. Для этого схема кодирования реализуется следующим образом: осуществляется кодирование из 32 битов в 34 бита применительно к потоку данных, подвергнутому 8-битовому/10-битовому декодированию, осуществляется кодирование с прямым исправлением ошибок применительно к потоку данных, подвергнутому кодированию из 32 битов в 34 бита, и отправляется кодированный поток данных; или осуществляется декодирование с прямым исправлением ошибок применительно к принятому потоку данных, и осуществляется декодирование из 32 битов в 34 бита применительно к потоку данных, подвергнутому декодированию с прямым исправлением ошибок. 5 н.п. и 15 з.п. ф-лы, 18 ил.