Компьютерные сети

Компьютерные сети

Н. Олифер

□ Услуга выделенного соединения по протоколу OTN, SDH или PDH. Это наиболее традиционная услуга оператора связи, когда пользователь берет в аренду выделенные каналы нужной ему скорости, например каналы со скоростями 34 (ЕЗ) и 622 Мбит/с (STM-4). Эти каналы соединяют географически разнесенные локальные сети предприятия, и на них пользователь строит свою корпоративную компьютерную сеть (напомним, что она называется в таком случае частной), соединяя этими каналами свои 1Р-маршртизаторы или FR-коммутаторы. В последнее время стала популярной такая услуга, как выделенный канал на 1 Гбит/с с интерфейсом Ethernet. Как вы знаете, скорость 1 Гбит/с не является стандартной для технологий первичных сетей, однако монополия Ethernet в локальных сетях привела к ситуации, когда выделенные каналы все чаще служат для соединения пограничных устройств клиентов с интерфейсами Ethernet. Поэтому появление такой услуги, как канал со скоростью 1 Гбит/с, явилось ответом на потребности пользователей, при этом пограничный мультиплексор SDH или OTN оснащается интерфейсом Ethernet, а принимаемые кадры Ethernet затем упаковываются мультиплексором в кадры SDH или OTN и отправляются по соединению сети SDH или OTN, арендованному пользователем (также могут применяться кадры GFP, получаемые универсальным методом кадрирования, а в сетях SDH еще и методы мультплексирования VCAT, позволяющие более эффективно расходовать емкость контейнеров).

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

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

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

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

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

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

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

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

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

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

В том случае, когда на канальном уровне работают технологии второй группы, то есть HDLC или РРР, трафик пользователя может коммутироваться только IP-маршрутизаторами
67

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

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

Анализ услуг и организации слоев сети оператора связи с коммутацией пакетов дает возможность сформулировать основные требования к протоколам этих уровней:
□ поддержка протокола IP и протоколов маршрутизации стека TCP/IP (OSPF, IS-IS для организации собственной сети и BGP для «встраивания» в Интернет);
□ поддержка услуг виртуальных частных сетей силами провайдера;
□ интеграция канального уровня с уровнем IP для уменьшения сложности сети;
□ интеграция с технологиями первичных сетей.

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

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

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

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

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

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

Таким образом, протоколом-пассажиром является протокол 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.
ARP-таблица С1
103
ip
Метка
IP-C4
102
IP-C2
101
02

Таблица коммутации S2
Входнойпорт
Входнаяметка
Выходнойпорт
Выходнаяметка
1
106
4
117
4
117
1
106
2
102
4
101
4
101
2
102

1
Порт 2
С1 102
Порт 1
S1
з. . _7Г. 177Г
ПортЗ 106
х
Порт 4
Таблица коммутации S1
s'
Входнойпорт
Входнаяметка
Выходнойпорт
Выходнаяметка
1
101
2
103
1
102
3
106
2
103
1
101
V.
3
106
1
102
СЗ

Рис. 19.8. Продвижение кадров вдоль виртуальных каналов FR
Для того чтобы конечные узлы сети — компьютеры С1, С2, СЗ и сервер С4 — могли обмениваться данными, в сети необходимо предварительно проложить виртуальные каналы. В нашем примере установлено три таких канала — между компьютерами С1 и С2 через коммутатор 51; между компьютером С1 и сервером С4 через коммутаторы 51 и 52; между компьютером СЗ и сервером С4 через коммутатор 52.

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

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

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

Например, вторая запись в таблице коммутации коммутатора 51 (запись 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.
Коммутатор 51, получив на порт 1 кадр с меткой 102, просматривает свою таблицу коммутации и находит, что такой кадр должен быть переправлен на порт 3, а значение метки в нем должно быть заменено на 106.
ПРИМЕЧАНИЕ-

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

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

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


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

Report Page