СПОСОБ И СИСТЕМА ДЛЯ ПОДДЕРЖКИ ОПЕРАЦИЙ ПО ПРОТОКОЛУ УПРАВЛЕНИЯ РАСПРЕДЕЛЕННЫМ РЕТРАНСЛЯТОРОМ (DRCP) ПРИ СБОЕ СВЯЗИ Российский патент 2017 года по МПК H04L12/709 H04L12/24 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0024] Фиг. 5 является схемой DRCPDU-структуры данных.

[0025] Фиг. 6A является схемой состояния протокола управления распределенным ретранслятором (DRCP).

[0026] Фиг. 6B является схемой одного варианта осуществления DRCP.

[0027] Фиг. 6C является полем состояний топологии 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] Фиг. 26A иллюстрирует TLV масок разговоров для агрегированного порта согласно одному варианту осуществления изобретения.

[0048] Фиг. 26B иллюстрирует поле состояний масок разговоров в 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 иллюстрирует способ для конфигурирования набора идентификаторов разговоров для агрегатора или шлюза в DRCP-узле в распределенном отказоустойчивом межсетевом взаимодействии (DRNI) согласно варианту осуществления изобретения.

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

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

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

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

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

[0062] Термины

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0077] Внутренняя услуга подуровня (ISS): Дополненная версия MAC-услуги, заданной в станд. IEEE 802.1AC-2012.

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

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

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

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

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

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

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

[0085] Экземпляр услуги

Идентификатор услуги: Значение, извлекаемое из заголовка кадра (VID, I-SID и т.д.), которое идентифицирует экземпляр услуги, с которым ассоциирован этот кадр.

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

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

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

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

[0090] При использовании в данном документе, сетевое устройство (например, маршрутизатор, коммутатор, мост) представляет собой единицу сетевого оборудования, включающего в себя аппаратные средства и программное обеспечение, которая функционально соединяет другое оборудование в сети (например, другие сетевые устройства, оконечные станции). Некоторые сетевые устройства представляют собой "сетевые устройства с поддержкой комплексных услуг", которые предоставляют поддержку для нескольких сетевых функций (например, маршрутизации, организации мостовых соединений, коммутации, агрегирования уровня 2, пограничного управления сеансами, качества обслуживания и/или управления абонентами) и/или предоставляют поддержку для нескольких прикладных услуг (например, данные, речь и видео). Оконечные абонентские станции (например, серверы, рабочие станции, переносные компьютеры, карманные компьютеры, мобильные телефоны, смартфоны, мультимедийные телефоны, телефоны по протоколу "речь-по-IP" (VoIP), абонентские устройства, терминалы, портативные мультимедийные проигрыватели, GPS-модули, игровые приставки, абонентские приставки (STB) и т.д.) осуществляют доступ к контенту/услугам, предоставленным по Интернету, и/или к контенту/услугам, предоставленным по виртуальным частным сетям (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, а также организация трафика (TE) по протоколу RSVP: расширения RSVP для LSP-туннелей (RFC 3209), RSVP-TE для передачи служебных сигналов по протоколу обобщенной многопротокольной коммутации по меткам (GMPLS) RFC 3473, RFC 3936, 4495 и 4558)), которые обмениваются данными с другими сетевыми устройствами, чтобы обмениваться маршрутами и выбирать эти маршруты на основе одного или более показателей маршрутизации. Помимо этого, плоскость управления также типично включает в себя управляющие ISO-протоколы уровня 2, к примеру, протокол высокоскоростных связующих деревьев (RSTP), протокол множественных связующих деревьев (MSTP) и SPB (организация мостовых соединений по кратчайшему пути), которые стандартизированы посредством различных органов по стандартизации (например, SPB задана в станд. IEEE 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, 2675, 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). Например, сетевое устройство, в котором соединены сеть поставщика и сеть пользователя, соответственно, упоминается в качестве PE (устройств на стороне поставщика) и CE (устройств на стороне пользователя). В VPN уровня 2, переадресация типично выполняется для CE на любом конце VPN, и трафик отправляется по сети (например, через одно или более PE, соединенных посредством других сетевых устройств). Схемы уровня 2 сконфигурированы между CE и PE (например, Ethernet-порт, постоянная виртуальная схема (PVC) по протоколу ATM, PVC по протоколу ретрансляции кадров). В VPN уровня 3, маршрутизация типично выполняется посредством PE. В качестве примера, граничное сетевое устройство, которое поддерживает несколько контекстов, может развертываться в качестве PE; и контекст может быть сконфигурирован с помощью VPN-протокола, и в силу этого данный контекст упоминается в качестве VPN-контекста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00123] g) Виртуальная линия связи и ее терминальные виртуальные MAC, называемые "шлюзом", сконструированы с возможностью соединять каждую DR-функцию со своей функцией 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1
DR-функция: переадресация кадра, принимаемого из внутрипортальной линии связи n Алгоритм для шлюза Алгоритм для порта DR-функция говорит "Шлюз..." говорит "Агрегированный порт..." испускает кадр в: является моим шлюзом является любым* мой шлюз находится после IPL n является одним из моих мой порт агрегатора агрегированных портов находится после IPL n отбрасывание находится после IPL m (≠n) IPL m (≠n) находится после IPL m (≠n) является любым <надстрочный индекс>1 IPL m (≠n)

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

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

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

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

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

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

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

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

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

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

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

[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, его ближайший соседний узел представляет собой A (поскольку он соединяется с IPP B1 через IPL AB), и ее другой соседний узел представляет собой C (поскольку он соединяется с IPP B2 через IPL BC). Следует отметить, что другой соседний узел IPP A2 также представляет собой C (поскольку он соединяется с IPP A1 через IPL AC), так что сравнение идентификаторов других соседних узлов IPP B1 и A2 верифицирует то, что предусмотрено не более трех систем в кольце или цепочке.

[00154] Внутрипортальная линия связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00166] Совместное использование сетевой/IPL по тегу

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

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

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

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

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

[00172] Машина состояний DR-функции

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

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

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

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

d) Кадр перевода в неактивное состояние, предлагаемый для IPP, передается только в том случае, если целевая портальная система для этого идентификатора разговора по порту находится после этого IPP, иначе он отбрасывается.

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

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

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

[00175] Интерфейсы предоставления услуг

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

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

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

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

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

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

[00177] Переменные в расчете на DR-функцию

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

[00179] DA: целевой адрес

[00180] SA: исходный адрес

[00181] mac_service_data_unit

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

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

[00184] Value: Булево выражение

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

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

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

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

[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] A) Устанавливать связь между портальными системами через внутрипортальную линию связи;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00231] E) Начальные и резервные назначения идентификаторов разговоров для шлюзов и агрегированных портов, чтобы охватывать режимы сбоя, сконфигурированы в нескольких управляемых объектах: 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] Целевой MAC-адрес

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

[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, после которой следуют дополняющие октеты, если таковые имеются, при необходимости посредством базовой MAC-услуги.

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

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

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

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

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

[00247] Когда кодирование (элемента) DRCPDU проиллюстрировано на схеме:

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

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

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

[00251] D) Когда последовательные октеты используются для того, чтобы представлять MAC-адрес, младшему биту первого октета назначается значение первого бита MAC-адреса, следующему старшему биту - значение второго бита MAC-адреса, и т.д. до восьмого бита. Аналогично, младшим-старшим битам второго октета назначается значение девятого-семнадцатого битов 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 протокола (шестнадцатеричное xx-xx).

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

[00256] DRCPDU-структура

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

[00258] A) Subtype. Поле подтипа идентифицирует инкапсуляцию конкретного протокола Slow Protocol. DRCPDU переносят значение подтипа 0x0X. Отметим, что A) не должно присутствовать, если выбор не является использованием EtherType по протоколу Slow Protocol, чтобы идентифицировать DCRP-операцию.

[00259] B) Version Number. Оно идентифицирует DCRP-версию; реализации согласно одному варианту осуществления переносят значение 0x01.

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

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

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

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

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

[00265] H) Portal_ID. Компонент MAC-адреса идентификаторов портала из aDrniPortalId в одном варианте осуществления.

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

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

[00268] K) 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, сконфигурирована как линия связи для разрыва петли. Истинный указывает то, что IPL сконфигурирована в aDrniLoopBreakLink и кодирована как 1; иначе, флаг кодирован как 0.

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

[00274] K2) 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. Истинный (кодируется как 1) указывает то, что TLV информации других портов не ассоциирован с ближайшим соседним узлом этой портальной системы. Ложный (кодируется как 0) указывает то, что TLV информации других портов представляет собой ближайший соседний узел в другом IPP в этой портальной системе в одном варианте осуществления.

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

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

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

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

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

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

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

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

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

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

[00289] 3) Other_Gateway кодируется в бите 2 в одном варианте осуществления. Этот флаг указывает рабочее состояние шлюза потенциально других DR-функций. Истинный указывает рабочее и кодируется как 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 в одном варианте осуществления. Если истинный (кодируется как 1), эта DR-функция считает, что соседние системы-партнеры этого IPP имеют свои шлюзы IN_SYNC; т.е. рабочий вектор этой портальной системы, перечисляющий то, какой шлюз портальной системы (если имеются) пропускает каждый идентификатор разговора по шлюзу, является согласованным с рабочим вектором соседних узлов этого IPP. Если ложный (кодируется как 0), то этот IPP в данный момент OUT_OF_SYNC; т.е. рабочий вектор соседних узлов этого IPP, перечисляющий то, какой шлюз портальной системы (если имеются) пропускает каждый идентификатор разговора по шлюзу, является рассогласованным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00307] Ae) Other_Ports_Information_Length. Это поле указывает длину (в октетах) этого TLV-кортежа. Информация других портов использует значение длины, в 4 раза превышающее число агрегированных портов другой портальной системы, которые включены.

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

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

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

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

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

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

[00314] Отметим, что использование Terminator_Length 0 является намеренным. В схемах TLV-кодирования, установившаяся практика для кодирования завершителя заключается в том, что он составляет 0 как для типа, так и для длины.

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

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

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

Таблица 4
Значения полей типа DRCP TLV TLV Поле типа TLV завершителя 0×00 TLV информации портала 0×01 TLV информации конфигурации портала 0×02 TLV DRCP-состояния 0×03

TLV информации домашних портов 0×04 TLV информации соседних портов 0×05 TLV других портов 0×06 TLV способа совместного использования сетевой/IPL 0×07 TLV совместного использования сетевой/IPL посредством инкапсуляции 0×08 Зарезервированный для IEEE 802.1 0×09-0×0E Конкретный для организации TLV 0×0F Зарезервированный для IEEE 802.1 0×10-0×FF

[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 является аналогичной DRCPDU-структуре по фиг. 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 является аналогичной DRCPDU-структуре по фиг. 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-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C.

[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) поле идентификаторов агрегаторов, указывающем идентификатор агрегатора, (3) поле приоритетов порталов, указывающем приоритет, назначаемый порталу, и (4) поле адресов порталов, указывающем компонент MAC-адреса, ассоциированный с сетевым устройством, как пояснено выше в данном документе.

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

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

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

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

- TLV информации других портов указывает текущее состояние другого соседнего узла, ассоциированного с DRNI, когда локальный портал включает в себя более двух узлов. В одном варианте осуществления, текущее состояние другого соседнего узла указывается в (1) поле административных ключей агрегатора, указывающем значение административного ключа агрегатора для агрегатора, присоединенного к другому узлу, (2) поле рабочих ключей агрегатора-партнера, указывающем рабочий ключ агрегатора-партнера, ассоциированный с идентификатором LAG агрегатора другого соседнего узла, и (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
Значения полей типа TLV совместного использования сетевой/IPL TLV Поле типа TLV способа совместного использования сетевой/IPL 0×07 TLV совместного использования сетевой/IPL посредством инкапсуляции 0×08

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

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

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

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

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

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

Таблица 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=совместное использование сетевой/IPL посредством инкапсуляции 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=TLV совместного использования сетевой/IPL посредством инкапсуляции. Это поле указывает характер информации, переносимой в этом TLV-кортеже. TLV совместного использования сетевой/IPL идентифицируются посредством целочисленного значения 0×08.

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

[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-C2). Значение по умолчанию 0x01-80-C2-00 указывает то, что IPL использует отдельную физическую или агрегированную линию связи. Значение 1 указывает то, что используется совместное использование сетевой/IPL по времени. Значение 2 указывает то, что используемый способ инкапсуляции является идентичным способу, используемому посредством сетевых кадров, и то, что используется совместное использование сетевой/IPL по тегу.

[00347] DrniIPLEncapMap

[00348] АТРИБУТ

[00349] НАДЛЕЖАЩИЙ СИНТАКСИС

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

[00351] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[00353] aDrniNetEncapMap

[00354] АТРИБУТ

[00355] НАДЛЕЖАЩИЙ СИНТАКСИС

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

[00357] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[00359] aAggPortalgorithm

[00360] АТРИБУТ

[00361] НАДЛЕЖАЩИЙ СИНТАКСИС

[00362] Последовательность октетов, состоящая из трехоктетного организационно уникального идентификатора (OUI) и одного следующего октета.

[00363] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[00365] aAggActorSystemID

[00366] АТРИБУТ

[00367] НАДЛЕЖАЩИЙ СИНТАКСИС:

[00368] MACAddress

[00369] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

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

[00372] aAggActorSystemPriority

[00373] АТРИБУТ

[00374] НАДЛЕЖАЩИЙ СИНТАКСИС:

[00375] INTEGER

[00376] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[00378] Конкретный для организации TLV

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

TLV_type=конкретный для организации 1 Organization_Specific_Length=LL 1 OUI 3 Subtype 7 Value (необязательное) LL-12,

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

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

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

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

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

[00385] Краткий обзор машин DRCP-состояния

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

[00387] Машины состояний следующие:

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

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

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

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

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

[00393] F) Машина передачи (TX-см. подраздел "Машина передачи" ниже в данном документе). Эта машина состояний обрабатывает передачу DRCPDU, как по требованию из других машин состояний, так и на периодической основе.

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

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

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

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

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

[00399] aDrniPortalId

[00400] АТРИБУТ

[00401] НАДЛЕЖАЩИЙ СИНТАКСИС:

ПОСЛЕДОВАТЕЛЬНОСТЬ 8 ОКТЕТОВ, которые совпадают с синтаксисом 48-битового MAC-адреса

[00402] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[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. Также используется в качестве идентификатора системы (6.3.2) актора для эмулированной системы.

[00421] aDrniPortalPriority

[00422] АТРИБУТ

[00423] НАДЛЕЖАЩИЙ СИНТАКСИС:

INTEGER

[00424] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

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

[00425] aDrniPortalTopology

[00426] АТРИБУТ

[00427] НАДЛЕЖАЩИЙ СИНТАКСИС:

[00428] INTEGER

[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], индексированных посредством идентификатора разговора по шлюзу. Каждая содержит текущее административное значение списка приоритетов выбора шлюза для распределенного ретранслятора. Этот список приоритетов выбора, последовательность целых чисел для каждого идентификатора разговора по шлюзу, представляет собой список номеров портальных систем в порядке предпочтений, от наибольшего к наименьшему, для шлюза соответствующей предпочтительной портальной системы, чтобы переносить этот разговор.

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

[00454] aDrniGatewayAlgorithm

[00455] АТРИБУТ

[00456] НАДЛЕЖАЩИЙ СИНТАКСИС:

Последовательность октетов, состоящая из организационно уникального идентификатора (OUI) и один или более следующих октетов.

[00457] ПОВЕДЕНИЕ ЗАДАЕТСЯ СЛЕДУЮЩИМ ОБРАЗОМ

Этот объект идентифицирует алгоритм, используемый посредством DR-функции, чтобы назначать кадры идентификатору разговора по шлюзу.

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

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

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

[00461] Value: Целое число; 1

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

[00463] Value: Целое число; 30

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

[00465] Value: Целое число; 3

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

[00467] Value: Целое число; 90

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

[00469] Value: Целое число; 2

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

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

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

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

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

[00475] Value: 48 битов

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

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

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

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

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

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

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

[00483] Value: Целое число

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

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

[00486] Value: 48 битов

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

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

[00489] Value: Целое число в диапазоне [0...3]

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

[00491] Переменные в расчете на DR-функцию

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

[00493] Value: Булево выражение

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

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

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

[00497] Value: последовательность идентификаторов портов

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

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

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

[00502] Value: Целое число

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

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

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

[00506] Value: MD5-дайджест

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

[00508] Value: MD5-дайджест

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

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

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

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

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

[00514] Value: Целое число

[00515] DRF_Home_Oper_Partner_Aggregator_Key: Рабочий ключ агрегатора-партнера, ассоциированного с идентификатором LAG агрегатора этой портальной системы. Передается в DRCPDU.

[00516] Value: Целое число

[00517] DRF_Home_State: Рабочее состояние этой DR-функции. Передается в DRCPDU.

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

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

[00520] Value: MD5-дайджест

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

[00522] Value: MD5-дайджест

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

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

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

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00526] Value: 8 битов

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

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

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

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

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

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

[00533] Value: Булево выражение

[00534] Переменные в расчете на IPP

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

[00536] Ipp_Gateway_Conversation_Direction: Рабочий список того, какие идентификаторы разговоров по шлюзу проходят через шлюзы, достижимые через этот IPP. Он задается посредством работы DRCP.

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

[00538] Для каждого идентификатора разговора по шлюзу значение является истинным исключительно в том случае, если a) переменные Drni_Gateway_Conversation и Drni_Portal_System_State[] указывают то, что целевая портальная система для этого идентификатора разговора по шлюзу находится после этого IPP, и b) Drni_Gateway_Conversation и Ipp_Other_Gateway_Conversation являются согласованными в отношении того, какая портальная система должна получать этот идентификатор разговора по шлюзу. Ipp_Gateway_Conversation_Direction инициализируется как ложная и повторно вычисляется каждый раз, когда изменяется любая из ее составляющих переменных. Для кадров, принимаемых в этом IPP, "истинный" означает то, что, кадр представляет собой кадр перевода в неактивное состояние, в конечном счете предназначенный для агрегатора (или отбрасываемый), и "ложный" означает то, что кадр представляет собой кадр перевода в активное состояние, в конечном счете предназначенный для шлюза (или отбрасываемый). Для кадров, предлагаемых для передачи по этому IPP, "истинный" указывает то, что кадр может проходить, а "ложный" - то, что он не может. Эта переменная не используется для того, чтобы управлять кадрами перевода в неактивное состояние.

[00539] Ipp_Port_Conversation_Passes: Рабочий список того, каким идентификаторам разговоров по порту разрешается передаваться через этот IPP.

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

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

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

[00543] Value: Булево выражение

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

[00545] Value: Булево выражение

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

[00547] Value: Булево выражение

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

[00549] Value: Булево выражение

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

[00551] Value: Булево выражение

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

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

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

[00555] Value: Булево выражение

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

[00557] Value: MD5-дайджест

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

[00559] Value: MD5-дайджест

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

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

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

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00563] Value: 8 битов

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

[00565] Value: Целое число

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

[00567] Value: Целое число

[00568] DRF_Neighbor_AggregatorID: Последний принимаемый компонент MAC-адреса идентификатора системы агрегатора соседней портальной системы, в этом IPP.

[00569] Value: 48 битов

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

[00571] Value: Целое число

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

[00573] Value: MD5-дайджест

[00574] DRF_Neighbor_Conversation_PortList_Digest: Последний принимаемый дайджест идентификаторов разговоров по порту соседней портальной системы в этом IPP.

[00575] Value: MD5-дайджест

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

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

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

[00579] Value: Булево выражение

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

[00581] Value: MD5-дайджест

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

[00583] Value: MD5-дайджест

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

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

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

[00587] Value: Целое число

[00588] DRF_Neighbor_Oper_Partner_Aggregator_Key: Значение рабочего ключа агрегатора-партнера соседней портальной системы в этом IPP. Передается в DRCPDU.

[00589] Value: Целое число

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

- HomeGateway

- NeighborGateway

- OtherGateway

- IPPActivity

- Timeout

- GatewaySync

- PortSync

- Expired

[00591] Value: 8 битов

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

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

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

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

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

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

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

[00599] Value: Целое число в диапазоне [0...3].

[00600] DRF_Neighbor_State: Рабочее состояние ближайшей соседней портальной системы в этом IPP.

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

[00602] Drni_Neighbor_ONN

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

[00604] Value: Целое число

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

[00606] Value: Целое число

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

[00608] Value: Целое число

[00609] DRF_Other_Neighbor_State: Рабочее состояние другой соседней портальной системы в этом IPP.

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

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

[00612] Value: 48 битов

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

[00614] Value: Целое число

[00615] Drni_Neighbor_PortalID: Последний принимаемый компонент MAC-адреса идентификатора портальной системы для соседней портальной системы в этом IPP.

[00616] Value: 48 битов

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

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

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

[00620] Value: Булево выражение

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

[00622] Value: Булево выражение

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

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

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

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

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

[00628] Value: Булево выражение

[00629] Истинная, если IPP является рабочим (MAC_Operational == истинная).

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

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

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

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

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

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

[00636] ONN

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

[00638] Value: Булево выражение

[00639] Истинный указывает то, что TLV информации других портов не ассоциирован с ближайшим соседним узлом этой портальной системы. Ложный (кодируется как 0) указывает то, что 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] Value: Целое число

[00649] 1

[00650] Drni_Slow_Periodic_Time

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

[00652] Value: Целое число

[00653] 30

[00654] Drni_Short_Timeout_Time

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

[00656] Value: Целое число

[00657] 3

[00658] Drni_Long_Timeout_Time

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

[00660] Value: Целое число

[00661] 90

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

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

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

[00665] Value: Булево выражение

[00666] DRCP_Enabled

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

[00668] Value: Булево выражение

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

[00670] Value: Булево выражение

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

[00672] Value: Булево выражение

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

[00674] Value: Булево выражение

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

[00676] Value: Булево выражение

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

[00678] Value: Булево выражение

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

[00680] Value: Булево выражение

[00681] Функции

[00682] Нижеприведенное пояснение акцентирует внимание на множестве функций согласно одному варианту осуществления изобретения.

[00683] extractGatewayConversationID

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

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

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

[00687] extractPortConversationID

[00688] extractPortConversationID

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

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

[00691] InitializeDRNIGatewayConversation

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

[00693] InitializeDRNIPortConversation

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

[00695] InitializeIPPGatewayConversation

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

[00697] InitializeIPPPortConversation

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

[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 задается как пустое (булев флаг для шлюза соседней портальной системы задается как ложный, и список рабочих агрегированных портов на соседней портальной системе в этом IPP опустошается), и если aDrniPortalTopology выполнен с возможностью содержать три портальные системы, DRF_Other_Neighbor_State также задается как пустое (булев флаг для шлюза другой соседней портальной системы задается как ложный, и список рабочих агрегированных портов в другой соседней портальной системе в этом 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 задается как истинная.

[00702] В завершение, она задает CC_Time_Shared и CC_EncTag_Shared как ложные.

[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 как истинную.

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

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

- Значения параметров для Other_Gateway в DRF_Home_Oper_DRCP_State и Other_Neighbor_Ports в TLV информации других портов, переносимом в принимаемой DRCPDU в IPP, используются в качестве текущих значений для DRF_Other_Neighbor_State в этом IPP, и ассоциирует информацию состояния этой портальной системы с портальной системой, идентифицированной посредством значения, назначаемого двум старшим битам DRF_Other_Neighbor_Admin_Aggregator_Key, переносимого в TLV информации других портов в принимаемой DRCPDU. Если TLV информации других портов не переносится в принимаемой DRCPDU, и топология портала содержит три портальные системы, DRF_Other_Neighbor_State задается как пустое (Other_Gateway задается как ложный, и список рабочих агрегированных портов в другой соседней портальной системе в этом 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 задаются как пустые, когда принимаемая DRCPDU не содержит TLV информации других портов.

[00706] Помимо этого, если совместное использование сетевой/IPL по времени поддерживается, функция записывает значение параметра для DRF_Home_Network/IPL_Sharing_Method, переносимого в принимаемом TLV способа совместного использования сетевой/IPL, в качестве текущего значения параметра для DRF_Neighbor_Network/IPL_Sharing_Method, и если оно является идентичным DRF_Home_Network/IPL_Sharing_Method системы, она задает CC_Time_Shared как истинный, иначе она задает CC_Time_Shared как ложный.

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

[00708] DRF_Neighbor_Network/IPL_Sharing_Method=DRF_Home_Network/IPL_Sharing_Method, переносимый в принимаемом TLV способа совместного использования сетевой/IPL;

DRF_Neighbor_Network/IPL_IPLEncap_Digest=DRF_Home_Network/IPL_IPLEncap_Digest, переносимый в принимаемом TLV совместного использования сетевой/IPL посредством инкапсуляции; и

DRF_Neighbor_Network/IPL_NetEncap_Digest=DRF_Home_Network/IPL_NetEncap_Digest, переносимый в принимаемом TLV совместного использования сетевой/IPL посредством инкапсуляции.

[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 как истинную;

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

[00717] она задает CC_EncTag_Shared как ложный.

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

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

[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_Portal_System_Number=DRF_Home_Conf_Neighbor_Portal_System_Number;

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; и

DRF_Neighbor_Conversation_GatewayList_Digest=DRF_Neighbor_Admin_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 задается как ложная;

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

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

[00744] recordPortalValues

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

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 задается как ложная;

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

[00757] переменная Differ_Portal задается как истинная, и ассоциированный набор переменных, имеющих различные значения, доступен в 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=aDrniGatewayAlgorithm;

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[], как если все шлюзы в портале сообщаются как ложные, и агрегированные порты в любой портальной системе не сообщаются как рабочие.

[00763] setGatewayConversation

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

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

[00766] setIPPGatewayConversation

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

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

[00769] setIPPGatewayUpdate

[00770] Эта функция задает IppGatewayUpdate в каждом IPP в этой портальной системе как истинную.

[00771] setIPPPortConversation

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

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

[00774] setIPPPortUpdate

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

[00776] setPortConversation

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

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

[00779] updateDRFHomeState

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

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

[00782] подключение не блокируется посредством работы управляющего сетевого протокола);

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

[00784] Помимо этого, если PSI == истинный и шлюз == ложный, то Actor_Oper_Port_State.Sync задается как ложная на всех агрегированных портах в этой портальной системе.

[00785] Функция также задает:

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

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

[00788] updateIPPGatewayConversationDirection

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

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

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

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

[00793] Помимо этого, если Drni_Gateway_Conversation и Ipp_Other_Gateway_Conversation являются рассогласованными для какого-либо идентификатора разговора по шлюзу:

[00794] Она задает DRF_Home_Oper_DRCP_State.Gateway_Sync как ложную и;

[00795] NTTDRCPDU как истинную.

[00796] Иначе:

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

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

[00799] updateIPPPortConversationPasses

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

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

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

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

[00804] Помимо этого, если Drni_Port_Conversation и Ipp_Other_Port_Conversation_Portal_System являются рассогласованными для какого-либо идентификатора разговора по порту:

[00805] Она задает DRF_Home_Oper_DRCP_State.Port_Sync как ложную и;

[00806] NTTDRCPDU как истинную.

[00807] Иначе:

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

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

[00811] updateKey

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

[00813] Если enable_long_pdu_xmit == истинный, то:

[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 как истинную, если любая из DRF_Home_Oper_DRCP_State.GatewaySync или DRF_Home_Oper_DRCP_State.PortSync, или DRF_Neighbor_Oper_DRCP_State.GatewaySync, или DRF_Neighbor_Oper_DRCP_State.PortSync является ложной.

[00817] updatePortalState

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

[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 задается как истинная в этом IPP.

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

[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 является ложным.

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

[00829] updatePortalSystemGatewayConversation

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

[00831] updatePortalSystemPortConversation

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

[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] IppM: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) отвечают за конфигурирование идентификаторов разговоров по шлюзу, которым разрешается проходить через шлюз этой DR-функции, и идентификаторов разговоров по порту, которым разрешается распределяться через агрегатор этой DR-функции. Эти машины состояний задаются в расчете на портальную систему.

[00850] DRNI IPP-машины (710) отвечают за конфигурирование идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, которым разрешается проходить через IPP этой DR-функции.

[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, то она должна переходить в состояние проверки совместимости (этап 809) для проверки посредством функции recordPortalConfValues. Она сравнивает административно сконфигурированные значения, которые ассоциированы с этим порталом, с принимаемой информацией, и если они отличаются, то система должна переходить в состояние REPORT_TO_MANAGEMENT (этап 810), и неправильно сконфигурированная DRCPDU должна сообщаться в систему управления. Машина приема выходит из состояния REPORT_TO_MANAGEMENT, когда новая DRCPDU принимается (или IPP деактивируется).

[00854] Если принимаемая DRCPDU сконфигурирована согласно предполагаемым значениям для этого портала, то машина приема должна переходить в текущее состояние (этап 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, которые не совпадают с административно сконфигурированными ожиданиями, в течение периода, более чем в два раза превышающего короткий тайм-аут, машина состояний должна переходить в установленное по умолчанию состояние, и текущие рабочие параметры для портальной системы в этом IPP должны перезаписываться с административно сконфигурированными значениями, и должно запускаться обновление портальной системы.

[00857] Если принимаемая DRCPDU сконфигурирована согласно предполагаемым значениям для этого портала, машина DRCPDU-приема переходит в текущее состояние.

[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 задается как истинная, если вид соседнего узла рабочей переменной состояния портала домашнего узла не является актуальным. Затем запускается таймер current_while. Значение, используемое для того, чтобы запускать таймер, составляет Short_Timeout_Time или Long_Timeout_Time, в зависимости от рабочего значения актора тайм-аута.

[00862] Если DRCPDU не принимается до того, как таймер current_while истекает, машина состояний переходит в истекшее состояние. DRF_Neighbor_Oper_DRCP_State.IPP_Activity задается как ложная, текущее рабочее значение переменной тайм-аута соседнего узла задается равным короткому тайм-ауту, и таймер current_while запускается со значением Short_Timeout_Time. Оно представляет собой переходное состояние; настройки тайм-аута дают возможность домашней портальной системе передавать DRCPDU быстро в попытке повторно устанавливать связь с соседним узлом.

[00863] Если DRCPDU не принимается до того, как таймер current_while истекает снова, машина состояний переходит в установленное по умолчанию состояние. Функция recordDefaultDRCPDU перезаписывает текущие рабочие параметры для соседних портальных систем с административно сконфигурированными значениями и запускает обновление портальной системы, и состояние сообщается в систему управления.

[00864] Если IPP становится нерабочим, машина состояний переходит в состояние инициализации. DRF_Neighbor_Oper_DRCP_State.IPP_Activity задается как ложная, функция recordDefaultDRCPDU инструктирует административным значениям параметров партнера использоваться в качестве текущих рабочих значений. Эти операции командуют PS-машине отсоединение соседних портальных систем от портала и повторное вычисление фильтров идентификаторов разговоров по шлюзу и по порту.

[00865] Машина приема также может реализовывать функцию, указываемую на фиг. 16, с ассоциированными параметрами. Машина приема на фиг. 16 следует нескольким различным трактам последовательности операций по сравнению с фиг. 8. Показатели и функции альтернативной машины приема на фиг. 16 являются аналогичными показателям и функциям по фиг. 8. Специалисты в данной области техники должны понимать, что другие реализации являются возможными согласно принципам и структурам проиллюстрированных машин приема.

[00866] Фиг. 33 иллюстрирует способ для синхронизации с соседним узлом в узле группы агрегирования DRNI-линий связи согласно варианту осуществления изобретения. Способ 3300 может реализовываться в DRCP-узле (например, в сетевом устройстве) DRCP-портала (называемого "локальным порталом") в качестве части DRNI, к примеру, как узлы K-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C. Отметим, что необязательные этапы обозначаются как пунктирный прямоугольник, как проиллюстрировано на фиг. 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 по ссылке с номером 3307. DRCPDU содержит PDU-структуру, проиллюстрированную на фиг. 5, причем PDU-структура имеет TLV, такие как 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), идентификатор агрегатора (например, 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). В этом состоянии, периодические передачи деактивируются, и функция stop_periodic_timer выполняется.

FAST_PERIODIC (этап 904). В этом состоянии, периодические передачи активируются на высокой скорости передачи. Переход в это состояние из непериодического состояния (этап 902) выполняется в ответ на безусловный переход (UCT). Небольшое периодическое состояние может переходить в состояние периодической передачи (этап 910) и длительное периодическое состояние (этап 905). Переход длительное в периодическое состояние 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, не periodic_timer и NTT, соответственно, как показано на фиг. 9), но последовательности операций являются идентичными в иных отношениях. Показатели и функции альтернативной машины передачи на фиг. 17 являются аналогичными показателям и функциям по фиг. 9. Специалисты в данной области техники должны понимать, что другие реализации являются возможными согласно принципам и структурам проиллюстрированных машин передачи.

[00886] Машина портальной системы

[00887] Машина портальной системы может реализовывать функцию, указываемую на фиг. 10, с ассоциированными параметрами, поясненными выше. Этот процесс может инициализироваться в состояние инициализации портальной системы (этап 1002). Функции setDefaultPortalSystemParameters и updateKey выполняются. В случае если либо ChangePortal, либо ChangeDRFPorts является истинной, процесс переходит в состояние обновления портальной системы (этап 1004). В состоянии обновления портальной системы, ChangePortal задается как ложная, ChangeDRFPorts задается как ложная, выполнение updateDRFhomestate и updatekey. Следующее обновление запускается, когда ChangePortal или ChangeDRFPorts обновляется как истинная.

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

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

[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-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C. Отметим, что необязательные этапы обозначаются как пунктирный прямоугольник, как проиллюстрировано на фиг. 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-функции узла, чтобы назначать кадры идентификаторам разговоров по порту (например, DRF_Home_Port_Algorithm), алгоритм для шлюза, используемый посредством DR-функции узла для того, чтобы назначать кадры идентификаторам разговоров по шлюзу (например, DRF_Home_Gateway_Algorithm) и т.д.

[00895] По ссылке с номером 3404, узел определяет то, что рабочее состояние, ассоциированное с порталом, изменяется. Изменение рабочего состояния может указываться посредством булевой переменной, которая задается как истинная, когда рабочее значение вида сетевого устройства значения IPP-операций соседнего сетевого устройства является активным. В одном варианте осуществления, такая переменная, как ChangePortal, поясненная выше, представляет собой такую булеву переменную. Изменение рабочего состояния также может указываться посредством булевой переменной, которая задается как истинная, когда рабочее состояние шлюза узла изменяется. Изменение рабочего состояния также может указываться посредством булевой переменной, которая задается как истинная, когда одно из рабочих состояний агрегированных портов узла, ассоциированного с первым порталом, изменяется. В одном варианте осуществления, такая переменная, как ChangeDRFPorts, поясненная выше, представляет собой такую булеву переменную для изменений рабочих состояний шлюза и агрегированных портов.

[00896] По ссылке с номером 3406 узел может задавать одну или более переменных, указывающих отсутствие изменения рабочего состояния, ассоциированного с порталом. В одном варианте осуществления, это выполняется посредством задания таких переменных, как ChangePortal и ChangeDRFPorts, как ложных, как проиллюстрировано на фиг. 10. Задание дает возможность дополнительных изменений триггерного обновления рабочего состояния ChangePortal и ChangeDRFPorts, так что узел может обнаруживать изменение.

[00897] По ссылке с номером 3408, узел обновляет набор рабочих состояний узла для агрегирования линий связи в ответ на изменение рабочего состояния, причем набор рабочих состояний включает в себя рабочее состояние шлюза для узла. В одном варианте осуществления, обновление выполняется через выполнение такой функции, как updateDRFHomeState, поясненная выше. В одном варианте осуществления, обновление также создает список рабочих агрегированных портов посредством включения только тех идентификаторов агрегированного порта, которые являются рабочими (например, присоединенный агрегатор сообщает их как имеющих Actor_Oper_Port_State.Distributing == истинный (условие, которое исключает случаи, в которых ассоциированные агрегированные порты либо являются нерабочими, либо находятся в истекшем состоянии, либо не в группе агрегирования линий связи)).

[00898] Способ предоставляет эффективный способ синхронизировать рабочие состояния DRCP-узла с соседним DRCP-узлом на основе изменений портала, которому принадлежит DRCP-узел.

[00899] Машина DRNI-шлюза и агрегатора

[00900] Машина DRNI-шлюза и агрегатора может реализовывать функцию, указываемую на фиг. 11, с ассоциированными параметрами, поясненными выше. В портальной системе существует две машины DRNI-шлюза и агрегатора. Каждая ассоциирована с типом идентификаторов разговоров: предусмотрен один для идентификаторов разговоров по шлюзу и один для идентификаторов разговоров по порту. Фиг. 11A является процессом DRNI-шлюза, который инициализируется в состоянии инициализации DRNI-шлюза (этап 1102). В этом состоянии, выполняется функция InitializeDRNIGatewayConversation, и GatewayCoversationUpdate задается как ложная, и если GatewayCoversationUpdate возникает, процесс переходит в состояние обновления DRNI-шлюза (этап 1104). В состоянии обновления DRNI-шлюза (этап 1104), процесс задает GatewayConversationUpdate как ложную, операции updatePortaState, setGatewayConversaion и setIPPGatewayUpdate выполняются, и updatePortalSystemGatewayConversation выполняется. Обновление DRNI-шлюза запускается при каждом возникновении GatewayConversationUpdate.

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

[00902] Фиг. 11B является процессом обновления 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] Эти машины состояний отвечают за конфигурирование идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, которым разрешается проходить через шлюз этой 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 активируется, чтобы идентифицировать портальную систему, которая отвечает за каждый идентификатор разговора по шлюзу, на основе согласованных приоритетов выбора и рабочего состояния шлюзов, как известно посредством этой портальной системы (на основе рабочего состояния локального шлюза и заявленного рабочего состояния соседних портальных систем собственных шлюзов, переносимых посредством последней DRCPDU, принимаемой из этих соседних портальных систем). В завершение, индексированный посредством идентификаторов разговоров по шлюзу булев вектор должен вычисляться на основе согласования между видом этой портальной системы для идентификаторов разговоров по шлюзу, которым разрешается проходить через шлюз портальной системы, и видом всех соседних узлов для идентификаторов разговоров по шлюзу, которым разрешается проходить через шлюз этой портальной системы [как заявлено через их DRCPDU и записывается посредством машины DRX-состояний этой портальной системы (фиг. 8)]. Это обеспечивает то, что идентификатору разговора по шлюзу не разрешается проходить через шлюз этой портальной системы, если согласование между всеми портальными системами не достигнуто.

[00906] Машина состояний инициализируется с отброшенными всеми идентификаторами разговоров по шлюзу и переходит в состояние DRNI_GATEWAY_UPDATE каждый раз, когда триггер GatewayConversationUpdate задается.

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

[00908] Фиг. 35 иллюстрирует способ для конфигурирования набора идентификаторов разговоров для агрегатора или шлюза в сетевом устройстве в распределенном отказоустойчивом межсетевом взаимодействии (DRNI) согласно варианту осуществления изобретения. Способ 3500 может реализовываться в DRCP-узле (например, в сетевом устройстве) DRCP-портала (называемого "локальным порталом") в качестве части DRNI, к примеру, как узлы K-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C. Отметим, что необязательные этапы обозначаются как пунктирный прямоугольник, как проиллюстрировано на фиг. 35.

[00909] По ссылке с номером 3502 узел инициализирует набор идентификаторов разговоров, и инициализация включает в себя задание записей булева вектора, ассоциированного с набором идентификаторов разговоров, в качестве последовательности нулей. Идентификаторы разговоров представляют собой идентификаторы разговоров по шлюзу или идентификаторы разговоров по порту. Булев вектор включает в себя значения, указывающие обработку набора идентификаторов разговоров через шлюз или агрегатор узла, которые задаются равными нулям (без обработки) посредством инициализации. Следует отметить, что DRCP-узел содержит один шлюз и один агрегатор.

[00910] Инициализация может выполняться посредством такой функции, как InitializeDRNIGatewayConversation и InitializeDRNIPortConversation, поясненные выше. Булев вектор может быть Drni_Portal_System_Gateway_Conversation или Drni_Portal_System_Port_Conversation для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно. В одном варианте осуществления, индикатор идентификатора разговора является булевым значением записи (например, "истинный" означает прохождение через шлюз или распределение через агрегатор). Инициализация задает все значения равными нулю и в силу этого как не проходящие.

[00911] По ссылке с номером 3504 узел определяет то, что распределение набора идентификаторов разговоров должно обновляться. В одном варианте осуществления, выполнение определения включает в себя проверку булевой переменной (например, переменных, к примеру, GatewayConversationUpdate и PortConversationUpdate, поясненных выше для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно).

[00912] По ссылке с номером 3506 узел задает значения рабочего вектора, индексированного посредством идентификаторов разговоров, причем рабочий вектор перечисляет то, какой узел портала обрабатывает каждый из набора идентификаторов разговоров. В одном варианте осуществления, рабочий вектор является Drni_Gateway_Converstaion и Drni_Port_Conversation для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно. Для идентификаторов разговоров по шлюзу, рабочий вектор перечисляет то, какой узел портала пропускает каждый идентификатор разговора по шлюзу. Для идентификаторов разговоров по порту, рабочий вектор перечисляет то, какой узел портала пропускает каждый идентификатор разговора по порту.

[00913] По ссылке с номером 3508, узел задает значения булева вектора, индексированного посредством идентификаторов разговоров, причем булев вектор перечисляет то, ассоциирован один шлюз или один агрегатор сетевого устройства с каждым из идентификаторов разговоров. Рабочий булев вектор может быть Drni_Portal_System_Gateway_Conversation или Drni_Portal_System_Port_Conversation для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно. Для идентификаторов разговоров по шлюзу каждая запись в булевом векторе указывает то, разрешается или нет идентификатору разговора по шлюзу проходить через один шлюз узла. Для идентификаторов разговоров по порту каждая запись в булевом векторе указывает то, разрешается или нет идентификатору разговора по порту распределяться через один агрегатор узла.

[00914] Затем необязательно по ссылке с номером 3510, узел обновляет рабочие состояния всех узлов портала. В одном варианте осуществления, обновление выполняется посредством такой функции, как updatePortalState, поясненная выше.

[00915] Также необязательно по ссылке с номером 3512, узел задает переменную, указывающую то, что распределение набора идентификаторов разговоров должно обновляться. В одном варианте осуществления, переменная является setIPPGatewayUpdate и setIPPPortupdate (поясненные выше) для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно.

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

[00917] DRNI IPP-машина

[00918] DRNI IPP-машина может реализовывать функцию, указываемую на фиг. 12A-B, со своими ассоциированными параметрами, поясненными выше. Фиг. 12A иллюстрирует машину состояний, чтобы обновлять разговор по IPP-шлюзу согласно одному варианту осуществления изобретения. Процесс начинается на этапе 1202, на котором инициализируется IPP-шлюз. В этом варианте осуществления, инициализация IPP-шлюза достигается через две функции инициализации. Через IPPGatewayUpdate = ложный, сетевое устройство задает триггеры обновления IPP-шлюза как ложные. Через функцию InitializeIPPPortConversation() сетевое устройство задает число прохождений разговоров (к примеру, Ipp_Gateway_Conversation_Direction) как последовательность нулей, индексированную снова посредством идентификатора разговора по шлюзу.

[00919] После инициализации, машина состояний переходит к этапу 1204, на котором обновляется IPP-шлюз. Передача представляет собой триггер посредством изменения переменной. Переменная, IppGatewayUpdate, указывает то, что распределения в расчете на идентификатор разговора по 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] Фиг. 12B иллюстрирует машину состояний, чтобы обновлять разговор по IPP-порту согласно одному варианту осуществления изобретения. Процесс для обновления IPP-порта является аналогичным процессу для обновления разговора по шлюзу, в силу чего процесс на фиг. 12B является аналогичным фиг. 12A, причем функции и переменные для IPP-портов используются для обновления разговора по IPP-порту.

[00922] Варианты осуществления этого процесса содержат этапы инициализации в состояние инициализации IPP-порта, инициализации триггера обновления IPP-порта как ложного, инициализации разговора по IPP-порту, перехода в состояние обновления IPP-порта в ответ на обнаружение того, что переменная обновления IPP-порта является истинной, задания разговора по порту, задания IPP-разговора, обновления числа прохождений разговоров по IPP-порту, задания переменной IppPortUpdate как ложной и возвращения в состояние обновления IPP-порта в ответ на обнаружение того, что PortConversationUpdate является истинной.

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

[00924] Для триггера из машины DRX-состояний (фиг. 8), объявляющего то, что IppGatewayUpdate задается как истинная, машина состояний переходит в состояние IPP_GATEWAY_UPDATE. Это инструктирует функции setGatewayConversation активироваться. Она идентифицирует портальную систему, которая отвечает за каждый идентификатор разговора по шлюзу на основе согласованных приоритетов выбора и рабочего состояния шлюзов, как известно посредством этой портальной системы (на основе рабочего состояния локального шлюза и заявленного рабочего состояния соседних узлов их собственных шлюзов, переносимых посредством последней DRCPDU, принимаемой из этих соседних узлов). Затем функция setIPPGatewayConversation идентифицирует портальную систему, которая отвечает за каждый идентификатор разговора по шлюзу на основе согласованных приоритетов выбора и рабочих состояний шлюзов, как заявлено посредством соседней портальной системы в этом IPP (на основе рабочего состояния шлюза соседней портальной системы и заявленного рабочего состояния соседней портальной системы для их вида для других шлюзов в портале, переносимым посредством последней DRCPDU, принимаемой из соседней портальной системы в этом IPP). Затем, индексированный посредством идентификаторов разговоров по шлюзу булев вектор должен вычисляться на основе согласования между видом этой портальной системы для идентификаторов разговоров по шлюзу, которым разрешается проходить через IPP портальной системы и видом IPP соседней портальной системы для идентификаторов разговоров по шлюзу, которым разрешается проходить через идентичный IPP [как заявлено через их DRCPDU и записывается посредством машины DRX-состояний этой портальной системы (фиг. 8)]. Это обеспечивает то, что идентификатору разговора по шлюзу не разрешается проходить через этот IPP, если согласование между этой портальной системой и ее соседней портальной системой не достигнуто. В завершение, IppGatewayUpdate сбрасывается на ложную.

[00925] Машина состояний инициализируется с отброшенными всеми идентификаторами разговоров по шлюзу и переходит в состояние IPP_GATEWAY_UPDATE каждый раз, когда триггер GatewayConversationUpdate задается.

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

[00927] Фиг. 36 иллюстрирует способ для конфигурирования набора идентификаторов разговоров для IPP в DRCP-узле в распределенном отказоустойчивом межсетевом взаимодействии (DRNI) согласно варианту осуществления изобретения. Способ 3600 может реализовываться в DRCP-узле (например, в сетевом устройстве) DRCP-портала (называемого "локальным порталом") в качестве части DRNI, к примеру, как узлы K-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C.

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

[00929] Инициализация может выполняться посредством такой функции, как InitializeIPPGatewayConversation и InitializeIPPPortConversation, поясненные выше. Булев вектор может быть Ipp_Gateway_Conversation_Direction или Ipp_Port_Conversation_Passes для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно. В одном варианте осуществления, значение для идентификатора разговора является булевым значением записи. Например, значение истинный для идентификатора разговора по шлюзу указывает то, что некоторый шлюз является достижимым через этот IPP. Инициализация задает все значения равными нулю и в силу этого как не проходящие.

[00930] По ссылке с номером 3604 узел определяет то, что распределение набора идентификаторов разговоров должно обновляться. В одном варианте осуществления, выполнение определения включает в себя проверку булевой переменной. В одном варианте осуществления, булева переменная является IppGatewayUpdate и IppPortUpdate для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно. В другом варианте осуществления, булевы переменные являются GatewayConversationUpdate и PortConversationUpdate для идентификаторов разговоров по шлюзу и идентификаторов разговоров по порту, соответственно.

[00931] По ссылке с номером 3606 узел задает значения первого рабочего вектора, индексированного посредством идентификаторов разговоров, причем рабочий вектор перечисляет то, какой узел портала обрабатывает каждый из идентификаторов разговоров, как назначено посредством узла. В одном варианте осуществления, узел задает значения через функции, к примеру, setGatewayConversation и setPortConversation, чтобы задавать первый рабочий вектор, к примеру, Drni_Gateway_Conversation и Drni_Port_Conversation, соответственно. Для идентификаторов разговоров по шлюзу Drni_Gateway_Conversation перечисляет то, шлюз какого узла (если имеются) пропускает каждый идентификатор разговора по шлюзу. Для идентификаторов разговоров по порту Drni_Port_Conversation перечисляет то, какой узел пропускает каждый идентификатор разговоров по порту.

[00932] По ссылке с номером 3608 узел задает значения второго рабочего вектора, индексированного посредством идентификаторов разговоров, причем рабочий вектор перечисляет то, какой узел портала обрабатывает каждый из идентификаторов разговоров, как назначено посредством соседнего узла. В одном варианте осуществления, узел задает значения через функции, к примеру, setIPPGatewayConversation и setIPPPortConversation, чтобы задавать второй рабочий вектор, к примеру, Ipp_Other_Gateway_Conversation и Ipp_Other_Port_Conversation_Portal_System, соответственно. Как пояснено выше в данном документе, для идентификаторов разговоров по шлюзу, Ipp_Other_Gateway_Conversation перечисляет то, какой узел (т.е. портальная система) (если таковые имеются) пропускает каждый идентификатор разговора по шлюзу, как назначено посредством соседнего узла в этом IPP, причем соседний узел представляет собой ближайший соседний узел, когда портал содержит более двух узлов. Аналогично, для идентификаторов разговоров по порту, Ipp_Other_Port_Conversation_Portal_System перечисляет то, какой узел пропускает каждый идентификатор разговора по порту, как назначено посредством ближайшего соседнего узла в этом IPP.

[00933] По ссылке с номером 3610, узел задает значения булева вектора, индексированного посредством идентификаторов разговоров, причем булев вектор перечисляет то, ассоциирован или нет IPP узла с каждым из идентификаторов разговоров. В одном варианте осуществления, булев вектор является Ipp_Gateway_Conversation_Direction для идентификаторов разговоров по шлюзу и Ipp_Port_Conversation_Passes для идентификаторов разговоров по порту, как пояснено выше в данном документе.

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

[00935] Машина передачи

[00936] Когда машина передачи (не проиллюстрирована) создает DRCPDU для передачи, она может заполнять следующие поля с соответствующими рабочими значениями для этого IPP согласно одному варианту осуществления изобретения:

[00937] - Идентификатор и приоритет агрегатора.

- Идентификатор и приоритет портала.

- Номер портальной системы.

- Состояние топологии.

- Рабочий ключ агрегатора.

- Алгоритм для порта.

- Алгоритм для шлюза.

- Дайджест порта.

- Дайджест шлюза.

- DRCP-состояние.

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

[00938] Когда периодическая машина находится в непериодическом состоянии, машина передачи должна:

- Не передавать любые DRCPDU, и

- Задавать значение NTTDRCPDU как ложное.

[00939] Когда переменная DRCP_Enabled является истинной, и переменная NTTDRCPDU является истинной, машина передачи может обеспечивать то, что надлежащим образом форматируемая DRCPDU передается [т.е. выдавать примитив DRCPCtrlMuxN:M_UNITDATA.Request (DRCPDU) услуг] согласно такому ограничению, что не более чем конкретное число LACPDU может передаваться в любом интервале Fast_Periodic_Time. Конкретное число может варьироваться в зависимости от реализации (например, десять или двадцать). Если NTTDRCPDU задается как истинная, когда этот предел имеет силу, передача может задерживаться до тех пор, пока такое время в качестве ограничения более не будет иметь силу. Переменная NTTDRCPDU может задаваться как ложная, когда машина передачи передает DRCPDU.

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

[00941] Когда переменная DRCP_Enabled является ложной, машина передачи не может передавать DRCPDU и может задавать значение NTTDRCPDU как ложное.

[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 как истинную (что указывает то, что соседняя портальная система в этом IPP также сконфигурирована для работы на основе совместного использования сетевой/IPL по времени). Система остается в состоянии TIME_SHARED_METHOD до тех пор, пока принимаемая DRCPDU не задаст CC_Time_Shared как ложный, что запускает переход состояния в состояние NO_MANIPULATED_FRAMES_SENT, и IPL-кадры отправляются по выделенной физической линии связи.

[00950] Аналогично, если домашняя портальная система сконфигурирована для режима работы на основе совместного использования сетевой/IPL по тегу или совместного использования сетевой/IPL посредством инкапсуляции, как указано посредством значения в aDrniEncapsulationMethod, то система должна переходить в MANIPULATED_FRAMES_SENT, если машина DRX-состояний (DRX - фиг. 8) задает CC_EncTag_Shared как истинную (что указывает то, что соседняя портальная система в этом IPP также сконфигурирована для режима работы на основе совместного использования сетевой/IPL по тегу или совместного использования сетевой/IPL посредством инкапсуляции, соответственно). Система остается в состоянии MANIPULATED_FRAMES_SENT до тех пор, пока принимаемая DRCPDU не задаст CC_EncTag_Shared как ложный, что запускает переход состояния в состояние NO_MANIPULATED_FRAMES_SENT, и IPL-кадры отправляются по выделенной физической линии связи.

[00951] Фиг. 31 иллюстрирует способ для совместного использования сетевой/IPL в узле согласно варианту осуществления изобретения. Способ 3100 может реализовываться в DRCP-узле (также называемом "портальной системой" портала, например, сетевого устройства) DRCP-портала (называемого "локальным порталом") в качестве части DRNI, к примеру, как узлы K-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C. Отметим, что необязательный этап обозначается как пунктирный прямоугольник, как проиллюстрировано на фиг. 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-состояние должно быть согласованным для системы, чтобы работать надлежащим образом. На фиг. 1C, согласованность проще поддерживать. Ссылаясь на фиг. 1C, линия связи между сетевым устройством 130 и сетевым устройством 134 представляет собой рабочую линию связи (линию 172 связи), а линия связи между сетевым устройством 130 и сетевым устройством 132 представляет собой защитную линию связи (линию 174 связи) для услуги. IPL-линия связи (не показана) между сетевыми устройствами 134 и 132 сохраняет их DRCP-состояние в синхронизации. С точки зрения сетевого устройства 130 (портала 142 с одним узлом), оно соединяется с одной системой (порталом 144), и информация относительно сетевых устройств 132 или 134 по отдельности явно не передается в сетевое устройство 130.

[00957] Когда IPL-линия связи между сетевыми устройствами 132 и 134 становится нерабочей, оба сетевых устройства 134 (в данный момент рабочий узел) и 132 (в данный момент защитный узел) пытаются брать на себя функции узла, передающего трафик, поскольку с их соответствующей точки зрения, неработающим надлежащим образом является соседний узел. Сетевое устройство 132, в качестве защитного узла, обновляет свой идентификатор 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) узла (причем узел представляет собой узел-партнер). Рабочий ключ агрегатора-партнера передается в DRCPDU. В одном варианте осуществления, рабочий ключ агрегатора-партнера сохраняется в переменной, называемой DRF_Home_Oper_Partner_Aggregator_Key, которая задается как рабочий ключ агрегатора-партнера, ассоциированный с идентификатором LAG сетевого устройства (узла портала), поясненного выше. Другой представляет собой рабочий ключ для каждой из портальных систем-партнеров в портале-партнере. Рабочий ключ соседнего портала также ассоциирован с идентификатором LAG узла (причем узел представляет собой соседний узел). Рабочие ключи соседних (ближайших или удаленных соседних) порталов передаются в 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, линия K-M связи представляет собой рабочую линию связи, и линия L-O связи представляет собой защитную линию связи. IPL-линия связи существует между узлами K и L и M и O, чтобы сохранять их DRCP-состояние в синхронизации.

[00961] Когда IPL-линия связи между M сетевых узлов и O становится нерабочей, оба узла M (в данный момент рабочий узел) и O (в данный момент защитный узел) для услуги пытаются брать на себя функции узла, передающего трафик, поскольку с их соответствующей точки зрения, неработающим является соседний узел. Узел O, в качестве защитного узла, должен обновлять свой идентификатор LAG во избежание наличия ситуации, когда обе линии K-M и L-O связи переносят дублированный трафик. В портале 112 узлы K и L должны независимо принимать решения касательно того, следует отбрасывать или разрешать трафик на линиях K-M и L-O связи. Решение может приниматься через обмен DRCPDU между соседними узлами в одном варианте осуществления. Помимо этого, логика выбора, применяемая посредством каждого узла, может модифицироваться, чтобы принимать передаваемую информацию во внимание. Узлы K и L могут обновляться таким образом, что они разрешают трафику проходить через их ассоциированные линии K-M и L-O связи, соответственно, только тогда, когда их рабочий ключ агрегатора-партнера является наименьшим значением из набора значений, включающего в себя рабочий ключ агрегатора-партнера и рабочий ключ(и) соседнего портала. Для выбора, чтобы работать, узел O в качестве защитного узла может обновлять свое значение рабочего ключа (в одном варианте осуществления, значение рабочего ключа обновляется с использованием функции обновления, такой как функция updateKey, поясненная выше), когда он обновляет свой идентификатор LAG.

[00962] Фиг. 19 иллюстрирует операции DRCP-узла при потере связи со своим соседним узлом согласно одному варианту осуществления изобретения. Способ может реализовываться в любом DRCP-узле, соединенном с одним или более соседних узлов. На 1902, DRCP-узел определяет то, что он более не поддерживает связь со своим соседним узлом(ами). Потеря связи может быть обусловлена деактивацией или неправильным функционированием IPP либо деактивацией или неправильным функционированием соседнего узла. На 1904, DRCP-узел затем определяет то, что он представляет собой узел, в данный момент не переносящий трафик. Отметим, что DRCP-узел может выступать в качестве рабочего или защитного узла портала для услуги. Если DRCP-узел представляет собой рабочий узел, дальнейшие действия не требуются, он должен продолжать перенос активного трафика. Если DRCP-узел представляет собой защитный узел, способ переходит к 1906, на котором DRCP-узел обновляет свой рабочий ключ и переносит активный трафик. Обновленный рабочий ключ задается равным наименьшему числовому ненулевому значению набора, содержащего значения ключа этого узла (например, Admin_Aggregator_Key этого узла), ключа соседнего узла (например, the_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-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C, причем узел соединяется с одним или более соседних узлов. На 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] Фиг. 26A иллюстрирует TLV масок разговоров для агрегированного порта согласно одному варианту осуществления изобретения. Отметим, что TLV масок разговоров является идентичным TLV масок разговоров, проиллюстрированному на фиг. 4A заявки на патент (США) № 14/135556, которая полностью содержится в данном документе по ссылке, как указано в данном документе. Фиг. 26B иллюстрирует поле состояний масок разговоров в TLV масок разговоров агрегированного порта согласно одному варианту осуществления изобретения. Фиг. 26B отличается от фиг. 4B заявки на патент (США) № 14/135556 тем, что одно поле, PSI (изолированное состояние портала) по ссылке с номером 2611 заменяет зарезервированный бит. Этот флаг является применимым только для портальных систем и используется для того, чтобы указывать то, изолирована или нет портальная система от других портальных систем в портале. Истинный (кодируется как 1), если DRF_Neighbor_Oper_DRCP_State.IPP_Activity==ложный во всех IPP в этой портальной системе. Его значение иначе является ложным (кодируется как 0).

[00974] Помимо этого, функция ReceivedConversationMaskTLV, раскрытая в заявке на патент (США) № 14/135556, может обновляться с помощью следующей дополнительной операции: она также записывает значение параметра для PSI, переносимого в принимаемой маске разговора по порту, в качестве текущих значений рабочих параметров для Partner_PSI.

[00975] Кроме того, функция upddateConversationMaskTLV, раскрытая в заявке на патент (США) № 14/135556, может обновляться с помощью следующей дополнительной операции: Если эта функция реализуется посредством портальной DRCP-системы, при этом ее значение DRF_Portal_System_Number задано равным значению, которое отличается от 1, ее идентификатор системы портала задан равным значению, которое является численно меньше идентификатора системы партнера, и PSI==Partner_PSI==истинный, то Comp_Oper_Conversation_Mask задается как пустая.

[00976] Например, ссылаясь на фиг. 1B, когда происходит сбой обеих IPL в K/L и M/O, все узлы должны передавать трафик: активные узлы K и M передают трафик, поскольку они представляют собой активные узлы, и защитные узлы L и M также передают трафик, поскольку они изолированы от активных узлов и теперь считают себя активными. Когда PSI поддерживается в обоих порталах 112 и 114, PSI и принимаемое PSI партнера должны быть истинными. При условии, что портал 112 представляет собой портал с более высоким приоритетом (например, идентификатор системы портала 112 ниже идентификатора системы портала 114, в силу чего его приоритет является более высоким), то узел L определяет то, что его номер портальной системы (при условии равенства 2, поскольку он представляет собой двухузловой портал, и рабочий узел K имеет номер портальной системы 1) не является наименьшим, он обновляет свою рабочую маску разговора на пустую, и он не передает или принимает трафик.

[00977] Фиг. 28 иллюстрирует работу DRCP-узла при сбое связи согласно одному варианту осуществления изобретения. Способ 2800 может реализовываться в DRCP-узле (например, в сетевом устройстве) DRCP-портала (называемого "локальным порталом") в качестве части DRNI, к примеру, как узлы K-O по фиг. 1B и сетевые устройства 132 и 134 по фиг. 1C. На 2802, DRCP-узел определяет то, что он более не поддерживает связь со своим соседним узлом(ами). Потеря связи может быть обусловлена деактивацией или неправильным функционированием IPP либо деактивацией или неправильным функционированием соседнего узла. Потеря связи может указываться в PSI-бите, заданном как истинный (который отправляется через TLV в LACPDU, поясненной выше), в одном варианте осуществления.

[00978] На 2804, узел определяет то, что его узел-партнер более не поддерживает связь с соседним узлом партнера. Узел-партнер может отправлять свое PSI-состояние через свою LACPDU, и PSI записывается посредством функции recordReceivedConversationMaskTLV партнера. Когда узел-партнер более не поддерживает связь со своим соседним узлом, принимаемое PSI-состояние должно задаваться как истинное, в этом случае PSI==Partner_PSI=="истинное".

[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. DRNI-функции 1311, описанные выше в данном документе, выполняются посредством сетевого процессора 1311.

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

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

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

- определяют (2802) то, какое сетевое устройство более не обменивается данными с соседним сетевым устройством;

- определяют (2804) то, какое сетевое устройство-партнер более не обменивается данными с соседним сетевым устройством для сетевого устройства-партнера;

- определяют (2806) то, что первый портал имеет более высокий приоритет портала, чем второй портал, при этом каждому порталу назначается приоритет портала;

- определяют (2808) то, что сетевое устройство имеет более низкий приоритет сетевого устройства, чем соседнее сетевое устройство, при этом каждому сетевому устройству назначается приоритет сетевого устройства; и

- прекращают (2810) передачу и прием кадров группы агрегирования линий связи в сетевом устройстве.

2. Способ по п. 1, в котором сетевое устройство, более не обменивающееся данными с соседним сетевым устройством, инструктирует сетевому устройству отправлять протокольную единицу данных управления агрегированием линий связи (LACPDU), включающую в себя тип/длину/значение масок разговоров по порту (TLV), содержащий индикатор состояния портала, называемый "изолированная портальная система" (PSI), при этом PSI указывает состояние отсутствия связи.

3. Способ по п. 2, в котором PSI является булевым значением, и при этом булево значение задается как истинное, когда IPP определяется как неактивный.

4. Способ по любому из пп. 1-3, в котором определение того, что сетевое устройство-партнер более не обменивается данными с соседним сетевым устройством для сетевого устройства-партнера, содержит этап, на котором:

- проверяют принимаемый TLV масок разговоров по порту, содержащий PSI, указывающее состояние отсутствия связи для сетевого устройства-партнера.

5. Способ по любому из пп. 1-3, в котором определение первого портала, имеющего более высокий приоритет портала, чем второй портал, содержит этапы, на которых:

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

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

6. Способ по любому из пп. 1-3, в котором определение того, что сетевое устройство имеет более низкий приоритет сетевого устройства, чем соседнее сетевое устройство, содержит этапы, на которых:

- сравнивают номер портальной системы сетевого устройства с номером портальной системы соседнего сетевого устройства; и

- определяют то, что номер портальной системы сетевого устройства выше номера портальной системы соседнего сетевого устройства.

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

- порты (1340), соединенные с физической или агрегированной линией связи из группы агрегирования линий связи;

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

8. Сетевое устройство по п. 7, при этом сетевое устройство, более не обменивающееся данными с соседним сетевым устройством, должно инструктировать сетевому устройству отправлять протокольную единицу данных управления агрегированием линий связи (LACPDU), включающую в себя тип/длину/значение масок разговоров по порту (TLV), содержащий индикатор состояния портала, называемый "изолированная портальная система" (PSI), и при этом PSI должно указывать состояние отсутствия связи.

9. Сетевое устройство по п. 8, в котором PSI является булевым значением, и при этом булево значение задается как истинное, когда IPP определяется как неактивный.

10. Сетевое устройство по любому из пп. 7-9, в котором DRNI-функция выполнена с возможностью определять то, что сетевое устройство-партнер более не обменивается данными с соседним сетевым устройством для сетевого устройства-партнера, через:

- проверку принимаемого TLV масок разговоров по порту, содержащего PSI, указывающее состояние отсутствия связи для сетевого устройства-партнера.

11. Сетевое устройство по любому из пп. 7-9, в котором DRNI-функция выполнена с возможностью определять то, что первый портал имеет более высокий приоритет портала, чем второй портал, через:

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

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

12. Сетевое устройство по любому из пп. 7-9, в котором DRNI-функция выполнена с возможностью определять то, что сетевое устройство имеет более низкий приоритет сетевого устройства, чем соседнее сетевое устройство, через:

- сравнение номера портальной системы сетевого устройства с номером портальной системы соседнего сетевого устройства; и

- определение того, что номер портальной системы сетевого устройства выше номера портальной системы соседнего сетевого устройства.

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

- определение (2802) того, какое сетевое устройство более не обменивается данными с соседним сетевым устройством;

- определение (2804) того, какое сетевое устройство-партнер более не обменивается данными с соседним сетевым устройством для сетевого устройства-партнера;

- определение (2806) того, что первый портал имеет более высокий приоритет портала, чем второй портал, при этом каждому порталу назначается приоритет портала;

- определение (2808) того, что сетевое устройство имеет более низкий приоритет сетевого устройства, чем соседнее сетевое устройство, при этом каждому сетевому устройству назначается приоритет сетевого устройства; и

- прекращение (2810) передачи и приема кадров группы агрегирования линий связи в сетевом устройстве.

14. Энергонезависимый машиночитаемый носитель хранения данных по п. 13, в котором сетевое устройство, более не обменивающееся данными с соседним сетевым устройством, инструктирует сетевому устройству отправлять протокольную единицу данных управления агрегированием линий связи (LACPDU), включающую в себя тип/длину/значение масок разговоров по порту (TLV), содержащий индикатор состояния портала, называемый "изолированная портальная система" (PSI), при этом PSI указывает состояние отсутствия связи.

15. Энергонезависимый машиночитаемый носитель хранения данных по п. 14, в котором PSI является булевым значением, и при этом булево значение задается как истинное, когда IPP определяется как неактивный.

16. Энергонезависимый машиночитаемый носитель хранения данных по любому из пп. 13-15, в котором определение того, что сетевое устройство-партнер более не обменивается данными с соседним сетевым устройством для сетевого устройства-партнера, содержит:

- проверку принимаемого TLV масок разговоров по порту, содержащего PSI, указывающее состояние отсутствия связи для сетевого устройства-партнера.

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

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

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

18. Энергонезависимый машиночитаемый носитель хранения данных по любому из пп. 13-15, в котором определение того, что сетевое устройство имеет более низкий приоритет сетевого устройства, чем соседнее сетевое устройство, содержит:

- сравнение номера портальной системы сетевого устройства с номером портальной системы соседнего сетевого устройства; и

- определение того, что номер портальной системы сетевого устройства выше номера портальной системы соседнего сетевого устройства.

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

- определяют (2702) то, что сетевое устройство принимает трафик из сетевого устройства-партнера;

- определяют (2704) то, что сетевое устройство соединяется с соседним сетевым устройством в первом портале группы агрегирования линий связи;

- определяют (2706) то, что рабочий ключ, принимаемый из сетевого устройства-партнера, обновлен;

- определяют (2708) то, какое сетевое устройство более не обменивается данными с соседним сетевым устройством; и

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

20. Способ по п. 19, в котором определение того, что рабочий ключ, принимаемый из сетевого устройства-партнера, обновлен, содержит этапы, на которых:

- определяют то, что старшие два бита принимаемого рабочего ключа партнера указывают значение 2 или 3; и

- определяют то, что младшие два бита приоритета рабочего порта-партнера агрегированного порта указывают значение 2 или 3.

21. Способ по п. 19 или 20, в котором определение того, что первый портал имеет более высокий приоритет портала, содержит этапы, на которых:

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

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

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

- порты (1340), соединенные с физической или агрегированной линией связи из группы агрегирования линий связи; и

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

23. Сетевое устройство по п. 22, в котором DRNI-функция выполнена с возможностью определять то, что рабочий ключ, принимаемый из сетевого устройства-партнера, обновлен, через:

- определение того, что старшие два бита принимаемого рабочего ключа партнера указывают значение 2 или 3; и

- определение того, что младшие два бита приоритета рабочего порта-партнера агрегированного порта указывают значение 2 или 3.

24. Сетевое устройство по п. 22 или 23, в котором DRNI-функция выполнена с возможностью определять то, что первый портал имеет более высокий приоритет портала, через:

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

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

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

- определение (2702) того, что сетевое устройство принимает трафик из сетевого устройства-партнера;

- определение (2704) того, что сетевое устройство соединяется с соседним сетевым устройством в первом портале группы агрегирования линий связи;

- определение (2706) того, что рабочий ключ, принимаемый из сетевого устройства-партнера, обновлен;

- определение (2708) того, что сетевое устройство более не обменивается данными с соседним сетевым устройством; и

- прекращение (2710) передачи и приема кадров группы агрегирования линий связи в сетевом устройстве после определения того, что первый портал имеет более высокий приоритет портала, чем второй портал, при этом каждому порталу назначается приоритет портала.

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

- определение того, что старшие два бита принимаемого рабочего ключа партнера указывают значение 2 или 3; и

- определение того, что младшие два бита приоритета рабочего порта-партнера агрегированного порта указывают значение 2 или 3.

27. Энергонезависимый машиночитаемый носитель хранения данных по п. 25 или 26, в котором определение того, что первый портал имеет более высокий приоритет портала, содержит:

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

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