Канальные среды (3)

Продолжаем мы с вами говорить про канальные среды. Соответственно, мы разобрали с вами 802 кадры, которые... 802,3, простите, кадры, которые есть в Ethernet и в некоторых других протоколах, например, в том же самом DOC-CC, например, в GE Pony. Там тоже используется формат кадра Ethernet. И мы с вами еще пока не смотрели, но, тем не менее, разберем то, как выглядит процедура коммутации в Ethernet. Но, по большому счету, любой коммутатор, я уже сказал, как работает, он берет и пытается прикинуться толстым желтым коаксиалом. То есть пытается разбросать все кадры на все порты, кроме некоторых. Вот, на самом деле, любой коммутатор в Ethernet устроен таким образом. Frame Relay — это протокол, который изначально имел коммутацию. Потому что в Ethernet изначально коммутации не было. Она там сбоку появилась потом, когда появилась вообще концепция коммутации в Ethernet. А изначально в Ethernet был просто толстый желтый коаксиал. Никаких коммутаторов в Ethernet изначально не было. И потом его туда, концепцию коммутации, приделали с сохранением возможности взаимодействия,

как будто этих коммутаторов не существует. Именно поэтому коммутатор Ethernet пытается прикинуться коаксиалом. Он должен вести себя так, чтобы его вообще никто не заметил. Во Frame Relay изначально коммутация была. Frame Relay — это протокол, который разрабатывался для сетей, который умеет передавать битовые потоки. То есть изначально он создавался для SDN сетей, но в принципе он может работать поверх любого битового потока. И он специально предназначен для того, чтобы можно было в ситуации, когда у вас есть какие-то каналы связи, связывающие между собой различные узлы, передавать трафик с использованием коммутации. То есть с одной стороны кадр получили, с другой стороны его передали. Вот эта вот штука, она достаточно инновационная была по состоянию, но тогда, когда Frame Relay вообще задумывался. Он примерно тех же самых годов, что Ethernet, что и IP. То есть это середина 70-х. Если мне память не изменяет, 78-й год. Авторы Frame Relay его предложили использовать. То есть примерно тогда же, когда и Ethernet, когда и IP зародились.

И особенностью работы Frame Relay по сравнению с теми протоколами связи, которые были на тот момент, являлись несколько вещей. Первое — это то, что протокол был коммутируемый. Второе — он позволял выполнять коммутацию с заданным уровнем качества. То есть если у вас есть коммутация, что она предполагает собой? Что у вас не выделены линии между любыми двумя участниками есть, а у вас есть какие-то линии, поверх которых трафик может бегать одновременно от нескольких участников. И в этом случае у нас будет коммутация с помощью пакетов происходить. То есть с одной стороны пакет получили, в другую сторону передали. Еще откуда-то пакет получили, еще куда-то передали. И может происходить такое, что у нас два пакета, которые придут от двух разных абонентов, надо будет отправить в сторону одного какого-то получателя. То есть по одному и тому же порту получателя выплюнуть два кадра, которые были получены из двух разных других портов. В этом случае всегда возникает вопрос, кого мы отправляем первым, кого вторым. Ну и FrameRelay — это протокол, который изначально предполагал,

что у вас может сложиться ситуация вида, надо сначала передать один кадр, потом другой. Или может сложиться ситуация, что мы хотим передать кадр в какой-то порт, а у нас там есть возможность передать только один кадр. А нам надо два, которые получены из двух разных мест. В этом случае одним кадром придется пожертвовать. У нас может быть такое, что ресурсов на обработку обоих картеров не хватит. FrameRelay — это протокол, в котором изначально была заложена возможность отбрасывания тех кадров, которыми можно пожертвовать. То есть вы можете отправить кадр в FrameRelay и сказать, этот кадр, он первый на заклане. Если где-то у нас в сети есть перегрузка, пусть он потеряется. На самом деле, когда мы говорим про управление качеством, всегда в голове у пользователя есть… Ну, у пользователя, у обывателя. Есть представление, что управление качеством, что вот можно отправить что-то просто отправить, а можно что-то отправить как-то хорошо отправить, чтобы оно хорошо дошло до местоназначения. На самом деле, управление качеством — это всегда… На самом деле, дискриминация одного типа трафика по отношению к другому.

То есть мы можем отправить какой-то трафик, чтобы он просто прошел, а какой-то трафик мы можем отправить, чтобы он с меньшей вероятностью дошел до получателя, если вдруг в сети возникнет перегрузка. Понятное дело, что если перегрузки нет, то доставить надо весь трафик. Если есть такая возможность, мы не должны выбрасывать трафик просто потому, что нам не нравится. Но если мы видим, что в сети возникает перегрузка, в этом случае, отправив кадры с разными свойствами, с разными настройками качества, мы можем сказать, какими кадрами пожертвовать можно, какими нельзя. Поэтому все механизмы Quality of Service — это как раз про то, чем пожертвовать можно в случае перегрузки. И как раз Frame Relay позволял вам такой вот признак, что кем-то можно будет пожертвовать, проставить изначально. Это была, еще раз повторюсь, инновационная идея. На тот момент в других протоколах такого не было. Frame Relay в какой-то степени похож на то, что мы сегодня знаем под названием Ethernet, то есть на коммутацию в Ethernet. У нас точно так же кадры приходят на одном порту,

точно так же коммутатор анализирует, что там такое пришло, точно так же принимает решение, что с этим кадром дальше делать, и, соответственно, отправляет кадр куда-то дальше по сети. Кадр так же, как в Ethernet, может быть переменной длины. Но Frame Relay некоторым образом и не похож на Ethernet, потому что он изначально создавался для решения One задач, он изначально создавался под коммутацию. Поэтому во Frame Relay есть определенная логика, которая после знакомства с Ethernet кажется немножко странной. Во-первых, Frame Relay позволяет пропускать кадры только по заданным маршрутам. То есть вы указываете, по какому маршруту может идти кадр. В Ethernet у нас коммутация работает немножко иначе. Мы не говорим, что трафик может пойти только от маршрута, от точки А до точки Б. Мы говорим, что если у нас просто есть обычный коммутатор, то он пытается прикинуться к аксиалам, и он на самом деле кадры получает на каком-то порту, и он разбрасывает копию этого кадра на всех портах, кроме некоторых. И дальше возникает вопрос, на каких именно некоторых портах

он копии там не отправляет. Вот в Ethernet мы там делаем ограничения. Никогда не отправляется кадр в тот порт, из-под которого кадр пришел, никогда не отправляется кадр в порты, которые не просоциированы с тем же самым WLAN. Никогда не отправляется кадр в порты, которые входят в ту же порт-группу, откуда пришел кадр. То есть если вы делаете агрегацию портов, на самом деле вы тем самым управляете коммутацией. Никогда не отправляется копия кадров на те порты, которые заблокированы Испания, и так далее. Вот во фрейм-рилее изначальная логика другая. Кадры могут отправляться только в тот порт, который в явном виде прописан. Если у нас пришел какой-то кадр на входящем порту, и в нем стоит какой-то адрес, куда он хочет пройти, то мы смотрим, что с этим кадром надо сделать. У нас должно быть в явном виде написано, такие кадры надо отправлять вот в таком-то направлении. Если нет указания, что с такими кадрами делать, такой кадр выбрасывается. Логика немножко похожа на то, что мы знаем под названием IP Unicast. То есть в IPv4 Unicast мы таким же образом работаем.

Какой-то пакет приходит, мы смотрим, что с ним делать. Если знаем, что с ним делать, выплевываем ровно в одном направлении. Если не знаем, выкидываем. Во фрейм-рилее была подобная логика. И, соответственно, если у вас прописана трасса, куда кадр следует отправить, вы такой кадр отправляете дальше. Если у вас не прописано указание, что с этим кадром делать, вы его выбрасываете. Во фрейм-рилее нет полносвязной топологии. То есть вы можете купить трассу между двумя точками, и у вас будет связь между этими двумя точками. Вы можете не покупать трассу между двумя точками, а у вас тогда связи там не будет. То есть вот таким вот образом он примерно работает. Во фрейм-рилее нет мультикаста и нет браткаста. То есть браткаст — это частный случай мультикаста. Вы не можете отправить какой-то один кадр, который пойдет в два разных направления. То есть отправляете вы один кадр, а он в какой-то момент разветвляется и начинает идти по двум разным направлениям.

В Ethernet у нас такое есть. Мы можем отправить бродкастовый кадр, и он на самом деле отправится на все порты, кроме порта источника, ну и каких-то еще других портов, на которых мы дополнительные ограничения сделаем. То есть не отправится бродкаст в те порты, которые заблокированы в Spanning 3, в те порты, которые в других виланах, в те порты, которые в той же самой портгруппе. Ну то есть вот бродкаст, он разбрасывается по многим портам, мультикаст разбрасывается по многим портам. А фрейм рилей мог отправить кадр только в одном направлении. Вот туда, куда купили трассу, туда он отправится. Не купили трассу, выкидываем. Поэтому мультикаста в нем нет, бродкаста в нем нет. И еще одна особенность, вы не можете отправить какой-то кадр и в нем написать, а я не знаю, кому это на самом деле. То есть в Ethernet мы можем доставить кадр до получателя, даже если мы не знаем его адрес. Мы можем отправить такой кадр бродкаста, но он дойдет до всех. А дальше мы внутри содержимого напишем, кому оно на самом деле адресовано. Ну как, например, протокол ARP. Мы можем кадр отправить, содержащий ARP запрос.

Он дойдет до всех. Но только тот, кто является обладателем адреса, на него будет отвечать. Вот во фрейм рилей вы не можете отправить такой кадр, который будет доставлен до вообще всех. Бродкаста нет. Соответственно, вы не можете доставить какой-то кадр конкретному получателю, если вы не знаете адрес этого получателя. Поэтому вы должны будете сначала узнать адрес, кому вы отправляете трафик, и только после этого самый первый кадр до этого получателя вы сможете отправить. Еще одна особенность фрейм рилея заключается в том, что адрес в кадре только один. Мы когда говорили с вами про кадры формата Ethernet, я говорил, что там есть адрес получателя в Ethernet, есть адрес отправителя. И адрес получателя, он нужный, потому что на его основе, собственно говоря, сам Ethernet работает. А вот адрес отправителя, он по большому счету декоративный. Изначально в толстом желтом коаксиале адрес отправителя не был нужен. Ну и во фрейм рилея, собственно говоря, такая же ситуация. Там тоже есть адрес получателя, который действительно будет полезен, будет нужен. И нет адреса отправителя.

Вот этим он не похож на Ethernet. То есть если вы отправляете какой-то кадр кому-то, вы проставляете его адрес, и вы точно знаете, какой адрес должен быть у этого получателя. Ответы, которые будут идти, они будут идти уже тоже с указанием вашего адреса. И вы тоже будете как бы хорошо известным получателем, хорошо известным получателем для вашего абонента, для вашей другой стороны. То есть вы сначала узнаете адреса, и только после этого вы можете отправлять трафик. И со всеми, с кем вы имеете взаимодействие, все адреса у вас тоже имеются заранее. Для того, чтобы все это работало, нужно, чтобы вы заранее, до начала взаимодействия, знали бы все адреса всех ваших собеседников, и чтобы все транзитные свечи имели бы заполненные таблицы коммутации. То есть правила, по которым они будут, собственно говоря, коммутировать трафик. Если правила коммутации нету на FrameRelay, то значит у нас кадр никуда не уйдет. Именно поэтому таблица коммутации сначала заполняется, только после этого начинает ходить трафик.

Примерно похоже на то, как сделано в IP. Во FrameRelay есть два типа услуг. Это Permanent Virtual Circuit и Switched Virtual Circuit. Permanent — это вы прописываете трассу, как может ходить трафик от одного узла до другого, и вот она всегда будет работать. Она перманентная, то есть один раз прописали, и дальше она постоянно живет на оборудовании. Вы прописываете маршрут на всех транзитных коммутаторах и указываете, как пойдет трафик от одной точки до другой. Соответственно, вам нужно будет один раз это все дело настроить, и дальше оно работает. Switched Virtual Circuit — это услуга, которая предоставляет маршрут по требованиям. То есть вы отправляете запрос на то, чтобы трафик смог ходить от одной точки до другой. Коммутаторы на лету пытаются построить для вас трассу, исходя из имеющихся ресурсов, исходя из своего понимания, как устроена сеть. Дальше они в какой-то момент говорят, окей, трасса построена. По этой трассе начинает ходить трафик. В какой-то момент узел говорит,

все, мне больше не нужно отправлять трафик. Отправляет сигнализационный запрос, типа, мне больше трассы не нужна. Коммутаторы освобождают имеющиеся ресурсы и могут выделить их под какие-то другие узлы. SVC требует предварительную настройку на коммутаторах, требует предварительную настройку на конечных абонентах и требует процедуру установления и терминации вот этой самой трассы. В реальности SVC достаточно редко использовалось. То есть чаще всего абоненты предпочитали услугу permanent virtual circuit, когда компания хочет подключиться к провайдерской сети FrameRelay, ей требуется организовать связь между двумя точками. Вот она говорит, мне постоянная связь будет нужна, мне не нужно вызывать абонента только в течение какого-то ограниченного времени. Я хочу, чтобы у меня постоянная связь была между двумя точками и, соответственно, я готов платить деньги за permanent virtual circuit. В случае с FrameRelay провайдеры были довольно рады тому, что компания готова платить деньги за какую-то услугу

с фиксированным качеством связи. И, соответственно, в FrameRelay одна из замечательных особенностей заключается в том, что вы могли продавать услугу с законтрактованной скоростью. То есть вы могли сказать, что вы провайдер, у вас есть клиент, клиент приходит и говорит, что он хочет организовать связь между офисом в одном городе и офисом в другом городе. И у вас везде в этих городах FrameRelay сети есть. Вы говорите, окей, я тебе продаю канал между этими двумя точками, я тебе продаю канал на определенной скорости. Вы во FrameRelay можете эту самую скорость законтрактовать, вы можете прописать, что трафик между этими двумя точками ходят только вот с определенными характеристиками, с определенной скоростью, эффективной скоростью. Опять же, не все протоколы позволяют такое делать даже до сих пор, а FrameRelay достаточно неплохо это все делал уже тогда. То есть он адресно был заточен для решения типичных провайдерских задач, а предоставление канала на определенной скорости – это определенно достаточно важная задача.

В FrameRelay использовались очень странные адреса. То есть там, где в изорнете, мы говорим, у нас используется MAC-адреса. Это шестибайтовые просто идентификаторы. У каждого узла он свой, отдельный, уникальный, нигде не повторяется. Во FrameRelay адресация была более хитрая. Во-первых, адреса были некратны байту. То есть они были переменной длины, чаще всего они были 10-битные. И более того, вот эти 10 бит, они шли непоследовательно внутри кадра. То есть мы отправляли кадр, и в этом кадре кусочек адреса один, кусочек адреса другой, они хранились в разных местах. Но в сумме эти адреса были 10-битные. И вот если посмотреть на кусок заголовка, который хранил как раз эти самые адреса, то он выглядел следующим образом. Там сначала первый байт был, вот этот вот первый байт, и потом второй байт. И в первом байте первые 6 бит соответствовали в верхней части, в старшей части DLCI-ки.

И, соответственно, в втором байте старшие 4 бита соответствовали младшей части DLCI-ки. Получается в сумме 6 бит из первого байта, 4 бита из второго байта. У нас получается как раз 10-битный адрес. Вот это вот слово DLCI — это фактически самоназвание адреса во FrameRelay. Если вдруг вам интересно, это Data Link Connection Identifier. Ну, фактически адрес. И особенностью FrameRelay, особенностью адресации во FrameRelay будет то, что эти адреса у вас могут меняться в кадре. Вы отправляете кадр, и вы отправляете его для того, чтобы он дошел до получателя. Вы указываете адрес, кому вы отправляете этот самый кадр, но вы указываете фактически не адрес получателя, а адрес трассы, по которой должен пройти этот кадр. И если вы обычный, там, допустим, абонент, ну, роутер, давайте, роутер предприятия, который подключается к FrameRelay Switch, вы отправляете какой-то кадр, вы указываете номер трассы,

по которой должен пойти этот кадр, ну, допустим, номер 100, и дальше Switch видит, что кадр пришел в порту, который смотрит на абонента, с номером трассы 100. Он говорит, окей, такие кадры я должен отправить по вот там, имеющимся правилу коммутации на выходной порт вот такой. И в этом кадре он может поменять адрес по своему усмотрению. То есть он может взять и сказать, а вот я хочу, чтобы дальше этот кадр ушел с номером DLT-200. То есть это все равно одна и та же трасса, просто она состоит из правил коммутации, что кадры, полученные вот отсюда и идущие в сторону куда-то там далеко, мы отправляем по вот такому вот направлению, и заодно в этом правиле коммутации указывается, на какой номер DLT-200 мы меняем модификатор вот этот самый в кадре. И, соответственно, правило будет, что если вот отсюда пришло с номером 100, мы отправляем это вот сюда вот, соответственно, с номером 200. То же самое здесь. На следующем коммутаторе в цепочке, если оно приходит на вот этом вот порту с номером трассы 200, с номером DLT-200, то мы это коммутируем вот сюда,

и, соответственно, перекладываем это с номером DLT-200, их там, допустим, 150. И когда у нас конечный абонент получает какой-то кадр с указанием DLT-150, он понимает, что это пришло от какого-то узла А, допустим, узел А, узел Б. На самом деле я вам сейчас это рассказываю не для того, чтобы вы знали, как устроен фрейм рилей, хотя на экзамене, в принципе, могут быть вопросы про фрейм рилей, я вам это рассказываю для того, чтобы вы, возможно, провели какие-то параллели исторические. Потому что есть такой протокол, который называется MPLS, и мы его обязательно будем дальше смотреть. Вот в MPLS все то же самое. Весь MPLS содран со фрейм рилей один в один. Там та же самая история. Какой-то кусочек данных приходит на одном интерфейсе, у него есть какой-то номер трассы, по которой он идет, и, соответственно, есть некое правило, что мы с этим кусочком данных делаем. Мы его перекладываем в какой-то другой интерфейс и меняем номер трассы на какой-то еще. И правила коммутации фактически состоят из набора указаний,

что мы принимаем на каком интерфейсе, куда мы отправляем и как меняем адрес в кусочке данных, которые мы коммутируем. Вот так вот может выглядеть таблица коммутации. То есть вот это у нас провайдерский свитч, фрейм рилей. Вот это у нас узел А, вот это у нас узел Б, это у нас узел Ц, ну или там R1, R2, R3, не суть важна. И на коммутаторе фрейм рилей мы прописываем правила. Соответственно, если нам нужно организовать связь между узлом А и узлом В, ну или роутер R1, R2, то мы должны будем сказать, что кадры, которые приходят от узла А на интерфейсе сериал 1.1 фрейм рилей свитча, мы должны будем отправить на интерфейс сериал 1.2. Ну, соответственно, трасса, которая у нас будет куплена между узлом А и В, она будет маркироваться со стороны узла А номером DLSI-102, а, соответственно, со стороны узла А, она будет маркироваться, допустим, номером DLSI-201. И вот такое вот правило у нас будет на фрейм рилей свитча, что если что-то приходит на сериал 1.1 интерфейсе,

это интерфейс, который смотрит на роутер R1, и там прописан номер DLSI-102, то мы это перекладываем на сериал 1.2 интерфейс, это в сторону R2, и, соответственно, прописываем новый номер, новый идентификатор трассы, по которой это все идет. Узел B принимает какие-то кадры с номером DLSI-201, и если он захочет, он может отправить, допустим, ответ. Гипотетически, в принципе, если он отправит что-то на номер DLSI-201, то это может прийти на R1 обратно, а может и не прийти. То есть может быть нюанс, что трасса, которая прописана в одну сторону, и трасса, которая может быть прописана в другую сторону, они совсем могут быть разные. Поэтому по-хорошему узел B заранее должен знать, из-под какой DLSI-ки трафик будет приходить, и на какую DLSI-ку надо будет отправлять трафик, чтобы он ушел в ответ на узел A. То есть это однонаправленная трасса, на самом деле, по-хорошему. Но чаще всего для удобства прописывают их двунаправленные, то есть говорят, что если что-то 201 идет на сериал 1.2, то это надо отправить в ответ в ту же самую сторону. Здесь у нас 102, соответственно, будет выходной идентификатор,

и мы в обратную сторону то же самое делаем. Потому что если что-то приходит от сериал 1.2 с номером DLSI-ки 201, то мы отправляем это на сериал 1.1 с номером DLSI-ки 102. И вот эта вот трасса — это от R1 до R2, а вот эта трасса — это от R2 до R1. То есть два разных набора правил коммутации нам нужны для того, чтобы отправить трафик туда и обратно. аналогично с связью между узлом А и С. То есть если нам нужно организовать связь между А и С, то это на самом деле будет две трассы. Одна трасса от А до С, другая трасса от С до А. Ну и набор правил коммутации опять же мы прописываем, что если трафик приходит от узла R1 на сериал-интерфейсе 1.1, то есть вот здесь вот, и прописана DLSI-ка, допустим, 103, то мы перекладываем такие кадры в сторону интерфейса сериал-интерфейса сериал-интерфейса с номером DLSI-ки 301. Мы меняем 103 на 301 внутри кадра, меняем адрес. Это у нас интерфейс, который смотрит в сторону роутера R3.

И в обратную сторону. Если что-то приходит на сериал-интерфейсе, это от роутера R3, то мы, если видим там DLSI-ку 301, мы понимаем, это должно пойти по трассе от R3 к R1, поэтому мы это перекладываем в сторону R1 роутера на сериал-интерфейс и меняем DLSI-ку на 103. Гипотетически можно здесь поставить другие DLSI-ки, то есть вот это 103 и вот это 103, это не обязаны быть одинаковые DLSI-ки, они могут быть разные. То есть мы можем здесь сделать 1031, а здесь сделать там 1032. То есть это... Они могут назначаться случайным образом, но для удобства чаще всего они назначались именно вручную и назначались они именно как-то одинаково, чтобы трасса туда и трасса обратно использовала одинаковые номера. Для того, чтобы узлы у вас заранее знали, какие DLSI-ки использовать для отправки трафика к какому абоненту, использовалось два механизма.

Первый механизм — это ручное задание привязок. То есть у нас фактически, если есть какой-то роутер, один и второй, и они связаны между собой через Frame Relay-сеть, вот они должны будут отправлять друг другу кадры, и они должны будут указывать в каждом кадре номер DLSI-ки, который доставит трафик до другого абонента. Поскольку подключение ко Frame Relay — это единичная штука, у вас не может самозародиться в этом Frame Relay произвольное количество соседей. Вы за каждую трассу, которой вы пользуетесь во Frame Relay, платите деньги, платите деньги регулярно. Поэтому вы заранее знаете, какие DLSI-ки соответствуют какому абоненту. И вы можете просто сказать, если у нас есть роутер, допустим, первый, у него IP-шник 10.001, и роутер 2 — 10.002. Вот можно сказать, что на роутере R1 мы пропишем просто статикой, что IP-шнику 10.002 соответствует DLSI-ка, допустим, 102. То же самое на роутере R2. Мы можем сказать, что IP-шнику 10.001 соответствует DLSI-ка 101. И там 201.

И вот в этом случае, если мы статикой просто пропишем все, это не так сложно, как может показаться, учитывая небольшое количество связей между роутерами обычно во Frame Relay, небольшое количество купленных трасс, вот у вас трафик будет просто бегать. Второй вариант — вы можете воспользоваться механизмом автоматического распознавания адресов DLSI для известных вам соседей. фишка будет в том, что во Frame Relay есть такая штука, как сигнализация. И эта сигнализация указывает, какие именно DLSI-ки у вас живы. То есть если вы берете, подключаете ваш роутер к Frame Relay свечу провайдера, он вам может по сигнализации сказать, живет сотая DLSI-ка в этом самом канале. То есть где-то какая-то трасса присутствует, у которой DLSI-ки дальше за спиной этого свеча, могут быть какие угодно, но, соответственно, со стороны абонента он может пользоваться сотой DLSI-кой для того, чтобы трафик доставить куда-нибудь.

И если вы видите по сигнализации, что сотая DLSI-ка существует, вы во Frame Relay можете использовать специальный хитрый протокол, который называется Inverse Arp. Вы можете с помощью Inverse Arp отправить по известной живой вам DLSI-ке сообщение. У меня IP-шник там 1001 или 1002. Трафик, соответственно, пойдет по известной вам DLSI-ке. Вы отправляете на один свеч, потом он отправляет на второй свеч, тот на третий свеч, тот на четвертый. В конце концов узел получает по какой-то неизвестной ему заранее DLSI-ке сообщение. Там, допустим, 400 DLSI-ка пришла. И в этой DLSI-ке, в этой кадре с указанием DLSI-400 написано «Меня зовут 172, 168, там 5, 5». Меня зовут 10, номер один. В предположении, что провайдер прописал все трассы двунаправленные, если вам Inverse Arp притащил сообщение, что меня зовут там 10, 0, 0, 1, и оно пришло в сообщении с 400 DLSI-кой, вы можете в ответ отправить сообщение

«Окей, а меня зовут 10, там, 0, 0, 2» или 172, 168, 5, 6». То есть вы, получив сообщение от соседа с указанием его DLSI-ке и с указанием его IP-шника с помощью протокола Inverse Arp, можете предположить, что в обратную сторону трафик пойдет с указанием той же самой DLSI-ке до того же самого соседа. Здесь, конечно, есть определенные допущения. Конечно же, здесь есть нюансы, заключающиеся в том, что провайдер совершенно не обязан прописывать двунаправленные трассы одинаково с одинаковыми DLSI-ками, во-первых. Во-вторых, провайдер может использовать сигнализацию, которая несовместима с вашим роутером. Этих типов сигнализации будет 3 штуки, и они все проприетарные. Ну, там есть один стандартный вариант, два проприетарных. И вот эти вот стандарты, они все между собой несовместимы. То есть, если вы хотите использовать роутер, который поддерживает один стандарт, а провайдер использует другой стандарт, то вы не получите сообщение, что у вас живет определенный DLSI-ка. Кроме того, во Frame Relay, например, CISC, те же самые CISC роутеры позволяют создавать так называемые

субинтерфейсы. Вот Inverse Arp с субинтерфейсами не работает. Он работает только с живыми интерфейсами. Поэтому для того, чтобы это все работало, вам потребуется еще и полносвязная топология. То есть, если у вас полносвязная топология, вы можете использовать Inverse Arp. В предположении, что у провайдера все настроено, нет, безумно. В предположении, что у вас тип сигнализации с провайдером совпадает. Но в противном случае вы привязываете просто ручками IP-шники к известным вам DLSI-кам. Вы заранее можете позвонить провайдеру, сказать, дорогой провайдер, скажи мне просто голосом, вот у меня есть трасса там до Владивостока, какой номер DLSI-ки мне использовать, чтобы трассу до Владивостока пощупать. И он вам скажет, используя там 203 DLSI-ку. Для работы IP поверх Frame Relay, поскольку мы, скорее всего, работаем с IP, то вот для работы IP поверх Frame Relay нам, в общем-то, ничего особо не нужно. Протокол простой, как барабан. Вы просто указываете номера DLSI-ек, и вам для того, чтобы эти самые номера DLSI-ек указывать, надо либо статикой прописать их, либо воспользоваться вот этим самым INARP-ом

или inverse ARP-ом, то есть протоколом, который будет преобразовывать DLSI-ки в IP-шники. У вас DLSI-ки будут известны, потому что притащат их сигнализация, и если их притащила сигнализация, если провайдер все прописывал корректно, если у вас полносвязная топология, если у вас оборудование это поддерживает, вы сможете воспользоваться протоколом INARP для того, чтобы узнать, какой IP-шник соответствует какой DLSI-ке. Нельзя воспользоваться протоколом ARP, потому что обычный ARP, он работает тогда, когда у вас возникает желание отправить какой-то пакет на известный вам адрес, и вы хотите узнать его канальный адрес соседа. Вот. И ARP пользуется браткастом. Ну или даже если он бы использовал мультикаст, все равно ни браткаста, ни мультикаста во фрейм-рилейе нет. Просто самого типа взаимодействия нет. Трафик может пойти только по тем DLSI-кам, которые заранее вы указываете в каждом конкретном кадре. Но за счет того, что есть механизм узнавания того, какие DLSI-ки живы, какие прописаны дальше по трассе и какие не прописаны,

вот вы можете воспользоваться этим механизмом для того, чтобы хоть как-то распознавать IP-адреса. Если вам нужно будет перенаправлять какой-то трафик на другой узел, то есть у вас есть, например, свитч фрейм-рилейевский, несколько фрейм-рилейевских свитчей провайдера, на самом деле неважно, они могут быть одним, свитчом могут быть нескольким, и у вас три роутера подключены к провайдерской сети. Вот это роутер первый, это роутер второй, это роутер третий. И роутер первый видит, что какой-то кадр или какой-то IP-пакет приходит от второго на первый. Но роутер первый понимает, что трафик надо будет отправить обратно в ту же самую сеть на третий роутер для того, чтобы он пошел до получателя. То есть на самом деле второму не следовало посылать трафик на первый роутер, ему сразу надо было отправить трафик на третий. В этом случае у протокола ICMP есть такая штука, которая называется ICMP Redirect. Вы можете отправить сообщение соседу, что дорогой соседушка не посылает трафик мне, а посылает трафик вот ему. Если у вас полносвязная топология, или, по крайней мере, если прописана трасса между вторым и третьим,

она у вас куплена, прописана, корректно работает, то в этом случае второй роутер, увидев, что первый не хочет обслуживать этот трафик, и что он рекомендует для дальнейшей работы обращаться напрямую на третий роутер, в этом случае второй роутер будет посылать сообщение на третий уже. Он будет посылать те же самые IP-пакеты, но будет указывать дел сяйку третьего роутера в работе. Вот. Ну, в общем, понятное дело, что FrameRelay вы сегодня вряд ли будете использовать, и в курсе он есть только потому, что, во-первых, он есть в Blueprint, ну и, конечно же, интересно заложить некоторую базу под MPLS, потому что дальше MPLS у нас обязательно будет, и, как вы увидите дальше, MPLS действительно заимствует многие из этих идей, которые были во FrameRelay, так что все это дело не пройдет для вас даром. Так, дальше. Что еще бывает на канальном уровне?

Не только Ethernet, не только FrameRelay, не только PPP, не только HDLC. Есть еще и другие варианты. Из того, что стоит упомянуть, это у нас протокол ATM. Опять же, протокол, так же, как и FrameRelay, в свое время был очень популярен, был очень любим провайдерами, но так же, как и FrameRelay, он постепенно сдулся. Но только FrameRelay сдулся, потому что его все возможности были доступны в Ethernet, по сути. То есть, если вы заменяете оборудование FrameRelay на оборудование Ethernet, то для вас вообще ничего не меняется. Ну, немножко меняются адреса, ну, немножко меняется тип взаимодействия. Но FrameRelay, по сути своей, это точно такой же протокол, как Ethernet, только правила коммутации немножко отличаются. Ну, и формат кадра отличается. А вот ATM — это прям совсем другой протокол. То есть, он сильно не похож ни на FrameRelay, ни на Ethernet, ни на что. Этот протокол точно так же создавался для работы в SDN-сетях, ну, или в любом битовом потоке. То есть, те самые T1, E1 и все остальное.

Но нюанс заключается в том, что FrameRelay позволяет передавать трафик с произвольным размером кадра, а вот ATM не позволяет передавать трафик с произвольным размером кадра. У него есть фиксированный размер данных, который можно передать за один раз. И вот этот кусочек данных, который можно будет передать, протокол DataUnit в ATM, это очень странный такой кусочек. Он будет иметь размер 53 байта. Если вы скажете, что что-то как-то кривовато, то да, это 48 байт полезных данных и 5 байт заголовка. Там были в свое время при создании этого протокола споры, сколько следует сделать полезных данных, сколько следует сделать заголовка, и не сделать ли это все дело красивое, или там, допустим, как степень двойки или что-то еще. Но вот в итоге пришло это все к тому, что вы можете в каждой ячейке передать 48 байт содержимого и 5 байт заголовка. В ATM есть несколько разных форматов этих самых ячеек.

То есть формат в любом случае будет предполагать, что у вас 48 байт содержимого и 5 байт заголовка, но в разных случаях используются разные содержимые этих самых 5 байт. существуют ячейки, которые предназначены для того, чтобы получать трафик напрямую от пользователя. Существуют ячейки, которые позволяют передавать трафик между узлами от МСТ, то есть они имеют разный формат натурально. Вы получаете данные от пользователя, а потом у них на лету переделывается заголовок, и они дальше присылаются куда-то там еще. У них не просто меняется там адрес, как во фрейм-рилее, у них прямо натурально формат меняется. То есть у них заголовок целиком отрезается, вместо него приклеивается другой, совсем на него не похожий, по формату не похожий, и дальше пересылается в сторону соседнего свеча. В ATM у вас есть различные способы оказания услуг, различные, если хотите, типы услуг, которые вы можете предоставлять. Эта штука называется AAL, ATM Adaptation Layer.

Этих самых уровней в ATM было 5 штук, и, соответственно, вот они пронумерованы. AAL1, AAL2, AAL3, AAL4, AAL5. Эти самые уровни указывают на то, что вы, собственно говоря, будете делать. То есть что за данные в этом самом ATM будут передаваться. Вот эти самые 48 байт, они относятся к какой-то полезной нагрузке. Если у вас есть, например, какой-то канал, который вы хотите организовать с помощью ATM, вы можете сказать, давайте у нас есть узел отправителя, узел получателя, между ними есть какая-то ATM-сеть, и, соответственно, у нас есть вот эти самые ячейки, которые можно отправлять, и они фиксированного размера. Вы отправляете 48 байт нагрузки и 5 байт заголовка. Потом 48 байт нагрузки, 5 байт заголовка. 48 байт нагрузки, 5 байт заголовка. У вас получается сравнительно фиксированный по скорости поток. То есть вы можете отправлять данные в ATM на фиксированной скорости. Опять же, это все не случайно, это все как раз потому, что это все разрабатывалось телефонистами для телефонистов изначально.

И, как следствие, телефонисты, они привыкли работать с потоками, которые имеют фиксированную скорость. Ну и, как следствие, да, получается, что у вас внутри этих самых ячеек фиксированы, если хотите, битрейт, получается. Но вы эти ячейки можете отправлять или можете не отправлять. И тем самым вы можете относительно максимальной скорости, на которой может работать ваш интерфейс, трафик отправлять на средние скорости пониже. То есть немножко помолчали, немножко передавали трафик, немножко помолчали, немножко передавали трафик. Половину времени молчали, половину передавали, средняя скорость у нас эффективна по факту упала вдвое относительно номинальной скорости интерфейса. Если вы должны будете передавать трафик на какой-то фиксированной средней скорости, то вы использовали это с уровнем AL1. То есть это набор услуг AL1. он предполагал, что у вас постоянный битрейт. Например, для телефонной связи вы поверх ATM могли гонять, например, те самые T1 и E1. Что T1, что E1 — это фиксированная скорость, там, полтора или два мегабита.

И если у вас был интерфейс ATM, например, скорость 155 мегабит, то вы, отправляя данные немножко, но, соответственно, отправили немножко, помолчали немножко, отправили немножко, помолчали немножко, могли добиться средней скорости той, которая вам была необходима. Например, 2 мегабита. И если вам требовалось отправлять данные с постоянной скоростью и фактически по известной, хорошо известной трассе, то вы в этом случае заказывали уровень AL1. AL2 — это примерно похожий уровень услуг, но с переменной скоростью. То есть у вас трафик шел все равно по одной и той же трассе, хорошо известной, и количество данных в этом потоке, оно могло варьироваться. В этом случае вы заказывали услугу AL2. Это было полезно, например, в случае, когда вы хотели для беспроводных каких-то соединений использовать ATM в качестве канальной среды. В некоторых случаях это использовалось для голоса, который использовал специальные кодеки.

То есть не фиксированный кодек, который дает 64 кг, а какой-то кодек, который жмет данные немножко лучше. Ну, в этом случае вот как раз можно было использовать канал с переменным битрейтом. AL3 и AL4 тоже использовались для переменного битрейта и для трафика произвольного характера. Но они были адаптированы для того, чтобы вкладывать внутрь отемных ячеек какие-то данные совершенно-совершенно произвольной природы. Эти данные произвольной природы могли быть, например, фрейм-релеевские ячейки. То есть вы могли запихнуть фрейм-релеевские ячейки, побить их на части по 48 байт, распихать эти самые фрагменты фрейм-релеевских кадров по ячейкам и отправить эти ячейки все эти назначения. Потом собрать оригинальный пакет из того, что у вас прибежало. ATM такие штуки делать позволял. Ну и если вы использовали эту, то вы использовали как раз два уровня услуг – AL3 и AL4.

И последний уровень услуг – AL5 – использовался по сути своей так же, как AL3 и AL4. То есть это совершенно произвольная природа трафик, но с хорошо известными типами вложений. То есть для AL5 фактически у вас есть схема вложения, которая позволяет вкладывать IP в ATM или Ethernet в ATM. И если вы используете два вот этих вот типа – IP ATM в Ethernet в ATM, то вы можете использовать упрощенный заголовок. Он позволяет вкладывать не все подряд в себя, а только вот ограниченное количество вложений. И она просто – эта схема немножко попроще по сравнению с AL3 и AL4. Ну, она заточена под то, что это будет совершенно произвольный трафик с произвольным битрейтом, но вот вложение может иметь вполне определенный тип. В каждой ячейке вы указываете адресацию. То есть у вас есть адресация Virtual Path Identifier, Virtual Channel Identifier. Эта пара задает трассу, по которой могут идти ячейки. Кроме того, тут есть тоже один битик. Вот этот вот клип-битик. Он может управлять качеством отправки данных. Вот ячейки 48-байтовые плюс 5-байт заголовка.

Можете проставить битик, что оно потенциальный кандидат на выпадание в случае перегрузки. То есть если потеряется что-то, то пусть потеряется это. Кроме того, там была чек-сумма. Чек-сумма простенькая, 1-байтовая, но тем не менее она была. И, ну, в общем, все. То есть вот такая вот простая ячейка. С ATM вы сегодня встретиться еще сможете. Например, все ADSL-развертывания, которые были в свое время довольно популярны, они до сих пор используют чаще всего ATM. Всякие поны, гопоны, только не путайтесь, г-е-пон, они тоже используют ATM. То есть, в принципе, ATM еще не совсем сдох. Frame Relay уже совсем сдох, а вот ATM еще сдох не совсем. Он был в свое время очень популярен, но, тем не менее, сейчас уступил позиции более простым протоколам. Но понятное дело, что Ethernet и IP, они настолько проще, они настолько привычные в работе,

что незачем разбираться с тем, как устроен ATM, незачем городить огород, незачем строить сеть на дорогом, сложном и, главное, очень специфическом оборудовании, если можно все то же самое сделать на простой логике Ethernet и IP. Ну, поэтому новых развертываний ATM-сетей практически нет. Но, тем не менее, кое-где и встретить его еще можно. Если говорить про другие какие-то варианты канальных средств, они тоже бывают. То есть, даже если говорить про IE-шные сети, то там форматов кадров, вагона, маленькая тележка, и в том числе провайдерский сценарий предполагают, что вы в некоторых случаях такие экзотические форматы кадров будете использовать. Например, если говорить про Wi-Fi тот же самый, который, в принципе, в провайдерских сетях бывает, может быть, не совсем чистый 802.11, может быть, немножко модифицированный, но, тем не менее, он бывает. Там тоже свой формат кадров. Вы тоже должны будете знать, как примерно хотя бы эти кадры выглядят. То есть, иногда бывают люди, которые думают, что в Wi-Fi кадры такие же, как в Ethernet. Нет, ничего подобного, они там намного сложнее. И для того, чтобы понимать, почему Wi-Fi кадры другие, нужно будет знать кое-что о Wi-Fi.

Wi-Fi — это стандарт организации беспроводной локальной сети. То есть, если у нас локальная сеть, LAN, это предполагает, что у вас все узлы находятся рядышком друг с дружкой. Они находятся на небольшом расстоянии друг от друга, и, соответственно, они все примерно плюс-минус километра однорандовые. Кроме того, 802.11 Wi-Fi предполагает, что все узлы будут использовать одну и ту же частоту, как следствие у вас возможной коллизии. И в Wi-Fi коллизия — это очень неприятная штука, потому что ее очень тяжело обнаружить. Если у вас есть какой-то один узел, который находится в одной части помещения, и другой узел, который находится от него достаточно далеко, они могут друг другу передавать сигнал. И, соответственно, когда вы передаете сигнал, вы не можете услышать, что вам в этот момент кто-то тоже что-то передает. В Ethernet мы это сделать можем, потому что Ethernet сам кабель устроен таким образом, что если вы что-то передаете в кабель, вы сами себя не слышите. Поэтому ваш сигнал в Ethernet не забивает сигнал всех остальных. Вы слышите тишину, если вы сами что-то передаете.

А вот когда вы принимаете какой-то кадр в Ethernet, чужой, то вы слышите его хорошо. Если вы что-то отправляете, вы что-то принимаете, то вы понимаете, что сигнал, который вы отправляете, сигнал, который вы принимаете, одновременно накладывается друг на друга, а как следствие все остальные слышат какую-то чепуху. Вот в Wi-Fi вы не можете узнать, что кто-то передает данные одновременно с вами. В Wi-Fi ваш сигнал занимает частоту, и вы, если будете слушать сами себя, то вы оглохнете от того количества сигнала, который вы сами будете слышать, то, что вы сами находитесь ближе всего к источнику излучения. А все остальные узлы, которые будут отправлять трафик одновременно с вами, они будут настолько слабо влиять на принимаемый вами ваш собственный сигнал, что просто вычленить его из оригинального сигнала будет невозможно. Поэтому в Wi-Fi у нас используется схема предотвращения коллизий, не схема работы с коллизиями, которая была в изомете CSMA-CD, а схема именно предотвращения коллизий CSMA-CA, collision avoidance. Ну и, соответственно, в Wi-Fi узлы будут договариваться о том,

в какой момент времени они могут передавать данные для того, чтобы коллизий не устроить. Если говорить про альтернативные варианты того, что можно назвать Wi-Fi, это механизмы, как правило, на основе разделения по времени. То есть у нас есть, допустим, несколько узлов, которые хотят организовать передачу данных по радио между собой, но они не хотят реализовывать вот эту самую схему предотвращения коллизий CSMA-CA. Они хотят просто использовать примерно тот же самый формат кадра, но вот как-нибудь попроще. В этом случае вы можете договориться о разделении по времени, Time Division Multiplexion, что у вас есть синхронизированное время на одном узле, синхронизированное время с другим узлом. И там половину времени, там четные миллисекунды, может занимать среду один узел, нечетные миллисекунды может занимать среду другой узел. Но это предполагает модификацию стандарта. И вот эти вот все схемы с Time Division Multiplexion, это все, соответственно, нестандартные штуки. Для провайдерских задач иногда это бывает полезно,

потому что все вот эти штуки с предотвращением коллизий, они действительно очень сильно жрут время. Там, где вы могли потратить время на передачу полезного сигнала на высокой скорости, вы вынуждены тратить это время полезное, эфирное, на согласование процедуры арбитража, и весь арбитраж Wi-Fi делается на скорости самого медленного абонента. Ну или иногда вообще на самой маленькой скорости, на которой вообще возможно ваше оборудование. Поэтому все вот эти арбитражные штуки, они действительно жрут время очень сильно. И если вы, допустим, работаете на современном Wi-Fi, который работает, давайте, предположим, на скорость, не знаю, 800 мегабит в секунду, вот вы можете передавать данные на скорости 800 мегабит в секунду, если вы передаете, вы их действительно передаете на скорости 800 мегабит в секунду. Но это значит, что каждый битик вы передаете за там 1 800 миллионную секунду. И у вас, помимо этих данных, нужно будет еще в обычном Wi-Fi отправлять кадры арбитражные. А они отправляются на минимальной скорости, допустим, на скорости 1 мегабит в секунду.

Это значит, что пока вы передаете один битик арбитража, вы могли бы отправить уже почти полноценный кадр на скорости 800 мегабит. Если вы хотите передать кадр, допустим, самый-самый маленький, не знаю, 64 байта арбитражный, ну, самый простой, вы за время передачи этого арбитражного трафика могли бы уже отправить, там, не знаю, в войну и мир на нормальной скорости. Но на нормальной скорости арбитраж передавать нельзя, потому что кто-то его может не понять. Вот. Ну, поэтому в Wi-Fi, если вы в провайдерских сценариях Wi-Fi используете, то вы, как правило, вот эту штуку отключаете. Это в тот же момент, когда вы эту отключаете, у вас Wi-Fi перестает быть 8211 Wi-Fi, и вы включаете какой-то другой механизм, как сделать так, чтобы данные от разных участников не столкнулись между собой. Wi-Fi отличается тем, что все узлы работают на одной и той же частоте. Как следствие, вы можете отправить какой-то кадр, который дойдет до всех участников в среде. То есть есть мультикаст, есть бродкаст. Опять же, все механизмы арбитража, которые используются в Wi-Fi,

они с мультикастом начинают быть совершенно невменяемо сложными, но, тем не менее, мультикаст, бродкаст, Wi-Fi есть. Еще одна неприятная штука, которая есть в Wi-Fi, которую нужно тоже будет знать, это механизм управления качеством. То есть если вам нужно какой-то кадр отправить с указанным качеством, то, соответственно, здесь опять же возникают усложнения. Покуда мы просто не заботимся о том, что дошло, что не дошло, все отправляем одинаково, там проблем с этим особых нет. Как только нам нужно будет начинать передавать какие-то кадры, например, с указанием, что это кадры голоса, что их надо обрабатывать максимально приоритетно, что задержки нужно минимизировать, в Wi-Fi начинают вылезать страшные ужасные костыли. Но, опять же, да, поскольку наш курс все-таки не про Wi-Fi, а про провайдерские сценарии, в которых классический 802.11 арбитраж не используется чаще всего, то мы сейчас на это обращаем внимание просто из любопытства. На всякий случай, если вдруг вы будете работать с Wi-Fi офисным,

ну, мало ли, вдруг когда-нибудь доведется, полезные термины, которые есть в Wi-Fi, это режим работы. Самый простой режим работы IBSS, Independent Basic Services, это иногда называется Wi-Fi ad hoc, когда у вас несколько участников, абсолютно одноранговые, начинают передавать данные друг другу. Они все находятся на расстоянии вытянутой руки друг от друга. То есть, допустим, вот два-три ноутбука взяли, создали эту самую ad hoc сеть и передали трафик без участия точки доступа. Каждый отправляет трафик напрямую до каждого получателя. Вариант очень простой, но он, естественно, ограничен по расстоянию, он ограничен по масштабированию. Вы не можете сделать так, чтобы у вас была ad hoc сеть на 100 тысяч абонентов, просто потому что нужно, чтобы каждый узел видел каждого, чтобы у вас была прямая видимость от любого узла до любого другого. Если вам нужно организовать сеть на большое количество узлов, скорее всего, вы захотите использовать режим работы Wi-Fi BSS, Basic Service Set,

при котором у вас есть некий инфраструктурный узел, и этот инфраструктурный узел чаще всего называется точка доступа. Эта точка доступа расположена в центре Wi-Fi сети, и, соответственно, любой участник, который хочет организовать связь, он подключается к этой самой точке доступа. Вот фактически в этом случае взаимодействие между пользователями напрямую не происходит. То есть если вы используете режим работы BSS, то передавая кадр с узла номер один на узел номер два, вы не передаете кадр напрямую. Вы отправляете кадр с первого узла на точку доступа, а она передает этот кадр дальше на другой узел. То есть даже если вдруг вы хотите передать трафик с одного ноутбука на другой ноутбук, который оба зацеплены по Wi-Fi на точку доступа, трафик бегает не между ними, трафик бегает между каждым узлом и точкой доступа. А потом от точки доступа бежит на второй ноутбук. Поэтому вы половину времени будете кадр передавать с одного узла на точку доступа, а потом вторую половину времени вы будете передавать кадр на узел получателя.

Есть вариант, который называется ESS. Extended Service Set. Это режим, при котором у вас в Wi-Fi будет несколько точек доступа, несколько инфраструктурных узлов, и, соответственно, эти инфраструктурные узлы будут между собой передавать кадры, которые предназначены для разных абонентов. Если нам нужно сделать сетку на 100 тысяч абонентов, мы не можем взять и посадить всех на одну и ту же точку доступа. То есть мы это физически не сможем сделать. У нас будет расстояние не позволять это организовать. Помимо того, что это все еще и работать не будет, ну, то есть понятно, да, что в эфире, в котором находятся 100 тысяч приемов передающих устройств, там будет очень сложно выкроить хотя бы полсекундочки на то, чтобы передавать какие-то полезные данные. Но гипотетически, если бы мы хотели организовать большую сеть, в этом случае мы бы не смогли разметить всех на одной и той же точке. Мы должны были бы поставить несколько точек. Если бы мы хотели организовать реально одну и ту же Wi-Fi-ную сеть, то в этом случае мы могли бы сделать следующую штуку. У нас есть узел, называется станция, допустим, 1,

и узел станция 2. И у нас есть точки доступа AP1 и AP2. Вот. Если вдруг мы хотим передать кадр со станции 1 на станцию 2, поскольку в режиме IBSS мы можем передавать кадры друг другу напрямую, а в других режимах мы не можем передавать кадры друг другу напрямую, мы должны передать кадр тому, до кого мы можем дотянуться. В нашем случае станция 1 может дотянуться до точки доступа 1. И он отправляет кадр. И в этом кадре нужно будет написать, что я, станция 1, отправляю кадр. В конечном итоге я хочу доставить кадр до станции 2. Но, соответственно, поскольку мы используем режим работы не IBSS, а какой-то другой, в нашем случае вот этот вот сценарий будет называться ESS, мы должны будем отправить этот кадр точки доступа. И поэтому у нас в кадре, который будет отправляться, есть указание, кто отправляет, есть указание, кому отправляет, есть указание, кто является непосредственным получателем этого кадра прямо сейчас,

в нашем случае точка доступа 1. И в сценарии, когда точка доступа 1 такой кадр получит, она должна будет его передать на ту точку доступа, на которую зацепилась станция 2. И в этом случае кадр будет передаваться от точки доступа 1 на точку доступа 2, по Wi-Fi тоже. И в этом случае адресов в этом кадре будет аж 4 штуки. Когда точка доступа 1 передает кадр точке доступа 2, она пишет, что это кадр, который отправил изначально станцию 1, конечным получателем является станция 2. На радио уровне это все дело сейчас прямо отправляет точка доступа 1. И непосредственным получателем этого кадра прямо сейчас будет являться точка доступа АП2. То есть в каждом кадре у нас может быть 4 MAC-адреса. Это немножко удивительно после Ethernet, в котором у нас было 2 MAC-адреса, и один из них был не нужен. Здесь вот их может быть 4 штуки. Причем в разных сценариях может использоваться разное количество MAC-адресов. Если у нас используется, допустим, BSS или IBSS, то там всего 3 MAC-а. И еще одно место, оно просто пустое. Ну, как оно там есть, но оно не используется. А в сценарии, когда у вас используется ESS, Extended Service Set, у вас в каждом кадре реально 4 MAC-а.

Если вдруг вы подумали, что, ну, ладно, 4 MAC-а, ну, еще бывает, я вас сейчас добью. Вот так вот выглядит кадр формата 802.11. Сначала идет двухбайтовое поле Frame Control. То есть там по битам будет много-много-много разных полей. Я сейчас не буду вас утомлять и говорить, какие конкретно поля, за что будут отвечать. Но поверьте, здесь полей много. Это вот просто первые два байта, которые вот здесь вот есть. Потом два байта будет указание на то, сколько времени вы собираетесь передавать этот кадр. В Ethernet в обычном мы передаем какой-то кадр, мы его передаем на хорошо известной скорость. У нас есть скорость там 10 мегабит, например, или 100 мегабит. И получатель знает, на какую скорость он работает, и он не может получить кадр на какую-то другую скорость. То есть кадр всегда идет на одной и той же линейной скорости. У нас есть 100-мегабитный канал. Значит, 100 миллионов бит в секунду приходят на этом интерфейсе. Каждый битик передается за одну 100-миллионную секунду. В Wi-Fi у нас может быть такое, что все абоненты работают на разных скоростях. Частота одна и та же, а скорости, на которых работают абоненты разные.

Точка доступа всех своих абонентов знает наперечет. И на какой скорости они работают, она тоже знает. Но может быть такое, что у нас есть какая-то вот такая точка доступа. На ней сидят абоненты. Один абонент, не знаю, сотовый телефон на столе лежит. И другой абонент тоже сотовый телефон на столе лежит. И один абонент начинает передавать какой-то кадр на точку доступа. Второй сотовый телефон, рядышком лежащий, он слышит все это дело. Он видит кадр, который идет. Но он может не уметь работать на той скорости, на которой кадр передается. И для того, чтобы можно было указать в кадре, сколько надо будет ждать до тех пор, пока этот кадр передается, каждый кадр начинается с указания того, какой он по длине. Причем не какой он по байтам, а вот какой он реально по секундам, по мили секундам. Сколько надо зажмуриться, чтобы дождаться, пока кто-то другой, какой-то кадр, который вам будет неинтересен, закончит передавать. Этот механизм изначально там был, потом его немножко модифицировали, но по большому счету он примерно так вот работает. Потом идет три MAC-адреса. MAC-адрес 1, MAC-адрес 2, MAC-адрес 3. То есть кто отправитель, кто конечный получатель и кому кадр передается прямо сейчас.

И, соответственно, потом идет двухбайтовое поле sequence control и еще идет четвертый MAC-адрес. Это вот кто на радиоуровне отправляет этот кадр в случае с режимом ESS. В конце любого кадра у нас идет чек-сумма 4 байта и, наконец, содержимое. Причем Wi-Fi содержимое может иметь размер до 2,5 килобайта. 2 312 байт. То есть вы можете отправить кадр, и в этом кадре будет столько вот места. Иногда говорят, что Wi-Fi может быть до 1500 байт. Нет, ничего подобного. Wi-Fi кадры могут быть достаточно жирные. Понятное дело, что если вы используете Wi-Fi для того, чтобы передавать в нем IP-пакеты, которые предназначены для интернета, вы не будете генерировать IP-пакеты больше, чем 1500 байт. Потому что дальше с ними должно что-то произойти, они должны уйти в интернет, там желательно не фрагментироваться. Но, тем не менее, как бы на канальном уровне Wi-Fi позволяет делать большие пакеты. На основе Wi-Fi есть, на основе 802.11 Wi-Fi есть разные механизмы организации канала.

Есть, например, вариант, при котором вы делаете радиорулейку. Если вы делаете радиорулейку, и вы точно знаете, что ваше оборудование имеет только природу, точка, точка, там ниоткуда не возьмутся какие-то другие абоненты, вы можете отключить SMACD или CA, вы можете использовать какую-то простую схему STDM, вы можете делать все, что угодно. Да, вы можете использовать формат кадра Wi-Fi просто потому, что он там есть, и он, в принципе, решает достаточно неплохо большую часть задач, которые вам нужно при организации радиорулейного канала. Ну и вот такие вот схемы, когда вы берете фактически кадр формата 802.11 и дальше отключаете механизмы, которые в полноценном Wi-Fi вам не нужны, вы можете тем самым заметно ускорить работу вашей радиорулейной линии. Есть куча маркетинговых терминов, которые обозначают примерно это, что вы покупаете железку, в которой кастрированный 802.11 Wi-Fi превращается во что-то Wi-Fi подобное, и оно работает быстрее, чем полноценный Wi-Fi, который очень осторожный, который пытается не устроить коллизию.

Вот в кастрированном Wi-Fi для операторов чаще всего все механизмы, которые связаны с коллизиями, они сильно вырезаны. И получается, да, такой псевдо-Wi-Fi, заточенный под операторские задачи. Соответственно, вот эти вот псевдо-Wi-Fi, они, как правило, имеют какие-то специальные свои маркетинговые термины. Может называться Radio Ethernet, может называться там Wireless Gigabit. То есть много разных способов, как это можно назвать. Смысл у этого всего примерно одинаковый. Вы берете Wi-Fi, отрезаете от него все ненужное, и получаете что-то, что заточено под ваши операторские задачи. Так, на этом я предлагаю тему с форматами кадра считать закрытой, и, соответственно, перейти к следующему модулю.