Маршрутизаторы обычно маршрутизируют трафик между подсетями. Чтобы маршрутизировать трафик между подсетями, которые не находятся поблизости одна от другой, маршрутизатор использует соединение, которое обеспечивает телефонная компания. Т.о. телефонная компания позволяет обеспечить установку соединения через каналы глобальной сети, также называемые выделенными каналами , выделенными линиями или каналами типа «точка-точка».
Телефонная компания так или иначе передает биты по внутренней сети телефонной компании, а конечный результат состоит в том, что для маршрутизаторов выделенный канал представляется эквивалентным кабелю с 4-мя проводами, проложенному между ними, по которому они могут посылать и получать данные в любой момент времени.
На каждой площадке установлен маршрутизатор, а также внутренний или внешний модуль CSU/DSC (устройство последовательного интерфейса маршрутизатора, которое кроме всего обеспечивает настройку последовательного канала на нужную скорость передачи). Модуль CSU/DSU конфигурируется со скоростью канала, кратной наименьшей скорости 64 Кбит/с.
Чтобы передавать трафик по каналу глобальной сети, используется протокол канального уровня. Наиболее популярные – HDLC (High-level Data Link Control) и PPP (Point to Point Protocol). Протоколы HDLC и PPP инкапсулируют пакет, помещая его между заголовком и концевиком. Они также имеют поле контрольной сумы в концевике. Поскольку любые данные, пересылаемы по выделенному каналу типа «точка-точка», предназначены для устройства, находящегося на другом конце – в заголовке (размером 1 байт) редко содержится информация об получателе, а есть лишь концевик с FCS (контрольной суммой для проверки на предмет ошибок). Поэтому отпадает необходимость использования протокола преобразования имён в IP-адреса (ARP). Независимо от того какой протокол используется, маршрутизатор инкапсулирует пакет во фрейм – или фрейм HDLC, или фрейм PPP.
Маршрутизаторы обычно маршрутизируют трафик между различными подсетями. Чтобы перенаправлять трафик между подсетями, которые не находятся в одном месте, маршрутизатор использует соединение, которое обеспечивает телефонная компания.
Технология Frame Relay позволяет избежать прокладки большого количества «выделенных линий» в случае необходимости объединения более 2-х площадок. Концепция службы аналогична концепции большого коммутатора Ethernet. Маршрутизаторы соединяются с сетью Frame Relay, используя выделенный канал, простирающийся от маршрутизатора до коммутатора Frame Relay, установленного в местной АТС. При пересылке фреймов Frame Relay по этому каналу доступа к ближайшему коммутатору, последний смотрит на заголовки фрейма и пересылает его, руководствуясь значением DLCI в заголовке. DLCI (Data-Link Connection Indetifier) – 10-разрядное число от 0 до 1023, которое идентифицирует отдельный постоянный виртуальный канал PVC (Permanent Virtual Circuit).
PVC – постоянный виртуальный канал, означает способность передавать фреймы Frame Relay между двумя устройствами, подключенными к одной сети Frame Relay, если провайдер заранее предусмотрел такую возможность. CIR (Committed Information Rate) — гарантированная скорость передачи.
Чтобы технология работала, каждый маршрутизатор должен быть физически подключен кабелем с коммутатором Frame Relay в местной АТС. Коммутатор Frame Relay – это оборудование которое «понимает» Frame Relay и может передавать трафик, основанный на протоколах Frame Relay. Набор коммутаторов Frame Relay провайдера, наряду с другим оборудованием, установленным между ними, формирует сеть Frame Relay . Услуга, которую предлагает провайдер – это возможность для маршрутизатора посылать фреймы Frame Relay и получать их от других маршрутизаторов, связанных с этой сетью.
Frame Relay – это набор протоколов, каждый из которых выполняет функции, соответствующие канальному уровню 2 модели OSI. Для выполнения функций уровня 1, т.к. обустройство кабельной системы и фактическая передача битов, Frame Relay использует те же стандарты, что и последовательные каналы. Физический последовательный канал между маршрутизатором и коммутатором Frame Relay называют каналом доступа (access link).
Чтобы послать фрейм, маршрутизатор должен поместить в заголовок нужный адрес. Каждый заголовок Frame Relay содержит поле адреса, именуемое идентификатором канала связи (DLCI).
Если маршрутизатору R1 необходимо послать пакет маршрутизатору R2, через сеть Frame Relay, маршрутизатор физически использует последовательный интерфейс и логически использует PVC с необходимым DLCI (для площадки в Киеве это например 102). Маршрутизатор выполняет инкапсуляцию Frame Relay, как это делают и другие протоколы канального уровня. Маршрутизатор R1 знает исходящий исходящий интерфейс и IP-адрес следующего перехода, но он не знает, какой DLCI нужно использовать. Для решения этой проблемы используется инверсный протокол ARP (Inverse ARP). Как только начинает работать постоянный виртуальный канал (PVC), R2 объявляет свой IP-адрес маршрутизатору R1, используя виртуальный канал (VC) между этими двумя маршрутизаторами. R1 также объявляет свой IP-адрес маршрутизатору R2.
Для начала немного лирики. Уж не знаю почему, но к Frame Relay я всегда имел какие-то теплые чувства (если их вообще можно иметь к протоколу передачи данных... коллеги меня поймут, надеюсь). Впервые я узнал о нем давным давно, когда ещё готовился к CCNA. Тогда Frame Relay произвел на меня достаточно большое впечатление, хотя бы потому что это был не Ethernet. Это было что-то новое, что я не знал тогда. С тех пор, я почти не видел его имплементаций в жизни. Зато в цисковских экзаменах его до недавнего времени было просто завались... Давайте попробуем разобраться, что же в нем такого...
Причины возникновения
После лирики самое время перейти к истории. Frame Relay появился в эру ISDN. Возникла надобность как-то организовать передачу данных по сети, для этого изначально была и разработана технология Frame Relay. Довольно редко встречающаяся в наши дни технология, однако не так уж редкая, как многие думают. Основным применением технологии был, так называемый, корпоративный сектор. В то время, для обеспечения канала связи между двумя офисами, применялись point-to-point serial линки. Штука простая и удобная, но не масштабируемая. Если нам нужно соединить 3 устройства через ISDN сеть, от каждого устройства понадобится прокладывать два serial линка. А если устройств 100?.. Эту проблему был призван решить Frame Relay. Он способен объединить все эти офисы чуть более эффективным методом. Понадобится всего один линк для соединения каждого устройства с Frame Relay облаком. Картина ниже иллюстрирует подход.Frame Relay - это NBMA (non-broadcast multiple access ) сеть. Это означает, что одно устройство в сети может взаимодействовать с множеством других, но делается это не средствами посылки broadrcast сообщений. В этом основной прикол Frame Relay, который накладывает отпечаток на многие аспекты связанные с этим протоколом. Например, работа протоколов маршрутизации через такую сеть имеет некоторые особенности.
Frame Relay - работает на втором уровне OSI, поверх которого можно передавать множество L3 технологий. Конечно же, основная из них - IP. Именно про IP over Frame Relay и пойдет речь дальше.
Frame Relay вводит пару терминов, которые особой сложности не несут, но иногда могут завести в заблуждение.
- DTE (data terminal equipment) - оборудование, которое использует сервис Frame Relay. По сути это CPE.
- DCE (data circuit-terminating equipment ) - оборудование, которое предоставляет сервис Frame Relay. Это Frame Relay Switch, который стоит на стороне провайдера.
Базовый принцип
Итак, теперь когда мы более или менее определились что такое Frame Relay, пора глянуть на то как он работает. Если говорить в терминах Frame Relay, то на схеме ниже у нас три устройства, которые подключены к Frame Relay облаку. Это DTE1, DTE2 и DTE3. Каждое их этих устройств подключено к провайдерскому устройству (DCE), которых на схеме тоже три.
Так же на схеме можно заметить некие VC
. Их тут три и это основополагающий концепт во Frame Relay. Устройства в сети Frame Relay соединенны средствами Virtual Circuit
, которые прокладываются поверх физических линков. Так, к примеру, DTE1 подключено к DTE2 и DTE3 двумя такими секитами, VC12 и VC31 соответственно.
Строго говоря, VC бывают двух типов:
- SVC (Switched Virtual Circuit)- такой канал сигнализируется DTE каждый раз, когда нужно передать данные.
- PVC (Permanent Virtual Circuit) - этот тип секита всегда присутствует в сети и настроен на узлах. DTE к нему всего лишь подключаются, но не сигнализируют.
Перейдем к тому как кадры передаются через такую сеть. Допустим, устройство DTE1 (192.168.0.1/24) хочет отправить какие-то данные устройству DTE2 с адресом 192.168.0.2/24.
- Роутер DTE1 инкапсулирует IP пакет в Frame Relay кадр, вставляет DLCI=102 в заголовок и отправляет получившийся сверток в сторону DTE2.
- В нашем случае, кадр попадает на DCE1. Внутри Frame Relay облака, перво наперво, проверяется заголовок Frame Relay, там находится идентификатор DLCI=102, это это часть секита VC12, DLCI в кадре меняется на 101 и отправляется в сторону DTE2.
- DTE2 так же смотрит заголовок Frame Relay, находит там DLCI 101 по которому он понимает, что данные пришли от DTE1. Далее заголовок отбрасывается и начинается работа с IP пакетом.
LMI (Local Management Interface)
Для взаимодействия между DTE и DCE существует специальный протокол LMI, который в сетях Frame Relay выполняет две важные функции.
- Keepalive. Если от соседа не приходит никаких сообщений, то такой линк считается умершим. Обычно это 3 не пришедших сообщения, интервал между которыми равен 10 секунд.
- Сигнализация состояния. Как только роутер (DTE) появляется в сети, он шлет сообщение LMI Status Enquiry в сторону DCE. Тот отвечает ему сообщением LMI Status , в котором рассказывает какие DLCI сейчас настроены на этом VC и в каком они статусе.
Таким образом, после настройки линка наш DTE автоматически узнает о том, какие DLCI используются . Проблема только в том, что мы не знаем какой IP какому DLCI соответсвует . "ARP" - воскликнет читатель. "Почти" - отвечу я.
Inverse ARP
После того, как мы подключили устройство к сети Frame Relay, ближайший свитч расскажет нам какие DLCI настроены в канале. Для того, чтобы узнать какие L3 адреса (IP, короче говоря) за ними сидят нам нужно что-то вроде ARP в Ethernet, но наоборот. В Ethernet мы знаем L3, но не знаем какой MAC, т.е. L2 адрес, ему соответствует. Тут же мы знаем L2 адрес (DLCI), а вот IP нет.
Как только наш роутер DTE получит сообщение LMI Status с перечислением DLCI, он сразу же отправит Inverse ARP сообщение в сеть, в котором расскажет свой DLCI и свой L3 адрес. Таким образом, другие участники сети узнают, с каким DLCI нужно слать кадры для достижения этого роутера .
Конечно, Inverse ARP можно отключить, отключив LMI, кстати говоря. В таком случае, всю настройку вы берете на себя. Нужно статически настроить DLCI на интерфейсах и записать каким DLCI на удаленных сторонах сети какие адреса соответсвуют.
Топологии
Стоит пару слов сказать про L3. Вы вольны как угодно строить дизайн L3 поверх Frame Relay облака. Можно одну подсеть "размазать" по всей сети, что я и сделал в своем примере (картинка ниже слева). Можно использовать логику точка-точка и на каждый VC выделить свою подсеть (справа).
Тип интерфейса
От типа интерфейса зависит то, как себя будет вести Frame Relay, и как будут вести себя протоколы динамической маршрутизации поверх него, кстати говоря. Сейчас рассмотрим немного исковерканную топологию из моего примера, у которой по какой-то причине убрали один линк между DTE1 и DTE3.
Для примера возьмем Cisco, где нам предлагаетя возможность настроить Frame Relay на:
- Физическом интерфейсе . Хороший вариант, но не очень масштабируемый. В нашем примере выше, всю топологию можно настроить на физических интерфейсах. Прописываем инкапсуляцию frame-relay и IP адрес, всю остальную работу за нас сделают LMI и InARP. А вот если бы мы выбрали для реализации подход с предыдущего рисунка, когда для каждого VC нам понадобилась бы своя подсеть, настроить Frame Relay на физическом уровне уже не получится. Нужно было бы прописать две подсети на один физический интерфейс.
- Сабинтерфейсе . Можно сказать, что это Best Practises. Но в таком случае, нам нужно выбрать тип интерфейса, коих у нас два:
- Point-to-Point . В таком случае, InverseARP нам не нужен, потому как сама логика PtP предполагает, что на другом конце только одно устройство. Роутер просто считает, что вся подсеть, которая прописана на локалном интерфейсе доступна через DLCI соседа. Например, если настроить VC12 как PtP сабинтерфейс на DTE1, то роутер просто решит, что вся подсеть 192.168.0.0/24 доступна через VC12 и слать трафик в неё нужно с DLCI 102. Такой DLCI рассказал нам DTE2 на другом конце средствами LMI. Напомню, InverseARP для маппинга L2 в L3 не используется в таком случае. Для нашего примера, линк на DTE3 тоже можно настроить как PtP.
- Multipoint . А вот на DTE2 такая логика неприменима, ведь через один линк должно ходить несколько VC. В нашем случае, здесь потребуется настроить multipoint сабинтерфейс.
Если прикинуть, как будет ходить трафик в такой топологии, то получится примерно следующее. Допустим, в облаке уже все настроено и вы включили свои настроенные устройства.
- Первым делом отправится LMI Status Enquiry в сторону свичей в облаке.
- Свичи ответят нашим DTE сообщением LMI Status какие DLCI настроены в VC. А именно, DTE1 и DTE3 узнают про DLCI 102, который принадлежит DTE2. DTE2 узнает про DLCI 101 и 102, которые принадлежат DTE1 и DTE2 соотвествнно.
- Как только придет LMI Status на наши DTE, они отправят InARP сообщения. DTE1 расскажет, что его IP 192.168.0.1/24 и DLCI 101. DTE2 расскажет соседям, что его аддрес 192.168.0.2/24 и DLCI 102. DTE3 тоже всё всем расскажет.
- Когда на DTE1 появится интерсующий нас трафик для отправки в сторону DTE3, он просто возьмет IP пакет, завернет его в Frame Relay кадр, запишет в него DLCI 102 . Смотреть на InARP он не будет, он просто знает, что все из сети 192.168.0.0/24 нужно отправлять с DLCI 102. Почему? Потому что у нас натсроен point-to-point интерфейс.
- Пройдя через Frame Relay облако, наш заголовок трансформируется и уже будет иметь DLCI 101 .
- Такой вот кадр с DLCI 101 и придет на DTE2. DTE2 поймет, что трафик этот не предназначается ему, потому что у него нет нужного IP на интерфейсах. Он взглянет на свой маппинг, который он составил по результатам LMI и InARP и поймет, что трафик этот предназначается DTE3 и должен быть отправлен в его сторону с DLCI 103.
- DTE2 инкапсулирует трафик в новый FR заголовок и ставит в него DLCI 103 .
- По пути DLCI в заголовоке опять магическим образом поменяется с 103 на 102 .
- Наконец-то DTE3 получил трафик, отбросил заголовок второго уровня (Frame relay), глянул в L3 заголовок (IP) и понял, что это для него. Далее трафик будет каким-либо образом обработан.
- В случае, если DTE3 сформирует какой-то ответный трафик в сторону DTE1, ситуация повторится с пункта 1, но в обратном направлении.
На картинке выше изображен первый случай .
- DTE1 отправляет некий трафик обернутый заголовком Frame Relay, в котором помимо DLCI находятся два бита - FECN и BECN. Роутер DTE1 отправляет их равными нулю, потому что он ни про какие перегрузки в канале не знает (ещё пока).
- DCE1 получает трафик и обрабатывает его, все как обычно. Однако он замечает, что в линке до DCE2 есть заторчик. Он запоминает VC, в котором к нему пришли данные и ставит бит FECN равным 1 в заголовке кадра в сторону соседа DCE2. Что означает, что в канале произошла перегрузка. Делает он это, по сути, в надежде, что кто-то на него-таки взглянет. Спойлер - не в этот раз...
- Кадр приходит на DCE2. Для него это самый обычный трафик, который он отправляет на DTE2.
- DTE2, получив трафик, начинает его как-то обрабатывать и, скорее всего, шлет некий обратный трафик. Он в этом примере про перегрузку канала ничего не знает, поэтому в его обратном кадре FECN и BECN тоже нулевые.
- Когда DCE1 получит такой трафик, он узнает VC и поставит бит BECN равный 1, для того, чтобы сказать источнику трафика (DTE1), что на канале есть проблемы и ему надо немного охладить свой пыл.
Втором примере на картинке выше.
В этом случае, DTE2 настроен на реакцию на бит FECN и сам проставит BECN = 1, для того чтобы уведомить DTE1 о перегрузке. DCE1 в этом случае ничего менять не будет. В этот раз, DCE1 не зря ставил FECN = 1, все таки хоть кому-то он пригодился и DTE2 взглянул на него.
FECN бит в нормальном сети меняют только DCE, а вот BECN могут менять как DCE, так и DTE.
Зачем же нужен бит DE ? Когда обнаружиться перегрузка, на DCE, рано или поздно, переполнится очередь на отправку и он будет вынужден начать процесс сбрасывания кадров с её конца. Он понятия не имеет какой трафик важный, а какой нет. Но ему можно попытаться рассказать об этом... Есть возможность помечать некий "неважный" трафик при отправке с DTE битом DE. В этом случае, наши свитчи в ядре (DCE) смогут понять какой трафик стоит отбрасывать в первую очередь, инспектируя значение этого бита в заголовке Frame Relay.
Наверное, пока хватит. Наконец-то я описал Frame Relay в своем блоге. Теперь я буду спать спокойно.
Как бы "залабить" все это?..
Технология Frame Relay(FR, ретрансляция кадров) ориентирована на использование в сетях с коммутацией пакетов. Сама технология охватывает только физический и канальный уровни OSI. Сетью Frame Relay принято считать любую сеть, использующую на нижних двух уровнях управления одноименную технологию. Основное отличие Frame Relay от Х.25 - в механизме обеспечения достоверности информации. Сеть Х.25 разрабатывалась с учетом плохих аналоговых каналов связи, имевшихся в то время, и поэтому в ней приняты весьма трудоемкие меры по обеспечению достоверности, требующие для своей реализации больших временных затрат. Именно поэтому сеть Х.25 является сетью с гарантированной доставкой информации.
Технология FR разрабатывалась с учетом уже достигнутых в телекоммуникациях высоких скоростей передачи данных и низкого уровня ошибок в современных сетях. Таким образом, сеть Frame Relay ориентирована на хорошие цифровые каналыпередачи информации, и в ней отсутствует проверка выполнения соединения между узлами и контроль достоверности информации(контроль за появлением ошибок) на канальном уровне, а именно на этом уровне в FR выполняется мультиплексирование потока данных в кадры. Каждый кадр канального уровня содержит заголовок, который используется для маршрутизации трафика. Контроль достоверности передачи осуществляется на верхних уровнях модели OSI. При обнаружении ошибки повторная передача кадра не производится, а искаженный кадр просто выбрасывается.
Таким образом в сети Frame Relay обеспечивается гарантированная согласованная скорость передачи информации. Скорость передачи может быть весьма большой: в диапазоне от 56 Кбит/с до 44 Мбит/с, но без гарантии достоверности доставки.
Компонентами сети Frame Relay являются устройства трех основных категорий:
l устройства DTE (Data Terminal Equipment);
l устройства DCE (Data Circuit-Terminating Equipment);
l устройства FRAD (Frame Relay Access Device).
Также как и в сети X.25, основу Frame Relay составляют виртуальные каналы (virtual circuits). Виртуальный канал в сети Frame Relay представляет собой логическое соединение, создаваемое между двумя устройствами DTE в сети Frame Relay и используемое для передачи данных.
В сети Frame Relay используется два типа виртуальных каналов - коммутируемые (SVC) и постоянные (PVC).
Коммутируемые виртуальные каналы представляют собой временные соединения, предназначенные для передачи импульсного трафика между двумя устройствами DTE в сетях Frame Relay. Процесс передачи данных с использованием SVC состоит из четырёх последовательных фаз:
l установление вызова (Call Setup) - на этом этапе организуется виртуальное соединение между двумя DTE;
l передача данных (Data Transfer) - непосредственная передача данных;
l ожидание (Idle) - передача данных через уже существующее виртуальное соединение не производится; если период ожидания превысит установленное значение, соединение может быть завершено автоматически;
l завершение вызова (Call Termination) - выполняются операции, необходимые для завершения соединения.
Постоянные каналы представляют собой постоянное соединение, обеспечивающее информационный обмен между двумя DTE-устройствами. Процесс передачи данных по каналу PVC имеет всего две фазы: передача данных и ожидание.
Для обозначения виртуальных каналов в сети Frame Relay используются идентификаторы DLCI (Data-Link Connection Identifier), выполняющие ту же роль, что и номера логического канала в сетях X.25. DLCI определяет номер виртуального порта для процесса пользователя.
В технологии Frame Relay задействуются протоколы только на физическом и канальном уровнях. Протокол физического уровня описывается весьма распространенным стандартом I.430/431.
Протоколом канального уровня в Frame Relay является LAP-F - весьма упрощенная версия протокола LAP-D, описывающего взаимодействие соседних узлов либо как процедуру без установления соединения, либо как процедуру с установлением соединения без подтверждения.
На остальных уровнях могут работать протоколы любых сетей с коммутацией пакетов. В частности, с технологией Frame Relay хорошо согласуются стек протоколов TCP/IPи протоколы сети Х.25.
Протокол LAP-F в сетях Frame Relay имеет два режима работы: основной и управляющий. В основном режиме кадры передаются без преобразования и контроля, как в обычных коммутаторах. Поэтому достигается высокая производительность, тем более, что подтверждения передачи не требуется.
Упрощена и процедура передачи пакетов из локальных сетей: они просто вкладываются в кадры канального уровня, а не в пакеты сетевого уровня, как в Х.25.
Кадр протокола Frame Relay содержит минимально необходимое количество служебных полей. Его формат, реализованный в соответствии с протоколом HDLC, показан ниже.
Широкополосная ISDN.
Широкополосная ISDN (Broadband ISDN – B-ISDN) - обеспечивает скорости превышающие скорость первичного доступа ISDN (Primary Rate Interface). Это новая технология. С внедрением B-ISDN станут доступными услуги видео, требующие скоростей на порядок выше, чем в ISDN.
В стандартах B-ISDN определены следующие скорости передачи:
Полнодуплексная 155.52 Мбит/с
Асимметричная 155.52 Мбит/с от абонента к сети и 622.08 Мбит/с в обратном направлении.
Полно дуплексная 622.08 Мбит/с
Скорость 155.52 Мбит/с поддерживает все службы узкополоснойISDN, в том числе один или более интерфейсов BRI и PRI. Кроме того, она поддерживает практически все службы B-ISDN. Т.о. скорость 155.52 Мбит/с будет наиболее распространенной в B-ISDN. Скорость 622.08 Мбит/с наиболее подходит для магистральных участков сети и линий абонентского доступа в направлении от провайдера к абоненту.
Рост компьютерных приложений, требующих высоких скоростей информационного обмена, быстрое увеличение производительности персональных компьютеров и автоматизированных рабочих мест, а также увеличение числа помехоустойчивых и высокоскоростных каналов связи привело к созданию нового метода информационного обмена в территориально распределенных сетях. Этот новый метод характеризуется высоким быстродействием, низкой задержкой, разделением портов и полосы пропускания на основании виртуальных каналов.
Frame Rе1ау имеет характеристики, которые делают его идеальным решением для передачи "взрывного" трафика. Frame Rе1ау предлагает пользователям возможность улучшить работу (время ответа) сети и существенно уменьшить затраты на передачу для множества сетевых приложений.
Frame Rе1ау (ретрансляция кадров) - это метод доставки сообщений в сетях передачи данных коммутацией пакетов. Первоначально разработка стандарта Frame Rе1ау ориентировалась на цифровые сети интегрированного обслуживания (ISDN – Integrated Services Digital Networks), однако позже стало ясно, что Frame Rе1ау применим и в других сетях передачи данных (под данными понимается любое сообщение, представленное в цифровой форме). К числу достоинств метода, прежде всего, необходимо отнести малое время задержки, простой формат кадров, содержащих минимум управляющей информации, и независимость от протоколов верхних уровней. Frame Rе1ау является бит-ориентированным синхронным протоколом и использует "кадр" в качестве основного информационного элемента - в этом смысле он очень похож на протокол HDLC (High Level Data Link Control). Одним из основных отличий протокола Frame Rе1ау от HDLC является то, что он не предусматривает передачу управляющих сообщений (нет командных или супервизорных кадров, как в НDLС). Для передачи служебной информации используется специально выделенный канал сигнализации. Другое важное отличие - отсутствие нумерации последовательно передаваемых (принимаемых) кадров. Дело в том, что протокол Frame Rе1ау не имеет никаких механизмов для подтверждения правильно принятых кадров. Протокол Frame Rе1ау является весьма простым по сравнению с НDLС и включает в себя небольшой свод правил и процедур организации информационного обмена. Основная процедура состоит в том, что если кадр получен без искажений, он должен быть направлен далее по соответствующему маршруту. При возникновении проблем, связанных с перегрузкой сети Frame Rе1ау, ее узлы могут отказываться от каких-либо кадров.
Frame Rе1ау обеспечивает возможность передачи данных с коммутацией пакетов через интерфейс между устройствами пользователя (например, маршрутизаторами, мостами, главными вычислительными машинами) и оборудованием сети (например, переключающими узлами). Устройства пользователя часто называют терминальным оборудованием (DТЕ), в то время как сетевое оборудование, которое обеспечивает согласование с DTЕ, часто называют устройством завершения работы информационной цепи (DСЕ). Frame Rе1ау является протоколом для линии с большим потоком информации, обеспечивая более высокую производительность и эффективность.
В роли интерфейса между оборудованием пользователя и сети, Frame Rе1ау обеспечивает средства для мультиплексирования большого числа логических информационных диалогов (называемых виртуальными цепями) через один физический канал передачи, которое выполняется с помощью статистики.
Важной характеристикой Frame Rе1ау является и то, что он использует новейшие достижения технологии передачи глобальных сетей. Более ранние протоколы WAN были разработаны в то время, когда преобладали аналоговые системы передачи данных и медные носители. Эти каналы передачи данных значительно менее надежны, чем доступные сегодня каналы с волоконно-оптическим носителем и цифровой передачей данных. В таких каналах передачи данных протоколы канального уровня могут предшествовать требующим значительных временных затрат алгоритмам исправления ошибок, оставляя это для выполнения на более высоких уровнях протокола. Следовательно, возможны большие производительность и эффективность без ущерба для целостности информации. Именно эта цель преследовалась при разработке Frame Rе1ау. Он включает в себя алгоритм проверки при помощи избыточного циклического кода (СRС) для обнаружения испорченных битов (из-за чего данные могут быть отвергнуты), но в нем отсутствуют какие-либо механизмы для корректирования испорченных данных средствами протокола (например, путем повторной их передачи на данном уровне протокола).
В настоящее время, когда большинство протоколов высших уровней эффективно выполняют свои собственные алгоритмы управления потоком, необходимость в этой функциональной возможности на канальном уровне уменьшилась. Frame Rе1ау не включает явно выраженных процедур управления потоком, которые являются избыточными для этих процедур в высших уровнях. Вместо этого предусмотрены очень простые механизмы уведомления о перегрузках, позволяющие сети информировать какое-либо устройство пользователя о том, что ресурсы сети находятся близко к состоянию перегрузки. Такое уведомление может предупредить протоколы высших уровней о том, что может понадобиться управление потоком.
Стандарты Frame Rе1ау адресованы перманентным виртуальным цепям (РVС), определение конфигурации которых и управление осуществляется административным путем в сети Frame Rе1ау. Был также предложен и другой тип виртуальных цепей - коммутируемые виртуальные цепи (SVС).
Frame Rе1ау определяется как "пакетный режим" обслуживания, означающий, что данные преобразуются в индивидуально адресованные единицы. (Это происходит быстрее, чем при помещении в установленные временные интервалы). Frame Rе1ау полностью устраняет всю обработку на сетевом уровне. Кроме того, Frame Rе1ау использует только часть функций канального уровня, так называемые "основные аспекты", которые включают проверку ошибок в кадре, но не требуют повторной передачи кадра при обнаружении ошибки. Таким образом, такие традиционные функции протокола передачи данных как проверка последовательности поступления кадров, регулирование размера "окна", механизм подтверждений не используются в сети Frame Rе1ау. Результатом исключения этих функций является существенное увеличение производительности (т.е. числа кадров, которые могут быть обработаны в секунду). По той же самой причине, задержка при использовании метода Frame Rе1ау достаточно низкая.
Поскольку протокол Frame Rе1ау значительно упрощен, ответственность за непрерывную и безошибочную передачу данных лежит на оконечных устройствах. Одна из особенностей Frame Rе1ау состоит в использовании кадров переменной длины. Это очень полезно при организации эффективной работы с LAN и другими источниками, которые требуют переменного размера кадра. Некоторые типы трафика критичны к задержке, например, речь и сжатое видео. Frame Rе1ау, к сожалению, плохо приспособлен для передачи такого трафика. Frame Rе1ау полностью соответствует требованиям источников "взрывного" трафика, например при информационном обмене LAN-to-LAN.
Для адресации пакетов в заголовке Frame Rе1ау содержится 10-разрядный идентификатор канала передачи данных (DLCI), который является номером связанного с определенным получателем виртуального канала. В случае информационного обмена LAN-WAN DLCI обозначает порт, к которому подключается LAN, см. рис. 26.
Рис. 26. Сеть Frame Relay.
При передачи данных через сеть Frame Rе1ау, обработка производится по следующему алгоритму:
1. Проверка целостности кадра. Используется проверочная последовательность кадра. В случае выявления ошибки кадр удаляется.
2. Сравнение DLCI кадра с таблицей DLCI в узле.Если для данного канала DLCI не определен, то кадру удаляется.
3. Ретрансляция кадра к получателю. Осуществляется из порта, указанного в таблице.
Разработанные в 1991 году стандарты предполагали использование в сетях Frame Relay только постоянных виртуальных каналов (РVС). Такие каналы устанавливаются непосредственно администратором сети через систему управления. РVС в сети Frame Rе1ау обычно определяет связь между двумя LAN, поэтому новый РVС необходим только при подключении новой LАN к сети. РVС полностью удовлетворяют требованиям большинства приложений. В ряде случаев возможно использование коммутируемых виртуальных каналов (SVС).
Основная процедура протокола Frame Rе1ау очень проста и включает одно правило: если имеется какая-нибудь проблема с обработкой кадра, то он уничтожается. К потере кадра Frame Rе1ау могут привести две основные причины:
Обнаружение ошибок в кадре;
Возникновение перегрузки в сети.
Оконечные устройства управляются протоколами высших уровней, которые могут обнаруживать и восстанавливать потерянные данные в сети, таким образом сеть может удалить кадр, не нарушая целостности сообщения. При обнаружении ошибки в кадре (не совпадает кодовая последовательность СRС) узел просто отказывается от кадра и переходит к обработке следующего. Процедура выявления ошибок и перезапроса возлагается на возможности персональных компьютеров или автоматизированных рабочих мест, которое являются отправителями данных. Использование механизма исправления ошибок на высоких уровнях не оправдано, если использовать зашумленные каналы с высокой вероятностью появления ошибки. В настоящее время в мире становится все больше оптоволоконных линий передачи с чрезвычайно низкими показателями вероятности появления ошибки, поэтому восстановления данных на таких линиях происходит достаточно редко и не является существенной проблемой. Таким образом, Frame Rе1ау максимально эффективен только на хороших каналах связи (с малой вероятностью возникновения ошибки).
Наиболее существенная причина потери кадров - перегрузка в сети. Перегрузка происходит в следующих ситуациях:
Узел сети не справляется с обработкойвходного потока;
Интенсивность потока данных (число пакетов в секунду) на входе не соответствует скорости канала связи;
Переполнение буфера (временнаяпамять для обработкикадра или выходной очереди кадров) узла коммутации.
Очень важно, чтобы сеть Frame Rе1ау имела хорошие механизмы управления потоком, которые могли бы минимизировать вероятность возникновения и масштабы перегрузок, а также уменьшить влияние потерянных кадров.
При практической реализации сетей Frame Rе1ау должны быть определены механизмы для решения следующих важных проблем:
Уведомление о возникновении перегрузки;
Сообщение о состоянии виртуальных каналов;
Обеспечение равноправия и гарантируемой производительности для пользователей;
Учет будущего расширения сети и новых условий эксплуатации.
В общем случае использование механизмов управления необязательно. Однако, они существенно влияют на такие показатели сети как производительность, время ответа, эффективность использования каналов и оконечного оборудования пользователей.
В случае возникновения перегрузки в одной точке сети Frame Rе1ау часть входящих кадров уничтожается. Если входная нагрузка продолжает увеличиваться, это приводит к серьезной перегрузке и эффективная производительность сети начинает уменьшаться из-за многократной передачи одного и того же кадра. В случае серьезной перегрузки (блокировки) полная производительность сети может сильно упасть и единственный способ выхода из данного положения - уменьшение входящей нагрузки. В связи с этим были использованы несколько механизмов об уведомлении устройства пользователя о перегрузке. В этом случае устройство пользователя должно уменьшить объем передаваемой информации. В идеальном случае сеть должна отследить появление перегрузки и при помощи специальных возможностей предотвратить появление серьезной перегрузки.
Один из механизмов уведомления о перегрузке использует два бита "явного уведомления о перегрузке " (ЕСN) в заголовке кадра Frame Rе1ау. Это бит "явного уведомления приемника о перегрузке " (FЕСN) и бит "явного уведомления источника о перегрузке" (ВЕСN). На рисунке 2.2 изображено использование этих битов.
Рис. 27 Использование FЕСN и ВЕСN при явном уведомлении о перегрузке.
Если узел В приближается к состоянию перегрузки. Это могло быть вызвано, например, временным пиком входящего в узел трафика или пиком трафика в канале между узлами В и С. Узел В может обнаружить начало перегрузки по внутренним признакам, таким как чрезмерное использование памяти или увеличение длины очереди. Узел С (следующий по направлению к получателю) будет уведомлен об этом, получив кадр с установленным битом FЕСN. Все последующие по направлению к получателю узлы, также как и устройство пользователя, узнают, что на определенных DLCI появилась перегрузка.
Для некоторых протоколов полезнее уведомить источник данных о перегрузке для того, чтобы он смог замедлиться до пропадания перегрузки. Узел В также наблюдает за кадрами, которые передаются в обратную сторону, и устанавливает бит ВЕСN в 1. Этот процесс установки FЕСN и ВЕСN может осуществляться одновременно на нескольких DLCI в ответ на перегрузку в данном канале или узле. Биты ЕСN представляют важный инструмент для уменьшения серьезных состояний перегрузки.
Другой механизм уведомление о перегрузках - это механизм передачи сигналов управления, известный как CLLM. При использовании CLLM один из DLCI (номер 1023) в интерфейсе Frame Rе1ау зарезервирован для передачи управляющих сообщений канального уровня от сети к устройству пользователя. Стандарт АNSI определяет формат сообщения CLLM, которое сеть посылает устройству пользователя. Оно содержит причину перегрузки (например, чрезмерного трафика, отказ канала, и т.д.) и список всех DLCI в которых необходимо уменьшить трафик и тем самым снизить перегрузку. CLLM может использоваться вместо или в дополнение к битам ЕСN, чтобы сообщить устройству пользователя о возникновении перегрузки. CLLM обеспечивает дополнительный (необязательный) стандартный механизм для передачи сигналов уведомления о перегрузке.
Некоторые протоколы верхних уровней, которые реализованы в оконечных устройствах, имеют механизм неявного обнаружения перегрузки. Эти протоколы используются для эффективной передачи информации по сетям с неопределенной вместимостью. Такие протоколы ограничивают поток данных посредством "окна", которое позволяет только ограниченному числу кадров быть посланными до получения подтверждения. Протокол может обнаружить перегрузку по увеличению задержки передачи сообщения к получателю и обратно или по анализу потери кадров в сети. Этот механизм известен как "неявное уведомление о перегрузке".
Если признаки указывают на возникновение перегрузки, протокол может уменьшить размер окна, что приведет к уменьшению входной нагрузки на сеть. Соответственно, при уменьшении перегрузки размер окна может постепенно увеличиваться. Регулирование размера окна может являться одним из механизмов ответа и на явное уведомление о перегрузке. В стандартах АNSI указано, что неявное и явное уведомление о перегрузке является дополнительным средством для повышения эффективности сети.
В соответствии со стандартами Frame Rе1ау устройство пользователя должно регулировать свой трафик. Для этого предложены некоторые подходы, включающие принципы регулирования размера окна. Выполнение устройством пользователя рекомендуемых действий приводит к уменьшению объема передаваемой информации, тем самым к сокращению перегрузки. В этом случае из сети Frame Rе1ау в последнюю очередь удаляются пакеты данных, наиболее чувствительных к задержкам, например телефония или видео. Однако устройство пользователя может и не выполнять данные рекомендации. Оно может просто игнорировать сигнал перегрузки и продолжать передавать данные с той же интенсивностью. Это привело бы к появлению сложной перегрузки или блокировки (узла, части сети, сети полностью). В этом случае сеть защищает себя, используя основное правило Frame Rе1ау: если имеется проблема с обработкой кадра, то он уничтожаются. Поэтому, если возникает перегрузка, то часть кадров уничтожается. Это увеличит время ответа и уменьшит полную производительность сети, но сеть будет продолжать функционировать. Кроме того, если сеть достаточно интеллектуальна, может происходить уничтожение кадров конкретного пользователя, гарантируя другим сохранность их кадров. Под термином "устройство пользователя" для сетей Frame Rе1ау обычно понимается устройство, непосредственно связанное с сетью, например маршрутизатор или мост.
Трафик в сетяхFrame Rе1ау генерируется широким диапазоном источников от медленных например, операционный терминал, который посылает небольшие потоки данных) до быстродействующих устройств (графические автоматизированные рабочие места, способные послать мультимегабитные потоки данных). Проблема состоит в обеспечении источников небольших потоков данных и данных, критичных к задержкам (голос, видео) гарантированной полосой пропускания, которая в общем случае может быть перекрыта источниками мультимегабитных потоков. Однако устройства пользователей могут игнорировать сигналы перегрузки. В этом случае производители решают проблему гарантии полосы пропускания в соответствии со стандартом АNSI. Один из битов в заголовке кадра Frame Rе1ау используется как "Разрешение сброса" (DЕ). Бит DЕ указывает, что в случае возникшей перегрузки сеть будет первыми уничтожать кадры с установленным битом DЕ. Этот бит может быть установлен устройством пользователя для некоторых кадров с низким приоритетом. Конечно не все устройства пользователей будут придерживаться этого принципа. Поэтому бит DЕ может устанавливаться непосредственно узлом сети для указания последующим узлам, что при необходимости данный кадр может быть уничтожен в первую очередь. Таким образом, бит DЕ является инструментом, который дает возможность сети управлять производительностью. В результате этот инструмент может использоваться для обеспечения пользователю предсказуемой и даже гарантированной производительности.
Имеются различные способы определения перегрузки. Наиболее простой подход состоит в том, чтобы распознать перегрузку по удалению кадров. Более совершенные алгоритмы контролируют внутренние параметры, например, длину очереди, чтобы обнаружить перегрузку прежде, чем это приведет к удалению кадров. При обнаружении перегрузки сеть должна разумно принять решение о том, какие источники должны уменьшить входную нагрузку. Выборочный подход намного лучше (и справедливее)чем общий подход, когда замедляются все источники трафика.
В случае перегрузки узлы должны принять решение об удаление кадров. Самый простой подход состоит в том, что кадр выбирается наугад. В этом случае увеличивается число оконечных устройств, которые должны вести восстановление кадров из-за их потери. Возможно улучшить работу сети, отказываясь от кадров в конкретном РVС.
Использование бита DЕ - мощный механизм для оптимизации решения об удалении кадра, и используется как в пограничных, так и во внутренних транзитных узлах сети. Этот механизм может использоваться как инструмент для обеспечения гарантируемого уровня обслуживания пользователям. Каждый пользователь выбирает "Гарантированную скорость передачи данных " (СIR), которая определяет потребность пользователя для передачи трафика в течение определенного периода времени. Сеть измеряет пользовательский трафик через определенные интервалы. Если пользователь посылает данные со скоростью не большей, чем СIR, сеть не будет изменять бит DЕ, и кадр гарантированно будет передан по сети. Если скорость превысит СIR в течение данного периода времени, то входной узел установит бит DЕнаизбыточных кадрах и будет продолжать передавать эти кадры, если сеть не перегружена. Наконец, если скорость поступления кадров окажется выше максимальной, то все избыточные кадры будут удаляться и не будут влиять на других пользователей.
Высокая скорость желательна для того, чтобы время задержки в сети было низким. Но так как трафик "взрывной", скорость нормального трафика для большинства пользователей будет несколько ниже, чем полная скорость в канале даже в течение пиковых часов. При использовании бита DЕ и с учетом "измерения" трафика сеть может гарантировать предсказуемый уровень обслуживания. Эта способность может быть весьма ценной. Этот метод может быть применим для проектирования и управления сетью, чтобы каждый пользователь получил соответствующий уровень обслуживания. Данные с более высоким приоритетом получили бы наименьшую задержку по сравнению с кадрами более низкого приоритета и гарантию доставки (более низкая вероятность удаления кадра). Эта особенность важна в сетях, которые поддерживают чувствительные к задержке приложения, и в то же время используются для передачи объемных файлов, которые более интенсивно занимают полосу пропускания, но менее чувствительны к времени ответа. Для чувствительных к задержке данных назначался бы более высокий приоритет, гарантируя быструю доставку.
В случае обычного использования DLCI имеет только локальное значение. Это означает, что каждый DLCI определяет канал связи от данного порта до одного из 1024 других портов сети. Тот же самый номер DLCI может многократно использоваться в различных портах. Таким образом, порт может иметь до 1024 DLCI. Число адресов в сети теоретически не ограничено. В некоторых стандартах Frame Rе1ау, например в LMI, применяется глобальная схема адресации. В этом случае кадры, исходящие из разных портов, но имеющие одинаковый DLCI будут иметь одного и того же получателя. Это упрощенный подход, который разрешает иметь 1024 DLCI в сети, так как адреса являются глобальными и не могут использоваться в другом порту. Глобальная адресация может упростить обращение к объектам в небольших сетях, однако это противоречит стандартам АNSI и ITU-Т. В частности, при использовании глобальных адресов было бы невозможно соединить частную сеть с сетью общего пользования или с другой частной сетью. Стандарты резервируют 32 DLCI для внутреннего использования сети, делая 992 DLCI доступными для использования.
Для большинства сетевых приложений размер поля DLCI десять бит вполне достаточен. Для больших сетей стандарт АNSI предусматривает биты "расширения адреса" (ЕА) в заголовке кадра. Они могутбыть установлены для увеличения заголовка до трех или четырех байт, увеличивая разрядностьDLCI и расширяя диапазон возможных адресов.
Организации, занимающиеся стандартизацией Frame Rе1ау, АNSI и ITU-Т определили стандарты для коммутируемых виртуальных каналов (SVС) в сетях Frame Rе1ау. Они определяют механизм, позволяюший устройству пользователя устанавливать (или разрывать) виртуальное соединение. Сейчас применение РVС достаточно для большинства сетевых задач, но применение SVС может оказаться важным для будущего использования в сетях общего пользования и для большинства частных сетей. Одна из наиболее важных практических задач использования SVС состоит в упрощении управления виртуальными кан алами в большой сети.
Использование постоянных виртуальных каналов означает, что все соединяющие оконечные устройства виртуальные каналы определены оператором сети. Однако активный путь трафика от узла к узлу может быть выбран из нескольких возможных. При самом примитивном подходе оператор сети должен определить на путь (и несколько дополнительных путей) от узла к узлу. Эти пути должны быть отражены в маршрутных таблицах узлов или, что менее надежно, в центральной системе управления сетью. Генерация такой таблицы отнимает достаточно много времени для обеспечения оптимальной маршрутизации в большой сети. Более эффективным является определение маршрутных таблиц автоматически системой управления сетью. Это приводит к уменьшению рабочей нагрузки оператора сети, но все же представляет недостаточно оптимальное решение.
Лучший подход состоит в том, чтобы маршрут определялся автоматически в узлах коммутации. В случае отказа канала или при последовательной перегрузке сеть должна автоматически и динамически найти лучший доступный дополнительный маршрут. В наиболее сложных подходах предполагается, что в каждом узле заложен маршрут каждого РVС, и при выборе маршрута узел способен учесть различные типы каналов (например, спутниковый, наземный, комбинированный, и т.д.) для гарантии автоматической оптимизации использования ресурсов сети для различных категорий пользователей. Архитектура сети и система управления сетью должна предоставить оператору сети способность "настроить" автоматическую маршрутизацию для соответствия потребностям сети.
Внутренний состав сети Frame Rе1ау пока не определен стандартами, но является принципиальным при построении качественных сетей связи. Эффективное функционирование сложной сети Frame Rе1ау требует, чтобы функции типа выбора РVС, предотвращения перегрузок и стратегии обработки ошибок управлялись непосредственно узлами сети автоматически и динамически. Сеть может обеспечивать гарантируемый уровень производительности пользователям посредством "измерения" трафика и использования в сети СIR и бита DЕ. Методы управления сетью включают контроль в реальном масштабе времени, статистику трафика и обширную удаленную диагностику.
1. Для чего в ISDN используется D-канал?
2. Использует ли Frame Relay механизм квитирования?
3. В каких случаях в Frame Relay удаляются кадры?
4. Какие уровни эталонной модели OSI охватывает D-канал?
5. Как работает механизм "неявное уведомление о перегрузке" в Frame Relay?
6. Какова пропускная способность (в бит/с) D-канала?
7. Сколько В-каналов содержит Т1-канал?
8. Сколько В-каналов содержит Е1-канал?
Лекция10
Функциональные устройства ISDN
ISDN применяется в коммуникациях «пользователь-пользователь» и «пользователь-сеть». Хотя модули (плоскости) ISDN выполняют функциональную роль нижних уровней модели OS1, отдельные аспекты ISDN невозможно полностью выразить в терминах данной модели. ISDN имеет отношение исключительно к сетевым операциям и, следовательно, полностью описывается нижними тремя уровнями модели OSI. Уровни 4-7 стека OSI отвечают управление соединением и за сквозное следование. В ISDN предполагается, что функции более высокого уровня реализуются участвующими в коммуникациях хост-системами. Кроме того, для определения взаимодействия над физическим уровнем В и D-каналов необходимы разные протоколы. На физическом уровне оба канала используют один и тот же интерфейс, поэтому здесь применяются одинаковые стандарты и протоколы. Выше используются разные протоколы. Фактически большинство протоколов СС1ТТ для ISDN описывают передачу пользовательских сигналов в D-канале.
Физический уровень ISDN соответствует уровню 1 модели OSI и выполняет следующие функции:
Кодирование цифровых данных
Дуплексную передачу по В-каналу
Дуплексную передачу по D-каналу
Мультиплексирование соединений ВRI и РRI
Активизацию и деактивизацию виртуального канала
Передачу питания от NТ1 на терминальные устройства
Идентификацию терминального устройства
Выделение D-канала и управление доступом
Устройства ISDN подключаются в опорных точках. Протоколы ISDN описывают характер соединения и взаимодействие, которое происходит в этих опорных точках.
Важное значение в схеме интерфейса «абонент-сеть» имеет понятие опорной точки. Опорные точки описывают взаимодействие между функциональными группами и позволяют объединить связанные функции. Взаимодействие в опорной точке определяются протоколами передачи информации с пользовательского узла ISDN в сеть ISDN.
Стандарты ISDN определяют следующие устройства или функциональные группы:
Оконечная станция типа 1 (NТ1 – network termination type 1). NT1 - это физическое оконечное устройство пользовательского интерфейса ISDN. Выполняет функции 1-го уровня OSI: физическое соединение между ISDN и устройствами пользователя, обслуживание линии и мониторинг производительности. NT1 поддерживает несколько каналов ВRI, РRI и осуществляет мультиплексирование битовых потоков с помощью разделения по времени (ТDМ).
Оконечная станция типа 2 (NT2 -– network termination type 2). В зависимости от уровня встроенной логики (интеллектуальности) реализуют средства OSI уровня 1,2 и/или 3. NТ2 используется как концентратор или коммутатор пользовательских устройств ISDN. В качестве примеров можно привести офисные АТС, шлюзы ЛВС и любые устройства с коммутацией пакетов. В небольших узлах, где ISDN -устройства подключены непосредственно к NТ1, можно обойтись без NT2.
Терминальное оборудование типа 1 (ТЕ1 -– network termination type 1). ТЕ1 - это любое ISDN -устройство конечного пользователя, применяющее протоколы ISDN и поддерживающее службы ISDN. Примерами являются телефоны ISDN, факсы ISDN, рабочие станции ISDN.
Терминальное оборудование типа 2 (ТЕ2 -– network termination type 2). ТЕ2 - это устройства конечного пользователя, несовместимые с ISDN (например аналоговые телефоны).
Терминальный адаптер (ТА –terminal adapter). Позволяет устройствам не поддерживающим ISDN (ТЕ2) взаимодействовать с ISDN.
Опорные точки.
В стандартах ISDN определяются различные соединения между устройствами. Каждый тип соединения (или интерфейс) требует конкретного протокола. Такие интерфейсы называются опорными точками.
Стандарт ISDN предусматривает 4 наиболее важные опорные. Точки ISDN: R, S, Т, U. Их можно определить следующим образом:
Опорная точка R описывает интерфейс между не поддерживающими ISDN оконечными устройствами (ТЕ2) и терминальными адаптерами (ТА).
Опорная точка S описывает интерфейс между ТЕ1 или ТА и оконечным устройством ISDN (NТ1 или NТ2).
Опорная точка Т описывает интерфейс между локальным коммутирующим устройством NТ2 и оконечным устройством абонентам (МТ1).
Опорная точка U находится между NТ1 и местной телефонной сетью (LЕ) и определяет стандарт коммуникации между ними. Стандарты СС1ТТ специфицируют устройство NТ1 как часть локальной сети и не имеют отношения к местной абонентской линии.
Кроме основных опорных точек есть дополнительные - К, L, М, N, Р опорные точки. В основном они определяют интерфейс между ISDN -сетями и не ISDN сетями.
Поддерживаемая стандартом ВRI конфигурация «точка-точка» допускают удаление устройства NТ от подключенного терминального оборудования на расстояние до 1 км. Многоточечное соединение определяется как короткая или расширенная пассивная шина. В конфигурации с короткой пассивной шиной к одной шине подключаются устройство NТ и до 8-ми ТЕ. ТЕ могут удаляться от NТ более чем на 200 м. Расширенной пассивной шиной называют группу из нескольких ТЕ, удаленных друг от друга не более чем на 50 м. Сама группа ТЕ может быть удалена от NТ на расстояние до 1 км.
В каждый момент времени В-каналы используются только одним устройством. Система сигналов «пользователь-сеть» гарантирует, что в любое время В-каналу присваивается только одно устройство ТЕ. Многоточечные конфигурации, допускаемые ВRI, должны использовать D-канал одновременно, что позволяет осуществлять обмен сообщениями между пользователем и сетью. Стандарты ВRI определяют полнодуплексный обмен. Физическое соединение между NТ и ТЕ осуществляется как минимум по 2-м парам проводников (одна пара передает в одном направлении).
Передача управляющих сигналов.
В BRI применяется псевдотроичное кодирование: "ноль" всегда представляется положительным или отрицательным напряжением, а "единица" - отсутствием напряжения. Импульсы двоичного нуля должны изменять напряжение с положительного на отрицательное. В кадре BRI используются специальные биты для балансирования напряжения в линии, обеспечивающие отсутствие в ней постоянного напряжения.
Кадры BRI представляет собой структуру с синхронным разделением времени. Это означает, что обмен данными осуществляется группами битов называемыми кадрами. Каждый кадр ВRI содержит 48 бит. Для ВRI в конфигурации 2В+D общая скорость передачи составляет 192 кбит/с. Один кадр переносит 16 бит для каждого В-канала и 4 бита для D-канала. В кадре эти биты чередуются в конкретной последовательности.
Рис. 29. Кадр ISDN
Кроме того ВRI можно конфигурировать как 1В+D и даже как один D-канал. Если применяется одна из этих дополнительных конфигураций, неиспользуемые биты кадра заполняются единицами (т.е. сигнал не передается).
Другие 12 бит кадра отвечаютза его обработкуи синхронизацию:- Е-биты. При передаче от NT к ТЕ кадр несет в себе Е-биты, повторяющие последние биты, переданные по D-каналу. Е-биты управляют доступом к NT подключенных устройств ТЕ. Так как в любой момент времени В-канал может использовать только одно устройство, никаких проблем с выделением В-канала не возникает. Все устройства должны работать через один общий D-канал (осуществляя передачу сигналов). Устройства ТЕ отслеживают Е-биты и поэтому знают, могут ли они продолжать передачу. Если передающее ТЕ получает Е-бит со значением, отличным от своего последнего D-бита, это значит, что оно больше не владеет D-каналом и поэтому прекращает передачу.
L-биты. Биты баланса постоянного напряжения в линии обеспечивает присутствие в кадре четного числа единиц, что гарантирует отсутствие в цепи постоянного напряжения. Если перед L-битом следует нечетное число нулей, он устанавливается в "ноль", а если нечетное число единиц - то в "единицу".
F-бит. Нулевой бит в начале кадра. За каждым F-битом для баланса напряжения в линии следует L-бит. Конфигурация "F-бит - L-бит" отмечает начало кадра, распознаваемое на приемном конце.
А-бит. Бит, используемый для активизации или деактивизации ТЕ.
F a -бит. Дополнительный бит кадра. Если не применяется группирование кадров, всегда устанавливается в "ноль".
S-бит. Резерв.
1 1 8 1 1 1 1 8 1 1 1 8 1 1 1 8
| F | L | В1 | L | D | L | F | L | В2 | L | D | L | В1 | L | D | L | В2 | ... |
| Пакет от ТЕ к NT |
| 1 1 8 1 1 1 1 1 8 1 1 1 8 1 1 1 8 |
| F | L | В1 | Е | D | А | F | F a | В2 | Е | D | S | В1 | Е | D | S | В2 | ... |
Пакет от NT к TE
Рис. 30. Кадры ISDN.
Е-биты помогают управлять доступом ТЕ к S или Т интерфейсу. В-каналы всегда выделяются одному устройству ТЕ, поэтому разрешать конфликты нет необходимости. При доступе к D-каналу разрешение конфликтов осуществляется следующим образом:
ТЕ не передающее данных, посылает серию двоичных единиц (отсутствие сигнала в линии).
NТ дает эхо сигнал как Е-бит со значением "единица".
ТЕ, желающие передать информацию, отслеживают Е-биты. Если ТЕ воспринимает достаточное число Е-битов со значением "единица", то предполагает, что линия свободна и передает данные.
Если ТЕ обнаруживает, что значения Е-битов отличаются от переданных им битов, оно считает, что передачу осуществляет другое устройство и не обращается к D-каналу.
В отличие от ВRI, стандарт РRI поддерживает только соединение"точка-точка".РRI определяется обычно в опорной точке Т. Кадры РRI состоят из одного F-бита плюс 1 байт информации из каждого информационного каналаРRI. Это кадры размером 193 бита (для РRI в США и Японии). Скорость - 8000 кадров в секунду. Биты оформления кадров организованы в группы кадров (multiframe). Оформляющие служебные биты используются для синхронизации, контроля кадров и служебных функций.
В ISDN на канальном уровне (уровне связи данных) для установления, поддержания и завершения соединений служит протокол LAPD. Для всех подобных операций используется D-канал. Протокол LAPD(Link Ассезз ргоtосо1 D) разработан на основе протокола HDLC. Назначение протокола LAPD состоит в подготовке и передаче информации между компонентами ISDN канального уровня.
Рис. 31. Формат кадра LAPD.
Для создания логических соединений между пользователями (ТЕ) и сетью через опорную точку S или Т в LAPD применяется D-канал. Адрес в LAPD называется идентификатором соединения уровня связи данных (DLCI - Data Link Соnnection Identifier). Адрес двухкомпонентный. Состоит из идентификатора конечной точки (ТЕI –terminal endpoint identifier), определяющего устройство и идентификатора точки доступа к службе (SАРI - service ассеcc роint identifier), определяющего процесс, который выполняется устройством на 3-м уровне. Вместе взятые ТЕI и SАР1 составляют DLCI. ТЕI присваивается динамически при включении устройства ТЕ или вручную.
Контрольные вопросы:
1. На каком уровне производится мультиплексирование соединений ВRI и РRI?
2. B и D-каналы симплексные или дуплексные?
3. Какие опорные точки существуют в ISDN?
4. Из каких компонент состоит адрес в кадре LAPD?
5. Какие функции выполняет уровень 1 в ISDN?
6. Какие типы оборудования используются в ISDN?
7. Какую функцию в ISDN выполняют биты L и E?
8. Поддерживает ли стандарт РRI многоточечное соединение?
Использование технологии АТМ
В локальных сетях технология АТМ применяется обычно на магистралях, где хорошо проявляются такие ее качества, как масштабируемая скорость, качество обслуживания, петлевидные связи (которые позволяют повысить пропускную способность и обеспечить резервирование каналов связи). Петлевидные связи поддерживаются в силу того, что АТМ - это технология с маршрутизацией пакетов, запрашивающих установление соединений, а значит, таблица маршрутизации может эти связи учесть - либо за счет ручного труда администратора, либо за счет протокола маршрутизации PNNL
Основной соперник технологии АТМ в локальных сетях - технология Gigabit Ethernet. Она превосходит АТМ в скорости передачи данных - 1000 Мбит/с, а также в затратах на единицу скорости. Там, где качество обслуживания важно (видеоконференции, трансляция телевизионных передач и т. п.), технология АТМ останется. Для объединения настольных компьютеров технология АТМ, еще долго не будет использоваться, так как здесь очень серьезную конкуренцию ей составляет технология Fast Ethernet.
В глобальных сетях АТМ применяется там, где сеть Frame Relay не справляется с большими объемами трафика, и там, где нужно обеспечить низкий уровень задержек, необходимый для передачи информации реального времени.
Сегодня основной потребитель территориальных коммутаторов АТМ - это Internet. Коммутаторы АТМ используются как гибкая среда коммутации виртуальных каналов между IP-маршрутизаторами, которые передают свой трафик в ячейках АТМ, так как виртуальный канал АТМ может динамически перераспределять свою пропускную способность между пульсирующим трафиком клиентов IP-сетей.
Достоинства АТМ:
Высокоскоростная связь;
Служба установления логического соединения, подобно традиционной телефонии;
Быстрая аппаратная коммутация;
Единый универсальный сетевой транспорт;
В одном сетевом подключении можно смешивать данные разных типов;
гибкое и эффективное распределение ширины полосы пропускания сети.
Сети Frame Relay - новые сети, которые лучше подходят для передачи пульсирующего трафика локальных сетей по сравнению с сетями Х.25, это преимущество проявляется только тогда, когда каналы связи приближаются по качеству к каналам локальных сетей, а для глобальных каналов такое качество обычно достижимо только при использовании волоконно-оптических кабелей.
Преимущество сетей Frame Relay заключается в их низкой протокольной избыточности и дейтаграммном режиме работы, что обеспечивает высокую пропускную способность и небольшие задержки кадров. Надежную передачу кадров технология Frame Relay не обеспечивает. Сети Frame Relay специально разрабатывались как общественные сети для соединения частных локальных сетей. Они обеспечивают скорость передачи данных до 2 Мбит/с.
Особенностью технологии Frame Relay является гарантированная поддержка основных показателей качества транспортного обслуживания локальных сетей - средней скорости передачи данных по виртуальному каналу при допустимых пульсациях трафика.
Технология Frame Relay (ретрансляция кадров) ориентирована на использование в сетях с коммутацией пакетов. Сама технология охватывает только физический и канальный уровень. Сетью Frame Relay принято считать любую сеть, использующую на нижних двух уровнях управления одноименную технологию. Основное отличие Frame Relay от Х.25 - в механизме обеспечения достоверности информации.
Технология FR разрабатывалась с учетом высоких скоростей передачи данных и низкого уровня ошибок в современных сетях. Сеть Frame Relay ориентирована на хорошие цифровые каналы передачи информации и в ней отсутствует проверка выполнения соединения между узлами и контроль достоверности информации (контроль за появлением ошибок) на канальном уровне, а именно на этом уровне в FR выполняется мультиплексирование потока данных в кадры. Каждый кадр канального уровня содержит заголовок, который используется для маршрутизации трафика. Контроль достоверности передачи осуществляется на верхних уровнях модели. При обнаружении ошибки повторная передача кадра не производится, а искаженный кадр просто выбрасывается.
Таким образом, в сети Frame Relay обеспечивается гарантированная согласованная скорость передачи информации.
Основу Frame Relay составляют виртуальные каналы (virtual circuits). Виртуальный канал в сети Frame Relay представляет собой логическое соединение, создаваемое между двумя устройствами передачи данных в сети Frame Relay.
В сети Frame Relay используется два типа виртуальных каналов - коммутируемые (SVC) и постоянные (РVС). Процесс передачи данных с использованием SVC состоит из четырех последовательных фаз:
Установление вызова (Call Setup) - на этом этапе создается виртуальное соединение между двумя DTE;
Передача данных (Data Transfer) - непосредственная передача данных;
Ожидание (Idle) - передача данных через уже существующее виртуальное соединение не производится; если период ожидания превысит установленное значение, соединение может быть завершено автоматически;
Завершение вызова (Call Termination) - выполняются операции, необходимые для завершения соединения.
Постоянные каналы представляют собой постоянное соединение, обеспечивающее информационный обмен между двумя передающими - устройствами. Процесс передачи данных по каналу PVC имеет всего две фазы: передача данных и ожидания.
Для обозначения виртуальных каналов в сети Frame Relay используются идентификаторы DLCI определяющие номер виртуального порта для процесса пользователя.
В технологии Frame Relay используются протоколы только на физическом и канальном уровнях.
Протокол канального уровня LAP-F в сетях Frame Relay имеет два режима работы – основной (core) и управляющий (control). В основном режиме, кадры передаются без преобразования и контроля, как и в коммутаторах локальных сетей. За счет этого сети Frame Relay обладают весьма высокой производительностью, так как кадры в коммутаторах не подвергаются преобразованию, а сеть не передает квитанции подтверждения между коммутаторами на каждый пользовательский кадр. Пульсации трафика передаются сетью Frame Relay достаточно быстро и без больших задержек.
При таком подходе уменьшаются накладные расходы при передаче пакетов локальных сетей, так как они вкладываются сразу в кадры канального уровня.
Кадр протокола Frame Relay содержит минимально необходимое количество служебных полей. Его формат, реализованный в соответствии с протоколом HDLC. В поле заголовка кадра размещается информация, используемая для управления виртуальными соединениями и процессами передачи данных в сети (в частности, поле адреса, содержащее адреса сетевых узлов источника и получателя кадра).
Поле данных в кадре Frame Relay имеет переменную длину (но не более 8000 байт, большинство сетей Frame Relay использует кадры длиной 1024 байт) и предназначено для переноса блоков данных протоколов верхних уровней. Поле FCS содержит 16-разрядную контрольную сумму всех полей кадра Frame Relay, за исключением поля «флаг».
Проверка достоверности преобразования информации в сетях Frame Relay выполняется на верхних уровнях управления, искаженные кадры не корректируют, а просто выбрасывают.
Поддержка «качества обслуживания» обеспечивается выполнением Заказа качества обслуживания, в котором указывается согласованная скорость передачи данных (Committed Information Rate) и некоторые дополнительные параметры: гарантируемый объем передаваемых данных и не гарантируемый объем передаваемых данных. Если пользователь сам нарушает согласованную скорость ввода информации в сеть, кадр с такой информацией получает низший приоритет обслуживания и ему не гарантируется «качество обслуживания», он может быть даже выброшен из сети в случае перегрузки последней.
