Мосты Ethernet

PDF

По материалам стандарта 802.1D-2004 – IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges.

Маркировка разделов и ссылки соответствуют указанному выше документу.

7. Принципы работы моста

В этом разделе

1. Разъяснены основные элементы работы мостов (Bridge) и перечислены поддерживаемые ими функции.

2. Описана архитектурная модель моста, регулирующая предоставление функций.

3. Представлена модель работы моста в терминах процессов (Process) и объектов (Entity), поддерживающих функции моста.

4. Детализированы требования к локальным сетям на базе мостов (Bridged Local Area Network) и задана адресация объектов в мостах.

7.1 Работа моста

Основными элементами работы моста являются:

1. трансляция и фильтрация кадров;

2. поддержка информации, требуемой для принятия решений о фильтрации и трансляции;

3. управление перечисленным выше.

7.1.1 Трансляция

Мост MAC транслирует отдельные пользовательские кадры данных между устройствами MAC в среде ЛВС на основе мостов, подключенными к портам этого моста. Ниже перечислены функции для поддержки трансляции кадров и QoS.

1. Прием кадров.

2. Отбрасывание кадров с ошибками (6.3.2).

3. Отбрасывание кадров, в которых frame_type отличается от user_data_frame (6.4).

4. Регенерация приоритета пользователя при необходимости (6.4).

5. Отбрасывание кадров для предотвращения петель в физической топологии сети.

6. Отбрасывание кадров для поддержки управления физической топологией сети.

7. Отбрасывание кадров в соответствии с фильтрами.

8. Отбрасывание кадров со служебными данными (service data unit) избыточного размера (6.3.8).

9. Пересылка полученных кадров в другие порты моста.

10. Выбор класса трафика после применения фильтров.

11. Размещение кадров в очередях в соответствии с классом трафика.

12. Отбрасывание кадров в случае превышения ими максимально допустимой задержки для моста (6.3.6).

13. Выбор кадров из очередей для передачи.

14. Выбор выходного приоритета (6.3.9).

15. Отображение служебных данных и новый расчет FCS¹ при необходимости (6.3.7, 7.7.6).

16. Передача кадров.

7.1.2 Данные для фильтрации и трансляции

Мост фильтрует кадры (т. е., не передает кадры полученные портом в другие порты или порт данного моста) для предотвращения дублирования кадров (6.3.4) и обеспечения административного контроля над сетевыми ресурсами. Функции, поддерживающие фильтрацию и управление ею, перечислены ниже.

1. Распределенный расчет и настройка состояния Port State (7.4) для каждого Bridge Port в сети с целью создания полного, простого и симметрично подключенного связующего дерева активной топологии.

2. Административная установка состояний MAC_Enabled (6.4.2) или Administrative Bridge Port (14.8.2.2) для исключения портов из активной топологии.

3. Принятая по умолчанию или заданная администратором конфигурация протокола RSTP² (раздел 17) для включения в активную топологию конкретных портов моста и подключенных к нему ЛВС.

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

4. Постоянная конфигурация зарезервированных адресов.

5. Явная настройка статических фильтров.

6. Автоматическое определение динамических данных фильтрации для индивидуальных адресов получателей на основе наблюдения адресов источников сетевого трафика.

7. Отбрасывание устаревших динамических данных фильтрации.

8. Автоматическое добавление и удаление динамических данных фильтрации в результате обменов GMRP.

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

9. Явная настройка классов трафика, связанная с портами моста.

7.1.3 Управление мостом

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

 
Рисунок 7-1. ЛВС на основе мостов.

7.2 Архитектура моста

Модель моста включает:

1. транслятор MAC Relay Entity, соединяющий порты моста;
2. не менее двух портов;

3. объекты вышележащего уровня (Higher-Layer Entity), включая не менее одного объекта STP (Spanning Tree Protocol Entity).

Транслятор MAC выполняет независимые от метода доступа к среде функции (Media Access Method Independent Function) трансляции кадров между портами моста, фильтрации кадров и получения динамических данных фильтрации. Он использует внутренний сервисный подуровень (Internal Sublayer Service, 6.4, 6.5), обеспечиваемый отдельными объектами MAC на каждом порту.

Каждый порт моста получает кадры из подключенной к нему ЛВС и передает кадры в ЛВС. Отдельный объект MAC (MAC Entity), постоянно связанный с портом, обеспечивает внутренний сервис (6.4, 6.5) для приема и передачи кадров. Объекты MAC выполняют все функции, зависящие от метода доступа к среде (Media Access Method Dependent Function), т. е. протокол и процедуры MAC.

Объект STP рассчитывает и настраивает активную топологию сети.

Объект STP и другие пользователи вышележащего уровня, такие как управление мостом (Bridge Management, 7.1.3), и объекты GARP, включая GARP Participant (Раздел 12), используют процедуры управления логическим каналом (LLC³). Эти процедуры обеспечиваются раздельно для каждого порта и используют сервис MAC, предоставляемый отдельными объектами MAC.

Рисунок 7-2. Порты моста.

На рисунке 7-1 приведен пример физической топологии ЛВС на основе мостов. ЛВС соединяются мостами MAC Bridge и каждый порт моста служит для подключения одной ЛВС. На рисунке 7-2 показан мост с двумя портами, а на рисунке 7-3 – архитектура такого моста. Термин «объекты LLC» (LLC Entities) на рисунках 7-3 и 7-9 относится к объединению функций канального уровня (включая демультиплексирование), обеспечиваемых LLC (ISO/IEC 8802-2), а интерпретация типа в поле Length/Type соответствует стандарту IEEE Std 802.3.

 
Рисунок 7-3. Архитектура моста.

7.3 Модель работы

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

Параграфы 7.5 и 7.6 задают использование объектом трансляции MAC (MAC Relay Entity) внутреннего сервисного подуровня. Информация о состоянии порта (Port State, 7.4) регулирует участие каждого порта в работе ЛВС.

Кадры воспринимаются для передачи и доставляются процессам и объектам (и от них), моделирующим работу объекта трансляции MAC в мостах. Эти объекты и процессы перечислены ниже.

1. Процесс пересылки (7.7) отправляет полученные кадры, которые будут транслироваться в другие порты моста, фильтруя кадры на основе данных из базы фильтров (Filtering Database, 7.9) и состояния портов моста (7.4).
2. Процесс обучения (Learning Process, 7.8) на основе наблюдаемых адресов отправителей в кадрах, принятых каждым портом, обновляет базу фильтров (7.9) с учетом состояния порта (7.4).

3. База фильтров (Filtering Database, 7.9) содержит данные для фильтрации и поддерживает запросы процесса пересылки о возможности отправки кадров с данным полем MAC Address для получателя в данный порт.

Каждый порт моста работает также в качестве конечной станции, обеспечивающей сервис MAC подуровню LLC, который, в свою очередь, поддерживает работу объекта STP (7.10) и других возможных пользователей LLC, таких как протоколы управления мостом (7.11).

Каждый порт моста должен поддерживать работу процедур LLC типа 1 для обеспечения работы объекта STP. Порты моста могут поддерживать другие типы процедур LLC, которые могут использоваться другими протоколами.

 
Рисунок 7-4. Трансляция кадров MAC.

На рисунке 7-4 показан пример трансляции кадра между портами двухпортового моста.

 
Рисунок 7-5. Наблюдение сетевого трафика.

На рисунке 7-5 проиллюстрировано включение информации, передаваемой в одном кадре, принятом на одном из портов двухпортового моста в базу фильтров (Filtering Database).

 
Рисунок 7-6. Работа GARP.

На рисунке 7-6 показаны прием и передача кадра BPDU4 объектом STP.

Рисунок 7-7. Работа протокола соединения между мостами.

На рисунке 7-7 показано получение и передача GARP PDU5 объектом GARP (7.10).

7.4 Состояние портов и активная топология

Каждый порт моста имеет рабочее состояние (Port State), которое управляет пересылкой кадров MAC этим портом и использованием адресов отправителей в кадрах для обучения.

Активная топология сети на основе мостов в любой момент представляет собой набор коммуникационных путей, образованных соединениями между ЛВС и мостами через пересылающие порты. Функция распределенного алгоритма связующего дерева (Spanning Tree) и реализующего его протокола (раздел 17) заключается в установке состояния портов для создания активной топологии, которая просто обеспечивает пересылку кадров между любой заданной парой MAC-адресов, используемых конечными станциями ЛВС. Пересылка и обучение, выполняемые каждым портом моста, поддерживается динамически для предотвращения временных петель и избыточного трафика в сети с минимизацией отказов в обслуживании в результате изменения физической топологии сети.

Любому порту, который не включен (например, имеет MAC_Operational = False, 6.4.2 или исключен из активной топологии путем установки Administrative Bridge Port State = Disabled, 14.8.2.2) или был динамически исключен из процесса пересылки и обучения, назначается состояние Discarding (отбрасывание кадров). Любому порту, на котором разрешено обучение, но запрещена пересылка, назначается состояние Learning, а порту с разрешенным обучением и пересылкой – Forwarding.

Примечание. Текущая база IETF Bridge MIB (IETF RFC 1493) использует состояния (dot1dStpPortState) disabled (отключен), blocking (заблокирован), listening (прослушивание), learning (обучение), forwarding (пересылка) и broken (оторван от сети). Состояния learning и forwarding точно соответствуют состояниям Learning и Forwarding, заданным этим стандартом. Состояния disabled, blocking, listening и broken соответствуют состоянию порта Discarding – хотя эти значения dot1dStpPortState служат для указания различных причин отбрасывания кадров, в процессах Forwarding и Learning они не различаются. Состояние dot1dStpPortState = broken представляет отказ или недоступность MAC для порта, как указано MAC_Operational = FALSE. Состояние disabled представляет исключение порта из активной топологии административными мерами (Administrative Port State = Disabled). Состояние blocking представляет исключение порта из активной топологии алгоритмом STP (роль порта Alternate или Backup, 17.7), listening представляет порт, который алгоритмом STP выбран в качестве участника активной топологии (роль порта Root или Designated), но временно отбрасывает кадры для защиты от петель или некорректного обучения.

На рисунке 7-6 показана работа объекта STP, который использует алгоритм Spanning Tree и связанные с ним протоколы, а также изменение данных состояния порта в процессе определения активной топологии ЛВС.

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

На рисунке 7-5 показано использование данных состояния для порта, принимающего кадр, процессом обучения (Learning) с целью определения возможности включения данных о местонахождении станции в базу фильтров (Filtering Database).

7.5 Прием кадра

Отдельный объект MAC каждого Bridge Port проверяет все кадры, передаваемые в подключенной ЛВС.

Принятые кадры без ошибок (error-free) получают индикацию M_UNITDATA⁶, обработка которой описана ниже.

Кадры с M_UNITDATA.indication frame_type = user_data_frame (6.4) нужно представлять процессам обучения и пересылки. Кадры с другими значениями frame_type не нужно представлять процессу пересылки, но они могут представляться процессу обучения.

Кадры с frame_type = user_data_frame, конечным получателем которых является порт моста, нужно представлять подуровню LLC. Такие кадры содержат индивидуальный MAC-адрес порта или связанный с портом адрес группы (7.12) в поле адреса получателя. Кадры, поданные LLC, могут также передаваться процессу пересылки, как указано выше.

Кадры, адресованные в порт моста (как конечную станцию) и ретранслированные в данный порт другим портом того же моста, тоже нужно представлять подуровню LLC. Никакие другие кадры в LLC не подаются.

7.5.1 Регенерация приоритета пользователя

Значение user_priority в каждом принятом кадре восстанавливается на основании полученного в кадре значения user_priority и таблицы регенерации (User Priority Regeneration) для принимающего порта. Таблица задает восстановленное значение user_priority для каждого из восьми7 возможных значений (от 0 до 7) user_priority в принятых кадрах. В таблице 7-1 приведены используемые по умолчанию значения, которые следует применять как исходные в таблицах каждого порта.

Таблица User Priority Regeneration может быть изменена системой управления, как описано в разделе 14. В таких случаях система управления должна быть способна независимо установить записи каждой таблицы для всех приемных портов и полученных значений user_priority и все значения должны лежать в диапазоне из таблицы 7-1.

Примечание. Значения в таблице User Priority Regeneration для данного порта должны быть согласованы с user_priority для трафика, полученного через данный порт, в остальной части сети и следует генерировать подходящие значения приоритета доступа для каждого MAC. Значения user_priority используются:

• через таблицу классов трафика (7.7.3) при определении класса для данного выходного порта;

• через фиксированные, связанные с MAC отображения (7.7.5) для определения приоритета доступа.

В таблице 7-1 показаны принятые по умолчанию значения для регенерации приоритета. В таблице приведены значения таблицы классов трафика для всех возможных количеств поддерживаемых классов. В таблице 7-4 указаны фиксированные отображения user_priority на приоритет доступа, которые требуются для разных методов выходных MAC.

Таблица 7-1. User Priority Regeneration.

Приоритет пользователя	Восстановленный приоритет по умолчанию	Диапазон
0	0	0-7
1	1	0-7
2	2	0-7
3	3	0-7
4	4	0-7
5	5	0-7
6	6	0-7
7	7	0-7

7.6 Передача кадра

Отдельный объект MAC для каждого порта передает кадры, поданные в порт объектом MAC Relay.

Ретранслированные кадры представляются для передачи посредством Forwarding Process. Примитив M_UNITDATA.request связанный с таким кадром содержит поля адресов получателя и отправителя, полученные в соответствующем примитиве M_UNITDATA.indication.

LLC PDU представляются подуровнем LLC как пользователи сервиса MAC, обеспечиваемого Bridge Port. Кадры, передаваемые для доставки PDU, содержат индивидуальный MAC-адрес порта в поле отправителя.

Каждый кадр передается в соответствии с процедурами MAC для конкретной технологии IEEE 802 LAN. В поле frame_type соответствующего M_UNITDATA.request должно быть значение user_data_frame (6.5).

Кадры, переданные по запросу пользователя LLC сервиса MAC, обеспечиваемого портом, также должны представляться объекту MAC Relay.

7.7 Процесс пересылки

Кадры, отправленные Forwarding Process после приема любым из портов моста (7.5), нужно пересылать через другой порт моста, выбранный функциями процесса пересылки. Эти функции учитывают топологические ограничения (7.7.1), использует Filtering Database для фильтрации кадров (7.7.2), помещают кадры в очереди (7.7.3), выбирают кадры из очередей для передачи (7.7.4), отображают приоритеты (7.7.5) и при необходимости перечитывают FCS (7.7.6).

Функции Forwarding Process описаны в параграфах 7.7.1–7.7.6 в терминах действий, выполняемых для данного кадра, полученного на данном порту (приемный порт). Кадры могут пересылаться для передачи в выходные порты (порты передачи), а также отбрасываться без передачи в другой порт.

Примечание. Это описание процесса пересылки ограничивается работой функции трансляции MAC Bridge и не рассматривает действия реальных реализаций после передачи кадра уровню MAC для отправки. В некоторых реализациях MAC при определенных условиях может возникать та или иная неопределенность между передачей выбранных кадров уровню MAC для отправки и реальной последовательностью кадров в среде ЛВС. Примером этого могут служить разные значения Token Holding Time в ЛВС FDDI. Такие неопределенности могут приводить к кажущемуся нарушению правил постановки в очередь и приоритизации. В результате становится невозможной проверка соответствия стандарту для некоторых реализаций путем простого сопоставления наблюдаемого в ЛВС трафика с описываемой моделью Forwarding Process. Проверки соответствия должны также учитывать поведение реализации MAC.

На рисунке 7-4 показана работа процесса пересылки с одним экземпляром кадра, транслируемого между портами двухпортового моста. На рисунке 7-8 представлены детали Forwarding Process.

 
Рисунок 7-8. Операции процесса пересылки.

7.7.1 Соблюдение активной топологии

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

1. Принявший кадр Port находился в состоянии Forwarding (7.4).
2. Предполагаемый порт передачи находится в состоянии Forwarding.
3. Предполагаемый порт передачи не является принявшим кадр портом.
4. Размер mac_service_data_unit в кадре не превышает максимальное значение mac_service_data_unit в ЛВС, подключенной к порту, предполагаемому для передачи.

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

7.7.2 Фильтрация кадров

Решение о фильтрации принимается процессом пересылки на основании:

1. MAC-адреса получателя в принятом кадре;
2. информации в Filtering Database для данного MAC-адреса и приемного порта;

3. принятого по умолчанию поведения групповой фильтрации для возможного порта передачи (7.9.4).

Для каждого возможного порта передачи (7.7.1) кадр должен пересылаться или отбрасываться (фильтроваться) в соответствии с определением типов записей в Filtering Database (7.9.1, 7.9.2, 7.9.3). Требуемое поведение пересылки и фильтрации описано в параграфах 7.9.4, 7.9.5 и таблицах 7-6, 7-7 и 7-8.

7.7.3 Постановка кадра в очередь

Процесс пересылки обеспечивает хранилище для помещенных в очередь кадров, ожидающих представления конкретным объектам MAC для каждого Bridge Port с целью передачи. Порядок кадров, полученных на одном порту моста должен сохраняться для:

1. индивидуальных кадров с данным значением user_priority и комбинацией destination_address и source_address;
2. групповых кадров с данным user_priority и destination_address.

Процесс пересылки может поддерживать более одной очереди на передачу для данного Bridge Port. Кадры помещаются в очереди на основе значений user_priority (7.5.1) с использованием таблицы классов трафика, которая является частью данных состояния, связанных с каждым портом. Очереди и классы трафика связаны взаимно-однозначным отображением.

Таблицы классов поддерживают до восьми классов трафика, что позволяет разделить очереди для каждого уровня user_priority. Классы трафика нумеруются от 0 до N-1, где N указывает число классов трафика для данного выходного порта. Таблицы классов трафика могут быть управляемыми. Класс трафика 0 соответствует неускоренному (nonexpedited) трафику, остальные соответствуют в той или иной мере ускоренным классам.

Примечание. В конкретном мосту может быть реализовано разное число классов трафика для различных портов. Порты с уровнями MAC, которые поддерживают один уровень приоритета передачи типа CSMA/CD, могут поддерживать более одного класса трафика.

Если процесс пересылки не поддерживает ускоренные классы трафика для данного порта (т. е. для порта имеется единственный класс), все значения user_priority отображаются на класс 0. В мостах с поддержкой ускоренного трафика рекомендуемые отображения user_priority для разного числа классов показаны в таблице 7-2. Каждая запись таблицы указывает класс трафика, назначенный для кадров с данным user_priority.

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

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

Кадры, помещенные в очередь передачи для порта, нужно удалять из этой очереди, для выполнения требований к максимальной транзитной задержке в мосту (6.3.6, таблица 7-3).

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

Таблица 7-2. Рекомендуемые отображения user_priority на класс трафика⁸.

 

		Число доступных классов трафика
		1	2	3	4	5	6	7	8
Пользовательский приоритет	0 (по умолч.)	0	0	0	1	1	1	1	2
	1	0	0	0	0	0	0	0	0
	2	0	0	0	0	0	0	0	1
	3	0	0	0	1	1	2	2	3
	4	0	1	1	2	2	3	3	4
	5	0	1	1	2	3	4	4	5
	6	0	1	2	3	4	5	5	6
	7	0	1	2	3	4	5	5	7

 

Таблица 7-3. Допустимая транзитная задержка в мосту.

7.7.4 Выбор для передачи

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

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

2. Для данной очереди порядок выбора кадров для передачи должен соответствовать правилам упорядочивания из параграфа 7.7.3.

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

7.7.5 Отображение приоритета

Параметр user_priority в примитиве M_UNITDATA.request (6.4) должен совпадать с параметром user_priority в соответствующей индикации данных.

Отображение user_priority на выходной приоритет доступа (access_priority) осуществляется статическими методами уровня MAC. Параметр access_priority в примитиве M_UNITDATA.request (6.4) должен определяться из user_priority в соответствии с таблицей 7-4. Показанные значения должны быть неизменными.

Таблица 7-4. Приоритет доступа на выходе.

user_priority	Приоритет доступа на выходе
	IEEE 802.3	IEEE 802.5	IEEE 802.11	FDDI
0	0	0	0	0
1	0	1	0	1
2	0	2	0	2
3	0	3	0	3
4	0	4	0	4
5	0	5	0	5
6	0	6	0	6
7	0	6	0	6

7.7.6 Перерасчет FCS

Когда кадр пересылается между двумя объектами MAC одного типа IEEE 802 и данные, учтенные в FCS, не изменяются, значение FCS, полученное в примитиве M_UNITDATA.indication может быть представлено в соответствующий примитив M_UNITDATA.request без перерасчета (6.3.7). Для кадров, пересылаемых между ЛВС с одним типом MAC, мост не должен показывать скорость незамеченных ошибок кадров больше, чем будет достигнута сохранением FCS.

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

Примечание. Имеется две возможности расчета действительного значения FCS. В первом случае генерируется новое значение FCS путем алгоритмического изменения полученного значения FCS, с учетом знания алгоритма FCS и преобразований кадра между его приемом и передачей. Второй вариант основан на обычных процедурах MAC для пересчета FCS в исходящем кадре. Первый вариант может защитить от роста числа незамеченных ошибок в кадрах. Этот подход более подробно рассмотрен в информационном Приложении F. Параметр frame_check_sequence в Internal Sublayer Service (6.4) указывает пригодность или непригодность FCS, отсутствие этого параметра в запросе данных указывает передающему уровню MAC, что значение FCS рассчитано заново.

7.8 Процесс обучения

Процесс обучения (Learning Process) наблюдает адреса отправителей в кадрах, полученных на каждом порту, и может обновлять базу фильтров (Filtering Database) в зависимости от состояния принимающего порта.

Процесс обучения должен создавать или обновлять динамический фильтр (Dynamic Filtering Entry, 7.9, 7.9.2) в Filtering Database, связанный с MAC Address, в поле отправителя полученного портом кадра, при выполнении всех перечисленных условий.

1. Принимающий порт находится в состоянии Learning или Forwarding (7.4).

2. Поле адреса отправителя в кадре указывает конкретную конечную станцию (не групповой адрес).

3. Не существует записи Static Filtering Entry (7.9, 7.9.1) для соответствующего MAC-адреса, в которой Port Map задает пересылку (Forwarding) или фильтрацию (Filtering) для данного порта.

4. Результирующее число записей в базе не превышает размер Filtering Database.

Если база Filtering Database уже заполнена, но нужно добавить в нее новую запись, для освобождения места может быть удалена одна из имеющихся записей.

На рисунке 7-5 показана работа процесса обучения при включении в Filtering Database информации о местоположении станции из одного кадра, принятого портом моста.

7.9 База фильтров

База фильтров (Filtering Database) поддерживает запросы процесса пересылки для решения вопросов пересылки кадра, принятого на данном порту с данным MAC-адресом получателя в данный возможный порт передачи (7.7.1, 7.7.2). База содержит записи двух типов:

1. статические, которые явно задаются системой управления;

2. динамические, которые автоматически добавляются в Filtering Database обычными операциями моста и поддерживаемых им протоколов.

Один тип записей (Static Filtering Entry) представляет всю статическую информацию в Filtering Database для индивидуальных и групповых MAC-адресов. Этот тип позволяет контролировать:

3. пересылку кадров по индивидуальным адресам получателей;

4. включение в Filtering Database динамических записей, связанных с расширенными услугами фильтрации (Extended Filtering Services), и использование этой информации.

База фильтров должна содержать записи типа Static Filtering Entry.

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

Для представления динамических фильтров используется два типа записей. Тип Dynamic Filtering Entry используется для указания портов, на которых будут наблюдаться (learning) индивидуальные адреса. Эти записи создаются и обновляются процессом обучения (Learning Process, 7.8), имеют ограниченное время действия и удаляются по окончании срока из Filtering Database. Тип Group Registration Entry поддерживает регистрацию групп MAC-адресов. Эти записи создаются, изменяются и удаляются протоколом GMRP в поддержку расширенных услуг фильтрации (Extended Filtering Services, 6.6.5, 7.9.3, раздел 10) с учетом состояния управляющего элемента Restricted_Group_Registration (10.3.2.3). Если этот элемент имеет значение TRUE, создание Group Registration Entry не разрешено, пока нет записи Static Filtering Entry, которая позволяет динамическую регистрацию для соответствующей группы. Динамические фильтры можно прочитать с помощью удаленного управления через систему Bridge Management (7.11), а также с помощью операций, описанных в разделе 14. Динамические и статические записи включают:

5. спецификацию MAC-адреса;

6. отображение Port Map с управляющим элементом для каждого выходного порта и спецификации MAC-адреса.

Службы фильтрации (Filtering Service), поддерживаемые мостом (базовые и расширенные), определяют принятое по умолчанию поведение моста применительно к пересылке кадров, адресованных группе MAC-адресов. В мостах с поддержкой Extended Filtering Services принятое по умолчанию поведение каждого порта для группы MAC-адресов может быть настроено статически или динамически с помощью записей Static Filtering и/или Group Registration, которые могут содержать приведенные ниже спецификации MAC-адресов.

7. All Group Addresses (все групповые адреса), для которых нет более конкретной записи Static Filtering.

8. All Unregistered Group Addresses (т. е., все групповые MAC-адреса, не указанные в Group Registration Entry), для которых не существует более конкретной записи Static Filtering.

Примечание. Спецификация All Group Addresses [g)] при использовании в записи Static Filtering с подходящей спецификацией элемента управления обеспечивает возможность настроить для моста, который поддерживает Extended Filtering Services, поведение обеспечивающее лишь Basic Filtering Service на некоторых или всех портах. Это может быть обусловлено двумя причинами:

• порты обслуживают «унаследованные» устройства, которые хотят получать групповой трафик, но не способны зарегистрироваться в группе;

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

База Filtering Database должна поддерживать создание, обновление и удаление записей Dynamic Filtering процессом обучения (7.8). В мостах с поддержкой Extended Filtering Services база фильтров должна поддерживать создание, обновление и удаление записей Group Registration протоколом GMRP (раздел 10).

На рисунке 7-4 показано использование Filtering Database процессом пересылки для трансляции кадра между портами двухпортового моста.

Рисунок 7-5 иллюстрирует создание или обновление динамической записи в Filtering Database процессом обучения.

На рисунке 7-6 показана работа объекта STP (7.10) и уведомление им Filtering Database об изменении активной топологии, переданном протоколом STP.

7.9.1 Статические фильтры

Статический фильтр (Static Filtering Entry) задает:

1. спецификацию MAC-адреса, содержащую одно из перечисленных значений:

   1. индивидуальный MAC-адрес;

   2. групповой MAC-адрес;

   3. все групповые адреса, для которых не существует более конкретной записи Static Filtering;

   4. все незарегистрированные групповые адреса, для которых не существует более конкретной записи Static Filtering;

2. отображение Port Map, содержащее элемент управления для каждого выходного порта, указывающий, что кадр с MAC-адресом получателя, который соответствует данной спецификации будет:

   1. пересылаться независимо от динамических фильтров в базе Filtering Database;

   2. фильтроваться независимо от динамических фильтров;

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

Все мосты должны обеспечивать возможность поддержки первых двух вариантов спецификации MAC-адреса и первых двух вариантов элементов управления для всех записей Static Filtering [т. е. должны иметь возможность поддержки пп. a1), a2), b1) и b2)].

Мост с поддержкой Extended Filtering Services должен иметь возможность поддержки всех четырех вариантов спецификации MAC-адреса и всех трех вариантов элемента управления для записей Static Filtering, которые задают групповые MAC-адреса, и может поддерживать все три элемента управления для записей Static Filtering, которые задают индивидуальные MAC-адреса [т. е. должны поддерживаться пп. a1) – a4) и может поддерживаться п. b3) в дополнение к поддержке b1) и b2)].

Для данной спецификации MAC-адреса может создаваться отдельная запись Static Filtering со своим отображением Port Map для каждого входного порта из которого кадры принимаются процессом пересылки.

В дополнение к контролю пересылки кадров записи Static Filtering для групповых MAC-адресов обеспечивают значения Registrar Administrative Control для протокола GMRP (разделы 10 и 12, параграф 12.8.1). Статическая конфигурация пересылки кадров, адресованных конкретной группе, в выходной порт указывается значением Registration Fixed для этого порта (желание получать адресованные в группу кадры даже при отсутствии динамической информации). Статическая конфигурация фильтрации кадров, которые в противном случае могли бы быть отправлены в выходной порт, указывается значением Registration Forbidden. Отсутствие записи Static Filtering для группового адреса или настройка пересылки или фильтрации на основе динамических фильтров указывается значением Normal Registration.

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

7.9.2 Динамические фильтры

Динамический фильтр (Dynamic Filtering Entry) задает:

1. индивидуальный MAC-адрес;

2. отображение Port Map, содержащее элемент управления, который определяет пересылку кадров, направленных по этому MAC-адресу, в один порт.

Примечание 1. Это эквивалентно указанию номера одного порта, поэтому данная спецификация является прямым эквивалентом динамических фильтров IEEE Std 802.1D в редакции 1993 года.

Записи Dynamic Filtering создаются и обновляются процессом обучения (7.8). Они должны автоматически удаляться по истечении заданного времени Ageing Time (таблица 7-5) с момента создания или обновления записи. Для данного MAC-адреса в базе Filtering Database должно создаваться не более одной записи Dynamic Filtering.

Запись Dynamic Filtering не должна создаваться или обновляться процессом обучения, если для этого MAC-адреса уже имеется любая запись Static Filtering со спецификацией элемента управления для выходного порта, указанного процессом обучения, которая задает пересылку или фильтрацию независимо от динамического фильтра.

Примечание 2. Для мостов, которые не разрешают (необязательную) возможность задавать записи Static Filtering для пересылки и фильтрации на основе динамической информации (см. 7.9.1), включая мосты, соответствующие стандарту IEEE Std 802.1D в редакции 1993 года, это препятствует созданию записей Dynamic Filtering, когда для того же MAC-адреса имеется запись Static Filtering. Это гарантирует соответствие таких мостов спецификации, которая запрещает создавать запись Dynamic Filtering при наличии Static Filtering Entry.

Для мостов, которые разрешают возможность задавать записи Static Filtering для пересылки и фильтрации на основе динамической информации, записи Dynamic Filtering и Static Filtering существуют одновременно для одного MAC-адреса, пока адрес не наблюдался (learning) на порту, для которого имеется запись Static Filtering, задающая «пересылку и фильтрацию независимо от какой-либо динамической информации».

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

Записи Dynamic Filtering не могут создаваться или обновляться системой управления.

Если имеется запись Dynamic Filtering для данного MAC-адреса, создание или обновление записи Static Filtering для того же адреса вызывает удаление любой конфликтующей информации, которая может присутствовать в Dynamic Filtering. Если удаление таких конфликтующих данных будет приводить к отображению Port Map, которое не задает пересылки в какой-либо порт, запись Dynamic Filtering удаляется из Filtering Database.

Старение (ageing) записей Dynamic Filtering гарантирует, что конечные станции, которые были перемещены в другую часть сети, не будут «изолированы навсегда» Принимаются также во внимание изменения активной топологии ЛВС на основе мостов, которые могут «перемещать» конечные станции с точки зрения моста (т. е. путь к этим станциям в результате изменения будет проходить через другой порт моста).

Значение Ageing Time может быть задано системой управления (раздел 14). Диапазон возможных значений и рекомендуемое по умолчанию значение указаны в таблице 7-5. Заданное для использования по умолчанию значение избавляет в большинстве случаев от необходимости явной настройки. Если значение Ageing Time может устанавливаться системой управления, мост должен иметь возможность задавать значения из указанного диапазона с шагом в 1 сек.

Таблица 7-5. Время старения записей.

Параметр	Рекомендуемое по умолчанию значение	Диапазон
Время старения (Ageing Time)	300,0 секунд	10,0 – 1000000,0 секунд

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

Алгоритм и протокол RSTP⁹, заданные в разделе 17, включают процедуру уведомления всех мостов в ЛВС на базе мостов об изменении активной топологии, чтобы записи Dynamic Filtering могли быть удалены из Filtering Database. Если топология не меняется, эта процедура позволяет использовать обычное старение с увеличенным сроком, когда конечные станции не генерируют кадров (возможно отключаясь), не жертвуя возможностью ЛВС продолжать обслуживание станций после автоматической настройки.

7.9.3 Записи регистрации групп

Запись регистрации группы (Group Registration Entry) задает:

1. спецификацию MAC-адреса, содержащую одно из перечисленных:

   1. групповой MAC-адрес;

   2. все групповые адреса, для которых не существует более конкретной записи Static Filtering;

   3. все незарегистрированные групповые адреса, для которых не существует более конкретной записи Static Filtering;

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

Записи регистрации групп создаются, изменяются и удаляются с помощью операций GMRP (раздел 10). Для данной спецификации MAC-адреса должно создаваться не более одной записи Group Registration в базе Filtering Database.

Примечание. Возможно наличие записей Static Filtering со значениями Forward или Filter для некоторых или всех портов, маскирующих динамические значения в соответствующих записях Group Registration. Значения в Group Registration будут по-прежнему обновляться GMRP, поэтому последующее обновление данной записи для разрешения использования динамических фильтров на одном или множестве портов незамедлительно активирует корректное состояние регистрации GMRP, которое до этого было замаскировано статической информацией.

7.9.4 Принятая по умолчанию групповая фильтрация

Пересылкой и фильтрацией адресованных в группу кадров на каждом выходном порту моста с поддержкой Extended Filtering Services можно управлять путем создания записи Static Filtering, которая задает принятые по умолчанию действия для All Group Addresses, и записи Static Filtering которая задает принятое по умолчанию поведение для All Unregistered Group Addresses (7.9.1). Оба принятых по умолчанию варианта поведения, измененных более явными записями Filtering Database, применимыми к MAC-адресу в данном кадре, приемному и выходному портам, выглядят, как показано ниже.

Примечание 1. Как сказано в параграфе 7.9.1, мост может поддерживать создание отдельных записей Static Filtering с разными Port Map для каждого приемного порта. Если это не поддерживается, данная запись Static Filtering применяется для всех приемных портов.

1. Пересылка для всех групп. Кадр пересылается, если явная запись Static Filtering не задает фильтрацию вне зависимости от каких-либо динамических фильтров.

2. Пересылка для незарегистрированных групп. Кадр пересылается, если не выполняется ни одно из условий.

   1. Явная запись Static Filtering задает фильтрацию вне зависимости от каких-либо динамических фильтров.

   2. Явная запись Static Filtering задает пересылку или фильтрацию на основе динамической информации и имеется применимая явная запись Group Registration, задающая фильтрацию.

   3. Нет явной применимой записи Static Filtering, но имеется применимая запись Group Registration, задающая фильтрацию.

3. Фильтрация для незарегистрированных групп. Кадр фильтруется, если не выполняется ни одно из условий.

   1. Явная запись Static Filtering Entry задает фильтрацию независимо от каких-либо динамических фильтров.

   2. Явная запись Static Filtering задает пересылку или фильтрацию на основе динамической информации и имеется применимая явная запись Group Registration, задающая пересылку.

   3. Нет явной применимой записи Static Filtering, но имеется применимая запись Group Registration, задающая пересылку.

В мостах с поддержкой Basic Filtering Services по умолчанию для групповой фильтрации используется поведение «пересылать все группы во все порты моста».

Примечание 2. Пересылка всех групп напрямую соответствует поведению, заданному в IEEE Std 802.1D 1993 года, где пересылаются кадры с групповым MAC-адресом, для которых нет статической информации в Filtering Database. Режим Forward All Groups использует информацию из записей Static Filtering для конкретных групповых MAC-адресов, но переопределяет информацию, содержащуюся в записях Group Registration. Режим Forward Unregistered Groups аналогичен поведению пересылки в мосту по отношению к индивидуальным MAC-адресам – если нет статической или динамической информации для конкретного группового MAC-адреса, кадр пересылается, в противном случае пересылка кадра управляется статически заданными или динамически определенными данными.

Примечание 3. Результатом является то, что принятое по умолчанию поведение групповой фильтрации может быть настроено для каждого порта в мосту с помощью записей Static Filtering, которые динамически определяются записями Group Registration создаваемыми или обновляемыми GMRP (раздел 10). Например, при отсутствии в Filtering Database статической или динамической информации для адресов All Group или All Unregistered Group по умолчанию будет использоваться поведение Filter Unregistered Groups для всех портов. Далее создание записи Dynamic Group Registration для адресов All Unregistered Group с Registered на данном порту приведет к тому, что порт будет использовать поведение Forward Unregistered Groups. Аналогично, создание записи Static Filtering для адресов All Group с Registration Fixed на данном порту приведет к поведению Forward All Groups. Следовательно, использование подходящих комбинаций Registration Fixed, Registration Forbidden и Normal Registration в Port Map записей Static Filtering для спецификаций адресов All Group и All Unregistered Group позволяет для данного порта выполнить один из перечисленных ниже вариантов:

• зафиксировать в качестве принятого по умолчанию поведения порта один из описанных выше вариантов;

• ограничить выбор вариантов поведения и разрешить регистрации GMRP для окончательного выбора;

• разрешить один из трех вариантов в соответствии с регистрациями, полученными с помощью GMRP.

7.9.5 Запросы к базе Filtering Database

Каждая запись в Filtering Database содержит:

1. спецификацию MAC-адреса;
2. отображение Port Map с элементом управления для каждого выходного порта.

Данный индивидуальный MAC-адрес может быть в записи Static Filtering, Dynamic Filtering, обоих или ни в одной. В таблице 7-6 приведены комбинации данных Static Filtering и Dynamic Filtering для задания пересылки или фильтрации кадров с индивидуальным MAC-адресом получателя на выходном порту.

Таблица 7-6. Комбинация статических и динамических записей для отдельного MAC-адреса.

Данные о фильтрации	Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
	Пересылка	Фильтрация	Используется динамический фильтр или нет статического. Элемент управления динамическим фильтром для этого MAC-адреса и порта задает:
			Пересылка	Фильтрация	Нет динамического фильтра
Результат	Пересылка	Фильтрация	Пересылка	Фильтрация	Пересылка

В таблице 7-7 показаны результаты (Registered или Not Registered) комбинирования записей Static Filtering и Group Registration для адресов All Group Addresses и All Unregistered Group Addresses.

Таблица 7-7. Комбинация статических фильтров и регистрации групп.

Данные о фильтрации	Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
	Регистрация зафиксирована (пересылка)	Регистрация запрещена (фильтрация)	Используется динамический фильтр или нет статического. Элемент управления динамическим фильтром для этого MAC-адреса и порта задает:
			Зарегистрирован (пересылка)	Не зарегистрирован (фильтрация)	Нет регистрационной записи группы
Результат	Зарегистрирован	Не зарегистрирован	Зарегистрирован	Не зарегистрирован	Не зарегистрирован

В таблице 7-8 показаны результаты комбинирования данных записей Static Filtering и Group Registration для конкретных групповых MAC-адресов с результатами из таблицы 7-7 для All Group Addresses и All Unregistered Group Addresses, указывающие пересылку или фильтрацию кадра с групповым MAC-адресом получателя на выходном порту.

Таблица 7-8. Пересылки или фильтрация для конкретной группы MAC-адресов.

				Элемент управления статическим фильтром для отдельного MAC-адреса и порта задает:
				Регистрация зафиксирована (пересылка)	Регистрация запрещена (фильтрация)	Используются данные регистрации группы или нет статической записи. Элемент управления записи Group Registration для этого MAC-адреса и порта задает:
						Зарегистрирован (пересылка)	Не зарегистрирован (фильтрация)	Нет регистрационной записи группы
Элементы управления адресами All Group для данного порта задают (таблица 7-7):	Не зарегистрирован	Элементы управления адресами All Unregistered Group для данного порта задают (таблица 7-7):	Не зарегистрирован	Пересылка	Фильтрация	Пересылка	Фильтрация	Фильтрация (Unregistered Groups)
			Зарегистрирован	Пересылка	Фильтрация	Пересылка	Фильтрация	Фильтрация (Unregistered Groups)
	Зарегистрирован			Пересылка	Фильтрация	Пересылка (All Group)	Пересылка (All Group)	Пересылка (All Group)

7.9.6 Постоянная база данных

Постоянная база данных (Permanent Database) обеспечивает фиксированное хранилище для множества записей Static Filtering. База Filtering Database должна инициализироваться записями Filtering Database из постоянного хранилища.

Записи могут добавляться в постоянную базу и удаляться из нее путем явных воздействий системы управления с помощью функциональности, описанной в разделе 14. Изменения содержимого записей Static Filtering в Permanent Database не влияют на решения о пересылке и фильтрации, принимаемые процессом пересылки, пока Filtering Database не будет инициализирована с использованием обновленных записей.

Примечание 1. Этот аспект Permanent Database можно рассматривать как предоставление «загрузочного образа» для Filtering Database, определяющего содержимое первоначальных записей до того, как будут добавлены динамические фильтры.

Примечание 2. В параграфе 10.3.2.3 определено начальное содержимое Permanent Database, требуемое для работы GMRP.

7.10 Объект STP и объекты GARP

Объект STP работает с протоколом RSTP10. Объекты STP в мостах, подключенных к данной отдельной ЛВС в сети на базе мостов, взаимодействуют между собой путем обмена BPDU11.

На рисунке 7-6 показана работа объекта STP, включая прием и передачу кадров с BPDU, изменение данных состояния, связанных с отдельными портами моста, и уведомление Filtering Database об изменении активной топологии.

Объекты GARP работают с алгоритмами и протоколами приложений GARP, поддерживаемых мостом, и состоят из множества участников GARP (Participant) для данных приложений GARP (параграф 12.2, раздел 10). Объекты GARP мостов, подключенных к данной отдельной ЛВС, взаимодействуют путем обмена GARP PDU12.

Рисунок 7-7 иллюстрирует работу объекта GARP, включая прием и передачу кадров с GARP PDU, использование данных управления из Filtering Database и уведомление Filtering Database об изменениях фильтров.

7.11 Управление мостом

Возможности удаленного управления могут предоставляться мостом и моделируются как выполняемые объектом Bridge Management. Обеспечиваемые возможности и поддерживаемые операции заданы в разделе 14. Протоколы управления мостом (Bridge Management) используют службу, обеспечиваемую с помощью процедур LLC, которые используют услуги MAC, обеспечиваемые Bridged Local Area Network.

7.12 Адресация

Все объекты MAC, взаимодействующие через Bridged LAN, используют 48-битовые адреса. Это могут быть глобально администрируемые адреса (Universally Administered Address) или комбинация с локально администрируемыми адресами.

7.12.1 Конечные станции

Кадры, передаваемые между конечными станциями с использованием сервиса MAC, обеспечиваемого Bridged LAN, содержат MAC-адреса отправителя и получателя в соответствующих полях. Адреса или иные средства идентификации мостов не передаются в кадрах между пользователями и не нужны для трансляции кадров в сети.

Широковещательный адрес и другие групповые MAC-адреса применимы при использовании сервиса MAC, обеспечиваемого Bridged LAN в целом. При отсутствии явных фильтров, заданных системой управления в записях Static Filtering или протоколом GMRP в записях Group Registration (разделы 14 и 10, параграф 7.9), кадры с такими адресами получателей транслируются через сеть.

7.12.2 Порты моста

Отдельные объекты MAC, связанные с каждым портом моста, должны иметь индивидуальные MAC-адреса. Эти адреса используются для всех процедур MAC, требуемых отдельным уровнем MAC.

Кадры, полученные из ЛВС, к которой подключен порт, или транслируемые в нее, содержащие MAC-адрес порта в поле получателя MAC, должны быть представлены пользователю сервиса MAC (LLC) и пользователю сервиса LLC для LSAP, указанного адресом получателя LLC как для конечной станции.

7.12.3 Объекты протоколов STP и GARP

Объекты STP получают и передают только BPDU, которые приходят от других объектов STP или передаются им (или при подключении двух портов моста к одной ЛВС между этими портами).

Объекты GARP получают и передают только GARP PDU (12.10), которые передаются в соответствии с требованиями поддерживаемого приложения GARP.

Объект STP или GARP использует примитив DL_UNITDATA.request (см. IEEE Std 802.2), предоставляемый отдельными объектами LLC, связанными с каждым активным портом моста, для передачи BPDU или GARP PDU. Каждый модуль PDU передается в один выбранный порт моста. PDU принимаются через соответствующие примитивы DL_UNITDATA.indication. Параметры source_address и destination_address в DL_UNITDATA.request должны содержать стандартные адреса LLC, выделенные протоколам STP для моста. Это идентифицирует объекты STP и GARP среди других пользователей LLC.

Каждый примитив DL_UNITDATA.request приводит к передаче блока PDU с командой LLC UI, который содержит BPDU или GARP PDU в своем информационном поле. Поля адресов LLC для получателя и отправителя содержат значения, представленные в примитиве запроса.

Значение, выделенное для LLC-адреса протокола STP, приведено в таблице 7-9¹³.

Таблица 7-9. Стандартный адрес LLC

Адрес	Значение
Bridge Spanning Tree Protocol	01000010

Представление кода. Младший бит значения указывается справа, значимость битов возрастает справа налево. Следует отметить, что используемое здесь представление кода выбрано для обеспечения согласованности с представлением, используемым в этом стандарте, однако оно отличается от ISO/IEC TR 11802-1: 1997.

Стандарт определяет поле идентификатора протокола (Protocol Identifier), присутствующее во всех BPDU (раздел 9) и GARP PDU (параграф 12.10), которое служит для указания разных протоколов, поддерживаемых объектами STP и GARP в области действия адреса LLC. Стандарт задает одно значение Protocol Identifier в разделе 9 для использования в BPDU. Это значение служит для идентификации BPDU, передаваемых между объектами STP алгоритма и протокола RSTP (раздел 17). Второе значение идентификатора для использования в GARP PDU определено в параграфе 12.10. Это значение служит для идентификации GARP PDU, передаваемых между участниками GARP в операциях протокола, описанных в разделе 12. Другие значения этого поля зарезервированы для будущих спецификаций.

Объекты STP и GARP, принимающие BPDU или GARP PDU с неизвестным значением Protocol Identifier должны отбрасывать такие PDU.

Объект STP, работающий с алгоритмом и протоколом RSTP (раздел 17), всегда передает BPDU, адресованные всем другим объектам STP, подключенным к ЛВС, в которую передается кадр с BPDU. Для этой цели выделен 48-битовый универсальный адрес, известный как Bridge Group Address, который должен указываться в поле получателя всех кадров MAC, содержащих BPDU. Значение адреса приведено в таблице 7-10. Этот групповой адрес должен быть указан в Permanent Database (7.12.6), чтобы ограничить распространение BPDU отдельной ЛВС.

Таблица 7-10. Зарезервированные адреса

Адрес	Значение
Bridge Group	01-80-C2-00-00-00
Операция IEEE Std 802.3x Full Duplex PAUSE	01-80-C2-00-00-01
IEEE Std 802.3ad Slow_Protocols_Multicast	01-80-C2-00-00-02
IEEE P802.1X PAE	01-80-C2-00-00-03
Резерв для будущей стандартизации	01-80-C2-00-00-04
Резерв для будущей стандартизации	01-80-C2-00-00-05
Резерв для будущей стандартизации	01-80-C2-00-00-06
Резерв для будущей стандартизации	01-80-C2-00-00-07
Резерв для будущей стандартизации	01-80-C2-00-00-08
Резерв для будущей стандартизации	01-80-C2-00-00-09
Резерв для будущей стандартизации	01-80-C2-00-00-0A
Резерв для будущей стандартизации	01-80-C2-00-00-0B
Резерв для будущей стандартизации	01-80-C2-00-00-0C
Резерв для будущей стандартизации	01-80-C2-00-00-0D
Резерв для будущей стандартизации	01-80-C2-00-00-0E
Резерв для будущей стандартизации	01-80-C2-00-00-0F

Объект GARP, который

1. работает с протоколом GARP (раздел 12);

2. поддерживает данное приложение GARP,

всегда передает GARP PDU, адресованные всем остальным объектам GARP, которые

3. реализуют то же приложение GARP;

4. подключены к ЛВС, куда передается кадр с GARP PDU.

Групповой MAC-адрес, относящийся к соответствующему приложению GARP, должен указываться в поле MAC-адреса получателя для объектов GARP данной группы. Для этого выделен набор 48-битовых универсальных адресов, называемый адресами GARP Application. Значения этих адресов приведены в таблице 12-1. Эти групповые MAC-адреса зарезервированы для выделения стандартным протоколам в соответствии с заданными критериями (раздел 5.5 в стандарте ISO/IEC TR 11802-2) и указываются в записях Static Filtering базы фильтрации (7.9.1), а также в Permanent Database (7.9.6), как показано ниже.

5. Адреса GARP Application, назначенные приложениям GARP, которые поддерживаются мостом, настраиваются так, чтобы ограничить распространение GARP PDU данным приложением GARP в ЛВС, куда они передаются.

6. Адреса GARP Application, назначенные приложениям GARP, которые не поддерживаются мостом, не включаются в Filtering Database и Permanent Database.

Система управления не должна позволять изменение или удаление записей в базах Permanent и Filtering для поддерживаемых адресов приложений GARP, а также создание записей для неподдерживаемых адресов.

Поле адреса отправителя в кадрах MAC с BPDU или GARP PDU для приложений GARP, поддерживаемых мостом, должно содержать индивидуальный MAC-адрес порта, через который PDU передается (7.12.2).

7.12.4 Объекты управления мостом

Объект управления мостом (Bridge Management Entity) передает и принимает протокольные блоки данных, используя сервис, обеспечиваемый отдельным объектом LLC, связанным с портом моста. Каждый объект LLC использует сервис MAC, предоставляемый объектом MAC данного порта и поддерживаемый Bridged LAN в целом. Как пользователь сервиса MAC, предоставляемого Bridged LAN, объект Bridge Management может быть подключен к любой точке сети. Кадры, адресованные объекту Bridge Management, будут транслироваться мостами, если это требуется для доступа в ЛВС, к которой подключен объект.

Для предотвращения дублирование кадров с каждой точкой подключения связывается уникальный адрес. Объект Bridge Management для конкретного моста обозначается одним или множеством индивидуальных MAC-адресов в соответствии с идентификатором протокола вышележащего уровня и адресной информацией. Объект может иметь одну или множество точек подключения к Bridged LAN через порты моста, с которым объект связан.

Стандарт задает групповой адрес общего пользования, который служит для передачи запросов объектам Bridge Management, связанным со всеми портами моста, которые подключены к Bridged LAN. Запрос управления в кадре MAC с таким адресом в поле получателя обычно будет приводить к получению множества откликов от одного моста. Этот адрес называют All LANs Bridge Management Group Address и его значение приведено в таблице 7-11.

Таблица 7-11. Зарезервированный адрес.

Адрес	Значение
All LANs Bridge Management Group	01-80-C2-00-00-10

7.12.5 Однозначная идентификация моста

Для каждого моста должен быть выделен уникальный 48-битовый MAC-адрес (Universally Administered), называемый Bridge Address. Это может быть индивидуальный MAC-адрес Bridge Port и в таком случае рекомендуется использовать порт с наименьшим номером (Port 1).

7.12.6 Зарезервированные адреса

Кадры с любым из групповых MAC-адресов, указанных в таблице 7-10, в поле получателя мосту не следует ретранслировать. Эти адреса задаются в Permanent Database. Система управления не должна разрешать изменение или удаление таких записей из баз Permanent и Filtering.

Эти групповые MAC-адреса зарезервированы для стандартных протоколов в соответствии с критериями выделения раздела 5.5 в стандарте ISO/IEC TR 11802-2.

7.12.7 Точки подключения объектов вышележащего уровня

Объекты вышележащего уровня (Higher-Layer Entity) в мосту, такие как STP (7.10), GARP (7.10) и Bridge Management (7.11), моделируются как подключенные напрямую к одной или нескольким ЛВС, соединенных с портами моста точно так же, как конечные станции сети. Хотя эти объекты и функции ретрансляции моста используют такие же индивидуальные объекты MAC для приема и передачи кадров, адресация и подключение этих объектов выглядят так, будто они подключены как отдельные конечные станции «вне» порта или портов, к которым они действительно подключены. На рисунке 7-9 приведен функциональный эквивалент рисунка 7-3 с указанием логического разделения между точками подключения, используемыми объектами Higher-Layer и объектом MAC Relay.

Рисунок 7-9. Логические точки подключения объектов Higher-Layer и MAC Relay.

На рисунке 7-10 показана информация, используемая для управления пересылкой кадров из одного порта моста в другой (Port State и содержимое Filtering Database), в виде цепочки переключателей (в разомкнутом состоянии), помещенных в путь, обеспечиваемый объектом MAC Relay. Для моста, пересылающего кадр между двумя портами все три переключателя должны находиться в замкнутом состоянии. Показывая объекты Higher-Layer с общей точкой подключения к каждой ЛВС, используемой каждым портом моста для пересылки кадров, этот рисунок также иллюстрирует точку, показанную на рисунке 7-9, – элементы управления в пути пересылки не оказывают влияния на способность объекта Higher-Layer передавать и принимать кадры из данной ЛВС, используя прямое подключение к ней (например, между объектом A и LAN A) и влияют лишь на путь непрямой передачи и приема (например, между объектом A и LAN B).

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

1. Одна точка подключения к Bridged LAN, обеспечивающая связность со станциями, подключенными к сети в любой точке (определяется администратором), как это делает объект Bridge Management.

2. Отдельные точки подключения к каждой ЛВС, соединенной с портом моста, обеспечивающие связность лишь с партнерскими объектами, подключенными непосредственно к этой ЛВС, как это делают объекты STP и GARP.

     
Рисунок 7-10. Влияние управляющей информации на путь пересылки.

Во втором случае важно, чтобы функция связывала каждый принятый и переданный кадр с точкой присоединения. Кадры, принятые или переданные через одну точку присоединения, не будут транслироваться в другие порты и подключенные ЛВС (или из них), поэтому MAC-адреса (7.12.3, 7.12.6, таблица 7-10), используемые для доступа к этим функциям, должны быть постоянно включены в базу Filtering Database (7.9.6).

Примечание 1. Для доступа к функциям с разными точками подключения обычно служат групповые MAC-адреса.

Примечание 2. Один объект Higher-Layer может включать функцию, требуемую для одной точки подключения, и функцию, требуемую для разных точек. Доступ к этим двум функциям осуществляется по разным MAC-адресам.

На рисунке 7-11 показана связность пути пересылки кадров, адресованных объектам Higher-Layer, которым требуется точка подключения для каждого порта. Конфигурация Permanent Database во всех мостах для предотвращения ретрансляции кадров, адресованных этим объектам, означает, что они будут получать кадры только через точки прямого подключения (например, из LAN A в объект A и из LAN B в объект B), независимо от состояния портов.

 
Рисунок 7-11. Точки подключения на уровне порта.

На рисунках 7-12 и 7-13 показана связность пути пересылки кадров, адресованных объекту Higher-Layer, которому требуется одна точка подключения. В обоих случаях Filtering Database разрешает трансляцию кадров, как и состояния портов на рисунке 7-12, где кадры из LAN B транслируются мостом объекту A и LAN A.

 
Рисунок 7-12. Одна точка подключения (трансляция разрешена).

На рисунке 7-13 кадры из LAN A принимаются объектом напрямую, но кадры из LAN B не транслируются мостом и будут приниматься объектом лишь при наличии другого пути пересылки между LAN A и LAN B. Если показанное на рисунке состояние Discarding Port вызвано расчетом связующего дерева (а не административным запретом), такой путь будет проходить через один или множество мостов. Если нет активного пути STP от B к A, сеть разделится на две Bridged LAN и показанный на рисунке объект Higher-Layer будет доступен через LAN A.

 
Рисунок 7-13. Одна точка подключения (трансляция не разрешена).

Конкретные объекты Higher-Layer могут учитывать административное состояние порта (Administrative Bridge Port State) в соответствии с их спецификацией. Объект STP относится к их числу и BPDU никогда не передаются и не принимаются на портах с административным состоянием Disabled.

Если объект MAC порта в мосту не работает, объект Higher-Layer, непосредственно связанный с этим портом, будет недоступен, как показано на рисунке 7-14. Объект STP гарантирует состояние порта Discarding, если MAC_Operational (6.4.2) имеет значение FALSE, даже при административном состоянии порта Enabled.

 
Рисунок 7-14. Эффект состояния порта.

Связность, обеспечиваемая для объектов Higher-Layer и ЛВС, которые образуют Bridged LAN, может дополнительно контролироваться портом моста, выступающим в качестве порта доступа в сеть (IEEE Std 802.1X). Работа управления доступом на уровне порта дает эффект создания двух разных точек доступа в ЛВС. Одной точкой является неуправляемый порт и обмен кадрами через него не зависит от результата проверки полномочий (authorization state), а другой (управляемый) порт разрешает только полномочный обмен кадрами. Если порт не имеет полномочий, объект STP, который использует управляемый порт (как делает объект MAC Relay), не сможет обмениваться BPDU с другими мостами, подключенными к LAN A, и будет устанавливать для Bridge Port состояние Discarding.

Примечание. Если объект STP не знает о состоянии порта Unauthorized и предполагает, что порт может принимать и передавать BPDU, он может установить для Bridge Port State значение Forwarding. После разрешения использовать порт в этом случае может возникать временная петля в сети.

На рисунке 7-15 показана связность, обеспечиваемая объектам Higher-Layer, если объект MAC физически способен передавать и принимать кадры, т. е. MAC_Operational = TRUE, но AuthControlledPortStatus имеет значение Unauthorized. Higher-Layer Entity A и PAE (объект доступа к порту, в котором работает протокол разрешения доступа) подключены к неуправляемому порту и могут передавать и принимать кадры, используя объект MAC, связанный с портом, а Higher-Layer Entity B не может этого. Ни один из трех объектов не может принимать кадры из LAN B или передавать их туда.

Примечание. Значения административного и рабочего состояния, связанные с MAC, состояние полномочности порта и Bridge Port State, совпадают с параметрами ifAdminStatus и ifOperStatus, связанными с соответствующими определениями интерфейса (см. IETF RFC 2233).

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru