Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

Согласование протоколов канального уровня мостами и коммутаторами

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

По принципу передачи пакетов между сетями с разными канальными протоколами мосты и коммутаторы подразделяются на инкапсулирующие (encapsulating) и транслирующие (translational).

Инкапсулирующие мосты и коммутаторы

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

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

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

Транслирующие мосты и коммутаторы

Транслирующие мосты и коммутаторы выполняют преобразование из одного протокола канального уровня в другой, например, Ethernet в FDDI, Fast Ethernet в Token Ring и т.п. Преобразование заключается в изменении формата кадра, в вычислении нового значения контрольной суммы. При этом они работают в соответствии со спецификациями RFC 1042 и 802.1H, определяющими правила преобразования полей кадров разных протоколов.

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

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

Так как технология 100VG-AnyLAN поддерживает кадры стандартного формата Ethernet или Token Ring, то в одних случаях трансляция может вовсе не потребоваться (при связи сегментами Ethernet или Token Ring), а в других - она может свестись к одной из известных процедур преобразования Token Ring -FDDI, Ethernet- FDDI.

Кроме изменения порядка бит при передаче байт адреса, трансляция протокола Ethernet (и Fast Ethernet, который использует формат кадров Ethernet) в протоколы FDDI и Token Ring включает выполнение следующих (возможно не всех) операций:

  • Вычисление длины поля данных кадра и помещение этого значения в поле Length при передаче кадра из сети FDDI или Token Ring в сеть Ethernet 802.3 (в кадрах FDDI и Token Ring поле длины отсутствует).
  • Заполнение полей статуса кадра при передаче кадров из сети FDDI или Token Ring в сеть Ethernet. Кадры FDDI и Token Ring имеют два бита, которые должны быть установлены станцией, которой предназначался кадр - бит распознавания адреса A и бит копирования кадра С. При получении кадра станция должна установить эти два бита для того, чтобы кадр, вернувшийся по кольцу к станции, его сгенерировавшей, принес данные обратной связи. При передаче коммутатором кадра в другую сеть нет стандартных правил для установки бит А и С в кадре, который возвращается по кольцу станции-источнику. Поэтому производители коммутаторов решают эту проблему по своему усмотрению.
  • Отбрасывание кадров, передаваемых из сетей FDDI или Token Ring в сеть Ethernet с размером поля данных большим, чем 1500 байт, так как это максимально возможное значение поля данных для сетей Ethernet. В дальнейшем возможно усечение максимального размера поля данных сетей FDDI или Token Ring средствами протоколов верхнего уровня, например, TCP. Другим вариантом решения этой проблемы является поддержка коммутатором IP фрагментации, но это требует, во-первых, реализации в коммутаторе протокола сетевого уровня, а во вторых, поддержки протокола IP взаимодействующими узлами транслируемых сетей.
  • Заполнение поля Type (тип протокола в поле данных) кадра Ethernet II при приходе кадров из сетей, поддерживающих кадры FDDI или Token Ring, в которых это поле отсутствует. Для сохранения информации поля Type в стандарте RFC 1042 предлагается использовать поле Type заголовка кадра LLC/SNAP, вкладываемого в поле данных МАС-кадра протоколов FDDI или Token Ring. При обратном преобразовании значение из поля Type заголовка LLC/SNAP переносится в поле Type кадра Ethernet II.
  • Пересчет контрольной суммы кадра в соответствии со сформированными значениями служебных полей кадра.

Трансляция на уровне канальных протоколов имеет преимущества по сравнению с инкапсуляцией:

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

Но трансляция имеет и недостатки:

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

Предыдущая глава | Оглавление | Следующая глава

Хостинг + Certum Commercial SSL и домен в подарок

VPS: SSD, KVM, бесплатные бэкапы и администрирование 24/7

Бесплатный перенос сайта + подарки к новоселью

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...