ГОСТ Р ИСО/МЭК 10038-99
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ
ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СЕТИ
МОСТЫ НА ПОДУРОВНЕ УПРАВЛЕНИЯ ДОСТУПОМ К СРЕДЕ
Information technology. Telecommunications and information exchange between
systems. Local area networks. Media access control (MAC) bridges
ОКС 35.110
ОКСТУ 4002
Дата введения 2000-07-01
Предисловие
1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Комитета при Президенте Российской Федерации по политике информатизации
ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 7 октября 1999 г. N 331-ст
Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10038-93 "Информационная технология. Передача данных и обмен информацией между системами. Локальные вычислительные сети. Мосты на подуровне управления доступом к среде"
3 ВВЕДЕН ВПЕРВЫЕ
1 Общие положения
1 Общие положения
Локальные вычислительные сети (ЛВС) любых типов могут быть объединены вместе с помощью мостов на подуровне управления доступом к среде (мостов УДС). Каждая отдельная ЛВС имеет свой собственный независимый подуровень УДС. Создание мостовой ЛВС позволяет взаимодействовать станциям, подключенным к отдельным ЛВС, так, как если бы они были подключены к одной ЛВС. Мосты УДС выполняют операции ниже границы услуг УДС, и они прозрачны для протоколов, функционирующих выше этой границы на подуровне управления логическим звеном (УЛЗ) по ГОСТ 28907 и на сетевом уровне по ГОСТ Р ИСО/МЭК 7498-1. Мостовая ЛВС может обеспечивать:
1) взаимосвязь станций, подключенных к ЛВС различных типов;
2) эффективное увеличение физической протяженности, числа допустимых подключений и суммарной производительности ЛВС;
3) разделение физической ЛВС по административным или эксплуатационным соображениям.
1.1 Область применения
Для совместимого взаимодействия оборудования обработки данных, которое использует услуги подуровня УДС, предоставляемые взаимосвязанными стандартными ЛВС с различными или одинаковыми методами управления доступом к среде, настоящий стандарт определяет общий метод работы мостов УДС. С этой целью стандарт:
1) определяет место мостовой функции в рамках архитектурного описания подуровня УДС;
2) определяет принципы работы моста УДС с точки зрения обеспечения и сохранения услуг УДС и поддержки качества этих услуг;
3) определяет внутренние услуги подуровня УДС, предоставляемые отдельными ЛВС для функций, не зависимых от метода доступа к среде, которые обеспечивают ретрансляцию кадров мостом;
4) идентифицирует функции, которые должен выполнять мост, и обеспечивает архитектурную модель внутренних операций моста в терминах процессов и логических объектов, обеспечивающих эти функции;
5) устанавливает требования к протоколу взаимодействия мостов мостовых ЛВС для организации сети и определяет метод распределенного вычисления активной топологии покрывающего дерева;
6) определяет кодирование протокольных блоков данных моста (ПБДМ);
7) устанавливает требования к административному управлению мостом в мостовых ЛВС, идентифицируя администрируемые объекты и определяя операции административного управления;
8) определяет способ доступа удаленного диспетчера к операциям административного управления, используя описание протокола и архитектуры, приведенное в ТЕЕЕ Std 802.1B;
9) устанавливает требования к соответствию, рекомендуемые значения по умолчанию и допустимые диапазоны рабочих параметров моста;
10) устанавливает требования к оборудованию, претендующему на соответствие настоящему стандарту;
11) определяет критерии использования специфичных для УДС методов работы моста.
Настоящий стандарт определяет операции мостов УДС, которые подключены непосредственно к ЛВС, как определено в соответствующих стандартных или практически реализованных технологиях УДС. Несмотря на то, что волоконно-оптический распределенный интерфейс передачи данных (ВОРИПД) в сети кольцевого типа с маркерным доступом, определенный в ГОСТ Р 50452, не входит в семейство стандартных ЛВС, он может рассматриваться как эквивалент УДС. Если не оговорено иное, то ссылки в настоящем стандарте на стандартные ЛВС подразумевают и ВОРИПД.
Определение удаленных мостов ЛВС, использующих для передачи кадров между мостами среду глобальной вычислительной сети (ГВС), не входит в предмет рассмотрения настоящего стандарта.
1.2 Нормативные ссылки
Настоящий стандарт содержит ссылки на следующие стандарты. Ссылки на стандарты IEEE или ANSI являются справочными и приведены в приложении Е.
ГОСТ 34.913.3-91 (ИСО/МЭК 8802-3-92) Информационная технология. Локальные вычислительные сети. Метод случайного доступа к шине (КДОН/ОК) и спецификация физического уровня
ГОСТ 34.913.4-91 (ИСО/МЭК 8802-4-90) Информационная технология. Локальные вычислительные сети. Метод маркерного доступа к шине и спецификация физического уровня
ГОСТ 34.936-91 (ИСО 10039-91) Информационная технология. Локальные вычислительные сети. Определение услуг уровня управления доступом к среде
ГОСТ 28907-91 (ИСО 8802-2-89) Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных
ГОСТ Р 50452-92 (ИСО 9314-1-89) Системы обработки информации. Волоконно-оптический распределенный интерфейс передачи данных (ВОРИПД). Часть 1. Протокол физического уровня кольца с маркерным доступом.
ГОСТ Р ИСО/МЭК 8802-5-99 Информационная технология. Локальные и региональные вычислительные сети. Часть 5. Метод доступа к кольцу с передачей маркера и спецификация физического уровня
ГОСТ Р ИСО/МЭК 8824-93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)
ГОСТ Р ИСО/МЭК 8825-93 Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии один (АСН.1)
ГОСТ Р ИСО/МЭК 9595-99 Информационная технология. Взаимосвязь открытых систем. Определение общих услуг административного управления
ИСО 6937-2-83* Информационная технология. Набор кодированных знаков для передачи текста. Графические знаки латинского и нелатинского алфавита
ИСО 9314-2-89* Системы обработки информации. Волоконно-оптический распределенный интерфейс передачи данных (ВОРИПД). Часть 2. Уровень управления доступом к среде (УДС) кольца с маркерным доступом ВОРИПД
ИСО/МЭК 9596-90* Системы обработки информации. Взаимосвязь открытых систем. Спецификация протокола общего административного управления
ИСО/МЭК 10178-92* Информационная технология. Передача данных и обмен информацией между системами. Структура и кодирование адресов подуровня управления логическим звеном в локальных вычислительных сетях.
______________________
* Международные стандарты ИСО/МЭК - во ВНИИКИ Госстандарта России.
1.3 Определения
Для настоящего стандарта специфично следующее определение:
мостовая локальная вычислительная сеть: Цепочка отдельных ЛВС, взаимосвязанных мостами УДС.
1.4 Сокращения
Для настоящего стандарта специфично следующее сокращение:
ПБДМ - протокольный блок данных моста.
1.5 Соответствие
Мост УДС, претендующий на соответствие настоящему стандарту:
1) должен удовлетворять:
a) соответствующим стандартным или реализованным технологиям УДС, таким как ГОСТ 34.913.3, ГОСТ 34.913.4, ГОСТ Р ИСО/МЭК 8802-5 или ИСО 9314-2, как изложено в 2.5, и
b) ГОСТ 28907 для реализации УЛЗ класса I или II при обеспечении операций типа 1 согласно требованиям подразделов 3.2, 3.3 и 3.12;
2) должен осуществлять ретрансляцию и фильтрацию кадров согласно 3.1, 3.5-3.7;
3) должен либо:
а) отфильтровывать кадры с одинаковыми адресами отправителя и получателя, либо
b) не отфильтровывать кадры с одинаковыми адресами отправителя и получателя, как описано 3.7;
4) может обеспечивать возможность управления преобразованием приоритетов продвигаемых кадров согласно 3.7;
5) должен сохранять информацию, требуемую для принятия решения о необходимости фильтрации кадров, согласно 3.1, 3.8 и 3.9;
6) должен использовать установленные значения следующих параметров базы данных фильтрации (см. 3.9):
а) размер базы данных фильтрации - максимальное число возможных содержащихся в ней записей,
b) размер постоянной базы данных - максимальное число возможных содержащихся в ней записей;
7) может обеспечивать возможности чтения и обновления базы данных фильтрации и постоянной базы данных согласно 3.9;
8) может обеспечивать возможности установления времени существования сообщения согласно 3.9. Мост, который обеспечивает эту возможность, должен реализовывать полный диапазон значений, определенных в таблице 3-3;
9) должен обеспечивать возможности адресации, определенные в 3.12;
10) может реализовывать факультативные возможности адресации административного управления моста, определенные в 3.12.4, для логической увязки адреса моста с портом моста согласно 3.12.5 и для реконфигурации групповых адресов в постоянной базе данных согласно 3.12.6;
11) должен обеспечивать:
a) средства назначения групповых адресов УДС с целью идентификации логического объекта протокола моста, если не используется 48-битовая универсально администрируемая адресация,
b) средства назначения уникальных адресов в пределах мостовой ЛВС с целью уникальной идентификации моста в случае использования 16-битовой локально администрируемой адресации согласно 4.5 и
c) индивидуальный идентификатор порта для каждого порта моста согласно 4.5 и в соответствии с требованиями подраздела 4.2 к алгоритму и протоколу покрывающего дерева;
12) должен реализовывать алгоритм и протокол покрывающего дерева, описанный в разделе 4, согласно 4.7;
13) не должен превышать значений, приведенных в 4.10.2, для следующих параметров:
a) максимальная мостовая транзитная задержка,
b) максимальная переоценка приращения времени существования сообщения,
c) максимальная задержка передаваемого ПБДМ;
14) должен использовать значения, приведенные в таблице 4-3 для параметра "время захвата";
15) может обеспечивать присвоение значений следующим параметрам с учетом конфигурации активной топологии покрывающего дерева:
a) приоритет моста,
b) приоритет порта,
с) стоимость пути для каждого порта. Мост, который обеспечивает эту возможность, должен реализовывать диапазон значений, определенных в 4.10.2 и таблицах 4-4 и 4-5;
16) может обеспечивать возможность установления значений следующих параметров алгоритма и протокола покрывающего дерева:
a) максимальное мостовое время существования сообщения,
b) мостовое время заявки,
c) мостовая задержка продвижения.
Мост, который обеспечивает эту возможность, должен реализовывать диапазон значений, определенных в 4.10.2 и таблице 4-3;
17) должен кодировать передаваемые ПБДМ и объявлять действительными принимаемые ПБДМ, как определено в разделе 5;
18) может обеспечивать административное управление мостом.
Мосты, претендующие на обеспечение административного управления, должны поддерживать все объекты и операции административного управления, определенные в разделе 6.
19) может обеспечивать удаленное административное управление, стандартизованное IEEE Std 802.1В. Мосты, претендующие на обеспечение удаленного административного управления согласно IEEE Std 802.1В, должны:
a) соответствовать стандарту IEEE Std 802.1B,
b) обеспечивать удаленные операции административного управления путем использования операций сетевого административного управления и кодирования, определенных в разделе 7;
20) должен определять гарантированный коэффициент фильтрации порта для каждого порта, гарантированный коэффициент ретрансляции моста и устанавливать соотношение между временными интервалами Т и Т, определенными в разделе 8. Операции моста в рамках специфицированных параметров не должны нарушать ни одного из требований, предъявляемых настоящим стандартом.
Поставщик реализации, претендующей на соответствие настоящему стандарту, должен заполнить копию формы ЗСРП, приведенной в приложении А, и представить информацию, необходимую для идентификации как поставщика, так и реализации.
1.6 Рекомендации
1.6.1 Административное управление
Настоятельно рекомендуется обеспечение объектов и операций административного управления, определенных в разделе 6.
1.7 Специфичные для УДС мостовые методы
Могут существовать специфичные для подуровня УДС методы организации мостов. Использование специфичного для УДС мостового метода и метода, определенного настоящим стандартом, на одной и той же ЛВС должно:
1) не препятствовать взаимосвязи между станциями мостовой ЛВС;
2) сохранять услуги и УДС;
3) сохранять характеристики каждого мостового метода в пределах своего региона;
4) обеспечивать возможность одновременного сосуществования обоих мостовых технологий в ЛВС без каких-либо неблагоприятных влияний друг на друга.
2 Обеспечение услуг УДС
Мосты УДС взаимоувязывают отдельные ЛВС, образуя ЛВС путем ретрансляции кадров между подуровнями УДС отдельных мостовых ЛВС. Место мостовой функции в подуровне УДС показано на рисунке 2.1.
Рисунок 2.1 - Внутренняя организация подуровня УДС
Рисунок 2.1 - Внутренняя организация подуровня УДС
Услуги УДС предоставляются их пользователю на оконечной станции и поддерживаются функцией ретрансляции моста. Это позволяет исключать требования, специфичные для отдельных методов доступа к среде.
В данном разделе рассматриваются вопросы предоставления услуг УДС оконечным станциям, поддержка услуг УДС мостами, сохранение услуг УДС, обеспечиваемых мостовой ЛВС, поддержание качества услуг в мостовой ЛВС и обеспечение внутренних услуг подуровня, предоставляемых для самих мостов с целью подключения отдельных ЛВС.
2.1 Общие положения
Услуги УДС, предоставляемые оконечным станциям мостовой ЛВС, обеспечиваются мостами УДС этой мостовой ЛВС. Мосты выдают примитивы УД-БЛОК-ДАННЫХ запрос и соответствующие примитивы УД-БЛОК-ДАННЫХ индикация, переносящие данные пользователя, без выдачи на них подтверждений. Услуги подтверждения оконечными станциями, взаимодействующими через мост, не обеспечиваются.
Стиль выполнения операций моста увеличивает доступность услуг УДС для оконечных станций и облегчает эксплуатацию мостовой ЛВС.
Поэтому желательно наделить мосты способностью организовывать мостовую ЛВС таким образом, чтобы:
1) можно было обеспечить резервные пути между оконечными станциями, позволяющими мостовой ЛВС продолжать предоставление своих услуг в случае выхода из строя какой-либо ее компоненты (моста или ЛВС);
2) можно было прогнозировать и автоматически изменять пути между оконечными станциями при заданной доступности к компонентам мостовой ЛВС.
2.2 Постоянство услуг УДС
Услуги подуровня УДС, предоставляемые мостовой ЛВС, которая состоит из отдельных соединенных мостами ЛВС, такие же, как и услуги отдельной ЛВС. Благодаря этой особенности:
1) мост непосредственно не адресуется взаимодействующими оконечными станциями, за исключением случаев, когда оконечная станция используется для целей административного управления: кадры, передаваемые между оконечными станциями, переносят в своем поле "адрес получателя" адрес УДС равноправной оконечной станции, а не адрес моста (при его наличии);
2) все адреса УДС должны быть уникальными и назначаться в пределах мостовой ЛВС;
3) адреса УДС оконечной станции не ограничиваются топологией и конфигурацией мостовой ЛВС.
2.3 Обеспечение качества услуг
Качество услуг УДС, обеспечиваемое мостом, не должно быть значительно ниже качества, обеспечиваемого отдельной ЛВС. Подлежат рассмотрению те параметры качества услуг, которые имеют отношение к:
1) доступности услуг;
2) потере кадров;
3) нарушению последовательности кадров;
4) дублированию кадров;
5) транзитной задержке, испытываемой кадром;
6) времени существования кадра;
7) коэффициенту необнаруженных ошибок в кадре;
8) обеспечиваемому максимальному размеру сервисного блока данных;
9) приоритету пользователя и
10) пропускной способности.
2.3.1 Доступность услуг
Подуровень УДС предоставляет услуги УДС оконечным станциям, подключенным к ЛВС или мостовой ЛВС. Доступность услуг измеряется как часть некоторого общего времени, в течение которого предоставляется услуга. Работа моста может увеличить или снизить доступность услуг.
Доступность услуг может быть увеличена путем автоматической реконфигурации мостовой ЛВС с целью обхода неисправной компоненты (например передатчика, кабеля или соединителя) на пути данных. Доступность услуг может быть снижена неисправностью самого моста по причине отклонения услуги или отфильтровывания кадров мостом.
В случае автоматической реконфигурации мост может отклонить услугу и аннулировать кадры (см. 2.3.2) с целью сохранения других аспектов услуг УДС (см. 2.3.3, 2.3.4). Услуги могут быть отклонены оконечной станцией, которая не получает преимуществ от реконфигурации; следовательно, доступность услуг для таких оконечных станций снижается. Мосты могут отфильтровывать кадры для локализации трафика в мостовой ЛВС. Как только оконечная станция изменит свое местоположение, она может оказаться неспособной принимать кадры от других оконечных станций до тех пор, пока не будет обновлена информация о фильтрации, хранимая мостом.
В мосту должны быть предусмотрены соответствующие меры по увеличению доступности услуг, исключению потерь услуг или задержек в предоставлении услуг, за исключением ситуаций, возникающих в результате неисправностей, удаления или подсоединения компонент мостовой ЛВС, или в результате перемены местоположения оконечной станции. Эти ситуации считаются экстраординарными событиями. Таким образом, операции любого дополнительного протокола, необходимые для поддержания качества услуг, ограничиваются конфигурацией мостовой ЛВС и не зависят от конкретных случаев обеспечения услуг.
2.3.2 Потеря кадров
Услуги, предоставляемые подуровнем УЛС, не гарантируют доставку сервисных блоков данных. Кадры, передаваемые станцией-отправителем, с высокой вероятностью поступают без искажений на станцию - получатель. Работа моста вносит минимальную дополнительную потерю кадров.
Кадры, передаваемые станцией - отправителем, могут поступать на станцию - получатель поврежденными в результате:
1) искажения кадра на физическом уровне в процессе передачи или приема;
2) аннулирования кадра мостом в случае:
a) невозможности передать его в течение некоторого максимального времени, в результате чего требуется удалить кадр, чтобы предотвратить превышение максимального времени существования кадра (см. 2.3.6),
b) невозможности сохранять кадр вследствие исчерпания емкости внутреннего буфера, например кадры, подлежащие хранению, прибывают со скоростью, превышающей скорость их возможной дальнейшей передачи,
c) когда размер сервисного блока данных, переносимого кадром, превышает максимальный, поддерживаемый процедурами УДС, реализуемыми в той ЛВС, в которую должен ретранслироваться кадр,
d) изменений в объединенной топологии мостовой ЛВС, вынуждающих аннулировать кадры в течение ограниченного периода времени, чтобы сохранить другие аспекты качества услуг.
2.3.3 Нарушение последовательности кадров
Услуги, обеспечиваемые подуровнем УДС, не допускают нарушения последовательности передачи кадров с заданным приоритетом пользователя. Сервисный примитив УД-БЛОК-ДАННЫХ индикация, соответствующий примитиву УД-БЛОК-ДАННЫХ запрос с тем же запрошенным приоритетом, должен приниматься в той же последовательности, в которой обрабатывался соответствующий примитив запроса. Работа моста не должна приводить к нарушению последовательности кадров, передаваемых с одним и тем же приоритетом пользователя.
В случае, когда мосты в мостовой ЛВС способны соединить отдельные УДС таким образом, что между любой парой отправитель - получатель может образоваться множество путей, протокол должен обеспечить исключение такой возможности.
2.3.4 Дублирование кадров
Услуги, обеспечиваемые подуровнем УДС, не допускают дублирования кадров. Работа моста не приводит к дублированию кадров данных пользователя.
Возможность дублирования кадров в мостовой ЛВС возникает вследствие возможного дублирования принимаемых кадров при последующих передачах в пределах моста или вследствие возникновения множества путей между оконечными станциями - отправителем и получателем.
Мосты не должны дублировать кадры данных пользователя.
2.3.5 Транзитная задержка
Услуги, предоставляемые подуровнем УДС, вносят транзитную задержку кадра, которая зависит от особенностей физической среды и используемого метода управления доступом к среде. Транзитная задержка кадра представляет собой время, прошедшее между выдачей примитива УД-БЛОК-ДАННЫХ запрос и выдачей соответствующего примитива УД-БЛОК-ДАННЫХ индикация. Значение истекшего времени вычисляется только для успешно переданных сервисных блоков данных.
Поскольку услуги УДС обеспечиваются в абстрактном интерфейсе оконечной станции, то не представляется возможным точно определить общую транзитную задержку кадра. Однако можно измерить те компоненты задержки, которые связаны с доступом к среде или с передачей и приемом кадра; может быть также измерена транзитная задержка, вносимая промежуточной системой, в данном случае мостом.
Минимальная дополнительная транзитная задержка, вносимая мостом, представляет собой время, затрачиваемое на прием кадра, плюс время, затрачиваемое на доступ к физической среде, в которую предполагается ретранслировать кадр. Заметим, что кадр должен быть принят полностью прежде, чем он будет ретранслирован, поскольку должна быть вычислена контрольная последовательность кадра (КПК) и в случае ошибки кадр должен быть аннулирован.
2.3.6 Время существования кадра
Услуги, обеспечиваемые подуровнем УДС, гарантируют наличие для каждого отдельного сеанса взаимосвязи верхней границы транзитной задержки. Это максимальное время существования кадра устанавливается для гарантии правильной работы протоколов вышерасположенных уровней. Дополнительная транзитная задержка, вносимая мостом, рассмотрена выше.
Для того, чтобы выдержать максимальное время существования кадра, мосту может потребоваться аннулировать некоторые другие кадры. Поскольку информация, предоставляемая мосту подуровнем УДС, не содержит значения транзитной задержки, которой подвергается любой отдельный кадр, мосты должны аннулировать кадры, чтобы не превысить максимальную задержку в каждом мосту.
Значение максимальной мостовой транзитной задержки основано как на максимальной задержке, налагаемой всеми мостами мостовой ЛВС, так и на требуемом максимальном времени существования кадра. Рекомендуемое и абсолютное максимальное значения транзитной задержки указаны в таблице 4-2.
2.3.7 Коэффициент необнаруженных ошибок кадра
Услуги, предоставляемые подуровнем УДС, вносят в передаваемые кадры очень незначительный коэффициент необнаруженных ошибок. Защита от необнаруженных ошибок осуществляется путем использования КПК, которая присоединяется к кадру подуровнем УДС станции - отправителя перед передачей и проверяется станцией - получателем при приеме.
Вычисленная КПК для данного сервисного блока данных зависит от используемого метода управления доступом к среде. Поэтому необходимо повторно вычислять КПК внутри моста, обеспечивающего функцию ретрансляции между стандартными УДС различных типов. Это вносит вероятность дополнительных необнаруженных ошибок, возникающих в процессе работы моста. Для кадров, ретранслируемых между ЛВС одного и того же типа УДС, мосты не должны превышать коэффициент необнаруженных ошибок кадра, выше того, который был бы достигнут при сохранении КПК неизменной.
2.3.8 Максимальный размер сервисного блока данных
Максимальный размер сервисного блока данных, который может быть обеспечен ЛВС, меняется в зависимости от метода управления доступом к среде и его соответствующих параметров (быстродействия и др.). Он может быть ограничен владельцем ЛВС.
Этот размер, обеспечиваемый мостом между двумя ЛВС, меньше размера, обеспечиваемого отдельными ЛВС. Мост не должен пытаться выполнять ретрансляцию кадра в ЛВС, которая не обеспечивает размер сервисного блока данных, переносимого данным кадром.
2.3.9 Приоритет
К услугам, обеспечиваемым подуровнем УДС, относится приоритет пользователя, рассматриваемый как параметр качества услуг. Примитив УД-БЛОК-ДАННЫХ запрос с более высоким приоритетом может преобладать над остальными примитивами запроса, выдаваемыми на той же станции, или в других станциях, подключенных к той же ЛВС, и может обгонять предшествующие примитивы УД-БЛОК-ДАННЫХ индикация.
Подуровень УДС преобразует запрашиваемые приоритеты пользователя в приоритеты, обеспечиваемые отдельными методами управления доступа к среде. Запрошенный приоритет пользователя может быть передан на станцию-получатель.
Поскольку мост не должен изменять последовательность кадров, создаваемых из примитивов УД-БЛОК-ДАННЫХ запрос одинакового приоритета, то преобразование приоритетов должно быть статическим.
2.3.10 Пропускная способность
Общая пропускная способность, обеспечиваемая мостовой ЛВС, может быть значительно выше, чем обеспечиваемая эквивалентной отдельной ЛВС. Мосты могут локализовать трафик внутри мостовой ЛВС путем фильтрации кадров.
Пропускная способность между оконечными станциями отдельных ЛВС, взаимодействующих через мост, может быть снижена путем аннулирования кадров в мосту из-за невозможности передавать их в течение длительного периода с требуемой скоростью в ЛВС, расположенную на пути к получателю.
2.4 Внутренние услуги подуровня, обеспечиваемые внутри моста УДС
Внутренние услуги подуровня, предоставляемые объектами УДС логическому объекту ретрансляции УДС внутри моста, - это те услуги, которые предоставляются отдельными независимыми УДС. Мост наблюдает за соответствующими процедурами УДС и протоколом каждой ЛВС, с которой он соединен. Никакие кадры управления (известные также как кадры УДС), руководящие работой отдельной ЛВС, не выдаются из ЛВС - источника этих кадров.
Внутренние услуги подуровня образуются из услуг УДС, стандартизованных ГОСТ 34.936, путем добавления данной спецификации с элементами, необходимыми для выполнения функций ретрансляции. В подключенной оконечной станции эти дополнительные элементы могут рассматриваться либо ниже границы услуг УДС и относиться только к операциям поставщика услуг, либо как локальные вопросы, не имеющие отношения к равноправным взаимоотношениям услуг УДС. К перечню параметров, относящихся к примитивам УД-БЛОК-ДАННЫХ запрос и УД-БЛОК-ДАННЫХ индикация, определенным в ГОСТ 34.936, добавляются три параметра: "тип кадра", "действие УДС" и "контрольная последовательность кадра". Определение внутренних услуг подуровня не добавляет никаких новых сервисных примитивов к примитивам, определенным в ГОСТ 34.936.
Внутренние услуги подуровня не содержат специфичных для УДС средств и процедур, работа которых ограничена в рамках отдельных ЛВС. К примитивам услуги БЛОК-ДАННЫХ, описывающих данную услугу, относятся следующие:
УД-БЛОК-ДАННЫХ индикация (
| тип кадра, | ||||
| действие удс, | ||||
| адрес получателя, | ||||
| адрес отправителя, | ||||
| сервисный блок данных удс, | ||||
| приоритет пользователя, | ||||
| контрольная последовательность кадра | ||||
| ) | ||||
Каждый привлекаемый примитив индикации соответствует приему кадра УДС из отдельной ЛВС.
Параметр "тип кадра" указывает класс кадра. Этот параметр принимает одно из следующих значений: кадр данных пользователя, специфичный кадр удс или зарезервированный кадр.
Параметр "действие удс" указывает действие, запрошенное от логического объекта УДС, получившего примитив индикации. Если параметр "тип кадра" имеет значение "кадр данных пользователя", то параметр "действие удс" принимает одно из следующих значений: "запрос с ответом", "запрос без ответа" или "ответ". Для значений "специфичный кадр удс" и "зарезервированный кадр" этот параметр не применяется.
Параметр "адрес получателя" представляет собой либо адрес отдельного логического объекта УДС, либо адрес группы логических объектов УДС.
Параметр "адрес отправителя" - это индивидуальный адрес логического объекта УДС - отправителя.
Параметр "сервисный блок данных удс" содержит сервисный блок данных.
Параметр "приоритет пользователя" представляет собой приоритет, запрошенный инициирующим пользователем услуг. Значение этого параметра, если оно специфицировано, находится в диапазоне от 0 (наименьшее) до 7 (наибольшее).
Параметр "контрольная последовательность кадра" явно обеспечивается как параметр примитива таким образом, чтобы его можно было использовать без перерасчетов в качестве параметра соответствующего примитива запроса.
Идентификация ЛВС, из которой получены конкретные кадры, является локальным вопросом и не выражается в параметрах сервисных примитивов.
УДБЛОКДАННЫХ запрос (
| тип кадра, | ||||
| действие удс, | ||||
| адрес получателя, | ||||
| адрес отправителя, | ||||
| сервисный блок данных удс, | ||||
| приоритет пользователя, | ||||
|
| приоритет доступа | |||
| контрольная последовательность кадра | ||||
| ) | ||||
Примитив запроса привлекается для передачи кадра в отдельную ЛВС.
Параметр "тип кадра" указывает класс кадра.
Параметр "действие удс" указывает действие, требуемое от логического объекта УДС.
Параметр "адрес получателя" представляет собой либо адрес отдельного логического объекта УДС, либо группы логических объектов УДС.
Параметр "адрес отправителя" содержит индивидуальный адрес логического объекта УДС - отправителя.
Параметр "сервисный блок данных удс" содержит сервисный блок данных.
Параметр "приоритет пользователя" представляет собой приоритет, запрошенный инициирующим пользователем услуг. Значение этого параметра, если оно специфицировано, находится в диапазоне от 0 (наименьшее) до 7 (наибольшее).
Параметр "приоритет доступа" представляет собой приоритет, используемый локальным поставщиком услуг для передачи запроса. Он может использоваться для определения приоритета подлежащих передаче кадров, поставленных в очередь локальным логическим объектом УДС как локально, так и среди других станций, подключенных к одной и той же отдельной ЛВС (если такую возможность допускает метод доступа к среде). Значение этого параметра, если оно специфицировано, находится в диапазоне от 0 (наименьшее) до 7 (наибольшее).
Параметр "контрольная последовательность кадра" явно предусматривается как параметр примитива, с тем чтобы он мог быть использован без пересчета.
Идентификация ЛВС, в которую передается кадр, является локальным вопросом и не выражается в параметрах сервисных примитивов.
2.5 Поддержка внутренних услуг подуровня специфичными для УДС процедурами
В этом подразделе определяется преобразование внутренних услуг подуровня УДС в протокол и процедуры УДС каждого отдельного стандартного типа УДС и кодирование параметров услуг в кадрах УДС. Преобразование осуществляется путем ссылок на стандарты по ЛВС, которые определяют отдельные методы доступа к среде. В вопросах этих преобразований обращают внимание на все специальные виды ответственности мостов, подключенных к ЛВС данного типа УДС.
2.5.1 Обеспечение услуг ЛВС КДОН/ОК по ГОСТ 34.913.3
Коллективный метод доступа с опознаванием несущей и обнаружением конфликтов (КДОН/ОК) определен в ГОСТ 34.913.3. В разделе 3 настоящего стандарта определена структура кадра УДС, а в разделе 4 - сам метод управления доступом к среде.
При приеме примитива УД-БЛОК-ДАННЫХ запрос локальный логический объект УДС выполняет компоновку передаваемых данных и формирует кадр, используя предоставляемые параметры в соответствии с изложенным ниже. Перед вручением кадра передающей компоненте "административное управление доступом к среде" подуровня УДС для его передачи он присоединяет преамбулу и начальный ограничитель кадра (см. 4.2.3 ГОСТ 34.913.3).
При получении кадра УДС приемной компонентой "административное управление доступом к среде" он направляется компоненте "раскомпоновка принимаемых данных", которая проверяет действительность КПК и расформировывает кадр, как определено ниже, на параметры, которые поставляются с примитивом УД-БЛОК-ДАННЫХ индикация (см. 4.2.4 ГОСТ 34.913.3).
Параметр "тип кадра" принимает единственное значение "кадр данных пользователя" и явно не кодируется в кадре УДС.
Параметр "действие удс" принимает единственное значение "запрос без ответа" и явно не кодируется в кадре УДС.
Параметр "адрес получателя" преобразуется в поле "адрес получателя" кадра УДС (см. 3.2.3 ГОСТ 34.913.3).
Параметр "адрес отправителя" преобразуется в поле "адрес отправителя" кадра УДС (см. 3.2.3 ГОСТ 34.913.3).
Число октетов в параметре "сервисный блок данных удс" преобразуется в поле "длина" кадра УДС (см. 3.2.6 ГОСТ 34.913.3), а октеты данных кодируются в поле "данные" (см. 3.2.7 ГОСТ 34.913.3).
Параметр "приоритет пользователя" не кодируется в кадре УДС и принимает неопределенное значение в соответствующем примитиве УД-БЛОК-ДАННЫХ индикация.
Параметр "контрольная последовательность кадра" преобразуется в поле КПК кадра УДС (см. 3.2.8 ГОСТ 34.913.3). КПК вычисляется как функция содержимого полей "адрес получателя", "адрес отправителя", "длина", "данные" и "заполнитель". Следовательно, этот параметр переносит также значение поля "заполнитель", необходимый для удовлетворения требований минимального размера кадра (см. 3.2.73 ГОСТ 34.913.3). Если примитив УД-БЛОК-ДАННЫХ запрос не сопровождается этим параметром, КПК вычисляется в соответствии с 3.2.8 ГОСТ 34.913.3.
Для обеспечения внутренних услуг подуровня УДС методом доступа КДОН/ОК никаких специальных действий, помимо тех, которые определены для использования услуг УДС подуровнем УЛЗ, не требуется.
2.5.2 Обеспечение услуг ЛВС по ГОСТ 34.913.4 (маркерный метод доступа к шине)
Маркерный метод доступа к шине определен в ГОСТ 34.913.4. В разделе 4 настоящего стандарта определены форматы кадра, в разделе 5 обсуждаются базовые концепции протокола доступа, а в разделе 7 дано определение спецификации операций УДС ЛВС шинного типа с маркерным доступом.
При получении примитива УД-БЛОК-ДАННЫХ запрос интерфейсный конечный автомат (ИНТ-КА) локального логического объекта УДС ставит в очередь кадр для его передачи конечным автоматом управления доступом (УД-КА) (см. раздел 7 ГОСТ 34.913.4). При передаче кадра его поля устанавливаются с использованием предоставляемых параметров, как определено ниже, и добавляются поля "преамбула", "начальный ограничитель" и "конечный ограничитель" (см. раздел 4 ГОСТ 34.913.4).
При получении приемным конечным автоматом (ПМ-КА) действительного кадра УДС (см. 7.1.5 ГОСТ 34.913.4) генерируется примитив УД-БЛОК-ДАННЫХ индикация с параметрами, полученными из полей кадра, как определено ниже.
Параметр "тип кадра" кодируется в битах FF (битовые позиции 1 и 2) поля "управление кадра" (см. 4.1.3.1 и 4.1.3.2 ГОСТ 34.913.4). Битовая комбинация 01 означает "кадр данных пользователя", битовая комбинация 00 или 10 - "специфичный кадр удс", а битовая комбинация 11 - "зарезервированный кадр".
Параметр "действие удс" кодируется битами МММ (битовые позиции 3-5) поля "управление кадра" (см. 4.1.3.2 ГОСТ 34.913.4). Для "кадра данных пользователя" они принимают значение 000 при "запросе без ответа", 001 - при "запросе с ответом" и 010 - при "ответе".
Параметр "адрес получателя" преобразуется в поле "адрес получателя" кадра УДС (см. 4.1.4.1 ГОСТ 34.913.4).
Параметр "адрес отправителя" преобразуется в поле "адрес отправителя" кадра УДС (см. 4.1.4.2 ГОСТ 34.913.4).
Параметр "сервисный блок данных удс" преобразуется в поле "блок данных УДС" (см. 4.1.5 ГОСТ 34.913.4).
Параметр "приоритет пользователя" кодируется битами РРР (битовые позиции 6-8) поля "управление кадра" (см. 4.1.3.2 и 5.1.7 ГОСТ 34.913.4).
Параметр "контрольная последовательность кадра" преобразуется в поле КПК кадра УДС (см. 4.1.6 ГОСТ 34.913.4). КПК вычисляется как функция содержимого полей "управление кадра", "адрес получателя", "адрес отправителя" и "данные". Если примитив УД-БЛОК-ДАННЫХ запрос не сопровождается этим параметром, КПК вычисляется в соответствии с 4.1.6 ГОСТ 34.913.4.
Для обеспечения внутренних услуг подуровня УДС маркерным методом доступа к шине никаких специальных действий, помимо тех, которые определены для использования услуг УДС подуровнем УЛЗ, не требуется.
2.5.3 Обеспечение услуг ЛВС по ГОСТ Р ИСО/МЭК 8802-5 (маркерный метод доступа к кольцу)
Маркерный метод доступа к кольцу определен в ГОСТ Р ИСО/МЭК 8802-5. В разделе 3 настоящего стандарта определены форматы и услуги, а в разделе 4 - протокол маркерного метода доступа к кольцу.
При получении примитива УД-БЛОК-ДАННЫХ запрос локальный логический объект УДС формирует кадр, используя поставляемые параметры, как определено ниже, добавляя к данным пользователя поля "управление кадра", "адрес получателя", "адрес отправителя" и КПК, и ставит его в очередь для передачи при получении приемлемого маркера (см. 4.1.1 ГОСТ Р ИСО/МЭК 8802-5). При передаче кадра к нему добавляются поля "начальный ограничитель", "управление доступом", "конечный ограничитель" и "состояние кадра".
При получении действительного кадра УДС (см. 4.1.4 ГОСТ Р ИСО/МЭК 8802-5), который не передавался локальным логическим объектом УДС порта моста, с битом "указатель информации маршрутизации" (занимающим ту же позицию в поле "адрес отправителя", что и бит "групповой адрес" в поле "адрес получателя") в значении ноль генерируется примитив УД-БЛОК-ДАННЫХ индикация с параметрами, полученными из полей кадра, как определено ниже.
Параметр "тип кадра" кодируется битами типа кадра (биты FF) поля "управление кадра" (см. 3.2.3.1 ГОСТ Р ИСО/МЭК 8802-5). Битовая комбинация 01 указывает "кадр данных пользователя", битовая комбинация 00 или 10 - "специфичный кадр удс" и битовая комбинация 11 - "зарезервированный кадр".
Параметр "действие удс" принимает единственное значение "запрос без ответа" и явно не кодируется в кадре УДС.
Параметр "адрес получателя" преобразуется в поле "адрес получателя" кадра УДС (см. 3.2.4.1 ГОСТ Р ИСО/МЭК 8802-5).
Параметр "адрес отправителя" преобразуется в поле "адрес отправителя" кадра УДС (см. 3.2.4.2 ГОСТ Р ИСО/МЭК 8802-5).
Параметр "сервисный блок данных удс" преобразуется в поле "информация" (см. 3.2.6 ГОСТ Р ИСО/МЭК 8802-5).
Параметр "приоритет пользователя", связанный с "кадром данных пользователя", кодируется битами YYY поля "управление кадра" (см. 3.2.3 ГОСТ Р ИСО/МЭК 8802-5).
Параметр "контрольная последовательность кадра" преобразуется в поле КПК кадра УДС (см. 3.2.7 ГОСТ Р ИСО/МЭК 8802-5). КПК вычисляется как функция содержимого полей "управление кадра", "адрес получателя", "адрес отправителя" и "информация". Если примитив УД-БЛОК-ДАННЫХ запрос не сопровождается этим параметром, КПК вычисляется в соответствии с 3.2.7 ГОСТ Р ИСО/МЭК 8802-5.
Биты "распознавание адреса" (А) в поле "состояние кадра" (см. 3.2.9 ГОСТ Р ИСО/МЭК 8802-5) могут быть установлены в значение 1, если сгенерирован примитив УД-БЛОК-ДАННЫХ индикация с параметрами "тип кадра" и "действие удс" в значениях "кадр данных пользователя" и "запрос без ответа" соответственно или если бы такая индикация была сгенерирована при наличии достаточной емкости буферной памяти; в противном случае биты А не должны устанавливаться, за исключением случаев, оговоренных в ГОСТ Р ИСО/МЭК 8802-5.
Если биты А установлены в 1, биты "копирования кадра" (С) также могут быть установлены в 1 для отражения доступности приемных буферов; в противном случае биты С не должны устанавливаться.
Для обеспечения внутренних услуг подуровня УДС мост с маркерным методом доступа к кольцу должен быть способен распознавать и удалять кадры, передаваемые самому себе, даже если они могут содержать адрес отправителя, отличный от того порта моста, который передавал их.
2.5.4 Обеспечение услуг волоконно-оптическим интерфейсом передачи данных (ВОРИПД)
Метод доступа ВОРИПД определен в ГОСТ Р 50452 и ИСО 9314-2. В разделе 6 настоящего стандарта определены услуги, а в разделах 7 и 8 - средства и операции, соответственно.
При получении действительного кадра (см. 8.3.1 ИСО 9314-2), который не передавался локальным логическим объектом УДС порта моста, с первым битом адреса отправителя, равным нулю, генерируется примитив УД-БЛОК-ДАННЫХ индикация. Параметры этого примитива вырабатываются из полей кадра, как изложено ниже.
Указатель "адрес опознан" (А) поля "состояние кадра" кадра (см. 7.3.8 ИСО 9314-2) в кольце, из которого он был получен, не должен устанавливаться, за исключением случаев, оговоренных в ИСО 9314-2. Указатель "кадр скопирован" (С) (см. 7.3.8 ИСО 9314-2) может быть установлен, если сгенерирован примитив УД-БЛОК-ДАННЫХ индикация с параметрами "тип кадра" и "действие удс" в значениях "кадр данных пользователя" и "запрос без ответа", соответственно, если кадр должен продвигаться и если доступен приемный буфер. В противном случае указатель С не должен устанавливаться, за исключением ситуаций, оговоренных в ИСО 9314-2.
Примечания
1 Изложенные выше требования по установке указателя С мостами УДС дополняют требования ИСО 9314-2 и рассматриваются в рабочей группе ANSI ASC X3T9.5 под названием УДС-2. Однако стандарт IEEE Std. 802.ID не требует выполнения всех функций УДС-2 или полного соответствия УДС-2.
2 Согласно требованиям ИСО 9314-2 мосты могут изменять указатели А и/или С при получении кадра, адресованного мосту как оконечной станции ВОРИПД, или кадра, относящегося к операциям УДС ВОРИПД.
К параметрам, связанным с примитивом УД-БЛОК-ДАННЫХ индикация, который генерируется при получении кадра, в настоящее время относятся следующие.
Параметр "тип-кадра" кодируется битами формата кадра (биты CL, FF и ZZZZ) поля "управление кадра" (см. 7.3.3 ИСО 9314-2). Комбинация битов 0L01rXXX означает "кадр данных пользователя" (асинхронный кадр УЛЗ, где бит L означает длину адреса и может принимать значение 0 или 1; бит r является резервным и может принимать значение 0 или 1; и биты XXX могут принимать значения от 000 до 111). Все остальные битовые комбинации образуют значение "не кадр данных пользователя" параметра "тип кадра".
Параметр "действие удс" принимает единственное значение "запрос без ответа" и явно не кодируется в кадре УДС.
Параметр "адрес получателя" преобразуется в поле "адрес получателя" кадра УДС (см. 7.3.4, 7.3.4.1 ИСО 9314-2).
Параметр "адрес отправителя" преобразуется в поле "адрес отправителя" кадра УДС (см. 7.3.4.2 ИСО 9314-2).
Параметр "сервисный блок данных удс" преобразуется в поле "информация" (см. 7.3.5 ИСО 9314-2).
Параметр "приоритет пользователя", относящийся к "кадрам данных пользователя", кодируется битами РРР в поле "управление кадра" (см. 7.3.3.4 ИСО 9314-2), если кадр является асинхронно передаваемым кадром УЛЗ, поле которого "управление кадра" имеет значение 0L010PPP, где бит L означает длину адреса (см. 7.3.3.2 ИСО 9314-2).
Параметр "контрольная последовательность кадра" преобразуется в поле "контрольная последовательность кадра" кадра УДС (см. 7.3.6 ИСО 9314-2). КПК вычисляется как функция содержимого полей "управление кадра", "адрес получателя", "адрес отправителя" и "информация".
При получении примитива УД-БЛОК-ДАННЫХ запрос локальный логический объект УДС формирует кадр, используя обеспечиваемые параметры, как определено выше, добавляет к данным пользователя поля "управление кадра", "адрес получателя", "адрес отправителя" и "контрольная последовательность кадра" и ставит кадр в очередь на передачу при получении приемлемого маркера (см. 8.3.1 ИСО 9314-2). При передаче кадра к нему присоединяются поля "преамбула", "начальный ограничитель", "конечный ограничитель" и "состояние кадра".
Если примитив УД-БЛОК-ДАННЫХ запрос не сопровождается контрольной последовательностью кадра, она вычисляется в соответствии с 7.3.6 ИСО 9314-2.
Комбинация битов поля "управление кадра" должна иметь значение 0L01rPPP, указывая на асинхронный кадр УЛЗ, где бит L означает длину адреса (см. 7.3.3.2 ИСО 9314-2), бит r зарезервирован и установлен в ноль, а биты РРР означают приоритет кадра (см. 7.3.3.4 ИСО 9314-2).
Если значение параметра "приоритет пользователя" специфицировано, оно кодируется битами РРР, а приоритет доступа (см. 8.1.4 ИСО 9314-2) образуется из значения тайм-аута удержания маркера (ТУМ); в противном случае он определяется разработчиком. Если значение параметра "приоритет пользователя" не специфицировано, биты РРР должны быть установлены в ноль и приоритет доступа образуется из значения ТУМ.
Для обеспечения внутренних услуг подуровня УДС мост ВОРИПД удаляет кадры, передаваемые самому себе, согласно требованиям ИСО 9314-2, даже если они могут содержать адрес отправителя, отличный от адреса того порта моста, который их передавал.
3 Принципы работы
В этом разделе определяются принципы и модель работы моста. В частности, в данном разделе:
1) поясняются основные элементы операций моста и перечисляются выполняемые им функции;
2) определяется архитектурная модель моста, управляющая обеспечением этих функций;
3) определяется модель операций моста в терминах процессов и логических объектов, обеспечивающих указанные функции;
4) подробно рассматриваются требования к адресации в мостовой ЛВС и определяются принципы адресации логических объектов моста.
3.1 Операции моста
К основным элементам операций моста относятся:
1) ретрансляция и фильтрация кадров;
2) обеспечение информацией, необходимой для принятия решения о фильтрации кадров;
3) административное управление перечисленными выше элементами операций.
3.1.1 Ретрансляция
Мост УДС ретранслирует отдельные кадры УДС между различными УДС мостовой ЛВС, подключенными к его портам. При этом последовательность поступления кадров в один порт и их передачи в другой порт сохраняется неизменной.
К функциям, обеспечивающим ретрансляцию кадров и сохранение качества услуг, выполняемым мостом, относятся:
1) прием кадров;
2) аннулирование кадров, полученных с ошибкой (см. 2.3.2);
3) аннулирование кадров, у которых параметр "тип кадра" не является "кадром данных пользователя" или значение его параметра "действие удс" не равно "запрос без ответа" (см. 2.4);
4) аннулирование кадров в результате применения информации фильтрации;
5) аннулирование кадров, полученных с чрезмерно длинным сервисным блоком данных (см. 2.3.8);
6) продвижение принятых кадров в направлении других портов моста;
7) аннулирование кадров для предотвращения превышения максимальной транзитной задержки (см. 2.3.6);
8) выбор приоритета исходящего доступа (см. 2.3.9);
9) преобразование сервисных блоков данных и перерасчет контрольной последовательности кадра (см. 2.3.7);
10) передача кадров.
3.1.2 Информация фильтрации
Мосты отфильтровывают кадры, т. е. не продвигают полученные портом моста кадры в другие порты данного моста, чтобы не допустить дублирования кадров (см. 2.3.4). Передача кадров между двумя оконечными станциями может быть ограничена только теми ЛВС, которые формируют маршрут между этими станциями (см. 2.3.10).
К функциям, которые обеспечивают использование и поддержание информации фильтрации, относятся:
1) обеспечение постоянной структуры резервных адресов;
2) четкое построение статической информации фильтрации;
3) автоматическое изучение динамической информации путем наблюдения за трафиком мостовой ЛВС;
4) перевод в разряд устаревшей автоматически изученной информации фильтрации;
5) вычисление и построение топологии мостовой ЛВС.
Рисунок 3.1 - Мостовая локальная вычислительная сеть
Рисунок 3.1 - Мостовая локальная вычислительная сеть
3.1.3 Диспетчер моста
Функции диспетчера моста обеспечивают контроль и управление выполнением перечисленных выше функций. Они определяются в разделе 6.
3.2 Архитектура моста
Каждый мост принимает и передает кадры в ЛВС, к которой он подключен, используя услуги отдельного логического объекта УДС, связанного с этим портом. Логический объект УДС каждого порта оперирует функциями, зависимыми от метода доступа к среде (протокол и процедуры УДС), как определено в соответствующем стандарте по конкретной технологии УДС.
Ретрансляционный логический объект УДС, не зависимый от метода доступа к среде, выполняет функции ретрансляции кадров между портами моста, фильтрации кадров и изучения информации фильтрации.
Протокольный логический объект моста вычисляет и строит топологию мостовой ЛВС.
Ретрансляционный логический объект УДС использует внутренние услуги и подуровня*, обеспечиваемые отдельными логическими объектами УДС каждого порта. Эти услуги и их обеспечение определены в 2.4 и 2.5. Они не зависят от конкретной технологии УДС.
________________
* Текст соответствует оригиналу. - Примечание.
Протокольный логический объект моста и другие пользователи протоколов более высоких уровней, например диспетчер моста, используют процедуры управления логическим звеном. Эти процедуры обеспечиваются отдельно для каждого порта и используют услуги УДС, обеспечиваемые отдельными логическими объектами УДС.
На рисунках 3.2 и 3.3 показан мост и его порты, а также архитектура моста с двумя портами. Мосты могут иметь более двух портов.
Рисунок 3.2 - Порты моста
Рисунок 3.2 - Порты моста
Рисунок 3.3 - Архитектура моста
Рисунок 3.3 - Архитектура моста
3.3 Модель операций
Использование ретрансляционным логическим объектом УДС внутренних услуг подуровня, обеспечиваемых отдельными логическими объектами УДС, связанными с каждым портом моста, определены в 3.5 и 3.6.
Кадры принимаются из процессов и логических объектов, которые моделируют операции ретрансляционных логических объектов УДС моста, для их последующей передачи, а при получении доставляются указанным процессам и объектам. К этим процессам и объектам относятся:
1) процесс продвижения (см. 3.7), который продвигает получаемые кадры, направляя их в остальные порты моста, отфильтровывает кадры на основе информации, содержащейся в базе данных фильтрации (см. 3.9), и исходя из состояний портов моста (см. 3.4);
2) процесс обучения (см. 3.8), который путем наблюдения за адресами отправителя кадров, получаемых каждым портом, обновляет базу данных фильтрации (см. 3.9), основываясь на состоянии порта (см. 3.4), в котором наблюдаются эти кадры;
3) база данных фильтрации (см. 3.9), которая оперирует информацией фильтрации.
Каждый порт моста функционирует также как оконечная станция, предоставляющая услуги УДС подуровню УЛЗ, который обеспечивает:
1) протокольный логический объект моста (см. 3.10), реализующий протокол построения конфигурации между мостами на подуровне УДС (см. раздел 4) и частично определяющий состояние каждого порта моста (см. 3.4) и их участие в работе активной топологии мостовой ЛВС.
2) других пользователей УЛЗ, таких как протоколы, обеспечивающие функции административного управления моста.
Каждый порт моста должен выполнять операции процедур УЛЗ типа 1 для обеспечения операций протокольного логического объекта моста. Порты моста могут обеспечивать другие типы процедур УЛЗ, которые могли бы использоваться другими протоколами.
На рисунке 3.4 показан отдельный пример ретрансляции кадров между портами двухпортового моста.
Рисунок 3.4 - Ретрансляция кадров УДС
Рисунок 3.4 - Ретрансляция кадров УДС
На рисунке 3.5 показано введение в базу данных фильтрации информации, переданной одним кадром и полученной одним из портов двухпортового моста.
Рисунок 3.5 - Вид сетевого трафика
Рисунок 3.5 - Вид сетевого трафика
На рисунке 3.6 показаны прием и передача ПБДМ протокольным логическим объектом моста.
Рисунок 3.6 - Операции межмостового протокола
Рисунок 3.6 - Операции межмостового протокола
3.4 Информация о состоянии порта
Информация о состоянии каждого порта управляет их участием в работе мостовой ЛВС. Если диспетчер допускает порт к участию в ретрансляции кадров и этот порт способен выполнять данную функцию, порт считается активным.
Настоящий стандарт определяет использование алгоритма и протокола покрывающего дерева, которые сводят топологию мостовой ЛВС к простой активно связанной топологии (см. раздел 4). В подразделе 4.4 специфированы состояния порта, относящиеся к этому механизму. Порты, участвующие в ретрансляции кадров, описываются как находящиеся в состоянии продвижения.
Введение информации о месте нахождения оконечной станции в базу данных фильтрации посредством процесса обучения также зависит от активной топологии. Если информация, относящаяся к принятым портом кадрам, подлежит введению в базу данных фильтрации процессом обучения, то этот порт характеризуется как находящийся в состоянии обучения, в противном случае, он не находится в этом состоянии.
На рисунке 3.4 показано использование процессом продвижения информации состояния порта, получившего кадр, с целью определения необходимости ретрансляции принятого кадра через другие порты моста, а также использование информации состояния порта для второго порта моста с целью определения необходимости продвижения через этот порт передаваемого кадра.
На рисунке 3.5 показано использование процессом обучения информации состояния порта, получившего кадр, с целью определения необходимости введения в базу данных фильтрации информации о месте нахождения станции.
На рисунке 3.6 показаны операции протокольного логического объекта моста, реализующие алгоритм и протокол покрывающего дерева, и операции по модификации информации состояния порта, выполняемые ими как часть процесса определения активной топологии мостовой ЛВС.
3.5. Прием кадров
Отдельный логический объект УДС, связанный с каждым активным портом моста, просматривает все кадры, передаваемые по ЛВС, к которой он подключен.
Кадры с ошибками, определенными соответствующими методами доступа к среде, должны быть аннулированы; к ним относятся кадры, имеющие ошибку КПК.
Все остальные кадры направляются к процессу обучения.
Кадры примитива УД-БЛОК-ДАННЫХ индикация с параметрами "тип кадра" и "действие удс" в значениях "кадр данных пользователя" и "запрос без ответа" соответственно (см. 2.5) направляются процессу продвижения. Кадры, у которых указанные параметры имеют другие значения, такие как "запрос с ответом" и "ответ", аннулируются и не должны ретранслироваться мостом.
Кадры, адресованные порту моста, который ведет себя как обычная оконечная станция, и имеющие параметр "тип кадра" в значении "кадр данных пользователя", должны передаваться подуровню УЛЗ. Такие кадры переносят в поле "адрес получателя" либо индивидуальный адрес УДС порта, либо групповой адрес, связанный с этим портом (см. 3.12).
Кадры, ретранслируемые в данный порт моста из других портов того же моста и адресуемые этому порту моста как оконечной станции, должны также передаваться подуровню УЛЗ.
3.6 Передача кадров
Отдельный логический объект УДС, связанный с каждым активным портом моста, передает кадры, направляемые ему ретрансляционным логическим объектом УДС.
Ретранслируемые кадры направляются для передачи процессом продвижения. Примитив УД-БЛОК-ДАННЫХ запрос, относящийся к таким кадрам, переносит значения полей "адрес получателя" и "адрес отправителя", полученных в соответствующем примитиве УД-БЛОК-ДАННЫХ индикация.
Протокольный блок данных УЛЗ передается подуровнем УЛЗ, который ведет себя как пользователь услуг УДС, предоставляемых портом моста. Передаваемые кадры, которые переносят такие ПБД, содержат в поле "адрес отправителя" индивидуальный адрес УДС порта.
Каждый кадр передается процедурами УДС, определяемыми конкретной технологии стандартных ЛВС. Параметры "тип кадра" и "действие удс" соответствующего примитива "УДС-БЛОК-ДАННЫХ запрос" имеют значения "кадр данных пользователя" и "запрос без ответа" соответственно (см. 2.5).
Кадры, переданные по запросу пользователя подуровня УЛЗ услуг УДС, обеспечиваемых портом моста, также должны направляться ретрансляционному логическому объекту УДС.
3.7 Продвижение кадра
Процесс продвижения направляет полученные кадры, подлежащие ретрансляции, в другие порты моста, фильтруя их на основе информации, содержащейся в базе данных фильтрации, и с учетом состояния портов моста.
3.7.1 Условия продвижения
Кадры, поступившие в активный порт моста и направленные процессу продвижения, ставятся в очередь на передачу в каждом другом активном порту моста только в том случае, если:
1) порт, в который поступит кадр, находится в состоянии продвижения (см. 4.4) и
2) порт, в который должен быть передан кадр, находится в состоянии продвижения, и
3) либо
а) база данных фильтрации указывает, что кадр с таким значением поля "адрес получателя" должен быть продвинут через передающий порт (например это может быть, если в базе данных фильтрации отсутствует адрес получателя), либо
b) значения полей "адрес получателя" и "адрес отправителя" одинаковые и мост не выполняет фильтрацию этого кадра, и
4) максимальная длина сервисного блока данных обеспечивается ЛВС, к которой подключен передающий порт, и не будет превышена.
3.7.2 Проверка дублирования адресов УЛЗ
Мост может либо:
1) отфильтровывать кадры, в которых поля "адрес отправителя" и "адрес получателя" на подуровне УДС имеют одинаковые значения с целью локализации трафика, либо
2) продвигать такие кадры для обеспечения факультативной функции проверки дублирования адресов УЛЗ.
3.7.3 Постановка кадров в очередь
Процесс продвижения обеспечивает память для постановки кадров в очередь в ожидании возможности их передачи отдельным логическим объектам УДС, связанным с каждым портом моста. При этом должен поддерживаться определенный порядок передачи кадров из очереди. Кадр, поставленный в очередь процессом продвижения для передачи в порт, должен быть изъят из этой очереди при передаче отдельному логическому объекту УДС этого порта; не следует продолжать попытки передачи кадра в этот порт, если становится известно, что передача окажется безуспешной.
Кадр, поставленный в очередь процессом продвижения для передачи в порт, может быть удален из этой очереди без последующей передачи, если время, на которое гарантирована буферизация, истекло для этого кадра.
Кадр, поставленный в очередь для передачи в порт, должен быть удален из этой очереди без последующей передачи отдельному логическому объекту УДС этого порта, если максимальная мостовая транзитная задержка (см. 2.3.6) может быть превышена на время, в течение которого этот кадр мог бы передаваться.
Кадр, поставленный в очередь для передачи в порт, должен быть удален из этой очереди, если этот порт выходит из состояния продвижения.
Удаление кадра в каком-либо порту из очереди на передачу само по себе еще не означает, что он должен быть удален из очереди на передачу в любом другом порту.
3.7.4 Преобразование приоритетов
Процесс продвижения выполняет преобразование приоритетов продвигаемых кадров (см. 2.3.9). Он определяет значения параметров "приоритет пользователя" и "приоритет доступа", используемых при ретрансляции кадров.
Параметр "приоритет пользователя" в примитиве УД-БЛОК-ДАННЫХ запрос (см. 2.5) должен быть:
1) равен значению параметра "приоритет пользователя" соответствующего примитива УД-БЛОК-ДАННЫХ индикация, если он специфицирован, т. е. если кадр получен из ЛВС, использующей маркерный метод доступа к шине, маркерный метод доступа к кольцу или метод доступа ВОРИПД, либо
2) установлен в значение параметра "приоритет пользователя при отправлении" (см. ниже) для передающего порта, если его значение в соответствующем примитиве УД-БЛОК-ДАННЫХ индикация не было специфицировано, т. е. если кадр был получен из ЛВС, использующей метод доступа КДОН/ОК.
Параметр "приоритет доступа" в примитиве УД-БЛОК-ДАННЫХ запрос (см. 2.5) должен быть:
а) установлен в значение параметра "приоритет доступа при отправлении" (см. ниже) для передающего порта или
b) равен значению параметра "приоритет пользователя" в примитиве запроса, или
с) для случая ВОРИПД (ИСО 9314-2) образуется из значения ТУМ в виде значения по умолчанию; в противном случае его значение выбирается разработчиком.
Параметры "приоритет пользователя при отправлении" и "приоритет доступа при отправлении" могут быть установлены диспетчером. Если такая возможность обеспечивается, значения этих параметров должны быть установлены независимо для каждого передающего порта, и мост должен быть способен использовать полный ряд значений в диапазоне, приведенном в таблицах 3.1 и 3.2. Если такая возможность не обеспечивается, мост должен использовать значения по умолчанию, приведенные в таблицах 3.1 и 3.2.
Таблица 3.1 - Приоритеты пользователя при отправлении
| Параметр | Значение рекомендуемое | Диапазон |
| Приоритет пользователя при отправлении (КДОН/ОК, ГОСТ 34.913.3) | 0 | 0-7 |
| Приоритет пользователя при отправлении (шина с маркерным доступом, ГОСТ 34.913.4) | 0 | 0-7 |
| Приоритет пользователя при отправлении (кольцо с маркерным доступом, ГОСТ Р ИСО/МЭК 8802-5) | 0 | 0-7 |
| Приоритет пользователя при отправлении (ВОРИПД, ГОСТ Р 50452) | 0 | 0-7 |
Таблица 3.2 - Приоритеты доступа при отправлении
| Параметр | Значение рекомендуемое | Диапазон |
| Приоритет доступа при отправлении (КДОН/ОК, ГОСТ 34.913.3) | 0 | 0-7 |
| Приоритет доступа при отправлении (шина с маркерным доступом, ГОСТ 34.913.4) | 0 | 0-7 |
| Приоритет доступа при отправлении (кольцо с маркерным доступом, ГОСТ Р ИСО/МЭК 8802-5) | 4 | 0-7 |
Заметим, что метод доступа КДОН/ОК рассматривает все значения параметра "приоритет доступа" одинаковыми и не передает значения параметра "приоритет пользователя". Параметры "приоритет пользователя при отправлении" и "приоритет доступа при отправлении" для этого метода доступа определяются таким образом, чтобы обеспечить согласованный подход к административному управлению портов моста различных типов УДС.
3.7.5 Перерасчет КПК
В тех случаях, когда кадр продвигается между двумя отдельными логическими объектами УДС одного и того же типа стандартных ЛВС (включая ЛВС типа ВОРИПД), КПК, полученную в примитиве УД-БЛОК-ДАННЫХ индикация, можно передать в соответствующем примитиве УД-БЛОК-ДАННЫХ запрос и повторно не вычислять (см. 2.3.7).
В случаях использования ЛВС различных типов это сделать невозможно и КПК должна пересчитываться в соответствии с конкретными процедурами УДС передающего логического объекта УДС.
3.7.6 Модель
На рисунке 3.4 на примере ретрансляции кадра между портами двухпортового моста показаны операции процесса продвижения.
3.8 Процесс обучения
Процесс обучения наблюдает адреса отправителя кадров, получаемых каждым портом моста, и модифицирует базу данных с учетом состояния принимающего порта.
Кадры направляются процессу обучения отдельными логическими объектами УДС, связанными с каждым портом моста, как определено в 3.5.
Процесс обучения может определить маршрут через мостовую ЛВС для конкретных оконечных станций путем просмотра поля "адрес отправителя" получаемых кадров. Он может создавать или изменять динамические записи (см. 3.9, 3.9.2) в базе данных фильтрации, относящиеся к порту, в котором был получен кадр с адресом УДС в поле "адрес отправителя" только в том случае, если:
1) порт, получивший кадр, находится в состоянии, позволяющем выполнять обучение (см. 4.4), и
2) поле кадра "адрес отправителя" указывает определенную оконечную станцию, т. е. не групповой адрес, и
3) статическая запись (см. 3.9, 3.9.1) соответствующего адреса УДС уже не существует, и
4) суммарное число записей не превышает емкости базы данных фильтрации.
Если емкость базы данных фильтрации уже заполнена и должна быть введена новая запись, то существующая запись может быть удалена, чтобы освободить место для новой записи.
Hа рисунке 3.5 показаны операции процесса обучения по введению в базу данных фильтрации информации о местонахождении станции, переданной отдельным кадром и полученной одним из портов моста.
3.9 База данных фильтрации
База данных фильтрации содержит информацию фильтрации, которая либо явно сформирована действием диспетчера, либо автоматически введена процессом обучения. Она обеспечивает различные запросы со стороны процесса продвижения, например, о необходимости передачи кадров с заданными значениями адреса получателя УДС в данный порт.
База данных фильтрации должна содержать в себе статические записи (см. 3.9.1) и обеспечивать возможность хранения динамических записей (см. 3.9.2). Для заданного адреса УДС не должны иметь место оба типа записей: динамическая запись не должна создаваться при наличии статической записи; создание статической записи должно приводить к удалению динамической записи для того же адреса УДС, если такая запись уже существует.
База данных фильтрации может быть опрошена и откорректирована диспетчером. Такая диспетчеризация может быть выполнена либо локальными или частными средствами, либо путем использования возможностей удаленного диспетчера, обеспечиваемых логическим объектом диспетчера моста (см. 3.11), с использованием операций, определенных в разделе 6.
3.9.1 Статические записи
Статические записи могут быть занесены в базу данных фильтрации и удалены из нее под непосредственным управлением диспетчера. Они не удаляются автоматически никаким механизмом таймирования.
Статистические записи определяют:
1) адрес УДС-получателя, для которого определена фильтрация;
2) для каждого входящего порта, в котором принимаются кадры, портовое преобразование, определяющее для каждого исходящего порта, из которого могут быть переданы кадры, необходимость фильтрации и продвижения кадров в этот порт.
Адреса УДС, которые могут быть специфицированы, должны включать в себя групповые адреса и глобальный адрес.
3.9.2 Динамические записи
Динамические записи создаются и обновляются процессом обучения, как определено в 3.8. Они должны удаляться по истечении определенного времени с момента их создания или последней коррекции. Такое таймирование записей гарантирует, что оконечные станции, которые переместились в другую часть мостовой ЛВС, не будут иметь постоянных препятствий по получению кадров. Оно учитывает также изменения активной топологии мостовой ЛВС, которые могут быть причиной того, что с точки зрения моста оконечные станции меняют свое местоположение, т. е. маршрут к этим оконечным станциям со временем меняется, проходя через другой порт моста.
Значения тайм-аутов или времени старения, по истечении которого динамическая запись автоматически удаляется, могут устанавливаться диспетчером (см. раздел 6). Рекомендуемые значения по умолчанию для использования в мостовой ЛВС приведены в таблице 3.3; они предложены с тем, чтобы в большинстве случаев исключить необходимость установления явных указанных значений. В таблице 3.3 определен также диапазон используемых значений. Если значение времени старения может быть установлено диспетчером, мост должен иметь возможность использовать значения заданного диапазона кратностью 1 с.
Таблица 3.3 - Значение параметра времени старения
| Параметр | Рекомендуемое значение | Диапазон |
| Время старения, с | 300,0 | 10,0 - 1,0х10 |
Определение в разделе 4 алгоритм и протокол покрывающего дерева охватывают процедуры уведомления всех мостов мостовой ЛВС об изменениях топологии и устанавливают короткий тайм-аут, действующий после любого изменения топологии. В периоды отсутствия изменений топологии эти процедуры допускают обычную длительность тайм-аута, достаточную для того, чтобы охватить периоды, в течение которых сами адресуемые оконечные системы не генерируют кадры (возможно, по причине отключения питания) и в то же время не уменьшающую возможностей мостовой ЛВС продолжать обеспечение услуг после автоматической реконфигурации.
Динамические записи определяют:
1) адрес УДС, для которого определена фильтрация;
2) номер порта.
Кадры с определенным адресом УДС - получателя могут продвигаться только в заданный порт. Динамическая запись ведет себя подобно статической записи с единственным портом, выбранным в операции портового преобразования.
Адреса УДС, определенные в динамической записи, не должны содержать групповые и глобальные адреса.
3.9.3 Постоянная база данных
База данных фильтрации содержит в себе постоянную базу данных, которая обеспечивает фиксированную память для статических записей. База данных фильтрации должна быть инициирована статическими записями, содержащимися в этой постоянной памяти данных.
Статические записи могут быть введены и удалены из постоянной базы данных явными управляющими действиями диспетчера.
3.9.4 Модель операций
На рисунке 3.4 на примере ретрансляции кадра между портами двухпортового моста показано использование базы данных фильтрации процессом продвижения.
На рисунке 3.5 показаны создание и корректировка динамических записей в базе данных фильтрации процессом обучения.
На рисунке 3.6 показаны операции протокольного логического объекта моста (см. 3.10), который реализует алгоритм и протокол покрывающего дерева, и информирование им базы данных фильтрации об изменениях активной топологии.
3.10 Протокольный логический объект моста
Реализует алгоритм и протокол покрывающего дерева.
Протокольные логические объекты мостов, подключенные через свои порты к одним и тем же отдельным ЛВС в мостовой ЛВС, взаимодействуют между собой путем обмена протокольными блоками данных моста.
На рисунке 3.6 показаны операции протокольного логического объекта моста, включая прием и передачу кадров, содержащих ПБДМ, модификацию информации о состоянии, относящуюся к отдельным портам моста, и информирование базы данных фильтрации об изменении активной топологии.
3.11 Диспетчер моста
Мост может обеспечивать средства удаленного административного управления.
Необходимые для этого средства и обеспечиваемые ими операции определены в разделе 6.
В разделе 7 определены протокольные операции, идентификаторы и конкретные значения, подлежащие использованию в реализуемых операциях административного управления согласно требованиям стандарта IEEE Std 802.1, часть В.
Протоколы диспетчера моста используют услуги, предоставляемые процедурами УЛЗ, которые, в свою очередь, используют услуги УДС, обеспечиваемые в мостовой ЛВС.
3.12 Адресация
Все логические объекты УДС мостовой ЛВС должны использовать 48-битовые адреса, которые могут быть либо универсально, либо локально администрируемыми адресами, либо теми и другими.
Мосты могут использовать:
1) 48-битовую универсально администрируемую адресацию или
2) 48-битовую локально администрируемую адресацию, или
3) 16-битовую локально администрируемую адресацию.
Каждый конкретный адрес УДС, используемый в мостовой ЛВС, должен быть уникальным в пределах данной сети с целью недвусмысленной спецификации адресуемой станции.
3.12.1 Оконечные станции
Кадры, передаваемые между оконечными станциями с использованием услуг УДС, обеспечиваемых мостовой ЛВС, содержат адрес УДС - отправителя и получателя равноправных оконечных станций в полях кадра "адрес получателя" и "адрес отправителя" соответственно. Адрес или другие средства идентификации моста не переносятся в кадрах, передаваемых между равноправными пользователями, с целью ретрансляции кадров в мостовой ЛВС.
Широковещательный адрес и другие групповые адреса в целом применимы для использования услуг УДС, обеспечиваемых мостовой ЛВС. Кадры с такими значениями поля "адрес получателя" при отсутствии явно администрируемой конфигурации базы данных фильтрации (см. 3.9 и раздел 6) ретранслируются через мостовую ЛВС.
3.12.2 Порты моста
Отдельный логический объект УДС, связанный с каждым портом моста, должен иметь отдельный специфичный адрес УДС. Этот адрес используется процедурами УДС, которые реализует логический объект УДС, если это требуется конкретным используемым методом доступа к среде.
Кадры, поступающие из ЛВС, к которой подключен порт, и содержащие в поле "адрес получателя" адрес УДС данного порта, доставляются пользователю услуг УДС (УЛЗ) точно так же, как и оконечной станции.
3.12.3 Протокольные логические объекты моста
Принимают и передают только те кадры, которые содержат ПБДМ. Они передаются и принимаются только из других протокольных логических объектов моста (а в ситуациях, когда два порта моста подсоединены к одной и той же ЛВС, передаются и принимаются только между этими портами).
Для передачи ПБДМ протокольный логический объект моста использует примитив ЗД-БЛОК-ДАННЫХ запрос, обеспечиваемый отдельными логическими объектами УЛЗ, связанными с каждым активным портом моста. ПБДМ поступают в соответствующем примитиве ЗД-БЛОК-ДАННЫХ индикация. Параметры примитива ЗД-БЛОК-ДАННЫХ запрос "адрес отправителя" и "адрес получателя" должны указывать стандартные ПДУЗ, назначенные протоколу покрывающего дерева моста.
Каждый примитив ЗД-БЛОК-ДАННЫХ индикация выдается для передачи командного ПБД НИ УЛЗ, который переносит ПБДМ в своем поле информации. Поля "адрес получателя" и "адрес отправителя" ПДУЗ принимают значения, поступившие в соответствующем примитиве запроса. Значение, присвоенное ПДУЗ протокола покрывающего дерева моста, приведено в таблице 3.4.*
______________
* Полный перечень стандартных присвоений ПДУЗ и критерии присвоения содержатся в ИСО/МЭК ТО 10178.
Таблица 3.4 - Стандартное присвоение ПДУЗ
| Назначение | Значение |
| Протокол покрывающего дерева моста | 01000010 |
| Кодовое представление - бит младшей значимости приведенного значения - крайний слева. Значимость битов возрастает слева направо. | |
В настоящем стандарте определяется содержащееся во всех ПБДМ (см. раздел 5) поле "идентификатор протокола", которое служит для идентификации различных протоколов, обеспечиваемых протокольными логическими объектами моста, в сфере действия присвоений ПДУЗ. В настоящем стандарте определяется одно значение идентификатора протокола, которое приведено в разделе 5. Это значение служит для идентификации ПБДМ, обмениваемых между протокольными логическими объектами моста, реализующими алгоритм и протокол покрывающего дерева согласно разделу 4. Все остальные значения этого поля зарезервированы для последующей стандартизации.
Протокольный логический объект моста, получивший ПБДМ с неизвестным идентификатором протокола, должен аннулировать такой ПБДМ.
Протокольный логический объект моста, реализующий алгоритм и протокол покрывающего дерева согласно разделу 4 настоящего стандарта, всегда передает ПБДМ, адресованные всем остальным протокольным логическим объектам моста, которые подключены к той ЛВС, по которой передавались кадры с ПБДМ. Для адресации данной группы логических объектов в поле "адрес получателя" должен быть использован групповой адрес. Этот групповой адрес должен быть сформирован в постоянной базе данных (см. 3.12.6) с целью ограничения числа ПБДМ, передаваемых в отдельную ЛВС.
Для этой цели назначается 48-битовый универсальный адрес, известный как групповой адрес моста. Значения этого адреса определены в таблице 3.5. Мосты, которые используют 48-битовую универсально администрируемую адресацию, должны вводить этот адрес в поле "адрес получателя" всех кадров УДС, содержащих ПБДМ.
Таблица 3.5 - Зарезервированные адреса
| Назначение | Значение |
| Групповой адрес моста | 01-80-С2-00-00-00 |
| Зарезервирован для дальнейшей стандартизации | 01-80-С2-00-00-01 |
| То же | 01-80-С2-00-00-02 |
| " | 01-80-С2-00-00-03 |
| " | 01-80-С2-00-00-04 |
| " | 01-80-С2-00-00-05 |
| " | 01-80-С2-00-00-06 |
| " | 01-80-С2-00-00-07 |
| Зарезервирован для дальнейшей стандартизации | 01-80-С2-00-00-08 |
| То же | 01-80-С2-00-00-09 |
| " | 01-80-С2-00-00-0А |
| " | 01-80-С2-00-00-0В |
| " | 01-80-С2-00-00-0С |
| " | 01-80-C2-00-00-0D |
| " | 01-80-C2-00-00-0F |
В поле "адрес отправителя" кадра УДС, содержащего ПБДМ, передается конкретный адрес УДС того порта моста, через который проходит этот ПБДМ (см. 3.12.2).
3.12.4 Логические объекты диспетчера моста
Передают и принимают ПБД с использованием услуг, предоставляемых отдельными логическими объектами УЛЗ, связанными с каждым портом моста. Каждый из этих объектов УЛЗ, в свою очередь, использует услуги УДС, предоставляемые отдельными логическими объектами УДС, связанными с каждым портом, и обеспечиваемые мостовой ЛВС в целом.
Логический объект диспетчера моста как пользователь услуг УДС, предоставляемых мостовой ЛВС, может быть подключен к любой точке мостовой ЛВС. Кадры, адресованные логическому объекту диспетчера моста, могут при необходимости ретранслироваться мостом, чтобы достичь ЛВС, к которой он подключен.
Чтобы исключить получение кадров - дубликатов, должно соблюдаться основное требование, предъявляемое к отдельной или мостовой ЛВС: каждому пункту подключения должен быть присвоен уникальный адрес.
Логическому объекту диспетчера конкретного моста присваивается один или несколько специфичных адресов УДС в сочетании с идентификатором протокола верхнего уровня и адресной информацией. Вместе с портами данного моста этот объект может участвовать в использовании одного или нескольких пунктов подключения к мостовой ЛВС. Рекомендуется, чтобы этот объект использовал услуги УДС, предоставляемые всеми логическими объектами УДС, связанными с каждым портом моста, т. е. чтобы к нему был обеспечен доступ через каждый порт моста с использованием кадров, содержащих в поле "адрес получателя" специфичный адрес УДС этого порта.
В настоящем стандарте определяется стандартный групповой адрес общего пользования, который служит для передачи запросов административного управления логическому объекту диспетчера моста, связанного со всеми портами моста, подключенными к мостовой ЛВС. Запрос административного управления, который передается в кадре УДС, содержащем такое значение адреса в поле "адрес получателя", как правило, будет приводить к выдаче многих ответов из отдельного моста. Этот адрес известен как групповой адрес диспетчера моста всех ЛВС и имеет значения, приведенные в таблице 3.6.
Таблица 3.6 - Адресация диспетчера моста
| Назначение | Значение |
| Групповой адрес диспетчера моста всех ЛВС | 01-80-С2-00-00-10 |
3.12.5 Уникальный идентификатор моста
Для функционирования протокола моста, определенного в разделе 4, желательно и необходимо, чтобы с каждым мостом был связан один уникальный идентификатор. Этот идентификатор образуется из уникального адреса УДС моста, известного как адрес моста.
В мостовой ЛВС, использующей локально присвоенные 16-битовые адреса, такой адрес должен быть уникален среди всех других адресов, присвоенных в мостовой ЛВС.
В мостовой ЛВС, использующей 48-битовую адресацию, такой адрес должен присваиваться как уникальный в глобальном масштабе, т. е. он должен быть 48-битовым уникально администрируемым адресом.
Рекомендуется, чтобы этот адрес был специфичным адресом УДС порта моста с наименьшим номером (порт 1).
Уникальный идентификатор моста, используемый алгоритмом и протоколом покрывающего дерева, образуется из адреса моста, как определено в 4.5.3 и 5.2.5.
3.12.6 Зарезервированные адреса
Кадры, содержащие в своем поле "адрес получателя" какой-либо из адресов, указанных в таблице 3.5, не ретранслируются мостом. Они должны храниться в постоянной базе данных. Диспетчер не должен иметь возможность удалять такие адреса из постоянной базы данных фильтрации. Эти групповые адреса зарезервированы для присвоения в стандартных протоколах согласно установленным критериям (см. 5.5 IEEE Std 802).
Другие групповые адреса могут быть сформированы в виде статических записей в постоянной базе данных без необходимости их явной инициализации диспетчером. Диспетчер может иметь возможность удаления таких адресов из постоянной базы данных фильтрации.
4 Алгоритм и протокол покрывающего дерева
Алгоритм и протокол конфигурации, описываемые в данном разделе, сводит топологию мостовой ЛВС к отдельному покрывающему дереву.
4.1 Требования к алгоритму
Алгоритм покрывающего дерева и соответствующий ему протокол моста работает для обеспечения, поддержки и сохранения качества услуг УДС относительно всех аспектов КУ, рассмотренных в разделе 2. Для выполнения этой функции алгоритм должен удовлетворять следующим требованиям, каждое из которых относится к вопросам данного раздела:
1) он должен организовывать активную топологию мостовой ЛВС любой топологии в единое покрывающее дерево таким образом, чтобы между двумя оконечными станциями существовал только один маршрут данных, исключая шлейфы данных (см. 2.3.3 и 2.3.4);
2) он должен обеспечить устойчивость к неисправностям путем автоматической реконфигурации топологии покрывающего дерева при неисправностях моста или разрыва тракта данных в рамках доступных компонентов мостовой ЛВС, и автоматическую адаптацию моста или порта моста, добавленного к мостовой ЛВС, без образования шлейфов данных (см. 2.1);
3) вся активная топология должна быть стабильной в мостовой ЛВС любых размеров. Она должна с высокой вероятностью прийти в устойчивое состояние за короткий установленный промежуток времени с целью уменьшения времени, в течение которого услуги оказываются недоступны для использования любой парой оконечных станций (см. 2.1);
4) активная топология должна быть предсказуема, воспроизводима и допускать выбор путем администрирования параметров алгоритма, обеспечивая тем самым применимость диспетчера конфигурации на основе анализа трафика в соответствии с задачами административного управления рабочими характеристиками (см. 2.1 и 2.3.10);
5) для оконечных станций работа алгоритма должна быть прозрачной с тем, чтобы при использовании услуг УДС они не заботились о том, подключены они к отдельной или мостовой ЛВС (см. 2.2);
6) полоса пропускания канала связи, используемая мостом при установлении и использовании покрывающего дерева в любой конкретной ЛВС, должна составлять небольшую долю от общей доступной полосы частот и не должна зависеть от общего трафика, обеспечиваемого мостовой ЛВС, при любом общем количестве мостов или ЛВС (см. 2.3.10).
Кроме того, алгоритм и протокол должны удовлетворять следующим целям, которые ограничивают сложность мостов и их конфигурации:
1) требования к памяти, относящейся к каждому порту моста, не должны зависеть от количества мостов и ЛВС в мостовой ЛВС;
2) мостам не следует задавать конфигурацию заранее до их включения в мостовую ЛВС, за исключением наличия адресов УДС, определенных путем использования обычных процедур.
4.2 Требования к мостам УДС
Для работы мостового протокола требуется следующее:
1) уникальный групповой адрес УДС, распознаваемый всеми мостами мостовой ЛВС, который идентифицирует протокольные логические объекты всех мостов, подключенных к отдельной ЛВС;
2) идентификатор каждого моста, уникальный в пределах мостовой ЛВС;
3) отличный от других идентификатор каждого порта моста, который может быть назначен независимо от значений, используемых в других местах.
Значения каждого из этих параметров и механизм определения их значений должны обеспечиваться каждым мостом. В случае, когда мосты УДС используют 48-битовую универсально администрированную адресацию, уникальный адрес УДС, идентифицирующий протокольный логический объект моста, представляет собой групповой адрес моста (см. 3.12.3).
Кроме того, для обеспечения административного управления конфигурацией покрывающего дерева активной топологии требуется следующее:
1) средства назначения относительного приоритета каждого моста в группе мостов мостовой ЛВС;
2) средства назначения относительного приоритета каждого порта в группе портов отдельного моста;
3) средства, позволяющие определить для каждого порта моста компоненту "стоимость маршрута".
Эти параметры могут устанавливаться диспетчером.
Уникальный идентификатор каждого моста частично образуется из адреса моста (см. 3.12.5) и частично из администрируемой компоненты "приоритет" (см. 5.2.5). Относительный приоритет мостов определяется численным сравнением уникальных идентификаторов, где наименьшее численное значение указывает наивысший приоритет идентификатора.
Одна часть идентификатора каждого порта является фиксированной и различной для каждого порта моста, а другая - администрируемой компонентой "приоритет" (см. 5.2.7). Относительный приоритет портов определяется численным сравнением уникальных идентификаторов, где наименьшее численное значение указывает наивысший приоритет идентификатора.
Стоимость маршрута, связанная с каждым портом моста, может быть администрируемой. Дополнительно в 4.10.2 даны их значения по умолчанию для портов, подключенных к ЛВС с конкретными типами УДС и скоростей.
4.3 Общие сведения
4.3.1 Активная топология и ее вычисление
Алгоритм и протокол покрывающего дерева образуют простую взаимоувязанную активную топологию из произвольно соединенных компонентов мостовой ЛВС. Кадры продвигаются через определенные порты моста мостовой ЛВС, минуя заблокированные. В любой момент времени мост эффективно соединяет только те ЛВС, к которым подключены порты, находящиеся в состоянии продвижения. Кадры продвигаются в обоих направлениях через те мостовые порты, которые находятся в состоянии продвижения. Порты, находящиеся в состоянии блокирования, не продвигают кадры ни в одном из направлений, но могут входить в состав активной топологии, т. е. могут быть переведены в состояние продвижения, если компоненты сети выходят из строя, удаляются или вводятся в сеть.
На рисунке 2.2 показан пример мостовой ЛВС. На рисунке 4.1 показана активная, т.е. логическая увязанная топология одной и той же мостовой ЛВС после ее образования.
Рисунок 4.1 - Активная топология
Рисунок 4.1 - Активная топология
Один из мостов называется "корневым мостом" или "корнем" мостовой ЛВС. Каждая отдельная ЛВС соединена с одним из портов моста, который продвигает кадры из этой ЛВС к корневому мосту и из корневого моста к данной ЛВС. Этот порт называется "назначенным портом" для данной ЛВС, а мост, в котором находится этот порт, - "назначенным мостом" для этой ЛВС. Корневой мост является назначенным мостом для всех тех ЛВС, с которыми он связан. Порты каждого моста, находящиеся в состоянии продвижения, являются корневыми портами (расположенными ближе всего к корневому мосту - см. ниже) и портами назначения (если таковые имеются).
На рисунке 4.1 в качестве корневого моста выбран мост 1 (хотя на первый взгляд не видно, какой из мостов является корневым), и он же является назначенным мостом для ЛВС1 и ЛВС2. Мост 2 является назначенным мостом для ЛВС3 и ЛВС4, а мост 3 - для ЛВС5. На рисунке 4.2 показана логическая древовидная топология этой конфигурации мостовой ЛВС.
Рисунок 4.2 - Связующее дерево
Рисунок 4.2 - Связующее дерево
Устойчивая активная топология мостовой ЛВС определяется:
1) уникальными идентификаторами моста, связанными с каждым мостом;
2) стоимостью маршрута, связанного с каждым портом моста;
3) идентификатором порта, связанного с каждым портом моста.
Мост, у которого идентификатор имеет наивысший приоритет, является корневым (для удобства вычислений этому идентификатору присваивают наименьшее числовое значение). Каждый мост и порт моста мостовой ЛВС имеет соответствующий параметр "стоимость маршрута к корневому мосту" (СМКМ). Это сумма стоимостей маршрутов к каждому порту, принимающему кадры из корневого моста по самому дешевому маршруту к мосту. Назначенным портом для каждой ЛВС является тот порт моста, для которого стоимость маршрута к корневому мосту наименьшая: если два или более портов имеют одинаковое значение СМКМ, то для выхода из тупиковой ситуации сначала используются мостовые идентификаторы этих мостов, а затем идентификаторы их портов. Таким образом один из портов моста выбирается в качестве назначенного порта для каждой ЛВС и по такому же расчету выбирается среди собственных портов моста корневой порт, что в конечном счете и определяет полностью активную топологию.
Компонента "мостовой идентификатор" каждого моста, а также "стоимость маршрута" и "идентификатор порта" каждого порта моста могут подвергаться административному управлению, что позволяет руководителю выбирать активную топологию мостовой ЛВС.
4.3.2 Распространение информации о топологии
Мосты передают друг другу ПБДМ, известные под названием ПБДМ "конфигурация", для обеспечения взаимосвязи и вычисления указанной выше информации. Кадр УДС, содержащий ПБДМ, переносит групповой адрес моста в поле "адрес получателя" и принимается всеми мостами, подключенными к той ЛВС, через которую передаются кадры.
ПБДМ не продвигаются непосредственно мостами, но содержащаяся в них информация может быть использована мостом при вычислении своего собственного ПБДМ, подлежащего передаче, и может стимулировать его передачу. ПБДМ "конфигурация", который переносит конкретные значения между портами моста, подключенного к отдельной ЛВС, распознается среди сообщений о конфигурации, осуществляющих распространение информации по всей мостовой ЛВС.
Каждый ПБДМ "конфигурация" наряду с другими параметрами содержит уникальный идентификатор того моста, который считает передающий мост корневым, стоимость маршрута к корневому мосту из передающего порта, идентификатор передающего моста и идентификатор передающего порта. Принимающему мосту этой информации достаточно, чтобы определить: имеет ли передающий порт более высокие основания стать назначенным портом для ЛВС, из которой получен ПБДМ "конфигурация", по сравнению с тем портом, который в данный момент рассчитывает стать назначенным, и следует ли принимающему порту стать корневым портом для данного моста, если такового еще нет.
Своевременное распространение по всей мостовой ЛВС информации, необходимой всем портам для определения своего состояния (блокирование или продвижение), достигается тремя основными механизмами:
1) мост, который рассчитывает стать корневым (все мосты после включения питания надеются стать корневыми, пока не обнаружится наличие другого корневого моста), выдает через регулярные интервалы времени "сообщение о конфигурации" (передаваемое в ПБДМ "конфигурация") во все ЛВС, к которым он подключен;
2) мост, который получает ПБДМ "конфигурация" и приходит к выводу, что его порт корневого моста передает более значимую информацию (идентификатор порта наивысшего приоритета, наименьшая стоимость маршрута к корневому мосту, передающий мост или порт наивысшего приоритета), продвигает эту информацию во все ЛВС, для которых этот порт надеется стать назначенным;
3) мост, который получает менее значимую информацию через порт, рассматриваемый им как назначенный для ЛВС, к которой он подключен, передает в ответ свою собственную информацию для ее опознания всеми другими мостами, подключенными к этой ЛВС.
Следовательно, маршруты покрывающего дерева в направлении к мосту с наивысшим приоритетом идентификатора корневого моста становятся быстро известны в пределах мостовой ЛВС, а менее значимая информация о потенциальных корневых мостах и маршрутах не воспринимается.
4.3.3 Реконфигурация
Чтобы обеспечить реконфигурацию мостовой ЛВС при исключении компонентов сети или при изменении диспетчером параметров, определяющих топологию, информация о топологии, распространяемая по всей мостовой ЛВС, должна иметь ограниченное время существования. Это достигается путем передачи в каждом ПБДМ "конфигурация" "возраста" переносимой информации (времени, прошедшего с момента генерации в корневом мосту сообщения о конфигурации). Каждый мост хранит информацию, полученную назначенным портом из каждой ЛВС, к котором* подключены его порты, и следит за "возрастом" этой информации.
_______________
* Текст соответствует оригиналу. - Примечание.
При нормальной устойчивой работе регулярная передача корневым мостом сообщений о конфигурации гарантирует своевременность информации о топологии.
Если мост отсчитывает тайм-аут хранения информации для порта, этот порт будет пытаться стать назначенным портом для ЛВС, к которой он подключен, и будет передавать в эту ЛВС протокольную информацию, получаемую из корневого моста через его корневой порт.
При истечении для данного корневого моста установленного тайм-аута в качестве корневого может быть выбран другой порт, при этом информация, передаваемая через ЛВС, для которой данный мост является назначенным, может быть вычислена на основе информации, полученной новым корневым портом.
Если в текущем корневом мосту никакой зарегистрированной информации не осталось, мост будет осуществлять реконфигурацию, объявив сам себя корневым мостом. Если корневой мост выходит из строя, другие мосты будут так же таймировать протокольную информацию, и информация, относящаяся к наилучшему преемнику корневого моста, а также новая топология будут быстро распространяться по всей мостовой ЛВС. Возможно также, что путь к текущему корневому мосту изменился (например, вследствие возрастания стоимости) и реконфигурирующий мост установил таймирование, поскольку он должен рассматривать самую последнюю информацию от корневого моста как менее значимую с момента наличия у него самого дорогостоящего маршрута к корневому мосту. В последнем случае соседние мосты должны немедленно отвечать на ПБДМ, передаваемые мостом, стремящимся стать корневым.
Чтобы все мосты мостовой ЛВС одинаково понимали, когда необходимо начинать таймирование прежней информации, значение тайм-аута передается из корневого моста во всех сообщениях о конфигурации. Это значение учитывает задержки распространения передаваемых и принимаемых ПБДМ в каждой отдельной ЛВС мостовой ЛВС и, тем самым, задержки распространения протокольной информации вниз по покрывающему дереву. Чтобы уменьшить вероятность запуска механизма реконфигурации при потере сообщения о конфигурации, это значение включает дополнительные временные интервалы, в течение которых эти сообщения передаются корневым мостом.
4.3.4 Изменение состояния порта
Поскольку при продвижении протокольной информации по всей ЛВС возникают задержки распространения, резкий переход от одной активной топологии к другой невозможен. Изменения топологии в различных частях мостовой ЛВС могут происходить в различные моменты времени и переход порта моста непосредственно из состояния неучастия в активной топологии в состояние продвижения связан с риском появления временных шлейфов данных, дублирований и нарушения порядка следования кадров. Желательно также перед началом продвижения кадров предоставлять другим мостам время для ответа на менее значимую протокольную информацию.
Следовательно, порты моста должны ожидать информацию о новой топологии для ее распространения по всей мостовой ЛВС и перед продвижением кадров они должны ожидать истечения старой информации об активной топологии с целью определения времени существования любых продвигаемых кадров.
В течение этого времени желательно таймировать информацию о местоположении станции в базе данных фильтрации, которая может оказаться уже недействительной, и в последней части этого интервала изучать новую информацию о местоположении станции, чтобы уменьшить влияние начального потока кадров при вхождении порта в состояние продвижения. Поэтому когда алгоритм принимает решение о переводе порта в состояние продвижения, он должен сначала ввести его в состояние прослушивания, в котором он должен ожидать протокольной информации, поскольку предполагается, что он может вернуться в заблокированное состояние, и истечения протокольного таймера, которое переводит его в состояние обучения. В этом состоянии он продолжает блокировать продвигаемые кадры, но информация о местоположении станции вводится процессом обучения в базу данных фильтрации. Наконец, истечение протокольного таймера переводит его в состояние продвижения, где разрешено как продвижение ретранслируемых кадров, так и изучение местоположения станции.
Переходы состояний порта показаны на рисунке 4.3.
Рисунок 4.3 - Состояния порта
1 - порт активизирован диспетчером или после инициализации; 2 - порт деактивизирован диспетчером
или вышел из строя; 3 - алгоритм выбрал данный порт назначенным или портом корневого моста;
4 - алгоритм не выбрал данный порт назначенным или портом корневого моста;
5 - истек протокольный тайм-аут (тайм-аут продвижения)
Рисунок 4.3 - Состояния порта
4.3.5 Информирование об изменении топологии
При нормальной устойчивой работе информация о местоположении станции в базе данных фильтрации нуждается в обновлении только после физического перемещения станции. Следовательно, может оказаться желательным допустить длительное время старения записей в базе данных фильтрации, особенно когда многие оконечные станции передают кадры после включения питания перемещенных станций, что может привести к необходимости повторного изучения информации о местоположении станции.
Однако перестройка активной топологии мостовой ЛВС для моста может выглядеть как перемещение в сети оконечных станций. Это может иметь место даже в том случае, если состояние портов этого моста остается неизменным. Даже перестройке одной части мостовой ЛВС необходимо повторное изучение местоположения станции.
Алгоритм и протокол покрывающего дерева обеспечивают для моста процедуры по обнаружению изменений в активной топологии, по надежному уведомлению корневого моста об изменениях, а для корневого моста - по последующей передаче изменений во все мосты. При этом мосты используют небольшое значение времени существования записей в базе данных фильтрации в течение установленного периода времени.
Когда мост, не являющийся корневым, изменяет активную топологию мостовой ЛВС, он передает ПБДМ "уведомление об изменении топологии" в ЛВС, которая подключена к порту корневого моста. Такая передача повторяется до тех пор, пока мост не получит подтверждения от моста - получателя этой ЛВС. Подтверждение посылается в ПБДМ "конфигурация", поэтому уведомление либо будет подтверждено, либо произойдет последующая реконфигурация. Назначенный мост направляет уведомление непосредственно корневому мосту или в его направлении, используя ту же процедуру.
Если корневой мост получает такое уведомление или сам изменяет топологию, он должен в течение некоторого времени во всех сообщениях о конфигурации установить флаг "изменение топологии". Это время должно быть таким, чтобы все мосты смогли принять одно или несколько сообщений о конфигурации, или можно было осуществить дальнейшую реконфигурацию. Если такой флаг установлен, мосты будут использовать значение "задержка продвижения" (интервал времени, затрачиваемый в каждом из состояний "прослушивание" или "обучение") для определения времени существования динамических записей. Когда указанный флаг сбрасывается, мосты возвращаются к использованию времени старения записей в базе данных фильтрации.
4.4 Состояния порта
Операции отдельного порта моста описываются в терминах состояний порта и процессов (см. 3.3), которые обеспечивают и поддерживают функции, необходимые для работы моста (см. 3.1).
Состояние каждого порта управляет обработкой кадров, получаемых из отдельного логического объекта УДС, связанного с данным портом (см. 3.5), предоставлением кадров логическому объекту УДС для их последующей передачи (см. 3.6) и возможностью включения порта в активную топологию мостовой ЛВС.
Операции алгоритма и протокола покрывающего дерева служат для поддержания и изменения состояний порта с целью обеспечения требований, предъявляемых к алгоритму (см. 4.1). Возможные состояния порта и соответствующие правила относительно обработки кадров специфичны для данного алгоритма и протокола моста.
Ниже для каждого из пяти состояний, т.е. "неактивное", "прослушивание", "обучение", "продвижение" и "блокирование", в которых может находиться порт, определяется следующее:
1) назначение состояния;
2) аннулирует ли процесс продвижения (см. 3.7) полученные кадры;
3) направляет ли процесс продвижения (см. 3.7) продвигаемые кадры для дальнейшей передачи;
4) каким образом процесс обучения (см. 3.8) обрабатывает полученные кадры;
5) включает ли протокольный логический объект моста (см. 3.10) порт в свои вычисления активной топологии;
6) условия, при которых порт входит в состояние и выходит из него.
4.4.1 Блокирование
В этом состоянии порт не участвует в ретрансляции кадров, предотвращая тем самым дублирование кадров вследствие их прохождения через многие маршруты, существующие в активной топологии мостовой ЛВС.
Процесс продвижения должен аннулировать получаемые кадры. Он не должен направлять продвигаемые кадры для передачи. Процесс обучения не должен вводить информацию о местоположении станции в базу данных фильтрации.
Протокольный логический объект моста должен включать порт в свои вычисления активной топологии. Принимаемые ПБДМ должны обрабатываться в соответствии с алгоритмом и протоколом покрывающего дерева.
В состояние "блокирование" порт входит либо в результате инициализации моста, либо из состояния "неактивное", когда порт активизируется операциями диспетчера. В это состояние порт может перейти из состояний прослушивания, обучения или продвижения в результате операций алгоритма и протокола покрывающего дерева. Порт входит в состояние "блокирование" при получении информации о том, что другой мост является назначенным мостом для ЛВС, к которой подключен данный порт.
Из этого состояния порт может выйти при истечении протокольного тайм-аута или при получении ПБДМ "конфигурация" этим или другим портом с переходом в состояние "прослушивание" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может перейти в состояние "неактивное" в результате действий диспетчера.
4.4.2 Прослушивание
В этом состоянии порт готовится к участию в ретрансляции кадров. Ретрансляция кадров временно деактивизируется с целью исключения временных шлейфов, которые могут возникнуть в мостовой ЛВС в течение времени существования этого состояния, при изменении активной топологии мостовой ЛВС. Состояние обучения деактивизировано, поскольку изменения в активной топологии могут привести к некорректности полученной информации, когда активная топология становится устойчивой.
Процесс продвижения должен аннулировать поступающие кадры. Он не должен направлять продвигаемые кадры для передачи. Процесс обучения не должен вводить информацию о местоположении станции в базу данных фильтрации.
Протокольный логический объект моста должен включать порт в свои вычисления активной топологии. Полученные ПБДМ должны обрабатываться в соответствии с алгоритмом и протоколом покрывающего дерева. ПБДМ могут выдаваться для передачи.
В это состояние порт входит из состояния "блокирование", когда операции алгоритма и протокола покрывающего дерева устанавливают, что порт должен участвовать в ретрансляции кадров.
Из этого состояния порт может выйти при истечении протокольного тайм-аута с переходом в состояние "обучение" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может выйти при получении ПБДМ этим или другим портом и войти в состояние "блокирование" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может перейти в состояние "неактивное" или "блокирование" в результате действий диспетчера.
4.4.3 Обучение
В этом состоянии порт готовится к участию в ретрансляции кадров. Ретрансляция кадров временно деактивизируется с целью предотвращения временных шлейфов данных, которые могут появиться в мостовой ЛВС во время существования этого состояния, при изменении активной топологии мостовой ЛВС. Обучение активизировано с тем, чтобы иметь возможность получать информацию до ретрансляции кадров с целью снижения объема ретрансляции необязательных кадров.
Процесс продвижения должен аннулировать принимаемые кадры. Он не должен направлять продвигаемые кадры для передачи. Процесс обучения должен вводить информацию о местоположении станции в базу данных фильтрации.
Протокольный логический объект моста должен включать порт в свои вычисления активной топологии. Поступающие ПБДМ должны обрабатываться в соответствии с требованиями алгоритма и протокола покрывающего дерева. ПБДМ могут направляться для передачи.
В это состояние порт вводится из состояния "прослушивание" операциями алгоритма и протокола покрывающего дерева по истечении протокольного тайм-аута.
Из этого состояния порт может выйти при истечении протокольного тайм-аута с переходом в состояние "продвижение" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может выйти при получении ПБДМ этим или другим портом и войти в состояние "блокирование" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может перейти в состояние "неактивное" или "блокирование" в результате действий диспетчера.
4.4.4 Продвижение
В этом состоянии порт участвует в ретрансляции кадров. Процесс продвижения может продвигать полученные кадры. Он может предоставлять продвинутые кадры для передачи. Процесс обучения должен вводить информацию о местоположении станции в базу данных фильтрации.
Протокольный логический объект моста должен включать порт в свои вычисления активной топологии. Принятые ПБДМ должны обрабатываться в соответствии с алгоритмом и протоколом покрывающего дерева. ПБДМ могут направляться для передачи.
В это состояние порт вводится из состояния обучения операциями алгоритма и протокола покрывающего дерева по истечении протокольного тайм-аута.
Из этого состояния порт может выйти при получении ПБДМ этим или другим портом и войти в состояние "блокирование" в результате операций алгоритма и протокола покрывающего дерева. Из этого состояния порт может перейти в состояние "неактивное" или "блокирование" в результате действий диспетчера.
4.4.5 Неактивное состояние
В этом состоянии порт не участвует в ретрансляции кадров и в операциях алгоритма и протокола покрывающего дерева.
Процесс продвижения должен аннулировать полученные кадры. Он не должен направлять кадры для передачи. Процесс обучения не должен вводить информацию о местоположении станции в базу данных фильтрации.
Протокольный логический объект моста не должен включать порт в свои вычисления активной топологии. Поступающие ПБДМ не должны обрабатываться в соответствии с алгоритмом и протоколом покрывающего дерева. ПБДМ не должны направляться для передачи.
В это состояние порт вводится из любого другого состояния операциями диспетчера.
Порт выходит из этого состояния по разрешению диспетчера и входит в состояние "блокирование".
4.5 Параметры и тайм-ауты протокола
Информация передается между протокольными логическими объектами отдельных мостов путем передачи кадров, содержащих ПБДМ. В данном подразделе определены параметры, содержащиеся в двух типах ПБДМ: "конфигурация" и "уведомление об изменении топологии". Кодирование этих параметров и дополнительных информационных элементов определено в разделе 5.
Каждый протокольный логический объект моста обеспечивает множество параметров и тайм-аутов независимо от отдельных портов, количества тайм-аутов и параметров каждого порта. В данном подразделе определяются эти параметры, их использование и условия их модификации.
4.5.1 Параметры ПБДМ "конфигурация"
4.5.1.1 Идентификатор корневого моста
Это уникальный идентификатор того моста, который мост, передающий ПБДМ "конфигурация", считает корневым.
Он передается для того, чтобы позволить всем мостам согласовать этот корневой мост.
4.5.1.2 Стоимость маршрута к корневому мосту
Этот параметр определяет стоимость маршрута к корневому мосту, указанному идентификатором корневого моста, выданным передающим мостом.
Он передается для того, чтобы мост принял решение: какой из мостов, подключенных к ЛВС, из которой получен ПБДМ "конфигурация", обеспечит самую дешевую стоимость маршрута к корневому мосту для данной ЛВС.
4.5.1.3 Идентификатор моста
Уникальный идентификатор моста, передающего ПБДМ "конфигурация".
Этот параметр передается для того, чтобы мост:
1) определил в случае с ЛВС, к которой подключено два или более мостов, какие из них обеспечивают равноценные по стоимости маршруты к корневому мосту и какой следует определить как назначенный мост для данной ЛВС;
2) выявил случаи, когда два или более портов одного и того же моста подключены к одной и той же ЛВС, т.е. находятся в прямой взаимосвязи через маршрут мостовой ЛВС, ни один из компонентов которой не работает по алгоритму и протоколу покрывающего дерева.
4.5.1.4 Идентификатор порта
Это идентификатор порта передающего моста, через который передан ПБДМ "конфигурация". Он однозначно идентифицирует порт этого моста.
Этот параметр передается для того, чтобы в случае подключения к ЛВС двух или более портов одного и того же моста мост мог решить, какие из портов подсоединены.
4.5.1.5 Время существования сообщения
Этот параметр указывает время существования сообщения "конфигурация", отсчитываемое от момента генерации ПБДМ "конфигурация" корневым мостом, который стимулирует генерацию этого ПБДМ.
Он передается мосту для того, чтобы разрешить ему аннулировать информацию, время существования которой превысило максимальное время существования (см. ниже).
4.5.1.6 Максимальное время существования
Этот параметр указывает значение тайм-аута, которое должны использовать все мосты мостовой ЛВС. Это значение устанавливается корневым мостом.
Он передается каждому мосту мостовой ЛВС с тем, чтобы они имели согласованные значения, относительно которых проверяется время существования хранимой информации о конфигурации.
4.5.1.7 Время заявки
Этот параметр указывает интервал времени, отсчитываемый с момента генерации корневым мостом ПБДМ "конфигурация".
Он не используется непосредственно алгоритмом связующего дерева, однако переносится в ПБДМ "конфигурация", чтобы облегчить функциям диспетчера управление работой протокола.
4.5.1.8 Задержка продвижения
Этот параметр указывает значение тайм-аута, которое должны использовать все мосты мостовой ЛВС. Значение задержки продвижения устанавливается корневым мостом.
Он передается для того, чтобы все мосты мостовой ЛВС использовали согласованное значение тайм-аута задержки продвижения при переходе порта из текущего состояния в состояние продвижения. Этот параметр используется так же как значение тайм-аута для времени старения динамических записей в базе данных фильтрации, отсчитываемое после изменения активной топологии.
4.5.1.9 Подтверждение изменения топологии
Флаг, устанавливаемый мостом, который является назначенным для данной ЛВС и который передает ПБДМ "конфигурация" в ответ на полученный ПБДМ "уведомление об изменении топологии".
Этот параметр передается для того, чтобы обеспечить протокол надежного подтверждения с целью уведомления корневого моста об изменениях в активной топологии.
4.5.1.10 Изменение топологии
Флаг, устанавливаемый корневым мостом во всех ПБДМ, передаваемых после уведомления об изменении топологии или при обнаружении такого изменения.
Этот параметр передается для информирования всех мостов мостовой ЛВС о произошедшем изменении активной топологии в части мостовой ЛВС и о необходимости быстрого обновления устаревших записей в базе данных фильтрации с целью ограничения влияния временной изоляции оконечных систем, подключенных к мостовой ЛВС, обусловленной использованием некорректной информации в базе данных фильтрации.
Значение времени старения применительно к динамическим записям базы данных фильтрации становится равным значению параметра задержки продвижения, хранимого для данного моста; т.е. после истечения тайм-аута задержки продвижения при установленном флаге "изменение топологии" во всех сообщениях конфигурации, полученных из корневого моста, в базе данных фильтрации остаются только те динамические записи, которые были созданы или смодифицированы в этот период.
4.5.2 Параметры ПБДМ "уведомление об изменении топологии"
Этот ПБДМ не содержит параметров.
4.5.3 Параметры моста
4.5.3.1 Корневой назначенный мост
Это уникальный идентификатор моста, который предполагается корневым мостом. Этот параметр используется в качестве значения параметра "идентификатор корневого моста" во всех ПБДМ "конфигурация", передаваемых этим мостом.
4.5.3.2 Стоимость маршрута к корневому мосту
Этот параметр указывает стоимость маршрута от данного моста к корневому мосту. Она равна сумме значений параметров "назначенная стоимость" и "стоимость маршрута", хранимых для данного порта моста. Если данный мост является корневым, этот параметр имеет значение ноль.
Этот параметр используется:
1) для проверки значения параметра "стоимость маршрута к корневому мосту", доставленного в полученном ПБДМ "конфигурация";
2) в качестве значения параметра "стоимость маршрута к корневому мосту", предложенного во всех ПБДМ "конфигурация", переданных данным мостом.
4.5.3.3 Порт корневого моста
Это идентификатор порта, обеспечивающего наименьшую стоимость маршрута к корневому мосту, т. е. порта, для которого сумма значений параметров "назначенная стоимость" и "стоимость маршрута", хранимых для данного порта, является наименьшей.
Если два или более портов обеспечивают одинаковые самые дешевые маршруты к корневому мосту, то портом корневого моста выбирается тот из них, у которого наиболее высокоприоритетный параметр "идентификатор моста", хранимый в виде параметра "назначенный мост" для этого порта.
Если два или более портов обеспечивают одинаковые самые дешевые маршруты к корневому мосту и имеют одинаковые значения параметра "назначенный мост", то портом корневого моста выбирается тот из них, который имеет наиболее высокоприоритетный параметр "назначенный порт", хранимый для данного порта.
И наконец, если два или более портов обеспечивают равные по стоимости маршруты к корневому мосту и имеют одинаковые значения параметров "назначенный мост" и "назначенный порт", то портом корневого моста становится тот из них, который имеет наиболее высокоприоритетный параметр "идентификатор порта". Для различных портов одного и того же моста гарантируется свой, отличный от других, идентификатор и тем самым обеспечивается развязка тупиковых ситуаций.
Этот параметр используется для идентификации порта, через который устанавливается маршрут к корневому мосту. Он теряет свою значимость, когда мост становится корневым и устанавливается в ноль.
4.5.3.4 Максимальное время существования
Этот параметр указывает максимальное время существования полученной протокольной информации, отсчитываемое до момента ее аннулирования.
4.5.3.5 Время заявки
Этот параметр указывает интервал времени между передачами ПБДМ "конфигурация" мостом, который пытается стать корневым или уже является таковым.
4.5.3.6 Задержка продвижения
Этот параметр указывает время, затрачиваемое в состоянии "прослушивание" на переход из состояния "блокирование" в состояние "обучение".
Это время, затрачиваемое в состоянии "обучение" на переход из состояния "прослушивание" в состояние "продвижение".
Этот параметр используется для отсчета времени существования динамических записей в базе данных фильтрации, когда в протокольных сообщениях, полученных из корневого моста, установлен флаг "изменение топологии"
4.5.3.7 Идентификатор моста
Это уникальный идентификатор моста, используемый в качестве значения:
1) параметра "идентификатор моста" во всех ПБДМ "конфигурация", передаваемых данным мостом;
2) параметра "корневой назначенный мост", когда мост является корневым или пытается стать таковым после истечения всей информации, касающейся текущего корневого моста, или в результате действий диспетчера.
Этот параметр содержит две части, одна из которых образуется из уникального адреса моста (см. 3.12.5) и гарантирует уникальность идентификатора моста в мостовой ЛВС, а другая позволяет отрегулировать приоритетность идентификатора моста и считается наиболее значимой частью при сравнении приоритетов. Эта приоритетная часть данного параметра может быть скорректирована действиями диспетчера.
4.5.3.8 Максимальное время существования моста
Это значение параметра "максимальное время существования", которое он принимает, когда мост является корневым или пытается стать таковым.
Этот параметр может быть скорректирован действиями диспетчера.
4.5.3.9 Мостовое время заявки
Этот параметр указывает значение параметра "время заявки", которое он принимает, когда мост является корневым или пытается стать таковым.
Он определяет интервал времени между передачами ПБДМ "уведомление об изменении топологии" по направлению к корневому мосту, когда мост пытается уведомить назначенный мост данной ЛВС, к которой подключен его порт корневого моста, об изменении топологии.
Этот параметр может быть скорректирован действиями диспетчера.
4.5.3.10 Мостовая задержка продвижения
Этот параметр указывает значение параметра "задержка продвижения", которое он принимает, когда мост является корневым или пытается стать таковым. Он может быть скорректирован действиями диспетчера.
4.5.3.11 Обнаружено изменение топологии
Это булевый параметр, устанавливаемый в значение "истинно" для регистрации изменений топологии, которые были обнаружены мостом или сообщены мосту.
Он используется:
1) с целью содействия регулярности передач через интервалы, определяемые параметром "время заявки моста" ПБДМ "уведомление об изменении топологии" в направлении корневого моста, где данный мост не является корневым;
2) в значении "истинно" чтобы установить параметр "изменение топологии" для данного моста в значение "истинно", если этот мост является или становится корневым.
4.5.3.12 Изменение топологии
Это булевый параметр, устанавливаемый для регистрации значения флага "изменение топологии" в ПБДМ "конфигурация", подлежащих передаче мостом в те ЛВС, для которых данный мост является назначенным.
Если этот параметр имеет значение "истинно", то тайм-аут существования записей в базе данных фильтрации принимает значение параметра "задержка продвижения". Динамические записи, время существования которых превысило это значение, удаляются из базы данных фильтрации.
Если этот параметр имеет значение "ложно", то тайм-аут старения записей в базе данных фильтрации принимает значение параметра "время старения". Время старения может быть установлено диспетчером (см. раздел 6).
4.5.3.13 Время изменения топологии
Этот параметр указывает период времени, в течение которого ПБДМ передаются с флагом "изменение топологии", установленным корневым мостом после обнаружения изменения топологии.
Значение этого параметра равно сумме значений параметров "максимальное мостовое время существования" и "мостовая задержка продвижения". Любой из этих составляющих параметров может быть скорректирован действиями диспетчера.
4.5.3.14 Время удержания
Этот параметр определяет минимальный период времени между передачами ПБДМ "конфигурация" через данный порт корневого моста. В любой период времени удержания не должно передаваться более двух ПБДМ "конфигурация".
Он является постоянным параметром моста. Его значение определено в таблице 4.3.
4.5.4 Тайм-ауты моста
4.5.4.1 Тайм-аут заявки
Служит для обеспечения периодической передачи ПБДМ "конфигурация" мостом, когда он является или пытается стать корневым.
Значение этого тайм-аута определяется мостовым параметром "время заявки".
4.5.4.2 Тайм-аут уведомления об изменении топологии
Должен гарантировать, что назначенный мост ЛВС, к которой подключен мост с портом корневого моста, будет проинформирован об обнаруженном изменении топологии.
Значение этого тайм-аута определяется мостовым параметром "время заявки моста".
4.5.4.3 Тайм-аут изменения топологии
Служит для определения периода времени, в течение которого передаются ПБДМ "конфигурация" с флагом "изменение топологии", установленным мостом, когда он становится корневым после обнаружения изменения топологии.
Значение этого тайм-аута определяется мостовым параметром "время изменения топологии".
4.5.5 Параметры порта
4.5.5.1 Идентификатор порта
Это идентификатор соответствующего порта, используемый в виде значения параметра "идентификатор порта" всех ПБДМ "конфигурация", передаваемых в соответствующий порт.
Этот параметр состоит из двух частей. Одна часть отражает фиксированное отношение к физическим портам, обеспечиваемым реальным оборудованием. Порты идентифицируются небольшими числами от единицы и выше. Эта часть параметра гарантирует уникальность идентификатора порта среди всех портов одного моста. Другая часть параметра позволяет регулировать приоритет порта и при сравнении приоритетов считается наиболее значимой частью. Приоритетная часть этого параметра может быть скорректирована действиями диспетчера.
4.5.5.2 Состояние
Этот параметр указывает текущее состояние порта (т.е. неактивное, прослушивание, обучение, продвижение или блокирование).
Он используется для управления приемом кадров из логического объекта УДС соответствующего порта, процессами обучения и продвижения, продвижением кадров процессом продвижения в данный логический объект УДС, передачей и приемом ПБДМ (см. 4.4).
Он модифицируется действиями протокола и может также корректироваться действиями диспетчера.
4.5.5.3 Стоимость маршрута
Этот параметр указывает долю стоимости маршрута, проходящего через данный порт, когда он является портом корневого моста, в общей стоимости маршрута к корневому мосту для данного моста.
Значение этого параметра, добавленное к значению параметра "назначенная стоимость" для порта корневого моста, используется в качестве значения параметра "стоимость маршрута к корневому мосту", содержащегося во всех ПБДМ "конфигурация", передаваемых мостом, когда он не является корневым.
Этот параметр может быть скорректирован действиями диспетчера.
4.5.5.4 Корневой назначенный мост
Это уникальный идентификатор моста, зарегистрированного как корневой мост в параметре "идентификатор корневого моста" ПБДМ "конфигурация", передаваемых назначенным мостом для той ЛВС, к которой подключен этот порт.
Этот параметр используется для проверки значения параметра "идентификатор корневого моста", содержащегося в полученном ПБДМ "конфигурация".
4.5.5.5 Назначенная стоимость
Этот параметр указывает стоимость маршрута к корневому мосту, установленную назначенным портом той ЛВС, к которой этот порт подключен.
Он используется для проверки значения параметра "стоимость маршрута к корневому мосту", содержащегося в полученном ПБДМ "конфигурация".
4.5.5.6 Назначенный мост
Это уникальный идентификатор моста, предполагающего стать назначенным мостом для ЛВС, связанной с данным портом.
Этот параметр используется:
1) вместе с параметрами порта "назначенный порт" и "идентификатор порта" для того, чтобы определить, должен ли этот порт стать назначенным для ЛВС, к которой он подключен;
2) для проверки значения параметра "идентификатор моста", содержащегося в полученном ПБДМ "конфигурация".
4.5.5.7 Назначенный порт
Это идентификатор порта, который предполагает стать назначенным портом для ЛВС, к которой этот порт подключен.
Этот параметр используется:
1) вместе с параметрами порта "назначенный мост" и "идентификатор порта" для того, чтобы определить, должен ли этот порт стать назначенным портом для ЛВС, к которой он подключен;
2) диспетчером для определения топологии мостовой ЛВС.
4.5.5.8 Подтвердить изменение топологии
Этот параметр указывает значение флага "подтверждение изменения топологии" в следующем ПБДМ "конфигурация", который должен быть передан соответствующему порту.
Он используется для того, чтобы зарегистрировать необходимость установки флага "подтверждение изменения топологии" в ответ на полученный ПБДМ "уведомление об изменении топологии".