Виртуальные каналы в сетях с коммутацией пакетов.
B сетях с коммутацией пакетов сегодня используются два класса механизмов продвижения пакетов — дейтаграммная передача и виртуальные каналы. И тот, и другой реализуются протоколами канального и сетевого уровня модели OSI. Примерами протоколов с применением дейтаграммного механизма продвижения могут служить Ethernet, IP и IPX. С помощью виртуальных каналов данные передаются в сетях X.25, frame relay и ATM. Этот урок посвящен базовым принципам техники виртуальных каналов, ее преимуществам и недостаткам по сравнению с дейтаграммным способом.
ЕЩЕ РАЗ О ДЕЙТАГРАММНОМ СПОСОБЕ ПЕРЕДАЧИ
Дейтаграммный механизм основан на том, что все передаваемые пакеты обрабатываются независимо друг от друга, пакет за пакетом. Выбор следующего узла — например коммутатора Ethernet или маршрутизатора IP/IPX — определяется адресом узла назначения, содержащегося в заголовке пакета. Для сети Ethernet таким адресом является МАС-адрес длиной 6 байт, а для сети IP — составной IP-адрес длиной 4 байт, включающий номер сети и номер узла.
Решение о том, какому узлу передать пришедший пакет, принимается на основе таблицы, где содержится набор адресов назначения и адресная информация, однозначно определяющая следующий (транзитный или конечный) узел. Таблица, создаваемая для протоколов канального уровня, к которым относится Ethernet, обычно называется таблицей продвижения (forwarding table), а для протоколов сетевого уровня, таких, как IP и IPX, — таблицей маршрутизации (routing table). Далее мы будем пользоваться термином «таблица маршрутизации» в качестве обобщенного названия таблиц такого рода для всех протоколов, занимающихся продвижением пакетов.
На Рисунке 1 приведен пример таблицы маршрутизации сети, в которой используется протокол IP. Из всех полей такой таблицы показаны только два основных, на основе которых принимается решение о продвижении, — поле Net, где хранится IP-адрес сети назначения, и поле NextHop, где находится IP-адрес следующего маршрутизатора. Каждый пакет, поступивший на маршрутизатор R1, обрабатывается в соответствии с хранящимся в нем IP-адресом назначения: если его старшая часть, определяющая адрес сети назначения, совпадает с одним из адресов из поля Net таблицы маршрутизации, то пакет передается следующему маршрутизатору с адресом NextHop.
В таблице маршрутизации для одного и того же адреса назначения может содержаться несколько записей с различными адресами следующего маршрутизатора. Такой подход используется для повышения производительности и надежности сети. В приведенном примере пакеты для узла назначения с адресом N2, A2 в целях баланса нагрузки распределяются маршрутизатором R1 между двумя следующими маршрутизаторами — R2 и R3, что снижает нагрузку на каждый из них, а значит, уменьшает очереди и ускоряет доставку. Некоторая «неопределенность» путей следования пакетов с одним и тем же адресом назначения через сеть — прямое следствие принципа независимой обработки каждого пакета. Пакеты с одним и тем же адресом назначения могут добираться до адресата разными путями и вследствие изменения состояния сети: например, из-за отказа промежуточного маршрутизатора, приводящего к соответствующей реконфигурации таблиц маршрутизации.
Гибкость обработки трафика при дейтаграммном подходе достигается за счет относительного увеличения накладных расходов. Использование полных адресов конечных узлов при принятии решения о продвижении пакетов приводит к громоздким таблицам маршрутизации и длинным адресным полям в заголовках пакетов. Действительно, таблица маршрутизации должна содержать адреса всех конечных узлов составной сети. Иерархический подход к адресации, подобный тому, который применяется в сетях IP, когда в таблицу помещают не адреса отдельных узлов, а адреса сетей, позволяет представить информацию в агрегированном виде и сократить количество записей. Учет топологии сети и введение строки «маршрут по умолчанию» еще более смягчают ситуацию, но не снимают проблему полностью. В очень крупных сетях количество записей в таблице маршрутизации все равно остается весьма большим, например, транснациональные провайдеры Internet вынуждены оперировать в своих магистральных маршрутизаторах десятками тысяч записей. Необходимость просмотра такой таблицы при обработке каждого пакета приводит к замедлению работы устройства и/или к повышению требований к его производительности.
Такая особенность дейтаграммного механизма, как неопределенность путей следования трафика через сеть, также в некоторых случаях оборачивается недостатком: например, если для пакетов какого-либо сеанса между двумя конечными узлами сети необходимо обеспечить заданное качество обслуживания (Quality of Service, QoS). Современные методы поддержки QoS более эффективны, когда нуждающийся в гарантированном обслуживании трафик всегда проходит через одни и те же промежуточные узлы.
СЛЕД В СЛЕД
Механизм виртуальных каналов (virtual circuit или virtual channel) создает в сети фиксированные пути следования трафика через сеть с коммутацией пакетов. Этот механизм учитывает существование в сети потоков данных (flow). Под потоком обычно понимают последовательность пакетов (кадров, ячеек — тип технологии, с которой связан определенный термин для обозначения порции данных, не имеет здесь принципиального значения), имеющих набор общих признаков, который выделяет их из общего трафика. Например, потоком будет последовательность пакетов, которыми два приложения IP-телефонии, работающие на компьютерах пользователей, обмениваются между собой через сеть. В данном случае признаками принадлежности пакетов к потоку станут адреса этих компьютеров и адресная информация, идентифицирующая программные процессы внутри компьютеров (порты TCP/UDP в случае применения стека TCP/IP). Определив таким образом поток, его обслуживание можно организовать особым образом с учетом требований реального времени.
Если целью является прокладка для всех пакетов потока единого пути через сеть, то необходимым (но не всегда единственным) признаком такого потока является наличие для всех его пакетов общих точек входа в сеть и выхода из нее. Именно для передачи таких потоков в сети создаются виртуальные каналы. На Рисунке 2 показан фрагмент сети АТМ, в которой проложены два виртуальных канала. Первый проходит от конечного узла с адресом N1, A1 до конечного узла с адресом N2, A2 через промежуточные коммутаторы сети R1, R3 и R4. Второй обеспечивает продвижение ячеек АТМ по пути N3, A3 — R5 — R7 — R4 — N2, A2. Между двумя конечными узлами может быть проложено несколько виртуальных каналов, при этом они могут проходить как через одну и ту же, так и через отличающуюся последовательность транзитных узлов.
Сеть только обеспечивает возможность передачи трафика вдоль виртуального канала, решение же о том, какие именно потоки будут передаваться по этим каналам, принимают сами конечные узлы. Узел может использовать один и тот же виртуальный канал для передачи всех потоков, когда они имеют общие с данным виртуальным каналом конечные точки, хотя это и не обязательно. Например, для потока реального времени может быть задействован один виртуальный канал между точками А и В, а для трафика электронной почты — другой. В последнем случае требования к качеству обслуживания у разных виртуальных каналов будут отличаться, и удовлетворить их потенциально будет проще, чем при передаче трафика с разными требованиями к параметрам QoS по одному виртуальному каналу.
В различных технологиях, основанных на технике виртуальных каналов, в разной степени осуществляется учет требований потока к параметрам QoS. Так, в технологии X.25 они вообще не учитываются, так что виртуальный канал характеризуется только своими маршрутными параметрами, т. е. последовательностью узлов, через которые он проходит. Технология frame relay позволяет задать требования к пропускной способности виртуального канала, а технология АТМ дополнительно к этому формулирует такие требования QoS, как время задержки и процент потерь. Однако вопросы поддержки качества обслуживания в сетях с виртуальными каналами выходят за рамки данного урока, поэтому далее мы сосредоточимся исключительно на базовом механизме, учитывающем лишь требования к маршруту прохождения трафика.
Важной особенностью сетей с виртуальными каналами является использование локальных адресов пакетов при принятии решения о продвижении. Вместо длинного адреса узла назначения (его длина должна позволять уникально идентифицировать все узлы и подсети в сети; так, АТМ, например, оперирует с адресами длиной в 20 байт) применяется локальная, т. е. меняющаяся от узла к узлу метка, она вставляется во все пакеты, перемещаемые по определенному виртуальному каналу. Эта метка в различных технологиях называется по-разному: номер логического канала (Logical Channel Number, LCN) в технологии X.25; идентификатор соединения уровня канала данных (Data Link Connection Identifier, DLCI) в технологии frame relay; идентификатор виртуального канала (Virual Channel Identifier, VCI) в технологии АТМ. Однако назначение ее везде одинаково: промежуточный узел, называемый в этих технологиях коммутатором, считывает значение метки из заголовка пришедшего пакета и просматривает свою таблицу коммутации, где указывается, на какой выходной порт нужно передать пришедший пакет. Таблица коммутации содержит записи только о тех виртуальных каналах, которые проходят через данный коммутатор, а не обо всех имеющихся в сети узлах (или подсетях, если применяется иерархический способ адресации). Обычно в крупной сети число проложенных через узел виртуальных каналов существенно меньше количества узлов и подсетей, поэтому и размер таблицы коммутации намного меньше таблицы маршрутизации. Просмотреть ее можно гораздо быстрее, поэтому от коммутатора не требуется большой вычислительной мощности.
По той же причине поле метки намного короче поля адреса конечного узла, а значит, избыточность заголовка пакета значительно меньше, ведь теперь он не содержит длинного адреса, а переносит по сети только метку виртуального канала.
Однако настала пора детально пояснить, каким же образом коммутаторы сети связывают адреса узлов назначения (которых никто не отменял!) с локальными метками. А также назвать причины, по которым технологии виртуальных каналов обычно относят к технологиям второго, т. е. канального, уровня, а коммуникационные устройства, продвигающие данные вдоль виртуальных каналов, называют не маршрутизаторами, а коммутаторами.
УСТАНОВЛЕНИЕ И ИСПОЛЬЗОВАНИЕ ВИРТУАЛЬНЫХ КАНАЛОВ
Виртуальные каналы бывают двух типов — коммутируемый виртуальный канал (Switched Virtual Circuit, SVC) и постоянный виртуальный канал (Permanent Virtual Circuit, PVC). При создании коммутируемого виртуального канала коммутаторы сети настраиваются на передачу пакетов автоматически, по запросу конечного (иногда и промежуточного) узла сети. Организация постоянного виртуального канала осуществляется заранее, причем коммутаторы настраиваются вручную администратором сети, возможно, с привлечением централизованной системы управления сетью и некоторого служебного протокола (пока чаще всего — собственного протокола производителя оборудования).
Рассмотрим сначала процесс создания коммутируемого виртуального канала, т. е. SVC.
Создание коммутируемого виртуального канала по-прежнему требует наличия на коммутаторах таблиц маршрутизации, аналогичных тем, что используются в дейтаграммных сетях, например IP. Пример такой таблицы приведен на Рисунке 3, иллюстрирующем процесс прокладки виртуального канала между узлами N1, A1 и N2, A2 через сеть АТМ, представленную здесь двумя коммутаторами R1 и R2. Сеть АТМ выбрана только ради конкретизации изложения, с тем же успехом можно было пояснить этот процесс на примере сети X.25 или frame relay. В таблице маршрутизации указывается адрес сети назначения (в примере для краткости записи используются адреса подсетей АТМ длиной 3 байт и адреса конечных узлов длиной 2 байт, на практике подобные адреса тоже допускаются, считая, что старшая часть 20-ти байтового адреса является нулевой).
Установление коммутируемого виртуального канала выполняется служебным протоколом, который оперирует с пакетами специального типа и формата. В сетях АТМ такой протокол носит название Q.2931 (в сетях frame relay — Q.933, а в сетях X.25 он считается одним из режимов работы основного протокола X.25 и поэтому не получил специального названия).
Создание виртуального канала начинается с того, что узел-инициатор N1, A1 генерирует специальный пакет — запрос на установление логического соединения с узлом N2, A2. В технологии АТМ этот запрос носит название Call Setup. Он содержит многоразрядный адрес узла назначения (в данном примере — это 132456.8112, где старшая часть — номер подсети (группы) АТМ, а младшая — номер узла), а также начальное значение идентификатора виртуального канала — 102.
Узел-инициатор должен выбрать, какому коммутатору сети предпочтительнее передать запрос на установление канала. Такой выбор может происходить на основе таблицы маршрутизации узла-отправителя, но если узел соединен с сетью через единственный порт, как в приведенном примере, то эта таблица ему, естественно, не требуется.
Присвоенный виртуальному каналу номер 102 имеет локальное значение для порта компьютера, через который устанавливается соединение. Так как через порт уже проходит виртуальный канал с номером 101, то работающее на конечном узле программное обеспечение протокола Q.2931 просто выбрало первый свободный (не используемый в данный момент на данном порту) номер из разрешенного диапазона. Такой подход гарантирует уникальную идентификацию виртуальных каналов в пределах каждого порта.
После поступления в буфер порта 1 коммутатора R1, пакет Call Setup обрабатывается в соответствии со своим адресом назначения и значениями таблицы маршрутизации. Запись с адресом 132456 говорит, что пакет нужно передать на порт 3. Заметим, что в приведенной таблице маршрутизации нет информации об адресе следующего коммутатора — в отличие от таблиц сетей IP. Это связано с тем, что в АТМ, как и в технологиях X.25 и frame relay, коммутаторы всегда соединяются физическими каналами «точка-точка» и не поддерживают типичное для технологий локальных сетей множественное подключение, поэтому номер выходного порта однозначно определяет следующий коммутатор.
Определив выходной порт, коммутатор R1 генерирует новое значение номера виртуального канала, а именно 106. Это связано с тем, что на участке сети от порта 3 коммутатора R1 до порта 1 коммутатора R2 номер 102 уже используется другим виртуальным каналом, проходящим через указанные порты. Первым свободным номером оказался 106, в пределах локального участка сети он однозначно идентифицирует устанавливаемый виртуальный канал. Именно данное обстоятельство имелось в виду, когда ранее отмечалось, что идентификаторы виртуальных каналов носят локальный характер. После изменения значения идентификатора пакет Call Setup передается через выходной порт 3 в коммутатор R2. (Особенность АТМ, состоящая в том, что пакет Call Setup при передаче разбивается на несколько ячеек, каждая из которых снабжается одним и тем же значением идентификатора, в данном случае, при рассмотрении процедуры установления виртуального канала не существенна.)
Одновременно с продвижением пакета коммутатор создает таблицу коммутации. Эта таблица будет использоваться впоследствии, когда виртуальный канал будет установлен и по нему начнут передаваться пользовательские данные, причем уже без адресов и узлов назначения.
Каждая запись таблицы коммутации состоит из четырех основных полей: номера входного порта, входной метки (идентификатора виртуального канала в поступающих на входной порт пакетах), номера выходного порта и выходной метки (идентификатора виртуального канала в передаваемых через выходной порт пакетах). Запись в таблице коммутации «1-102-3-106» означает, что все поступающие на порт 1 пакеты (здесь более точно — ячейки АТМ) с идентификатором виртуального канала 102 будут передаваться на порт 3, а в поле идентификатора виртуального канала будет помещено новое значение — 106.
| Рисунок 4. Продвижение по виртуальному каналу. |
Процедуру установления виртуального канала продолжает коммутатор R2: на основании указанного в запросе адреса назначения и своей таблицы маршрутизации (на рисунке она не показана) он определяет выходной порт и передает ему запрос, попутно обновляя поле идентификатора виртуального канала, а также формирует записи таблицы коммутации. В результате конечный узел получает запрос Call Setup со значением номера виртуального канала 108. Получив запрос, конечный узел или принимает его, или отвергает (по своим внутренним причинам), используя служебный пакет Connect для уведомления о своем решении. Указанный пакет проходит по сети в обратном направлении, подтверждая коммутаторам и узлу-инициатору факт установления виртуального канала.
После получения подтверждения Connect конечные узлы могут начать пользоваться проложенным виртуальным каналом, посылая по нему пользовательские данные. Отправляемые узлом N1, A1 ячейки продвигаются в соответствии со значением идентификатора виртуального канала, который умещается в коротком заголовке длиной 5 байт, оставляя 48 байт из 53 для переноса данных. Применение дейтаграммной техники потребовало бы резервирования 20 байт для адреса узла назначения, что снизило бы коэффициент использования ячейки до неприемлемого уровня.
Постоянные виртуальные каналы, т. е. PVC, в отличие от SVC, не могут автоматически создаваться по инициативе пользователя сети. Вместо этого администратор сети заранее составляет таблицы коммутации вручную. Обычно для облегчения работы он использует ту или иную систему управления сетью для передачи данных о том, через какие узлы должен проходить виртуальный канал. Взаимодействуя с коммутаторами сети, эта система затем автоматически выбирает конкретные значения меток и создает записи таблиц коммутации. Применение в системах управления нестандартных протоколов конфигурирования порождает одну характерную проблему — обычно автоматизировать прокладку PVC можно только в пределах части сети, построенной на базе оборудования одного производителя, а «сшивать» части PVC в единое целое приходится вручную. Очевидно, что при создании PVC таблицы маршрутизации становятся ненужными, так как путь выбирается администратором. Для того чтобы можно было работать с проложенным постоянным виртуальным каналом, администратор должен ввести в конечные узлы, для которых канал создавался, номер этого PVC — свой для каждого конца канала.
По существу, техника коммутируемых виртуальных каналов использует два различных режима работы сети. При организации канала запрос на установление соединения передается с помощью стандартного режима маршрутизации с использованием глобальных (для всей сети) адресов назначения и информации о полной топологии сети. Иными словами, протоколы установления виртуальных каналов работают на сетевом уровне модели OSI.
После установления соединения сеть работает только с локальными адресами и локальными таблицами продвижения, что позволяет отнести такой режим к канальному уровню модели OSI, а коммуникационные устройства — к классу коммутаторов (стандартное название для устройств этого уровня).
ОТ ОБЩЕГО К ЧАСТНОМУ
Нетрудно заметить, что виртуальный канал — частный случай логического соединения между узлами сети. И для лучшего понимания техники виртуальных каналов полезно рассмотреть общие свойства тех протоколов, где используются механизмы логических соединений (а таких протоколов немало, причем они работают на разных уровнях стека протоколов, примерами могут служить TCP, IPSec, Microsoft SMB, Novell SPX).
Логическое соединение (называемое также сеансом) устанавливается между двумя (или более) узлами сети в результате проведения процедуры переговоров. Оно существует до тех пор, пока одна из сторон не инициирует процедуру его разрыва. После установления соединения процедура обработки определяется не для отдельного пакета, а для всего множества пакетов, передаваемых между узлами в рамках данного соединения. Процесс обслуживания вновь поступившего пакета напрямую зависит от предыстории: например, при потере нескольких предыдущих пакетов скорость отправки последующих может быть автоматически снижена.
Для реализации дифференцированного обслуживания пакетов, принадлежащих разным соединениям, сеть должна, во-первых, идентифицировать каждое соединение, а во-вторых, запоминать (отслеживать) значения параметров процедуры обработки для данного соединения. В качестве признаков, по которым обрабатывающие узлы могут распознавать принадлежность пакета к тому или иному соединению, часто выступает набор параметров, идентифицирующих пару из отправителя и получателя (адреса узлов, номера портов приложений и т. п.).
Знание «предыстории» обмена позволяет более рационально обрабатывать каждый вновь поступающий пакет. Параметры соединения применяются для разных целей. Так, например, динамически изменяемый параметр соединения — текущий размер окна (количество пакетов, которое в данный момент отправителю разрешено передать в сеть без получения подтверждения от адресата) делает возможным управление скоростью обмена. А нумерация пакетов повышает надежность передачи, позволяя в рамках соединения упорядочивать пакеты, отбрасывать дубликаты и повторять передачу потерянных. Если соединения устанавливаются с целью защиты данных, их параметры могут задавать режим защиты (аутентификация, обеспечение целостности или шифрование) и ключи шифрования.
Параметры процедуры обработки могут быть как постоянными в течение всего соединения (например, максимальный размер пакета), так и переменными, динамически отражающими текущее состояние соединения (например, упомянутые выше номера пакетов или текущий размер окна). Когда отправитель и получатель организуют новый сеанс, они прежде всего «договариваются» о начальных значениях параметров процедуры обмена и только после этого начинают собственно передачу данных.
Многие протоколы с установлением соединений никак не регламентируют маршрут продвижения пакетов по сети, в то время как фиксация маршрута в рамках соединения является сутью техники виртуальных каналов. Так, в задачу протокола TCP вообще не входит выбор маршрута — этим занимается нижележащий дейтаграммный протокол IP. Поскольку протокол IP может направлять пакеты с одними и теми же адресами отправления и назначения по разным маршрутам, то пакеты в рамках соединения TCP способны перемещаться по независимым друг от друга маршрутам.
ОБРАТНАЯ СТОРОНА МЕДАЛИ
В отличие от дейтаграммных, протоколы с поддержкой коммутируемых виртуальных каналов, т. е. SVC, предусматривают предварительное установление соединения, что вносит дополнительную задержку перед передачей данных. Эта задержка особенно заметна при передаче небольшого объема данных, когда продолжительность установления виртуального канала может быть соизмерима со временем передачи данных. Кроме того, дейтаграммный метод быстрее адаптируется к изменениям в сети. При отказе коммутатора или участка маршрута виртуального канала соединение разрывается, и виртуальный канал нужно прокладывать заново, естественно, в обход отказавшего участка сети. Однако, сравнивая эти два принципиально различных подхода, следует учесть, что время, затраченное на установление виртуального канала, компенсируется последующей быстрой передачей всего потока пакетов, поэтому для долговременных потоков режим SVC достаточно эффективен.
Применение режима постоянных виртуальных каналов, т. е. PVC, позволяет избежать задержки на установление канала. Но у этого режима свой недостаток — большой объем ручной работы при прокладке каналов, что приводит к плохой масштабируемости сети. Количество каналов PVC для организации полносвязной топологии при наличии N подключенных к сети конечных узлов равно N(N-1)/2, так что объем работ по конфигурированию крупной сети на основе PVC возрастает как квадратичная функция. В случае применения дейтаграммных протоколов, подобных IP, сложность конфигурирования сети прямо пропорциональна N, что говорит об отличной масштабируемости этого класса технологий.
А можно ли взять от каждого подхода только хорошее? Такую попытку предприняли разработчики технологии MPLS, где используется для продвижения пакетов техника пути коммутации меток (Label Switching Path), родственная технике виртуальных каналов. Но это тема для отдельного разговора.
Наталья Олифер — обозреватель «Журнала сетевых решений/LAN». С ней можно связаться по адресу: olifer@lanmag.ru.