1

Мосты 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. Отображение служебных данных и новый расчет FCS1 при необходимости (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. Принятая по умолчанию или заданная администратором конфигурация протокола RSTP2 (раздел 17) для включения в активную топологию конкретных портов моста и подключенных к нему ЛВС.

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

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

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

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

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

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

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

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

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), используют процедуры управления логическим каналом (LLC3). Эти процедуры обеспечиваются раздельно для каждого порта и используют сервис 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_UNITDATA6, обработка которой описана ниже.

Кадры с 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. групповых кадров с данным given 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 на класс трафика8.

 

Число доступных классов трафика

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. Допустимая транзитная задержка в мосту.

Параметр

Рекомендуемое значение

Абсолютный максимум

Максимальная транзитная задержка

1,0 секунда

4,0 секунды

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-адресов. Этот тип позволяет контролировать:

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

  2. включение в 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. Динамические и статические записи включают:

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

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

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

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

  2. 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.

Алгоритм и протокол RSTP9, заданные в разделе 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-913.

Таблица 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, которые

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

  2. подключены к ЛВС, куда передается кадр с 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), как показано ниже.

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

  2. Адреса 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 или передавать их туда.

 
Рисунок 7-15. Эффект предоставления полномочий.

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

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

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

nmalykh@protocols.ru

1Frame Check Sequence – контрольная сумма кадра.

2Rapid Spanning Tree Protocol – ускоренный протокол связующего дерева.

3Logical Link Control.

4Bridge Protocol Data Unit – блок данных протокола моста.

5Protocol Data Unit – блок данных протокола.

6Кадры с ошибками, определенными соответствующей спецификацией MAC, отбрасываются объектом MAC без какой-либо индикации M_UNITDATA (6.4).

7Технологии IEEE 802 LAN поддерживают до 8 значений user_priority. В информационном приложении G даны дополнительные описания значений user_priority и их отображения на классы трафика.

8Основания для этого отображения рассмотрены в информационном Приложении G. Кадры с принятым по умолчанию приоритетом пользователя получают преимущество перед классами 1 и 2 в мостах с 4 и более классами трафика.

9Rapid Spanning Tree.

10Rapid Spanning Tree Protocol.

11Bridge Protocol Data Unit – модуль данных протокола мостов.

12GARP Protocol Data Unit – модуль данных протокола GARP.

13ISO/IEC TR 11802-1: 1997 содержит полный список стандартных назначений адресов LLC и критерии выделения.




Методы цифрового кодирования

Методы цифрового кодирования

PDF

Цифровое кодирование (Digital Encoding), иногда не совсем корректно называемое модуляцией, определяет способ представления битов в физическом канале передачи данных. В этом документе рассмотрены различные варианты цифрового кодирования от простого метода NRZ (Non Return to Zero – без возврата к нулю) до существенно более сложного кодирования HDB3 (High Density Bipolar 3 – биполярное кодирование с высокой плотностью, вариант 3). Документ содержит список требований, предъявляемых к алгоритмам цифрового кодирования, и краткие описания наиболее распространенных методов кодирования цифровых сигналов.

Требования к алгоритмам цифрового кодирования

При кодировании цифровых сигналов должны выполняться перечисленные ниже требования.

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

  2. Невысокий уровень постоянного напряжения в линии.

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

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

Обзор методов цифрового кодирования

NRZ – Non Return to Zero (без возврата к нулю)

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

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются напряжением +V.

Рисунок 1. Кодирование NRZ.

Этот метод кодирования является наиболее простым и служит базой для построения более совершенных алгоритмов кодирования. Кодированию по методу NRZ присущ целый ряд недостатков:

  • высокий уровень постоянного напряжения (среднее значение 1/2V для последовательности, содержащей равное число 1 и 0);

  • широкая полоса сигнала (от 0 Гц для последовательности, содержащей только 1 или только 0, до половины скорости передачи данных при чередовании 10101010…);

  • возможность возникновения продолжительных периодов передачи постоянного уровня (длинная последовательность 1 или 0) в результате чего затрудняется синхронизация устройств;

  • сигнал является поляризованным.

RZ – Return to Zero (возврат к нулю)

Цифровые данные представляются следующим образом:

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются значением +V в первой половине и нулевым напряжением – во второй, т.е. единице соответствует импульс напряжения продолжительностью в половину длительности передачи одного бита данных.

Рисунок 2. Кодирование RZ.

Этот метод имеет два преимущества по сравнению с кодированием NRZ:

  • средний уровень напряжения в линии составляет ¼ V (вместо ½ V);

  • при передаче непрерывной последовательности 1 сигнал в линии не остается постоянным.

Однако при использовании кодирования RZ полоса сигнала может достигать значений, равных скорости передачи данных (при передаче последовательности 1).

NRZI – Non Return to Zero Invertive (инверсное кодирование без возврата к 0)

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

  • биты 0 представляются нулевым напряжением (0 В);

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

Рисунок 3. Кодирование NRZI.

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

AMI – Alternate Mark Inversion (поочередная инверсия единиц)

Этот метод кодирования использует следующие представления битов:

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются поочередно значениями +V и -V.

Рисунок 4. Кодирование AMI.

Этот метод подобен алгоритму RZ, но обеспечивает в линии нулевой уровень постоянного напряжения. Недостатком метода AMI является ограничение на «плотность» нулей в потоке данных, поскольку длинные последовательности 0 ведут к потере синхронизации.

HDB3 – High Density Bipolar 3 (биполярное кодирование с высокой плотностью)

Представление битов в методе HDB3 лишь незначительно отличается от представления, используемого алгоритмом AMI. При наличии в потоке данных 4 последовательных битов 0 последовательность изменяется на 000V, где полярность бита V такая же, как для предшествующего ненулевого импульса (в отличие от кодирования битов 1, для которых знак сигнала V изменяется поочередно для каждой единицы в потоке данных).

Рисунок 5. Кодирование HDB3.

Этот алгоритм снимает ограничения на плотность 0, присущие кодированию AMI, но порождает взамен новую проблему – в линии появляется отличный от нуля уровень постоянного напряжения за счет того, что полярность отличных от нуля импульсов совпадает. Для решения этой проблемы полярность бита V изменяется по сравнению с полярностью предшествующего бита V. Когда это происходит, битовый поток изменяется на B00V, где полярность бита B совпадает с полярностью бита V. Когда приемник получает бит B, он думает, что этот сигнал соответствует значению 1, но после получения бита V (с такой же полярностью) приемник может корректно трактовать биты B и V как 0.

Метод HDB3 удовлетворяет всем требованиям, предъявляемым к алгоритмам цифрового кодирования, но при использовании этого метода могут возникать некоторые проблемы.

PE – Phase Encode (Manchester, фазовое кодирование, манчестерское кодирование)

При фазовом кодировании используется следующее представление битов:

  • биты 0 представляются напряжением +V в первой половине бита и напряжением -V – во второй половине;

  • биты 1 представляются напряжением -V в первой половине бита и напряжением +V – во второй половине.

Рисунок 6. Манчестерское кодирование.

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

CDP – Conditional Diphase

Этот метод является комбинацией алгоритмов NRZI и PE и использует следующие представления битов цифрового потока:

  • биты 0 представляются переходом напряжения в том же направлении, что и для предшествующего бита (от +V к -V или от -V к +V);

  • биты 1 представляются переходом напряжения в направлении, противоположном предшествующему биту (от +V к -V или от -V к +V).

Рисунок 7. Кодирование CDP.

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

Заключение

Как вы увидели из приведенных описаний, существует достаточно много алгоритмов кодирования цифровых сигналов. Простейший метод NRZ используется в протоколах на базе интерфейса RS232, в сетях Ethernet применяется кодирование PE, а в телефонии используется алгоритм HDB3 (этот метод служит для кодирования сигналов в потоках E1 и E2). Выбор метода кодирования зависит от полосы канала связи, используемой кабельной системы, скорости передачи данных и других параметров.

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

nmalykh@protocols.ru




IEN 178 ADDRESSING PROBLEMS IN MULTI-NETWORK SYSTEMS

     IEN 178                                                April 1981




ADDRESSING PROBLEMS IN MULTI-NETWORK SYSTEMS

Проблемы адресации в многосетевых системах


Carl A. Sunshine

University of Southern California

Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90291

Оригинал

PDF

Аннотация

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

Примечание. С этим документом связаны три рисунка, которые можно запросить у автора, отправив ему сообщение по адресу <SUNSHINE@ISIF>1.

Введение

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

Имеющиеся многосетевые системы достаточно малы (не более десятков сетей) и в основном созданы и управляются одной организацией. Здесь такие сети называются однородными или гомогенными. Базовые соединения между сетями поддерживаются на основе простых иерархических процедур адресации и маршрутизации, единообразно применяемых в системах [1,4,10,13]. Организация соединений между многосетевыми системами (неоднородные или гетерогенные сети) только начинается и происходит в основном на основе специализированных решений.

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

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

Иерархические методы

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

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

Если бы каждый коммутатор сохранял маршрутную информацию отдельно для каждого получателя, таблицы маршрутизации были бы очень большими. Стандартным подходом служит иерархическая адресация, где каждому хосту назначается определённый порт в конкретном коммутаторе и адрес принимает форму <коммутатор, порт>. После этого маршрутизацию также можно организовать иерархически, отправляя все пакеты, предназначенные для данного коммутатора, по одному маршруту с игнорированием «младшей» части адреса (порт). Поэтому каждому коммутатору нужно поддерживать лишь таблицу маршрутов к другим коммутаторам, что существенно снижает число разных пунктов назначения и, следовательно, маршрутных записей.

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

Этот подход можно распространить на многосетевые системы, добавив ещё один уровень в иерархию адресов, чтобы получить формат <сеть, коммутатор, порт>. При иерархической маршрутизации пакеты сначала направляются в сеть получателя с игнорированием остальных частей адреса, затем маршрутизируются в этой сети, как описано выше. Эта форма иерархической адресации была принята для сетей общего пользования с коммутацией пакетов в документе CCITT Recommendation X.121 и похоже, что большинство сетей общего пользования планируют применять иерархическую маршрутизацию [13,19].

За уменьшение размера таблиц при использовании иерархической маршрутизации приходится платить тем, что маршруты не всегда могут быть оптимальными. При наличии двух путей в удалённую сеть (что часто встречается на практике) один может оказаться лучше для одних хостов сети, второй – для других. Однако нет возможности определить это из локальной таблицы маршрутизации, содержащей единственную запись для всей удалённой сети. Ещё более серьёзные последствия строгого применения иерархической маршрутизации рассмотрены ниже.

Для предотвращения указанных проблем можно принимать решения на основе большего числа адресов там, где это желательно [5,14]. Например, таблицу межсетевой маршрутизации можно дополнить записями для отдельных коммутаторов, получающих большой объем трафика в удалённой сети, сохранив для всех прочих коммутаторов этой сети общую запись. Это ведёт к селективному росту таблиц маршрутизации и требует поддержки операций поиска в таблицах по части адреса переменного размера с разным уровнем детализации.

Разделение сетей

Сеть считается разделённой (partitioned) при выходе из строя коммутаторов и/или каналов, в результате которого в сети возникает две или более группы хостов, не способных взаимодействовать между собой. В изолированной сети проблема не может быть решена, пока не будут выполнены работы, обеспечивающие восстановление связности. Но если разделённая сеть является частью многосетевой системы, могут быть пути через другие сети, позволяющие соединить части разделённой сети. К сожалению эти пути не могут использоваться при строгой процедуре иерархической маршрутизации, описанной выше. Даже при передаче «локального» пакета коммутатором в соседнюю сеть этот пакет скорей всего вернётся из неё в ту же часть разделённой сети.

Это указывает дополнительную сложность. Трафик в удалённой сети, предназначенный для разделённой сети, будет маршрутизироваться в ту или иную часть без учёта коммутации внутри разделённой сети (напомним, что другие сети видят лишь один «лучший» путь в эту сеть, рассматриваемую как целое). Для некоторых адресатов пакеты будут приходить не в тот раздел, а эти получатели будет недоступны для внутрисетевых маршрутов, что ведёт к их недоступности из удалённых сетей [14,16].

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

В военных системах, где предполагаются многочисленные повреждения, желательно иметь средства принудительного использования любых доступных соединений [3]. Один из подходов заключается в рассмотрении числа сетей как динамического параметра и превращении разделённой сети в две сети, каждая из которых может быть явным адресатом. Это требует более сложных методов обновления представлений каждой сети об общей топологии и распространения информации о разделе одной сети во все другие сети [8]. Другой подход заключается в возврате специального сообщения об ошибке, вынуждающего выбрать другую точку входа в «отвалившуюся» сеть. Этот метод «резервирования с переключением» (backup-and-try-alternate) реализован для организации вызовов в Telenet [19].

Маршрутизация по «быстрому пути»

Использование разных внешних маршрутов между парой точек, расположенных в одной области, может быть желательно не только в случаях аварий с разделением сети. Если две сети охватывают одну территорию, например, наземная сеть с промежуточной буферизацией (store-and-forward) и широковещательная спутниковая сеть, для некоторых типов трафика производительность может быть повышена при выходе из наземной сети вблизи источника и возврате в неё вблизи получателя. Например, передача файлов в этом варианте может ускоряться.

Для достижения этого снова требуется отойти от иерархической маршрутизации. Либо маршрутизация на уровне сетей должна различать адресатов, доступных напрямую в этой сети и адресатов, доступных с использованием внешних путей, либо маршрутизация внутри сети должна видеть пути через другие сети как особый случай доступных изнутри каналов [9]. Однако в последнем случае требуется внедрение информации о состоянии внешних путей в процедуры поддержки состояний внутренних каналов, что может оказаться «грязным» делом.

Множество адресов

Абонент может организовать несколько соединений с системой связи для повышения надёжности или производительности. В простейшем случае несколько независимых физических линий может поддерживаться как один логический канал для повышения надёжности и производительности или снижения стоимости (с учётом тарифов операторов связи). Было разработано несколько процедур множественных подключений, например, Transpac и X.75. Абонент по-прежнему имеет один адрес и никаких сложностей не возникает.

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

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

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

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

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

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

Даже в сетях на основе дейтаграмм протоколы высоких уровней чувствительны к адресам локального и удалённого хоста [3]. Адес отправителя служит для демультиплексирования входящих пакетов в нужно «соединение» и получение пакета с другого адреса приведёт к тому, что он не будет должным образом распознан. Для предотвращения этой проблемы можно использовать (одно) имя отправителя в таблицах соединений, но это имя потребуется включать в пакет. Другим решением может быть хранение нескольких удалённых адресов в таблице соединений, чтобы пакет с любого из этих адресов обрабатывался корректно. Эти адреса могут быть представлены в процессе организации соединения и могут применяться для передачи трафика при отказе основного адреса.

Мобильные хосты

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

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

Одним из методов «отслеживания» мобильных хостов может служить поддержка специальной базы данных с текущим местоположением хостов (возможно дублирование базы для надёжности), как это делается в отдельных пакетных радиосетях (на «станциях»). Мобильные хосты по мере необходимости обновляют записи в этой базе, а пользователи, которым нужны соединения с мобильными хостами, могут запросить адрес в базе данных, как в обычной службе каталогов. Однако они должны быть готовы к получению частых обновлений о смене адреса от самого мобильного хоста, дополнительных точек ретрансляции или базы данных. Описание этой схемы представлено в работе [18].

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

Мобильные хосты могут иметь несколько адресов одновременно или менять адрес со временем (например, самолёт может быть подключён к двум радиосетям). Это усугубляет проблемы и усложняет их решение.

Общий доступ в сеть

Проблема, обратная по отношению к хосту с множеством линий, возникает при использовании одной линии доступа несколькими хостами. Это может оказаться желательным при ограниченном числе физических интерфейсов или портов в сети, а также при использовании линии дальней связи несколькими близко расположенными абонентами. Сети общего доступа предоставляют многоточечные интерфейсы для терминального трафика (X.28), но не для пакетов (X.25). Для пакетных устройств альтернативой фиксированному (следовательно, неэффективному) мультиплексору с частотным или временным разделением является тот или иной «интеллектуальный» мультиплексор, работающий на уровне пакетов протокола доступа в сеть.

Широковещательные сеть (например, Ethernet и кольцевые сети) обеспечивают такую возможность по своей природе, поскольку каждый интерфейс «слышит» весь трафик. Интерфейс отвечает за восприятие соответствующего трафика и в некоторых случаях может настраиваться на захват трафика для нескольких адресов.

Другим подходом служит использование протоколов вышележащего уровня для обеспечения мультиплексирования. Протокол доступа Arpanet (Host-IMP) не поддерживает разделяемые интерфейсы а ограничение в 4 интерфейса на хосте для исходных IMP в некоторых случаях стало проблемой. Протокол Internet (IP) является следующим уровнем над конкретными протоколами доступа в сеть в иерархии ARPA [10,11]. Размер адреса IP достаточно велик для поддержки нескольких «логических» хостов на одном физическом порту хоста Arpanet. заголовок Host-IMP указывает один физический адрес хоста для всех таких пакетов, а модуль вышележащего уровня IP у адресата демультиплексирует пакеты нужному логическому хосту. Разработано независимое устройство для реализации этой функции на базе оборудования PDP-11/03. Этот «расширитель портов» эффективно превращает каждый порт IMP в 4-8 портов для остов, использующих протокол IP [7].

Сравнение сетей и шлюзов в качестве узла коммутации

В большинстве моделей иерархической маршрутизации сети рассматриваются как «супер-коммутаторы», похожие на обычные узлы коммутации в сети. Такое представление было бы верным, если бы в каждой сети присутствовал один коммутирующий межсетевой трафик узел для маршрутизации входящего из других сетей трафика с пересылкой его в другую сеть или на локальный хост. На рисунке X2 показа пример небольшой многосетевой системы и таблица маршрутизации в одной сети (коммутаторе). Таблица указывает стоимость числом интервалов межсетевой пересылки (internet hop) и лучшую из соседних сетей для доступа в каждую из сетей системы.

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

Следующим шагом является добавление одного шлюза, размещаемого «в середине» каждого межсетевого канала, вместо установки по одному процессору в каждой сети. Шлюзы идентифицируют свои межсетевые каналы. В такой конфигурации более реально задавать стоимость числом интервалов пересылки, а не межсетевых соединений. Поэтому каждый шлюз поддерживает сведения о дистанции (число интервалов) между шлюзами и лучший следующий шлюз для каждого адресата. В этой модели более реалистично считать шлюзы узлами коммутации, а сети – соединительными каналами между ними. По сути, это двойник предыдущей модели, показанный на рисунке Z. Однако получателями в таблице маршрутизации являются сети, а не шлюзы, что делает эту схему любопытным гибридом. В результате неясно, как применить маршрутизацию по состоянию канала (link state), используемую внутри отдельной сети (например, Arpanet) к этой многосетевой системой со шлюзами в качестве узлов коммутации.

Соединения внутри сайта

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

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

Для более эффективной обработки локального трафика может оказаться желательным организация явной локальной сети. При этом возникает вопрос – нужно ли остальной части многосетевой системы «знать» об этой сети и подключать такую сеть (через один или несколько полноценных шлюзов) или оставить её «невидимой» на межсетевом уровне с представлением хостов локальной как подключённых напрямую к сети дальней связи. В первом случае локальные хосты получают «межсетевой» адрес в явной локальной сети, а во втором используют адреса сети дальней связи.

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

Однако такое участие может вызывать проблемы на межсетевом уровне. По мере роста числа сайтов с локальными сетями будут расти таблицы маршрутизации и объем обновлений, которые должны распространяться по всей межсетевой системе. Если рост продолжается на сайте и там появляется несколько локальных сетей, соединённых «локальными» шлюзами, возникает вопрос о передаче сведений об этих локальных сетях и их топологии в межсетевую систему (internet). В какой-то момент рассмотрение локальных сетей как дальних или магистральных станет невозможным.

Модель с «невидимой» локальной сетью позволяет избежать проблем, связанных ростом числа сетей на межсетевом уровне. Многие расширители портов или локальные системы распределения могут выполнять функции коммутации, освобождая коммутатор сети дальней связи от обработки локального трафика. Однако сайты, соединённые с несколькими сетями, будут иметь множество адресов на своих хостах (по одному адресу для каждой сети, к которой хост представляется подключённым напрямую) и это вызывает сложности, рассмотренные выше (см. Множество адресов).

Эффективный компромисс для решения этих проблем не найден. Добавление уровня в иерархию адресов может дать временное решение, но оно тоже с течением времени столкнётся со сложностями. Это решение предполагает использование переменного числа уровней иерархии в системе с добавлением уровней по мере усложнения той или иной области. Однако это требует жёсткого упорядочения уровней и, следовательно, маршрутизации, тогда как в реальности представления «выше-ниже» для уровней могут зависеть от точки зрения пользователя. Требуются дальнейшие исследования процессов роста многосетевых систем (internet) с поддержкой в них эффективных процедур адресации и маршрутизации.

Множество доменов

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

Один из подходов основан на допущении об использовании одним доменом другого в качестве транспортной среды между своими однородными компонентами. Используемая система появляется просто как один из нескольких типов сред, которые использующая система может применить через соответствующие протоколы доступа. Пакеты использующей системы будут «инкапсулироваться» в пакеты протоколов используемой системы. Два таких домена могут взаимно использовать друг друга иногда даже неограниченно взаимодействовать между собой, используя «взаимную инкапсуляцию» [15]. Для неограниченного взаимодействия между разнородными системами каждая из них должна распознавать хосты другой системы. Имеется два базовых варианта работы через границы доменов — отображение (mapping) и заданная отправителем маршрутизация (source routing).

В варианте с отображением каждый домен предоставляет набор свободных внутренних адресов для сопоставления с адресами в другом домене. Трафик, направленный на такой «псевдо-адрес» маршрутизируется на интерфейс или шлюз в соответствующий внешний домен. В простейшем случае это требует лишь двухстороннего соглашения между доменами, но может быть распространено и на работу через промежуточные домены. Недостаток такого подхода заключается в том, что набор доступных внешних адресов ограничен таблицей сопоставления, которая обычно включает лишь часть адресов удалённого домена. Другой недостаток состоит в том, что один объект имеет разные адреса в каждом домене и каталог имён включает несколько записей для каждого имени (по одной для каждого домена). Основным преимуществом этого подхода является возможность обращения к поддерживаемым именам из удалённого домена как к локальным без дополнительных процедур.

В модели source routing [14,17,5] отправитель задаёт маршрут к адресату, состоящий из последовательности адресов промежуточных междоменных шлюзов вплоть до конечного получателя. Каждый адрес из этого списка интерпретируется в своём домене, где он имеет смысл, и затем удаляется, чтобы в следующем домене применялся понятный ему адрес. При использовании этого метода доступны все адреса удалённого домена, а междоменным шлюзам не нужно поддерживать заранее заданные сопоставления или преобразовывать адреса. Вся работа переносится к отправителю, который должен иметь сведения о топологии и форматах адресов для задания полного маршрута. Это увеличивает размер заголовков в пакете и объем обработки пакетов, поскольку размер заданного отправителем маршрута является переменным. Ещё раз отметим, что «адреса» различаются в разных доменах, но сейчас можно комбинировать эту информацию, – если каталог даёт маршрут для задания отправителем в домен X из домена A, а пользователь из домена B знает маршрут в домен A, он может объединить их в маршрут для домена X из B (хотя он может не быть оптимальным).

Зачастую полезно собрать маршрут возврата в процессе прохождения «прямого» маршрута, заданного отправителем (source route). Это позволяет адресату отвечать. В общем случае маршрут возврата не является простым обращением прямого маршрута. Адес возврата добавляется при входе пакета в каждый домен, а достигнутый адрес получателя удаляется на выходе из каждого домена (см. подробный пример в [17]).

«Независимый» от сети транспортный протокол [2], разработанный в British PSS Users Forum, является первым из тех, которые явно решают проблему нескольких доменов. По сути, предлагается механизм задаваемой отправителем маршрутизации, включая дополнительные средства трансляции явно указанной адресной информации, передаваемой между пользователями как данные. Протокол предполагает процедуру организации маршрута как часть организации соединения, поэтому задаваемый отправителем маршрут требуется передавать лишь в пакете запроса соединения.

В сетях общего пользования также предоставляется ограниченная возможность задания маршрута отправителем в форме поля Call User Data пакетов запроса соединения X.25. Это поле может использоваться целевым устройством DTE как дополнительная адресная информация для последующих шагов в соединении. Этот механизм применялся для соединений между сетями общего пользования в Канаде и США до внедрения иерархической адресации X.121 [12]. Поле Call User Data также начинает применяться в специализированной форме для адресации в различных частных и локальных сетях, соединённых с сетями общего пользования.

Протокол Arpa Internet также поддерживает опцию задаваемой отправителем маршрутизации, но для всех адресов на маршруте предполагается формат IP [11].


Заключение

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

Благодарности

Многие из представленных здесь концепций обсуждались несколько лет в рамках проекта ARPA Internet. Значительные заслуги в разработке и прояснении идей принадлежат коллегам автора из ISI и других организаций, вовлечённых в проект.

Литература

Примечание. Некоторые из указанных ниже ссылок относятся к категории IEN (Internet Experiment Note), разработанных в рамках проекта ARPA Internet, и не были опубликованы.

[1] D. R. Boggs, J. F. Shoch, E. A. Taft, and R. M. Metcalfe, “Pup: An Internetwork Architecture,” IEEE Trans. On Communications 28, 4, April 1980, pp. 612-6233.

[2] British Post Office PSS User Forum, A Network Independent Transport Service, February 1980.

[3] V. G. Cerf, Internet Addressing and Naming in a Tactical Environment, Internet Experiment Note 110, August 1979.

[4] V. G. Cerf and P. T. Kirstein, “Issues in Packet-Network Interconnection,” Proc. IEEE 66, 11, November 1978, pp. 1386-14084.

[5] D. D. Clark and D. Cohen, A Proposal for Addressing and Routing in the Internet, Internet Experiment Note 46, June 1978.

[6] R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C. Kunzelman, “Advances in Packet Radio Technology,” Proc. IEEE 66, 11, November 1978, pp. 1468-1496.

[7] H. A. Nelson, J. E. Mathis, and J. M. Lieb, The ARPANET IMP Port Expander, SRI Report 1080-140-1, November 1980.

[8] R. Perlman, Flying Packet Radios and Network Partitions, Internet Experiment Note 146, June 1980.

[9] R. Perlman, Utilizing Internet Routes as Expressways Through Slow Nets, Internet Experiment Note 147, June 1980.

[10] J. B. Postel, “Internetwork Protocol Approaches,” IEEE Trans. on Communications 28, 4, April 1980, pp. 604-6115.

[11] J. B. Postel, C. A. Sunshine, and D. Cohen, “The ARPA Internet Protocol,” to appear in Computer Networks, 1981.

[12] A. M. Rybczynski, D. F. Weir, and I. M. Cunningham, “Datapac Internetworking for International Services,” Proc. 4th Int. Conf. on Computer Communication, September 1978, pp. 47-56.

[13] A. M. Rybczinski, J. D. Palframan, and A. Thomas, “Design of the Datapac X.75 Internetworking Capability,” Proc. 5th Int. Conf. on Computer Communication, October 1980, pp. 735-740.

[14] J. F. Shoch, “Inter-Network Naming, Addressing, and Routing,” Proc. 17th IEEE Computer Society Int. Conf., September 1978, pp. 72-796.

[15] J. F. Shoch, D. Cohen, and E. A. Taft, “Mutual Encapsulation of Internetwork Protocols,” to appear in Computer Networks, 19817.

[16] C. A. Sunshine, “Interconnection of Computer Networks,” Computer Networks 1, 3, January 1977, pp. 175-195.

[17] C. A. Sunshine, “Source Routing in Computer Networks,” ACM SIGCOMM Computer Communication Rev. 7, 1, January 1977, pp. 29-33.

[18] C. A. Sunshine and J. B. Postel, Addressing Mobile Hosts in the ARPA Internet Environment, Internet Experiment Note 135, March 1980.

[19] D. F. Weir, J. B. Holmblad, and A. C. Rothberg, “An X.75 Based Network Architecture,” Proc. 5th Int. Conf. On Computer Communication, October 1980, pp. 741-750.


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

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

nmalykh@gmail.com

1Адрес был действителен в момент публикации документа, но утратил актуальность. Прим. перев.

2См. примечание в начале заметки.

3Доступна по ссылке. Прим. перев.

4Статья доступна по ссылке. Прим. перев.

5Статья доступна по ссылке. Прим. перев.

6Доступна в IEN 19. Прим. перев.

7Доступна в IEN 140. Прим. перев.