Технологии IBM : Технология Token Ring

Коммутация с помощью моста сетей Token Ring и декодирование RIF

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ объясняет мостовое соединение Token Ring и декодирование Поля маршрутной информации (RIF).

Фреймы Token Ring имеют подобную структуру к 802.3 Ethernet и кадрам Интерфейса для передачи распределенных данных по волоконно-оптическим каналам (FDDI). Эти кадры имеют назначение и адреса источника, а также Контрольную сумму фрейма (FCS) и раздел для переноса данных. Начало и конечные разделители также распространено.

/image/gif/paws/24501/trb_rif-100.gif

Фреймы Token Ring, но встроили дополнительные функции также. К этой категории относятся:

  • (Дополнительное) поле маршрутной информации (RIF)

  • Управление доступом (AC)

  • Управление кадрами (FC) и поля Frame Status (FS)

Кроме того, можно использовать первый бит адреса источника для указания на присутствие RIF. Но, только одно поле относительно при изучении Мостового соединения с маршрутизацией от источника (SRB).

trb_rif-2.gif

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

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

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Поля сведений о маршрутизации

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

/image/gif/paws/24501/trb_rif-3.gif

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

Вызов к фрагменту моста RIF между ПК A и ПК B в предыдущей схеме является 00AF.00B0.

Обзор структуры MAC-адреса

Locally Administered Addresses (LAA) обычно замечен на Станциях Token Ring, невзирая на то, что возможно назначить LAA на Ethernet и Станции FDDI. В LAA второй бит первого откусывания установлен в 1.

/image/gif/paws/24501/trb_rif-4.gif

Одни из навыков, которые требуются при поддержке Сетей Token Ring являются способностью преобразовать схемы шестнадцатеричной нумерации в двоичные единицы при необходимости. Token Ring предоставляет почти всю свою информацию в hex, но базовая структура основывается на двоичных знаках. Шестнадцатеричное представление обычно маски часть базовой структуры. Необходимо быть в состоянии преобразовать шестнадцатеричное представление в двоичные файлы для надлежащей интерпретации полей, с которыми вы работаете.

Данный пример демонстрирует это преобразование.

/image/gif/paws/24501/trb_rif-5.gif

  1. Разделите шестнадцатеричное число на отдельные цифры:

    /image/gif/paws/24501/trb_rif-6.gif

  2. Преобразуйте шестнадцатеричные числа в эти четыре двоичных знака (откусывание), которое представляет каждое шестнадцатеричное число:

    /image/gif/paws/24501/trb_rif-7.gif

  3. Измените двоичные полубайты на двоичные октеты:

    /image/gif/paws/24501/trb_rif-8.gif

Шестнадцатеричная нумерация

/image/gif/paws/24501/trb_rif-9.gif

Если предыдущий адрес является адресом назначения (DA), первый бит мог бы быть установлен в 1, который указывает, что это предназначено для группы или функционального адреса в принимающих станциях. Достаточно странно локальный/универсальный бит установлен в 1, как функциональное разрядное / разрядный групповой адрес. Поскольку выполнимо иметь локально администрируемый функциональный адрес для Token Ring, а также универсально назначенного адреса, это походит на упущение со стороны Комитета по IEEE 802.5. Функциональный и групповые адреса выходят за рамки этого документа, поскольку они не непосредственно применимы к мостовому соединению Token Ring. См. Token Ring документа / Цели главы IEEE 802.5 для получения дополнительной информации.

/image/gif/paws/24501/trb_rif-10.gif

Если предыдущий адрес является адресом источника, и Фрейм Token Ring несет RIF, первый бит установлен в 1. Если это - также LAA, адрес запускается с 0xC. Просмотрите шестнадцатеричный дамп кадра для определения этого.

trb_rif-11.gif

/image/gif/paws/24501/trb_rif-12.gif

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

/image/gif/paws/24501/trb_rif-13.gif

Глобальной сетью (WAN) может быть Frame Relay как в данном примере.

/image/gif/paws/24501/trb_rif-14.gif

Глобальная сеть (WAN) может быть X.25, как в данном примере.

/image/gif/paws/24501/trb_rif-15.gif

Глобальная сеть (WAN) может быть виртуальным кольцом, как в данном примере.

/image/gif/paws/24501/trb_rif-16.gif

Тип WAN не релевантен, потому что Фрейм Token Ring безопасно упакован в TCP/IP, или просто IP, прежде чем это достигнет Интерфейса WAN. Инкапсуляция Fast-Sequenced Transport (FST) поддерживается почти каждый тип LAN или глобальной сети (WAN).

trb_rif-17.gif

С непосредственной инкапсуляцией необходимо гарантировать, что Максимальные размеры передаваемого блока данных (MTU) всех интерфейсов в пути способны для обработки всех 802.5 кадров, поскольку непосредственная инкапсуляция не позволяет фрагментацию. Необходимо добавить дополнительные 73 байта, который является для заголовка Cisco RSRB и других издержек Token Ring к максимальному MTU Token Ring в пути для получения корректного MTU для всех неинтерфейсов Token Ring в пути. Последовательные соединения требуют, чтобы MTU был 1573, если MTU Token Ring является 1500. Только один переход позволен для непосредственной инкапсуляции.

В предыдущей схеме ПК A не может достигнуть ПК B, и ПК B не может достигнуть ПК A, пока маршрутизатор B не имеет узлы RSRB (непрямые) с маршрутизатором A. Маршрутизатор A имеет узлы RSRB с маршрутизатором B. Маршрутизаторам A и B можно было также установить непосредственную инкапсуляцию между ними. Маршрутизатор B может быть прямо к маршрутизатору A, но не маршрутизатору C. Маршрутизатор C может быть прямо к маршрутизатору A, но маршрутизаторам B и C нужны реальные узлы для передачи.

Другой способ просмотреть это продемонстрирован в этой схеме:

/image/gif/paws/24501/trb_rif-18.gif

Прозрачное соединение маршрут-источник

Прозрачное соединение маршрут-источник (SRT) было добавлено в 802.5 спецификации. Это позволяет 802.5 кадрам без RIF пересекать Интерфейсы Token Ring, которые настроены для прозрачного режима моста. SRT также преобразовывает 802.3 в 802.5 для мостового соединения Token Ring Ethernet. Это не решает вопросы о мостовом соединении маршрутизируемых протоколов по различным средствам.

/image/gif/paws/24501/trb_rif-19.gif

Станции, которые используют SRT, не могут связаться со станциями, которые выполняют SRB, когда они находятся на отдельных кольцах. Эти два сценария существенно несовместимы. ПК SRT нужно патентованное решение Cisco для передачи с ПК SRB.

trb_rif-20.gif

ПК SRB также требует решения Cisco для передачи с ПК Ethernet.

/image/gif/paws/24501/trb_rif-21.gif

Примечание: В предыдущей схеме:

  • 6 номер фиктивного кольца, используемый для Сегмента Ethernet.

  • 7 поддельный номер моста, который указывает к Сегменту Ethernet.

  • PC Token Ring предполагают, что PC Ethernet находятся на Token Ring, потому что они требуют допустимого RIF.

  • Маршрутизатор составляет поддельную часть RIF, и это добавляет RIF к кадрам, предназначенным для PC A и B.

  • PC Ethernet не сообщают, что PC A и B не находятся на Ethernet. Маршрутизатор разделяет RIF от ПК A и ПК B кадры.

IEEE решил использовать немного схемы передачи заказа для Ethernet, которая отличается от того из Token Ring. В то время как тем из FDDI и Token Ring является Most Significant Bits (MSB) сначала, схемой Ethernet FDDI является Наименьший значащий бит (LSB) сначала.

trb_rif-22.gif

Соединение "источник-маршрут"

Это - простой сценарий, который иллюстрирует SRB:

/image/gif/paws/24501/trb_rif-23.gif

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

Анализаторы

trb_rif-24.gif

Рассмотрите RIF во Фрейме Token Ring для понимания концепции обозревателей. RIF имеет два основных раздела:

  • служебные байты (2)

  • байты ring-and-bridge (меньше чем 30)

Это - отказ служебных байтов:

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

/image/gif/paws/24501/trb_rif-25.gif

/image/gif/paws/24501/trb_rif-26.gif

Следует иметь в виду, что IBM работает в шестнадцатеричном, и что путь исходного маршрута от ПК к ПК B является 00AF.00B0. Помните, что необходимо преобразовать двоичное выражение битов ring-and-bridge к шестнадцатеричному выражению, которое используется, когда вы работаете с SRB. Этот путь в двоичных файлах 00000000.10101111.00000000.10110000. Вошедший двоичные полубайты, это 0000.0000.1010.1111.0000.0000.1011.0000. Последний номер моста всегда 0000, как конец путей на вызовах, не мосты. Правило состоит в том, что три откусывания делает вызов, и одно откусывание делает мост. Диапазоны 1-4095 для вызовов, и 1-15 для мостов.

/image/gif/paws/24501/trb_rif-27.gif

Часть ring-and-bridge RIF ранее обсуждена. Посмотрите раздел Полей сведений о маршрутизации для получения дополнительной информации. Если вы добавляете эти два служебных байта к исходному RIF, вы заканчиваете с 00AF.00B0. RIF должен быть по крайней мере два байта длиной, потому что он требует служебных байтов. У вас есть два вызова, таким образом, необходимо добавить две комбинации ring-and-bridge двух байтов каждый. Это делает RIF шесть байтов длиной. Помните, двоичная структура байтов является BBXLLLLL.DFFFXXXX.RRRRRRRR.RRRRBBBB.RRRRRRRR.RRRRBBBB.

Рассмотрите данный пример, анализатор одного маршрута от ПК к ПК B.

/image/gif/paws/24501/trb_rif-28.gif

RIF является C670.00AF.00B0. Откусывание C670 всегда 0.

/image/gif/paws/24501/trb_rif-29.gif

RIF анализатора одного маршрута появляется на Вызове B как C610.00AF.00B0, который принимает MTU 1500 и предполагает, что это считано слева направо. Прямой RIF является 0610.00AF.00B0, который принимает MTU 1500 и предполагает, что это считано слева направо. Биты MTU постепенно уменьшены от 111 (0x7) к максимальному значению размера блока данных, которое может обработать каждый мост, поскольку проводник проходит через мост на своей поездке. Мост исследует текущее значение битов MTU и, если значение больше, чем поддержки моста, мост должен постепенно уменьшить значение вниз к самому большому MTU, который это может поддержать. Для трансляционного объединения с помощью мостов к Ethernet максимальное значение размера блока данных является 1500.

trb_rif-30.gif

Когда многопортовый мост заменяет два моста порта, больше RIF возможно:

/image/gif/paws/24501/trb_rif-31.gif

Когда многопортовый маршрутизатор Cisco заменяет два моста порта, действия маршрутизатора как виртуальное кольцо для соединения фактических звонков. Это добавляет мосты к Интерфейсам Token Ring. В большинстве случаев все номера моста могут быть 1. Исключением являются параллельные мосты то подключение два вызова. ПК к ПК C теперь 0810.00A1.00F1.00C0.

Маршрутизатор Cisco с тремя интерфейсами Token Ring

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

/image/gif/paws/24501/trb_rif-32.gif

Эта схема демонстрирует маршрутизатор Cisco с двумя Интерфейсами Token Ring. Этот маршрутизатор не может выполнить RSRB.

/image/gif/paws/24501/trb_rif-33.gif

/image/gif/paws/24501/trb_rif-34.gif

RIF является самым трудным и основной аспект SRB Token Ring. Оставшаяся часть этого документа обсуждает другие способы достигнуть Фреймов Token Ring по различным топологиям сети, поскольку они заставляют их появиться как Token Ring к RIF. Пока RIF не завершен, технология для перемещения кадров от станции до станции должна так или иначе поддержать точный RIF. Коммутация соединения передачи данных (DLSw) является основной реализацией, которая завершает RIF. Этот документ только обращается к реализациям, в которых RIF несут от начала до конца через всю сеть.

trb_rif-35.gif

Это некоторые обычные правила для учета:

  • Устройства Системной сетевой архитектуры (SNA) имеют тенденцию отсылать проводники для всех маршрутов в поисках своего выбранного целевого устройства. Они одноадресно переданы к MAC - адресам назначения. Целевые устройства обычно инвертируют направление, укусил (D) и передал кадр обратно как directed frame, не проводник. SNA не имеет никакого фонового широковещательного трафика. Например, Front End Processor (FEP) не передают кадры, которые передавали их местоположение так, чтобы они могли быть найдены.

  • Network Basic Input/Output System (NetBIOS) передают анализаторам одного маршрута и ожидают, что станция назначения ответит с ответом проводника для всех маршрутов. NetBIOS также выполняет большое количество фонового широковещания. Устройства постоянно передают кадры, которые передают их местоположение и другие важные сообщения. NetBIOS, как правило, передает свои анализаторы к функциональному адресу NetBIOS, для которого слушают все Станции NETBIOS: C000.0000.0080.

  • Большинство других протоколов передает свои анализаторы, поскольку MAC передает, например, FFFF.FFFF.FFFF или C000. FFFF.FFFF.

  • Novell может быть настроен для передачи одного маршрута или широковещания по всем маршрутам. Станциям, возможно, понадобился бы route.com. Серверам, возможно, понадобился бы route.nlm.

При соединении двух вызовов с параллельными мостами номера моста должны быть уникальными.

/image/gif/paws/24501/trb_rif-36.gif

Локальное подтверждение

С локальным подтверждением (local-ack) маршрутизатор оказывается замешанным в 802.2 Управления логическим Каналом (LLC), сеанс типа 2 (LLC2), который происходит в уровне управления каналом передачи данных между с двумя окончаниями станциями. Необходимо понять некоторые основные принципы 802.2 уровней управления каналом передачи данных для понимания local-ack. Эти 802.2 являются IEEE и международным стандартом Открытого взаимодействия системы (OSI) для связи на канальном уровне. Международная организация по стандартизации (ISO) номер спецификации 8802.2. Несмотря на то, что много людей обращаются к семиуровневой модели OSI во время обсуждений LAN, более соответствующая модель является эталонной моделью LAN IEEE.

За исключением протоколов OSI (Connection Mode Network Service [CMNS] и Сетевой сервис без предварительного соединения [CLNS]) и протоколы International Telecommunication Unit (ITU), такие как X.25, большинство протоколов выше канального уровня является или составляющим собственность, таким как Межсетевой пакетный обмен (IPX), AppleTalk и Сеть Digital Equipment Corporation (DECnet), или они стандартизированы другим телом (TCP/IP и инженерная группа по развитию Интернета [IETF]). Ни IEEE, ни ITU не управляют спецификацией большинства протоколов, которые работают на основе LAN сегодня.

Эталонная модель локальной сети IEEE

/image/gif/paws/24501/trb_rif-37.gif

IEEE принял решение подразделить канальный уровень OSI на два уровня. 802.2 уровня имеют три типа сервиса:

  1. без установления соединения

  2. с установлением соединения

  3. подтвержденный без установления соединения

Тип 3 почти никогда не используется. Тип 2 используется SNA и NetBIOS. Маршрутизируемые протоколы, такие как IP, IPX и AppleTalk, которые настроены для 802.2 типов 1 использования.

Формат 802.2

В этом разделе рассматриваются некоторые ключевые области 802.2 уровней.

Точки доступа к сервису (SAP), используются, чтобы мультиплексировать и демультиплексировать высокоуровневые протоколы через 802.2 уровня. Типичный SAP, 04 (SNA), F0 (NetBIOS) и E0 (IPX). Контрольное поле является двумя октетами в 802.2. Это используется для инициализации сеанса и завершения, управления потоками и контроля сеанса. Local-ack в основном обрабатывает управление потоками и контроль сеанса. Это только применяется к сеансам с установкой соединения типа 2.

/image/gif/paws/24501/trb_rif-38.gif

Сеанс с установкой соединения подтверждает кадры, которые приняты, и указывает на номер кадра, которые передаются. Например, третий фрейм информации предназначил для партнера по сеансу, который еще не передал I-кадр, передается как я NR0 NS3. Это связывается, тот фрейм информации 3 должен быть передан и что следующий I-кадр ожидается как порядковый номер 0. Если партнер по сеансу уже имеет переданные кадры 0-4, I-кадр передается как я NR5 NS3. Это подтверждает, что структурирует 0-4, были получены, и говорит партнеру, что нормально передавать больше кадров. Если по какой-либо причине партнер по сеансу не способен для приема большего количества кадров для временного периода, партнер может передать контрольный кадр для подавления сеанса (например, S NR5 RNR). NR5 говорит другого партнера, что было получено, и RNR передает это, получатель не готов.

Контрольные кадры также используются, когда таймеры, которые установлены в конечных станциях, истекают, прежде чем они получат подтверждение выдающихся I-кадров. Станции могут передать контрольный кадр receiver-ready, который запрашивает, чтобы партнер сразу ответил. Например, станции могут передать ОПРОС NR4 RR S, который предполагает, что ожидаемый следующий фрейм равняется 4. В этой ситуации local-ack полезен.

Время от времени задержка распространения через глобальную сеть (WAN) может превысить настройки таймера в конечных системах. Это заставляет конечные станции повторно передавать I-кадры, даже при том, что исходные кадры отправлены, и подтверждения возвращены. Local-ack передает кадрам RR S до конца станцию, где это происходит из, в то время как код RSRB отправляет кадр системе другого конца.

Автоматическое декодирование RIF может быть выполнено с Инструментом декодирования RIF.


Дополнительные сведения


Document ID: 24501