Пътища през мрежата
Има два класа механизми за пренасочване на пакети, използвани днес в мрежи с комутация на пакети - предаване на дейтаграми и виртуални вериги. И двата се изпълняват от протоколите за връзка и мрежов слой на OSI модела. Примери за протоколи, използващи механизма за препращане на дейтаграми, са Ethernet, IP и IPX. С помощта на виртуални канали данните се предават в X.25, frame relay и ATM мрежи. Този урок се фокусира върху основните принципи на техниката на виртуалната верига, нейните предимства и недостатъци в сравнение с метода на дейтаграмите.
ВЕДНЪЖ ЗА МЕТОДА ЗА ПРЕДАВАНЕ НА ДАТАГРАМА
Такава характеристика на механизма на дейтаграмата като несигурността на пътищата на трафик през мрежата също се превръща в недостатък в някои случаи: например, ако е необходимо да се осигури дадено качество на услугата (QoS) за пакетите на сесия между два крайни мрежови възела. Съвременните методи за поддържане на QoS са по-ефективни, когато трафикът, който се нуждае от гарантирано обслужване, винаги преминава през едни и същи междинни възли.
ДО СЛЕДВАЩИЯ
Ако целта е да се постави един път през мрежата за всички пакети от потока, тогава необходим (но не винаги единствен) знак за такъв поток е наличието за всичките му пакети на общи точки за влизане и излизане от мрежата. Именно за предаването на такива потоци в мрежата се създават виртуални канали.
Мрежата предоставя само възможност за предаване на трафик по виртуалния канал, докато решението кои потоци ще се предават по тези канали се взема от самите крайни възли. Един възел МОЖЕ да използва една и съща виртуална верига, за да пренася всички потоци, когато споделя крайни точки с дадена виртуална верига, въпреки че това не еЗадължително. Например, една виртуална верига между точки A и B може да се използва за трафик в реално време, а друга за имейл трафик. В последния случай изискванията за качество на услугата за различните виртуални вериги ще се различават и потенциално ще бъде по-лесно да ги задоволим, отколкото при предаване на трафик с различни изисквания за QoS параметри през една виртуална верига.
В различни технологии, базирани на техниката на виртуални канали, изискванията на потока към параметрите на QoS се вземат предвид в различна степен. Така че в технологията X.25 те изобщо не се вземат предвид, така че виртуалният канал се характеризира само с параметрите на маршрутизирането си, т.е. с последователността от възли, през които преминава. Технологията Frame Relay ви позволява да зададете изискванията за честотна лента на виртуалния канал, а технологията ATM допълнително формулира такива изисквания за QoS като време на забавяне и процент на загубите. Въпросите за поддържане на QoS в мрежи с виртуални вериги обаче са извън обхвата на този урок, така че по-долу ще се съсредоточим изключително върху основния механизъм, който взема предвид само изискванията за пътя на трафика.
ИНСТАЛИРАНЕ И ИЗПОЛЗВАНЕ НА ВИРТУАЛНИ КАНАЛИ
Има два вида виртуални вериги - комутирана виртуална верига (Switched Virtual Circuit, SVC) и постоянна виртуална верига (Permanent Virtual Circuit, PVC). Когато създавате комутируем виртуален канал, мрежовите комутатори са конфигурирани да предават пакети автоматично, по искане на крайния (понякога междинен) мрежов възел. Организирането на постоянен виртуален канал се извършва предварително, а комутаторите се конфигурират ръчно от мрежовия администратор, евентуално с участието на централизирана система за управление на мрежата инякакъв сервизен протокол (засега най-често - собствен протокол на производителя на оборудването).
Помислете първо за процеса на създаване на комутирана виртуална верига, т.е. SVC.
Установяването на комутирана виртуална верига се извършва от сервизен протокол, който работи с пакети от специален тип и формат. В ATM мрежите този протокол се нарича Q.2931 (в мрежите с frame relay е Q.933, а в мрежите X.25 се счита за един от режимите на работа на основния протокол X.25 и затова не е получил специално име).
Иницииращият възел трябва да избере към кой комутатор в мрежата е за предпочитане да изпрати заявката за установяване на връзка. Този избор може да се основава на таблицата за маршрутизиране на изпращащия възел, но ако възелът е свързан към мрежата чрез един порт, както в примера по-горе, тогава тази таблица, разбира се, не се изисква от него.
Номерът 102, присвоен на виртуалната верига, има локално значение за порта на компютъра, през който се осъществява връзката. Тъй като номерът на виртуалния канал 101 вече преминава през порта, софтуерът на протокола Q.2931, работещ на крайния възел, просто избира първия свободен (неизползван в момента на този порт) номер от разрешения диапазон. Този подход гарантира, че виртуалните вериги са уникално идентифицирани във всеки порт.
След като определи изходния порт, превключвателят R1 генерира нова стойност на номера на виртуалния канал, а именно 106. Това се дължи на факта, че в мрежовия участък от порт 3 на превключвател R1 до порт 1 на превключвател R2 номер 102 вече се използва от друг виртуален канал, преминаващ през посочените портове. Първият безплатен номер се оказа 106, в локалната зона на мрежата той уникално идентифицира инсталирания виртуаленканал. Именно това обстоятелство се има предвид, когато по-рано беше отбелязано, че идентификаторите на виртуалните канали са от локален характер. След като стойността на ID бъде променена, пакетът за настройка на повикване се изпраща през порт 3 за превключване на R2. (Особеността на ATM, която се състои в това, че пакетът за настройка на повикване по време на предаване е разделен на няколко клетки, всяка от които е снабдена с една и съща стойност на идентификатор, не е от съществено значение в този случай, когато се разглежда процедурата за установяване на виртуален канал.)
Всеки запис в таблицата за превключване се състои от четири основни полета: номер на входен порт, входен етикет (идентификатор на виртуален канал в пакети, пристигащи на входния порт), номер на изходен порт и етикет на изход (идентификатор на виртуален канал в пакети, предавани през изходния порт). Записът в таблицата за превключване "1-102-3-106" означава, че всички пакети, пристигащи на порт 1 (тук, по-точно, ATM клетки) с идентификатор на виртуална верига 102, ще бъдат предадени на порт 3, а в полето за идентификатор на виртуална верига ще бъде поставена нова стойност - 106.
Виртуалните вериги могат да бъдат еднопосочни или двупосочни. В този пример е организиран двупосочен канал, така че превключвателят създава друг запис в таблицата за превключване - за препращане на пакети в обратна посока, от възел N2, A2 към възел N1, A1. Този запис е огледален по отношение на първия, така че пакетът, който отива в обратната посока, ще получи първоначалната стойност на етикета, а именно 102, когато напусне порт 1. В резултат на това възелът N1, A1 правилно разпознава, че входящият пакет принадлежи към конкретен виртуален канал, въпреки постоянната промяна на числата по време на пътуването на пакета през мрежата. За еднопосочни връзки се създава само записза една посока.
Постоянните виртуални вериги, т.е. PVC, за разлика от SVC, не могат да бъдат създадени автоматично по инициатива на мрежовия потребител. Вместо това мрежовият администратор предварително компилира ръчно превключващи таблици. Обикновено, за да направи нещата по-лесни, той използва някаква система за управление на мрежата, за да комуникира през кои възли трябва да премине виртуалната верига. Взаимодействайки с мрежови комутатори, тази система след това автоматично избира специфични стойности на етикети и създава записи в таблицата за превключване. Използването на нестандартни конфигурационни протоколи в системите за управление поражда един характерен проблем - обикновено е възможно да се автоматизира полагането на PVC само в рамките на част от мрежа, изградена на базата на оборудване от един производител, и трябва ръчно да „шиете“ PVC части в едно цяло. Очевидно, когато се създаде PVC, таблиците за маршрутизиране стават ненужни, тъй като пътят се избира от администратора. За да може да работи с поставената перманентна виртуална верига, администраторът трябва да въведе крайните възли, за които е създаден канала, номерът на този PVC е различен за всеки край на канала.
ОТ ОБЩО КЪМ КОНКРЕТНО
Лесно е да се види, че виртуалният канал е частен случай на логическа връзка между мрежови възли. И за по-добро разбиране на технологията на виртуалните канали е полезно да се разгледат общите свойства на онези протоколи, които използват механизми за логическа връзка (има много такива протоколи и те работят на различни нива на протоколния стек, примери включват TCP, IPSec, Microsoft SMB, Novell SPX).
Логическа връзка (наричана още сесия) се установява между два (или повече) мрежови възела в резултат на процедура на договаряне. Съществува, докато една от странитене инициира процедурата за прекъсване. След установяване на връзка, процедурата за обработка се определя не за отделен пакет, а за целия набор от пакети, предавани между възлите в дадена връзка. Процесът на обслужване на новополучен пакет зависи пряко от историята: например, ако няколко предишни пакета са загубени, скоростта на изпращане на следващите пакети може да бъде автоматично намалена.
Параметрите на процедурата за обработка могат да бъдат или постоянни по време на връзката (например максималния размер на пакета), или променливи, които динамично отразяват текущото състояние на връзката (например номерата на пакетите, споменати по-горе, или текущия размер на прозореца). Когато изпращачът и получателят организират нова сесия, те първо се „договарят“ за първоначалните стойности на параметрите на процедурата за обмен и едва след това започват реалния трансфер на данни.
НО ОТ ДРУГА СТРАНА
За разлика от протоколите за дейтаграми, протоколите за комутирана виртуална верига, т.е. SVC, осигуряват установяване на предварително свързване, което въвежда допълнително забавяне преди предаване на данни. Това забавяне е особено забележимо при предаване на малко количество данни, когато продължителността на установяване на виртуален канал може да бъде съизмерима с времето за предаване на данни. Освен това методът на дейтаграмите се адаптира по-бързо към промените в мрежата. Ако превключвателят или участъкът от маршрута на виртуалния канал се повреди, връзката се прекъсва и виртуалният канал трябва да бъде положен отново, естествено, заобикаляйки неуспешния мрежов участък. Въпреки това, когато се сравняват тези два фундаментално различни подхода, трябва да се има предвид, че времето, изразходвано за установяване на виртуален канал, се компенсира от последващото бързо предаване на целия пакетен поток, следователно за дългосрочни потоциSVC режимът е доста ефективен.
Използването на постоянни виртуални вериги, т.е. PVCs, избягва забавянето при установяване на връзка. Но този режим има своя недостатък - голямо количество ръчна работа при полагане на канали, което води до лоша скалируемост на мрежата. Броят на PVCs за напълно заплетена топология с N крайни възли, свързани към мрежата, е N(N-1)/2, така че количеството работа за конфигуриране на голяма базирана на PVC мрежа се увеличава като квадратична функция. В случай на дейтаграмни протоколи като IP, сложността на мрежовата конфигурация е право пропорционална на N, което показва отличната скалируемост на този клас технологии.
Възможно ли е да вземем само доброто от всеки подход? Такъв опит беше направен от разработчиците на технологията MPLS, където техниката Label Switching Path, подобна на техниката на виртуална верига, се използва за препращане на пакети. Но това е тема за отделна дискусия.