Функции физического уровня. Средства согласования

Большинство базовых технологий локальных сетей допускает использование различных спецификаций физического уровня в одной сети. Эти спецификации отличаются используемой кабельной системой, а также способом физического кодирования сигналов в кабелях. Например, технология Ethernet имеет 6 вариантов реализации физического уровня: 10Base-5, 10Base-2, 10Base-T, FOIRL, 10Base-FL и 10Base-FB.

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

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

Иногда концентраторы выполняют и более сложные функции, нежели замена метода физического кодирования сигнала. Например, при объединении физического уровня 100Base-TX и 100Base-T4 в сетях Fast Ethernet концентратор должен выполнять преобразование логического кода 4B/5B в логический код 8B/6T. Такой концентратор называется транслирующим. Операция трансляции логических кодов занимает гораздо больше времени, чем простое преобразование электрических импульсов в оптические, как это происходит при объединении сегментов 100Base-TX и 100Base-FX, использующих один и тот же метод логического кодирования 4B/5B. Из-за этого в одном домене коллизий Fast Ethernet допускается использование максимум одного транслирующего концентратора, тогда как нетранслирующих концентраторов может быть два.

Функции канального уровня модели OSI

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

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

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

Примерами протоколов канального уровня для локальных сетей являются протоколы Token Ring, Ethernet, Fast Ethernet, 100VG-AnyLAN, FDDI.

В глобальных сетях, которые редко обладают регулярной топологией, канальный уровень обеспечивает обмен сообщениями между двумя соседними компьютерами, соединенными индивидуальной линией связи. К таким протоколам типа "точка-точка" относятся протоколы PPP, SLIP, LAP-B, LAP-D. Эти протоколы не используют подуровня доступа к среде, но требуют наличия процедур управления потоком кадров, так как промежуточные коммутаторы могут переполниться при слишком высокой интенсивности трафика по некоторым индивидуальным каналам. Кроме того, из-за высокой степени зашумленности глобальных каналов связи в протоколах этих сетей широко используются методы передачи данных с предварительным установлением соединения и повторными передачами кадров при их искажениях и потерях.

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

В локальных сетях канальный уровень разделяется на два подуровня:

уровень управления логическим каналом (logical link control, LLC).

уровень доступа к среде (media access layer, MAC),

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

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



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

Для доступа к разделяемой среде в локальных сетях используется два типа методов доступа:

методы случайного доступа,

методы маркерного доступа.

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


Такая децентрализация делает работу сети более надежной.

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

Методы маркерного доступа основаны на детерминированной передаче от одного узла сети другому специального кадра информации - маркера (токена) доступа. Маркерные методы доступа используются в сетях Token Ring, ArcNet и FDDI. В таких сетях право на доступ к среде передается циклически от станции к станции по логическому кольцу.

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

Функции канального уровня реализуются установленными в компьютерах сетевыми адаптерами и соответствующими им драйверами, а также различным коммуникационным оборудованием: мостами, коммутаторами, маршрутизаторами, шлюзами. В зависимости от того, какой протокол реализует сетевой адаптер, адаптеры делятся на Ethernet-адаптеры, Token Ring-адаптеры, FDDI-адаптеры и т. д. Аналогично, коммутаторы, мосты и машрутизаторы могут иметь порты, поддерживающие различные канальные протоколы.

Все эти устройства могут выполнять следующие действия:

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


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

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

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

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

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

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

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

Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP

Метод инкапсуляции часто применяется, когда двум сетям, использующим один и тот же сетевой протокол, нужно связаться через транзитную сеть, которая работает с другими сетевыми протоколами. Примером могут служить две сети Х.25, которым нужно связаться между собой через сеть TCP/IP.

В таких случаях сетевой протокол транзитной сети считается протоколом более низкого уровня, чем сетевой протокол объединяемых сетей (рисунок 3.2). Поэтому пакеты сетевого протокола сопрягаемых сетей Х.25 инкапсулируются в пакеты TCP транспортного уровня транзитной сети TCP/IP пограничным маршрутизатором М1, и переносятся в пакетах TCP по транзитной сети до следующего пограничного маршрутизатора М2. Для переноса по сети TCP/IP пакеты TCP в соответствии с технологией этой сети помещаются в пакеты IP, которые инкапсулируются в кадры протокола канального уровня, например, РРР. Пограничный маршрутизатор М2 извлекает пакет Х.25 из пакета TCP и отправляет его по сети Х.25 в соответствии с правилами этого протокола - то есть предварительно установив виртуальное соединение с узлом назначения по адресу Х.25_S1, а затем отправив по этому виртуальному соединению прибывший пакет.

Рис. 3.2. Соединение сетей X.25 через транзитную сеть TCP/IP методом инкапсуляции

Реализация такого подхода требует от протокола сетевого уровня объединяемых сетей разработанных процедур нахождения адреса пограничного маршрутизатора М2 в транзитной сети TCP/IP по адресу сети назначения протокола Х.25. Обычно такие протоколы называют протоколами разрешения адресов - Address Resolution Protocol, ARP. Если бы такой протокол был определен для сети Х.25, то он бы должен оперировать с ARP-таблицей, подобно той, которая приведена на рисунке 3.2. Эта таблица содержит для каждого адреса сети назначения Х.25 соответствующий IP-адрес пограничного маршрутизатора, через который эту сеть можно достичь.

К сожалению, многие сетевые протоколы разрабатывались или в расчете на работу только в сетях своего стека протоколов ( например, протокол Х.25), или в расчете на работу только через локальные сети (например, протокол IPX).

Наибольшую гибкость при инкапсуляции своих пакетов в пакеты других сетевых протоколов демонстрирует протокол IP. Для него разработано семейство протоколов ARP, каждый из которых предназначен для выполнения процедуры инкапсуляции пакетов IP в определенный протокол - Ethernet, Х.25, frame relay, ATM и т.п.

Протокол Х.25 рассчитан на инкапсуляцию только в кадры протокола LAP-B, который в свою очередь передает эти кадры между соседними коммутаторами, соединенными выделенными каналами "точка-точка". Процедуры и таблицы нахождения локальных адресов соседних коммутаторов при передачах пакетов Х.25 не предусмотрены, так как в них нет надобности, если трафик не выходит за пределы сети Х.25. Поэтому для передачи пакетов Х.25 через сети с другим стеком протоколов процедуры разрешения адресов и форматы инкапсуляции необходимо определять отельным стандартом.

Похожая ситуация возникает при необходимости передачи пакетов протокола IPX через сети TCP/IP. Процедуры передачи пакетов через составные локальные сети в протоколе IPX предусмотрены. Однако, из-за того, что в протоколе IPX на сетевом уровне для задания адреса узла просто дублируется аппаратный адрес сетевого адаптера, процедуры отображения сетевого адреса узла на локальные адреса транзитных сетей здесь отсутствуют. Поэтому, для протокола IPX, как и для протокола Х.25, необходимо разработать дополнительный протокол для того, чтобы этот протокол мог использовать сети TCP/IP как транзитные.

Спецификация "cisco Systems X.25 over TCP (XOT)"

Стандартный способ для передачи трафика сетей Х.25 через сети TCP/IP предусмотрен в спецификации RFC 1613, имеющей название "cisco Systems X.25 over TCP (XOT)", разработанный сотрудниками компании cisco Systems и организации JANET.

Эта спецификация определяет способ инкапсуляции пакетов Х.25 в сообщения TCP для переноса их по магистральной сети TCP/IP.

Так как протокол Х.25 работает на основе установления соединения, то спецификация использует для инкапсуляции протокол TCP, который также работает с установлением соединения.


Для каждого виртуального соединения Х. 25 маршрутизатор, который поддерживает стандарт XOT, устанавливает отдельное TCP-соединение с другим пограничным маршрутизатором. Новое TCP-соединение устанавливается при поступлении из сети Х.25 служебного кадра Call Request, запрашивающего новое соединение и несущего Х.25-адрес узла назначения. Спецификация XOT не предусматривает какого-либо способа определения IP-адреса маршрутизатора-партнера по сети IP, поэтому наиболее целесообразно использовать ее для случая, когда такой партнер один, или же маршрутизатор должен иметь таблицу соответствия адресов Х.25 и IP-адресов маршрутизаторов-партнеров, сформированную вручную.

После установления TCP-соединения все пакеты Х.25, принадлежащие данному виртуальному соединению сети Х.25, передаются в сообщениях TCP, принадлежащих этому TCP-соединению. Так как протокол TCP ориентирован на передачу неструктурированного потока байт, то стандарт ХОТ имеет небольшой заголовок, состоящий из 4-х байт, для выделения пакетов Х.25 в потоке байт сообщений TCP.

Спецификация "Tunneling IPX Traffic through IP Networks"

Для туннелирования пакетов IPX через магистрали TCP/IP компания Novell предложила спецификацию "Tunneling IPX Traffic through IP Networks", которая была утверждена в качестве стандарта RFC 1234.

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

Транзитная IP-сеть вместе с объединяемыми IPX сетями рассматривается в этой спецификации как одна IPX-сеть, поэтому узлы по разные стороны IP-сети должны иметь один и тот же сетевой IPХ-адрес.

Спецификация RFC 1234 предлагает автоматизировать процесс поиска маршрутизатора-партнера в сети IP за счет прямого преобразования МАС-адреса узла на фиктивный IP-адрес этого же узла. Адрес узла в приходящем для транзитной передачи IPX-пакете состоит из 6 байт.Для получения IP-адреса назначения пакета, который будет переносить данный IPX-пакет, старшие два байта адреса узла отбрасываются, а оставшиеся 4 рассматриваются как IP-адрес.

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

Широковещательные пакеты сервиса SAP предлагается распространять на индивидуальной основе, то есть путем дублирования пакета всем узлам сети IPX через сеть IP.

Инкапсуляция (туннелирование) протоколов

Инкапсуляция (encapsulation) или туннелирование (tunneling) - это еще один метод решения задачи согласования сетей, который однако применим только для согласования транспортных протоколов и только при определенных ограничениях. Инкапсуляция может быть использована, когда две сети с одной транспортной технологией необходимо соединить через сеть, использующую другую транспортную технологию. В приведенном на рисунке 1.3 примере две сети с протоколом NetBIOS нужно соединить через сеть TCP/IP. Необходимо обеспечить только взаимодействие узлов двух сетей NetBIOS, а взаимодействие между узлами NetBIOS и узлами сети TCP/IP не предусматривается. То есть, при инкапсуляции промежуточная сеть используется только как транзитная транспортная система.

Рис. 1.3. Инкапсуляция протоколов сетевого уровня (вложение друг в друга)

Метод инкапсуляции заключается в том, что пограничные маршрутизаторы, которые подключают объединяемые сети к транзитной, упаковывают пакеты транспортного протокола объединяемых сетей в пакеты транспортного протокола транзитной сети. В данном случае пакеты NetBIOS упаковываются в пакеты TCP, как если бы пакеты NetBIOS представляли собой сообщения протокола прикладного уровня. Затем пакеты NetBIOS переносятся по сети TCP/IP до другого пограничного маршрутизатора. Второй пограничный маршрутизатор выполняет обратную операцию - он извлекает пакеты NetBIOS из пакетов TCP и отправляет их по сети назначения адресату.

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

Инкапсуляция может быть использована для транспортных протоколов любого уровня. Например, протокол сетевого уровня Х.25 может быть инкапсулирован в протокол транспортного уровня TCP, или же протокол сетевого уровня IP может быть инкапсулирован в протокол сетевого уровня Х.25. Для согласования сетей на сетевом уровне могут быть использованы многопротокольные и инкапсулирующие маршрутизаторы, а также программные и аппаратные шлюзы.

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

Использование единого сетевого протокола в маршрутизаторах

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

Мосты и коммутаторы, описанные в предыдущих разделах, представляют собой хорошее средство для построения структурированных сетей, но их возможности ограничиваются в основном соединением фрагментов сетей одной или близких технологий. Соединение таких разнородных сетей, как X.25 и Ethernet становится неразрешимой задачей для моста из-за самого принципа его работы, так как для передачи пакетов через сеть X.25 ему необходимо выполнить ряд несвойственных для прозрачного моста операций, например, операцию преобразования пакетов Ethernet с максимальным размером поля данных в 1500 байтов в 128-байтовые пакеты X.25.

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

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

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

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

При определении стратегий межсетевого взаимодействия понятие "сеть" использовалось в более узком смысле: "сеть - это совокупность компьютеров, использующих для взаимодействия один и тот же стек протоколов".

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

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

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

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

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

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



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

На рисунке 2.2 приведена гипотетическая интерсеть, иллюстрирующая идею использования сетевого протокола. Интерсеть состоит из 6 сетей, к каждой из которых присоединены ее узлы, которые в соответствии с терминологией ISO называются конечными системами - ES (End System). Терминология ISO здесь используется для удобства, так как сети разных типов используют различные термины для обозначения одних и тех же понятий, что вносит путаницу при рассмотрении механизма межсетевого взаимодействия с общих позиций. Внутренняя структура каждой сети не показана, так как она не имеет значения при рассмотрении сетевого протокола. Сети соединяются маршрутизаторами, которые ISO называет промежуточными системами - IS (Intermediate System). Каждая промежуточная система присоединена к нескольким сетям (по крайней мере к двум) и имеет в каждой такой сети локальный адрес, как и остальные конечные системы этой сети. Таким образом, каждый маршрутизатор имеет несколько локальных адресов, по числу сетей, подключенных к нему. Обычно каждый локальный адрес связан с соответствующим портом маршрутизатора. Промежуточная система должна поддерживать все протоколы, используемые в каждой из сетей, к которым она непосредственно присоединена.



Рис. 2.2. Гипотетическая интерсеть

IS N - промежуточная система/шлюз/маршрутизатор N; ESNn - конечная система/узел/хост n

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



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

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

Маршрутизатор выбирает маршрут на основании его представления о текущей конфигурации сети и принятого критерия выбора маршрута.


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

В сложных составных сетях почти всегда существует несколько альтернативных маршрутов для передачи пакетов между двумя конечными узлами. Так, в нашем примере для передачи пакетов от узла ES 1.1 сети 1 узлу ES 5.1 сети 5 существует несколько альтернативных маршрутов, из которых наиболее очевидными представляются:

ES1.1 --> IS3 --> СЕТЬ 3 --> IS 6 --> СЕТЬ 5 --> ES5.1

ES1.1 --> IS4 --> СЕТЬ 6 --> IS 8 --> СЕТЬ 5 --> ES5.1

ES1.1 --> IS1 --> СЕТЬ 2 --> IS 2 --> СЕТЬ 4 --> IS 10 --> СЕТЬ 5 --> ES5.1,

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

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

Как конечный узел может узнать локальный адрес маршрутизатора или маршрутизаторов, присоединенных к его сети?

Как маршрутизатор может определить локальные адреса конечных узлов, присоединенных к его сетям?

Каким образом конечный узел может выбрать подходящий маршрутизатор в своей сети для отправки пакета через интерсеть, если таких маршрутизаторов несколько?

Каким образом маршрутизатор может узнать локальные адреса других маршрутизаторов, присоединенных к его сетям?

Каким образом маршрутизатор выбирает следующий маршрутизатор при выборе рационального маршрута пакета?

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

Протоколы сетевого уровня делятся на три класса. Протоколы первого класса так и называют протоколами сетевого уровня.


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

Протоколы второго класса называют протоколами маршрутизации, они выполняют служебные функции для маршрутизаторов - переносят в своих блоках данных информацию о топологии связей интерсети. С помощью этих протоколов маршрутизаторы составляют карту связей сети той или иной степени подробности и принимают решение о том, какому следующему маршрутизатору нужно передать пакет для образования рационального пути. Примерами таких протоколов являются протоколы IPX RIP, IP RIP, EGP, BGP, OSPF, IS-IS. Служебная информация протоколов маршрутизации, иногда называемых также протоколами обмена маршрутной информацией, хранится в поле данных пакета сетевого уровня и имеет еще и свой собственный служебный заголовок, поэтому с точки зрения вложенности пакетов протоколы маршрутизации следует отнести к более высокому уровню, чем сетевой. Но функционально они решают общую задачу с пакетами сетевого уровня - доставляют кадры отдельных сетей нужному адресату через разнородную составную сеть.

Протоколы третьего класса отвечают за отображение адреса узла, используемого на сетевом уровне, в локальный адрес сети. Очевидно, что они нужны только в случае, если сетевой протокол использует в своих заголовках адреса конечных узлов, отличные от локальных (например, так делает протокол IP). Если же на сетевом уровне используются локальные адреса, то надобность в протоколах этого класса отпадает. Такие протоколы часто называют протоколами разрешения адресов - Address Resolution Protocol, ARP. Иногда их относят не к сетевому уровню, а к канальному, хотя тонкости классификации не изменяют их сути.

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


Именно такая схема адресации является одной из причин большой гибкости протокола IP, что выгодно отличает его от протокола IPX. Протокол IPX использует в качестве адреса узла копию МАС-адреса, поэтому может работать только поверх протоколов канального уровня локальных сетей.

Поддержка маршрутизаторами различных базовых технологий

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

Для локальных сетей этот перечень определяется набором интерфейсов, поддерживаемых маршрутизатором. Для портов локальной сети понятие "интерфейс маршрутизатора" включает как физический, так и канальный протокол как неразрывное целое, описывающее базовую технологию. Обычно модульный маршрутизатор на основе шасси имеет в номенклатуре интерфейсных модулей модули для сетей Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN и ATM.

Для глобальных сетей перечень включает два списка - набор интерфейсов физического уровня для связи с аппаратурой передачи данных (модемами, устройствами CSU/DSU или терминальными адаптерами ISDN), а также набор протоколов канального и, может быть, сетевого уровня, необходимых для подключения к глобальным сетям с коммутацией каналов и пакетов (набор этих протоколов часто называется глобальным сервисом). Для глобальных сетей интерфейс не связан жестко с базовой технологией, так как один и тот же протокол физического уровня, например, RS-232, может использоваться с различной аппаратурой передачи данных и различными протоколами канального и сетевого уровня.

Обычно в современных маршрутизаторах для организации глобальных связей поддерживаются интерфейсы последовательных линий (serial lines) RS-232, RS-449/422, V.35 (для передачи данных со скоростями до 2 - 6 Мб/с), высокоскоростной интерфейс HSSI, обеспечивающий скорость до 52 Мб/с, а также интерфейс G.703 для непосредственной связи с цифровыми глобальными каналами T1/E1, T3/E3 и интерфейсы BRI и PRI сетей ISDN.Наличие интерфейсов G.703 и BRI/PRI говорит о том, что маршрутизаторы включают аппаратуру передачи данных цифровых каналов T1/E1 или сетей ISDN соответственно.

В набор поддерживаемых глобальных сервисов обычно входят сервисы сетей X.25, frame relay, ISDN и коммутируемых аналоговых телефонных сетей, сетей ATM, а также поддержка протокола канального уровня PPP.

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



Рис. 2.3. Упрощенная схема использования маршрутизаторов различных типов

Использование нескольких протоколов сетевого уровня (IP, IPX, X.25)

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

Хотя идея объединения составной сети с помощью маршрутизаторов подразумевает использование во всех частях сети одного сетевого протокола, очень часто сетевым интеграторам и администраторам приходится сталкиваться с задачей объединения сетей, каждая из которых уже работает на основе своего сетевого протокола. Имеется несколько сетевых протоколов, которые получили широкое распространение: IP, IPX, DECnet, Banyan IP, AppleTalk. Каждый из них имеет свою нишу и своих сторонников, поэтому очень вероятно, что в отдельных частях большой сети будут использоваться разные сетевые протоколы. Маршрутизаторы, даже многопротокольные, не могут решить задачу совместной работы сетей, использующих разные сетевые протоколы, поэтому в таких случаях используются другие средства, например, программные шлюзы.

Использование различных базовых сетевых технологий

Базовая сетевая технология - это согласованный набор протоколов и реализующих их программно-аппаратных средств, достаточный для построения вычислительной сети. Протоколы, на основе которых строится сеть базовой технологии, специально разрабатывались для совместной работы, поэтому от разработчика сети не требуется дополнительных усилий по организации их взаимодействия. Примерами базовых сетевых технологий могут служить хорошо известные технологии Ethernet и Token Ring для локальных сетей и технологии Х.25 и frame relay для территориальных сетей. Для получения работоспособной сети в этом случае достаточно приобрести программные и аппаратные средства, относящиеся к одной базовой технологии - сетевые адаптеры с драйверами, концентраторы, коммутаторы, кабельную систему и т.п., и соединить их в соответствии с требованиями стандарта на данную технологию.

Однако, построение крупной сети на основе одной базовой технологии - это большая редкость. Обычным состоянием для любой вычислительной сети средних и крупных размеров является сосуществование различных стандартов и базовых технологий. Появление новых технологий, таких как Fast Ethernet или 100VG-AnyLAN, не означает, что мгновенно исчезают старые, например, 10-Мегабитный Ethernet, Token Ring или FDDI, так как в эти технологии были сделаны огромные капиталовложения. Поэтому трудно рассчитывать на вытеснение в обозримом будущем всех технологий какой-либо одной, хотя бы и такой многообещающей, как ATM.

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

Комбинирование разных протоколов сбора маршрутной информации (RIP, OSPF, NLSP)

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

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

В результате в корпоративной сети может одновременно работать несколько протоколов обмена маршрутной информации, например, RIP IP, RIP IPX, OSPF, NLSP, IGRP. Для того, чтобы добиться их согласованной работы, от администратора сети требуется использование соответствующих маршрутизаторов и выполнения специфических операций по их настройке.

Коммутатор Catalyst 5000 компании Cisco Systems

Коммутатор Catalyst 5000 представляет собой старшую модель семейства Catalyst. Это модульная, многоуровневая платформа коммутации, которая обеспечивает высокий уровень производительности, предоставляя возможность как для создания выделенных соединений в сети Ethernet со скоростями 10 и 100 Mб/с, так и для организации взаимодействия с сетями FDDI и АТМ.

Шасси Catalyst 5000 имеет 5 разъемов. В один разъем устанавливается модуль управления Supervisor Engine, который управляет доступом к коммутируемой матрице, имеющей возможность коммутации более 1 млн. пакетов в секунду. Модуль поддерживает функции локального и удаленного управления и имеет два порта Fast Ethernet, которые могут использоваться для соединения серверов сети или каскадирования устройств Catalyst 5000. Остальные разъемы могут использоваться для установки следующих модулей:

24 порта 10Base-T;

12 портов 10Base-FL;

12 портов 100Base -TX;

12 портов 100Base-FX;

1 порт DAS CDDI/FDDI (не более 3-х модулей в шасси);

1 порт 155 Мб/с АТМ (не более 3-х модулей в шасси).

Одно устройство Catalyst 5000 может поддерживать до 96 коммутируемых портов Ethernet и до 50 коммутируемых портов Fast Ethernet.

Поддерживается формирование виртуальных сетей как в пределах одного устройства Catalyst 5000, так и для нескольких устройств на основе группирования портов. Можно создать до 1000 виртуальных сетей для нескольких устройств Catalyst 5000, соединенных интерфейсами Fast Ethernet, CDDI/FDDI или ATM. Любой интерфейс Fast Ethernet может быть сконфигурирован как интерфейс InterSwitch Link (ISL) для поддержки нескольких виртуальных сетей. Интерфейс ISL - частное решение компании Cisco для передачи информации между коммутаторами о виртуальных сетях.

Все виртуальные сети поддерживают протокол IEEE 802.1d Spanning Tree для обеспечения отказоустойчивых соединений. При использовании интерфейса АТМ для соединения коммутаторов поддержка виртуальных сетей осуществляется на основе спецификации LANE через виртуальные соединения. Интерфейс FDDI поддерживает виртуальные сети с помощью спецификации 802.10.

Отличительной особенностью коммутаторов Catalyst является выполнение коммутации на 3 уровне модели OSI, что позволяет объединять виртуальные сети внутри устройства (для этого требуется дополнительное программное обеспечение).

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

Большой буфер (по 192 Кбайта на порт) обеспечивает сохранение и передачу информации при пиковых нагрузках.

Коммутаторы CELLplex компании 3Com

Коммутатор CELLplex 7000 представляет собой модульное устройство на основе шасси, осуществляющее коммутацию до 16 портов ATM (4 модуля по 4 порта). Он предназначен для образования высокоскоростной ATM-магистрали сети путем соединения с другими ATM-коммутаторами или же для подключения высокоскоростных ATM-узлов к стянутой в точку магистрали сети на основе центра данных, имеющего порт ATM.

Коммутационный центр обеспечивает обмен данными по схеме 16(16, используя неблокирующую технологию коммутации "на лету" с общей пропускной способностью 2.56 Гб/с и поддерживая до 4096 виртуальных каналов на порт.

Пассивная внутренняя шина коммутатора обеспечивает передачу данных со скоростью до 20.48 Гб/с, обеспечивая переход в будущем на интерфейсные модули с большим количеством портов или с более скоростными портами.

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

Имеются два типа интерфейсных модулей:

модуль с 4 портами OC-3c 155 Мб/с для многомодового оптоволоконного кабеля, предназначенный для локальных связей;

модуль с 4 портами DS-3 45 Мб/с - для глобальных связей.

Коммутатор поддерживает основные спецификации технологии ATM: установление коммутируемых виртуальных каналов (SVC) по спецификациям UNI 3.0 и 3.1, поддержку постоянных виртуальных каналов (PVC) с помощью системы управления, Interim Interswitch Signaling Protocol (IISP), эмуляцию локальных сетей (LAN emulation), управление перегрузками (congestion management).

Управление коммутатором реализовано для стандартов: SNMP, ILMI, MIB 2, ATM MIB, SONET MIB. Используется система управления Transcend.

Коммутатор CELLplex 7200 совмещает функции ATM-коммутатора и Ethernet-коммутатора, одновременно позволяя ликвидировать узкие места на магистрали сети и в сетях отделов.

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

Коммутационный ATM-центр (8(8) совмещен с процессором Ethernet/ATM коммутации на микросхеме ZipChip. ZipChip преобразует пакеты данных Ethernet в стандартные ячейки ATM, а затем коммутирует их со скоростью до 780000 ячеек в секунду.

В отличие от модели CELLplex 7000 модель CELLplex 7200 имеет не два, а четыре типа интерфейсных модулей:

модуль с двумя портами ATM OC-3c;

модуль с двумя портами DS-3;

модуль с 12 портами Ethernet и одним портом ATM OC-3c;

модуль с 12 портами Ethernet и одним портом ATM DS-3.

Остальные характеристики коммутаторов CELLplex 7200 и CELLplex 7000 практически совпадают.

Коммутаторы CELLplex поддерживают как серверную, так и клиентскую части спецификации LAN Emulation. При реализации в коммутаторе CELLplex серверов LECS, LES и BUS возможна поддержка до 16 эмулируемых сетей, каждая из которых включает до 16 клиентов LEC.

Маршрутизаторы компании Cisco

Маршрутизаторы, выпускаемые компанией Cisco, можно разделить на следующие классы:

Модульные маршрутизаторы. Сюда входят маршрутизаторы, предназначенные для построения магистралей крупных сетей и работающие практически со всеми технологиями локальных и глобальных сетей и со всеми основными сетевыми протоколами: серии Cisco 7500, 7000, AGS+, Cisco 4000;

Маршрутизаторы с фиксированным числом портов, предназначенные для объединения сетей небольших офисов: серии Cisco 3000, Cisco 2500;

Маршрутизаторы для подключения тупиковой удаленной локальной сети - "расшири-

тели" сетей (LAN extenders): серия Cisco 1000;

Маршрутизаторы, встраиваемые в персональные компьютеры - карты AccessPro PC представляют собой полнофункциональные многопротокольные маршрутизаторы, которые устанавливаются в IBM-совместимые персональные компьютеры с шинами ISA или EISA;

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

Модульные маршрутизаторы предоставляют возможность строить систему, выбирая необходимые интерфейсные модули. Количество модулей ограничено размером шасси. Все маршрутизаторы работают под управлением IOS. Модульные маршрутизаторы компании Cisco включают следующие модели: Cisco 7500, Cisco 7000, AGS+, Cisco 4000.

Серия Cisco 7000 поддерживает очень широкий диапазон соединений, среди которых: Ethernet, Token Ring, FDDI, Serial, HSSI, ATM, Channelized T1, Fractionalized E1 (G.703/G.704), ISDN PRI, Channel Interface for IBM mainframes.

Сетевые интерфейсы располагаются на модульных процессорах, которые обеспечивают прямое соединение между высокоскоростной магистралью Cisco Extended Bus (CxBus) и внешней сетью. Пять разъемов доступны под интерфейсные процессоры в модели Cisco 7000. Возможность "горячей" замены позволяет добавлять, заменять или удалять процессорные модули CxBus без прерывания работы сети.
Для хранения информации используется стандартная Flash-память. Все модели поставляются с комплектом для монтажа в стандартную 19" стойку. Cisco 7000 содержит пять слотов для интерфейсных процессоров.

Распределенная обработка выполняется процессором маршрутизации (Route Processor - RP), коммутирующим процессором (Switch Processor - SP) и силиконовым коммутирующим процессором (Silicon Switch Processor - SSP).

Протоколы конкретных локальных и глобальных сетей обеспечиваются соответствующими интерфейсными процессорами :

Ethernet Interface Processor (EIP),

Token Ring Interface Processor (TRIP),

FDDI Interface Processor (FIP),

High-Speed Serial Interface (HSSI) Interface Processor (HIP),

Fast Serial Interface Processor (FSIP),

Asynchronous Transfer Mode (ATM) Interface Processor (AIP),

MultiChannel Interface Processor (MIP),

Channel Interface Processor (CIP).

Маршрутизаторы Cisco 7000 обеспечивают общую скорость продвижения пакетов 270000 п/с.

Отличительные особенности серии Cisco 7000

Горячая программная переконфигурация системы (On-line software reconfiguration). Допускается изменять параметры системы без перезагрузки или остановки работы приложений и сервисов.

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

Быстрая загрузка. Обеспечивается быстрая загрузка системы (обычно 35 секунд) после обновления (upgrade) программного обеспечения с минимальным влиянием на сеть.

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

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

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



Перепрограммируемое ПЗУ (flash erasable programmable read-only memory - EPROM). Возможна быстрая, надежная и централизованная замена микрокода ПЗУ всех существующих в сети маршрутизаторов без необходимости присутствия оператора в физических местах их расположения.

Серия 7500 - это новая серия многопротокольных маршрутизаторов, объявленная в сентябре 1995 года и пришедшая на замену маршрутизаторов серии 7000, которые по данным IDC заняли 59% рынка магистральных маршрутизаторов.

Серия 7500 во многом похожа на серию 7000, но отличается от нее в нескольких отношениях:

Мультипроцессорная архитектура,

Шасси с большим количеством слотов,

Улучшенная отказоустойчивость,

Более быстрые внутренние шины.

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

Шасси старшей модели 7513 имеет 13 слотов, в 11 из которых могут устанавливаться интерфейсные модули. Для первой реализации модели 7513 предлагаются следующие интерфейсные модули:

100Base-T - 2 порта,

Token Ring - 6 портов,

10Base-T - 6 портов,

WAN-связи - 6 портов.

В отличие от одной внутренней шины серии 7000 с пропускной способностью только 500 Мб/с, шасси модели 7513 имеет 2 шины с пропускной способностью по 1 Гб/с каждая. К этим шинам подключаются два центральных модуля RPS (Rout Processor Switch), на которых работает операционная система IOS. Вместо процессора с тактовой частотой 33 МГц моделей серии 7000 в модулях RSP использованы RISC-процессоры с тактовой частотой 100 МГц.

Компания Cisco планирует в ближайшее время снабдить маршрутизаторы серии 7500 функцией сервера маршрутизации для поддержания модели виртуального маршрутизатора в сетях, использующих коммутаторы. Для этого требуется внести соответствующие изменения в IOS, а также в коммутаторы Catalyst.Новая версия IOS также будет в состоянии загружать маршрутные таблицы в интерфейсные модули серии 7500, которые будут иметь возможность самостоятельно принимать маршрутные решения без участия центральных модулей RPS.

Рис. 3.9. Структура маршрутизаторов новой серии Cisco 7500

Мост/маршрутизатор NETBuilder II компании 3Com

Мост/маршрутизатор NETBuilder II предназначен для соединения больших, многосегментных локальных сетей с сетевой магистралью. Его внутренняя шина имеет пропускную способность 800 Мб/с и в сочетании с мультипроцессорной RISC-архитектурой обеспечивает быстрый обмен пакетами между портами во всех режимах работы. Можно менять конфигурацию устройства не останавливая его работы - это обеспечивается за счет соответствующей программной поддержки процесса конфигурирования.

Имеется несколько вариантов шасси для NETBuilder II - на 4 слота, на 8 слотов и расширенное шасси на 8 слотов. В слоты шасси устанавливаются модули двух размеров - обычного и расширенного. В шасси на 4 и на 8 слотов имеются слоты для обычных модулей и слоты для расширенных модулей, причем в расширенный слот можно установить два обычных модуля. Расширенное шасси отличается тем, что в нем пара соседних обычных слотов образует один слот для расширенного модуля, поэтому его компоновка отличается большей гибкостью, чем у обычного шасси. Все модули подходят для любого варианта шасси.

Основную работу по ведению топологической базы данных и вычислению маршрутов ведет модуль Communications Engine Card (CEC), то есть модуль коммуникационного центра. Кроме этого, он выполняет и функции управления, включая диагностику с использованием специального диагностического процессора. Высокая скорость вычисления маршрутов обеспечивается за счет наличия в модуле специализированной БИС, работающей совместно с RISC-процессором AMD 29000. CEC выпускается в двух вариантах - с быстрой памятью объемом 12 Мбайт и объемом 20 Мбайт. Наличие модуля CEC в шасси обязательно.

Модуль CEC совместно с шиной 800 Мб/с обеспечивает скорость продвижения 75000 пакетов в секунду. Дальнейшее повышение производительности маршрутизатора происходит при использовании мультипроцессорной схемы обработки маршрутов, когда каждый интерфейсный модуль маршрутизатора имеет свой процессор, работающий в кооперации с модулем CEC. Такой интеллектуальный интерфейсный модуль кэширует информацию о необходимых для его работы маршрутах и обращается к центральному модулю CEC только при отсутствии сведений о новом маршруте.
Использование мультипроцессорной архитектуры повышает скорость продвижения пакетов в модуле до 250000. Пока для маршрутизатора NETBuilder II выпускается только один интерфейсный модуль в мультипроцессорной архитектуре - это модуль NETBuilder II MP Ethernet 6-Port 10Base-T. Компания 3Com намерена реализовать в мультипроцессорной архитектуре интерфейсные модули для всех сетевых технологий.

NETBuilder II можно сконфигурировать так, чтобы он работал как мост. В качестве моста он поддерживает такие дополнительные функции, как защиту от широковещательных штормов, алгоритм покрывающего дерева, маршрутизацию от источника (Source rout bridging) и прозрачную маршрутизацию от источника (Source rout transparent bridging). Поддерживаются виртуальные группы, которые затем могут маршрутизироваться на внутренней шине NETBuilder II, образуя виртуальные сети.

В зависимости от используемых шасси и модулей NETBuilder II может поддерживать до 48 локальных связей и до 24 глобальных связей.

Для поддержки глобальных связей имеются модули с интерфейсами V.35, RS-232, RS-449, RS-530, G.703, X.21 и HSSI. Для глобальных связей поддерживаются скорости от 1200 б/с до скоростей T1/E1 и дробных линий T3/E3 (до 6.2 Мб/с), а с модулем HSSI - полные скорости T3/E3, а также SONET OC-1 (52 Мб/с). Модуль G.703 имеет встроенное устройство DSU/CSU. Интерфейсные модули для глобальных связей могут работать с сетями на основе стандартов PPP, X.25, frame relay, SMDS и ATM.

Для локальных связей имеются модули с портами:

Ethernet AUI (1 порт в модуле), BNC (1), 10Base-FL (2), 10Base-T (6);

Token Ring DB-9 или RJ-45 (1 порт по выбору);

FDDI с поддержкой многомодового или одномодового кабеля, возможно SAS или DAS подключение одного MAC-адреса.

Поддерживаются основные маршрутизируемые протоколы сетевого уровня, включая TCP/IP, Novell IPX, XNS, OSI, DECnet, VINES, AppleTalk, DLSw, APPN. Могут использоваться такие протоколы обмена маршрутной информацией, как RIP-IP, RIP-IPX, OSPF, IS-IS и Novell NLSP.



Для передачи пакетов по глобальным связям может осуществляться компрессия с коэффициентом сжатия до 1:4.

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

Для управления и администрирования моста/маршрутизатора NETBuilder II может использоваться система управления Transcend в средах Windows и UNIX.

Так как мост/маршрутизатор NETBuilder II представляет собой в высокой степени программируемое устройство, то набор функций, которые он может выполнять по отношению к своим портам и линиям связи, во многом зависит от состава загруженного в его память программного обеспечения. Версия программного обеспечения NETBuilder II 8.1 состоит из отдельных модулей: моста, центрального маршрутизатора в архитектуре Boundary Routing, IP (вместе с RIP, OSPF, EGP, BGP), IPX (вместе с NLSP), XNS, PPP, компрессии данных, сервисов вызова по телефонным коммутируемым линиям, поддержки мультипроцессорной архитектуры.

На рисунке 3.3 показан пример построения сети с использованием маршрутизатора NETBuilder II и основных моделей коммутаторов компании 3Com.

Для расширения возможностей NETBuilder II по построению глобальных связей через цифровые телефонные сети ISDN компания 3Com выпустила два устройства расширения: NETBuilder II WAN Extender T1 и E1. Это отдельные устройства в архитектуре SuperStack, которые работают в качестве дополнительного ISDN-интерфейса для моста/маршрутизатора NETBuilder II. Эти устройства обеспечивают большое количество 64-килобитных каналов как для коммутируемых, так и для выделенных цифровых линий. Каждый такой канал данных представляет собой независимый коммуникационный путь к мосту/маршрутизатору в удаленной точке, и он представляется для NETBuilder II как отдельный "виртуальный" порт.

Рис. 3.3.

Устройство NETBuilder II WAN Extender E1 обеспечивает два интерфейса E1, которые независимо присоединяются к каналу ISDN PRI (30 каналов типа B и один канал типа D) или к каналу E1 (31 канал по 64 Кб/с). Поддерживается до 75 виртуальных портов и до 256 удаленных точек.

Мультиплексирование протоколов

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

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

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной: мультиплексирование осуществляется не на уровне стеков, а на уровне отдельных протоколов. В общем случае на каждом уровне может быть установлено несколько протоколов, и для каждого уровня может существовать собственный мультиплексор, выполняющий коммутацию между протоколами соседних уровней. Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, IPX через один сетевой адаптер. Аналогично сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.

Рис. 1.2. Мультиплексирование протоколов

Мультиплексирование протоколов в конечных узлах

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

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

Для того, чтобы один сетевой протокол мог использовать несколько канальных протоколов, реализованных в виде драйверов сетевых адаптеров, и, наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, необходимо стандартизовать интерфейс между этими уровнями. Примерами таких стандартных интерфейсов и их программных реализаций являются NDIS (Network Driver Interface Specification) и ODI (Open Driver Interface). Эти продукты выполняют не только функции мультиплексоров, но и функции программной среды, изолирующей драйверы сетевых адаптеров от аппаратуры, то есть самих сетевых адаптеров. NDIS, например. Предоставляет разработчику драйвера функции управления сетевым адаптером, например, функции ввода-вывода, или обработки прерываний. Что делает код драйвера более мобильным.

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

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

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

Магистральные маршрутизаторы (backbone routers) предназначены для построения центральной сети корпорации и соединения ее с помощью магистральных высокоскоростных и многопротокольных связей с сетями региональных отделений корпораций.

Маршрутизаторы региональных отделений - соединяют региональные отделения между собой и с центральной сетью. Сеть регионального отделения, также как и центральная сеть, может состоять из нескольких локальных сетей.

Маршрутизаторы удаленных офисов - соединяют, как правило, единственную локальную сеть удаленного офиса с центральной сетью или сетью регионального отделения.

Магистральный маршрутизатор должен поддерживать большой список сетевых протоколов и протоколов маршрутизации, чтобы поддерживать трафик всех существующих на предприятии вычислительных систем (в том числе и морально устаревших, но все еще успешно эксплуатирующихся), а также систем, которые могут появиться на предприятии в ближайшем будущем. Если центральная сеть связывается с региональными отделениями через Internet, то, возможно, потребуется поддержка и специфических протоколов маршрутизации этой сети, таких как EGP и BGP. Программное обеспечение магистральных маршрутизаторов обычно строится по модульному принципу, поэтому при возникновении потребности можно докупать и добавлять модули, реализующие недостающие протоколы. Перечень поддерживаемых сетевых протоколов обычно включает протоколы: IP, CONS и CLNS OSI, IPX, AppleTalk, DECnet, Banyan VINES, Xerox XNS, а перечень протоколов маршрутизации - IP RIP, IPX RIP, NLSP, OSPF, IS-IS OSI, EGP, BGP, VINES RTP, AppleTalk RTMP.

Маршрутизаторы удаленных офисов поддерживают один-два протокола локальных сетей и низкоскоростные глобальные сервисы.

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

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

Назначение и история создания технологии

Технология Data Link Switching (DLSw) была разработана для организации связи локальных сетей, не использующих сетевые маршрутизируемые протоколы, через транзитные сети TCP/IP. Основная область применения протокола DLSw - это транзитная передача кадров протокола LLC2, используемого в локальных сетях Token Ring архитектуры SNA и в локальных сетях NetBIOS.

Протоколы подуровня LLC (Logical Link Control) разработаны комитетом 802.2 института IEEE для организации логического обмена кадрами данных между двумя конечными станциями локальной сети после того, как МАС-подуровень станции-инициатора обмена получит доступ к среде. Для уровня LLC в стандарте 802.2 определены процедуры трех типов - LLC1, LLC2 и LLC3.

Процедура LLC1 выполняет передачу кадра без предварительного установления соединения, дейтаграммным методом. Основное назначение процедуры LLC1 - это обеспечение интерфейса между МАС-уровнем и вышележащими протоколами. Многие стеки протоколов используют ненадежную процедуру LLC1 на канальном уровне, с тем чтобы обеспечить надежное соединение средствами протоколов верхнего уровня - транспортными (TCP, SPX) или прикладными (NCP).

Процедура LLC2 работает на основе установления соединения между конечными станциями. После установления соединения пересылаемые кадры нумеруются, а для обеспечения надежной доставки кадров используется механизм положительных квитанций с повторными передачами при истечении таймера ожидания квитанции. Процедура LLC2 похожа на протокол LAP-B, используемый в сетях Х.25 для соединения "точка-точка" между конечным узлом и коммутатором сети.

Процедура LLC3 похожа на процедуру LLC1. Она работает без установления соединения, но с уведомлением отправителя о доставке кадра узлу назначения.

Протокол LLC2 используется в двух типах широко распространенных сетей - архитектуры IBM SNA с протоколом Token Ring на нижнем уровне и в сетях с протоколом NetBIOS. Технология DLSw позволяет передавать трафик этих сетей через общий туннельный канал в магистральных сетях TCP/IP, используя для объединения сетей многопротокольные маршрутизаторы.

Рис. 2.11. Два метода инкапсуляции кадров LLC2

Оба подхода имеют свои преимущества и недостатки. В первом случае избыточность служебных заголовков гораздо меньше, чем во втором. Кадры LLC2 быстрее упаковываются и извлекаются из транзитного протокола. Однако, в первом случае метод может работать только тогда, когда конечные узлы объединяются транзитной сетью одной технологии, например, только сетью Х.25 или только сетью frame relay. Говорят, что первый метод - это метод "одной транзитной передачи" (one hop).

Метод инкапсуляции в пакеты TCP в этом отношении универсален - он может работать при объединении конечных узлов через большое количество транзитных сетей разных технологий - X.25, frame relay, ATM, Ethernet, если только они связаны через маршрутизаторы, поддерживающие протокол TCP/IP. Протокол DLSw образует туннель через эти сети, пронося через него кадры LLC2, упакованные в сообщения TCP.

В стандартизации второго подхода наряду с другими производителями приняла участие компания IBM. Спонсором работ выступила организация APPN Imlementators Workshop (AIW) и организованный IBM форум производителей. В конце-концов протокол DLSw был принят комитетом IETF в качестве стандарта и получил номер RFC 1434. Позже этот стандарт был заменен версией RFC 1795, обратно совместимой с аппаратурой, поддерживающей RFC 1434. Однако, маршрутизаторы, поддерживающие версию RFC 1795, могут оказаться несовместимыми с маршрутизаторами, поддерживающими фирменные улучшения версии RFC 1434, например, фирменную версию DLSw+ компании Cisco.

Назначение и общие принципы работы

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

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

Гораздо чаще для согласования протоколов канального уровня используется трансляция с помощью таких промежуточных устройств, как мосты, коммутаторы и маршрутизаторы. Однако мосты и коммутаторы способны выполнять трансляцию только близких технологий, например, Ethernet и FDDI или Ethernet и Token Ring, а задача трансляции существенно отличающихся технологий локальных и глобальных сетей для устройств этого типа является слишком сложной. Примером таких "плохо совместимых" пар протоколов могут служить Х.25 и Ethernet или frame relay и Ethernet. Поскольку технология ATM близка к технологиям территориальных сетей и плохо совместима с традиционными канальными протоколами локальных сетей, то в этом случае трансляционные возможности мостов и коммутаторов так же оказываются недостаточными.

Маршрутизаторы же умеют выполнять трансляцию существенно отличающихся протоколов, используя для этого общий протокол сетевого уровня для всех согласуемых сетей. Для обеспечения совместимости ATM с протоколами канального уровня локальных сетей разработана спецификация Classical IP (RFC 1577), в которой в качестве объединяющего протокола сетевого уровня определен протокол IP. Такое решение хорошо работает, когда локальные сети объединяются с территориальной сетью АТМ, применение же этого подхода в случае, когда технология АТМ используется для построения локальной сети, не всегда оказывается эффективным.
Во-первых, необходимость использования маршрутизаторов для локальных сетей не всегда является экономически оправданной. Во-вторых, не все локальные сети поддерживают протокол сетевого уровня - так, например, функции маршрутизации отсутствуют в часто используемом стеке SMB/NetBIOS.

Поэтому возникла необходимость в создании технологии объединения сетей АТМ и традиционных локальных сетей без привлечения маршрутизаторов и протоколов сетевого уровня. Такой технологией и является технология LAN Emulation (LANE), разработанная организацией ATM Forum.

Эта спецификация использует инкапсуляцию кадров канальных протоколов локальных сетей, таких как Ethernet или Token Ring, в ячейки АТМ. Использование инкапсуляции в спецификации LAN Emulation несколько отличается от ее традиционного применения.

Обычно инкапсуляция обеспечивает связь двух сетей одной технологии через промежуточную сеть другой технологии. При этом узлы промежуточной сети недоступны конечным узлам объединяемых сетей (рисунок 2.4), и промежуточная сеть играет роль транзитной сети. LAN Emulation с помощью инкапсуляции решает не только традиционную задачу связи локальных сетей через транзитную сеть АТМ, но и решает общую задачу связи всех узлов составной сети - связи между узлами локальных сетей и внутренними узлами АТМ-сети, показанные как запрещенные на рисунке 2.4, также обеспечиваются с помощью протокола LAN Emulation.

Рис. 2.4. Взаимодействие двух локальных сетей через транзитную сеть ATM

Рассмотрим последовательно решение этих двух задач, причем для определенности будем предполагать, что сеть АТМ используется для соединения сетей Ethernet.

Недостатки версии LAN Emulation 1.0 и пути ее совершенствования

Наличие единственного серверного элемента в сети всегда является недостатком как в отношении производительности, так и в отношении надежности сети. При большом количестве клиентов LEC трафик к коммутатору, который поддерживает серверы LES и BUS, может быть очень большим, особенно при широком использовании метода группового распространения мультимедийной информации через BUS. Отказ коммутатора, в котором работает пара LES/BUS, будет приводить в останову всей сети.

К тому же производители часто ограничивают возможности серверов LES/BUS по одновременной работе с большим количеством клиентов LEC. Так, коммутатор LANplex компании 3Com поддерживает не более 16 эмулируемых сетей, в каждой из которых должно быть не более 16 клиентов LEC. Это ограничение не такое жесткое, если речь идет о LEC, встроенных в коммутаторы, ведь в этом случае один LEC может представлять несколько сот узлов. Однако, при использовании LEC в сетевых адаптерах ATM-узлов, такое ограничение является существенным тормозом при создании сети с большим количеством АТМ-узлов.

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

Протоколы взаимодействия между несколькими копиями LES/BUS, поддерживающими одну и ту же эмулируемую сеть, должны быть определены в спецификации LAN Emulation 2.0.

Кроме того, версия LAN Emulation 2.0 должна определить работу эмулируемой сети при передаче трафиков различных классов сервиса, а не только класса QoS 0 с неопределенной полосой пропускания. Это необходимо для работы в сети приложений, требующих обработки их кадров в реальном времени - приложений, организующих видеоконференции, передающих голос и т.п.

Несовместимость оборудования разных производителей

Проблемы несовместимости оборудования разных производителей, возникают чаще всего по трем причинам:

неточная (с ошибками) реализация стандартов;

использование фирменных стандартов;

улучшение стандартов - введение дополнительных функций и свойств.

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

Однако оставшиеся две причины часто порождают проблемы. На первый взгляд может показаться, что нет ничего страшного в том, что в коммуникационной аппаратуре имеются дополнительные функции или что эта аппаратура поддерживает наряду с общепринятыми и свои, фирменные протоколы. В любом случае остается возможность организовать совместную работу двух устройств разных производителей на основе стандартных протоколов. Тем не менее, на практике этой возможностью удается воспользоваться не всегда. Примером служит история с протоколом DLSw, первая стандартная версия которого была описана в документе RFC 1434. Затем компания Cisco выпустила фирменную улучшенную версию этого протокола, названную ею DLSw+, обратно совместимую со стандартной версией. Затем появилась новая стандартная версия DLSw, описанная в RFC 1795, которая также была обратно совместима с прежним стандартом. Однако, версия DLSw по RFC 1795 оказалась несовместимой с версией DLSw+, что породило необходимость модификации программного обеспечения в маршрутизаторах Cisco в тех организациях, которые стали устанавливать новые маршрутизаторы от других фирм.

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

|

Объединение локальных сетей через транзитную АТМ-сеть

Итак, пусть сеть ATM используется только в качестве транзитной сети. Сети Ethernet подключаются к сети коммутаторов АТМ с помощью пограничных устройств, названных в спецификации LAN Emulation АТМ-LAN конверторами. Такой конвертор должен иметь ATM-порт, с помощью которого он подключается к АТМ-сети, а также некоторое количество портов для подключения локальных сетей традиционных технологий. Конвертор имеет АТМ-адрес для взаимодействия с другими конверторами по сети АТМ. Кроме того, конвертор должен иметь информацию о МАС-адресах всех узлов каждой из локальных сетей, которые он присоединяет к сети АТМ. Конвертором может быть любое устройство локальной сети, но наиболее подходящим устройством для выполнения этих функций является коммутатор локальной сети, так как он имеет таблицу МАС-адресов всех устройств сети, которые обмениваются через него данными. Поэтому будем далее использовать термины АТМ-LAN конвертор и ATM-LAN коммутатор как синонимы.

В каждый АТМ-LAN коммутатор встроен протокол LAN Emulation (рисунок 2.5), в задачу которого входит передача принятого коммутатором МАС-кадра через АТМ-сеть другому ATM-LAN коммутатору. Так как к АТМ-сети может быть подключено несколько локальных сетей, то при получении из локальной сети кадра с МАС-адресом назначения, ATM-LAN коммутатор должен решить, к какому из остальных ATM-LAN коммутаторов относится данный МАС-адрес.

Рис. 2.5. Взаимодействие узлов локальных сетей через транзитную ATM-сеть

Таким образом, коммутатор для принятия решения о передаче кадра оперирует с двумя таблицами - с локальной, которая устанавливает соответствие МАС-адресов его локальной сети локальным портам, и с транзитной, которая содержит для каждого МАС-адреса составной сети АТМ-адрес пограничного коммутатора. Спецификация LAN Emulation не определяет конкретный вид таблиц ATM-LAN конверторов. Один из возможных вариантов этих таблиц приведен на рисунке 2.6.

Рис. 2.6. Таблицы адресов ATM-LAN коммутатора

Если АТМ-LAN коммутатор в результате просмотра адресных таблиц видит, что кадр нужно передать через АТМ-сеть другому ATM-LAN коммутатору, то он с помощью стека протоколов АТМ устанавливает виртуальное соединение (Virtual Channel Connection, VCC) с этим коммутатором, а затем передает по нему кадр в форме потока ячеек АТМ.

Особенностью инкапсуляции кадров в спецификации LAN Emulation является то, что кадр не упаковывается целиком в ячейку АТМ, а, в виду очень малого размера ее поля данных (48 байт), разбивается на фрагменты, которые затем инкапсулируются в последовательность АТМ-ячеек. Разбиение (сегментация) кадра и последующая его сборка осуществляются стандартными средствами стека АТМ, реализованного в ATM-LAN конверторе.

Для передачи трафика локальных сетей через сеть АТМ выбран класс АТМ-сервиса с неопределенной битовой скоростью, что хорошо соответствует алгоритмам работы протоколов локальных сетей, когда конечному узлу не дается никаких гарантий относительно выделяемой ему пропускной способности. Этот класс сервиса реализован в сетях АТМ подуровнем AAL5 (ATM Adaptaton Layer 5), принимающем запросы на установление соединений от протоколов верхних уровней. Остальные классы сервиса сетей АТМ, гарантирующие некоторую часть пропускной способности своим абонентам, в спецификации LAN Emulation версии 1.0 не используются, хотя потребность в них может возникать при работе в локальной сети приложений реального времени. Эти возможности ожидаются в следующих версиях спецификации LAN Emulation.

Отдельной задачей является автоматическое построение транзитных адресных таблиц АТМ-LAN коммутатора. Поскольку сети АТМ, как и большинство территориальных сетей, не поддерживают широковещательность, то обнаружить через сеть АТМ пограничные коммутаторы с помощью широковещательных запросов (как это делают, например, клиенты и серверы сетей NetWare) невозможно.

Ручное задание АТМ-адресов пограничных коммутаторов может оказаться обременительным занятием для администратора, если таких коммутаторов много и их набор часто претерпевает изменения, что характерно для локальных сетей.

Для автоматического построения транзитных адресных таблиц спецификация LAN Emulation предлагает использовать централизованный подход, то есть возложить решение этой задачи на сервер, присоединенный к сети АТМ (рисунок 2.7).



Этот сервер носит название LAN Emulation Server - LES. Та часть протокола спецификации LAN Emulation, которая работает в ATM-LAN коммутаторе, называется LAN Emulation Client - LEC. При своей инициализации LEC АТМ-LAN коммутатора сообщает серверу LES свои МАС- и ATM-адреса. Затем LEC регистрирует в LES все МАС-адреса узлов, которые он узнает при изучении своей локальной сети. Таким же образом поступают все пограничные ATM-LAN коммутаторы, поэтому в сервере LES накапливается общая таблица соответствия МАС-адресов узлов локальных сетей АТМ-адресам их пограничных коммутаторов.

Для взаимодействия с сервером LES каждый клиент LEC устанавливает прямое виртуальное соединение VCC с этим сервером, называемое Control Direct VCC. Это соединение устанавливается еще на стадии присоединения (Join) клиента LEC к эмулируемой сети. Под эмулируемой сетью понимается вся совокупность локальных сетей, взаимодействующих друг с другом через данный сервер LES и пограничные коммутаторы таким образом, как будто они работают в локальной сети, объединенной с помощью обычных повторителей, мостов и коммутаторов.

Каждый ATM-LAN коммутатор должен изначально знать только один адрес - АТМ-адрес сервера адресов LES, чтобы установить с ним виртуальное соединение. Теперь при приходе кадра с неизвестным МАС-адресом пограничный коммутатор может послать запрос серверу LES об АТМ-адресе коммутатора, который обслуживает локальную сеть, в которой имеется узел с данным МАС-адресом. Протокол передачи запроса на разрешение MAC-адреса и получения на него ответа является частью спецификации LAN Emulation и называется LE_ARP (LAN Emulation Address Resolution Protocol).



Рис. 2.7. Присоединение к эмулируемой сети и регистрация адресов

При получении LE_ARP-запроса сервер LES просматривает свои адресные таблицы, и если находит там зарегистрированный искомый МАС-адрес, то посылает LE_ARP-ответ, в котором указывает АТМ-адрес пограничного ATM-LAN коммутатора, которому нужно переслать кадр с данным МАС-адресом.


Если же искомый МАС-адрес отсутствует в таблице сервера, то сервер LES пересылает LE_ARP-запрос всем LEC, присоединившимся к эмулируемой сети.

Пересылать LE_ARP-запрос можно по очереди каждому клиенту LEC по тем индивидуальным виртуальным соединениям Control Direct VCC, которые были созданы при присоединении LEC к LES, но такой способ будет работать медленно при большом числе LEC. Для ускорения работы LES использует специфический механизм мультивещательности, поддерживаемый сетями АТМ. Этот механизм позволяет какому-либо узлу АТМ-сети, называемому корнем, устанавливать виртуальное соединение "один-ко-многим" (point-to-multipoint) и одновременно передавать одни и те же данные всем остальным узлам соединения, называемым листьями. При этом узлы-листья могут посылать данные только узлу-корню, а между собой обмениваться данными по соединению такого вида им запрещено.

Сервер LES при присоединении к эмулируемой сети нового клиента LEC сразу же добавляет последнего к мультивещательному соединению в качестве нового листа. Такое соединение называется Control Distribute VCC и служит для одновременного распространения LE_ARP-запроса всем LEC эмулируемой сети. Тот LEC, который опознал в запросе МАС-адрес обслуживаемой сети, генерирует LE_ARP-ответ, в котором указывает свой АТМ-адрес. Получив LE_ARP-ответ, сервер LES распространяет его также по мультивещательному VCC, чтобы все LEC сети могли бы кэшировать данную информацию для будущего использования.

После получения информации об АТМ-адресе соответствующего ATM-LAN коммутатора, LEC устанавливает с ним прямое виртуальное соединение Data Direct VCC, по которому начинает передавать кадры для данного МАС-адреса.

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



Эмуляцию широковещательности спецификация LAN Emulation выполняет с помощью уже описанного механизма мультивещательности "один-ко-многим". С этой целью в сети АТМ, кроме сервера LES, создается еще один сервер - Broadcast and Unknown Server, BUS. Сервер BUS организует доставку кадров с широковещательными адресами, а также кадров, ATM-адрес пограничного коммутатора которых неизвестен клиенту LEC, всем узлам эмулируемой сети. Сервер BUS имеет отдельный ATM-адрес, который сообщается сервером LES клиенту LEC при его присоединении к эмулируемой сети. Клиент LEC должен после этого установить с сервером BUS прямое виртуальное соединение Multicast Send VCC, по которому он будет пересылать кадры с широковещательными или неизвестными адресами. Сервер BUS добавляет каждого нового клиента LEC к мультивещательному соединению Multicast Forward VCC в качестве листа. Это соединение используется сервером BUS для одновременной рассылки широковещательных кадров и кадров с неизвестными адресами всем пограничным коммутаторам эмулируемой сети.

Спецификация LAN Emulation рекомендует клиентам LEC делать LE_ARP-запрос серверу LES для кадра с неизвестным адресом, и, не дожидаясь ответа, сразу же отправлять этот кадр через сервер BUS. Это делается для ускорения работы эмулируемой сети, так как кадры начнут доходить до узла назначения широковещательным образом еще до того, как будет получен LE_ARP-ответ от сервера LES. После получения LE_ARP-ответа, LEC перестает посылать кадры для данного МАС-адреса широковещательно, а устанавливает виртуальное соединение Data Direct VCC с конкретным ATM-LAN коммутатором (или же пользуется уже установленным ранее соединением с этим коммутатором) и передает остальные кадры с данным МАС-адресом уже по прямому каналу.

Организация нескольких эмулируемых сетей

Спецификация LAN Emulation позволяет организовать в рамках одной составной ATM-LAN сети нескольких отдельных эмулируемых сетей. Эти сети полностью отделены друг от друга, так что узлы, входящие в одну эмулируемую сеть, не получают кадры другой эмулируемой сети, какие бы типы МАС-адресов назначения не применялись: индивидуальные, групповые или широковещательные (рисунок 2.8). Такая концепция хорошо согласуется с концепцией виртуальных сетей, реализованной во многих коммутаторах традиционных протоколов локальных сетей, которые также определяются как наборы узлов сети, в которых локализуется весь их трафик, включая и широковещательный, вне зависимости от физического расположения узлов.

Для поддержания каждой эмулируемой сети в сети АТМ должна работать собственная пара серверов LES и BUS. АТМ-LAN конвертор может быть присоединен одновременно к нескольким эмулируемым сетям, при этом для работы с каждой сетью он имеет отдельный элемент LEC, который образует с каждым из серверов сети отдельные виртуальные соединения VCC, так что трафики эмулируемых сетей не смешиваются внутри сети АТМ. Аналогично, если два ATM-LAN коммутатора поддерживают несколько эмулируемых сетей, то для обмена данными между собой они образуют для каждой эмулируемой сети отдельное виртуальное соединение Data Direct VCC.

Рис. 2.8. Эмуляция локальных сетей в ATM/LAN сети

Для автоматического поддержания нескольких эмулируемых сетей в АТМ-сети организуется еще один центральный сервер - LAN Emulation Configuration Server, LECS. Этот сервер хранит список имен эмулируемых сетей, а также значения их основных параметров - АТМ-адреса серверов LES и BUS каждой сети, тип сети (например, Ethernet или Token Ring), максимальный размер кадра, поддерживаемого этой сетью и т.п. (рисунок 2.9). Поэтому каждый LEC при инициализации должен сначала установить соединение с единственным в сети сервером LECS (он должен знать АТМ-адрес этого сервера) и получить от LECS список всех эмулируемых сетей и их параметров.

Рис. 2.9. Компоненты LANE и их взаимосвязи

На основании полученной информации LEC должен выбрать эмулируемую сеть, к которой он желает присоединиться и известить об этом LECS. Затем LEC выполняет процедуру присоединения к LES выбранной эмулируемой сети, регистрирует там МАС-адреса своих узлов и начинает работать с составной сетью. Протокол взаимодействия клиентской части протокола LAN Emulation, а именно LEC, с серверными частями этой спецификации LECS, LES и BUS называется LAN Emulation User-Network Interface (LUNI).

Если ATM-LAN коммутатор поддерживает со стороны локальной сети несколько виртуальных сетей, то он может отождествить каждую виртуальную сеть с эмулируемой сетью. Поэтому при регистрации МАС-адресов на сервере LES определенной эмулируемой сети коммутатор регистрирует только те МАС-адреса, которые относятся к виртуальной сети, отождествляемой с этой эмулируемой сетью.

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

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

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

Организация взаимодействия всех узлов составной сети

Понятно, что узлы, непосредственно присоединенные к АТМ-коммутаторам с помощью АТМ-адаптеров, могут взаимодействовать между собой и без привлечения добавочных протоколов, таких как протоколы спецификации LAN Emulation. Но в таком случае приложения и протоколы прикладного уровня (NCP, SMB, NFS или FTP) должны быть модифицированы, так как они должны научиться поддерживать интерфейс со стеком протоколов АТМ на своем узле, а также не использовать отсутствующие в протоколах АТМ широковещательные рассылки. Кроме того, АТМ-узлы не смогут взаимодействовать с узлами локальных сетей, на которых установлены традиционные стеки протоколов с канальными протоколами Ethernet, Token Ring и т.п.

Спецификация LAN Emulation позволяет превратить АТМ-узлы в узлы, подобные традиционным узлам локальных сетей. Это достигается за счет размещения в АТМ-узле программного обеспечения клиента LEC, выполняющего те же функции, что и LEC пограничных ATM-LAN коммутаторов. На АТМ-узле LEC размещается между АТМ-протоколами драйвера сетевого адаптера АТМ и протоколом LLC (рисунок 2.10) или любым другим протоколом, который рассчитан на работу с протоколом МАС-уровня локальной сети. Протокол LEC предоставляет протоколам верхних уровней того узла, на котором он работает, тот же интерфейс, что и МАС-уровень сети Ethernet или Token Ring.

В отличие от протокола LEC, работающего на ATM-LAN коммутаторе, LEC отдельного АТМ-узла представляет только один МАС-адрес - МАС-адрес данного узла. Остальные действия LEC узла ничем не отличаются от LEC коммутатора. Он точно так же соединяется с сервером LECS, получает от него список эмулируемых сетей и присоединяется к одной из сетей, регистрируя в LES этой сети пару АТМ-адрес/МАС-адрес своего узла. Для присоединения одного и того же узла к нескольким сетям на узле должны работать одновременно несколько копий LEC, по одной на каждую сеть. Сообщения, получаемые от протоколов верхних уровней, LEC узла преобразует с помощью функции SAR в поток ячеек, который передает по виртуальному соединению протоколу LEC других АТМ-узлов.
Широковещательный трафик направляется узлам эмулируемой сети через сервер BUS.

Рис. 2.10. Взаимодействие протоколов в модели LAN Emulation

Наличие МАС-адреса у узла АТМ-сети позволяет ей взаимодействовать и с узлами присоединенных локальных сетей. При этом LEC узла взаимодействует с LEC пограничного коммутатора, посылая через сеть АТМ-кадр, в котором указывает в качестве адреса назначения МАС-адрес узла локальной сети, а в качестве адреса источника - свой МАС-адрес. Пограничный коммутатор затем передает кадр в соответствии с МАС-адресом назначения и своей адресной таблицей на один из своих локальных портов. Локальный узел, получив кадр, может ответить на него обычным кадром, указав в нем МАС-адрес узла АТМ-сети.

Спецификация LAN Emulation сегодня реализована в устройствах различных типов многих производителей. Серверные части спецификации - серверы LECS, LES и BUS обычно встраиваются в АТМ-коммутаторы или корпоративные АТМ-LAN коммутаторы, а клиентские компоненты LEC - в драйверы сетевых адаптеров и ATM-LAN коммутаторы уровня отдела или рабочей группы.

Поддержка нескольких независимых сетей с помощью многопротокольных маршрутизаторов

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

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

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

Рис. 3.1. Мультипротокольные сети - сети с несколькими сетевыми протоколами

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

Примеры оборудования с функциями согласования протоколов канального уровня

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

Принципы работы протокола DLSw

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

Рис. 2.12. Элементы протокола DLSw

Основной составляющей протокола DLSw является элемент, реализующий протокол "коммутатор DLSw - коммутатор DLSw", называемый протоколом SSP (Switch-to-Switch Protocol).

Протокол SSP взаимодействует с программным обеспечением протокола LLC2, от которого получает исходные кадры, а также с программным обеспечением TCP/IP, с помощью которого передает сообщения модулю SSP в коммутаторе DLSw на другом конце транзитной интерсети.

Другой важной составляющей коммутатора DLSw является элемент "DLC-трансфор-

мация", который обеспечивает преобразование протокола SDLC и других, отличных от LLC2 протоколов, в протокол LLC2.

Служебные сообщения между двумя элементами SSP, а также переносимые пользовательские данные (кадры LLC2) передаются по соединениям (connections), которые представляют собой дуплексные каналы "точка-точка" между двумя DLSw-коммутаторами.

Рис. 2.13. Соединения и каналы протокола DLSw

Канал (circuit) - это LLC2-тунель, соединяющий две конечные станции, которые поддерживают протокол SNA или NetBIOS. Два DLSw-коммутатора могут поддерживать несколько каналов с помощью одного соединения (рисунок 2.13). Такое мультиплексирование повышает эффективность протокола DLSw по сравнению с ранними схемами туннелирования, когда для каждого соединения LLC2 требовалось отдельное TCP-соединение.

Взаимодействие конечных узлов по протоколу DLSw можно упрощенно представить в виде следующей последовательности этапов.

1. Конечная станция посылает запрос на установление LLC2 соединения по своей локальной сети. Узлы, поддерживающие стек SNA, используют для этого служебные кадры LLC, вложенные в МАС-кадры Token Ring.
В этом случае узел назначения идентифицируется адресной парой MAC/SAP, где МАС - это МАС-адрес конечного узла, а SAP (Service Access Point) указывает на сервис, с которым нужно установить соединение в узле назначения (для SNA узлов используются значения SAP 0x04, 0x08 или 0x0C). В случае использования протокола NetBIOS станция устанавливает соединение с помощью запроса Name Query, в котором указывается NetBIOS-имя узла назначения.

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

2. Программное обеспечение SSP проверяет в своем кэше, не является ли запрос на установление соединения обращением к локальному узлу. Кэш может создаваться вручную либо автоматически, в зависимости от типа протоколов, работающих в локальной сети. Если SSP не находит пару MAC/SAP или имя NetBIOS в кэше локальных адресов, то он просматривает кэш адресов удаленных станций.

3. Если заданный адрес не найден и в кэше удаленных станций, то DLSw-коммутатор устанавливает соединение со всеми известными ему партнерами - DLSw-коммутаторами. Если же соединение с каким-либо коммутатором уже было установлено ранее, то DLSw-коммутатор пользуется им. По соединениям с коммутаторами-партнерами программное обеспечение передает сообщение протокола SSP, называемое CANUREACH. Все сообщения протокола SSP, инкапсулируемые в сообщения TCP, имеют служебный заголовок, в котором указывается тип сообщения, а также адресная информация - пара MAC/SAP, имя NetBIOS и некоторые дополнительные параметры. Служебным заголовком сопровождаются также и кадры LLC2, которые затем передаются по соединению.

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


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

5. Как только локальный DLSw-коммутатор принимает сообщение ICANREACH от какого-либо удаленного DLSw-коммутатора, он устанавливает канальное соединение между конечными LLC2-узлами (или узлами, которые выглядят как LLC2-узлы, благодаря элементу DLC-трансформации). После установления LLC2-канала конечные узлы могут обмениваться по нему данными, которые проходят по туннелю в сети TCP/IP. Каждый канал однозначно идентифицируется идентификатором канала в заголовке DLSw-сообщения, поэтому кадры LLC2 внутри общего соединения между коммутаторами не смешиваются.

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

Протокол LLC2 был разработан для использования в локальных сетях. Поэтому его разработчики рассчитывали на вполне определенное максимальное время получения положительных квитанций на отправленные кадры. В станциях, поддерживающих этот протокол, используется специальный таймер, называемый таймером Т1, который фиксирует превышение времени получения положительной квитанции на отправленные кадры (протокол LLC2 работает в режиме окна, разрешая отправлять 8 или 128 кадров до получения подтверждения на первый из них). При истечении таймера Т1 станция-отправитель повторяет передачу кадра определенное число раз, а затем считает, что соединение разорвано. В условиях работы через глобальные линии связи это может приводить к разрыву SNA или NetBIOS сессий просто из-за больших задержек в сети.

Для исключения таких ситуаций протокол DLSw использует технику "локальных подтверждений" (local termnation) (рисунок 2.14).

Рис. 2.14. Локальное подтверждение в каналах LLC2

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


На удаленном конце транзитной сети коммутатор DLSw организует надежную передачу кадра по локальной сети с помощью механизма подтверждений протокола LLC2.

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

Поддержка узлов, не являющихся узлами LLC2

В сетях SNA только часть узлов работает с протоколом LLC2 - это те узлы, которые подключаются к процессорам FEP по протоколу Token Ring. В то же время существует большое количество узлов, работающих на канальном уровне по протоколу SDLC или BSC. Кроме того, SNA трафик может быть представлен трафиком протокола Qualified Ligical Link Control (QLLC), который разработан для передачи трафика SDLC по сетям Х.25.

Протокол DLSw предусматривает поддержку этих видов трафика с помощью программного обеспечения DLC-трансформация, которое отображает команды протоколов, отличающихся от LLC2, в команды протокола LLC2.

Для поддержки трафика SDLC маршрутизаторы, работающие по протоколу DLSw, должны в режиме спуффинга имитировать постоянные опросы (polls) конечной станции процессором FEP. Эта имитация выполняется программным обеспечением DLC-трансформации.

Поддержка дейтаграммного и широковещательного трафика

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

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

Для имитации широковещательности коммутаторы DLSw рассылают такие дейтаграммы всем известным им DLSw-партнерам по IP-сети.

В отличие от спецификации LAN Emulation стандарт DLSw не предусматривает в сети IP централизованного сервера, который бы регистрировал все DLSw-коммутаторы, образующие единую локальную сеть.

Протокол, интерфейс, стек протоколов. Модель ISO/OSI

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

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

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

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

Международная Организация по Стандартам (International Standards Organization, ISO) разработала модель, которая четко определяет различные уровни взаимодействия систем, дает им стандартные имена и указывает, какую работу должен делать каждый уровень. Эта модель называется моделью взаимодействия открытых систем (Open System Interconnection, OSI) или моделью ISO/OSI.

В модели OSI взаимодействие делится на семь уровней или слоев, как показано на рисунке 5.1. Каждый уровень имеет дело с одним определенным аспектом взаимодействия. Таким образом, проблема взаимодействия декомпозирована на 7 частных проблем, каждая из которых может быть решена независимо от других.
Каждый уровень поддерживает интерфейсы с выше- и нижележащими уровнями.

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

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

Рис. 5.1. Модель взаимодействия открытых систем ISO/OSI

Итак, пусть приложение обращается с запросом к прикладному уровню, например к файловому сервису. На основании этого запроса программное обеспечение прикладного уровня формирует сообщение стандартного формата, в которое помещает служебную информацию (заголовок) и, возможно, передаваемые данные. Затем это сообщение направляется представительному уровню. Представительный уровень добавляет к сообщению свой заголовок и передает результат вниз сеансовому уровню, который в свою очередь добавляет свой заголовок и т.д. Некоторые реализации протоколов предусматривают наличие в сообщении не только заголовка, но и концевика. Наконец, сообщение достигает самого низкого, физического уровня, который действительно передает его по линиям связи. К этому моменту сообщение выглядит так, как показано на рисунке 5.2. (Здесь мы сознательно упростили картину, не рассматривая пока процедуры сборки-разборки пакетов.)



Рис. 5.2. Вложенность пакетов различных уровней

Когда сообщение по сети поступает на другую машину, оно последовательно перемещается вверх с уровня на уровень.


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

В модели OSI различается два основных типа протоколов. В протоколах с установлением соединения (connection-oriented network service, CONS) перед обменом данными отправитель и получатель должны сначала установить соединение и, возможно, выбрать протокол, который они будут использовать. После завершения диалога они должны разорвать это соединение.

Вторая группа протоколов - протоколы без предварительного установления соединения (connectionless network service, CLNS). Такие протоколы называются также дейтаграммными протоколами. Отправитель просто передает сообщение, когда оно готово. При взаимодействии компьютеров используются как те, так и другие протоколы.

Функции уровней модели OSI

Модель ISO/OSI определяет функции уровней следующим образом:

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

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

Примером протокола физического уровня может служить спецификация 10Base-T технологии Ethernet, которая определяет в качестве используемого кабеля неэкранированную витую пару категории 3 с волновым сопротивлением 100 Ом, разъем RJ-45, максимальную длину физического сегмента 100 метров, манчестерский код для представления данных на кабеле, и другие характеристики среды и электрических сигналов.



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

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

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



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

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

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

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


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

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

Примерами протоколов сетевого уровня являются протокол межсетевого взаимодействия IP стека TCP/IP и протокол межсетевого обмена пакетами IPX стека Novell.

Транспортный уровень. На пути от отправителя к получателю пакеты могут быть искажены или утеряны. Хотя некоторые приложения имеют собственные средства обработки ошибок, существуют и такие, которые предпочитают сразу иметь дело с надежным соединением. Работа транспортного уровня заключается в том, чтобы обеспечить приложениям или верхним уровням стека - прикладному и сеансовому - передачу данных с той степенью надежности, которая им требуется. Модель OSI определяет пять классов сервиса, предоставляемых транспортным уровнем. Эти виды сервиса отличаются качеством предоставляемых услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными прикладными протоколами через общий транспортный протокол, а главное - способностью к обнаружению и исправлению ошибок передачи, таких как искажение, потеря и дублирование пакетов.

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



Начиная с транспортного уровня, все вышележащие протоколы реализуются программными средствами, обычно включаемыми в состав сетевой операционной системы. В качестве примера транспортных протоколов можно привести протоколы TCP и UDP стека TCP/IP и протокол SPX стека Novell.

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

Уровень представления. Этот уровень обеспечивает гарантию того, что информация, передаваемая прикладным уровнем, будет понятна прикладному уровню в другой системе. В случаях необходимости уровень представления выполняет преобразование форматов данных в некоторый общий формат представления, а на приеме, соответственно, выполняет обратное преобразование. Таким образом прикладные уровни могут преодолеть, например, синтаксические различия в представлении данных. На этом уровне может выполняться шифрование и дешифрование данных, благодаря которому секретность обмена данными обеспечивается сразу для всех прикладных сервисов. Примером такого протокола является протокол Secure Socket Layer (SSL), который обеспечивает секретный обмен сообщениями для протоколов прикладного уровня стека TCP/IP.

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

Существует очень большое разнообразие сервисов прикладного уровня.


Приведем в качестве примеров протоколов прикладного уровня хотя бы несколько наиболее распространенных реализаций файловых сервисов: NCP в операционной системе Novell NetWare, SMB в Microsoft Windows NT, NFS, FTP и TFTP, входящие в стек TCP/IP.

Сетезависимые протоколы и протоколы, ориентированные на приложения

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

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

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

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

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

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

Семейство маршрутизаторов компании Bay Networks/Wellfleet

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

Модели Access Node (AN) и Access Node Hub (ANH) представляют собой недорогое решение для небольших удаленных офисов, имеющих локальные сети Ethernet или Token Ring и нуждающихся в связи с корпоративной магистральной сетью. Модель AN может поддерживать как Ethernet, так и Token Ring, в то время как модель ANH предназначена для соединения только сетей Ethernet.

Access Stack Node (ASN) - это первый в промышленности стековый маршрутизатор, с помощью которого можно строить легко расширяемые сети, включающие сегменты Ethernet, Token Ring и FDDI, связанные с центральной сетью через глобальные связи. По мере роста сети в стек можно добавлять дополнительные устройства ASN (до 4-х), обеспечивая до 24 сетевых интерфейсов в стеке с общей скоростью продвижения пакетов до 200000 пакетов в секунду.

Модель Backbone Link Node (BLN) предназначена для крупных сетей за счет поддержки до 16 сетевых интерфейсов (Ethernet, Token Ring, FDDI, WAN) с общей производительностью продвижения пакетов 250000 пакетов в секунду.

Разработанный для наиболее ответственных применений, маршрутизатор старшей модели Backbone Concentrator Node (BCN) поддерживает до 52 сетевых интерфейсов с общей производительностью до 760000 пакетов в секунду.

Почти все модели маршрутизаторов (кроме AN и ANH) основаны на симметричной мультипроцессорной архитектуре Wellfleet, которая иллюстрируется рисунком 3.4.

Рис. 3.4. Симметричная мультипроцессорная структура маршрутизаторов Wellfleet

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

Модуль связи (Link module) является интерфейсным модулем, поддерживающим специфический стандартный сетевой интерфейс локальных или глобальных связей (Ethernet, FDDI, RS-232, T1 и т.д.). Каждый модуль связи непосредственно соединен с обслуживающим его процессорным модулем через специальный интерфейс Processor-Link.
Модуль связи выполняет три основные функции:

физический интерфейс к специфической сети (Ethernet, Token Ring, ...),

передачу пакета через интерфейс Processor-Link в процессорный модуль,

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

Процессорный модуль FRE (Fast Routing Engine) состоит из центрального процессора Motorola MC68040 33MHz, локальной памяти, глобальной памяти (общим объемом 8 Мб), процессора прямого доступа к памяти (DMA) и интерфейса с модулем связи (рисунок 3.5).

Рис. 3.5. Структура процессорного модуля

(интеллектуальный интерфейс модуля связи с процессорным модулем)

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

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

Глобальная память представляет собой буфер, который хранит пакеты, передаваемые от модуля связи данного процессорного модуля или от другого процессорного модуля. Память называется глобальной, так как она видна из любого процессорного модуля и доступна ему. Пакеты передаются в глобальную память с помощью процессора прямого доступа к памяти (DMA processor).

Процессорные модули поддерживают все основные сетевые протоколы: TCP/IP, OSI, DECnet Phase IV, Novell IPX, Banyan VINES, AppleTalk Phase 2, IBM SNA, X.25, Frame Relay, SMDS, ATM.

Высокоскоростная шина межпроцессорных соединений PPX (Parallel Packet Express) обеспечивает скорость передачи данных 1 Гб/с. Используется 4 независимых, избыточных шины 256 Мб/с, нагрузка между которыми может балансироваться динамически. Шина обеспечивает высокую производительность и одновременно высокую отказоустойчивость.


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

Программное обеспечение маршрутизаторов Wellfleet имеет распределенную архитектуру (рисунок 3.7).



Рис. 3.6. Связь процессорных модулей по шине PPX

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

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



Рис. 3.7. Распределенная архитектура программных средств



Рис. 3.8. Многоуровневая структура программных средств

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

Программное обеспечение маршрутизаторов Wellfleet организовано в соответствии с многоуровневым принципом, как и любая современная операционная система (рисунок 3.8), что позволяет ее легко модифицировать.

Интерфейсные модули (модули связи)

Существует 5 типов интерфейсных модулей связи:

Ethernet Intelligent Link Interface - 2/4 порта Ethernet с возможностью высокоскоростной фильтрации (29000 п/с), поддержкой алгоритмов Transparent Bridging и Spanning Tree, конфигурирование с помощью системы Optivity;



Token Ring Intelligent Link Interface - 2/4 порта Token Ring 4/16 Мб/с;

FDDI Intelligent Link Interface - 2 порта, поддерживающие два соединения SAS или одно соединение DAS, фильтрация со скоростью до 500000 п/с;

ATM Intelligent Link Interface - обеспечивает маршрутизаторы BLN и BCN возможностями соединения локальных сетей через частные или общественные сети ATM. Предоставляет мультипротокольные возможности для ATM-рабочих групп. Поддерживает спецификации RFC-1483 и RFC-1577, определяющие работу протокола IP через сети ATM. Обеспечивает интерфейс SONET/SDH со скоростью 155 Мб/с, поддерживая до 1024 виртуальных каналов SVC. Поддерживает сервис для уровней AAL 3/4 и AAL 5. Для других маршрутизаторов интерфейс с сетями ATM обеспечивается модулями глобальных связей;

Serial Intelligent Link Interface - обеспечивают глобальные связи для всех основных видов глобальных интерфейсов и протоколов: V.35, RS-449/422, RS-232, X.21 со скоростью до 6 Мб/с, HSSI для связи с линиями T3/E3 со скоростью до 52 Мб/с; поддерживаются протоколы Frame Relay, SMDS и ATM, T1/E1 со скоростью до 2.048 Мб/с, ISDN BRI и PRI.

Шлюзы как средство трансляции сетевых протоколов

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

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

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

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

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

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

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

Согласование типа и размера кадров в составных сетях

Ниже приведены различные форматы кадров технологии Ethernet.

Кадр стандарта 802.3 (или кадр Novell 802.2);

Кадр Novell 802.3 (или кадр Raw 802.3);

Кадр Ethernet DIX (или кадр Ethernet II);

Кадр Ethernet SNAP.

Кадр стандарта 802.3 содержит восемь полей, определяемых следующим образом:

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

Начальный ограничитель кадра состоит из одного байта с набором битов 10101011. Появление этой комбинации является указанием на предстоящий прием кадра.

Адрес получателя - может быть длиной 2 или 6 байтов (MAC-адрес получателя). Первый бит адреса получателя - это признак того, является адрес индивидуальным или групповым: если 0, то адрес указывает на определенную станцию, если 1, то это групповой адрес нескольких (возможно всех) станций сети. При широковещательной адресации все биты поля адреса устанавливаются в 1. Общепринятым является использование 6-байтовых адресов.

Адрес отправителя - 2-х или 6-ти байтовое поле, содержащее адрес станции отправителя. Первый бит - всегда имеет значение 0.

Двухбайтовое поле длины определяет длину поля данных в кадре.

Поле данных может содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется следующее поле - поле заполнения, чтобы дополнить кадр до минимально допустимой длины.

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

Поле контрольной суммы - 4 байта, содержащие значение, которое вычисляется по определенному алгоритму (полиному CRC-32).
После получения кадра рабочая станция выполняет собственное вычисление контрольной суммы для этого кадра, сравнивает полученное значение со значением поля контрольной суммы и, таким образом, определяет, не искажен ли полученный кадр.

Кадр 802.3 является кадром MAС-подуровня, и в соответствии со стандартом 802.2 в его поле данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра. Служебный заголовок кадра LLC имеет три поля: точка входа в сервис назначения (Destination Service Access Point, DSAP), точка входа в сервис источника (Source Service Access Point, SSAP) и поле управления. Первые два поля могут использоваться для характеризации протоколов верхнего уровня, данные которых представлены в поле данных кадра LLC. Поле управления используется для реализации процедуры установления соединения на канальном уровне, но оно редко используется в протоколах локальных сетей. Результирующий кадр MAC/LLC изображен в левой части рисунка 2.1. Так как кадр LLC имеет заголовок длиной 3 байта, то максимальный размер поля данных уменьшается до 1497 байт.

Рис. 2.1.

Справа на этом рисунке приведен кадр, который называют кадром Raw 802.3 (то есть "грубый" вариант 802.3) или же кадром Novell 802.3. Из рисунка видно, что это кадр MAC-подуровня стандарта 802.3, но без вложенного кадра подуровня LLC. Компания Novell долгое время не использовала служебные поля кадра LLC в своей операционной системе NetWare из-за отсутствия необходимости идентифицировать тип информации, вложенной в поле данных - там всегда находился пакет протокола IPX, долгое время бывшего единственным протоколом сетевого уровня в ОС NetWare.

Теперь, когда необходимость идентификации протокола верхнего уровня появилась, компания Novell стала использовать возможность инкапсуляции в кадр MAC-подуровня кадра LLC. Такой кадр компания обозначает теперь в своих операционных системах как кадр 802.2.

Кадр стандарта Ethernet DIX, называемый также кадром Ethernet II, отличается от кадра Raw 802.3 тем, что на месте поля длины в нем определено поле типа протокола (поле Type).


Это поле предназначено для тех же целей, что и поля DSAP и SSAP кадра LLC - для указания типа протокола верхнего уровня, вложившего свой пакет в поле данных этого кадра. Для кодирования типа протокола используются значения, превышающие значение максимальной длины поля данных, равное 1500, поэтому кадры Ethernet II и 802.3 легко различимы.

Еще одним популярным форматом кадра является кадр Ethernet SNAP (SNAP - SubNetwork Access Protocol, протокол доступа к подсетям). Кадр Ethernet SNAP определен в стандарте 802.2H и представляет собой расширение кадра 802.3 путем введения дополнительного поля идентификатора организации, которое может использоваться для ограничения доступа к сети компьютеров других организаций. Кроме этого, кадр Ethernet SNAP содержит поле типа протокола верхнего уровня, аналогичное полю Type кадра Ethernet II.

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

В сетях Token Ring и FDDI всегда используются кадры стандартного формата, поэтому в этих сетях не возникают проблемы, связанные с несовместимостью форматов кадров.

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

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

Не требуется устанавливать дополнительное программное обеспечение на рабочих станциях.

Сохраняется привычная среда пользователей и приложений, транслятор полностью прозрачен для них.

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

Недостатки согласования протоколов путем трансляции состоят в том, что:

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

Централизация обслуживания запросов к "чужой" сети снижает надежность. Однако можно предусмотреть резервирование - использовать несколько трансляторов.

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

Достоинства мультиплексирования по сравнению с трансляцией протоколов заключаются в следующем:

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

Более надежный способ - при отказе стека на одном из компьютеров доступ к ресурсам другой сети возможен посредством протоколов, установленных на других компьютерах.

Недостатки данного подхода:

Сложнее осуществляется администрирование и контроль доступа.

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

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

Стандартные стеки коммуникационных протоколов

Существует достаточно много стеков протоколов, широко применяемых в сетях. Это и стеки, являющиеся международными и национальными стандартами, и фирменные стеки, получившие распространение благодаря распространенности оборудования той или иной фирмы. Примерами популярных стеков протоколов могут служить: стек IPX/SPX фирмы Novell, стек TCP/IP, используемый в сети Internet и во многих сетях на основе операционной системы UNIX, стек OSI международной организации по стандартизации, стек DECnet корпорации Digital Equipment и некоторые другие.

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

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

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

Умение хорошо работать в среде той или иной операционной системы является важной характеристикой коммуникационного оборудования. Часто можно прочитать в рекламе сетевого адаптера или концентратора, что он разрабатывался специально для работы в сети NetWare или UNIX. Это означает, что разработчики аппаратуры оптимизировали ее характеристики применительно к тем протоколам, которые используются в этой сетевой операционной системе, или к данной версии их реализации, если эти протоколы используются в различных ОС.
Из-за особенностей реализации протоколов в различных ОС в качестве одной из характеристик коммуникационного оборудования используется его сертифицированность на возможность работы в среде данной ОС.

На нижних уровнях - физическом и канальном - практически во всех стеках используются одни и те же протоколы. Это хорошо стандартизованные протоколы Ethernet, Token Ring, FDDI и некоторые другие, которые позволяют использовать во всех сетях одну и ту же аппаратуру.

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

Стек OSI. Следует четко различать модель OSI и стек OSI. В то время как модель OSI является концептуальной схемой взаимодействия открытых систем, стек OSI представляет собой набор вполне конкретных спецификаций протоколов. В отличие от других стеков протоколов стек OSI полностью соответствует модели OSI, он включает спецификации протоколов для всех семи уровней взаимодействия, определенных в этой модели. На нижних уровнях OSI поддерживает Ethernet, Token Ring, FDDI, а также такие протоколы как LLC, X.25 и ISDN. Сервисы сетевого, транспортного и сеансового уровней этого стека пока мало распространены. Наиболее популярными протоколами стека OSI являются протоколы, реализующие высокоуровневые сервисы по передаче файлов, эмуляции терминала, ведению каталогов имен и по организации электронной почты. Хотя в стеке OSI предусматривается еще ряд дополнительных высокоуровневых сервисов, многие из них еще не реализованы или реализованы частично.

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



Стек OSI - международный, независимый от производителей, стандарт. Его поддерживает правительство США в своей программе GOSIP, в соответствии с которой все компьютерные сети, устанавливаемые в правительственных учреждениях США после 1990 года, должны или непосредственно поддерживать стек OSI, или обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы. Большинство организаций пока только планируют переход к стеку OSI, и очень немногие приступили к созданию пилотных проектов. Из тех, кто работает в этом направлении, можно назвать Военно-морское ведомство США и сеть NFSNET. Одним из крупнейших производителей, поддерживающих OSI, является компания AT&T, ее сеть Stargroup полностью базируется на этом стеке.

Стек TCP/IP. Стек был разработан по инициативе Министерства обороны США (Department of Defense, DoD) более 20 лет назад для связи экспериментальной сети

ARPAnet с другими сетями как набор общих протоколов для разнородной вычислительной среды. Большой вклад в развитие стека TCP/IP, который получил свое название по популярным транспортным протоколам IP и TCP, внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Популярность этой операционной системы привела к широкому распространению протоколов TCP, IP и других протоколов стека. Этот стек используется для связи компьютеров всемирной информационной сети Internet. Организация Internet Engineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.

Стек TCP/IP на нижнем уровне поддерживает все популярные стандарты физического и канального уровня: для локальных сетей это Ethernet, Token Ring, FDDI, для глобальных - протоколы работы на аналоговых коммутируемых и выделенных линиях SLIP/PPP, протоколы территориальных сетей X.25 и ISDN.

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


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

За долгие годы использования в сетях различных стран и организаций стек TCP/IP вобрал в себя большое количество протоколов прикладного уровня. К ним относятся такие популярные протоколы как протокол пересылки файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы доступа к удаленной информации, такие как Mosaic, и многие другие.

Все говорит о том, что стек TCP/IP станет наиболее распространенным в ближайшем будущем. Если в настоящее время он распространен в основном в UNIX-сетях, то реализация его в последних версиях сетевых операционных систем для персональных компьютеров (Windows 95, Windows NT, NetWare 4.1) приведет к еще большему его распространению. По данным IDC в 1994 году стек TCP/IP использовался в 9.5% настольных систем, 2.5% серверов локальных сетей, 35.1% систем средних среднего класса и в 17.3% сетей на основе мейнфреймов. По прогнозам IDC в 1998 году эти цифры существенно изменяться и будут равны 50.3%, 18.2%, 59% и 40.8% соответственно.

Стек IPX/SPX. Этот стек является оригинальным стеком протоколов фирмы Novell, разработанным для сетевой операционной системы NetWare еще в начале 80-х годов. Протоколы сетевого и сеансового уровня Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали название стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, распространенных в гораздо меньшей степени, чем стек IPX/SPX. Популярность стека IPX/SPX непосредственно связана с операционной системой Novell NetWare, которая, несмотря на то, что ее популярность несколько снизилась в последнее время, все еще сохраняет мировое лидерство по числу установок .

Многие особенности стека IPX/SPX обусловлены ориентацией ранних версий ОС NetWare (до версии 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами.


Понятно, что для таких компьютеров Novell нужны были протоколы, на реализацию которых требовалось бы минимальное количество оперативной памяти (ограниченной в IBM-совместимых компьютерах под управлением MS-DOS 640 Кбайтами) и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате протоколы стека IPX/SPX до недавнего времени хорошо работали в локальных сетях и не очень - в больших корпоративных сетях, так как они слишком перегружали медленные глобальные связи широковещательными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Это обстоятельство, а также тот факт, что стек IPX/SPX является собственностью фирмы Novell, и на его реализацию нужно получать у нее лицензию, долгое время ограничивали распространенность его только сетями NetWare. Однако с момента выпуска версии NetWare 4.0 Novell внесла и продолжает вносить в свои протоколы серьезные изменения, направленные на приспособление их для работы в корпоративных сетях. Сейчас стек IPX/SPX реализован не только в NetWare, но и в нескольких других популярных сетевых ОС, например, SCO UNIX, Sun Solaris, Microsoft Windows NT.

Стек NetBIOS/SMB. Этот стек широко используется в продуктах компаний IBM и Microsoft. На физическом и канальном уровнях этого стека используются все наиболее распространенные протоколы Ethernet, Token Ring, FDDI и другие. На верхних уровнях работают протоколы NetBEUI и SMB.

Протокол NetBIOS (Network Basic Input/Output System) появился в 1984 году как сетевое расширение стандартных функций базовой системы ввода/вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM. В дальнейшем этот протокол был заменен так называемым протоколом расширенного пользовательского интерфейса NetBEUI - NetBIOS Extended User Interface. Для обеспечения совместимости приложений в качестве интерфейса к протоколу NetBEUI был сохранен интерфейс NetBIOS. Протокол NetBEUI разрабатывался как эффективный протокол, потребляющий немного ресурсов, для использования в сетях, насчитывающих не более 200 рабочих станций.Этот протокол содержит много полезных сетевых функций, которые можно отнести к сетевому, транспортному и сеансовому уровням модели OSI, однако с его помощью невозможна маршрутизация пакетов. Это ограничивает применение протокола NetBEUI локальными сетями, не разделенными на подсети, и делает невозможным его использование в составных сетях. Некоторые ограничения NetBEUI снимаются реализацией этого протокола NBF (NetBEUI Frame), которая включена в операционную систему Microsoft Windows NT.

Протокол блоков сообщений сервера SMB (Server Message Block) выполняет функции сеансового, представительного и прикладного уровней. SMB реализует файловый сервис, сервис печати и сервис передачи сообщений между приложениями.

|

Стратегии межсетевого взаимодействия

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

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

Несколько другая проблема, называемая interoperability, возникает при объединении сетей, использующих разные протоколы более высоких уровней. Как сделать, например, возможным для клиентов сети Novell NetWare доступ к файловому сервису Windows NT или работу с сервисом telnet ОС Unix?

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

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

Равным образом проблема межсетевого взаимодействия может возникнуть в однородной сети Ethernet, в которой установлено несколько сетевых ОС. В этом случае, все компьютеры и все приложения используют для транспортировки сообщений один и тот же набор протоколов, но взаимодействие клиентских и серверных частей сетевых сервисов осуществляется по разным протоколам. Здесь компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы верхних уровней, например, сеть Windows NT, сеть NetWare. Конечно, эти сети могут спокойно сосуществовать, не мешая друг другу и мирно пользуясь общим транспортом. Однако, если потребуется обеспечить доступ к данным файл-сервера NetWare для клиентов Windows NT, администратор сети столкнется в необходимостью согласования сетевых сервисов.

Существует три основных подхода к согласованию разных стеков протоколов:

трансляция;

мультиплексирование;

инкапсуляция.

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

Транслирующие мосты и коммутаторы выполняют преобразование из одного протокола канального уровня в другой, например, 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.

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

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

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

доступность станций другой сети.

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

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

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

Трансляция протоколов

Трансляция обеспечивает согласование двух протоколов путем преобразования (трансля-

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

В зависимости от типа транслируемых протоколов процедура трансляции может иметь разную степень сложности. Так, преобразование протокола Ethernet в протокол Token Ring сводится к нескольким несложным действиям, главным образом благодаря тому, что в обоих протоколах используется единая адресация узлов. А вот трансляция протоколов сетевого уровня IP и IPX представляет собой гораздо более сложный, интеллектуальный процесс, включающий не только преобразование форматов сообщений, но и отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах.

Рис. 1.1. Пример трансляции протоколов

Следует отметить, что сложность трансляции зависит не от того, насколько высокому уровню соответствуют транслируемые протоколы, а от того, насколько сильно они различаются. Так, например, весьма сложной представляется трансляция протоколов канального уровня ATM-Ethernet, именно поэтому для их согласования используется не трансляция, а другие подходы.

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

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

Управление неоднородными сетями

Мощные многофункциональные системы управления, такие как HP OpenView или Sun NetManager, существуют и совершенствуются уже много лет, однако для управления неоднородными сетями они пока оснащены явно недостаточно. Система OpenView компании Hewlett-Packard хорошо справляется с управлением сетями, построенными в основном на оборудовании компании Hewlett-Packard, система Spectrum компании Cabletron демонстрирует впечатляющие функциональные возможности при управлении сетями, построенными на оборудовании именно этой компании и т.д.

Такое положение сложилось в силу нескольких причин:

Наличие наряду со стандартными базами управляющей информации, типа MIB-I, MIB-II или RMON MIB, более тысячи фирменных баз MIB со своей структурой объектов, отражающей некоторые нестандартные особенности оборудования.

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

Существование нескольких протоколов управления: протокол SNMP широко используется в оборудовании локальных сетей, протокол CMIP более популярен среди разработчиков оборудования для территориальных сетей, а для управления серверами и рабочими станциями разработан протокол DMI со своим форматом управляющей информации MIF.

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

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей.
Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании Bay Networks, CiscoWorks компании Cisco Systems, Transcend компании 3Com. Система Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании Bay Networks, полностью используя все их возможности и свойства. Оборудование других производителей поддерживается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNet Manager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими системами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью.

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

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как, например, Oracle, Ingres или Informix.


Использование универсальных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

В следующей таблице представлены наиболее важные характеристики наиболее популярных платформ управления:

OpenView Network Node Manager 4.1 (Hewlett-Packard)

Spectrum Enterprise Manager (Cabletron Systems)

NetView for AIX SNMP Manager (IBM)

Solstice Enterprise Manager (SunSoft)

Автообнаружение

Ограничение по числу промежуточных маршрутизаторов

-

-

+

+

Определение имени хоста по его адресу через сервер DNS

+

+

+

+

Возможность модификации присвоенного имени хоста

+

-

+

+

Распознавание сетевых топологий

Любые сети, работающие по TCP/IP

Ethernet, Token Ring, FDDI, ATM, распределенные сети, сети с коммутацией

Распознавание по интерфейсам устройств

Ethernet, Token Ring, FDDI, распределенные сети

Максимальное рекомендуемое число обслуживаемых узлов

200 - 2000, наибольшее изв. - 35000

Программных ограничений не существует

Программных ограничений не существует

10000 - 50000

Поддержка баз данных

Ingres, Oracle

файлы

Собств., Oracle, Sybase, ...

Informix, Oracle, Sybase

Распределенное управление

Один сервер/много клиентов

Число клиентов

до 15

Нет программного ограничения

Протестировано более 30

Нет программного огранич.

Клиент использует X-Window

ь

-

-

+

Система с GUI запускается на клиенте

+

+

+

+

Собственная карта сети у клиента

+

+

+

-

Задание доступных для просмотра объектов сети

с помощью дополнительного продукта Operations Center (HP)

+

+

-

Много серверов/много клиентов

Текущее состояние

+/-

+/+

+/-

+/+

Планируется

+/+

+/+

+/+

+/+

Число приложений третьих фирм

220

180

> 200

400

Число поддерживаемых MIB третьих фирм

218

> 1000

193

Нет данных

Поддержка протокола SNMP:

Через IP

+

+

+

+

Через IPX

+

-

-

-

Поддержка MIB, утвержденных IETF

Большинство, но нет RMON

Все

20

MIB-II

Поддержка протокола CMIP

Дополнительно оплачиваемый продукт - OpenView HP Distributed Management Platform

Дополнительно оплачиваемый продукт

+

+

Взаимодействие с мэйнфреймами

При помощи приложений третьих фирм

По SNA через BlueVision

Может обращаться к NetView на мэйнфрейме

+

Поддержка ОС

HP UX, Sun OS, Solaris

IBM AIX, Sun OS, HP UX, SGI IRIX, Windows NT

AIX, OSF/1, Windows NT

Solaris SPARC

---

---