Категории услуг протокола АТМ и управление трафиком
Для поддержания требуемого качества обслуживания различных виртуальных соединений и рационального использования ресурсов в сети на уровне протокола АТМ реализовано несколько служб, предоставляющих услуги различных категорий (service categories) по обслуживанию пользовательского трафика. Эти службы являются внутренними службами сети АТМ, они предназначены для поддержания пользовательского трафика различных классов совместно с протоколами AAL. Но в отличие от протоколов AAL, которые работают в конечных узлах сети, данные службы распределены по всем коммутаторам сети. Услуги этих служб разбиты на категории, которые в общем соответствуют классам трафика, поступающим на вход уровня AAL конечного узла. Услуги уровня АТМ заказываются конечным узлом через интерфейс UNI с помощью протокола Q.2931 при установлении виртуального соединения. Как и при обращении к уровню AAL, при заказе услуги необходимо указать категорию услуги, а также параметры трафика и параметры QoS. Эти параметры берутся из аналогичных параметров уровня AAL или же определяются по умолчанию в зависимости от категории услуги.
Всего на уровне протокола АТМ определено пять категорий услуг, которые поддерживаются одноименными службами:
- CBR - услуги для трафика с постоянной битовой скоростью;
- rtVBR - услуги для трафика с переменной битовой скоростью, требующего соблюдения средней скорости передачи данных и синхронизации источника и приемника;
- nrtVBR - услуги для трафика с переменной битовой скоростью, требующего соблюдения средней скорости передачи данных и не требующего синхронизации источника и приемника;
- ABR - услуги для трафика с переменной битовой скоростью, требующего соблюдения некоторой минимальной скорости передачи данных и не требующего синхронизации источника и приемника;
- UBR - услуги для трафика, не предъявляющего требований к скорости передачи данных и синхронизации источника и приемника.
Названия большинства категорий услуг совпадают с названием типов пользовательского трафика, для обслуживания которого они разработаны, но необходимо понимать, что сами службы уровня АТМ и их услуги - это внутренние механизмы сети АТМ, которые экранируются от приложения уровнем AAL.
Услуги категории CBR предназначены для поддержания трафика синхронных приложений - голосового, эмуляции цифровых выделенных каналов и т. п. Когда приложение устанавливает соединение категории CBR, оно заказывает пиковую скорость трафика ячеек PCR, являющуюся максимальной скоростью, которую может поддерживать соединение без риска потерять ячейку, а также параметры QoS: величины максимальной задержки ячеек CTD, вариации задержки ячеек CDV и максимальной доли потерянных ячеек CLR.
Затем данные передаются по этому соединению с запрошенной скоростью - не с большей и, в большинстве случаев, не меньшей, хотя уменьшение скорости приложением возможно, например, при передаче компрессированного голоса с помощью услуги категории CBR. Любые ячейки, передаваемые станцией с большей скоростью, контролируются первым коммутатором сети и помечаются признаком CLP=1. При перегрузках сети они могут просто отбрасываться сетью. Ячейки, которые запаздывают и не укладываются в интервал, оговоренный параметром вариации задержки CDV, также считаются мало значащими для приложения и отмечаются признаком низкого приоритета CLP=1.
Для соединений CBR нет ограничений на некоторую дискретность заказа скорости PCR, как, например, в каналах Т1/Е1, где скорость должна быть кратна 64 Кбит/с.
По сравнению со службой CBR, службы VBR требуют более сложной процедуры заказа соединения между сетью и приложением. В дополнение к пиковой скорости PCR приложение VBR заказывает еще и два других параметра: длительно поддерживаемую скорость - SCR, которая представляет собой среднюю скорость передачи данных, разрешенную приложению, а также максимальный размер пульсации - MBS, Максимальный размер пульсации измеряется в количестве ячеек АТМ. Пользователь может превышать скорость вплоть до величины PCR, но только на короткие периоды времени, в течение которых передается объем данных, не превышающий MBS. Этот период времени называется Burst Tolerance, ВТ - терпимость к пульсации. Сеть вычисляет этот период как производный от трех заданных значений PCR, SCR и MBS.
Если скорость PCR наблюдается в течение периода времени, большего чем ВТ, то ячейки помечаются как нарушители - устанавливается признак CLP=1.
Для услуг категории rtVBR задаются и контролируются те же параметры QoS, что и для услуг категории CBR, а услуги категории nrtVBR ограничиваются поддержанием параметров трафика. Сеть также поддерживает для обеих категорий услуг VBR определенный максимальный уровень доли потерянных ячеек CLR, который либо задается явно при установлении соединения, либо назначается по умолчанию в зависимости от класса трафика.
Для контроля параметров трафика и QoS в технологии АТМ применяется так называемый обобщенный алгоритм контроля скорости ячеек - Generic Cell Rate Algorithm, который может проверять соблюдение пользователем и сетью таких параметров, как PCR, CDV, SCR, ВТ, CTD и CDV. Он работает по модифицированному алгоритму «дырявого ведра», применяемому в технологии frame relay.
Для многих приложений, которые могут быть чрезвычайно «взрывными» в отношении интенсивности трафика, невозможно точно предсказать параметры трафика, оговариваемые при установлении соединения. Например, обработка транзакций или трафик двух взаимодействующих локальных сетей непредсказуемы по своей природе - изменения интенсивности трафика слишком велики, чтобы заключить с сетью какое-либо разумное соглашение.
В отличие от CBR и обеих служб VBR, служба UBR не поддерживает ни параметры трафика, ни параметры качества обслуживания. Служба UBR предлагает только доставку «по возможности» без каких-либо гарантий. Разработанная специально для обеспечения возможности превышения полосы пропускания, служба UBR представляет собой частичное решение для тех непредсказуемых «взрывных» приложений, которые не готовы согласиться с фиксацией параметров трафика.
Главными недостатками услуг UBR являются отсутствие управления потоком данных и неспособность принимать во внимание другие типы трафика. Несмотря на перегрузку сети, соединения UBR будут продолжать передачу данных. Коммутаторы сети могут буферизовать некоторые ячейки поступающего трафика, но в некоторый момент буферы переполняются, и ячейки теряются. А так как для соединений UBR не оговаривается никаких параметров трафика и QoS, то их ячейки отбрасываются в первую очередь.
Служба ABR подобно службе UBR предоставляет возможность превышения полосы пропускания, но благодаря технике управления трафиком при перегрузке сети она дает некоторые гарантии сохранности ячеек. ABR - это первый тип служб уровня АТМ, который действительно обеспечивает надежный транспорт для пульсирующего трафика за счет того, что может находить неиспользуемые интервалы в общем трафике сети и заполнять их своими ячейками, если другим категориям служб эти интервалы не нужны.
Как и в службах CBR и VBR, при установлении соединения категории ABR оговаривается значение пиковой скорости PCR. Однако соглашение о пределах изменения задержки передачи ячеек или о параметрах пульсации не заключается.
Вместо этого сеть и конечный узел заключают соглашение о требуемой минимальной скорости передачи MCR. Это гарантирует приложению, работающему в конечном узле, небольшую пропускную способность, обычно минимально необходимую для того, чтобы приложение работало. Конечный узел соглашается не передавать данные со скоростью, выше пиковой, то есть PCR, а сеть соглашается всегда обеспечивать минимальную скорость передачи ячеек MCR.
Если при установлении соединения ABR не задаются значения максимальной и минимальной скорости, то по умолчанию считается, что PCR совпадает со скоростью линии доступа станции к сети, а MCR считается равной нулю.
Трафик соединения категории ABR получает гарантированное качество услуг в отношении доли потерянных ячеек и пропускной способности. Что касается задержек передачи ячеек, то хотя сеть и старается свести их к минимуму, но гарантий по этому параметру не дает. Следовательно, служба ABR не предназначена для приложений реального времени, а предназначена для приложений, в которых поток данных не очень чувствителен к задержкам в передаче.
При передаче трафика CBR, VBR и UBR явное управление перегрузками в сети отсутствует. Вместо этого используется механизм отбрасывания ячеек-нарушителей, а узлы, пользующиеся услугами CBR и VBR, стараются не нарушать условия контракта под угрозой потери ячеек, поэтому они обычно не пользуются дополнительной пропускной способностью, даже если она в данный момент доступна в сети.
Служба ABR позволяет воспользоваться резервами пропускной способности сети, так как сообщает конечному узлу о наличии в данный момент избыточной пропускной способности с помощью механизма обратной связи. Этот же механизм может помочь службе ABR снизить скорость передачи данных конечным узлом в сеть (вплоть до минимального значения MCR), если сеть испытывает перегрузку.
Узел, пользующийся услугами ABR, должен периодически посылать в сеть наряду с ячейками данных специальные служебные ячейки управления ресурсами - Resource Management, RM. Ячейки RM, которые узел отправляет вдоль потока данных, называются прямыми ячейками RM - Forward Recource Management (FRM), а ячейки, которые идут в обратном по отношению к потоку данных направлении, называются обратными ячейками RM - Backward Recource Management (BRM).
Существует несколько петель обратной связи. Самая простая петля обратной связи - между конечными станциями. При ее наличии коммутатор сети извещает конечную станцию о перегрузке с помощью специального флага в поле прямого управления перегрузками (флаг EFCI) ячейки данных, переносимой протоколом АТМ. Затем конечная станция посылает через сеть сообщение, содержащееся в специальной ячейке управления BRM исходной станции, говоря ей о необходимости уменьшить скорость посылки ячеек в сеть.
В этом способе конечная станция несет основную ответственность за управление потоком, а коммутаторы играют пассивную роль в петле обратной связи, только уведомляя станцию - отправитель о перегрузке.
Такой простой способ имеет несколько очевидных недостатков. Конечная станция не узнает из сообщения BRM, на какую величину нужно уменьшить скорость передачи данных в сеть. Поэтому она просто понизит скорость до минимальной величины MCR, хотя, возможно, это и не обязательно. Кроме того, при большой протяженности сети коммутаторы должны продолжать буферизовать данные все время, пока уведомление о перегрузке будет путешествовать по сети, а для глобальных сетей это время может быть достаточно большим, и буферы могут переполниться, так что требуемый эффект достигнут не будет.
Разработаны и более сложные схемы управления потоком, в которых коммутаторы играют более активную роль, а узел-отправитель узнает более точно о возможной в данный момент скорости отправки данных в сеть.
В первой схеме узел-источник посылает в ячейке FRM явное значение скорости передачи данных в сеть, которую он хотел бы поддерживать в данное время. Каждый коммутатор, через который проходит по виртуальному пути это сообщение, может уменьшить запрашиваемую скорость до некоторой величины, которую он может поддерживать в соответствии с имеющимися у него свободными ресурсами (или оставить запрашиваемую скорость без изменения). Узел назначения, получив ячейку FRM, превращает ее в ячейку BRM и отправляет в обратном направлении, причем он тоже может уменьшить запрашиваемую скорость. Получив ответ в ячейке BRM, узел-источник точно узнает, какая скорость отправки ячеек в сеть для него в данный момент доступна.
Во второй схеме каждый коммутатор сети может работать как узел-источник и узел назначения. Как узел-источник он может сам генерировать ячейки FRM и отправлять их по имеющимся виртуальным каналам. Как узел назначения он может отправлять на основе получаемых ячеек FRM ячейки BRM в обратном направлении. Такая схема является более быстродействующей и полезной в протяженных территориальных сетях.
Как видно из описания, служба ABR предназначена не только для прямого поддержания требований к обслуживанию конкретного виртуального соединения, но и для более рационального распределения ресурсов сети между ее абонентами, что в конечном итоге также приводит к повышению качества обслуживания всех абонентов сети.
Коммутаторы сети АТМ используют различные механизмы для поддержания требуемого качества услуг. Кроме описанных в стандартах ITU-T и АТМ Forum механизмов заключения соглашения на основе параметров трафика и параметров QoS, а затем отбрасывания ячеек, не удовлетворяющих условиям соглашения, практически все производители оборудования АТМ реализуют в своих коммутаторах несколько очередей ячеек, обслуживаемых с различными приоритетами.
Стратегия приоритетного обслуживания трафика основана на категориях услуг каждого виртуального соединения. До принятия спецификации ABR в большинстве коммутаторов АТМ была реализована простая одноуровневая схема обслуживания, которая давала трафику CBR первый приоритет, трафику VBR второй, а трафику UBR - третий. При такой схеме комбинация CBR и VBR может потенциально заморозить трафик, обслуживаемый другим классом служб. Такая схема не будет правильно работать с трафиком ABR, так как не обеспечит его требования к минимальной скорости передачи ячеек. Для обеспечения этого требования должна быть выделена некоторая гарантированная полоса пропускания.
Чтобы поддерживать службу ABR, коммутаторы АТМ должны реализовать двухуровневую схему обслуживания, которая бы удовлетворяла требованиям CBR, VBR и ABR. По этой схеме коммутатор предоставляет некоторую часть своей пропускной способности каждому классу служб. Трафик CBR получает часть пропускной способности, необходимую для поддержания пиковой скорости PCR, трафик VBR получает часть пропускной способности, необходимую для поддержания средней скорости SCR, a трафик ABR получает часть пропускной способности, достаточную для обеспечения требования минимальной скорости ячеек MCR. Это гарантирует, что каждое соединение может работать без потерь ячеек и не будет доставлять ячейки ABR за счет трафика CBR или VBR. На втором уровне этого алгоритма трафик CBR и VBR может забрать всю оставшуюся пропускную способность сети, если это необходимо, так как соединения ABR уже получили свою минимальную пропускную способность, которая им гарантировалась.
Передача трафика IP через сети АТМ Технология АТМ привлекает к себе общее внимание, так как претендует на роль всеобщего и очень гибкого транспорта, на основе которого строятся другие сети. И хотя технология АТМ может использоваться непосредственно для транспортировки сообщений протоколов прикладного уровня, пока она чаще переносит пакеты других протоколов канального и сетевого уровней (Ethernet, IP, IPX, frame relay, X.25), сосуществуя с ними, а не полностью заменяя. Поэтому протоколы и спецификации, которые определяют способы взаимодействия технологии АТМ с другими технологиями, очень важны для современных сетей. А так как протокол IP является на сегодня основным протоколом построения составных сетей, то стандарты работы IP через сети АТМ являются стандартами, определяющими взаимодействие двух наиболее популярных технологий сегодняшнего дня. Протокол Classical IP (RFC 1577) является первым (по времени появления) протоколом, определившим способ работы интерсети IP в том случае, когда одна из промежуточных сетей работает по технологии АТМ. Из-за классической концепции подсетей протокол и получил свое название - Classical. Одной из основных задач, решаемых протоколом Classical IP, является традиционная для IP-сетей задача - поиск локального адреса следующего маршрутизатора или конечного узла по его IP-адресу, то есть задача, возлагаемая в локальных сетях на протокол ARP. Поскольку сеть АТМ не поддерживает широковещательность, традиционный для локальных сетей способ широковещательных ARP-запросов здесь не работает. Технология АТМ, конечно, не единственная технология, в которой возникает такая проблема, - для обозначения таких технологий даже ввели специальный термин - «Нешироковещательные сети с множественным доступом» (Non-Broadcast networks with Multiple Access, NBMA). К сетям NBMA относятся, в частности, сети X.25 и frame relay. В общем случае для нешироковещательных сетей стандарты TCP/IP определяют только ручной способ построения ARP-таблиц, однако для технологии АТМ делается исключение - для нее разработана процедура автоматического отображения IP-адресов на локальные адреса. Такой особый подход к технологии АТМ объясняется следующими причинами. Сети NBMA (в том числе X.25 и frame relay) используются, как правило, как транзитные глобальные сети, к которым подключается ограниченное число маршрутизаторов, а для небольшого числа маршрутизаторов можно задать ARP-таблицу вручную. Технология АТМ отличается тем, что она применяется для построения не только глобальных, но и локальных сетей. В последнем случае размерность ARP-таблицы, которая должна содержать записи и о пограничных маршрутизаторах, и о множестве конечных узлов, может быть очень большой. К тому же, для крупной локальной сети характерно постоянное изменение состава узлов, а значит, часто возникает необходимость в корректировке таблиц. Все это делает ручной вариант решения задачи отображения адресов для сетей АТМ мало пригодным. В соответствии со спецификацией Classical IP одна сеть АТМ может быть представлена в виде нескольких IP-подсетей, так называемых логических подсетей (Logical IP Subnet, LIS) (рис. 6.33). Все узлы одной LIS имеют общий адрес сети. Как и в классической IP-сети, весь трафик между подсетями обязательно проходит через маршрутизатор, хотя и существует принципиальная возможность передавать его непосредственно через коммутаторы АТМ, на которых построена сеть АТМ. Маршрутизатор имеет интерфейсы во всех LIS, на которые разбита сеть АТМ. Рис. 6.33. Логические IP-подсети в сети АТМ ПРИМЕЧАНИЕ Подход спецификации Classical IP к подсетям напоминает технику виртуальных локальных сетей VLAN -там также вводятся ограничения на имеющуюся возможность связи через коммутаторы для узлов, принадлежащих разным VLAN. В отличие от классических подсетей маршрутизатор может быть подключен к сети АТМ одним физическим интерфейсом, которому присваивается несколько IP-адресов в соответствии с количеством LIS в сети. Решение о введении логических подсетей связано с необходимостью обеспечения традиционного разделения большой сети АТМ на независимые части, связность которых контролируется маршрутизаторами, как к этому привыкли сетевые интеграторы и администраторы. Решение имеет и очевидный недостаток — маршрутизатор должен быть достаточно производительным для передачи высокоскоростного трафика АТМ между логическими подсетями, в противном случае он станет узким местом сети. В связи с повышенными требованиями по производительности, предъявляемыми сетями АТМ к маршрутизаторам, многие ведущие производители разрабатывают или уже разработали модели маршрутизаторов с общей производительностью в несколько десятков миллионов пакетов в секунду. Все конечные узлы конфигурируются традиционным образом — для них задается их собственный IP-адрес, маска и IP-адрес маршрутизатора по умолчанию. Кроме того, задается еще один дополнительный параметр — адрес АТМ (или номер VPI/VCI для случая использования постоянного виртуального канала, то есть PVC) так называемого сервера ATMARP. Введение центрального сервера, который поддерживает общую базу данных для всех узлов сети, — это типичный прием для работы через нешироковещательную сеть. Этот прием используется во многих протоколах, в частности в протоколе LAN Emulation, рассматриваемом далее. Каждый узел использует адрес АТМ сервера ATMARP, чтобы выполнить обычный запрос ARP. Этот запрос имеет формат, очень близкий к формату запроса протокола ARP из стека TCP/IP. Длина аппаратного адреса в нем определена в 20 байт, что соответствует длине адреса АТМ. В каждой логической подсети имеется свой сервер ATMARP, так как узел может обращаться без посредничества маршрутизатора только к узлам своей подсети. Обычно роль сервера ATMARP выполняет маршрутизатор, имеющий интерфейсы во всех логических подсетях. При поступлении первого запроса ARP от конечного узла сервер сначала направляет ему встречный инверсный запрос ATMARP, чтобы выяснить IP- и АТМ- адреса этого узла. Этим способом выполняется регистрация каждого узла в сервере ATMARP, и сервер получает возможность автоматически строить базу данных соответствия IP- и АТМ - адресов. Затем сервер пытается выполнить запрос ATMARP узла путем просмотра своей базы. Если искомый узел уже зарегистрировался в ней и он принадлежит той же логической подсети, что и запрашивающий узел, то сервер отправляет в качестве ответа запрашиваемый адрес. В противном случае дается негативный ответ (такой тип ответа в обычном широковещательном варианте протокола ARP не предусматривается). Конечный узел, получив ответ ARP, узнает АТМ-адрес своего соседа по логической подсети и устанавливает с ним коммутируемое виртуальное соединение. Если же он запрашивал АТМ-адрес маршрутизатора по умолчанию, то он устанавливает с ним соединение, чтобы передать IP-пакет в другую сеть. Для передачи IP-пакетов через сеть АТМ спецификация Classical IP определяет использование протокола уровня адаптации AAL5, при этом спецификация ничего не говорит ни о параметрах трафика и качества обслуживания, ни о требуемой категории услуг CBR, rtVBR, nrtVBR или UBR. |
Сосуществование АТМ с традиционными технологиями локальных сетей Технология АТМ разрабатывалась сначала как «вещь в себе», без учета того факта, что в существующие технологии сделаны большие вложения и поэтому никто не станет сразу отказываться от установленного и работающего оборудования, даже если появляется новое, более совершенное. Это обстоятельство оказалось не столь важным для территориальных сетей, которые в случае необходимости могли предоставить свои оптоволоконные каналы для построения сетей АТМ. Учитывая, что стоимость высокоскоростных оптоволоконных каналов, проложенных на большие расстояния, часто превышает стоимость остального сетевого оборудования, переход на новую технологию АТМ, связанный с заменой коммутаторов, во многих случаях оказывался экономически оправданным. Для локальных сетей, в которых замена коммутаторов и сетевых адаптеров равнозначна созданию новой сети, переход на технологию АТМ мог быть вызван только весьма серьезными причинами. Гораздо привлекательнее полной замены существующей локальной сети новой сетью АТМ выглядела возможность «постепенного» внедрения технологии АТМ в существующую на предприятии сеть. При таком подходе фрагменты сети, работающие по новой технологии АТМ, могли бы мирно сосуществовать с другими частями сети, построенными на основе традиционных технологий, таких как Ethernet или FDDI, улучшая характеристики сети там, где это нужно, и оставляя сети рабочих групп или отделов в прежнем виде. Применение маршрутизаторов IP, реализующих протокол Classical IP, решает эту проблему, но такое решение не всегда устраивает предприятия, пользующиеся услугами локальных сетей, так как, во-первых, требуется обязательная поддержка протокола IP во всех узлах локальных сетей, а во-вторых, требуется установка некоторого количества маршрутизаторов, что также не всегда приемлемо. Отчетливо ощущалась необходимость способа согласования технологии АТМ с технологиями локальных сетей без привлечения сетевого уровня. В ответ на такую потребность АТМ Forum разработал спецификацию, называемую LAN emulation, LANE (то есть эмуляция локальных сетей), которая призвана обеспечить совместимость традиционных протоколов и оборудования локальных сетей с технологией АТМ. Эта спецификация обеспечивает совместную работу этих технологий на канальном уровне. При таком подходе коммутаторы АТМ работают в качестве высокоскоростных коммутаторов магистрали локальной сети, обеспечивая не только скорость, но и гибкость соединений коммутаторов АТМ между собой, поддерживающих произвольную топологию связей, а не только древовидные структуры. Спецификация LANE определяет способ преобразования кадров и адресов МАС - уровня традиционных технологий локальных сетей в ячейки и коммутируемые виртуальные соединения SVC технологии АТМ, а также способ обратного преобразования. Всю работу по преобразованию протоколов выполняют специальные компоненты, встраиваемые в обычные коммутаторы локальных сетей, поэтому ни коммутаторы АТМ, ни рабочие станции локальных сетей не замечают того, что они работают с чуждыми им технологиями. Такая прозрачность была одной из главных целей разработчиков спецификации LANE. Так как эта спецификация определяет только канальный уровень взаимодействия, то с помощью коммутаторов АТМ и компонентов эмуляции LAN можно образовать только виртуальные сети, называемые здесь эмулируемыми сетями, а для их соединения нужно использовать обычные маршрутизаторы. Рассмотрим основные идеи спецификации на примере сети, изображенной на рис. 6.34. Рис. 6.34. Принципы работы технологии LAN emulation Основными элементами, реализующими спецификацию, являются программные компоненты LEC (LAN Emulation Client) и LES (LAN Emulation Server). Клиент LEC выполняет роль пограничного элемента, работающего между сетью АТМ и станциями некоторой локальной сети. На каждую присоединенную к сети АТМ локальную сеть приходится один клиент LEC. Сервер LES ведет общую таблицу соответствия МАС - адресов станций локальных сетей и АТМ - адресов пограничных устройств с установленными на них компонентами LEC, к которым присоединены локальные сети, содержащие эти станции. Таким образом, для каждой присоединенной локальной сети сервер LES хранит один АТМ - адрес пограничного устройства LEC и несколько МАС - адресов станций, входящих в эту сеть. Клиентские части LEC динамически регистрируют в сервере LES МАС - адреса каждой станции, заново подключаемой к присоединенной локальной сети. Программные компоненты LEC и LES могут быть реализованы в любых устройствах — коммутаторах, маршрутизаторах или рабочих станциях АТМ. Когда элемент LEC хочет послать пакет через сеть АТМ станции другой локальной сети, также присоединенной к сети АТМ, он посылает запрос на установление соответствия между МАС - адресом и АТМ - адресом серверу LES. Сервер LES отвечает на запрос, указывая АТМ - адрес пограничного устройства LEC, к которому присоединена сеть, содержащая станцию назначения. Зная АТМ - адрес, устройство LEC исходной сети самостоятельно устанавливает виртуальное соединение SVC через сеть АТМ обычным способом, описанным в спецификации UNI. После установления связи кадры MAC локальной сети преобразуются в ячейки АТМ каждым элементом LEC с помощью стандартных функций сборки-разборки пакетов (функции SAR) стека АТМ. В спецификации LANE также определен сервер для эмуляции в сети АТМ широковещательных пакетов локальных сетей, а также пакетов с неизвестными адресами, так называемый сервер BUS (Broadcast and Unknown Server). Этот сервер распространяет такие пакеты во все пограничные коммутаторы, присоединившие свои сети к эмулируемой сети. В рассмотренном примере все пограничные коммутаторы образуют одну эмулируемую сеть. Если же необходимо образовать несколько эмулируемых сетей, не взаимодействующих прямо между собой, то для каждой такой сети необходимо активизировать собственные серверы LES и BUS, а в пограничных коммутаторах активизировать по одному элементу LEC для каждой эмулируемой сети. Для хранения информации о количестве активизированных эмулируемых сетей, а также АТМ - адресах соответствующих серверов LES и BUS вводится еще один сервер — сервер конфигурации LECS (LAN Emulation Configuration Server). Спецификация LANE существует сегодня в двух версиях. Вторая версия ликвидировала некоторые недостатки первой, связанные с отсутствием механизма резервирования серверов LES и BUS в нескольких коммутаторах, что необходимо для надежной работы крупной сети, а также добавила поддержку разных классов трафика. На основе технологии LANE работает новая спецификация АТМ Forum - Multiprotocol Over АТМ, МРОА. Эта спецификация АТМ определяет эффективную передачу трафика сетевых протоколов - IP, IPX, DECnet и т. п. через сеть АТМ, По назначению она близка к спецификации Classical IP, однако решает гораздо больше задач. Технология МРОА позволяет пограничным коммутаторам 3-го уровня, поддерживающим какой-либо сетевой протокол, но не строящим таблицы маршрутизации, находить кратчайший путь через сеть АТМ. МРОА использует для этого серверный подход, аналогичный тому, что применен в LANE. Сервер МРОА регистрирует адреса (например, IP-адреса) сетей, обслуживаемых пограничными коммутаторами 3-го уровня, а затем по запросу предоставляет их клиентам МРОА, встроенным в эти коммутаторы. С помощью технологии МРОА маршрутизаторы или коммутаторы 3-го уровня могут объединять эмулируемые сети, образованные на основе спецификации LANE. |
Использование технологии АТМ Технология АТМ расширяет свое присутствие в локальных и глобальных сетях не очень быстро, но неуклонно. В последнее время наблюдается устойчивый ежегодный прирост числа сетей, выполненных по этой технологии, в 20-30 %. В локальных сетях технология АТМ применяется обычно на магистралях, где хорошо проявляются такие ее качества, как масштабируемая скорость (выпускаемые сегодня корпоративные коммутаторы АТМ поддерживают на своих портах скорости 155 и 622 Мбит/с), качество обслуживания (для этого нужны приложения, которые умеют запрашивать нужный класс обслуживания), петле-видные связи (которые позволяют повысить пропускную способность и обеспечить резервирование каналов связи). Петлевидные связи поддерживаются в силу того, что АТМ - это технология с маршрутизацией пакетов, запрашивающих установление соединений, а значит, таблица маршрутизации может эти связи учесть - либо за счет ручного труда администратора, либо за счет протокола маршрутизации PNNL Основной соперник технологии АТМ в локальных сетях - технология Gigabit Ethernet. Она превосходит АТМ в скорости передачи данных - 1000 Мбит/с по сравнению с 622 Мбит/с, а также в затратах на единицу скорости. Там, где коммутаторы АТМ используются только как высокоскоростные устройства, а возможности поддержки разных типов трафика игнорируются, технологию АТМ, очевидно, заменит технология Gigabit Ethernet. Там же, где качество обслуживания действительно важно (видеоконференции, трансляция телевизионных передач и т. п.), технология АТМ останется. Для объединения настольных компьютеров технология АТМ, вероятно, еще долго не будет использоваться, так как здесь очень серьезную конкуренцию ей составляет технология Fast Ethernet. В глобальных сетях АТМ применяется там, где сеть frame relay не справляется с большими объемами трафика, и там, где нужно обеспечить низкий уровень задержек, необходимый для передачи информации реального времени. Сегодня основной потребитель территориальных коммутаторов АТМ - это Internet. Коммутаторы АТМ используются как гибкая среда коммутации виртуальных каналов между IP-маршрутизаторами, которые передают свой трафик в ячейках АТМ. Сети АТМ оказались более выгодной средой соединения IP-маршрутизаторов, чем выделенные каналы SDH, так как виртуальный канал АТМ может динамически перераспределять свою пропускную способность между пульсирующим трафиком клиентов IP-сетей. Примером магистральной сети АТМ крупного поставщика услуг может служить сеть компании UUNET - одного из ведущих поставщиков услуг Internet Северной Америки (рис. 6.35). Рис. 6.35. Магистральная сеть АТМ компании UUNET Сегодня по данным исследовательской компании Distributed Networking Associates около 85 % всего трафика, переносимого в мире сетями АТМ, составляет трафик компьютерных сетей (наибольшая доля приходится на трафик IP - 32 %). Хотя технология АТМ разрабатывалась для одновременной передачи данных компьютерных и телефонных сетей, передача голоса по каналам CBR для сетей АТМ составляет всего 5 % от общего трафика, а передача видеоинформации - 10 %. Телефонные компании пока предпочитают передавать свой трафик непосредственно по каналам SDH, не довольствуясь гарантиями качества обслуживания АТМ. Кроме того, технология АТМ пока имеет недостаточно стандартов для плавного включения в существующие телефонные сети, хотя работы в этом направлении идут. Что же касается совместимости АТМ с технологиями компьютерных сетей, то разработанные в этой области стандарты вполне работоспособны и удовлетворяют пользователей и сетевых интеграторов. |
Выводы
|
Дата добавления: 2016-01-03; просмотров: 825;