|
Internetworking Technology Overview.
Библиографическая справкаFrame Relay первоначально замышлялся как протокол для использования в интерфейсах ISDN, и исходные предложения, представленные в CCITT в 1984 г., преследовали эту цель. Была также предпринята работа над Frame Relay в аккредитованном ANSI комитете по стандартам T1S1 в США. Крупное событие в истории Frame Relay произошло в 1990 г., когда Cisco Systems, StrataCom, Northern Telecom и Digital Equipment Corporation образовали консорциум, чтобы сосредоточить усилия на разработке технологии Frame Relay и ускорить появление изделий Frame Relay, обеспечивающих взаимодействие сетей. Консорциум разработал спецификацию, отвечающую требованиям базового протокола Frame Relay, рассмотренного в T1S1 и CCITT; однако он расширил ее, включив характеристики, обеспечивающие дополнительные возможности для комплексных окружений межсетевого об'единения. Эти дополнения к Frame Relay называют обобщенно local management interface (LMI) (интерфейс управления локальной сетью). Основы технологииFrame Relay обеспечивает возможность передачи данных с коммутацией пакетов через интерфейс между устройствами пользователя (например, маршрутизаторами, мостами, главными вычислительными машинами) и оборудованием сети (например, переключающими узлами). Устройства пользователя часто называют терминальным оборудованием (DTE), в то время как сетевое оборудование, которое обеспечивает согласование с DTE, часто называют устройством завершения работы информационной цепи (DCE). Сеть, обеспечивающая интерфейс Frame Relay, может быть либо общедоступная сеть передачи данных и использованием несущей, либо сеть с оборудованием, находящимся в частном владении, которая обслуживает отдельное предприятие. В роли сетевого интерфейса, Frame Relay является таким же типом протокола, что и Х.25 (смотри Главу 13 "Х.25"). Однако Frame Relay значительно отличается от Х.25 по своим функциональным возможностям и по формату. В частности, Frame Relay является протоколом для линии с большим потоком информации, обеспечивая более высокую производительность и эффективность. В роли интерфейса между оборудованием пользователя и сети, Frame Relay обеспечивает средства для мультиплексирования большого числа логических информационных диалогов (называемых виртуальными цепями) через один физический канал передачи, которое выполняется с помощью статистики. Это отличает его от систем, использующих только технику временного мультиплексирования (TDM) для поддержания множества информационных потоков. Статистическое мультиплексирование Frame Relay обеспечивает более гибкое и эффективное использование доступной полосы пропускания. Оно может использоваться без применения техники TDM или как дополнительное средство для каналов, уже снабженных системами TDM. Другой важной характеристикой Frame Relay является то, что она использует новейшие достижения технологии передачи глобальных сетей. Более ранние протоколы WAN, такие как Х.25, были разработаны в то время, когда преобладали аналоговые системы передачи данных и медные носители. Эти каналы передачи данных значительно менее надежны, чем доступные сегодня каналы с волоконно-оптическим носителем и цифровой передачей данных. В таких каналах передачи данных протоколы канального уровня могут предшествовать требующим значительных временных затрат алгоритмам исправления ошибок, оставляя это для выполнения на более высоких уровнях протокола. Следовательно, возможны большие производительность и эффективность без ущерба для целостности информации. Именно эта цель преследовалась при разработке Frame Relay. Он включает в себя алгоритм проверки при помощи циклического избыточного кода (CRC) для обнаружения испорченных битов (из-за чего данные могут быть отвергнуты), но в нем отсутствуют какие-либо механизмы для корректирования испорченных данных средствами протокола (например, путем повторной их передачи на данном уровне протокола). Другим различием между Frame Relay и Х.25 является отсутствие явно выраженного управления потоком для каждой виртуальной цепи. В настоящее время, когда большинство протоколов высших уровней эффективно выполняют свои собственные алгоритмы управления потоком, необходимость в этой функциональной возможности на канальном уровне уменьшилась. Таким образом, Frame Relay не включает явно выраженных процедур управления потоком, которые являются избыточными для этих процедур в высших уровнях. Вместо этого предусмотрены очень простые механизмы уведомления о перегрузках, позволяющие сети информировать какое-либо устройство пользователя о том, что ресурсы сети находятся близко к состоянию перегрузки. Такое уведомление может предупредить протоколы высших уровней о том, что может понадобиться управление потоком. Стандарты Current Frame Relay адресованы перманентным виртуальным цепям (PVC), определение конфигурации которых и управление осуществляется административным путем в сети Frame Relay. Был также предложен и другой тип виртуальных цепей - коммутируемые виртуальные цепи (SVC). Протокол ISDN предложен в качестве средства сообщения между DTE и DCE для динамичной организации, завершения и управления цепями SVC. Подробная информацию о ISDN дана в Главе 11 "ISDN". Как T1S1, так и CCITT ведут работу по включению SVС в стандарты Frame Relay. Дополнения LMIПомимо базовых функций передачи данных протокола Frame Relay, спецификация консорциума Frame Relay включает дополнения LMI, которые делают задачу поддержания крупных межсетей более легкой. Некоторые из дополнений LMI называют "общими"; считается, что они могут быть реализованы всеми, кто взял на вооружение эту спецификацию. Другие функции LMI называют "факультативными". Ниже приводится следующая краткая сводка о дополнениях LMI:
Форматы блока данныхФормат блока данных изображен на Рис. 14-1. Флаги ( flags ) ограничивают начало и конец блока данных. За открывающими флагами следуют два байта адресной ( address ) информации. 10 битов из этих двух байтов составляют идентификацию (ID) фактической цепи (называемую сокращенно DLCI от "data link connection identifier").
Центром заголовка Frame Relay является 10-битовое значение DLCI. Оно идентифицирует ту логическую связь, которая мультиплексируется в физический канал. В базовом режиме адресации (т.е. не расширенном дополнениями LMI), DLCI имеет логическое значение; это означает, что конечные усторойства на двух противоположных концах связи могут использовать различные DLCI для обращения к одной и той же связи. На рис. 14-2 представлен пример использования DLCI при адресации в соответствии с нерасширенным Frame Relay.
Рис. 14-2 предполагает наличие двух цепей PVC: одна между Aтлантой и Лос-Анджелесом, и вторая между Сан Хосе и Питтсбургом. Лос Анджелес может обращаться к своей PVC с Атлантой, используя DLCI=12, в то время как Атланта обращается к этой же самой PVC, используя DLCI=82. Аналогично, Сан Хосе может обращаться к своей PVC с Питтсбургом, используя DLCI=62. Сеть использует внутренние патентованные механизмы поддержания двух логически значимых идентификаторов PVC различными. В конце каждого байта DLCI находится бит расширенного адреса (ЕА). Если этот бит единица, то текущий байт является последним байтом DLCI. В настоящее время все реализации используют двубайтовый DLCI, но присутствие битов ЕА означает, что может быть достигнуто соглашение об использовании в будущем более длинных DLCI. Бит C/R, следующий за самым значащим байтом DLCI, в настоящее время не используется. И наконец, три бита в двубайтовом DLCI являются полями, связанными с управлением перегрузкой. Бит "Уведомления о явно выраженной перегрузке в прямом направлении" (FECN) устанавливается сетью Frame Relay в блоке данных для того, чтобы сообщить DTE, принимающему этот блок данных, что на тракте от источника до места назначения имела место перегрузка. Бит "Уведомления о явно выраженной прегрузке в обратном направлении" (BECN) устанавливается сетью Frame Relay в блоках данных, перемещающихся в направлении, противоположном тому, в котором перемещаются блоки данных, встретившие перегруженный тракт. Суть этих битов заключается в том, что показания FECN или BECN могут быть продвинуты в какой-нибудь протокол высшего уровня, который может предпринять соответствующие действия по управлению потоком. (Биты FECN полезны для протоколов высших уровней, которые используют управление потоком, контролируемым пользователем, в то время как биты BECN являются значащими для тех протоколов, которые зависят от управления потоком, контролируемым источником ("emitter-controlled"). Бит "приемлемости отбрасывания" (DE) устанавливается DTE, чтобы сообщить сети Frame Relay о том, что какой-нибудь блок данных имеет более низшее значение, чем другие блоки данных и должен быть отвергнут раньше других блоков данных в том случае, если сеть начинает испытывать недостаток в ресурсах. Т.е. он представляет собой очень простой механизм приоритетов. Этот бит обычно устанавливается только в том случае, когда сеть перегружена. Формат сообщений LMIВ предыдущем разделе описан базовый формат протокола Frame Relay для переноса блоков данных пользователя. Разработанная консорциумом спецификация Frame Relay также включает процедуры LMI. Сообщения LMI отправляются в блоках данных, которые характеризуются DLCI, специфичным для LMI (определенным в спецификации консорциума как DLCI=1023). Формат сообщений LMI представлен на Рис. 14-3.
В сообщениях LMI заголовок базового протокола такой же, как в обычных блоках данных. Фактическое сообщение LMI начинается с четырех мандатных байтов, за которыми следует переменное число информационных элементов (IE). Формат и кодирование сообщений LMI базируются на стандарте ANSI T1S1. Первый из мандатных байтов (unnumbered information indicator-индикатор непронумерованной информации) имеет тот же самый формат, что и индикатор блока непронумерованной информации LAPB (UI) с битом P/F, установленным на нуль. Подробная информация о LAPB дается в разделе "Уровень 2" Главы 13 "Х.25". Следующий байт называют "дискриминатор протокола" (protocol discriminator); он установлен на величину, которая указывает на "LMI". Третий мандатный байт (call reference-ссылка на обращение) всегда заполнен нулями. Последний мандатный байт является полем "типа сообщения" (message type). Определены два типа сообщений. Сообщения "запрос о состоянии" (status enquiry) позволяют устройствам пользователя делать запросы о состоянии сети. Сообщения "состояние" (status) являются ответом на сообщения-запросы о состоянии. Сообщения "продолжайте работать" (keepalives) (посылаемые через линию связи для подтверждения того, что обе стороны должны продолжать считать связь действующей) и сообщения о состоянии PVC являются примерами таких сообщений; это общие свойства LMI, которые должны быть частью любой реализации, соответствующей спецификации консорциума. Сообщения о состоянии и запросы о состоянии совместно обеспечивают проверку целостности логического и физического каналов. Эта информация является критичной для окружений маршрутизации, т.к. алгоритмы маршрутизации принимают решения, которые базируются на целостности канала. За полем типа сообщений следуют несколько IЕ. Каждое IЕ состоит из одно-байтового идентификатора IЕ, поля длины IЕ и одного или более байтов, содержащих фактическую информацию. В дополнение к общим характеристикам LMI существуют несколько факультативных дополнений LMI, которые чрезвычайно полезны в окружении межсетевого об'единения. Первым важным факультативным дополнением LMI является глобольная адресация. Как уже отмечалось раньше, базовая (недополненная) спецификация Frame Relay обеспечивает только значения поля DLCI, которые идентифицируют цепи PVC с локальным значением. В этом случае отсутствуют адреса, которые идентифицируют сетевые интерфейсы или узлы, подсоединенные к этим интерфейсам. Т.к. эти адреса не существуют, они не могут быть обнаружены с помощью традиционной техники обнаружения и резолюции адреса. Это означает, что при нормальной адресации Frame Relay должны быть составлены статистические карты, чтобы сообщать маршрутизаторам, какие DLCI использовать для обнаружения отдаленного устройства и связанного с ним межсетевого адреса. Дополнение в виде глобальной адресации позволяет использовать идентификаторы узлов. При использовании этого дополнения значения, вставленные в поле DLCI блока данных, являются глобально значимыми адресами индивидуальных устройств конечного пользователя (например, маршрутизаторов). Реализация данного принципа представлена на Рис.14-4.
Необходимо отметить, что каждый интерфейс, изображенный на Рис.14-4, имеет свой собственный идентификатор. Предположим, что Питтсбург должен отправить блок данных в Сан Хосе. Идентификатором Сан Хосе является число 12, поэтому Питттсбург помещает величину "12" в поле DLCI и отправляет блок данных в сеть Frame Relay. В точке выхода из сети содержимое поля DLSI изменяется сетью на 13, чтобы отразить узел источника блока данных. Т.К. интерфейс каждого маршрутизатора имеет индивидуальную величину, как у идентификатора его узла, отдельные устройства могут быть различимы. Это обеспечивает адаптируемую маршрутизацию в сложных окружениях. Глобальная адресация обеспечивает значительные преимущества в крупных комплексных об'единенных сетях, т.к. в этом случае маршрутизаторы воспринимают сеть Frame Relay на ее периферии как обычную LAN. Нет никакой необходимости изменять протоколы высших уровней для того, чтобы использовать все преимущества, обеспечиваемые их возможностями.
Другой ценной факультативной характеристикой LMI является многопунктовая адресация. Группы многопунктовой адресации обозначаются последовательностью из четырех зарезервированных значений DLCI (от 1019 до 1022). Блоки данных, отправляемые каким-либо устройством, использующим один из этих зарезервированных DLCI, тиражирутся сетью и отправляются во все выходные точки группы с данным обозначением. Дополнение о многопунктовой адресации определяет также сообщения LMI, которые уведомляют устройства пользователя о дополнении, ликвидации и наличиии групп с многопунктовой адресацией. В сетях, использующих преимущества динамической маршрутизации, маршрутная информация должна обмениваться между большим числом маршрутизаторов. Маршрутные сообщения могут быть эффективно отправлены путем использования блоков данных с DLCI многопунктовой адресации. Это обеспечивает отправку сообщений в конкретные группы маршрутизаторов. Реализация сетиFrame Relay может быть использована в качестве интерфейса к услугам либо общедоступной сети со своей несущей, либо сети с оборудованием, находящимся в частном владении. Обычным способом реализации частной сети является дополнение традиционных мультиплексоров Т1 интерфейсами Frame Relay для информационных устройств, а также интерфейсами (не являющимися специализированными интерфейсами Frame Relay) для других прикладных задач, таких как передача голоса и проведение видео-телеконференций. На Рис. 14-5 "Гибридная сеть Frame Relay" представлена такая конфигурация сети.
Обслуживание общедоступной сетью Frame Relay разворачивается путем размещения коммутирующего оборудования Frame Relay в центральных офисах (CO) телекоммуникационной линии. В этом случае пользователи могут реализовать экономические выгоды от тарифов начислений за пользование услугами, чувствительных к трафику, и освобождены от работы по администрированию, поддержанию и обслуживанию оборудования сети. Для любого типа сети линии, подключающие устройства пользователя к оборудованию сети, могут работать на скорости, выбранной из широкого диапазона скоростей передачи информации. Типичными являются скорости в диапазоне от 56 Kb/сек до 2 Mb/сек, хотя технология Frame Relay может обеспечивать также и более низкие и более высокие скорости. Ожидается, что в скором времени будут доступны реализации, способные оперировать каналами связи с пропускной способностью свыше 45 Mb/сек (DS3). Как в общедоступной, так и в частной сети факт обеспечения устройств пользователя интерфейсами Frame Relay не является обязательным условием того, что между сетевыми устройствами используется протокол Frame Relay. В настоящее время не существует стандартов на оборудование межсоединений внутри сети Frame Relay. Таким образом, могут быть использованы традиционные технологии коммутации цепей, коммутации пакетов, или гибридные методы, комбинирующие эти технологии. Данный документ подготовлен для HTML версии Владимиром Плешаковым. Версия: 0.1 Vladimir V. Pleshakov , [email protected]. |
|||||||||||||||||
With any suggestions or questions please feel free to contact us |