Услуги и технологии пакетных уровней

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

На сетевом уровне сегодня применяется лишь протокол IP, все остальные (такие как IPX или DECnet) благодаря успехам Интернета сошли со сцены. IP является обязательным протоколом, так как он нужен оператору связи/поставщику услуг Интернета как для предоставления доступа в Интернет своим клиентам, так и для взаимодействия с сетями других операторов связи/поставщиков услуг.

Более сложная ситуация наблюдается на канальном уровне. Как видно из рис. 19.4, здесь могут использоваться разные технологии (на рисунке они объединены в два прямоуголь­ника разной высоты, что символизирует свойства двух групп технологий канального уров­ня). Первая группа технологий, в которую входят технологии ATM, Frame Relay, MPLS и Carrier Ethernet, отличается тем, что с их помощью можно построить сеть, выполняющую коммутацию пакетов (кадров, ячеек — термины могут быть разными, но суть в том, что эти технологии подразумевают наличие коммутаторов, способных продвигать данные на основе адресной информации той или иной технологии).

Главной особенностью технологий второй группы, в которую входят протоколы HDLC и РРР, является то, что эти технологии предназначены для работы на двухточечных соединениях. Это означает, что они могут передавать данные только между двумя непо­средственно соединенными интерфейсами, но не далее. В этих технологиях не исполь­зуются уникальные адреса конечных узлов, так как их задача очень проста — передача кадра непосредственному соседу Можно сказать, что это технологии интерфейсов, так как они действительно реализуются в интерфейсах маршрутизаторов или конечных узлов — компьютеров. При этом задачу коммутации пакетов решает маршрутизатор на основе IP-адресов, а интерфейсная технология требуется только для доставки IP-пакета соседнему маршрутизатору. Меньшая высота прямоугольника отражает более бедную функциональ­ность этой группы протоколов.

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

Рис. 19.5. Использование канального уровня для организации соединений между маршрутизаторами

 

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

Рис. 19.6. Соединение маршрутизаторов через четыре виртуальных канала

 

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

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

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

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

В том случае, когда на канальном уровне работают технологии второй группы, то есть HDLC или РРР, трафик пользователя может коммутироваться только IP-маршрутизаторами^[62], так как в сети нет других устройств, работающих по принципу коммутации пакетов. Такой также встречающийся вариант организации сети оператора связи упрощает сеть, так как устраняет целый слой коммутаторов канального уровня, и это — весьма положительный фактор. Однако в этом случае оказание услуг виртуальных частных сетей оператором связи усложняется, так как уровень IP с его дейтаграммным способом передачи данных не очень хорошо подходит для решения этой задачи. Здесь нет противоречия с популярно­стью сервиса VPN протокола IP, так как в большинстве случаев этот сервис организуется силами самих пользователей; для поставщика услуг Интернета трафик такого сервиса не отличим от обычного трафика IP, так что никаких усилий по его поддержанию провайдеру прикладывать не нужно. Однако столь высоких характеристик в плане гарантии пропуск­ной способности соединений VPN, которые могут быть достигнуты в случае реализации сервиса провайдером на канальном уровне, пользовательский сервис VPN достигнуть не может.

Пакетные слои могут взаимодействовать с различными слоями первичной сети для полу­чения физических соединений между маршрутизаторами или коммутаторами. Совсем не обязательно взаимодействовать с самым верхним слоем первичной сети, например со слоем PDH или SDH. В том случае, когда маршрутизаторам или коммутаторам необходимы высокоскоростные соединения, можно их организовывать с помощью нижних слоев пер­вичной сети, например, с помощью слоя DWDM (мы уже упоминали о маршрутизаторах, поддерживающих интерфейсы DWDM).

Анализ услуг и организации слоев сети оператора связи с коммутацией пакетов дает воз­можность сформулировать основные требования к протоколам этих уровней:

§ поддержка протокола IP и протоколов маршрутизации стека TCP/IP (OSPF, IS-IS для организации собственной сети и BGP для «встраивания» в Интернет);

§ поддержка услуг виртуальных частных сетей силами провайдера;

§ интеграция канального уровня с уровнем IP для уменьшения сложности сети;

§ интеграция с технологиями первичных сетей.

Туннелирование

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

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

Данное описание подходит к стандартной схеме, описанной в модели OSI, если под про­токолом объединяемых сетей понимать протокол IP, а под протоколом транзитной сети — любой протокол канального уровня, например Ethernet. Действительно, IP-пакеты могут инкапсулироваться на границе сети в кадры Ethernet и передаваться в этих кадрах через транзитную сеть Ethernet в неизменном виде. А при выходе из транзитной сети IP-пакеты извлекаются из кадров Ethernet и дальше уже обрабатываются маршрутизатором.

Для того чтобы понять, в чем нестандартность инкапсуляции, сначала заметим, что в этом процессе принимают участие три типа протоколов:

§ протокол-пассажир;

§ несущий протокол;

§ протокол инкапсуляции.

При стандартной работе составной сети, описанной в модели OSI (и повсеместно приме­няемой на практике), протоколом-«пассажиром» является протокол IP, а несущим прото­колом — один из протоколов канального уровня отдельных сетей, входящих в составную сеть, например Frame Relay или Ethernet. Протоколом инкапсуляции также является протокол IP, для которого функции инкапсуляции описаны в стандартах RFC для каждой существующей технологии канального уровня.

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

На рис. 19.7 показан пример сети, в которой трафик сетей Frame Relay передается по тунне­лю через транзитную IP-сеть, канальный уровень которой эту технологию не поддерживает, так как построен на технологии Ethernet.

Рис. 19.7. Туннелирование трафика Frame Relay через IP-сеть

 

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

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

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

В связи с популярностью Интернета и стека TCP/IP ситуация, когда несущим протоколом транзитной сети обычно выступает протокол IP, а протоколом-пассажиром — некоторый канальный протокол, является очень распространенной. Вместе с тем применяются и другие схемы инкапсуляции, такие как инкапсуляция IP в IP, Ethernet в MPLS, Ethernet в Ethernet. Подобные схемы инкапсуляции нужны не только для того, чтобы согласовать транспортные протоколы, но и для других целей, например для шифрования исходного трафика или для изоляции адресного пространства транзитной сети провайдера от адрес­ного пространства пользовательских сетей.

Технология Frame Relay

История стандарта

Пакетная технология глобальных сетей Frame Relay появилась в конце 80-х годов в связи с распространением высокоскоростных и надежных цифровых каналов технологий PDH и SDH. До этого основной технологией глобальных сетей являлась технология Х.25, слож­ный стек которой был рассчитан на низкоскоростные аналоговые каналы, отличавшиеся к тому же высоким уровнем помех и, следовательно, ошибок в передаче данных. Особенно­стью Frame Relay является простота; освободившись от многих ненужных в современном телекоммуникационном мире функций, эта технология предоставляет только тот минимум услуг, который необходим для доставки кадров адресату. Вместе с тем разработчики техно­логии Frame Relay сделали важный шаг вперед, предоставив пользователям сети гарантию пропускной способности сетевых соединений — свойство, которое до появления Frame Relay технологии пакетных сетей стандартным способом не поддерживали.

Техника продвижения кадров

Технология Frame Relay основана на использовании техники виртуальных каналов, которую мы кратко рассмотрели в главе 3. Техника виртуальных каналов является ком­промиссом между неопределенностью дейтаграммного способа продвижения пакетов, ис­пользуемого, например, в сетях Ethernet и IP, и жесткостью коммутации каналов, которая свойственна технологиям первичных и телефонных сетей.

Рассмотрим технику виртуальных каналов сетей Frame Relay на примере сети, изобра­женной на рис. 19.8.

Рис. 19.8. Продвижение кадров вдоль виртуальных каналов FR

 

Для того чтобы конечные узлы сети — компьютеры С1, С2, СЗ и сервер С4 — могли обме­ниваться данными, в сети необходимо предварительно проложить виртуальные каналы. В нашем примере установлено три таких канала — между компьютерами С 1 и С2 через коммутатор S1; между компьютером С\ и сервером С4 через коммутаторы S1 и S2; между компьютером СЗ и сервером С4 через коммутатор S2.

Виртуальные каналы Frame Relay могут быть как однонаправленными (то есть способными передавать кадры только в одном направлении), так и двунаправленными.

Будем считать, что в примере на рис. 19.8 установлены двунаправленные каналы. Процедура установления виртуальных каналов Frame Relay заключается в формировании таблиц коммутации в коммутаторах сети. Такие процедуры могут выполняться как вруч­ную, так и системами управления сетью.

Виртуальные каналы Frame Relay относятся к типу постоянных виртуальных каналов (Permanent Virtual Circuit, PVC), они заранее устанавливаются по командам оператора сети.

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

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

§ номер входного порта канала;

§ входная метка канала в поступающих на входной порт пакетах;

§ номер выходного порта;

§ выходная метка канала в передаваемых через выходной порт пакетах.

Например, вторая запись в таблице коммутации коммутатора S 1 (запись 1-102-3-106) означает, что все пакеты, которые поступят на порт 1 с идентификатором виртуального канала 102, будут продвигаться на порт 3, а в поле идентификатора виртуального канала появится новое значение — 106. Так как виртуальные каналы в нашем примере двунаправ­ленные, то для каждого канала в таблице коммутации должно существовать две записи, описывающие преобразование метки в каждом из направлений. Так, для записи 1-102-3-106 существует запись 3-106-1-102.

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

Комбинации «метка-порт» должны быть уникальными в пределах одного коммутатора.

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

Метка виртуального канала является локальным адресом этого канала, формально мет­ка FR имеет название DLCI (Data Link Connection Identifier — идентификатор соединения уровня канала данных).

Метки DLCI переносятся кадрами FR; формат такого кадра показан на рис. 19.9.

Рис. 19.9. Формат кадра FR

 

Поле DLCI состоит из 10 бит, что позволяет задействовать до 1024 виртуальных соедине­ний. Поле DLCI может занимать и большее число разрядов — этим управляют признаки расширения адреса EA0 и ЕА1 (аббревиатура ЕА как раз и означает Extended Address, то есть расширенный адрес). Если бит расширения адреса установлен в ноль, то признак на­зывается EA0 и означает, что в следующем байте имеется продолжение поля адреса, а если бит расширения адреса равен 1, то поле называется ЕА1 и означает окончание поля адреса. Десятиразрядный формат DLCI является основным, но при использовании трех байтов для адресации поле DLCI имеет длину 16 бит, а при использовании четырех байтов — 23 бита. Поле данных может иметь размер до 4056 байт.

Поле C/R переносит признак команды (Command) или ответа (Response). Этот признак является унаследованным от протоколов Х.25 и в операциях FR не используется.

Поля DE (Discard Eligibility), FECN (Forward-explicit congestion notification) и BECN (Backward-explicit congestion notification) используются протоколом FR для оповещения коммутаторов сети FR о возможности отбрасывания кадров (DE), а также о перегрузке в сети (FECN и BECN).

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

Для этого администратор сети должен для каждого конечного узла создать статические записи таблицы ARP, В каждой такой записи устанавливается соответствие между IP- адресом узла назначения и начальным значением метки виртуального канала, ведущего к этому узлу. Например, в таблице ARP компьютера С1 должна присутствовать запись, отображающая IP-адрес сервера С4 на метку 102 для виртуального канала, ведущего к серверу С4.

Давайте сейчас проследим путь одного кадра, отправленного компьютером С 1 серверу С4. При отправлении кадра (этап 1 на рис. 19.8) компьютер помещает в поле адреса начальное значение метки 102, взятое из его таблицы ARP.

Коммутатор S 1, получив на порт 1 кадр с меткой 102, просматривает свою таблицу ком­мутации и находит, что такой кадр должен быть переправлен на порт 3, а значение метки в нем должно быть заменено на 106.

ПРИМЕЧАНИЕ

Операция по замене метки (label swapping) характерна для всех технологий, использующих технику виртуальных каналов. Может возникнуть законный вопрос: «А зачем менять значение метки на каждом коммутаторе? Почему бы не назначить каждому виртуальному каналу одно неизменяемое значение метки, которая бы играла роль физического адреса узла назначения?» Ответ состоит в том, что в первом случае уникальность меток достаточно обеспечивать в пределах каждого отдельного порта, а во втором — в пределах всей сети, что гораздо сложнее, так как требует наличия в сети цен­трализованной службы назначения меток.

В результате действий коммутатора S1 кадр отправляется через порт 3 к коммутатору S2 (этап 2). Коммутатор S2, используя свою таблицу коммутации, находит соответствующую запись, заменяет значение метки на 117 и отправляет кадр узлу назначения — серверу С4. На этом обмен заканчивается, а при отправке ответа сервер С4 задействует метку 117 как адрес виртуального канала, ведущего к компьютеру С 1.

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